What is quiz-to-revenue attribution QA?
Quiz-to-revenue attribution QA is a reproducible reconciliation test across systems that observe different parts of the journey. It checks whether one synthetic participant and completion can be traced to the expected contact, qualification state, action, opportunity, and revenue record without duplication, accidental merging, or unsupported inference.
Keep identifier classes distinct: person or account, quiz completion, analytic event, downstream action or opportunity, and transaction. One person can have several completions; one completion can emit several events; and several attempts can precede one accepted action. Google Analytics recommends separate lifecycle events such as generate_lead, qualify_lead, working_lead, and close_convert_lead, but those observations still need to reconcile with the operational record.
Related: Define the identity and deduplication contract · Preserve fields at CRM handoff
Sources: Google Analytics, Recommended events
Use a cross-system reconciliation matrix
Declare the owner, join evidence, cardinality, authoritative value, and unmatched state for every layer. Never let a reporting convenience silently turn a one-to-many history into one overwritten row.
Use privacy-preserving pseudonymous identifiers in analytics. Do not export direct contact details, sensitive answers, or free text merely to make a join convenient. The ICO says personal data should be adequate, relevant, and limited to what is necessary, and it marks this guidance as under review following the Data (Use and Access) Act.
| Layer | Required join evidence | Common failure | Blocking result |
|---|---|---|---|
| Quiz | completion ID, quiz version, result, time | Missing version | Historical logic cannot be reconstructed |
| Contact or CRM | person ID, completion ID, source, permission state | Prior completion overwritten | Repeated journeys disappear |
| Analytics | event ID, completion ID, event name, time | Duplicate success event | Funnel and attribution inflate |
| Sales | owner, route version, opportunity ID, accepted time | Owner change without history | Handoff cannot be explained |
| Revenue | opportunity or order ID, value, currency, close time | Reused or unmatched ID | Revenue joins to the wrong journey |
Sources: ICO, Data minimisation principle
Run eight synthetic attribution tests
For each case, record the expected row count, join cardinality, attribution state, unresolved state, and cleanup action. Block release when a join becomes many-to-many without an explicit model, retries double revenue, or unmatched records disappear from the report.
- One person, one completion, one accepted opportunity, and one conversion.
- One person with two completions under different quiz versions.
- One completion with a failed action attempt followed by a successful retry.
- Two people sharing a company or household identifier.
- A duplicate browser submission that must not create a second opportunity.
- A lead closed unconverted and later reopened under a new opportunity.
- Revenue arriving after the selected reporting window.
- An analytics event present while the operational record is missing.
Worked retry and wrong-completion example
A synthetic participant completes quiz version 7 twice. Completion A routes to nurture; completion B routes to manual review after an answer changes. The CRM correctly retains both completion IDs, but analytics sends generate_lead twice for completion B after a retry and the sales system attaches the opportunity to completion A.
Do not choose the most favorable result. Quarantine the record, exclude or annotate the duplicate event in reporting, repair the opportunity join to completion B, preserve the audit history, and add a deterministic event or action key so the retry cannot create a second accepted success.
Separate attribution from causality
An attributed outcome means the declared rules linked a revenue record to a quiz journey. It does not establish incremental effect. Prior touches, seller effort, seasonality, traffic mix, and self-selection can explain the observed outcome. Use attribution for operational reconciliation and descriptive reporting; use controlled experiments or stronger causal methods for causal claims.
Google's Measurement Protocol can supplement tagged activity with server-side or offline events, but Google says it is intended to augment rather than replace normal tagging. Preserve the operational source record and validate the payload; an accepted request alone does not make the business join correct. NIST's experimental-design guidance starts with explicit objectives, variables, and design selection, which a retrospective attribution table does not provide.
Related: Design a controlled quiz experiment
Sources: Google Analytics, Measurement Protocol · NIST, Choosing an experimental design
Quiz attribution release checklist
Release only when the joins and interpretation can be reproduced from synthetic records and declared rules.
- Person, completion, event, action, opportunity, and transaction IDs are distinct.
- Every join has an owner, cardinality, authoritative source, and unmatched state.
- Timestamps, time zones, quiz versions, and rule versions are preserved.
- Retries cannot duplicate opportunities, accepted conversions, or revenue.
- Multiple completions remain visible instead of overwriting history.
- Value and currency come from the authoritative transaction record.
- Direct contact data and unnecessary sensitive fields stay out of analytics.
- Unmatched and late-arriving records remain measurable.
- Reporting language separates attribution, association, and causality.
What this matrix cannot prove
This matrix checks data integrity and declared joins. It cannot recover data that was never recorded, resolve identity perfectly across devices, choose the right attribution model for every business, or prove incremental revenue.
Privacy, retention, and legal duties vary by context. The test cases are synthetic, not performance benchmarks, and this guide does not replace statistical review, privacy assessment, or legal advice.
Evidence
How to reproduce the method
A five-layer reconciliation matrix, five identifier classes, eight synthetic attribution tests, a worked retry and wrong-completion example, an attribution-versus-causality distinction, and a blocking release checklist, verified against current Google Analytics, NIST, and ICO primary guidance on October 11, 2026.
Limitation
Where this conclusion stops
The matrix validates declared joins and reporting integrity but cannot recover unrecorded data, resolve identity perfectly, choose a universal attribution model, or prove incremental revenue.
Sources and verification
What this guide relies on
- Google Analytics, Recommended events
- Google Analytics, Measurement Protocol
- NIST, Choosing an experimental design
- ICO, Data minimisation principle
- The Lead Quiz Review editorial methodology
Sources and method checked October 11, 2026. External standards are linked to their primary publishers. Request a factual correction.