Capturing Additional Data in a View Event in Sitecore CDP/Personalize

I’m currently working on a real-world use case for this blog, to fully demonstrate how to create a real decision model (and why you would do so with Sitecore Personalize), and in that journey, I have found that I need to collect more data about the pages that users visiting my website are viewing. The goal is to use this data, to make educated guesses about what kind of content they would like to see more of in the future. For example, if the user comes in and looks at CDP/Personalize content, there is a decent possibility they want to see more content in the future. For now, this is a simple use case, one which we will build upon in the future.

The Specific Use Case

The goal that I’m hoping to achieve is to track these blog posts, which are being driven from the CMS, in my case I use Sanity IO as the CMS, but in theory, this approach could be used by any CMS system including Sitecore XP or XM Cloud. Ideally, I want to track the page and additional schema information about that page to display full-stack and/or web experiences in Sitecore CDP/Personalize from those views. The specific use case I’m thinking about now relates to a recent change I made to my home page, which now includes categories of blog posts. I want to store in addition to a page view, additional metadata about the page. I could theoretically have it store category information or tags directly, which theoretically could save me an additional request to an external system in my decision model (but that’ll be a blog post for another time), but instead, I want to just store the sanity unique identifier, that way no matter what data I need at any point now or in the future, I can do that without any extra fuss. Storing the category or something arbitrary could work, but what if I add additional details (such as persona attributes to each of the articles, etc) to that item in the future and want to use it to make decisions? Well with storing only the ID and using a connection during the decision model process, I’ll be able to cover future use cases easily.

Also before I jump too deeply into this topic, I wanted to mention that this covers the existing CDP JS library and not the new Sitecore Cloud SDK with Engage modules that I recently covered in this video: https://www.youtube.com/watch?v=LdxNRo22Vf8 on Discover Sitecore. I will have more content coming up on that topic in the coming blogs.

Custom Event vs View Event

How should we store this additional information? This led to a dilemma because there were essentially two different ways to achieve the same outcome. But the custom event had some major drawbacks including an additional request to the stream APIs which would lead to even more code needing to be written to achieve the same thing. Plus we really wanted the View of the page to have those additional details. We could’ve potentially created a meta event or something to track the additional data, but then it’s not specifically tied to a view event. It was decided that the View event was the right decision.

The complexity with the View event is that you need a way to store the extra data, and turns out Sitecore documentation calls out two different ways to do this. There is a way to pass in Session Data with additional attributes, as well as passing extension data with attributes. However, with both methods, the documentation examples are a little unclear, made worse by the fact that if you have Sitecore CDP with the Guest Profile dashboard, and you are viewing the page events, it just tracks the page on the default view, without the additional information. Furthermore, it’s unclear which of these approaches is the better choice and why, so I had to make sense of it, and provide a response below about what I chose to do and why. Later in a future blog, I will walk through using these attributes in a decision model and potentially other use cases.

Let’s start by taking a closer look at both of these options, the code that is required, and how to view the data within CDP. Keep in mind the code below, isn’t the full story here because I’m avoiding the initialization of the CDP JavaScript library. For information about adding that, just refer to this reference in Sitecore documentation: https://doc.sitecore.com/cdp/en/developers/sitecore-customer-data-platform--data-model-2-0/javascript-tagging-examples-for-webpages.html#activating-the-boxever-javascript-library_body.

Using Session Data Attributes

This is quite simple, and really just requires passing in any additional attribution with a custom object with Session data:

1function sendCustomPageEvent(page: string, attributes: any) {
2    if (!window._boxever) return;
3    window._boxeverq.push(function () {
4        let customPageViewEvent = {
5            browser_id: window.Boxever.getID(),
6            pos: window._boxever_settings.pointOfSale,
7            channel: window._eventSettings.Channel,
8            language: window._eventSettings.Language,
9            currency: window._eventSettings.Currency,
10            sessionData: {
11                attributes
12            },
13            type: 'VIEW',
14            page: page
15        };
16
17        customPageViewEvent = window.Boxever.addUTMParams(customPageViewEvent);
18
19        window.Boxever.eventCreate(customPageViewEvent, function (data: any) {}, 'json');
20    });
21}

I created this as a function so that I could reuse it for various purposes later. My code base is also using TypeScript/React/Next.js so disregard the typing information in the function if you are using vanilla JavaScript.

Really the important part here is the sessionData: {} which allows you to now pass in arbitrary session data for what I assume is the current session. It’s a little unclear if this just tracks this to the session data or just the event. In our case, that is unclear and really we want to make sure these attributes are only to the current event in the current session (which leads to why I chose to go with the next option below). To view this data inside CDP, there is a really good way to do this. You’ll first want to go to your browser and type in Boxever.getID() as I’ve covered in other blogs in the past. Then navigate over to your CDP tenant, click on Guests under the Customer data section of the navigation, and type in bid: {id} from the command in the console above.

Additional Event Data

So the second option, which is the option I opted for with my own implementation, looks like the following:

1function sendCustomPageEvent(page: string, attributes: any) {
2    if (!window._boxever) return;
3    window._boxeverq.push(function () {
4        let customPageViewEvent = {
5            browser_id: window.Boxever.getID(),
6            pos: window._boxever_settings.pointOfSale,
7            channel: window._eventSettings.Channel,
8            language: window._eventSettings.Language,
9            currency: window._eventSettings.Currency,
10            ext: attributes,
11            type: 'VIEW',
12            page: page
13        };
14
15        customPageViewEvent = window.Boxever.addUTMParams(customPageViewEvent);
16
17        window.Boxever.eventCreate(customPageViewEvent, function (data: any) {}, 'json');
18    });
19}

As you can see, there really isn’t a huge difference in how this data is stored, the difference is that I think this method is meant for Event data vs the other option having the hard-to-comprehend sessionData attributes, where I don’t want multiple session data with the same attribute values.

The big difference with the above is just the new attribute of ext: attributes, added where you can send a custom object to that ext attribute.

To view this information, there are a couple of options, but I like seeing the data input via the Event Debugger:

Conclusion

To summarize, there are some great ways to store additional attributes in Sitecore CDP, and I opted for the path which allows me to track per event trigger. In my use case, I wanted to track additional metrics about the pages that the user is navigating through and we’ll discuss in my next blog how that information is useful in a decision model to determine the next best action for a user.