Configuring Page View Event with OneTrust Consent in AEM Analytics Integration | Community
Skip to main content
Level 1
February 19, 2026
Solved

Configuring Page View Event with OneTrust Consent in AEM Analytics Integration

  • February 19, 2026
  • 2 replies
  • 0 views

Hello Experience League Community,  

I’m working on configuring Adobe Analytics in AEM Sites and have successfully set up page view tracking using the guidance from this documentation:  
[Collect Data for Analytics in AEM Sites](https://experienceleague.adobe.com/en/docs/experience-manager-learn/sites/integrations/analytics/collect-data-analytics)  

Now, we also need to ensure that page view events are only triggered after the user has given consent via OneTrust.  

My question is:  
- What changes do I need to make to the existing rule configuration so that the page view event fires only after consent is granted?  
- Should the page view rule be modified to listen for OneTrust’s consent event before triggering the Analytics beacon?  
- Are there best practices or recommended approaches for integrating OneTrust consent with Adobe Analytics page view tracking in AEM?  

Any guidance, examples, or references would be greatly appreciated.  

Thank you!  
 

Best answer by bjoern__koth

Hi ​@SaurabhPathakRa 

assuming that you have Launch in place and are using the Adobe Analytics extension as well as the Experience Cloud ID Service:

  • here is a great tutorial, essentially what you do is
    • on the ID Service:
      • set “Enable Opt-in” settings to “yes”
      • create a data element for “Previous Permissions” that returns a JSON with the existing cookie consent, mapped to the Adobe solutions, as 
    • in a library-loaded Launch rule, make sure to listen to consent change events of your consent platform and  reevaluate the Adobe consent categories.
    • As soon as Analytics consent is given, the Identity Service will release the queued tracking calls. For OneTrust, you can register a callback function that is called upon consent change.
const consentInterval = setInterval(() => {
if (typeof window?.OneTrust?.OnConsentChanged === "function") {
clearInterval(consentInterval);
window.OneTrust.OnConsentChanged(() => {

// todo: reevaluate Adobe consent categories with adobe.optIn.approve, adobe.optIn.deny,
// todo: or adobe.optIn.approveAll() and adobe.optIn.denyAll()
// todo: once done, confirm consent changes with adobe.optIn.complete();

});
}
}, 250);

 

 

2 replies

bjoern__koth
Community Advisor and Adobe Champion
bjoern__kothCommunity Advisor and Adobe ChampionAccepted solution
Community Advisor and Adobe Champion
February 19, 2026

Hi ​@SaurabhPathakRa 

assuming that you have Launch in place and are using the Adobe Analytics extension as well as the Experience Cloud ID Service:

  • here is a great tutorial, essentially what you do is
    • on the ID Service:
      • set “Enable Opt-in” settings to “yes”
      • create a data element for “Previous Permissions” that returns a JSON with the existing cookie consent, mapped to the Adobe solutions, as 
    • in a library-loaded Launch rule, make sure to listen to consent change events of your consent platform and  reevaluate the Adobe consent categories.
    • As soon as Analytics consent is given, the Identity Service will release the queued tracking calls. For OneTrust, you can register a callback function that is called upon consent change.
const consentInterval = setInterval(() => {
if (typeof window?.OneTrust?.OnConsentChanged === "function") {
clearInterval(consentInterval);
window.OneTrust.OnConsentChanged(() => {

// todo: reevaluate Adobe consent categories with adobe.optIn.approve, adobe.optIn.deny,
// todo: or adobe.optIn.approveAll() and adobe.optIn.denyAll()
// todo: once done, confirm consent changes with adobe.optIn.complete();

});
}
}, 250);

 

 

Cheers from Switzerland!
Jennifer_Dungan
Community Advisor and Adobe Champion
Community Advisor and Adobe Champion
February 19, 2026

In addition to what ​@bjoern__koth said, setting the ID service Opt-In is important, and making sure your rules listen to your status..

However, depending on your set up… are you set up to be “initial status” of opt-in or opt-out until explicit consent is granted?

 

If you need explicit consent, then your initial PV likely won’t be tracked (since you will have conditions on it)… but what you can do, is add an additional “Direct Call” trigger on your page view rule… 

 

Then, when consent is granted, you can call your page view rule with the direct call naming, and trigger the page view rule again, but now it should run because the consent has been granted. 

 

At the end of the day, the implementation depends on your consent modelling approach and what is legal in your jurisdiction.  If you can treat the initial PV as trackable until the user opts out, then you can set your initial status to opted in and not have to change your rule at all…

 

Scenario 1 - Default Opt-In:

  • Page 1
    • Page View tracked as normal
    • consent window appears - user can now opt-out or agree, etc
  • Page 2
    • Depending on the consent selection, this page may or may not be tracked

 

 

Scenario 2 - Explicit Opt-In:

  • Page 1
    • Page View will not track (as consent has not been granted yet, condition not met)
    • consent window appears - user can now opt-out or agree, etc
      • If user opts in, this needs to trigger the rule to track your PVs (the initial trigger, i.e. DOM Ready, Window Loaded, etc has already passed - Direct Call is the easier way to trigger the same rule
  • Page 2
    • Depending on the consent selection, this page may or may not be tracked