Adobe Analytics Introduction: Terms and Concepts
This is one of several post aiming to give an introduction into Adobe Analytics. They are intended as both tutorials and references for future use. While there already are a lot of good sources for this, some are quite dated and miss connections to recently released features and enhancements.
In this post, I will explain some general things that are helpful to know when starting with Adobe Analytics. We will go over different interfaces to analyze data, explain Dimensions, Metrics, and Events and name some common integrations.
Know what you are looking at: Dimensions
One of the most important building blocks of Adobe Analytics are Dimensions. With Dimensions, we capture descriptive values on our websites or in our apps. Many people call them variables when explaining the general concept. On a website we might record the name of a certain page in a dimension. This would allow us to report on the usage of the different pages we offer on our website. We could do the same thing in an App as well, giving names to the different app screens and showing their usage.
Adobe Analytics offers some dimensions out of the box. When we are using the standard SDKs for websites or apps, we will automatically capture things like the user’s Operating System, Browser, or App version. Some of those are recorded on the client, like browser settings or app versions, and some are generated on the Data Collection Servers by Adobe, like the user’s geo location.
There are also some useful but optional variables like the name of a Page or Screen. Adobe Analytics does not restrict us in any way if we choose not to use them, but there are some inherent advantages. With years of experience in building Analytics Tools, Adobe (and Omniture before that) has put a lot of consideration in how we benefit from using them.
While the built in dimensions would give us plenty of options to analyze our user’s behavior, we also have our very own dimensions on top of that. We will not go into detail about props and eVars here, but what is important is that we can setup and use a large set of our very own variables. This allows us to tailor our tool to our exact business needs.
As always in life, knowing about our options and using all of them will give the most value to us. There is no black and white when it comes to the question of whether we should build something ourselves or use what Adobe gives to us. Instead, we should try to use the offering as extensive as possible and augment it with anything we need to model our business initiatives.
Counting things: Events and Metrics
Now that we have a way to track dimensional values, we will quickly go over our options to count how often things happen. This is what Metrics help us with. They are numerical values that we can measure with Events or calculate with Calculated Metrics. Out of the box, Adobe Analytics offers a way to track how often a page or screen is viewed and how many links are clicked on those pages. Those Events are then used to calculate the Page View or Custom Link Instances Metrics.
Every other Event has to be sent to Analytics together with either a Page View or Custom Link Event. This applies to both built in Events and Custom Events we can define on our own. For common use cases like eCommerce Tracking, we have a set of Events we can use to track Add-to-Carts or Purchases. Additionally, Custom Events let us track every meaningful interactions with our digital experiences.
And there still is more! Adobe Analytics has some very helpful concepts to aid us in understanding our users better. For example, the Unique Visitors Metric shows, how many people interact with the offerings on our properties. We can use it in a trended view to understand our reach or in breakdowns with dimensions. Sessions are called Visits within Analytics and show us how often our users came back to our website. We don’t need any setup to use them, they just work! The same counts for the time people spent with us online or engagement metrics like the Bounce Rate.
Knowing how and when to use which Metric is crucial in deriving the right actions from the insights we get in our users behavior. Again, finding the right combination of pre-built and custom Events and Metrics is key to generating the most value out of our Analytics investment.
Getting data in: SDKs and Integrations
There are two fundamentally different ways of getting data into Adobe Analytics. The first and most intuitive approach is to measure our user’s interactions on our websites and apps ourselves using the SDKs offered and maintained by Adobe. But even if we don’t do that ourselves, we can use the Data Insertion APIs, Data Sources or other integrations to fill our Analytics instance with content.
Let’s quickly go over the first way of getting data into Adobe Analytics. There are SDKs offered for any major platform like Android or iOS, which are maintained and updated regularly by Adobe. With the recent developments regarding Adobe’s Experience Platform, those SDKs have also moved to a more integrated approach to leverage integrations between different Experience Cloud solutions. For websites we have Launch as tag manager to help us with deploying and managing our different Adobe products.
All of the Adobe SDKs are sending data to the data collection servers, but we can also do this on our own. We can assemble the calls to Analytics by hand or use the Data Insertion API. This is one thing I especially like about Analytics: If we want to, we can just look at the documentation and build everything ourselves.
When we want to import data from other systems or tools, we also have quite a lot of options. Besides the Insertion API, there are Data Sources for aggregated or transaction data. For large sets of data, we also have the new Bulk Data Insertion API. There are also some nice integrations for tools like Google Ads with Advertising Analytics.
Getting data out: Frontends and APIs
Now that we have data in Analytics, let’s look at our options to actually analyze it. Over the last years, there has been one predominant answer to what Adobe Analytics is and has to offer: Analysis Workspace. This frontend has revolutionized the way we interact with our data by offering us a flexible and interactive way to build reports, dashboards, and anything in between. Releases got very frequent in the recent time, so we constantly get more value and options for analysis. It is built using the 2.0 API, which offers nearly the same functionality as the frontend. With the Adobe Analytics dashboards App, we can also take custom built scorecards with us on the go.
Analysis Workspace was heavily inspired by it’s predecessor Ad Hoc Analysis, formerly named Discover. It offered a very similar analytics experience but required us to use a standalone Java application instead of just running in the browser. While it was superior to the old interfaces in terms of flexibility and freedom, it was not made for the average user and quite tough to learn and master.
While Ad Hoc Analysis was made for the expert analyst, Reports & Analytics was the mainstream frontend and is still around. The experience back then was far more rigid than today, with a set of possibilities to analyze data in the interface. Since processing power was more limited back then, data needed to be processed far more than today, materializing the possibilities for analytics at processing time. Today, there is very little reason to still use it.
Complementing Reports & Analytics, other tools were built on top of the same processed data, using what is called the 1.4 API. For example, Report Builder offers a way to extract data directly to Excel and build sophisticated, automated workbooks. It is using the same data model, so is quite limited in terms of what we can do. Unfortunately, even the newer Power BI connector is built with that API and even more limited and slow.
Besides the Reporting APIs mentioned above, there also is the option to get all your data in Data Feeds. This allows us to build our very own Analytics tool if we wanted to. For more complex use cases, Adobe also offers Data Workbench to process Analytics data together with other data sources like Callcenter data on our own.
The most complete Analytics solution today
Looking at everything written above, we are describing the most advanced and complete tool for digital analytics offered today. Not only do we have a lot of SDKs that are maintained for us, but we also have a constantly evolving frontend. The year 2020 has so far been an excellent year for Analytics customers with more frequent releases and major upgrades to our workflows and analysis options.
I hope this article has been helpful to get an overview of Adobe Analytics. With more posts like this in the future, I will go into detail about certain concepts and features to help beginners and offer some reference. Let me know if there is anything in particular you would like to hear about!
Frequently asked questions
Not exactly. There are Metrics like Visits or Unique Visitors, which we don’t need to trigger by ourselves. On the other hand, not every Event needs to be visible in the frontend, but might only be visible when building Calculated Metrics.
Easy answer: Analysis Workspace, with a huge margin. It is where most of the features are today and where all of the development seems to happen. With the Adobe Analytics dashboards app, most KPIs can be taken on the road as well.
Yes, but not as many as in the past. Both can be used together in Analysis Workspace. With the Attribution feature, persistence is available for props, and the Flow visualization brings something similar to Pathing to eVars.
Sadly, some still are. Report Builder is the prime example, which is still using the 1.4 API and the same data as Reports & Analytics. The same applies to the Power BI connector, which is equally slow and limited compared to the current 2.0 API (which is behind Analysis Workspace as well).
German Analyst and Data Scientist working in and writing about (Web) Analytics and Online Marketing Tech.