How I build my Adobe Analytics Implementations
Getting the most out of enterprise analytics systems is not easy. A lot can go wrong on the way from gathering business requirements to getting actionable insights. While most of my posts are focused on the analysis or reporting capabilities of Adobe Analytics, this post is focused on how I plan and build my implementations.
With an analytics system like Adobe Analytics, even small implementation choices can have large consequences later down the value chain. Errors and misjudgments can lead to skewed data that is affected in a non-obvious way. The implications range from more effort during analysis or higher maintenance to wrong conclusions and business decisions.
This post will walk you trough the number of steps I take when planing a new Adobe Analytics implementation. While I’ve been successful in delivering value by following those, there might be situations where a different approach is better suited to the task at hand. If you feel unsure if the way you do things is optimal, consider reaching out to an external expert to avoid costly mistakes that will hold back your analytics maturity. Enough introduction, let’s go!
Steps towards the perfect implementation
Over the years I’ve mixed insights and experiences from industry experts with my own views. Today I try to follow a sequence of steps whenever I’m starting to work on a new implementation or join a new project. Depending on the project phase and requirements, some of those steps might be skipped or have already happend. But even with existing implementations, it’s a good exercise to go back to previous steps and check if you are still in line with your business.
The earlier steps in this eight-step-list mostly consist of exploration and asking questions to the business while the later ones are more technical and closer to the day job of an analyst.
Step 1: Explore and understand your business and your customers
We start this list off with what might be your first weeks or months in a new company or a new team. On a surface level, you are trying to understand both your business and your customers as best as you can. Even if you’ve already worked on a project for a while it isn’t a bad idea to go back to the roots and try to connect with your business sponsors.
Ideally, you would start planing your implementation by asking some questions on the grand scale of your business. Start with the big topics: How is your business providing value today and what is the strategy for the next years? How does the market look like? Who are the competitors? What sets your company apart from them?
While answering those questions, you should also start thinking about your business’s existing or potential users or customers. Who are they? In which ways is your company providing value to them on an individual level? What does it take for a prospect to become a customer? How could you tell if a customer is satisfied by just observing them?
Next, start asking yourself which concrete business initiatives you can already see today and what will come in the next years. Which touchpoints are relevant today and what is their purpose? How do online and offline play together? Are they evolving or set in stone? How are they aligned with your overall strategy and your customers needs?
Step 2: Define Success, set and translate KPIs
The next step in creating your perfect implementation is to look at the definition of “success” for both your business as a whole and your individual business activities. Depending on your industry those can vary drastically on an operative level (like user reach for media companies or goods sold for retailers) but tend to get more similar on a larger scale, like overall growth or profitability.
It’s a long way from those high level company-wide KPIs down to what an analyst has to deal with on a daily basis, but doing this exercise is crucial in keeping your analytics aligned and relevant to the business. Many data driven businesses utilize a KPI tree to visualize and communicate success factors and challenges. Ideally, every business activity should contribute to one or more KPI on that large scale tree.
Your job as the digital analyst in charge is to map those KPIs to user behavior on the platforms you are going to track. This step is of utmost importance, and something that digital analytics as an industry has in common with social sciences. We have to remind ourselves that it is impossible for us to really know if a user is “engaged” or “frustrated”. The only thing we have is clues derived from their activity on our properties, like how many users purchased or came back within a week. All we can do is observe their behavior and draw conclusions when comparing it to our business KPIs. Sure, you would like your users to be happy, but you also want them to buy. So what would your business prefer, unhappy buyers or happy non-buyers? Whatever the outcome is, it has serious implications for what we need to prioritize in our tracking concept.
Once we have gathered our business goals, we need to translate them to measurable behavior on our digital properties. This activity should be done together with your business stakeholders, as they are the ones who are building the experience and are responsible for achieving the goals behind them. If your goal is to get users to buy your products, you need to come up with a way to measure that goal by translating user behavior to meaningful and measurable user interactions that are going to be tracked later on. If your goal is engagement or retention, those interactions will vary drastically from retail interactions.
A good approach for this is to start with a meaningful interaction, like the purchase, and work your way backwards from there to identify other meaningful steps in the user journey. Whatever helps your business understand and optimize that meaningful journey should be of importance.
Step 3: Cluster meaningful user interactions and define valuable metadata
Now we know what our business strategy and value propositions are, and how our digital activities map to that strategy. We also know how we want our users to behave on our digital properties and what the most meaningful interactions on those properties are. The next step is to cluster those interactions into classes and analyze which metadata about those interactions provide value us.
Let’s go trough an example. Imagine we work for a media company that is aiming to provide entertainment with video content. We earn money by selling ads that run before those videos. One of our goals will be to get users to watch our videos and some example KPIs will be the number of users who start a video and the number of videos watched.
One class of interaction will be everything that is related to interacting with our media assets. We might even have some information from our business strategy if there will be more types of assets in the future, like games or digital music. To get closer to our tracking concept, we now need to think about which metadata about those media interactions are helpful to our business.
For example, we will most definitely need to know which of our assets is viewed most. This means we have to make sure we not only know how many assets are viewed by how many people, but also have a way to analyze which assets contribute most to the overall performance by reporting on metadata like the name or brand of an asset. Again, your business folk are the perfect sparring partners to make sure you don’t overlook anything. Whatever provides potential for optimization should be considered.
Now is also a good time to come up with a strategy on how to acquire that metadata. In our example, we might have an asset management system that holds all of our valuable metadata. With a comfort like this, all we need to measure is the backend id of an asset and build an automated export to enrich that tracked id with the actual metadata.
At the end of this step, you should have clustered your user interactions you want to track and know which metadata will help us optimize our business in the future. For example, we might also have some functionality for our users to engage with the content on our site and need to know if they are used, and if and how they are contributing to retention. That way we already have two clusters of interactions, media interactions and content interactions, and some metadata attached to both.
Step 4: Define Analytics dimensions
After step 3 we have a good basis to start thinking about which Adobe Analytics dimensions we want to be using. The way we decide on which type of variable we use has changed quite a bit over the years. With only Adobe Analytics, we will still have to decide if and how we want to use Props and Evars, which is not as important if we are using products like Adobe’s Customer Journey Analytics.
Nowadays, almost everyone (including Adobe) advises against using Props, since Evars became more powerful over the years and Attribution IQ has changed the way we think about Allocation and Expiration. But if you know me, you know that I do still like Props quite a bit (I even dedicated a whole post to them) for the value they offer even today. Here are some of the decision points I consider when choosing the dimension type:
- Are real time reports important to you? If yes, you need a Prop, since Evars don’t support real time reports.
- Do you want your Analytics users to be able to easily analyze and segment on the first or last dimension value in a specific session? If yes, Props are great for that thanks to Pathing.
- If you want to report on the first thing a user has ever done, you might need an Evar for that, since Attribution will only go back to the start of the reporting window.
- Another good reason for an Evar is anything funky you want to do with Allocation and Expiration beyond the previous use case.
- Since Evars can be 2.5 times as long in size as Props, you need them for long values. This can be important if you are going to use classification rules to save on dimensions.
- With older interfaces, like Report Builder or Data Warehouse, dimensions can only be broken down by dimensions of the same type and Events can only be used with Evars. So if those interfaces are relevant to you, you should remember this.
With those points considered, you should know whether a Prop or an Evar is more appropriate for your use case. While almost everyone does it, it is considered an anti-pattern today to put the same value into more than one type of variable or even more than one variable of the same type. But I tend to disagree with that, since we can use Curation in Analysis Workspace to limit a Workspace to a specific use case and only include dimensions relevant to that context.
The important part here is to document your choices and results in your SDD/SDR together with your business goals and questions. This is also true for all the following steps that happen in Analytics.
Step 5: Define Analytics Event strategy
Events are another important building block of your Analytics implementation, but there are some decisions we have to take before we can set them up. Going wrong here can have some serious implications on the usability of Analysis Workspace and how quick you can get results out of Analytics.
The first decision is if and how we want to use Calculated Metrics. Together with your dimension strategy, this decision will influence how you are going to use frontends like Analysis Workspace and how much maintenance there will be in the future. Let’s go trough an example to show what I mean.
Coming back to our media example from before, there are a few ways we can translate it to dimensions, events, and/or calculated metrics. For example, we could set up a dimension named “media interaction name” and set it to “start” when a video is started. Together with a “media interactions” event, we could then create a Calculated Metric “Media Starts”, filtering our media interactions event by “media interaction name equals start”. The advantage with this approach is that it is quite future proof if there should ever be more than videos, since that metric would work regardless of the type of asset.
Another solution would be to create a “real” event for both “Media Starts” and “Video Starts” and set them via Launch or Processing Rules on the same conditions described before. There is no real shortage on Events since we have 1000 of those available, but I personally feel the first approach is a bit more up to date since it makes good use of Calculated Metrics.
In addition to the number of Events we have to use with either approach, relying on Calculated Metrics has one major advantage and disadvantage over using normal events. The advantage is that using Calculated Metrics allows us to redefine the numbers that make up our reports on the fly and after the fact. This allows for corrections and adaptions even after the data was collected. On the negative side, segmenting on Events is much easier with normal events, since Calculated Metrics are still not supported in segments and require a more creative approach to segmentation. That point is also valid for some Visualizations in Analysis Workspace, like the Histogram, which only work with normal events.
Step 6: Define event firing strategy
Now that we have understood our business and built our Analytics backend, we need to decide on how we will actually get our data into Analytics. To make full use of Adobe Analytics, we need to consider some points in regards to how we want to fire events and send data to data collection.
To do this, we need to decide which interactions should be tracked in which way. With Adobe Analytics we have two choices for sending data, using either Page Tracking or Link Tracking. Deciding on which events should fire when is crucial to your implementation since they affect your data and builtin metrics.
For example, the OOTB “Bounces” metric relies on there being only a single HIT in a visit. If you track the popup of one of those pesky newsletter subscription boxes, almost every visitor will have more than one hit in their visit, causing your bounce rate to be very low. The same goes for the OOTB “Single Page Visits” metric, which shows how many people visit only a single page in their session. If your newsletter box is tracked as a separate page, you will have almost no Bounces or Single Page Visits.
So what we need to do is define what a page is for us. This is rather intuitive for classical websites, but has become more complex with the rise of Single Page Applications and mobile apps. Under normal circumstances, I try to separate pages and the interactions on a page both for websites and apps, which can be tricky, but really is necessary to make best use of some builtin Analytics functionality.
Another thing to consider is whether you want to use onclick events for certain interactions. One good example for this is tracking interactions with a menu on a page. There are at least two ways to track this: We could either fire a Link Tracking event once someone clicks on a menu or include that information with the next Page Tracking call. I prefer the latter whenever I can, since I like to be mindful not to send events for everything a user can do on a page, especially when there will be another event right after the first one. In this example I would set the clicked menu item on the next Page Tracking call, since clicking on a menu will always lead to a new page being loaded and a Page Tracking call to be fired, so we don’t even need the onclick event.
Step 7: Define responsibility for events
Now that we know when we want to fire our events, it’s time to start talking to your developers on who should be responsible for firing events. Again, there are multiple ways we can tackle this.
With modern Tag Management Systems, analytics teams can be almost independent from the devs team for a lot of use cases. If we want to track clicks on a certain page element, we can just go into Launch and create a rule for this on our own. But I never do it like this, for a very simple reason: Since our devs and the content team will continue to work on that site, things like CSS classes or ids might change without notice, completely messing up our implementation! Even worse, we might notice weeks later that our data has been wrong for a long time.
To avoid this, I talk to the devs and delegate that responsibility to them. Instead of creating my own conditions, I ask them to send a Java Script event for the interaction I want to track and include the necessary metadata. This approach allows them to keep this requirement in mind with future changes to the site or even create some automated test cases during development. And if something breaks, you can work with them to avoid future problems by building a solid process.
I have been quite successful with the second approach, which is why I prefer it by a huge margin. It also follows the pattern “loose coupling, high cohesion” from Computer Science, which is a method for keeping interdependent systems maintainable and reliable, because it separates the website logic from the tracking logic as much as possible.
Step 8: Decide where to fill your dimensions
Last step! Now that we know what to track when and how, we need to decide how we want to get our event data into Analytics dimensions. This can also be done in at least two ways, so let’s look at both.
Depending on the type of property you are tracking, there are different recommended approaches to tracking. For websites, Adobe recommends using Launch to fill your Props and Evars. It is very convenient to follow that recommendation as long as there are not too many conditions on how to fill those variables. But once there are conditions like “only set the onsite searches event on the result page”, things are getting more complex quickly.
For mobile Apps, Adobe recommends to not fill your Props and Evars in the events itself but use Context Data and Processing Rules, which allows for conditions to be used on those events. Funny enough, there is no simple way yet to set Context Data variables in Launch for websites. This will likely change with the Experience Platform Edge SKDs, but is just inconsistent today.
This situation leads to some funky situations if you try to combine mobile and web data in a Global Report Suite. This requires you to use both Launch and Processing Rules for different environments on the same data, forcing you to be really mindful with how you set up those Processing Rules to only affect mobile data. This will get better with Customer Journey Analytics, but is a real pain today.
Done with collecting data, now show it!
Whew, you really made it through the whole list! At this point you should have some excellent and robust data in Adobe Analytics, ready to be analyzed. The next step is to go back to your business questions and use cases and build some Analysis Workspaces specific to those questions. By using Tags and Curation, you can give your users a safe environment for data democratization and allow them to explore data on their own!
And the best thing is that you should also have an excellent documentation at hand, mapping your implementation to your business strategy and goals. As always, let me know what your experiences are. Would you do something different? What are your best practices?
German Analyst and Data Scientist working in and writing about (Web) Analytics and Online Marketing Tech.