Onetrust's default opt out consent causing AA data loss | Community
Skip to main content
A
AbhijithRa1
Level 3
January 19, 2024
Question

Onetrust's default opt out consent causing AA data loss

  • January 19, 2024
  • 1 reply
  • 2934 views

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?

    This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

    1 reply

    Jennifer_Dungan
    Community Advisor and Adobe Champion
    Jennifer_DunganCommunity Advisor and Adobe Champion
    Community Advisor and Adobe Champion
    January 20, 2024

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

    A
    AbhijithRa1Author
    Level 3
    January 22, 2024

    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.

    A
    AbhijithRa1Author
    Level 3
    February 6, 2024

    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... 


    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.

     

       

      Terms & ConditionsAccessibility statement

      Loading footer...