Introduction

Many of us are familiar with Adobe Analytics’ reporting interface, namely Analysis Workspace (previously ‘Reports and Analytics’, which incidentally will be sunset 31st Dec 2023). Adobe’s reporting frontend is feature rich and can at times feel multifarious. However, the reporting layer that end users interact with is just the visible part of an even more complicated and technically varied ‘stack’ (the phrase ‘tip of the iceberg’ would be appropriate here).

One aspect of this stack is data collection; in this article we discuss how Adobe accrues the information that eventually ends up within a report suite for use within Analysis Workspace reports. Specifically, we focus on tracking hits themselves.

For the technically curious, the article refers to tracking hits fired from older Adobe SDKs and considers the hits fired from the AppMeasurement.js library from a website. There exist newer Adobe implementation SDKs and other deployment methods (e.g. via a tag manager), which may involve different collection protocols.

Deployment

Deploying Adobe Analytics involves several basic steps. First, developers integrate some code onto each page of a website (or web app). Second, developers ensure certain parts of this code are invoked in a particular manner to ensure out-the-box tracking (e.g. pageview tracking) is working, alongside wiring up any custom tracking requirements (i.e. recording an article name within an eVar).

When a tracked scenario occurs and the associated code runs, that code needs to package up the information which has been collected on the website (such as page name, page URL, and so on) in a standard format, and transfer this information to Adobe for processing. Rather than define a new proprietary transport format, Adobe (and incidentally, any other tool which supports information transfer between parties/systems) leverage existing formats. Namely, once the information has been collected ready for transfer, the code deployed on-site generates an HTTP URL and instructs the users browser to issue a request to this URL. There is nothing unique or special about the URL generated; to our eyes, this looks like a normal link which with we are all familiar as internet users.

It is interesting to note that (as is the case with any analytics product) Adobe tracking hits are publicly visible to an individual user. This includes the data collection server to which a site is sending data. This means individuals with enough technical knowledge may be able to piece together aspects of a business’ Adobe Analytics implementation (such as whether or not they are using Adobe Tags (a.k.a Adobe Launch), which eVars are used for what sorts of purposes, report suite IDs – right down to specific implementation library versions.

For instance, reviewing this tracking hit taken from an org known to use Adobe Analytics (not affiliate with Lynchpin in any way):

At least for the tracking calls we observed:

  • They have not implemented AA via Adobe Launch
  • They are currently using version 2.22.0 of the AppMeasurement.js library
  • We can observe the name of one of their production report suites (redacted in the given figure)
  • They are not using custom context data variables, i.e. eVars, Props and events are used ‘directly’. Adobe ‘Processing Rules’ are a necessary part of an implementation which uses context data. Considering the figure above (for the given observed report suite), we may infer Processing Rules are not used extensively if at all (although they may use Marketing Channel Processing Rules for acquisition tracking)
  • They utilise Dynamic Variables extensively
  • There is no ‘mid’ field. The organisation in question may not be using the latest methods of Visitor identification, or may not be using it correctly
  • They set a cookie domain period of 2, which is likely redundant given the default behaviour of modern Adobe Analytics (see here)
  • Interestingly, they look to set the lifetime of the cookie which identifies Unique Visitors to 1800 seconds, contrasting with the default of two years

Further analysis of tracking hits may reveal further insight into this organisation’s implementation.

Conclusion

To conclude, Adobe Analytics leverages existing standards (HTTP URLs) to convey information tracked on a webpage or web app to Adobe’s own systems for processing and storage. All analytics products – such as Google Analytics – work in this manner (although the details of actual URLs will vary depending on the vendor). We direct the interested reader to the following technical references which outline the exact semantics defining a tracking hit for Google Analytics and Adobe Analytics:

To find out how Lynchpin can help

READ MORE ABOUT ADOBE ANALYTICS AND TARGET SUPPORTCONTACT US