How it works

If you are familiar with the "XP" part of Sitecore Experience Platform, think about Uniform Optimize as decoupled tracking and personalization without Sitecore Experience Database (Xdb) and all of the other roles required to support personalized web experiences.

Backend-less and origin-less tracking & personalization

There is no origin-based session that is required to execute personalization:

• Personalization rule execution - With traditional Sitecore, the Sitecore CD instance is responsible for this. With Uniform, the personalization rules configured in Sitecore are converted into a format that can run on the CDN (often called the "edge").
• Context collection - Context is essential to personalization. It describes who the visitor is, where they come from, what they are doing, etc. With traditional Sitecore, context is collected on the Sitecore CD instance during the tracking process. With Uniform, tracking happens in the visitor's browser, which greatly improves performance and scalability without compromising on features.

What about persistent data collection?

Uniform for Sitecore does not provide a centralized visitor data collection database like Sitecore Xdb. Such databases create all sorts of privacy, security, scalability and performance challenges. But visitor analytics is impossible without some sort of centralized collection point.

Uniform lets you send data to whatever data collection points you like. Out-of-the-box, Uniform supports sending data to Google Analytics, Oracle DMP, and even Sitecore Xdb, if you want. This is possible thanks to a feature of the Uniform tracker called the dispatch process. Developers can hook into the dispatch process in order to send visitor data to any system with an endpoint that can be accessed from the visitor's browser.

Personalization approaches

Personalization with traditional Sitecore is tightly coupled with the page building & delivery process. Uniform decouples personalization from theis process. This section explains the differences and why the decoupled approach is faster, cheaper to operate, and trivial to scale.

Coupled

The following diagram is a simplified illustration of how Sitecore's tightly coupled, origin-based personalization approach works:

This approach appears to be simple, but at each step of the process, the Sitecore content delivery environment has a lot of work to do:

1. The visitor connects to the Sitecore instance - Fast performance requires a fast connection between the visitor and the Sitecore server. The physical distance between the visitor and the Sitecore server must also be minimized.

   CDNs are the solution to these challenges, but since Sitecore tracking and personalization require the Sitecore server handle every single visitor request, the CDN is not an option.

   The only option available to try to scale the Sitecore CD environment. Even if you have unlimited time and money and a team of the most experienced Sitecore engineers in the world, there is no guarantee that you will be able to squeeze the kind of performance out of Sitecore that today's business requirements demand.

2. Sitecore instantiates the visitor context - The session and tracking process happen on the Sitecore instance. This involves expensive (i.e. performance destroying) I/O operations like loading visitor history from Sitecore Xdb. These operations must be completed before any information can be returned to the visitor.

   In addition, these operations put a load on the Sitecore instance. This slows system performance and reduces the number of visitors the instance can handle, which increases the need for scaling.

3. Sitecore renders the page - The page rendering process involves even more I/O operations than resolving the visitor context.

4. Sitecore returns the page to the visitor - The server-side session management can often be the bottleneck in scaling. Sitecore's dynamic content delivery process that is highly reliant on in-memory caching. That cache must be primed in order to deliver the page in a reasonable amount of time.

Decoupled

Uniform moves the execution of personalization rules from the CD server to the CDN. Since the CDN can deliver content to visitors much faster than even the most highly tuned and scaled Sitecore Content Delivery architecture and can do it with virtually no configuration, you end up with the fastest possible personalized Sitecore site.

To understand how this works, consider the two things that happen when the CDN receives a request: the request is for a page that is not currently cached (called a cache miss), or the request is for a page that is currently cached (called a cache hit).

What happens during a cache miss?

When a cache miss happens, CDN must make a call to the Sitecore instance. This does slow things down, but since the personalization does not run on the Sitecore instance, Sitecore is able to handle the response faster than it would if it had to build a personalized response.

What happens during a cache hit?

This is where things get interesting because this time CDN has everything it needs to handle the request. It does not need to make a call to the Sitecore CD instance:

How does the process change when Uniform Deploy is used?

This is where things get exciting, because this eliminates the need for the Sitecore CD instance entirely.

Tracking approaches

Just like personalization, tracking can be decoupled from the Sitecore page delivery process. Every personalization needs visitor context. Visitor context tracking is handled completely client-side, and the data can be configured to be dispatched using an asynchronous call to the Sitecore CD instance. This way, Sitecore can continue to track visitor behavior without affecting site performance. If you don't really need to collect visitor behavior in Sitecore Xdb, you can use the Uniform Tracker to write visitor behavior data to any repository you like, including Google Analytics, a CDP, your own data warehouse, etc.