Why do Adobe Analytics hits double up or fail specifically on WebKit/Safari?

Why this happens

WebKit's back-forward cache keeps a full snapshot of a page in memory when the user navigates away, so that hitting Back restores it instantly instead of reloading from the network. If your page-view tracking is bound to a load or DOMContentLoaded event without accounting for bfcache, that code does not automatically re-run when the page is restored from cache - the real risk is the opposite of what people expect: a page-view listener written to fire "once, on load" can miss the restored view entirely, while other implementations that rebind listeners on every pageshow event (a reasonable-looking fix for that gap) fire the tracking twice if they don't check whether the page was actually reloaded or merely restored.

Intelligent Tracking Prevention is a separate mechanism entirely: Safari limits the lifetime of cookies set via JavaScript (as opposed to an HTTP response header) for tracking-classified domains, so a visitor identifier that would normally persist for a year in other browsers can expire and regenerate far sooner in Safari. That doesn't create duplicate hits - it creates duplicate visitors, inflating unique-visitor counts and fragmenting a single person's activity across what Adobe Analytics reports as several distinct visits.

Fix it

1. For bfcache-related duplicate or missing page views, check the persisted property on the pageshow event rather than relying on load alone - it tells you definitively whether the page just came from the network or was restored from bfcache:

window.addEventListener('pageshow', function (event) {
  if (event.persisted) {
    // Restored from bfcache - the page did not actually reload.
    // Track it explicitly here if a restored view should count as a page view.
    window.digitalData = window.digitalData || [];
    window.digitalData.push({ event: 'virtualPageView', pageName: document.title });
  }
  // A normal (non-persisted) pageshow fires alongside the regular load event -
  // don't also track here, or a fresh load double-counts.
});

Whether a bfcache restore should count as a new page view at all is a measurement-policy decision, not a technical one - decide it once, encode it in this one listener, and remove any other page-view binding on load that doesn't account for it.

2. For ITP-related visitor fragmentation, there is no code fix that restores pre-ITP cookie lifetimes - it's a deliberate browser privacy control, not a bug. The available options are: rely on Adobe's own first-party ID service where your implementation supports it (which uses a CNAME'd first-party domain, treated differently than a plain JS-set cookie by ITP in many configurations), or accept that Safari visitor counts are structurally not directly comparable to other browsers' and report on that basis rather than trying to normalize them to match.

3. Rule out a third, mundane cause before assuming either of the above: a rule or listener bound twice (see the general data-element-firing-twice pattern) is browser-agnostic and shows up more often in Safari testing simply because Safari-specific QA passes tend to be the first place a real duplicate-binding bug gets noticed, not because Safari itself caused it.

How to verify it worked

• In Safari, load a page, navigate forward to a second page, then use Back - with the AEP Debugger or Network tab open, confirm exactly one page-view-equivalent event fires for the restored page (or zero, if your policy is that bfcache restores shouldn't count), consistently.
• For ITP, check the actual expiry on the visitor cookie in Safari's own developer tools (Storage panel) against the same cookie's expiry in Chrome or Firefox on the same site - a materially shorter lifetime in Safari confirms ITP capping, not a duplicate-hit bug.
• Cross-check visit and unique-visitor counts for Safari specifically in Analysis Workspace against another browser over the same period - a persistent gap in visits-per-visitor is the ITP signature; a spike in exact-duplicate hits for the same session ID is the bfcache signature. They call for different fixes.

Illustrative, not a measured result: a site whose page-view tracking was bound only to load might see duplicate hits from back-navigation testers disappear entirely once the same tracking call is gated behind an explicit pageshow/persisted check, without touching anything ITP-related.