The Page Name That Arrives Too Late
A media company runs a single-page application with Adobe Experience Platform Tags. After a release, 30% of Analytics page views have no pageName and 12% of page views are duplicates. The Analytics extension's Set Variables action runs in a rule triggered at DOM Ready. A separate Page Data rule sets pageName at Window Loaded. The SPA router calls a global function that executes s.t() on every route change, and the page-load rule also sends a beacon. A consent tool blocks Analytics until the visitor opts in, but the tag rule still fires. The team uses a staging report suite and wants a diagnosis before changing production.
1. Diagnose the missing and duplicate page views. What rule-order and ownership changes do you recommend?
Read the worked answer
The pattern is a rule-order and ownership problem, not a data-element problem.
- The Analytics Set Variables action runs at DOM Ready. The pageName is set by a different rule at Window Loaded. Window Loaded runs after DOM Ready, so the beacon fires first and pageName is empty. The 30% figure is the subset of pages where both rules run and the timing exposes the gap.
- The SPA router calls a global function on route change, and the page-load rule also fires
s.t(). Every route change that also triggers a page load produces two page views. The 12% duplicate rate is the overlap between the two paths.
Fixes:
- Put pageName, pageType, and other page-level variables in the same rule that sends the beacon. Use a data element with a default so the value is never empty.
- Use Library Loaded or a Direct Call rule from the router for page views, not DOM Ready plus Window Loaded.
- Establish one owner for
s.t(). The router should invoke a Direct Call rule; remove the page-load beacon or condition it on not being an SPA route. - Add a guard: if
s.pageNameis empty, do not send, and log a warning in staging.
2. How should consent be enforced so no hit leaves the browser before opt-in?
Read the worked answer
Consent must gate the beacon, not just the variable value. Use the tag property's consent management: set default consent to pending and have the consent tool update consent when the visitor chooses. The Analytics extension should be configured to respect consent, or the beacon action should sit inside a rule with a consent condition.
Do not fire s.t() before opt-in and then clear cookies as a remedy; the hit has already left the browser. If policy allows, do not load the Analytics library at all before opt-in. If the library must load, a pre-beacon rule can set s.abort = true for opted-out visitors, but test that no other rule resets it. Verify in staging with the network panel and the Experience Cloud Debugger: zero /b/ss/ requests before opt-in, one request per page after opt-in, and no request after opt-out.
3. How would you validate the fix in staging before production?
Read the worked answer
Use the Experience Cloud Debugger and the browser network panel on a staging report suite. Check that each route change produces exactly one /b/ss/ request, that pageName is populated, and that the pe parameter is absent for s.t() and set to lnk_o for s.tl().
Compare the router's navigation count to page views for a fixed script of 50 route changes; the ratio should be 1:1. Replay the consent states and confirm zero hits before opt-in. Run the same script against the old tag build to reproduce the 30% and 12% symptoms, then against the fix. Finally, monitor page views and bounce rate for 48 hours in production; a single day is too noisy to judge.