Analytics is not “just” firing pixels
The following story illustrates what happens when thinking about analytics code as “just” firing pixels to Google Analytics (or your favorite analytics vendor). Later we will analyze what the pains are with this mindset, and how to avoid and overcome them.
Product Manager: “Hi, Good morning. Quick question, can you please let me know how many times a product and a video were added to a catalog in the past month?”
Developer: “Hmmm… Let me check it on our analytics system.”
*After few minutes*
Developer: “20,431 times”.
Product Manager: “Just to make sure. This is for all platforms, right?”
Developer: “No, it’s only for Android. I don’t know how it’s reported on other platforms”.
Product Manager: “Can you please also check it for Web?”
Developer: “Sure. NP”.
*After few hours*
Developer: “Well… In Web we had 10,153 instances but I’ve noticed that the item type is not reported. I can only find out how many times it happened in general. Regarding IOS, I think it is called: ‘Save Video’ and ‘Save Product’. Assuming this is indeed this action, then it happened 670 times in this platform. Regarding the others, I’m not sure it was developed yet…”
This is how the Product Manager looks like right now…
What went wrong here?
More than one way to report the same action. In order to get insights on how many times a product was added to catalog, you need to understand how it is being reported on all platforms/flows (this feature might have different instances in the same platform). It starts to get messy as you will find yourself adding more and more conditions in your report in order to count the exact same business action. Even worse, it might even yield wrong business insights.
Mixing the codebase with technical analytics concepts such as dimensionX or metricY. Following our story, for the sake of the example, one of the ways to report the action for Android would be:
ga(‘send’, ‘event’, ‘Catalogs’, ‘Add’, {
‘dimension1’: ‘Product’,
‘metric1’: 1 } // Metric1 stands for Add To Catalog
);And here is another way to report it for Web:
ga(‘send’, ‘event’, ‘Catalogs’, ‘Added To Catalog’ });Looking at this code, it means nothing to someone who reviews it. Dimensions & metrics shouldn’t be the developer’s concern. As a developer you have no knowledge what it is about without accessing Google Analytics back-office to see the settings.
ga(‘send’, ‘event’, ‘Catalogs’, ‘Added To Catalog’ });The developer was the one who defined the analytics. Both Web and Android developers defined how the analytics were reported. It is not the developer’s responsibility and it is not his expertise.
Changing definition is done at the “feature level”. If for some reason the business analyst decides to change the index of metric23 to metric24, then you will have to replace it manually on all instances at the same time (as opposed to changing it once in one place).
Meet Dynamo
To overcome having multiple reporting definitions, there is a need to consolidate the reporting definition into one place and force all of the developers to use this exact definition. In other words, keep the DRY principle for your analytics reporting code.
The main challenge we are facing is sharing this definition across different flows, different platforms and even different programming languages.
Dynamo (open source project) was built exactly to solve this case. The main concept of Dynamo is to have one analytics definition for all of the business actions in your organization and then it generates a business API for your analytics actions.
For example, here is a json file containing only one business action for add to catalog:
{
"eventDefinitions": {
"actionsList": [
"Add To Catalog"
]
},
"definitions": {
"addToCatalog": {
"parameters": {
"entityType": "string"
},
"dimensions": {
"eventAction": "Add To Catalog",
"entityType": "{{entityType}}"
},
"metrics": [ "engagementMetric", "addToCatalogMetric" ],
"eventType": "event"
}
}
}Then Dynamo will generate the following API:
import tagManagerReporter from './tag-manager-reporter';
export var actions = {
"addToCatalog": "Add To Catalog"
};
var actionsValues = {
"Add To Catalog": 1
};
export function addToCatalog(entityType) {
const eventData = {};
eventData.eventAction = `Add To Catalog`;
eventData.entityType = `${entityType}`;
eventData.engagementMetric = `1`;
eventData.addToCatalogMetric = `1`;
tagManagerReporter.link(eventData);
}This API will then be called in the following way:
myGeneratedAnalytics.addToCatalog('Product');tagManagerReporter can be anything you chose it to be. It can be a tag manager wrapper such as Tealium, or it can be a shared wrapper between the business language to your dimensions and metrics in your analytics vendor.
At the moment Dynamo supports only JSON to JavaScript, but it is a living project and will in the future support other languages, such as C#. Dynamo is an Open Source project and we’ll happily accept contributions for different implementations.
Summary
Having only one way to report and only one way to measure is one of the biggest challenges we as developers have when using analytics for the same action in more than one instance. Whether you chose to go with Dynamo or not, you should keep that in mind. And remember, analytics is not “just” firing pixels.
Want to explore Dynamo?
