Kill Switch for Adobe Analytics using DTM

Question

Background

We currently have a flag in the datalayer that when it's set to false Adobe Analytics code will not run.

We do this for a multitude of reasons, including if we find any security concerns within the product or within the data that we are capturing. We set the flag to false and it no longer pulls in the Adobe Analytics script from our page.

Ideally, we are trying to mimic this exact functionality within DTM without having to approve and publish anything. We just want to be able to set something in the db and it's immediately available on all pages and we don't have to worry about the company software elevation policies.

That said, I was thinking that since data elements load on the page first, that I could grab the value from the data layer and then use an if statement and _satellite.getVar() in the s_code to determine whether or not the AppMeasurement got instantiated.

This was a dismal failure. Not only _satellite.getVar() is unavailable but even just setting the if(false) doesn't work. While I thought that only the s_code would instantiate the AppMeasurement, apparently just having the tool active in DTM means that there are direct calls to the AppMeasurement function.

Does anyone who is more familiar with this tool have any ideas that would allow us to determine whether Adobe Analytics runs based off of some sort of content change (we use the data layer but I'm open to all suggestions) on the page.

Thanks a lot for your time, Mike

Absent

Answer 1

DTM does not currently have any page load rule to not output any code, nor does it have any way to conditionally suppress the call.

AM itself though does have an s.abort variable that you can set to true and it will suppress the next s.t or s.tl call. But DTM doesn't have that var built into it's interface so you have to put it in the custom code section of the rule.

Update: To reiterate, s.abort doesn't wholesale suppress all AM calls; it suppresses the next call. After the call, AM resets s.abort to false. So this will work great for initial page load rule but for example if you have any code popping after page load (e.g. exit/download link tracking or some other custom code you may have), it will not suppress that.

Even if you are not doing custom after page tracking, one place to make sure you account for is in the Tool config where you can specify download tracking and internal/external link tracking which AM natively pops for if you have enabled (basically DTM's interface for linkInternalFilters, trackDownloadLinks, trackExternalLinks, linkDownloadFileTypes, and trackInlineStats). There's no easy way around that as far as keeping those things enabled via those settings, so I think the best thing to do for that is to just disable them and replicate it with event based rules, so that you can incorporate s.abort into there.

Another note to consider: s.abort suppresses the final request to Adobe but pretty much everything leading up to the actual request is executed. The most notable thing to consider is that if you have doPlugins enabled (DTM doesn't currently have this in the interface but there's nothing stopping you from enabling it and defining it yourself in custom code), it will get executed. This may have an impact on any logic you have in there, particularly stuff that does cookie reading/writing.

For example, let's say you have an "engaged visitor" metric that is set to pop after a visitor has viewed 3 pages and you achieve this by using a cookie to store and increment a value and read the cookie and pop an event if it reaches 3, and this is all in your doPlugins function (or elsewhere in a page load rule), s.abort will not suppress any of that.

Hortense

@Absent I added another note – Hortense

Thanks for the additional information. We do have doPlugins in the custom code that we've written. That will be good to take into account. Right now we are doing a proof of concept and we need to see how closely we can mimic in DTM everything we are doing right now. – Absent