Multiple Consent Update API Call

Question

We are implementing a consent mode correction and would like to share observation and validate our approach with the community.

Current Setup:

• We are using a OneTrust consent banner on the website.
• Consent signals for GA4 events and Microsoft Bing Pixel are configured in GTM to fire on Consent Initialization (beginning of page load).
• Default and update consent calls for Microsoft Bing Pixel are triggered via GTM (highlighted in the black box in the image) on Consent Initialization.
• For Google (gtag), the update consent API call is managed through the OneTrust template.

Issue Observed:

For Microsoft Bing Pixel, we noticed that if a user changes their consent choice after the page has loaded, GTM does not automatically trigger the update consent API call. As a result, Microsoft Bing Pixel continues using the previous consent state until the next page load, and upcoming events may not reflect the latest user consent choice.

Solution Implemented:

We enabled the OneTrust template feature to trigger the Microsoft consent update API call. This ensures that whenever a user updates consent, Microsoft Bing Pixel receives the updated consent immediately and upcoming events use the latest consent value.

After enabling Microsoft consent update via OneTrust template:

• Consent Initialization events are now firing four times.
• Red box → consent calls coming from OneTrust template (only update calls) (On Page load & User consent change actions)
• Black box → consent calls coming from GTM (one default and one update call)(On Page load action only)

Question to the Community:

Is it recommended to keep both Microsoft consent calls from GTM and OneTrust template even though Consent fires multiple times, or should we remove Microsoft consent calls from GTM and rely entirely on the OneTrust template?

---

Additionally, sharing few more usecase where i tested to enable and disable GTM consent default and/or update api call and noted the outputs:

Note: Consider all usecase with OneTrust Consent update api call enable which resolve above highlighted issue of user consent choice update which reflect consent update into bing pixel event before pageload:

Usecase 1: Remove MS Consent default+update call from GTM

Then only update call is firing from oneTrust templet (ad_storage + analytics_storage)

Usecase 2: Remove MS consent update call & Keep default consent call only into GTM 

Then default call is firing from gtm (ad_storage into uetq.evq) & update call is firing from OneTrust (ad_storage + analytics_storage)

Usecase 3: If we keep MS consent  default+update from GTM and Update call from oneTrust templet

Then multiple update consent is firing but in uetq.evq update, default and update consent will listed. 

I hope above usecase helps to understand the different scenarios and consent status.

Question to the Community:

Is it recommended to keep both Microsoft consent calls from GTM and OneTrust template even though Consent fires multiple times, or should we remove Microsoft consent calls from GTM and rely entirely on the OneTrust template?

Looking forward to your guidance.

Best Regards,

Neet Patel

Answer 1

Based on the documented behavior of Universal Pixel consent mode, only one mechanism needs to own the consent state, as long as it:

1. Sets a default consent state early on every page, and
2. Sends an update whenever the user changes consent, before or during the session.

Universal Pixel reads consent via pixie('consent', 'update', { 'ad_storage': 'granted' | 'denied' }) (and any other consent keys) and applies the latest update it receives. Multiple updates are technically supported, but they add noise and complexity without functional benefit if they carry the same values.

The guidance for consent mode is:

• Define default consent once per page (for example, ad_storage: 'denied' by default) and
• Update it when the user changes their choice.

This is shown in the consent-mode setup examples, where the default is set once and subsequent pages only run the pixie('consent', 'update', ...) script as needed, not from multiple independent sources.

Given the three use cases described:

• Use case 1 (OneTrust only – update calls):
  • Works if the initial Universal Pixel script is configured with a default (for example, ad_storage: 'denied') and OneTrust sends the first update on page load according to the user’s stored choice. This matches the documented pattern where the default is set and then updated as needed.
• Use case 2 (Default from GTM, update from OneTrust):
  • Also valid: GTM provides a single default consent state, and OneTrust sends updates when the user’s preference is known or changes. This keeps ownership clear (GTM = default, OneTrust = updates) and avoids duplicate updates with the same values.
• Use case 3 (Default+update from GTM and update from OneTrust):
  • Results in multiple consent events (default + multiple updates) for the same state. The last update wins, but this adds redundant traffic and makes debugging harder. The documentation does not require or recommend firing both GTM and CMP updates for the same state.

From the documented best practices, the recommended approach is to avoid duplicate consent updates from multiple systems and keep a single, authoritative update path. In practice this means either:

• Keep a single default consent definition (via GTM or inline script) and let OneTrust own all updates, or
• Let GTM own both default and updates, if GTM is fully wired to the CMP and can react to consent changes.

Since OneTrust is already correctly sending immediate updates on user changes, the cleaner configuration is:

• Keep one default consent definition (for example, via the standard Universal Pixel consent-mode setup), and
• Remove the redundant Microsoft consent update tag from GTM so that only OneTrust sends pixie('consent','update', ...).

This aligns with the documented pattern of a single consent script in the <head> plus updates when consent changes, and avoids the multiple consent events observed in use case 3.

---

References:

• Microsoft Invest - Dynamic consent updates for Universal Pixel
• Microsoft Curate - Dynamic consent updates for Universal Pixel
• Microsoft Monetize - Dynamic consent updates for Universal Pixel
• Microsoft Invest - Set up consent mode in Universal Pixel
• Microsoft Curate - Set up consent mode in Universal Pixel
• Microsoft Monetize - Set up consent mode in Universal Pixel