Adobe Analytics for Target (A4T) – A Look Under the Hood
As a consultant, I see a lot of different Adobe Target and Analytics implementations. They are all unique and special snowflakes, but in the past few years they all share something in common – A4T, short for Analytics for Target.
First, let me clear something up: A4T is not a separate product you need to license from Adobe. It’s quite simply an integration to stitch together Target data with Adobe Analytics data. No one likes data silos, so this sounds great doesn’t it? Well… it is, but A4T should come with a disclaimer about a mile long. A4T has quite a history, and while most bugs have been resolved, there are still plenty of quirks and features you should be aware of.
Now let’s assume everything is properly provisioned for A4T on Adobe’s end, your libraries are up-to-date, and you have a (mostly) defect-free implementation of both Target and Analytics. I’ll spare you from having to sift through all the help documentation and summarize some of the pros and cons of A4T:
Pros:
Cons:
Caveats (Seriously, read these):
Not quite as simple as it seems on the surface, is it? Let’s take it one step at a time to unpack what is actually going on with this Adobe Target and Analytics integration.
How the data stitching works
Let’s see how it works in a browser on a regular page load with a global mbox and an Analytics page view tag:
- The Experience Cloud ID Service loads, which basically handles the communication between Target and Analytics.
- The mbox request on the page includes a parameter called mboxMCSDID. This is what will be used for stitching the data with Analytics.
- The page view Analytics tag fires and includes a parameter called sdid. This value should match the value from mboxMCSDID from the Target request.
- The Target activity and experience data is stitched together with analytics tag data server-side.
- The raw data is classified into friendly names as shown in the Target UI for reporting purposes.
Simple enough. But what if there are multiple mboxes on the page? What if the analytics call happens before the Target call? The table below outlines various scenarios that can occur. This is not all inclusive, but it should help with illustrating where things can go awry.
| Scenario | Call | SDID | Notes | ||||||||
| Global mbox call, then analytics page view |
|
|
Target and Analytics are properly stitched. | ||||||||
| Global mbox call, then analytics, then regional mboxes |
|
|
Target and Analytics are properly stitched because there was not a page change to reset the SDID. | ||||||||
| Global mbox call, then analytics page view, then an additional analytics page view on the same page (E.g. scrolling to a specific section) |
|
|
Target and Analytics are properly stitched for the initial page view. The target data is not attached to any subsequent analytics tags, which is by design. | ||||||||
| Global mbox which triggers a redirect, then global mbox on destination page, then analytics tag on destination page |
|
|
The call to Target that initiates the redirect is stitched with the Analytics call on the destination page to ensure data is not lost. | ||||||||
| Global mbox which triggers a redirect, then analytics tag before redirect completes, then global mbox call and analytics call on destination page |
|
|
The call to Target that initiates the redirect is stitched with the Analytics call on the original page. The Target call and Analytics calls on the destination page are stitiched. No data is lost, but metrics for the original page will be inflated | ||||||||
| Global mbox which triggers a redirect, then analytics tag on destination page, then global mbox call on destination page |
|
|
The call to Target that initiates the redirect is stitched with the Analytics call on the destination page. The analytics tag has already fired and used the SDID from the redirect, so the Target call has nothing to stitch to and the data for that hit is lost. | ||||||||
| Analytics page view, then global mbox call |
|
|
The Target call is not stitched to an analytics call. No Target data captured. |
If you need to stop here and race off to another meeting and can only remember one thing from this post, it should be this: The SDID or Supplemental Data ID is the glue between Target and Analytics. Almost every data issue you may encounter can be traced back to the SDID values between the Target and Analytics calls… or misinterpreting the data.
OK. Great. That explains how the data is stitched together, but what does the raw data look like?
Dissecting the raw data
Let’s take a closer look at the two “post” columns in the raw Adobe Analytics data feed to understand what is going on.
These columns store a comma separated list information about each activity:
The format for both columns is the same: activityID:experienceID:targettype|event
If you are familiar with Adobe Analytics variables, you’ll notice that this format is very similar to a List Var. In fact, A4T is basically a List Var configured to full allocation, 90-day expiration, with a bit of special extra processing to interpret the four different events that can occur. Let’s break down an example value:
273607:1:0|0,273607:1:0|1,273607:1:0|2,270309:1:0|2,270309:1:0|32767
| Raw Data | Activity | Experience | Event Type | Action | Notes |
| 273607:1:0|0 | 273607 | 1 | A4T | Entrance | Present because this is the first hit when a visitor enters the activity/experience |
| 273607:1:0|1 | 273607 | 1 | A4T | Visit | Present because this is first hit of a visit to the activity/experience |
| 273607:1:0|2 | 273607 | 1 | A4T | Impression | Present because Target returned content for activity 273607, experience 1 |
| 270309:3:0|2 | 270309 | 3 | A4T | Impression | Present because Target returned content for activity 270309, experience 3 |
| 270309:3:0|32767 | 270309 | 3 | A4T | Conversion | Present because Target captured a conversion event for activity 270309, experience 3 |
Now, you can probably see how this contributes to some of the caveats I mentioned earlier:
Impressions and Conversions should generally not be used in Analytics Workspace.
I’m sure it’s more complicated than my over-simplification, but basically Workspace does not currently apply the special logic for allocating the Impression and Conversion metrics solely to the activity/experience in question. Instead those metrics are allocated similar to how an analytics success event would be allocated – all values get credit for the event.
For example, if a visitor qualifies for two different tests, a Conversion for Test #1 will also count as a Conversion for Test #2 even if the goals are different. This is why Adobe recommends using other analytics success events instead of the Conversions metric in Workspace. I consider this a “bug” instead of a “feature” and everyone that uses Workspace should be aware of it. Thankfully the Conversions and Impressions metrics are accurate when viewing the data in the Target UI and the Reports section of Analytics.
(I wish Adobe would put warnings on these metrics…)
You need to be diligent about test timeframes when looking at data in Analytics.
The Target data persists in a variable that behaves like a List Var with a 90-day expiration. Because of this expiration you may see traffic to activities after they have been disabled. Furthermore, if the visitor qualifies for another activity before the 90-day expiration, the values for the original activity will continue to be renewed. This is why it’s generally best to view the data for a particular activity only for the timeframe it was active.
