AMCV Cookie is not being set on the first page load

[DataNord]

Hello Community, We recently found a bug on our site that the AMCV cookie which contains ecid is not being set when page gets loaded for the first time. It is being set after 2 or 3 page loads. After some debug, i figured that this is likely happening due to the Opt-in settings we have in ECID extension. 

Within ECID extension, we have configurations below:

"Previous Permission" uses a "onetrust: adobe consent" data element which returns either true/false for below objects based on our CMS OneTrust active consent groups on the page:

return {
aa: analyticsConsent,
aam: aamConsent,
target: targetConsent,
ecid: ecidConsent
};

When i look up the value of "onetrust: adobe consent" data element in the browser after the first load, i can see that it is setting everything as "true"

However, these values are not being passed to adobe as "true" for some reason and when i look for adobe.OptIn.permissions on the console, it is returning the below result.

Can someone help me explain on why this is happening and how to fix? 

Any leads would be appreciated!

[DataNord]

Looks like Adobe is not respecting the values which I'm sending via  "previous permissions". I just changed my config for pre optin approvals and set it based on the region. For example: if the users region is X , then set aa,aam,ecid etc to "true". Else If the user is from region Y, then set aa,aam,ecid etc to "false". Looks like the AMCV cookie is now being set but only when i keep the "Previous permissions" empty. Im wondering how can i retrieve the previous permissions of the user from region Y ? 

[Vinay_Chauhan]

Hi @DataNord 

It sounds like the issue may be with how and when the Opt-In settings are being applied, not necessarily the values themselves.

Even though your 'previousPermissions' data element returns 'true' values, they might be getting passed after the ECID service tries to set the AMCV cookie on the first page load.

One approach you could try:

• Make sure your 'previousPermissions' data element resolves synchronously and is available before the ECID extension fires.

• Double-check that your Launch rules aren’t delaying consent updates until after the ECID library attempts initialization.

• If needed, use 'adobe.optIn.approve()' manually as soon as consent is available, especially useful for region-based logic.

Also, the reason it “works” when you leave 'previousPermissions' empty is that Adobe waits for real-time user interaction, avoiding pre-mature evaluation. To persist prior consent per region, you might consider storing user consent in localStorage or a cookie, then reading that on subsequent visits.

Hope that helps clarify things a bit!

[bjoern__koth · Accepted solution]

Hi @DataNord 

question: is your logic based upon the window scoped "OptanonActiveGroups" object?

If so, then I would urge you to check the "OptanonConsent" cookie value directly which will give you the same opt-in information in the form "<consent group id>:1" (or :0 if no consent for that category).

Like so:

(_satellite.cookie.get("OptanonConsent") || "").includes("C0002:1")

Example where parts are enabled and C0003 is disabled "groups=C0001:1,C0003:0,C0004:1,C0002:0"

OneTrust is let's say "special" when it comes to the time when the consent information is available within the OptanonActiveGroups.

I have seen this happen many times, analyzing the cookie yourself is your best bet to initialize the previous consent if you ask me.

[Sukrity_Wadhwa]

Hi @DataNord,

Were you able to resolve this query with the help of the provided solutions, or do you still need further assistance? Please let us know. If any of the answers were helpful in moving you closer to a resolution, even partially, we encourage you to mark the one that helped the most as the 'Correct Reply.'

Thank you!