This post is the continuation to the three-part sequence on Tracking Codes and focused towards Tracking Code Nomenclature. Although business and technical experts understand the value of tracking code, most do not have a proper Tracking Code Nomenclature. Still today, several companies have fragmented/incoherent generation and maintenance of tracking codes. In addition to the proper implementation, appropriate generation and maintenance of tracking codes is important to achieve in-depth business insights, thereby results.
As mentioned in the previous post, proper Tracking Code Nomenclature will give more information about the Campaigns and allow us to classify metadata related to Campaigns (Including channels). So, what is the recommended Tracking Code Nomenclature? In my experience in Digital Analytics, I have two recommendations based on how we want to classify the campaign metadata.
Recommendation 01 : Comprehensive Nomenclature
Use this method if company is fine to expose the campaign related information in the URL. The nomenclature information is comprehensive, however it is simple to create, implement and classify without any struggles. We simply have to define the metadata fields and the delimiter value for this method. The mandatory metadata fields that I would suggest to include in the tracking code are below.
The following are the supplementary notes for consideration on the mandatory metadata fields.
- Metadata fields need not be in the above mentioned sequence and it is architect’s call.
- Network metadata values are often correlated with channels i.e. GDN and GSP can be used only for Display, Facebook and Instagram can be used only for Facebook, Own(Own Network) can be used only for Email and Mobile etc.
- Organic versus Paid differentiation is mandatory for better insights. Adding tracking code doesn’t mean that the campaigns are only paid.
- Metadata values in lower case and without spaces or symbols are always preferred i.e. Only alphanumeric.
- If a campaign channel has more than one identifier, add numbers at the end of the values to differentiate i.e. Email Campaign with 2 or 3 Call To Actions can be differentiated by adding numbers at the end of the identifier (Shown in the example below – Mail channel).
Considering the delimiter value as hyphen ‘-‘ (Recommended), below are few tracking code examples for the method.
In short, we just have to make sure that 255 char bytes have not been surpassed. We can now create a Classification Rule Builder with Regular Expression to segregate the values based on delimiter value, use the metadata field values to correlate/sub-relate each other for in-depth insights and analysis.
Thus, the strategy to identify, concur and classify Campaign metadata fields with values is simple for this recommendation. In addition, a proper inventory of tracking codes must be maintained such that tracking codes are not duplicated between campaigns or within campaign touch points. When business or marketing teams create and store tracking codes using Microsoft Excel, they should ensure that only a single Excel Version is available. If it is generated through an URL Builder like Google Analytics Campaign URL Builder, they should make sure that tracking codes are validated at the back end database to avoid duplicates during tracking codes creation.
Aside the mandatory metadata fields, we can force the stake holders to include metadata fields like Campaign Start Date, Campaign End Date, Banner Size, Stake Holder Name etc., during tracking code creation (For database storage) but not mandatory to include them in the tracking codes. Page information such as Language, Category, Product etc., are also not needed since tracking codes can be broken down by both default or custom variables.
Recommendation 02 : Compact Nomenclature
The significant difference between Recommendation 01 and 02 is the use of meta data values in abbreviations. This approach uses abbreviations so which users cannot quickly decipher campaign details instead of explicitly revealing the specifics in the URL i.e. Encoding or Hashing. The abbreviations can be either user defined or auto created i.e. Random or Rational. If it is user defined, analytics user can at least understand the tracking code without classification upload, else classification is must.
Lets see user defined and auto created abbreviations for one of the tracking codes from Recommendation 01.
Thus, the resultant tracking code for the methods will look like the below.
The following are the supplementary notes for consideration when comparing Recommendation 01.
- In User Defined method, slot the abbreviation of metadata value to fixed char bytes. If 2 char bytes are used for Channel Abbreviation, use it with consistence. Example, if you secure Channel char bytes to 2, values should be ‘se’, ‘di’, ‘ma’ etc., with only 2 char bytes and not ‘s’, ‘edm’, ‘mail’ etc., with any other char length.
- Keep campaign metadata abbreviation to minimum of 6 char bytes since campaigns are not limited as other metadata values.
- Delimiter to segregate the metadata for User Defined method is not required because the values are inconceivable even though we use the Classification Rule Builder.
- Creation and maintenance of tracking code inventory is mandatory since we would need Classification Importer to classify the tracking codes for our understanding and reporting.
As said during the Recommendation 01, we can force the stake holders to include metadata fields like Campaign Start Date, Campaign End Date, Stake Holder Name etc., during tracking code creation (For database storage) but not mandatory to include them within the tracking codes.
My Recommendation
If we think about maintaining the inventory, it is mandatory for both the recommendations and thus I would go with Recommendation 02, but User Defined. First, there is no need to expose the campaign details upfront to customers, however we can understand. Second, I would love to limit the char bytes not only for tracking codes but for the entire server call. The disadvantage is that we would need Classification Importer unlike Recommendation 01 (Uses Classification Rule Builder) to classify the metadata values, but that is fine, we can automate it.
The last post in this series would be on Tracking Code Implementation and would try to update in a week. Bye until then!
