Mastering advanced tracking with Kentico Xperience
In the world of Digital Experience Platforms (DXPs), understanding and harnessing the power of data is key to unlocking
In the world of Digital experience Platforms (DXPs), understanding and harnessing the power of data is key to unlocking success. In this blog post series, we will take you on a journey through a real-life scenario of implementing advanced tracking and analytics using Kentico Xperience 13 DXP. Whether you are working on a project with Xperience by Kentico or Kentico Xperience 13, the activity tracking principles remain consistent, making this information relevant for both.
Very often, the process of building websites goes through the challenges of budget restrictions and pressing deadlines. As a result of multiple tough prioritization calls, tasks like personalized user experience, marketing automation, visitor segmentation, and advanced tracking are usually not making the MVP launch of the project.
Gotcha 0: Tracking Trumps All Marketing Features
Data is the modern-day gold, and without detailed tracking from the very beginning, you risk missing out on valuable insights. Only building a solid foundation of data collection ensures all your marketing efforts, like segmentation, automation, and personalization, can reach their full potential in the future.
Gotcha 1: Going Beyond Out-of-the-Box Tracking
While Kentico Xperience 13 and other DXPs offer default activity tracking, it's not enough to fully comprehend the business context of your website. Injecting context into the tracked activities becomes your responsibility to gain deeper insights into visitor interactions.
With the enabled default activity tracking Kentico Xperience tracks multiple activity types automatically, such as:
Page visits. In the activity log, you will have the URL of the visited page and the referer URL (the page the user visited just before, what will be included there is defined by referer policy). However, there is no information regarding the context of content on the visited page.
Form submissions. This activity provides a bit more information, including a link to a form submission data and the type of the form. But if there was a generic form used on many pages, the context of the page is not included here.
e-commerce events. Products added to the basket, purchases, basket abandonment. This is probably the most advanced area of standard tracking because it includes a lot of data about products. But not the page context where it was performed on the website.
There is a common pattern here – the context of the visited page is missing.
To explain this in more detail, let's have a look at a real-life scenario we implemented recently with Kentico Xperience 13:
Website for one of the top real-estate agencies in the UK operating on a franchising model.
More than 100 offices advertising their properties for sale and to rent.
Different types of properties – homes, flats, commercial, etc.
Geolocation search feature to find a property in chosen city, postcode area, etc.
Gotcha 2: Unveiling User Interests with Page Visits
Page visits offer more than just a measure of visitor traffic. Understanding which specific pages users engage with can provide valuable insights into their interests, in our case, such as property type, location, price range, and status. Augmenting page visits with this additional information enriches your tracking data, leading to more informed decisions.
In our example, landing on property details page reveals:
Property is for sale or to rent
Location of property
Property type (home, flat, commercial, etc)
Status (available now or in the future, already sold/let, etc)
From the search results page we could gather very similar insights:
Buy or rent filter
Region filter, where the property is located
Ideally, all this valuable information should be tracked in addition to a page visit activity.
Gotcha 3: Making Analytics Actionable
Collecting data is only the first step, but making it actionable is where the real value lies. To achieve effective marketing automation, the activity data must be captured within your DXP. However, if your primary focus is reporting on the data and then applying actions manually, platforms like Google Analytics may suffice.
Below are the examples of reports that business could be interested in our example. These reports can be achieved in either of systems – Kentico Xperience or Google Analytics:
How many users are looking to buy or rent properties
How price range adjusts over time
What number of bedrooms is the most popular on the market
What offices perform the best in terms of leads
However later it can evolve into something more sophisticated, improving the visitor's experience based on the analytics. Supporting these cases would be easier if the analytical data is stored in the DXP:
If the user searched property for sale in a particular region, then suggest properties nearby
If they have seen N number of properties to rent, personalize their homepage to showcase more rental properties
If they have searched properties within a specific price range, then prioritize similarly priced properties on listing pages
Gotcha 4: Plan Personas First
Now we have a list of additional data to be tracked. Shall we go ahead and implement it? Not precisely. Although the data makes perfect sense now, there are multiple ways we can achieve these tracking requirements.
Before diving into implementing additional tracking information, it's essential to consider your website personas. By tailoring the tracking to individual personas, such as purchasers, landlords, renters, and vendors from our example, you can capture relevant data that aligns with their unique behavior. This targeted approach enhances user experience and optimizes marketing efforts.
From our example the main personas and their typical journeys were:
Sally, the purchaser. Is looking to buy a new property. Typically they would:
Visits bying landing page
Performs a few searches for properties for sale, providing their region, price range, type and size of the property
Visits a number of property pages for sale
Submits arrange a viewing form for the most interesting properties
Adds those into favourites
Mike, the landlord. Is looking to let his property:
Submits request a valuation (to rent) form
Searches for already let properties in the past, to check how efficient estate agents are in the area they live
Visits letting landing page
John, the renter. Is looking to rent a property:
Performs a few searches for the properties to rent, providing their region, price range, type and size of the property
Visits a number of property pages to rent
Submits arrange a viewing form for the most interesting properties
Visits rentals landing page
James, the vendor. Is looking to sell a property, and then potentially buy or rent another:
Submits request a valuation (for sale) form
Searches for already sold properties in the past, to check how efficient estate agents are in the area they live
Visits selling landing pages
Downloads terms and fees documents
Lisa, the franchisee prospect. Is looking to invest into opening a new branch:
Visits franchising blog
Subscribes to franchising newsletter
Fills franchising contact form
Gotcha 5: Crafting the Ideal Data Structure
The list above is a starting point of custom activities we want to track and here is what can be customized when a new custom activity type is created in Kentico Xperience 13 (or Xperience by Kentico):
ActivityType – this is the main unique identifier of custom activity type
ActivityItemID – integer identifier of whatever “primary” object from DXP database you would like to relate to this activity: location or office is a good example
ActivityItemDetailID – yet another integer identifier to relate something “secondary”, e.g. the property itself
ActivityValue – free text field where we can put any additional information
ActivityComment – same as previous, another free text field
In a nutshell we have one string unique identifier, two integer ID fields, and two free text fields where we can store any relevant info regarding tracked activities. Next is to define how many custom activity types we need, and what additional information is written in the rest of the fields.
There are two extremes in modeling data for custom activity types:
Extremely specific: Creating a new type for every specific activity you are tracking. Following this principle, there will be “search for properties to sale, from A to B price, in London,” “visit of property details page, to rent, in Manchester” and so on. There will be many unique activity types in the system, and complimentary integer and string fields for each will not be utilized.
Extremely generic: Creating one generic custom type, like “estate agents custom activity,” and storing as much additional information as we can in the 4 fields available. For example, in ActivityItemID, store the ID of the office if relevant; in ActivityItemDetailID, store the ID of the property; in ActivityValue and ActivityComment fields, store all the additional information serialized as XML or JSON. This can include whether this activity is “sales” or “lettings,” price range, identifier of area search, sub-type of activity performed – search, page visit, download, etc.
Very often, if not always, these extreme approaches are not great, and we need to find some sweet spot in the middle.
Gotcha 6: Keeping Numbers Manageable
The rule of thumb here: keep the number of custom activity types manageable – between 10 and 25. Usually, you can park between these two numbers if you create a custom activity type for each combination of your main taxonomy comprising personas and a list of actions to be tracked.
In our estate agency example:
Main taxonomy – property interest:
Type of activity performed:
Request valuation form submitted
Request property viewing form submitted
Property page visit
Property saved to favourites
Property Search saved to favourites
As a result there will be 12 unique activity types, like: selling property page visit, letting property page visit, selling property search, letting property search, and so on.
One small but important detail worth noting here is that we could have avoided creating duplicates for both selling and letting in our example and stored selling or letting value in the details of the activity. However, this would have made the use of these activities inside other marketing features, like persona scoring rules or marketing automation, more complicated and less visual.
For example, when configuring persona scoring rules for a purchaser, we could either:
Select “visited selling property page” activity type
Or, select “visited property page”, and configure further condition “where property page is selling”
The second option is less attractive because:
Further conditional checks could affect the performance on high traffic websites.
It's less visual in the DXP admin. In persona scoring rules list, activity log, and other places, these extra conditions are not displayed, hence you have to expand the specific rule to notice the difference.
Gotcha 7: Attaching More Context
Although custom activity gives you only 4 fields to fill, there are ways to inject more valuable context information.
Storing data in an attached object. Here we can create a structured object like module custom class, record all necessary context information inside it, then while logging activity object just store integer ID referencing this custom class.
Storing data in structured text format. Alternative option would be to prepare serialized context information as XML (or JSON) and storing it in one of the two text fields available in the activity object.
Mastering advanced tracking and analytics is essential for gaining valuable insights into user behavior and optimizing marketing efforts. By going beyond out-of-the-box tracking, understanding user interests with page visits, making analytics actionable, planning personas, crafting an ideal data structure, and attaching as much context as needed, you can create a comprehensive and effective tracking strategy for your website. Stay tuned for more insights in the next blog post in this series!