Sitecore 8 Profiling Visitors for Beginners

The first step to deliver Personalisation for Anonymous Visitors of your web site is knowing your Visitors through the pages that they have visited…

Sitecore allow you to Profile your customers interests and behavior through the Profile framework where you can define the Profile Keys, Profile Cards and PatternMatch Cards.

In order to be able to fully benefit from this feature, you need to have XDB & Analytics enabled so that you can fully track your customer behavior.




As you can see, there is not always a clear classification, but often the definition touch multiple dimensions…

Once that you have defined your Profiles, it is time to TAG your content so that you can classify your visitors….



Once that you have defined your Profiles and Tagged your content you can easily identify your Anonymous visitors and start delivering personalized content based on the interest and behavior that you were able to track….

Some example of personalisation rules are reported here…






Integrate AKAMAI with Sitecore to deliver GeoIP personalisation

As probably not everybody knows AKAMAI offer as well GEOIP resolution capabilities based on MaxMind database.

OOTB Sitecore offer GeoIP personalisation based on their cloud service that consume MaxMind database, Sitecore charge customers for this service and in case you are not using Akamai, this could be an easy and effective way to have GeoIP in place without writing any code but just paying for Sitecore GeoIP service.

Therefore if you are already using AKAMAI and Sitecore GeoIP personalisation you should consider following this route…

In order to get AKAMAI to deliver personalisation you need to enable Content Targeting via property manager obviously you need to ensure that Content Targeting is included within your AKAMAI contract.


Once that you have this in place, you will simply get GeoIp information injected within your http header that should look like:

X-Akamai-Edgescape: georegion=263,country_code=US,region_code=MA,city=CAMBRIDGE,dma=50 6,pmsa=1120,areacode=617,county=MIDDLESEX,fips=25017,lat=42.3933,l ong=-71.1333,timezone=EST,zip=02138-02142+02238-02239,continent=NA ,throughput=vhigh,asnum=21399

In order to configure Sitecore to read the following header instead than calling the original service, it is recommended to implement your custom lookup provider. Implementing your custom lookup provider is fairly simple since you need to inherit from Sitecore.Analytics.Lookups.LookupProviderBase and override WhoIsInformation to read your information from the HttpHeader and return the information as within the whoIsInformation object.

using Sitecore.Analytics.Lookups;
using Sitecore.Configuration;
using Sitecore.Diagnostics;
using System;
using System.Web;
using System.Web.Hosting;

namespace xxx.Akamai.LookupProvider
    public class AkamaiGEoIpProvider : LookupProviderBase
        public string ExtractValue(string keyName, string headerValue)
            //ToDo: nice regex to Parse Value

        public override WhoIsInformation GetInformationByIp(string ip)

            WhoIsInformation information = new WhoIsInformation();
            var headerValue = Request.Headers["X-Akamai-Edgescape"];
            information.Country = ExtractValue("country_code", headerValue);
            information.PostalCode = ExtractValue("zip", headerValue);
            //etc etc to set all the value for the information object

            return information;

Once that you have implemented your lookup provider you would need to regiter within the web.config your own provider

        <patch:attribute name="defaultProvider">akamai</patch:attribute>
          <add name="akamai" patch:after="processor[@type='Sitecore.Analytics.Lookups.MaxMindProvider,Sitecore.Analytics']" type="xxx.Akamai.LookupProvider.AkamaiGEoIpProvider,xxx.AkamaiGeoIp">/>

Useful resources to consider when you implement a custom lookup provider are the following ones:

Sitecore GeoLiteProvider:

CircuitBreaker design pattern:

Akamai Edgescape Parser:

Sitecore 8 Personalisation rules for beginners

Probably most of you are already aware of what it means personalisation in Sitecore 8 but in case you have not heard about it, this post will give you a better idea of how Sitecore has implemented it…

Within Sitecore the easier way to deliver a Personalised experience is through Personalisation Rules at Rendering level.

The starting point is defining a page with one rendering and click on the Personalise button


From here you will be able to select your rule:


Once that you have selected your rule, you will than be able to select the actions associated to the conditional rendering that could be setting a different datasource, or Hiding the rendering or displaying a different rendering


Sitecore 8 allows the Developer to customise Rules but OOTB it comes with the following rules to personalise your content:

Sitecore Rules are grouped in the following logical categories:

