adobe.optIn and ECID in an eVar

[bkoth_work]

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

[yuhuisg]

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_koth]

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 · Accepted solution]

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.

[b_koth]

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