Adobe analytics page load rule is not triggering second time with ACDL | Community
Skip to main content
P
Phani_KumarPi
New Participant
July 11, 2025
Question

Adobe analytics page load rule is not triggering second time with ACDL

  • July 11, 2025
  • 3 replies
  • 924 views

Hello Everyone,

I'm new to Adobe Analytics and have created a rule for page load using a specific custom event called 'page load', triggered via Adobe Client Data Layer - Data Pushed. This rule works perfectly in all lower environments. However, in the Prod env (including the author environment), the rule triggers only once—when the page is loaded for the first time. On subsequent page loads, the rule does not fire.

Additionally, I noticed that the prod launch script includes headers like

cache-control : max-age=3600
etag :"1e97f6ab69caa332353cdff72029d3f5:1752060858.688733"
server: AkamaiNetStorage
 
What could be the reason ?? 
I am not able to reproduce in lower env.
 
 

3 replies

KumarRishii
KumarRishii
New Participant
July 12, 2025

In production, your Launch rule likely fires only once due to CDN caching (cached Launch script) and timing issues (ACDL event firing before Launch loads). To fix it:

- Invalidate the Launch script cache.
- Ensure adobeDataLayer.push fires after Launch loads.
- Use adobeDataLayer.push(callback) to reliably capture events.

I will recommend you to use the Adobe Debugger to confirm rule firing and data layer events.

Vinay_Chauhan
Vinay_Chauhan
New Participant
July 11, 2025

Hi @phani_kumarpi 

This definitely sounds like a timing issue between when your data layer event is firing and when Launch is actually ready to listen for it, which is why it works the first time but not on subsequent page loads in Prod.

A few things that to check -

  • Even though you're using the Data Pushed event from ACDL, if that event fires before Launch is fully loaded (or before the rule is listening), it’ll just be missed. This is a pretty common issue, especially in faster Prod environments where everything loads quicker than in lower ones.

  • Also, keep in mind that Data Pushed is a one-time event. So if your app isn't re-pushing that same page load event again on the next page transition, the rule won’t trigger a second time. This is especially important in SPAs or partially dynamic AEM setups where the URL changes but the full page doesn’t reload.

  • One quick test you can try: after the page loads, open Dev Tools and manually run -

    window.adobeDataLayer.push({ event: 'page load' });

    If your rule fires then, it's definitely a timing or trigger issue — not caching.

     

The caching headers you saw are normal and shouldn't block your rule from firing, unless the scripts themselves are outdated or loading in the wrong order. Just make sure the ACDL and Launch scripts aren’t duplicated or delayed due to how things are bundled in Prod.

P
Phani_KumarPiAuthor
New Participant
July 11, 2025

Thanks, Vinay, for checking this.
Interestingly, I'm not seeing this issue in the lower environments—even though the Launch script is also being loaded asynchronously there. To confirm this issue, I just updated the launch configuration in the PROD environment with the Stage Launch script, and with that change, the rule started triggering correctly on every page load.

    Vinay_Chauhan
    Vinay_Chauhan
    New Participant
    July 11, 2025

    Ah, that’s really interesting and a great find.

    If swapping in the Stage Launch script makes things work consistently in Prod, that definitely suggests there’s something off in the current Prod Launch build. It might be an older library version, or maybe that specific rule didn’t get published correctly to Prod.

    A few things that might be worth checking -

    • Is the rule setup exactly the same between Stage and Prod (especially the event trigger and any conditions)?

    • Has the latest build actually been published to the Prod environment?

    • Any chance there’s a timing difference or custom script in Prod that’s interfering?

    Sometimes even a small mismatch between environments can cause weird behavior like this, especially when it comes to how quickly things load or fire.

    Jennifer_Dungan
    Jennifer_Dungan
    New Participant
    July 11, 2025

    Caching of the script shouldn't be an issue... the actual script isn't changing on every request so there is no reason for the server to take the strain of sending the file to every user on every page that loads the file... that caching just allows the JS file to be distributed on a cloud network to improve performance.

     

    Is your site an SPA (single page application)? Are there any conditions on the rule that might prevent it from triggering again? Are you seeing any errors in the console?

     

    Would you be willing to share a URL for me to check your site (you can send in private messages so its not available to everyone)? I can try taking a look, at least as much as I can see without access to your rules.

    P
    Phani_KumarPiAuthor
    New Participant
    July 11, 2025

    The application is not a Single Page Application (SPA). here is page
    In my rule, I haven’t added any conditions—it's a very simple setup that just reads page information to track the number of page views.

    In incognito mode, the rule fires correctly on every page hit, and metrics are captured as expected.
    However, in the browser, the rule only triggers on the first page load. From the second load onward, it doesn’t fire.

    Interestingly, I also noticed that if I open Developer Tools and then load the page, the rule does trigger again.

      Jennifer_Dungan
      Jennifer_Dungan
      New Participant
      July 11, 2025

      Good, SPAs are a pain...  they may be good for performance, but they require so much custom effort to make them work (both from a functional and analytics perspective....)

       

      After turning on Satellite Debugging, I am seeing a JS issue on your page.. this is the likely culprit.

       

       

       

      To use Satellite Debugging:

      // Turn on Debugging _satellite.setDebug(true); // Turn off Debugging _satellite.setDebug(false);

       

      This can help you get insights into what is happening in real time.

      Terms & ConditionsAccessibility statement

      Loading footer...