Web Analytics with Adobe’s Customer Journey Analytics, Part 3: Data Structure in Experience Platform
This post is the third post of the eight-part-series Web Analytics with Adobe’s Customer Journey Analytics, showing how web sites can be analyzed better using Adobe’s next evolution of Adobe Analytics. In the previous post, we took a look at the different possible solution architectures we can use to bring data into Customer Journey Analytics and decided on the best one. In this post, we will take a look at our actual business questions and how we can structure our data most effectively.
From the last post we already know that we want to track data using only the new Adobe Web SDK going forward. To make that work, we need to create a schema in Experience Platform first, which defines the structure of the data that we want to capture. While some people (sometimes me included) see schema management as one of the more tedious tasks in Platform, I try to primarily see it as the best opportunity to ensure we realize the maximum potential of our data.
For this concrete project, we will create a schema that is perfectly equipped to measure website behavior on a simple content website. That site, as most sites do, will contain both pages as well as interactive content on those pages that need to be tracked. By following a few simple principles, I hope I can show how this example can easily be translated to other use cases as well.
Once thing we won’t cover for now are mobile apps. That is for two reasons: First, I just recently covered the technical part of measuring apps with the new AEP way of tracking (including schema and the AEP SDKs) in a dedicated post and second, the process and mindset are fundamentally the same.
Let’s start with the first part of every tracking concept, which is the exploration phase!
Exploring the page and defining the data structure
I create a little demo site based on this bootstrap template (because everyone loves bootstrap, right?). You can see that we have multiple pages, a top and footer navigation, as well as interactive content like slider galleries on those pages. Users can get to a page by using the menus or directly by using the browser navigation:
From an analytics perspective, we would like to know how people got to a certain page (directly or by using the menus) and how the technical performance in terms of loading times was. In terms of content, we would like to know which elements (like the gallery you can see above) were used and on which page, since different interactive content like galleries and CTAs might be reused and placed on more than one page.
With that information collected, we now need to head over to Experience Platform and create a new schema. While we will basically define all the data points we want ourselves, I went ahead and added the Web SDK Mixin Field Group to have some basic, technical information collected automatically:
First, since we are going to use Adobe Launch to collect data, I have extended the implementationDetails object to include details from the Adobe Launch environment for each event:
I always find that information super helpful when debugging, so I just want to have it and feel safe. Next, we need to model the structure of our page and possible interactions. In the first post, I was admiring the possibilities in Experience Platform to model data just as we want, so I’ve gone all-in with this extension of the web.webPageDetails path:
Let’s go through this, step by step.
Bringing detail to our web interactions
We will start with the very basic details about our page:
Since we can already track a lot of information about a page (like page name, server, site section, page views, etc.) in the web.webPageDetails section, we only have to add the things we need on top of that. For ease of use, I’ve added the previous page as a dimension (more on that in a later post). With the navigation_method, we are going to track how the user got to a certain page. And, in the performance path, I’ve added the total load time to analyze page performance. I could have added any additional performance metric as well, but this is sufficient for our little project. Next, let’s look at the on-page content object you see above at a more detailed level:
One thing is very important: This node is not only an object, but an array of objects. That is one of the most beautiful things in Experience Platform, since we can just define that there should be a list of elements that themselves can again hold lists of other, detailed properties. We are going to make good use of that awesome feature, more on that later.
What we can see on this high level is that we can just list the content pieces that are present on our page. Each item on our pages can have a name, a type, and a path. But on top of that, we also track metrics like impressions and interactions, as well as the position of the content on the page. By defining it like that, we can precisely analyze which content on our page got how many impressions and interactions relative to its position, or for all content in relation to its position. Think of questions like “how well do teasers perform if they are the first thing on a page?” I don’t know about you, but I got asked those questions a lot in my career!
But that’s not all we have in store in regards to content. Let’s extend the interactive elements object:
Isn’t that beautiful? What we are defining here goes like this: “On our websites we have pages. Those pages hold any number of content, that can be seen and interacted with. And each piece of content has any number of interactive elements, that have a relative position within the content piece as well as interactions like clicks, impressions, and swipes.” How amazing is that?! So again, we have an array of objects here, which defines if a piece of content has any interactive elements, what their type and name is, and what you can do with them. Also, we track their relative position to later answer questions like “How often do people even view the second element of a slider gallery?” without problems.
For our little project, that’s already everything we need. I hope I was able to spark your creativity on how deeply nested data in Experience Platform can be. If we would be tasked to track shopping basket interactions or media use cases, we could just as easily model the objects and interactions on our pages in the schema as demonstrated above. It takes a little time to get used to this new way of thinking, but it pays of big time!
Conclusion
I can’t overstate how much I love this new way of modeling websites, interactions, and how they play together. Finally we are able to respect the natural structure of those things in our data. We are not forced to flatten those interactions unnaturally like we did it for years in earlier analytics systems! And since that hierarchy is also then reflected in Customer Journey Analytics, we will be able to do some great things there later on as well.
In the next part, we are going to take a look at the actual implementation in Adobe Launch and how we can track all of that beautiful data. Don’t miss that next post!
German Analyst and Data Scientist working in and writing about (Web) Analytics and Online Marketing Tech.