Skip To Content

Kentico Extensibility: How to Identify Unique Visitors in a Headless Architecture

At Kentico Connection Denver, we had the privilege of presenting a case study about using a headless architecture with Kentico EMS. Using a headless architecture provides our customer the benefits of Kentico EMS without disrupting their existing architecture or forcing a rewrite of their e-commerce website. This enables their robust e-commerce site to present marketing content managed in Kentico. It also allows them to use Kentico's online marketing features, like contact management and activity tracking.

The Challenge

In order to use Kentico’s EMS features in a headless architecture, you’ll need to create a Web API endpoint for logging contact activities (more about that here). However, it is important to remember that Kentico's activity tracking features are not natively designed to be used in a headless architecture. For example, Kentico uses a cookie for identifying and tracking unique visitors (in Kentico, “contacts”), but within a headless architecture, it does not have access to the web visitor's cookies.

Fortunately, because Kentico is very extensible, it allows deep customizations that enable it to satisfy unique customer needs. In this case, Kentico allows you to change how it identifies unique contacts when tracking activities.

cookie consent workflow

To clarify the challenge, if we allowed Kentico to use cookies to identify unique contacts, it would recognize only eight unique users -- one user for each of the eight e-commerce servers in the ecosystem. Every time a new email address was submitted for an activity, such as a form submission, Kentico would merely update one of the few contacts already identified with Web API client cookies.

The Solution

To solve this problem, we moved the responsibility of identifying unique contacts from Kentico to the custom e-commerce site. We configured the e-commerce site to create a current-contact cookie for each site visitor, and then whenever it identified a new visitor without a current-contact cookie, the e-commerce site would generate a new ContactGuid and store it in the cookie. This approach allowed the e-commerce site to provide the ContactGuid to Kentico every time it logged an activity through the custom Web API.

This would not have been possible if Kentico did not allow customizing how unique contacts are recognized. Fortunately, it is so extensible that it allows replacing its built-in ICurrentContactProvider with a custom one. However, it turns out we didn't even have to go that far. Kentico's built in ICurrentContactProvider includes a SetCurrentContact(ContactInfo) method which allowed us to set the current contact according to the ContactGuid parameter in the Web API.

To demonstrate how straightforward Kentico made this to configure, here’s a simplified example of the code that sets the current contact based on a Web API parameter:

// Try to get the current contact with the ContactGuid.

// If a contact is not returned, check the VisitorToContactInfoProvider.

// The ContactGuid may have been replaced and changed to a

// VisitorToContactVisitorGUID after contact merging.

var contactInfo = ContactInfoProvider.GetContactInfo(contactGuid) ?? 

     VisitorToContactInfoProvider.GetContactForVisitor(contactGuid);

// If not contact exists for this contactGuid, create one.

if (contactInfo == null)

{

    contactInfo = new ContactInfo

    {

        ContactLastName = $"Anonymous - {DateTime.Now : yyyy-MM-dd HH:mm:ss.fff}",

        ContactMonitored = true,

        ContactGUID = contactGuid

    };

    ContactInfoProvider.SetContactInfo(contactInfo);

}

// Set the current contact

var currentContactProvider = Service.Resolve<ICurrentContactProvider>();

currentContactProvider.SetCurrentContact(contactInfo);

If Kentico was not such an incredibly extensible platform, implementing it with a headless EMS architecture would not have been possible. For example, because Kentico allowed us to change how it identified unique visitors, we were able to implement contact management and activity tracking through a Web API. It’s details like this that enable us to implement solutions to meet unique customer needs.

Have questions on how to get the most out of your Kentico implementation? Drop me a line on Twitter (@HeyMikeWills), or contact our BlueModus team of experts today.