Start of Main Content

Personalization delivers targeted content to users based on their behavior or demographics. It enables you to provide personal experiences on your website that engage your users. To personalize your website's content, Sitecore provides a variety of out-of-the-box options such as geolocation, device type, and behavior from current and past visits. The best thing about Sitecore personalization though is that it's highly customizable: almost any condition you can determine via code can become a personalization rule. This means that any accessible data can be a source to personalize your content.

If you want more data about your users than what you can access by default in Sitecore, external data service providers like Kickfire or Demandbase can help.

For this post, we'll focus on a Kickfire integration that we recently implemented for a client. Kickfire determines a user’s company based on their IP address and provides data such as company name, website, size, revenue, category, etc.

Our first step to leverage this company data for personalization was to set up the integration with Kickfire. We won’t go into detail about the integration, because the focus of this post is how external data is leveraged for personalization. In short, we made a call to the Kickfire API and stored each piece of data returned in a separate cookie. In this instance, we used cookies because our website was not using Sitecore xDB (more on xDB later).



The API call is done client-side or server-side. It’s better to do it server-side so that the data can stored prior to the first page load, but this requires your site to have access to the True-Client-IP if your site is on a CDN or load balancer (True-Client-IP exposes the user's real IP, which may be masked by the CDN). In our case, the client’s Azure CDN subscription didn't include True-Client-IP and we were unable to upgrade it, so we made our Kickfire call on the client side with Javascript. This worked fine, but we had to make sure the cookies were set prior to the first page load, in case the page contained content that was personalized based on these cookies. Personalization is done on the server-side prior to page load, so the data needs to be available at this time. Because Javascript is client-side, the cookies cannot be set by Javascript until after the first page load.

Ready to kick off your next digital marketing project? Start the conversation.

We can’t wait to hear all about your organization’s unique needs and develop innovative ways you can foster lasting connections with your audiences.

To make sure the personalized content showed on the first page load, we modified the Kickfire Javascript so that if the cookies weren't set yet, the page would appear blank and then refresh once the cookies were set. This meant that the personalized content was technically appearing onthe second page load, but to the user it still appeared to be the first load, and they never got to see the content prior to personalization. Because this Javascript set-cookies-and-reload solution is a workaround, I recommend always retrieving and storing personalization data on the server-side (prior to when personalization occurs in the Sitecore pipeline) if possible.

Once the Kickfire API call was complete and our cookies were set, we created a personalization rule to use the Kickfire cookies. This part was easy, and the rule we created was very flexible. It wasn't just limited to Kickfire data, but instead to any data stored in a cookie. We created a personalization rule to check if the value of a specified cookie matched specific text:


Code snippet

We configured the rule in Sitecore to accept a value for CookieName and CookieValue, which got passed into the code shown above.

(A quick note: With GDPR, websites must get the user’s consent to store cookies, and this means that if the user opts out of cookies, we can’t use them to track our Kickfire data. If this is an issue for your site, you can put the Kickfire data in session state instead and update the condition code to check either cookie or session state.)



With the above rule, our client can create personalization conditions based on any cookie. Using the Kickfire data, they can create personalizations based on how many employees or how much revenue a user’s company has. They could also personalize based on the industry of a company (e.g. Telecommunications, Manufacturing, or Digital Strategy) or create personalization rules based on a company's name or website. With this data, our client can display targeted content to specific preferred or prospective clients, or they can even hide content from their competitors.



We did this with cookies because our site did not have Sitecore xDB set up. However, there are benefits to using xDB instead if it's an option. If xDB is enabled, rather than storing the data in cookies or session state, you can store the data as custom contact facets and retrieve it that way. This allows you to get analytics on your personalized content to see how well it's performing, and makes the data available for other parts of the xDB ecosystem, like Marketing Automation and segmentation.

We previously mentioned that this approach to personalization isn't limited to Kickfire. It can be for any cookie (or contact facet). Whatever external data service you want can expand your website's personalization capabilities. As we've demonstrated, if you can access external data, you can personalize with it in Sitecore.


Latest Ideas

Take advantage of our expertise with your next project.