Onetrust's default opt out consent causing AA data loss

[abhijithr]

As major traffic in Canada comes from Quebec, and oneTrust's performance(adobe analytics mapped) category takes default opt-out(until user opt-in voluntarily), thus missing significant amount of data. Is it unavoidable in client side app measurement setup? Any work around until we switch to server side?

[Jennifer_Dungan]

Are you trying to opt out of tracking completely? Or just cookies that identify the user?

[abhijithr]

Jennifer, thanks much for the response. My understanding is until user opt-in performance category, none of hits must be captured, so no data payload would be sent for that user, right. I didn't get you completely, but I hope this helps get the context of the Q. 

NO adobe cookies would be dropped until user enable performance category on his/her oneTrust banner, AA completely goes dark for that session.

[Jennifer_Dungan]

It really depends on what your policies are and what you are asking users to Opt In / Out of... 

If you are going for full on, Opt In to tracking, then you will get data loss.. 100%, nothing you can do about that... You've asked users to Opt In, they didn't.. Therefore you cannot track them... you can't force people to opt in...

If your policy was simply around cookies (tracking cookies), you could still track analytics about what content is being viewed, but prevent the ECID cookies from being set, and I believe you can set the s_vid cookies to expire at the session, preventing that user from being re-identified on their next visit... this will cause inflation in your UV stats, but you would still at least see what people are looking at and get basic stats around traffic.

My understanding around the Quebec Law is around identifying the user and collecting personal information... being able to collect "page views on page X" shouldn't fall under that (but I am no legal expert)...

[abhijithr]

hi Jen(Champ),

It was so well put, and now I'm realizing the distinction between Geo regulatory expectation and our possibilities yet. it's a spectrum rather binary(mindset!). I'll explore s_vid, although it needs tweaking in Launch as we have currently primarily relied on the ECID opt-in/out(based on OT cookie val) to to send/not the payload despite rule execution condition.

Please feel free to drop a link to article in case if had came across; for it's execution. Thanks a ton. 

[Jennifer_Dungan]

Sadly, a lot of this is so new to us all.. I don't know if there are any specific articles out there (there are probably some, and I bet like here, there's going to be a lot of varying viewpoints while everyone tries to navigate all these new legislations).

I just know that I was helping someone in the last few weeks that after disabling the ECID during the Opt-Out state, Adobe will default to the s_vid cookie (which is still "following" the user)... It's just that ECID is network wide (all your sites in your organization), vs s_vid which is set to the specific domain (basically this is how users were tracked before ECID was a thing)... So in theory, if users opt-out, you can disable ECID and I think set the s_vid to expire after the session... but this would still allow you to track basic data about your site...

Your own internal team may have made decisions about opt-out means total opt-out.. but that obviously is going to really hurt overall stats (as you mentioned)

[abhijithr]

hi Jenny,

no worries at all, I completely understand it's a new for all.

Before ECID, my understanding was app measurement JS itself set s_vid, but now within AA extension in Launch, there is a place holder in cookie accordion for customer to set. We can absolutely populate a session cookie or session length persistency. Would there be any data processing concerns from Adobe, pls advise?

of course, UV & visits KPI spikes, campaign time2purchase goes off, and below few possible session splits scenarios, which are unavoidable. that's okay.

• As one clears their cache within a session
• Opens a different browser
• switch to Incognito and so forth, which are acceptable rather having nothing.

Thanks

[Jennifer_Dungan]

I believe that if the ECID isn't set (i.e. if the ECID extension is disabled due to opt-out), that Adobe will go back to writing the s_vid cookie. But, if you are talking about "cookie lifetime":

That is also what I was saying... I think the will still set the old s_vid... but I think it will set it to none or session, or "X" Seconds if you change it from default... it might apply to all cookies set by the tracking, but I don't know if this will apply to cookies set via plugins (if you have any)... you would have to test this.

Since s_vid is still a tracking cookie, you need to make sure that this isn't set to persist in order to comply with your opt-out....

If opt-in, user should use ECID, if opted out, they get the s_vid, but it doesn't persist... or at least that is what I think will happen....

The only processing issue you will experience is likely to be higher UVs...(which you already have anticipated for) since opted out users will be treated as a new visitor on each visit... but I don't think anything else will be impacted... the session based s_vid should allow all the pages inside the visit to at least be stitched together. If no s_vid, then Adobe will write a temporary s_fid (fallback id), which I don't believe has a long life, but again, it's better to confirm this.

[abhijithr]

Hi Jenny,

OK. we set custom vid(session length), but besides that there is s_fid(fallback) w/ 6m expiry. Although processing would happen s_vid basis, wonder why s_vid got set(concerned from not opt-in consent perspective) even when I set custom vid!.

If you could shed some more light on s_fid? hoping to consider tweak it only with better info as that's critical for sessionization when custom vid goes blank, otherwise UV/V may become hits count!

Thanks a ton I know you would have 100's post like me. Your interest & effort are much appreciate always.

[Jennifer_Dungan]

Hmm that's odd about the s_fid... though Adobe cookies have always been a bit of a black box...  I'm honestly surprised that the fallback id isn't set to the same lifetime as the settings... 

This may require support.. maybe that's a bug, or maybe they can explain the rational behind setting it that way... (I suspect a bug... since the cookie lifetime was something I don't recall being an option back in the old days of hosting the AppMeasurement.js files (or even older to the s_code.js files.... )

What I know about the s_fid cookie is that its some sort of "short-lived" (maybe not as short as I thought) cookie...

Basically, Adobe looked for the ECID, then for the s_vid, then for the s_fid to send an identifier to Adobe... with all the cookie opt-outs, ECID is easy, s_vid is decent (when you can set the lifetime to session - which if you have ECID you shouldn't need), but s_fid seems it might be an issue... I also don't know if Adobe will use the s_fid to reset the s_vid (to try and "re-stitch" the user...).. this is why I think support would be really helpful here... 

[abhijithr]

Alright, now s_fid made session bound.

And another thought that "would Adobe reset(to re-stich) s_vid", also now ruled out; within single session I deliberately changed my s_vid(not s_fid) twice, and eventually my report tells me 3 visits and not one(not stitched despite retained s_fid in all those hits). Thanks Jenny.

[Jennifer_Dungan]

Whoot! Excellent news!

Hopefully this information will help new people as they find it... it's certainly something I am going to store in my brain until we are ready to implement cookie consent!