Aborting all analytics server call

[Herder]

Hello Analytics Experts,
I hope everyone is doing well.

I have a scenario question, is there a way to abort all server calls when a certain condition doesn't meet? I know that Adobe has s.abort(), but this option will only work in certain conditions.

I am exploring the possibility that if a user opt-out, all server calls will be aborted. I know that we have some extensions like ECID, but I am trying to avoid using any of the extensions.

Question:
Is there a way to create a condition in Launch that when the user opt-out, all server calls will be aborted, and when I opt-in, then, that is the time when the beacons start to fire again?

I don't know if there is a way to inject a Global Privacy Setting like "navigator.globalPrivacyControl" or "Sec-GPC:1", but seems like this is browser-specific only. Hoping that there is a way to implement it from the Client side (adobe).

I hope this question makes any sense.

Thank you in advance.

[bjoern__koth]

Maybe a combination of s.registerPreTrackCallback and s.abort if a certain condition does not apply?

https://experienceleague.adobe.com/en/docs/analytics/implementation/vars/functions/registerpretrackc...

or in general, this seems to be the standard case for the Visitor ID service and/or Web SDK consent settings?

else, can you be more specific about your setup?

[Jennifer_Dungan]

You can create a condition on your rules that won't even let the rule run if the user hasn't opted in.  While you do have to add that to all your rules, this would be more efficient on the site performance since you wouldn't even run the code if the user isn't opted in.

[bjoern__koth]

But also keep in mind that the consent functionality in Visitor ID service and WebSDK have an internal queueing system that is preserving previously made calls which did not go through (on that same page) and releases them should the user give consent later.

that way you will not lose anything.

[Herder]

Thanks for the insights, @bjoern__koth and @Jennifer_Dungan.

I do have 1 follow-up question, does s.abort also prevent the target call or Google floodlight?

Since our rules contain a floodlight tag, I am under the impression that even if we prevent the beacons from firing, the 3rd party tag will still continue to trigger.

Have you encountered any scenarios that could also prevent the 3rd party call from firing when certain conditions are met? if yes, would you mind sharing the solutions you did?

Thanks in advance

[Jennifer_Dungan]

Hi @Herder,

the s.abort only affects Adobe Analytics (since it affects only the s object which is used exclusively by Analytics).

This is another reason why adding conditions to your rules is the better option. Conditions stop the entire rule from triggering.

Let's say your rule looks like this:

(You have a trigger: Dom Ready; and 3 actions: Set Variables, Sent Beacon and your Floodlight code)

Right now, all of these will run when the DOM is ready.

But, let's add a condition:

Now, when the DOM is ready, it must first pass my condition that analytics is opted in...

In my example, I am using the opt-in configuration I set up in my ECID extension:

Here, I explicitly set Analytics Opt-in to "false" as my previous value, but in a real scenario I would be using data elements to extract the user's chosen opt-in status based on whatever the site is using to control your opt-ins.

[bjoern__koth]

Fully agree with @Jennifer_Dungan ,

that's what a tag management system is all about. Controlling your tags through rule conditions to not fire. If you are only using Adobe products, I would always recommend using the Visitor ID service or WebSDK to control these. In that case you don't need to have conditions in your rules.

Unfortunately, Launch does not have a built-in tracking queue that you can release as soon as consent is given. In other words, you may also have to manually retrigger e.g. a page view event should the page load without user consent and the user grants it a moment later.

[Jennifer_Dungan]

---

Unfortunately, Launch does not have a built-in tracking queue that you can release as soon as consent is given. In other words, you may also have to manually retrigger e.g. a page view event should the page load without user consent and the user grants it a moment later.

---

True, but on the consent popup, you could listen for the "accept" to trigger.. so the same rule might be able to be set up with 2 triggers... something like DOM Ready or Window Loaded (depending on the needs), and a second trigger for the "Accept" action.

So when the page loads the first time (and the consent option appears but has not yet been acknowledged), the standard page trigger will pass, but the condition will not (so no tracking)... when the user accept tracking, the rule would be triggered and since consent is now accepted the condition should pass.

One thing to note @Herder , before getting too far down this path... is the consent screen actually about Analytics, or just cookies? Because technically you can continue to collect data without a fingerprinting cookie and I want to be sure you are aware of the distinction between the two... while tracking without setting the cookies can lead to higher UVs, opting out of tracking completely can result in a lot of lost data to help make decisions about what is and isn't working.... a lot of people seem to think that opting out of cookies means you can't track... and that's not really the case... unless you specifically are asking users if they will allow tracking, and not just about "fingerprinting cookies".