A tracking implementation is ready when a controlled inquiry produces the expected record and outcome, including its failure cases. An attribution QA checklist should therefore describe inputs, expected results and retained evidence. A screenshot showing that a tag exists is only one small part of that test.
View full-size graphic ↗Write the expected behavior before running a test
Choose one representative acquisition path, such as a local moving landing page followed by a form and a scheduled survey. Document the event, internal inquiry ID, source fields, responsible system and eventual booking update. State which system owns each value.
Separate an interface event from a business outcome. Pressing the submit button should not count as an accepted inquiry if validation or delivery fails. An accepted inquiry should not become a booked job until the business's booking conditions are satisfied.
Scroll the table horizontally to compare all columns.
| Field | What to record |
|---|---|
| Case ID | Stable test reference and release version |
| Input | Channel context, device and action |
| Expected | Event count, source and business state |
| Observed | Actual record and timestamps |
| Evidence | Redacted screenshot or internal record reference |
| Disposition | Pass, fail or blocked with owner |
Use test records in a controlled environment where possible. Avoid sending synthetic inquiries to live customer-facing workflows or advertising optimization destinations without a defined test procedure. Remove or clearly exclude test records from business reporting.
Exercise successful and unsuccessful lead entry
Scroll the table horizontally to compare all columns.
| Case | Expected result | Failure to catch |
|---|---|---|
| Valid form accepted | One inquiry with source context | Event without durable delivery |
| Required field missing | Accessible error; no accepted lead | Button click counted as conversion |
| Network or server failure | Honest failure state and safe retry | Success message despite lost submission |
| Double click or retry | One business inquiry for the attempt | Duplicate conversions |
| Answered phone call | Call record with actual answer state | Every call labeled qualified |
| Missed call or voicemail | Distinct call disposition | Missed contact counted as a booking |
CallRail's API distinguishes answered, missed and voicemail call states. Those fields describe call handling; they do not establish that a customer qualified or booked. Map your own vendor's documented fields to business outcomes rather than assuming the names are interchangeable. [1]
Run the same material form path on mobile and desktop. Test keyboard error recovery and the return path after a failed submission. Record whether the source survives the retry without copying personal form contents into analytics.
Check source continuity and privacy together
Inspect the landing context, any redirect, the submission and the downstream record. Test an untagged visit as well as a tagged campaign. An unknown source should stay unknown unless another valid signal resolves it; a default campaign label can conceal the defect.
Inspect the payload, not only the event name
Google Analytics prohibits sending recognizable personally identifiable information through ordinary analytics collection. URLs, titles and free-text fields can accidentally carry it. Review the actual outgoing payload and the fields your implementation permits. [2]
Include the site's consent states in the expected behavior. When a user declines optional measurement, lead delivery should follow the site's documented design without secretly restoring disabled tracking. The QA report should distinguish unavailable measurement from a broken business submission.
The GA4 event specification guide provides the broader event-design context.
Test the booking lifecycle and corrections
Scroll the table horizontally to compare all columns.
| Transition | Required check |
|---|---|
| Inquiry to estimate | Original inquiry remains linked |
| Estimate revision | No additional unique lead created |
| Booking accepted | Correct job ID and approved value basis |
| Cancellation | Outcome changes in the operating record |
| Revenue correction | Documented treatment in each destination |
| Duplicate import retry | No duplicate business outcome |
Do not assume every destination supports the same correction mechanism. A cancelled project may need a status update in the CRM, a reporting adjustment and a separate advertising correction. Specify and verify the supported path for each system before making a promise about automatic synchronization.
Test a late outcome and a record with incomplete identifiers. The correct result may be a visible rejection or a review queue. Silently dropping it or inventing a match would make the apparent coverage better while reducing the report's reliability.
Set release criteria and a repeatable regression sample
Classify failures by consequence. A lost inquiry, exposed personal data or repeated booked conversion should block the affected release. A missing optional campaign label may allow a limited rollout only if the owner accepts and documents the reporting gap.
After launch, repeat a small representative set after form changes, call-routing edits, CRM migrations or advertising connector updates. Monitor duplicate rates, unmatched outcomes and unknown-source share for unexpected changes. Investigate a sudden improvement too; it can reflect inflated counts.
Use lead tracking and attribution support to assign ownership across the website, intake process and reporting destinations.
Common questions
Does a tag-manager preview prove tracking is correct?
It proves only the behavior observed in that preview. Verify accepted submissions, downstream records, source continuity, duplicates and final business outcomes as separate steps.
How often should attribution QA run?
Run it before material releases and after changes to any part of the lead path. Maintain a smaller recurring sample based on traffic, change frequency and the consequences of a missed defect.
Your next step
An effective attribution checklist is a set of reproducible cases with expected business outcomes. It should catch failed delivery and incorrect bookings as readily as missing events.
Sources & editorial notes
Platform claims cite the documents below. Operating frameworks and labeled examples are MoverFuel editorial analysis, not client results or industry benchmarks.
- CallRail API v3 documentationCallRail API answer_status distinguishes answered, missed and voicemail, separate from lead qualification. Reviewed .
- Google Analytics: avoid personally identifiable informationGoogle Analytics prohibits recognizable PII in ordinary analytics collection; URLs and fields can leak it. Reviewed .
