The Preferred Sources interaction leaves the publisher page for a Google-controlled flow. A click listener can prove that the control was exposed or invoked, but it cannot automatically prove the user confirmed the site as a preferred source. Treating initiation as completion inflates adoption and can create misleading reporting, especially when consent is denied, navigation is interrupted, or a browser blocks the library.
Use this for publishers, analytics teams, and WordPress developers who want to evaluate placement and reader interest without sending unnecessary data or inventing a conversion state they cannot observe.
Quick answer
Define four separate states: eligible page view, button rendered, preference flow initiated, and reader returned. Name the click event preferred_source_flow_start, never preferred_source_added. Record page type, placement, integration type, device class, and consent state only when permitted. Keep Google-controlled confirmation outside the publisher conversion count unless Google exposes a documented completion callback. Compare exposure-normalized starts, return rate, engagement after return, and downstream subscribed-reader behavior.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Consent granted | One article view and button click | One start event |
| Consent denied | Same interaction | No analytics event |
| Library blocked | Fallback deeplink | Fallback start if permitted |
| Return navigation | Back to original article | No false new acquisition |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Document observable states and the claim each event is allowed to make. | Write the measurement boundary before adding a listener so initiation cannot become a false completion metric. | One eligible interaction generates at most one consented start event. |
| Implement one consent-aware listener for the chosen integration path. | Inspect standard and custom integration events without wrapping the control in a handler that fires twice. | Denied consent generates no publisher analytics request. |
| Exclude credentials, email, account identifiers, query text, and full referrer details. | Respect analytics consent and test granted, denied, delayed, and changed consent states. | Return navigation does not create a self-referral or duplicate acquisition session. |
| Test granted, denied, blocked, repeated-click, mobile return, and browser-back branches. | Preserve the clean return URL without campaign parameters that create duplicate sessions or self-referrals. | Dashboards label completion as unobservable unless an official callback exists. |
What to check first
- Write the measurement boundary before adding a listener so initiation cannot become a false completion metric.
- Inspect standard and custom integration events without wrapping the control in a handler that fires twice.
- Respect analytics consent and test granted, denied, delayed, and changed consent states.
- Preserve the clean return URL without campaign parameters that create duplicate sessions or self-referrals.
- Use page and placement cohorts to judge whether the control helps readers instead of optimizing raw clicks.
Field notes
- Use synthetic IDs and examples that can be traced from the first request or interaction to the final record.
- Keep a before and after result for every changed setting, package, selector, route, or deployed version.
- Separate user-visible success from internal success so a green interface cannot hide a failed request or inaccessible control.
- Review the evidence again after caches, queues, browser history, and scheduled work have had time to settle.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
event: preferred_source_flow_start
page_path: /blog/example-guide
placement: article_footer
integration: standard_js
consent_state: granted
returned_to_article: unknown
preference_completed: not_observable
Why this usually happens
- Delegated click listeners can fire once on the wrapper and once on the custom trigger.
- A tag manager may rename initiation as a completed conversion.
- Cross-site navigation can create referral or session artifacts when return handling is not tested.
- Consent can change after initial render, leaving a stale listener or queued event.
Decision rule
Keep the measurement only if event names accurately describe initiation, denied consent produces no analytics request, one click produces one event, and reporting never labels an unobserved Google confirmation as completed.
Production verification checklist
- One eligible interaction generates at most one consented start event.
- Denied consent generates no publisher analytics request.
- Return navigation does not create a self-referral or duplicate acquisition session.
- Dashboards label completion as unobservable unless an official callback exists.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Document observable states and the claim each event is allowed to make.
- Implement one consent-aware listener for the chosen integration path.
- Exclude credentials, email, account identifiers, query text, and full referrer details.
- Test granted, denied, blocked, repeated-click, mobile return, and browser-back branches.
- Report starts per rendered control and evaluate qualified engagement after return.
Mistakes to avoid
- Changing production before recording exact versions, UTC timestamps, settings, stable fixture IDs, and a reproducible baseline.
- Treating one successful screen as proof that keyboard access, APIs, caches, jobs, reports, analytics, and downstream records agree.
- Testing only an administrator session instead of the devices, roles, networks, consent states, and failure branches customers use.
- Closing the work without a named owner, rollback point, observation window, and contextual incoming link from an established guide.
Questions teams ask during testing
Can this be tested on production?
Use production for read-only checks and one narrow synthetic fixture that cannot charge a card, send real customer email, expose personal data, or change inventory. Run upgrades, package changes, cache changes, and destructive repairs on staging first.
What evidence should the test report keep?
Keep exact versions, UTC timestamps, stable synthetic IDs, expected and actual results, screenshots or response excerpts, the decision owner, rollback point, and final verification. Redact credentials, tokens, customer data, private addresses, and infrastructure details.
How long should the observation window stay open?
Keep it open long enough to include at least one cache cycle, scheduled job cycle, and representative traffic period. For release changes, include both logged-in and logged-out use plus the first real operational handoff.
When is the task complete?
Complete it when the primary user path passes, downstream records reconcile, failure branches are understood, monitoring is active, and an established owner page links to this guide in context.
What to tell the client or owner
Give the site owner the affected versions, exact synthetic fixture, UTC timeline, before and after evidence, cause class, decision, rollback point, unresolved risks, and next review date. State which measurements prove success and which observation window remains open.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, audit consent-aware WordPress analytics.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references