adobe.optIn and ECID in an eVar | Community
Skip to main content
B
bkoth_work
New Participant
March 24, 2022
Solved

adobe.optIn and ECID in an eVar

  • March 24, 2022
  • 1 reply
  • 1688 views

Hi all

 

I am facing a problem which you can maybe help me with (if it can be resolved at all...).

We are having a setup deployed by Launch, including Experience Cloud ID Service and Analytics.

We are also applying the ECID service's opt-in functionality, meaning we're explicitly setting the adobe.OptInCategories when they are accepted by the user.

 

The problem we have is the following

  • the page fires a page view including an eVarX that gets mapped to the ID Service's ECID data element type
  • when the consent is approved, this initial eVar value is not set and only subsequent calls have the eVarX set

I assume that is since as soon as the page view event is triggered but consent is not given, it ends up in an internal queue. And since the ECID has just not been retrieved yet, it is set to undefined.

 

Question is whether updating the page view call that is already in the queue with the new ECID that is retrieved after the banner has been accepted is actually possible at all?

 

Cheers

Björn

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

Ok, I get it. (Admittedly, I haven't used ECID's opt-in settings before. My knowledge is from Jan Exner's excellent posts on it: https://webanalyticsfordevelopers.com/2021/02/16/consent-and-launch/ and https://webanalyticsfordevelopers.com/2021/06/01/consent-and-launch-part-ii-opt-in/)

Back to your problem: yes, it seems that AA prepares and queues the hit before consent is given, and from what I can tell, there's no way to go back and modify that queued hit before it is sent. So I think you're stuck with what you have.

1 reply

yuhuisg
yuhuisg
New Participant
March 24, 2022

From my understanding of consent, I would assume that since the page view occurred before the user had given consent, then that page view should not be tracked in the first place. If so, then there is no need to backfill any eVar or other data point because it would be moot.

B
b_koth
New Participant
March 24, 2022

Hi Yuhui

 

that's the thing about Adobe's Visitor ID's consent API handles which Adobe tools to fire when.

So you can still trigger Analytics page views which are just not being sent unless consent is given.

 

The question was more if there is a way to update the bound data elements which are being mapped to the Analytics call as soon as it's available to fill previously missing data. I don't think it's feasible since it's more a fire and forget.

yuhuisg
yuhuisgAccepted solution
New Participant
March 24, 2022

Ok, I get it. (Admittedly, I haven't used ECID's opt-in settings before. My knowledge is from Jan Exner's excellent posts on it: https://webanalyticsfordevelopers.com/2021/02/16/consent-and-launch/ and https://webanalyticsfordevelopers.com/2021/06/01/consent-and-launch-part-ii-opt-in/)

Back to your problem: yes, it seems that AA prepares and queues the hit before consent is given, and from what I can tell, there's no way to go back and modify that queued hit before it is sent. So I think you're stuck with what you have.

    Terms & ConditionsAccessibility statement

    Loading footer...