In this second blog of 4-blog series, we are going to look into how the Sitecore analytics works out of the box and what extension options are available to you. If you haven’t read the first blog, please read it here.

Commerce Connect Framework

The ‘Commerce Connect’ Framework contains the engagement artifacts in one of its service layers. It is one of the reasons that the Commerce System APIs are not directly called.

If a scenario or a feature is not supported by Commerce Engine OOTB, you can extend the commerce engine, SXA storefront, and customize/extend ‘Commerce Connect’.

Extending the Commerce Tracker

A static class ‘CommerceTracker’ is responsible for checking if xDB is enabled and then load the respective tracker provider. There are two trackers provided by Sitecore, namely –

1. PlatformTrackerProvider – used when xDB is enabled
2. CookieTrackerProvider – used when xDB is disabled. The interaction is tracked based on ‘SC_COMMERCE_GLOBAL_COOKIE’ and not persisted in the xDB

Both the above-mentioned trackers implement ‘ICommerceTracker’ interface. This provides the extension point for custom implementations. You can write a custom tracker provider by implementing this interface ‘ICommerceTracker’.

How the trackers are instantiated?

The trackers are instantiated based on the connect config and can be patched in Sitecore.Commerce.Config

<platformCommerceTracker type=”Sitecore.Commerce.Providers.PlatformTrackerProvider, Sitecore.Commerce.Connect.Core” singleInstance=”true”/>

 <cookieCommerceTracker type=”Sitecore.Commerce.Providers.CookieTrackerProvider, Sitecore.Commerce.Connect.Core” singleInstance=”true”/>

Please note – For this to work, you must not use xConnect Tracking in the storefront or your custom frontend.

How these events are triggered and captured into xDB?

As explained in the first blog – ‘Commerce Connect Abstract Service Layer’, carries the essential information between front-end and the Commerce system. This layer provides the functionality to track user behaviour using goals/events and move users through “Marketing Automation Plans” in the correct state. The default pipelines provided by Sitecore –

1. Execute the necessary processors/pipelines
2. Trigger marketing events or update the users in the automation plan.

The Base

The base configurations are provided in ‘Sitecore Commerce Connect’ which is the collection of configs in the format Sitecore.Commerce.<feature>.config.
You will see the pipelines/processors to execute the features and importantly, it contains the processors to trigger the marketing events or to execute the functions to manage the automation plan.

The Implementation

When you implement ‘Commerce Connect’ to connect to External Commerce System (ECS), you patch into the ‘Sitecore Commerce Connect’ configs highlighted in the last paragraph.

Commerce Connect, Commerce Engine Connect, blah blah…. I am confused

Let’s simplify, ‘Sitecore Commerce Engine Connect’ implements ‘Sitecore Commerce Connect’, which means ‘Engine Connect’ configs are patched into the ‘Commerce Connect’ so that specific platform feature is executed and ‘Commerce Connect’ triggers the corresponding marketing events. This approach allows Sitecore Marketing and other base features to work irrespective of the Commerce platform used.

Can you explain with an example?

Sure, let us take an example of the ‘create user’ feature and see how it is defined in ‘Sitecore Commerce Connect’

Create user pipeline consists of the following –

1. Validate Domain
2. Create a user in the external system
3. Create User in Sitecore
4. Create Contact in xDB
5. Trigger a Goal

All the above-mentioned steps, except for step 2, should be executed every time irrespective of the commerce system used. Let us see how the Create User pipeline looks like in ‘Sitecore Commerce Engine Connect’ Config –

1. It deletes the CreateUserInExternalSystem processor
2. It adds a CreateUser implementation specific to Sitecore Commerce into the ‘Commerce Connect’ pipeline

The new CreateUser will consist of –

1. Validate Domain (from ‘Commerce Connect’)
2. Create a user in the external system (From ‘Commerce Engine Connect’)
3. Create User in Sitecore (from ‘Commerce Connect’)
4. Create Contact in xDB (from ‘Commerce Connect’)
5. Trigger a Goal (from ‘Commerce Connect’)

To summarise, ‘Commerce Connect’ contains features and corresponding events to be triggered, and ‘Commerce Engine Connect’ patches commerce features implementation into ‘Commerce Connect’.

What about implementing a new feature?

You can have your configs to implement a new feature and patch it into the Connect Config.

‘Commerce Connect’ contains the configuration for ‘LoyaltyProgram’ and contains a pipeline ‘LoyaltyProgramJoined’. It triggers Goal in Sitecore whenever someone joins the loyalty program.

Sitecore Commerce does not have a loyalty program feature and hence no configuration is provided in the ‘Commerce Engine Connect’. If you implement this new feature as a plugin, I suggest that you create a loyalty config in the ‘Commerce Engine Connect’ and patch the implementation into ‘Commerce Connect’.

When this feature is executed, the pipeline in ‘Commerce Connect’ is called which in turn will call the custom type you have implemented and at the same time will trigger the marketing event provided in the ‘Commerce Connect’ configs.

This way, you will benefit from all the marketing features provided by Sitecore today and if in future Sitecore decides to add more marketing features or an Automation Plan around loyalty, your implementation will work seamlessly.

Pro-tip – DIY Audit – Check the number of plugins created for your implementation. If the number is not close to the custom functionalities you have, please find out the reasons for the same. It may be the features are not implemented using the plugins and may cause issues with maintainability and upgrades.

Read more about Sitecore Commerce marketing at the Sitecore Doc Site