Universal Tracker

Sitecore in on a journey from monolith to NET Core based Service Architecture by leaving the safety of the monolith but because of tight coupling we have to live with large instances, slow start up and all or nothing upgrades. This old approach is hard to scale, bug in one feature can affect the whole platform. It always slowed down the adoption of new technologies.  Now, Sitecore is going into direction where they creating  a new building blocks on the same Sitecore Host (hOS+). One of them is Universal Tracker. But what is it ?

Universal Tracker is a headless API for xDB collection. You asking your self isn’t that xConnect? It is not. xConnect only accepts immutable history and it designed for trusted service communication – Authentication only, no authorization. Universal Tracker is needed to not expose xConnect. I has been told that in the future, Sitecore will use Universal Tracker instead of Sitecore.Analytics.Tracker. The Universal Tracker will allow collection of interaction data from all channels, wherever they may be, including Sitecore websites (web tracker), other websites (JS tracker) and even mobile applications (mobile tracker).

Where xConnect is concerned with collecting completed interactions, the universal tracker is concerned with collecting live interactions as they happen, and submit them to xConnect when they’re done.

 

Requirements

  • OS:         Windows 10, Windows Server 2016
  • IIS        10
  • .Net        .Net 4.6.1 and later, [.Net Core 2.0 runtime ]
  • IIS .Net Core module
  • Database        SQL 2016R2, SQL 2017
  • Web Deploy 3.6

 

Architecture

Sitecore Universal Tracking consist of three parts:

  • Universal Tracking Collection – is .net core web API service responsible for collection interactions and events from different sources and store them temporarily in a database.
  • Universal Tracking Processing – is .net core web API service that can be deployed as a windows service. It contains logic for real-time processing of data, collected with UT Collection service, and sending it to XConnect.
  • Universal Tracking SQL – represent the concrete implementation of ITrackingInteractionCache and consist of database schema for MS SQL and Azure databases. This component was built as a plug-in for UT and has its own configuration.

UTArchitecture.png

Processing Pipelines

 

Universal Tracker Processing Pipelines

There are 3 pipelines:

  • Pre-Filter: You can use it to discard interactions , aggregate them, etc .
  • Enrichment: to decorate, add some external date, etc.
  • Post-Filter: final processing before interaction will be send to xConnect

Out of the box there is noting in pipelines.

 

Basic Deployment

UTBasic.png

Scaling

Sitecore Universal Tracking can be scaled in few different ways

Scale Collection

A lot of interaction, no or little processing

UT Scaled Collection.png

Scale Processing

Few interactions but  heavy processing in the pipelines.

UT Scaled Processing

Full Scaled/ Multiple Universal Tracker Deployments

The performance of database will be always a bottleneck of previous scenarios.

UT Full

Client Side

No Library for C#, no package for JS, the do have SDK for Xamarin.

You can use the Sitecore Mobile SDK for Universal Tracker to develop client applications for any of these supported platforms:

  • Windows
  • Windows Phone
  • Mac Os
  • Xamarin iOS
  • Xamarin Android
  • Azure Apps[IK1] 
  • IoT applications using Xamarin IoT extension

 

Get the most out of Sitecore’s data and analytics beyond out-of-the box dashboard with Sitecore 8.X and MongoDB BI Connector

While waiting for Sitecore 9.X and xConnect  we may want to get the most out of Sitecore MongoDB, to go beyond out-of-the-box dashboards and impress executives wit h deep insights. In some cases, Sitecore xDB Cloud may limit you what you can get from custom reports.

To help marketers ans BI specialists I used  two tools: MongoDB Connector for BI and Tableau . Continue reading

How to enable/disable visits tracking from content database.

I has been ask by business to find out a way to not track internal visits – easy stuff – we can add internal IP, public IP into <excludedIPAddresses> node of Sitecore.Analytics.ExcludeRobots.config file.

 

It worked for a while. Then I has been ask to disabled only on CM, but     …sometimes 😉 . Marketers, usually don’t want to see internal traffic to be tracked, but from time to time they would like to test some functionalities and  to track visits.  Deploying each time a config file is not an option.

I thought, it would be nice to add some logic into  the same pipeline (excludeRobots) where we filter already IP to exclude.

Continue reading