Move pageview tracking to OptimizelyProvider

[andrewscfc]

Resolves JIRA:

This PR tries out a suggestion from an Optimizely consultant, I'm not 100% sure if this code structure is clean long term but I'm happy to change it to debug the page view events we lose.

Below is an AI generated PR description verified by me

---

Bug: Optimizely page-views events not sent consistently

The experiment is evaluated client-side via useDecision from @optimizely/react-sdk, which fires a DECISION notification that the listener in withOptimizelyProvider subscribes to.

Previously, track('page-views') was called from the PageViewTracking component, which only rendered when OptimizelyPageMetrics read an active flag key from the optimizelyDecisionStore. The store was only populated when decisionEventDispatched was true — a flag the SDK sets only when it has successfully dispatched an impression event to Optimizely's servers. If that flag was false for any reason, the store was never updated, OptimizelyPageMetrics returned null, and no page-views event fired.

Fix:

• Move both track('visit') and track('page-views') into the notification listener in withOptimizelyProvider. Both events are now sent directly when a decision is received with decisionEventDispatched: true and an active variationKey, removing the dependency on the optimizelyDecisionStore rendering pipeline. visit is the ratio metric denominator and page-views is the numerator — sending them in the same synchronous call sequence guarantees visit always precedes page-views, ensuring page-views fall within Optimizely's 48-hour attribution window for the ratio metric. Visit session logic (30-minute inactivity window via localStorage) is encapsulated in a new visitTracking.ts module.
• Add a URL-keyed idempotency check (trackedPageViewUrls: Set<string>) to ensure both events fire at most once per page URL. A DECISION notification fires once per decide() call — not once per page load — so without this guard, multiple experiments on the same page would each trigger track(), inflating metrics. Note: track() is not experiment-scoped; Optimizely's backend attributes a single event to all experiments the user is enrolled in, so one call per page is correct. The Set is URL-aware for SPA navigation: a new pathname gets a fresh entry so each page still gets exactly one event.
• Add an onClient() early return at the top of the listener to prevent any module-level state mutation (notifyDecision, trackedPageViewUrls, localStorage) during SSR.
• Remove the decisionEventDispatched guard from notifyDecision. notifyDecision now runs on every eligible decision (active flagKey and variationKey !== 'off'), which is safe because notifyDecision already has its own idempotency check (activatedExperiments.has(flagKey)).
• Remove the newswb_ws_topic_discovery_module special case, which allowed tracking even when variationKey was 'off'. The listener now applies a single consistent rule.
• Delete PageViewTracking entirely and remove the trackPageView and trackVisit props from OptimizelyPageMetrics.

Testing

1. List the steps required to test this PR.

Useful Links

• Coding Standards
• Repository use guidelines
• Add Links to useful resources related to this PR if applicable.

[Copilot]

Pull request overview

This PR fixes inconsistent Optimizely view-event tracking by ensuring Simorgh records experiment activation on every Optimizely DECISION notification, rather than only when Optimizely reports that it successfully dispatched an impression event.

Changes:

• Removes the decisionEventDispatched property from the DECISION notification payload typing.
• Removes the decisionEventDispatched gate so notifyDecision(flagKey) runs whenever an eligible decision is received.

Comments suppressed due to low confidence (1)

src/app/legacy/containers/PageHandlers/withOptimizelyProvider/index.tsx:57

• The decision notification listener change isn’t covered by the existing withOptimizelyProvider tests. Given this PR’s goal (ensuring tracking renders even when Optimizely’s decisionEventDispatched is false), it would be valuable to add a unit test that mocks notificationCenter.addNotificationListener, invokes the registered callback with a DECISION payload where decisionInfo.flagKey is set and decisionInfo.decisionEventDispatched is false, and asserts notifyDecision(flagKey) is still called exactly once (and is idempotent on subsequent calls).

optimizely?.notificationCenter?.addNotificationListener(
  enums.NOTIFICATION_TYPES.DECISION,
  (
    notification: ListenerPayload & {
      decisionInfo?: {
        flagKey?: string;
        variationKey?: string;
      };
    },
  ) => {
    const flagKey = notification.decisionInfo?.flagKey;
    const variationKey = notification.decisionInfo?.variationKey;

    if (
      flagKey &&
      (variationKey !== 'off' || flagKey === 'newswb_ws_topic_discovery_module')
    ) {
      notifyDecision(flagKey);
    }

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 3 comments.

[andrewscfc]

de069ec

The solution now includes search so the doc is accurate

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 1 comment.

[andrewscfc]

de069ec

[HarveyPeachey]

I don't think this readme should contain any info about page view and visits, it might get confusing

[andrewscfc]

I think your point aligns with your other one around renaming this component, can we address it at the same time?

I think this helps a bit in that some metrics you'd expect to be in here have moved; I'd like the final version of this to have a better name and focus on the depth/completion metrics exclusively.

[Copilot]

Pull request overview

Copilot reviewed 11 out of 11 changed files in this pull request and generated 1 comment.