Mastering advanced tracking with Kentico Xperience

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.

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:

1. Website for one of the top real-estate agencies in the UK operating on a franchising model.
2. More than 100 offices advertising their properties for sale and to rent.
3. Different types of properties - homes, flats, commercial, etc.
4. Geolocation search feature to find a property in chosen city, postcode area, etc.

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:

1. Property is for sale or to rent
2. Location of property
3. Price
4. Property type (home, flat, commercial, etc)
5. Status (available now or in the future, already sold/let, etc)

From the search results page we could gather very similar insights:

1. Buy or rent filter
2. Region filter, where the property is located
3. Price range
4. Property type
5. Status

Ideally, all this valuable information should be tracked in addition to a page visit activity.

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

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:

1. 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
2. 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
3. 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
4. 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
5. Lisa, the franchisee prospect. Is looking to invest into opening a new branch:
   • Visits franchising blog
   • Subscribes to franchising newsletter
   • Fills franchising contact form

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:

1. 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.
2. 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.

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:

1. Main taxonomy - property interest:
   • Selling
   • Letting
2. Type of activity performed:
   • Request valuation form submitted
   • Request property viewing form submitted
   • Property page visit
   • Property search
   • 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:

1. Select "visited selling property page" activity type
2. 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.

Although custom activity gives you only 4 fields to fill, there are ways to inject more valuable context information.

1. 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.
2. 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.