This is Part 2 in a multi-part series describ­ing the new clas­si­fi­ca­tions rule builder in Adobe Ana­lyt­ics. 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 man­ag­ing clas­si­fi­ca­tions and told you that the new clas­si­fi­ca­tions rule builder is designed for sit­u­a­tions where meta­data is located within the string val­ues being passed into Adobe Ana­lyt­ics. In this post I will dis­cuss three exam­ple use cases: track­ing codes, prod­ucts, and inter­nal search terms.

How rules apply to track­ing codes

Track­ing codes are used to mea­sure the effec­tive­ness of online mar­ket­ing activ­i­ties. They are used in ban­ner ads, remar­ket­ing emails, affil­i­ate ads and many other adver­tis­ing efforts to track how many peo­ple clicked on an ad and sub­se­quently com­pleted some kind of “con­ver­sion activ­ity.” Track­ing codes often have a defined struc­ture. This struc­ture is deter­mined by the adver­tiser but might look some­thing like this:


This exam­ple track­ing code is a delim­ited list with three sec­tions where the first sec­tion rep­re­sents a mar­ket­ing chan­nel, the sec­ond sec­tion rep­re­sents a cam­paign name, and the third sec­tion rep­re­sents a date. The delim­iter is a colon (:) char­ac­ter. The for­mat of actual track­ing codes dif­fers from adver­tiser to adver­tiser but many look like a delim­ited list. The tra­di­tional method can be used to clas­sify these codes into chan­nel, name, date, etc., but cre­at­ing and upload­ing clas­si­fi­ca­tions files is cum­ber­some. Every pos­si­ble track­ing code has to be clas­si­fied and uploaded into Ana­lyt­ics. With new track­ing codes being cre­ated all the time, keep­ing clas­si­fi­ca­tions up-to-date can be a daunt­ing task. This sit­u­a­tion is beg­ging for a rules-based approach. The clas­si­fi­ca­tions rule builder let’s you build rules such as:

If the track­ing code starts with ‘em:’ then auto­mat­i­cally set the Chan­nel clas­si­fi­ca­tion to ‘Email’.

How rules apply to the Prod­ucts variable

Some com­pa­nies use prod­uct names where meta­data is embed­ded directly into the prod­uct string. As an exam­ple, the prod­uct code for a travel-related sight might look like this:


This made up prod­uct string is clearly a delim­ited list. In it is infor­ma­tion that says the trav­eler bought a first class air­line ticket from Salt Lake to San Jose and that the ticket was sold at a spe­cial price. Using the clas­si­fi­ca­tions rule builder this com­pany could build rules such as:

If the prod­uct ends with ‘:S’ then auto­mat­i­cally set the ‘Fare Type’ clas­si­fi­ca­tion to ‘Spe­cial Fare’

How rules apply to inter­nal search terms.

Many sites and appli­ca­tions con­tain a search box where end users can search for infor­ma­tion. This is really use­ful for the end user but crazy hard for ana­lysts to ana­lyze effec­tively. Every search term is basi­cally a ran­dom set of words and search term-related reports usu­ally have a very long tail. It would be much more use­ful if you could group search terms into cat­e­gories. For instance, I might want to clas­sify one of the fol­low­ing search strings as ‘Branded search’ and the other as ‘Non-branded search’:

  • Nike run­ning shoes
  • Cross train­ers

Using the clas­si­fi­ca­tions rule builder you can cre­ate rules such as:

If the search term con­tains ‘Nike’ then auto­mat­i­cally set the ‘Search type’ clas­si­fi­ca­tion to ‘Branded search.’

The sky is the limit

I antic­i­pate you will come up will all sorts of other cool and use­ful ways to lever­age the clas­si­fi­ca­tions 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 com­ments sec­tion below.

Com­ing up next…

In Part 3 of this series we will get into the meat of the mat­ter. I will dive into the user inter­face and talk about rule sets and rules and how they work. See you then…