Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

SOLVED

adobe.optIn and ECID in an eVar

Avatar

Level 1

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 eVarset

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

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

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.

View solution in original post

4 Replies

Avatar

Community Advisor

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.

Avatar

Level 1

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.

Avatar

Correct answer by
Community Advisor

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.

Avatar

Level 1

Yeah I think so as well. The Visitor ID Service API is actually quite handy, it's just these small things that need to be known and some tweaks are always needed I guess.

 

Thanks for the input, I will pass it on to my stakeholders