Adobe calls firing inconsistently after onetrust implementation

[at9191]

I recently implemented onetrust on my website. The set up is the user requires to opt in to for the cookies to be dropped and analytics calls to fire. Once the accepts all or performance cookies the Adobe analytics and ECID cookies drop, dataLayer loads but the AA calls don't fire consistently. Sometime they fire and sometimes they don't. Out of 10 page reloads it AA calls fire approx. 4 times. It's clear that the tags work but there is something prevents it from firing in certain cases. I suspect it is a timing issue. 

• The onetrust banner fires Library load (page top) 
• We have a data element for previous permissions 
• And rule with the onetrust function that opts in or out based on the user intraction on the banner 
• Onetrust group each rule belongs to

Can someone help me understand why the AA calls fire in some cases and do not in other? Do I add a banner directly to the website instead of doing it via launch? 

[Jennifer_Dungan]

While I haven't actually implemented this, I have done some playing with the settings.

My first question is, the policy you are checking is only around cookies? Have you considered having tracking occur without the cookies, then setting the cookies after the user has opted in? Basically the ECID plugin has Opt-In logic available, and for the old s_vid cookie you can set that to be session level (thereby not really a fingerprinting cookie any longer). Once the user accepts cookies, the ECID can be set and should stitch into Adobe via the temp s_vid cookie, and if the user doesn't accept, you still can track traffic, but without tracking the returning user (who should be treated as new).

I suspect you are right about a timing issue, but without seeing what is happening it could be harder to help.

Would you be willing to share a URL to your website (even if it's directly in a Private Message and not posted publicly)? 

[at9191]

Hello Jennifer! 

What type of logic will I need to use in the ECID extension to fire analytics calls without using cookies? If aa and ecid is set to false will AA calls still fire? 

Let me just confirm if that is allowed. It is not on a public website at the moment. If I can share it via a private message. Thank you! 

Thanks!

[Jennifer_Dungan · Accepted solution]

So my demo site, I didn't have anything like OneTrust, so I just pre-set my permissions to false (but obviously you would want to use your controller to remember settings between visits):

(again, remember that this was all just demo data)

Now, this would control my opt-in out settings, and this for me defaulted to "false", but this only controls the ECID, as it's part of the Visitor Service Extension.. 

But for my Analytics Rules, I still had to add conditions to allow tracking if I wanted to stop analytics from firing completely...

Something like:

if (adobe.optIn.isApproved("analytics")){
  return true;
}

But that is only IF I didn't want analytics to fire...  If I still want tracking, without the ECID this wouldn't be needed.

But since without the ECID, the old s_vid cookie will be set, and there seems to be no control on that one, I suggest changing the cookies in Analytics to "Session":

This should make sure that s_vid doesn't stick around as a fingerprinting cookie.

But test this, to be sure you are matching your company's policy.

[at9191]

Hello Jennifer! I followed the steps above and I can see the AA calls firing consistently now. Thank you for sharing this with me. Since this worked, does it shed some light on what the issue was initially? 

[Jennifer_Dungan]

YAY! I am so glad this worked for you!

Without seeing your original implementation, I can really only guess... but if you were using conditions (basically checking the opt-in/out status), my suspicion is that your rules weren't firing because the allowed state hadn't yet been determined when your trigger had fired.

If your analytics tracking had been dependent on opting in (and not just cookies), then the solution would have been to use a more delayed trigger for tracking, something that would ensure that OneTrust had completed it's evaluation on each page.

For instance, let's say that you were using DOM Ready or Window Loaded as your trigger, and maybe OneTrust was using the same basic timing... depending on how long it took each script to run, it's possible that when OneTrust completed first your tracking would pass the condition, but when OneTrust hadn't completed, then your code wouldn't see the "yes, allow this" and your condition failed.

At least that is my guess at this time...

[at9191]

This makes a lot of sense. Thank you again Jennifer for all your help! 

[Jennifer_Dungan]

You are very welcome, and I am glad that you got the issue resolved without too much of a headache!