Checklist · tracking · ga4 · measurement
A pre-launch tracking checklist for forms, calls, GTM, GA4, conversion actions, consent, identifiers, deduplication, and booked-job reconciliation.
Tracking is not a technical ornament placed beside a campaign. It is the audit trail on the money.
If a form click is counted as a lead, a missed call is counted as a booking, or a duplicate GA4 event is counted twice, the campaign can report confidently in the wrong direction.
The short answer
Test the path from advertising activity to a business outcome you can verify: identity, event definition, capture, delivery, attribution, and reconciliation. A tag firing is not a booked job. A platform conversion is not revenue. A screenshot is not proof that the whole chain works.
Before launch, test these six layers in order. A failure at an early layer makes every later layer unreadable.
Is the correct property, container, account, domain, and business connected?
What exact business action does each event represent?
Does the event fire when the action actually occurs?
Does the event reach GA4, Google Ads, the call system, CRM, calendar, or other receiving system?
Can the outcome be associated with the ad interaction, and is the action correctly marked primary or secondary?
Can the event be compared with qualified enquiries, booked jobs, completed work, revenue, and contribution?
Create a simple map before changing tags.
| System | Record |
|---|---|
| Website or landing page | Domain, forms, phone numbers, booking tools, thank-you pages, AJAX paths, and redirects |
| Google Tag Manager | Container ID, environments, workspaces, published version, and owners |
| Google Analytics 4 | Property, data stream, events, key events, internal traffic, and retention settings |
| Google Ads | Customer ID, conversion actions, campaign goals, primary and secondary actions, and account access |
| Call system | Main number, dynamic number insertion, provider, recordings, call outcomes, and retention policy |
| CRM or booking system | Lead ID, source fields, stage changes, booking status, revenue, and cancellation status |
| Consent system | Banner, regional logic, consent signals, and tags affected by consent |
Do not assume the account is correct because a tag appears on the page. Confirm the property and the customer ID.
Write the event definition before choosing the tag.
| Event | Business definition | Is it a booking? |
|---|---|---|
phone_click | A user tapped a phone link | No |
connected_call | A call connected under the call system’s rules | Not automatically |
qualified_call | The call met the business’s service and location criteria | Not automatically |
form_attempt | A user attempted to submit a form | No |
form_success | The form was accepted by the intended receiving system | Not automatically |
qualified_enquiry | The request fits service, location, timing, and customer criteria | No |
booked_job | The business’s written booking milestone occurred | Yes, under the stated definition |
completed_job | The service was delivered | It is a later outcome |
revenue_recorded | Revenue was confirmed in the business system | It is an economic outcome |
Do not name an event booked_job if it only represents a button click or a form submission. Names should describe what the business can defend.
Confirm the intended container is installed on every relevant page, that the published version is the version being tested, that there is no unintended second container or duplicate Google tag, that the correct Google Ads customer and GA4 measurement IDs are used, that the domain, subdomains, redirects, and booking tools are covered, that consent behaviour is known before tags fire, and that the data layer or event model is documented.
A duplicate container can cause duplicates, but it is not the only cause. Other causes include multiple tags, imported and native conversions measuring the same action, repeated thank-you pages, duplicate event pushes, single-page-app history changes, or form integrations firing more than once.
Google Tag Manager’s Form Submission trigger has a Check Validation option. Google says that when it is enabled, the trigger fires only if the form is successfully sent according to the trigger behaviour; when it is disabled, the trigger fires whenever a user attempts to submit.
That is useful, not universal. Modern forms may use AJAX, custom validation, embedded tools, redirects, or a data-layer event instead of a traditional browser form submission. Choose the trigger that matches the actual implementation.
| Test | Expected evidence |
|---|---|
| Required field left blank | No lead conversion. Validation error visible |
| Invalid email or phone | No lead conversion unless the business intentionally accepts it |
| Valid submission | Success state, backend or CRM receipt, and one event |
| Refresh the thank-you page | No unintended second conversion |
| Double click or repeated submit | Duplicate handling is understood |
| AJAX or embedded form | Success event comes from the correct response, not the button alone |
| Spam or blocked submission | It does not become a qualified lead without business review |
| Consent not granted where required | Tags respect the consent state |
| CRM or inbox receipt | The enquiry reaches the person or system expected to handle it |
A tag firing proves the tag fired. It does not prove the business received the customer’s message.
Separate the call stages, because the campaign optimises toward whichever one you send it.
| Stage | Meaning |
|---|---|
| Phone-link click | A user clicked a phone number |
| Call attempt | A call was initiated |
| Connected call | A connection occurred under the call system’s rules |
| Duration-qualified call | The call met a provisional duration rule |
| Qualified enquiry | The caller fits service, area, timing, and customer criteria |
| Booked job | The business recorded a booking |
| Imported outcome | A later business outcome was linked back to the ad interaction |
Then test that the number shown on the landing page is the intended number, that dynamic number insertion does not replace the wrong number or break the call path, that calls from ads and calls from the website are distinguished where possible, that the source, campaign, landing page, time, and call record are retained lawfully, that missed and returned calls are classified consistently, that recording and transcription follow the applicable notice, consent, retention, and access rules, and that the call system and CRM can identify qualification and booking status.
Google’s call-conversion documentation distinguishes call types and supports duration and other settings, but the business decides what a meaningful enquiry is.
Before importing or creating a conversion action, document each decision.
| Setting | Decision |
|---|---|
| Conversion name | A name that describes the real action |
| Source | Native Google Ads tag, GA4 import, call system, CRM, or another source |
| Primary or secondary | Whether the action is used for bidding or observation |
| Counting | One or every, based on the business meaning of repeated actions |
| Value | A defensible value, or no value when it is unknown |
| Conversion window | Long enough to cover the observed outcome delay for this account |
| Attribution | The selected model and its limitations |
| Deduplication | How the same action is prevented from counting twice |
| Consent | How measurement behaves under the applicable consent state |
Google says GA4 events and key events can be imported into Google Ads, that Analytics and Google Ads settings can differ, and that events created through the Google Analytics interface are set as secondary by default and may need an optimisation-setting change in Google Ads.
Do not set every form, phone click, and call event as primary. Choose the action that best represents the outcome the campaign can optimise toward, and keep diagnostic or earlier-stage events for observation.
Counting is not a deduplication tool. Setting a conversion action to count one conversion answers a business question about repeated actions by the same customer; it does not fix an event that reaches the account through two paths. Deduplication requires a tested event and source design.
For later outcomes, check whether the identifiers needed for attribution survive the journey. Auto-tagging is enabled where required. GCLID or other supported identifiers are not dropped by redirects or forms. Booking tools and CRM fields preserve the source or lead ID where lawful and practical. Email and phone data used for enhanced or offline measurement are handled under the applicable privacy and consent requirements. The identifier is attached to the right customer and not copied across unrelated records. Imported outcomes are not uploaded twice.
Google’s import guidance notes that GCLID preservation can matter when connecting later outcomes to Google Ads. Offline conversion imports can improve the connection between an ad interaction and a later outcome such as a signed contract or a completed sale. They do not make a weak source record accurate by themselves.
Tracking should be tested in more than one consent state.
| Consent state | Verify |
|---|---|
| Consent granted | Permitted tags and events fire as intended |
| Consent denied | Tags honour the denial and no prohibited data is collected or stored |
| No choice yet | Default behaviour matches the configured consent design |
| Region-specific state | Regional logic does not accidentally apply the wrong rule |
| Withdrawal | The system responds to a later change where applicable |
Do not send unnecessary form contents, health information, financial information, call transcripts, or other sensitive data into analytics or advertising systems. Review the tracking design against the business’s legal and privacy obligations, not only against platform setup instructions.
At the end of the test, compare the layers.
| Layer | Owner record |
|---|---|
| Advertising | Spend, clicks, impressions, search terms, and campaign |
| Platform conversions | Google Ads and GA4 event counts with dates and settings |
| Contact | Calls, messages, forms, and source identifiers |
| Qualification | Service, area, timing, customer type, and validity |
| Booking | Booking milestone, date, service, and source rule |
| Completion | Delivered job, cancellation, refund, and repeat status |
| Economics | Revenue, variable cost, acquisition cost, and estimated contribution |
A difference between Google Ads and GA4 is not automatically a tracking bug. Differences can come from attribution, time zones, counting, consent, import delay, conversion windows, filters, modelled data, or different event definitions. Investigate before changing tags.
Thirteen checks. Nothing spends until each one has a pass condition met and a piece of evidence attached.
Pre-launch tracking checks
0 of 13Accounts and tags
Forms and calls
Conversion configuration
Outcome continuity
The pass condition and the evidence for each check are the part that makes the list an audit rather than a to-do list:
| Check | Pass condition | Evidence |
|---|---|---|
| Correct account | Property, container, and Ads account are identified | Account map |
| Correct tag | Google tag and IDs match the intended systems | Published version and Tag Assistant or preview |
| Form success | Valid submission produces one intended event and reaches the receiver | Preview, backend, CRM, or inbox record |
| Form failure | Invalid or abandoned submission does not become a lead | Validation test |
| Calls | Number, source, and call path are correct | Test call and call-system record |
| Call quality | Provisional qualification rule is documented | Call review or business record |
| Conversion action | Name, source, primary or secondary role, count, value, and window are intentional | Google Ads settings |
| Deduplication | One business action is not counted through multiple paths | Event and conversion comparison |
| Consent | Tags respond correctly to consent states | Regional and consent test |
| Identifiers | GCLID or supported source data survives where needed | Test lead record |
| CRM | Lead and source can be reconciled | CRM record |
| Offline outcome | Later job or revenue record can be linked where configured | Import or matching report |
| Documentation | Version, date, owner, and known limitations are recorded | Tracking change log |
Screenshots are supporting evidence for individual checks. They are not the proof that the chain works end to end.
A pre-launch test is not the final audit. Review the live chain after real traffic has passed through it, and do not treat a status label in the interface as confirmation on a fixed timetable, check the receiving system.
Look at whether platform conversions match receiving-system records, whether call or form quality is changing, whether consent is reducing the observable count, whether duplicates appear after website changes, and whether booked or completed outcomes are arriving late.
Do not change three layers at once. Record the hypothesis, the change, the date, the expected effect, and the verification result.
The Profit Ledger
Tracking does not create profit. It creates the possibility of seeing where the money went. I count conservatively. Every untracked job is your upside, not my credit.
A checklist can only find what it tests. When a box cannot be ticked, the conversion tracking audit works the failure in order, or ask for the free audit and I will run it against the account directly.
Define the business outcome before installing the tag. Then test whether the event fires at the correct moment, reaches the receiving system, is attributed where possible, avoids duplication, respects consent, and reconciles with the business record.
No. It may be an attempt. A lead event should represent a successful submission or another business-defined contact action. Google Tag Manager's Check Validation setting can help with traditional form submissions, but custom or AJAX forms may need a different success signal.
No. Import only events whose definitions and optimisation roles are understood. Google says imported Analytics conversion actions created through the Analytics interface are secondary by default and may require a deliberate setting change if they should be used for bidding.
Only if a phone click is the business outcome the campaign can reasonably optimise toward. A click is not a connected call, a qualified enquiry, a booking, or a completed job.
There is no universal threshold. Use a provisional duration alongside call review and business records, then compare it with qualified enquiries and booked jobs. Duration alone is a proxy, not a quality measure.
Not for every campaign. It can be useful in some privacy, performance, or data-control designs, but the business should first have clear event definitions, reliable capture, lawful consent behaviour, source continuity, and a reconciliation process.
Possible causes include different event definitions, attribution, time zone, counting, consent, imports, reporting delay, conversion windows, filters, and modelled data. Investigate the definitions and settings before replacing the implementation.
Capture a source identifier or a reliable contact record, define the booking milestone, store the outcome in the CRM or business system, and import or reconcile later outcomes where the data and consent design support it. A platform form event alone does not prove a booked job.
Audit before launch, after material website or CRM changes, after a tag or conversion-setting change, and periodically during live campaigns. The frequency should reflect traffic, complexity, risk, and the business's tolerance for measurement error.
Start here
Send what you have. A missing number is not a blocker. Working it out is part of the audit. No contracts, ever. I reply within 12 hours.
Send the numbers
Spend, leads, and what you suspect is going wrong. I reply within 12 hours.