AMCV Cookie is not being set on the first page load | Community
Skip to main content
D
DataNord
New Member
June 23, 2025
Solved

AMCV Cookie is not being set on the first page load

  • June 23, 2025
  • 4 replies
  • 792 views

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!

 

 

 

 

    Best answer by bjoern__koth

    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.

    4 replies

    D
    DataNordAuthor
    New Member
    June 23, 2025

    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
    Community Advisor and Adobe Champion
    Vinay_ChauhanCommunity Advisor and Adobe Champion
    Community Advisor and Adobe Champion
    June 24, 2025

    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
    Community Advisor and Adobe Champion
    bjoern__kothCommunity Advisor and Adobe ChampionAccepted solution
    Community Advisor and Adobe Champion
    June 24, 2025

    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.

    Cheers from Switzerland!
      Sukrity_Wadhwa
      Community Manager
      Sukrity_WadhwaCommunity Manager
      Community Manager
      July 3, 2025

      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!

      Sukrity Wadhwa
      Terms & ConditionsAccessibility statement

      Loading footer...