Optimise Custom Dimension Usage In Adobe Analytics

Here is the second half of my sharing in the Adobe Experience Maker The Skill Exchange event about optimising custom dimension usage.

For multinational companies, it is common to have similar websites across multiple countries with similar features and slightly different data collection, such as lead generation forms from different countries collecting similar but different user information.

Market A Lead Form:

• Age Group
• Income Level
• Shopping Preference

Market B Lead Form:

• Age Group
• Material Status
• Shopping Preference

Market C Lead Form:

• Income Level
• Shopping Preference

Even for a single market company, there may be the same feature with different data collection requirements on different applications, such as filter functions on products, past orders, and shop addresses.

Product Filter:

• Product Category
• Price Range
• Brand

Past Order Filter:

• Delivery Status
• Year
• Delivery Address

Shop Address Filter:

• Region
• Service Center

The simplest and most direct implementation is having 1 evar/prop for each piece of information to be collected. For the above two examples, 4 custom dimensions for the lead generation form and 8 custom dimensions for the filter function.

The problem is there are only 75 prop and 200 evar in Adobe Analytics and it will be difficult to manage for MNCs with tens or over a hundred digital properties looking for a standardised Adobe Analytics configuration. Moreover, each prop/evar can store up to 255 characters and storing just one character like M or F for gender into one custom dimension is a waste.

Instead of having one custom dimension for each piece of information, it is better to store all information for the same feature into one single dimension in a name-value pair convention.

One custom dimension for lead generation form with data like:

age=30-40|marital=single|shopping=online

One custom dimension for filtering with data like:

year=2020|deliver=received

Be reminded that each custom dimension can store up to 255 characters including = and |, so the name should be shortened and the value could probably be encoded.

Storing multiple data into one single dimension can optimize the use of custom dimensions. However, users are not exceptionally happy with the combined and probably encoded data when they are building reports with the combined data especially when they want to analyze each and individual information, such as married prospect alone.

The classification can help to break down the combined data into individual values as classification which looks like a separated custom dimension in Adobe Analytics.

For the lead generation form custom dimension, it can have classification:

Then create rules in Classification Rule Builder to automatically break the combined data back to their form using regular expression and accessible like an individual dimension in Workspace.

The above classification rules extract value as in the custom dimension into classification. If the value in the custom dimension is encoded, such as state code like AL, AK, AZ, and the exact state name is desired in the classification, such as Alabama, Alaska, and Arizona. The regular expression cannot be used in the matching condition but using ‘contain’ with state=AL and similar then fill in the exact state name in the classification action instead of $1. It will be a long list of rules but able to produce more user-friendly data in reporting.