This is Part 2 in a multi-part series describing the new classifications rule builder in Adobe Analytics. In case you missed it, here is a link to Part 1.
A rule-based approach
In Part 1 of this series I described the need for a rule-based approach for managing classifications and told you that the new classifications rule builder is designed for situations where metadata is located within the string values being passed into Adobe Analytics. In this post I will discuss three example use cases: tracking codes, products, and internal search terms.
How rules apply to tracking codes
Tracking codes are used to measure the effectiveness of online marketing activities. They are used in banner ads, remarketing emails, affiliate ads and many other advertising efforts to track how many people clicked on an ad and subsequently completed some kind of “conversion activity.” Tracking codes often have a defined structure. This structure is determined by the advertiser but might look something like this:
This example tracking code is a delimited list with three sections where the first section represents a marketing channel, the second section represents a campaign name, and the third section represents a date. The delimiter is a colon (:) character. The format of actual tracking codes differs from advertiser to advertiser but many look like a delimited list. The traditional method can be used to classify these codes into channel, name, date, etc., but creating and uploading classifications files is cumbersome. Every possible tracking code has to be classified and uploaded into Analytics. With new tracking codes being created all the time, keeping classifications up-to-date can be a daunting task. This situation is begging for a rules-based approach. The classifications rule builder let’s you build rules such as:
If the tracking code starts with ‘em:’ then automatically set the Channel classification to ‘Email’.
How rules apply to the Products variable
Some companies use product names where metadata is embedded directly into the product string. As an example, the product code for a travel-related sight might look like this:
This made up product string is clearly a delimited list. In it is information that says the traveler bought a first class airline ticket from Salt Lake to San Jose and that the ticket was sold at a special price. Using the classifications rule builder this company could build rules such as:
If the product ends with ‘:S’ then automatically set the ‘Fare Type’ classification to ‘Special Fare’
How rules apply to internal search terms.
Many sites and applications contain a search box where end users can search for information. This is really useful for the end user but crazy hard for analysts to analyze effectively. Every search term is basically a random set of words and search term-related reports usually have a very long tail. It would be much more useful if you could group search terms into categories. For instance, I might want to classify one of the following search strings as ‘Branded search’ and the other as ‘Non-branded search’:
- Nike running shoes
- Cross trainers
Using the classifications rule builder you can create rules such as:
If the search term contains ‘Nike’ then automatically set the ‘Search type’ classification to ‘Branded search.’
The sky is the limit
I anticipate you will come up will all sorts of other cool and useful ways to leverage the classifications rule builder. I’d love to hear from you if you have a great idea you’d like to share. Feel free to describe it in the comments section below.
Coming up next…
In Part 3 of this series we will get into the meat of the matter. I will dive into the user interface and talk about rule sets and rules and how they work. See you then…