allBlogsList

Tracking users with Sitecore DMS across sessions locations devices and a couple of Christmas wishes

One of the (many) great things about Sitecore DMS is the ability to track users across sessions – not only are you able to adapt your site to the user’s behavior in the current session without any customization at all – you can do it across multiple sessions to work off of the user’s full history. It sounds awesome – it IS awesome – but not (yet) perfect. Let’s take a look at how Sitecore DMS works when it comes to recognizing returning users: Those familiar with Sitecore over the past couple of years have probably heard the story about a man buying a dishwasher one week, then returning to the store the following week; In the real-life store the man is recognized by the sales rep and instead of trying to sell him another dishwasher (which would be waste of time, since he already has one), the sales rep can use his knowledge about the customer to upsell accessories, soap etc. If the visitor has purchased the dishwasher through a (not-so-smart) web site, the site wouldn’t know about his previous purchase and would automatically try to sell him another dishwasher – since that’s what the web site is configured to do. The point to this story is that the web site would be much more efficient at selling (and upselling) to the customer, if it actually recognized him and knew about his purchase history. Luckily Sitecore can do this right out of the box with DMS, and while Sitecore hasn’t invented the concept of recognizing returning users and utilizing previously acquired knowledge about them, Sitecore DMS has certainly made it much easier to deal with, as most of the basic tools are readily available. But – let’s take a look at how it is actually done:

Tracking and recognizing the returning anonymous user

Looking deeper into Sitecore DMS (been there, done that, still waiting for the t-shirt), reveals that there are some core concepts that are highly relevant for the discussion at hand. First, let’s see what those are in terms of DMS:

  • Visitors: The Visitor is your “user” in the Sitecore analytics database. For our purpose it is enough to consider a visitor “someone who has one or more visits to the web site”.
  • Visits: A visit is more or less the same as a session. There are subtle differences between the two, but none that really matter in this context. A visit is fundamentally a collection of pages viewed in the session plus some basic data about the visit itself.
  • Pages: The individual page views with information about the item viewed, time stamps etc. Also very relevant for our discussion here is that each page view can have triggered page events such as goals that signal that some action has been taken by the user and something has been accomplished.

Note that this is a very simplified way of describing DMS and the Analytics database – there are lots of more facets to it such as GeoIP, Campaigns, Visitor tags, Multivariate testing and more – but that’s for another blog post (or five) J To automatically recognize a previous user, Sitecore uses its GLOBAL_SESSION cookie that matches the visitor. That means that when a user returns to the site, the GLOBAL_SESSION cookie is recognized and the new visit is tied to the existing Visitor record. That’s awesome, isn’t it? Not just do we recognize the user from having been with us before – we also know what he has done, what pages he has visited, what goals he has accomplished and so on – which has brought the web site in the shoes of the sales rep above; we don’t need to try to sell the visitor a dishwasher – we know that he already has one – so maybe we should instead start asking him if he is happy with it and if we can help with other stuff? So – the vision has come through – the web site can now recognize the visitor the same way as the sales rep and base it’s approach upon previous visits, purchase history etc. just by seeing the customer enter the store/web site. Everything is good – or is it? What if the sales rep is not at work when the customer comes back – or it’s been so long that the rep doesn’t remember the customer? And even worse – what if the customer walks into another store location where no one has seen him before? While most customers are reasonable people, they will still feel it’s a waste of time if somebody tries to sell them yet another dishwasher. Sitecore DMS has similar problems recognizing anonymous users using a cookie-based approach. This is not really a weakness of DMS, but just general characteristics about cookies – they may fail for our purpose if:

  • The visitor uses another browser to access the site, as cookies are browser specific
  • The user accesses the site from another computer or device
  • Someone else is using the computer
  • Cookies are cleared

In all of the above cases we cannot recognize the returning visitor correctly – either we think we don’t know him at all – or we think he’s actually somebody else – so what do we do? The answer is simple – we need to uniquely identify the user – we need him to create a user account and log into this account. While this can be done in many ways, depending on audience, site etc., we’ll for now assume we can get him to do it, which brings us to:

Unleashing the full power of the DMS – what we can do for the returning user when he logs in

So – tracking users when they are logged into a web site is certainly nothing new – this is a very well-known concept and not revolutionary in any way – so why is it interesting here? Let’s take a step back and look at one of the core benefits of DMS: It keeps track of visitor behavior and actions without requiring the visitor to provide any explicit information – it simply records what the visitor does from browsing, accomplishing goals, accumulating profiling information and so on. This is the part that makes Sitecore DMS a dream to work with – since it’s all available out of the box with no need to code it. While we of course like “explicit” facts provided by the user directly, the “implicit” information gathered by DMS gives us enormous insight in the visitor, his preferences, actions and other measures we can use to serve him better by building on our knowledge about him – not just from what he is doing here and now – but from every time he has visited our web site or been in touch with us at all – either online or offline. Sitecore allows you to map an authenticated user to a Visitor record in the analytics database via the externaluser field, thereby pairing your unique identification of the user (the user account used to log in) with the DMS visitor – and suddenly we know everything from every visit to the site having eliminated the weaknesses from the cookies as described above. So the value of DMS has been fully unleashed – we can now use all our knowledge about the visitor, whether implicit (from behavior) or explicit (from form submissions, CRM data, Purchase history etc.) to serve the visitor and increase loyalty, conversions, site presence and all the other possible goals our web site should meet. THAT’s the real beauty in my eyes – DMS is powerful, yet simple to deal with, since Sitecore has provided an awesome product with “everything” available out of the box – and it allows us, as well as our customers, to focus our efforts on using the tools – not building them (once again).

But what’s for Christmas?

As I stated in the beginning, Sitecore DMS is not perfect (yet) – and while the current product is great, there are a couple of things I would like to see implemented in the future to make DMS even stronger and simpler to work with. My biggest wish is the ability to map visitors to existing Visitor records even without matching GLOBAL_SESSION cookies. The way it works today, a GLOBAL_SESSION cookie corresponds to a Visitor record – and if no cookie is found on the visitor’s device, a new cookie AND a new visitor record are created. This is fine – for the anonymous user – but when the user logs in, it would be fantastic if DMS could help me map the current visit to an existing Visitor record if one exists for the user – but it doesn’t. The result is that while I am able to track the full history of the user (through Visitor records with matching externaluser values), the information is spread over multiple Visitor records and thereby harder to use. If Sitecore could support this, we would truly have a user concept in DMS – where all knowledge of the visitor is joined in one place – wouldn’t that be awesome? My second wish is that Sitecore’s rules engine would have more support for information accumulated across multiple visits and not just the current one. The rules engine certainly makes things easier when it comes to configuring the behavior of the web site, but unfortunately most of the conditions only deal with the current visit and not all the Visitor’s visits. So – I can check if a certain page has been visited and a form submitted, but only within the current visit – not if it has happened during a previous visit – and that makes it somewhat harder to configure Sitecore in a meaningful way. Be aware that it’s certainly not impossible to get around this – it’s not exactly rocket science to implement new conditions for the rules engine, use e.g. roles to keep track of cross-visit activities and act upon them or in other way accomplish what you need – it would just be so much easier to work with for everyone. Christmas is coming up – so please, please, please Santa Sitecore – will you give me these (I believe I’ve been good this year)