Goodbye, Adobe Analytics “Multiples”!
Get to a consistent, manageable setup of your eVars, props, Success Events, and Classifications, including Version Control
Have you seen any “Multiples” lately? Do they make you nervous, too? Then you must be an Adobe Analytics Admin. This post explains how to set up your Report Suites in a maintainable way. We also show how to compare the values behind those “Multiples” more efficiently. The method shown also frees you from the fear of undocumented, unwanted changes to your eVars, props, Success Events, or Classifications — thanks to the built-in version control of Google Sheets!
It is long considered best practice to keep your eVars, props, Success Events as well as classifications identical across your Report Suites. This is the foundation for scalability of anything you do with Adobe Analytics:
- You can easily bulk-edit Report Suites (e.g. change eVar definitions in multiple Suites at once)
- You can use the same data collection setup across all sites, especially when using an Adobe Launch Extension to enforce a global tracking standard across sites and overcome Launch’s scalability issues
- You can apply the same Processing Rules to all Report Suites — because a Processing Rules setup with different rules for each Report Suite is a nightmare to maintain
- You can apply the same baseline of a standard set of curated components across multiple Virtual Report Suites (e.g. with the Adobe Analytics Component Manager for Google Sheets)
- Generally, a consistent setup with as few exceptions as possible is better for your nerves, saves time, prevents errors, and thus is ultimately good for data quality and usability
Exceptions? Use Report-Suite-specific slots
Standardized exceptions are sometimes needed, of course. But the keyword here is “standardized”, otherwise you end up with an absolute mess. For such exceptions, one client uses Report-Suite-specific slots which can differ from Suite to Suite. For example, eVar 175–200, prop 70–75 and Success Events 901–1000 are allowed to differ between Suites. An example could be a bank which has a separate career website. That career site has its own Report Suite and needs to track things like Job ID, Job Title, Applicant ID or a “Job Application Submitted” Success Event. Those things make no sense on any other sites of that bank. It would be a waste of variables if all these job-site-specific variables were present in all those other Report Suites.
So the job site, in its Report Suite, uses its Report-Suite-specific slots for its site-specific variables, while the banking site in Asia may use the same slots for something that only makes sense on that Asian banking site. Still, those should be exceptions. Each exception needs to be well-justified.
The dreaded “Multiple”
In a poor, non-standardized Adobe Analytics setup, you see “Multiple“ (values) almost everywhere. “Multiple” means a variable (e.g. eVar24) has not been given the same name, description, allocation, or other setting across the selected Report Suites: eVar118 may be called “Search Term” in Report Suite 1, but “User ID” in Report Suite 2–5.
It is cumbersome to reconcile “Multiples”. You need to click into each variable’s field (each name, description, allocation etc. of each eVar, Success Event and prop that shows “Multiple”) and then wait for a slow-loading popup to show you the differences for this particular field. Then again for the next field, and the next… until you fall asleep.
If the “multiple” is due to more than just a slightly inconsistent naming, but an actual semantic difference (e.g. prop5 is “Search Term” in Report Suite 1–3, but “User ID” in Report Suite 4–5), reconciling “Multiples” also requires changing the tracking implementation. What helps in these cases is finding out if this eVar, prop or Success Event is still used anywhere (something the Component Manager can do for you with a few clicks btw). If it isn’t, it may just be a legacy leftover, and you can force it to the standard right away.
In any case, curing the Adobe variant of “multiple sclerosis” is one of the most dreaded Admin tasks and can take years.
No change history: What is gone won’t come back
But even in a standardized and well-curated setup, stuff happens. Scatterbrained admins like me sometimes forget to select all Report Suites when adding or editing a Success Event. Or worse, they accidentally select all Report Suites even though they just wanted to edit a Report-Suite specific slot for that one site. Too late! The change cannot be reversed. You can at least garner the status after a change via the Account usage logs API, but then you still don’t know status before the change (which is what you need). Moreover, the format of these logs is nothing easily standardizable, and you are prone to run into the typical issues with the usage logs.
“Compare Report Suites” to the Rescue!
With these experiences and fears in mind and the beautiful Adobe Analytics API Wrapper by Julien Piccini to help, we enhanced the Datacroft Adobe Analytics Component Manager for Google Sheets by a new “Compare Report Suites” function. It works like this:
- Select the Report Suites to compare in the report_suites tab:
2. Run the Comparison via Report Suites -> Compare Report Suites:
3. The “compare_rs” tab will now assemble a comparison of all Report Suites’ eVars, props, Success Events, including List variables and Classifications. The column “Differences” will highlight the fields that are not identical in all Suites. Then you can simply scan through the columns to the right to see where the differences lie (to protect the client, the screenshot shows “Rep Suite 1–14” instead of the real Report Suite IDs you normally see in the column headers).
Or you can rejoice when you see no differences, like in this example:
No more clicking on each and every “Multiple” in the Admin interface just to see which Report Suites messed up. Finding inconsistencies has never been piece-of-cakier!
Hard to imagine? Check out this video for a live impression:
Transparency and Version Control for your Report Suites
Simply run this function regularly, e.g. once a week (you can ask your Datacroft contact to set up such a regular run for free), and you’ll always have the latest state as well as the history. Why the history? Well, simply because in the Google Sheets version history, you can always go back:
This makes it a lot easier to find out what that eVar’s life was like before that guy accidentally drove his “select-all-Report-Suites-and-then-change-it” monster truck over it.
Wait — there’s more!
Of course, this is just one new little feature of the Adobe Analytics Component Manager for Google Sheets, by Datacroft. The Component Manager’s main power comes by allowing bulk editing incl. deletion of metrics, segments, date ranges, workspaces, or the “auto-replacer” (“replace segment X by segment Y in all workspaces or calculated metric definitions”). It also tells you exactly which of your thousands of components are most popular or completely unused so you can then go on to delete them right away.
Want to learn more? Contact me for a free demo or trial.
