Reporting Metrics, Part 2: When Analytics For Target (A4T) Reporting Does Not Match Expectations

[#1]

by Christopher Davis and Kevin Scally

This is Part 2 of our series on Target Activity Reporting FAQs & Troubleshooting which focuses specifically on using Analytics/A4T as the reporting source. Check out Part 1 of this Series which covers Using Target as the Reporting Source, and Part 3 of this Series which covers Using Third-Party Tools as the Reporting Source.

Unstitched Hits  

When using A4T in an at.js + AppMeasurement.js (non-Web SDK) implementation; it is important to understand how data is collected for A4T. 

Target generates a Supplemental Data ID (SDID) that is sent as part of the Target request. This ID is used to link data from the Target call to the page's Analytics call (what activities were returned, what experience the visitor is in for each activity, etc.). Second, note that Target fires at the "top" of the page (as content begins to load), while Analytics is fired at the page bottom (after the page's content has been delivered). Due to this difference in timing, it is possible for instances where a Target call is made but the user (either by their own volition or the server's) is navigated away from that page before an Analytics call can be made. This results in what is known as an "unstitched hit", as the Target information is never relayed to Analytics. Redirect offers are known to occasionally cause this behavior if not using recommended best practices when employing redirect offers. 

In reporting, this manifests by Analytics reporting that the Target activity does not appear to be behaving as it was authored to (e.g., a 50/50 split activity might show 60/40 or even more extreme discrepancy). In situations like this, Target is indeed delivering experiences as instructed, however, Analytics is not receiving the full picture in its reporting data. If you notice anomalous figures in your A4T data, please validate that SDIDs are being properly generated by Target and then are subsequently picked up by Analytics. You can also contact Client Care if you would like to get information about the overall level of unstitched hits coming from your account.  

Analytics Logging Methods  

A4T can use one of two types of logging for stitching Target & Analytics hits: client-side logging & server-side logging. It's important to understand the differences in these methods, as using them improperly can lead to inaccuracies in reporting data. With server-side logging, which is the default behavior of A4T, the previously mentioned SDID is used to automatically link Analytics hits to Target hits. This is the default method and is generally more reliable than client-side logging. However, server-side logging isn't possible for some custom implementations. If your implementation uses client-side logging, the response from Target will contain an Analytics payload rather than Target generating an SDID as part of the request. In order for this data to be sent to Analytics, that payload must be forwarded manually via the Data Insertion API. Failure to do so correctly will result in reporting inaccuracies, see this documentation for a deeper dive into the subject. 

Classification Issues  

When using A4T, it is normal for it to take as long as 24 hours for reporting data to be translated from raw A4T data contained within the Analytics for Target dimension into the classified, user-friendly activity and experience names specified within the Target Interface. However, there can arise issues with the classification processing correctly. You can tell this is the case if you're seeing the Activity ID represented in the Analytics for Target dimension in Analytics Workspace but never seeing the activity or experiences populate in the user-friendly dimensions. Thankfully, reporting data is still being captured, but a Customer Care ticket is required to correct the classification issue on the backend.

 

Example of raw A4T data, in the form of tnta values. These values are the contents of an Analytics payload from Target. The first value correlates to Activity IDs in Target, the other values represent information about Target Activities. 

Example of the user-friendly format that the raw A4T values are classified into by Analytics. Remember, if you’re seeing an Activity ID in the Analytics for Target dimension, but never seeing that activity represented in the Target Activities & Target Activity > Experience dimensions and it’s been 24 hours since the activity launched, please contact Customer Care so they can manually reclassify that Activity’s A4T data. 

[#2]

Hi @chrismdavis, thanks for this post! One of the links in the article https://docs.mktossl.com/docs/target/using/integrate/a4t/a4timplementation.html?lang=en#step7 seem not to be accessible as it gives a security error. Any other way to access this document?

Thanks!

[#3]

Hey @ylevy1 - it looks like that piece of documentation has become unavailable since publishing this, sorry! This page also touches on using the Data Insertion API with A4T: https://experienceleague.adobe.com/en/docs/target-dev/developer/server-side/integration/a4t-reportin...