Using CNAME to boost data capture rates

[BarryLennon]

1 Bottom Line

I am considering implementing a "noscript"-style data capture method to boost the rate at which Adobe Analytics data is recorded on my organisation's websites.

The basic idea is If Adobe Launch fails to load (i.e. the _satellite object cannot be detected), formulate and trigger an Adobe Analytics server call with the most pertinent pieces of data (Page Name, URL, Transaction ID).

I'm interested in thoughts around this:

1. Has anyone implemented anything similar?
   1. If not, why not?
2. Does anyone see any flaws (technically-speaking)?
3. Does it smack of circumventing Customer wishes to avoid being “tracked”?

2 Background

2.1    Ad-blockers and Privacy Tools

Ad-blockers and related technologies present a significant challenge to the concept of accurate Digital Analytics data capture.  Although the primary focus of ad-blockers is almost always online advertising, Digital Analytics tracking being affected as a greater focus on privacy emerges, and blocking spreads to include, for example, popular Tag Management Solutions (TMS) such as Adobe Launch and Google Tag Manager (GTM).

2.2    Adobe Managed Certificate Program

The Adobe Managed Certificate Program (often informally referred to "CNAME") forms part of a solution to mitigate loss of data that arises from initiatives such as Intelligent Tracking Prevention (ITP) from Apple.  At a simplified level, ITP prevents a cookie being stored in the User's browser for more than 24 hours (even first-party cookies), in the case that the cookie is not set by a server; the converse is obviously that a cookie that is set in a first-party context by a first-party server (i.e. a server that has the same domain as the website) is not affected.

An organisation using CNAME from Adobe sets up a sub-domain (e.g., metrics.example.com) that is configured in DNS to resolve to the Adobe Analytics processing server's address (e.g., example.com.ssl.omtrdc.net). Two major benefits arise from this:

1. The Adobe Visitor ID (ECID) ends up being set by a server in a first-party context (and is therefore not automatically expired by technologies like Apple’s ITP)
2. The call to Adobe Analytics that contains the Digital Tracking data is less likely to be blocked by any ad-blocking or privacy-preserving technology in the User’s browser

3 Proposal

Given that my organisation will start using CNAME, I intend to require the website developers to wrap the call to _satellite.pageBottom in some JavaScript logic that - in the case that the _satellite object is not detected - will formulate an Adobe Analytics call (in the way that <noscript> tags used to in the old days!).

3.1    Details

The call is likely to include the following details, some of which are pulled directly from the dataLayer object in the page:

• Page Name
• URL (window.location attributes)
• Order ID
• A dimension that indicates that this is a “manually”-generated call
• Additional settings that my organisation routinely captures (such as setting the ECID into a prop)

I think it’s unlikely that I would try to reproduce our complicated code for parsing dataLayer.products into s.products; however, I would possibly consider extracting the product names on the Thank You page and setting s.events=purchase – this needs more consideration.

3.2    Benefits

The primary benefit I anticipate is Visitor, Visit, Page View, and Order (“Purchase”) volumes that are closer to the “truth”; I would like to know what traffic we are not considering when we make decisions about platforms on which to concentrate development and testing efforts.

Additionally, I feel that knowing the ratio of our Customers using aggressive ad-blocking technology or availing themselves of strong privacy measures could be useful in evaluating Digital Marketing efforts – are we spending all of our Marketing money on trying to sell to users who find us “organically” or already respond to our e-mail communications?

4 Considerations

4.1    Is it under-handed?

My personal stance is that Digital Analytics tracking (by which I mean, running Adobe Analytics or Google Analytics on your organisation’s website and capturing data about how a User experiences it) does not constitute privacy-invading behaviour:  there is a legitimate business interest in understanding how the User experiences a resource that is being offered with goals that include improving and optimising the experience.  In addition to this, I’m not convinced that many users of ad-block technology are concerned with anything beyond not being bothered by ads and “tracked around the Internet”.  I’m interested to know if anyone disagrees with what I’m proposing on the basis that it illegitimately goes against what the User has implicitly signalled by running an ad-blocker.

4.2    Is it the wrong approach?

If you agree that it is legitimate to seek to capture this data, you may propose server-side tracking to replace or supplement Adobe Analytics data – for example, a service such as SPLUNK can provide access to server logs that can be compared against Adobe Analytics data to show the difference (where the “difference” represents traffic that is not captured in Adobe Analytics).  My experience is that this is a substantially non-trivial exercise (that is potentially thwarted in some cases by CDN caching).

I’m interested in knowing whether anyone has already implemented what I’m considering here; whether the server-side approach is easier than I think; whether anyone is already doing something (else?) that achieves the primary benefit (improved data collection rates).

4.3    Any other suggestions?

Finally, is there anything else that you think I should be considering?