Kill Switch for Adobe Analytics using DTM

Question

Background

We currently have a flag in the datalayer, which, when set to false , will not execute Adobe Analytics code.

We do this for many reasons, including if we find any security issues in the product or in the data we collect. We set flag to false and it no longer extracts from the Adobe Analytics script from our page.

Ideally, we try to mimic this exact functionality in the DTM without the need to approve and publish anything. We just want to be able to install something in db, and it is immediately available on all pages, and we do not need to worry about policies to improve the company's software.

However, I thought that since the data items are first loaded onto the page so that I can grab the value from the data level, then use the if and _satellite.getVar() operator in s_code to determine if _satellite.getVar() not created.

It was a gloomy failure. Not only _satellite.getVar() not available, but even setting if(false) does not work. Although I thought that only s_code would create an instance of AppMeasurement , apparently just having an active tool in the DTM means that there are direct calls to the AppMeasurement function.

Anyone familiar with this tool has ideas that will allow us to determine if Adobe Analytics working based on any change in content (we use the data layer, but I'm open to all suggestions) on the page.

Thanks so much for your time, Mike

Answer 1

Currently, the DTM does not have a page load rule so as not to display any code, and has no way to conditionally suppress a call.

AM itself, although it has an s.abort variable that you can set to true , and it will suppress the next call to st or s.tl But the DTM does not have this interface built into it, so you must put it in the user code section of the rule.

Update: To repeat, s.abort does not refute all AM calls; he suppresses the next challenge . After the call, AM resets s.abort to false . Thus, this will work just fine for the initial page load rule, but, for example, if you have code that appears after the page loads (for example, tracking download / download links or some other custom code that you may have ), he will not suppress that.

Even if you do not perform customs after tracking the pages, there is one place to make sure that the account is in the tool configuration, where you can specify the tracking of loading and tracking of internal / external links that AM initially comes in if you turned on (basically DTM- interface for linkInternalFilters , trackDownloadLinks , trackExternalLinks , linkDownloadFileTypes and trackInlineStats ). There is no easy way to maintain these things with these settings, so I think the best thing to do is to just disable them and copy them using event-based rules so you can enable s.abort there

Another note to consider : s.abort suppresses the final request to Adobe, but pretty much everything that leads to the actual request is executed. The most noteworthy thing to keep in mind is that if you turned on doPlugins (the DTM does not currently have this in the interface, but there is nothing that prevents you from turning it on and defining it yourself in user code), it will be executed. This can affect any logic you have, especially what cookies are read / written.

For example, suppose you have a “busy visitor” metric that is set to pop after the visitor has viewed 3 pages, and you will achieve this by using a cookie to store and increase the value, and read the cookie and enter the event if it reaches 3, and that’s all in your doPlugins function (or elsewhere in the page load rule), s.abort will not suppress all of this.