Campaigns: Condition based on the campaign defined, newsletter, landing page, etc
Channel: Condition based on the channel, web, mobile etc
Date: Condition based on the date & time of the visit
Device: Condition based on Device capability (it rely on NetBiscuit service charged separately)
GeoIp: Condition based on user geolocation (rely on Sitecore service based on MaxMind, charged separately
Outcomes: Condition based on the engagement plan status and outcomes triggered
Security: Condition based on user security context, eg.  is anonymous etc
Social : Conditions based on Social network information, in the case the user has a federated identity via social network can be used to personalised on the profile information
Visit: Condition based on the current visit (eg. goal / event, campaign, previous interactions, engagement value, search keyword etc)
Visitor: Condition based on previous interactions (require analytics to be enabled)



Sitecore as a Service… is it really a good idea?

Sitecore as a Service is the first thing that would come to the mind to a Developer / Architect who is not familiar with Sitecore.

The idea is pretty simple, the non Sitecore developer think: “I do not like products, I do not know how to use Sitecore, I do not want really use it, but I have to… therefore I am limiting the dependency and the role of Sitecore within my architecture”

Unfortunately most of Developers still understand Sitecore as a CMS rather than a Digital Martketing Suite and cannot really get the difference and the benefit of it…

If you have heard about this consideration and you have been in similar situation, this is the right post for you….

As you probably know, Sitecore architecture is pretty flexible and allow you to use Sitecore in a variety of way, consuming Sitecore through the OOTB web api to manage the items or write a custom webApi just to serve content items as a web service or a rest endpoint serving Json is fairly simple and you can find plenty of documentation about it. Other way to access your content structure is through the use of Dictionaries or customising your publish pipeline to create static Json/JS files is also a simple way to consume the content information.

The following approaches are considered a quick win for “non Sitecore developers” who think I will be in control of my website / application, Sitecore will just give me HTML via Json and I will do the rest without having to tunnel all my request through Sitecore pipeline…

Reality for Sitecore people is very different…. the reason for tunnelling all your request through Sitecore pipelines are multiple ones and before going for the “content as a service” should be really considered to tunnel all your request through Sitecore for the following reasons:

  1. Content structure and your website features are very bounded and you cannot decouple it. Decoupling it, you would loose a lot of benefits (eg. Seo, friendly url, linking content elements, etc)
  2. Page Edit mode you would loose it
  3. Page composition having the ability to control page structure on Sitecore open the doors to an infinite number of possibility for your Authoring team allowing them to control your application.
  4. Renderings associated to Content Items associating renderings to Content Items via Datasource allow you to test different configuration and permutation of your application and encourage re-usability principles within your code.
  5. Personalisation allows your content team to deliver a personalised experience is one of the key selling point of Sitecore, decoupling the content from the application would effectively prevent you to Personalise the experience through Sitecore. Sitecore echosystem leverage personalization of Renderings to show and Datasource to use via Sitecore rules.
  6. Content Testing is key in the digital age, continuos testing is the new culture and bypassing Sitecore pipeline force you to a Non Sitecore MVT testing approach.
  7. Analytics & Behaviour personalisation require your Sitecore implementation to tunnel all the request within Sitecore pipelines, moving out from it would mean effectively preventing your trading team to benefit from the great benefits coming from Sitecore

Having done these considerations, is fair to say that if all what you need from Sitecore is the Authoring shell to upload content and images and you are happy to consume Sitecore as Service, you would still benefit some of the features of an enterprise CMS


SQL Azure and Sitecore Retryer

If you are deploying Sitecore on Azure and you are using SQL Azure, you should know that you could experience some connectivity issue between your Sitecore instance and your database…

Therefore it is strongly recommended to enable a retry mechanism on Sitecore data provider to recover these intermittent connectivity issues.

This is the default configuration that you will find in your web config, and what you need to do is to switch disabled to false….

you can either keep the logging enabled/disabled to log these connectivity issues and change the interval setting, but I would recommend to keep the default value…

<retryer disabled="true" type="Sitecore.Data.DataProviders.Retryer, Sitecore.Kernel">
      <param desc="Number of tries">6</param>
      <param desc="Interval between tries">00:00:00.500</param>
      <param desc="Log each exception (should be used for debug only)">true</param>

Sitecore & CDN

Sitecore has a well known limitation in the number of concurrent hits per second to serve for each content delivery.

A healthy Sitecore CD  instance on a decent hardware can probably support a maximum 200 hit per second, this number depend on the complexity of the renderings, items involved and on the caching strategy.

Therefore it is strongly recommended to implement a CDN server or a Reverse proxy in order to minimize the number of requests to the static assets served from Sitecore, leaving to Sitecore to serve dynamic pages only and leaving to the CD to serve only the Content Items rather than css, js, images, in this way your CD would be probably able to serve a much higher number of requests (generally a modern web site, for each page,  consume 30/40 static resources)

A typical use of the CDN is to request images/static files from the media library, even if the media library should cache all the assents on the file system, it is good to serve the requests from a CDN to offload the work of the CD, the network and improve the page load.

Configuring Sitecore media library to support a CDN is pretty simple, you need to adjust the following settings:

<setting name=”Media.MediaLinkServerUrl” value=”” />

<setting name=”MediaResponse.Cacheability” value=”public” />

In the case you decide to use Azure CDN, you can point it to the CDN folder and therefore you could need the following rewrite url Rule:



<rule name=”RewriteIncomingCdnRequest” stopProcessing=”true”>

<match url=”^cdn/(.*)$”/>

<action type=”Rewrite” url=”{R:1}”/>





In the case you won’t go with a full CDN you can consider implementing a reverse proxy to cache static requests and offload the number of requests from the Content Delivery.

Here you can find a reference on how to configure a reverse proxy.

An other possibility is to use the CDN or a reverse proxy to cache HTML static pages, in this way your site will be able to serve an higher number of clients, keeping low the number of CD… obviously this deployment scenario would not work well with the personalized and dynamic content served to different users and I would definitively recommend to think carefully before taking this route that would help you with performances but it would limit the functionalities.

Sitecore on Azure

When it come to deploy Sitecore on the cloud and more specifically to Azure there are several approaches and alternatives.

The biggest decision is to go with a PAAS or IAAS or decide for an Hybrid approach



In order to deploy Sitecore on PAAS you need to ensure that your license allow you to do it:

There are 2 way to achieve it:

Azure Module

This is recommended if you have to deploy environments across multiple datacenters easily


You can convert your web application in VS to a cloud service in order to deploy it, this guideline explain the steps


  • Less infrastructure (no windows update, security fix etc)
  • Easier to configure Auto Scaling
  • Easier to provision dedicated environments


  • Less control on when an instance got recycled
  • Less knowledge and experience in the team and worldwide
  • Not supporting some of the Sitecore Modules in the market place
  • Increasing the complexity level to monitor the infrastructure


  • Cold deployment, it could be achieved having a staging infrastructure to switch the traffic during the deployment. Having all the CD the same config, you would have only one publishing target.
  • Less control on Indexes
  • Provisioning time of a single instance could take long time
  • Continuous Delivery instrumentation is a bit more difficult
  • Verify if logs can be stored on the Application log or use an azure storage account or custom appender


You deploy Sitecore on Azure VM


  • Allows more complex and tailored deployments scenario
  • Easier to instrument Continuous Delivery
  • Support multiple targets and simplify cold deployments
  • Lower the complexity level of the solution
  • Easier to switch to Amazon / other cloud provider


  • More infrastructure to worry about windows update, security fix etc
  • Provisioning of new environments could take longer
  • Higher overall cost (TBC)


IAAS with SQL AZURE and XDB Cloud

This approach it is an hybrid approach between PAAS and IAAS.

We are envisioning the use of VM for hosting the Sitecore Instances and the use of SQL Azure for the databases and Cloud XDB service for the analytics (a decision if we want to use Sitecore analytics and the best infrastructure to use has still not be taken and it will be considered later on)

Sitecore recommend to deploy the database tier on SQL Azure V12 using Standard or Premium tiers for better performances


  • Allows more complex and tailored deployments
  • Easier to instrument Continuous Delivery
  • Support multiple targets and cold deployments
  • Lower the complexity level of the solution
  • Lower the cost and maintenance of SQL
  • Lower the cost and maintenance of XDB for analytics
  • Easier to switch to Amazon / other cloud provider


  • Still need VM with IIS to deploy Sitecore

Hybrid scenario

It is fairly common an hybrid scenario deployment where CM are hosted on premises / IAAS and the CD servers are hosted as WebApps. The reason for it  is  that generally you don’t need to scale the CM instance.

Hybrid scenario can point the IAAS server to SQL Azure and to XDB cloud as well.