Articles · Analytics
Google Ads conversion tracking setup: Reconcile Ads, GA4 and CRM
A campaign dashboard says enquiries increased. The CRM shows fewer usable leads. Finance cannot connect the reported conversion value to booked revenue. Before changing bids or replacing the landing page, establish whether those systems are counting the same thing.
A dependable Google Ads conversion tracking setup needs more than a tag that appears to fire. It needs an agreed business definition, a controlled collection path, documented reporting settings and a way to explain discrepancies without forcing every dashboard to match.
This manual treats tracking as a reconciliation problem: follow the business outcome from its operational record to its advertising report, then account for every material difference. The aim is not a reassuring screenshot. It is a measurement system that makes budget decisions more defensible.
Open a reconciliation file before touching tags
Create a shared working document with four sections: business definitions, implementation map, test evidence and unresolved differences. Give it an owner and a revision date. Keep restricted customer records outside this document; use aggregate counts and non-identifying test references instead.
Start with one question: What decision will this conversion support?
A submitted enquiry may support an initial acquisition decision. A sales-qualified opportunity supports a different decision about lead quality. A completed purchase supports a revenue decision. Combining these outcomes into one undifferentiated total makes that total harder to interpret.
Record which system is authoritative for each fact. The application database may confirm that a submission was accepted. The CRM may confirm qualification. The order system may confirm payment status. Google Ads provides the advertising measurement view. None should silently substitute for the others.
Google describes Performance Max as goal-based and explains that conversion goals and values guide its optimisation. That makes choosing the right outcome a campaign input, not just a reporting preference. See .
This article is about that measurement foundation. It does not cover acquisition strategy, landing-page persuasion, checkout usability or email recovery. Those activities can change customer behaviour; reconciliation establishes what your measurement system recorded about that behaviour.
Write the conversion contract
Before creating or editing a conversion action, write its contract in plain language. Another person should be able to apply the definition without asking what you meant.
For each outcome, specify:
- Business event: The real-world action being measured.
- Acceptance condition: What must happen before it counts.
- Exclusions: Failed attempts, tests, spam or other non-outcomes.
- Repeat rule: Whether another occurrence represents another valuable outcome.
- Value basis: Actual transaction value, a documented estimate or no monetary value.
- Operational evidence: The system that confirms completion.
- Campaign role: Whether the outcome should guide optimisation or only provide diagnostic context.
Lead generation: separate acceptance from qualification
A sensible proposed definition for an enquiry is “a submission accepted by the application and recorded for follow-up.” A button click is evidence of an attempt, not necessarily acceptance. A confirmation message is useful only if it reliably corresponds to a successful operation.
Define qualification separately. For example, a hypothetical SaaS business might require a supported use case and a verified sales review before calling an enquiry qualified. That is a proposed business rule, not a Google requirement.
Keep the two stages visible. Otherwise, a campaign could appear successful because it creates many initial submissions while the sales team evaluates a much smaller usable pool.
Commerce: define the financial boundary
For purchases, state whether completion means order creation, payment authorisation, payment capture or another operational milestone. Decide how cancellations, returns, delivery charges, discounts and taxes should appear in management reporting.
Do not call an order-total field “profit.” Do not describe a modelled lead value as collected revenue. If your financial treatment differs from the value sent for advertising measurement, document the bridge between them.
The contract should also distinguish another purchase from another notification about the same purchase. Repeated browser actions and repeated backend notifications belong in the test plan, not in an assumed revenue uplift.
Map one collection route for each outcome
Draw the proposed path before implementing it:
Business confirmation → measurement signal → collection route → conversion action → campaign reporting → reconciliation.
For each arrow, identify the responsible system and owner. This exposes gaps such as a developer assuming the marketing team receives a success event while the marketing team assumes a confirmation page proves success.
Audit the existing installation first. Inspect site code, tag-management containers, platform integrations and any server-side measurement service. Ask who installed each component and whether it is still required. Do not remove unfamiliar tracking until its purpose and dependencies are understood.
If the account offers both a website-tag route and a linked analytics route for the same outcome, compare the available options and their current documentation. Choose a clearly identified production route rather than enabling everything because it is available.
A second route can support a controlled comparison, but the comparison needs a purpose, an owner and an end condition. Do not allow two representations of the same event to become an unexplained combined business total.
Record the configuration you actually find. Avoid assuming that an action’s name tells you how it is collected or used. “Purchase” could be an old integration, a current action or a misleading label left behind after a migration.
For the broader website instrumentation layer, the is the adjacent implementation topic. Here, the central question is whether the resulting advertising measurement represents the agreed outcome.
Configure from the contract, not from default labels
Use the account’s current conversion-management interface and . Interface labels and available routes should be verified in the account rather than copied from an old screenshot.
Work through the setup in this order.
1. Identify the destination
Confirm the intended Ads account, website and collection route. Capture the destination identifiers provided by the selected setup method in a restricted implementation record.
Where a linked analytics property is involved, verify the property and relevant data source. Similar account names are not sufficient evidence that the destination is correct.
2. Create or select the intended action
Use a name that communicates the business stage and collection route. An internal naming convention such as Lead | Accepted | Website is more useful than Conversion 2.
Check existing actions before creating another. If an existing action is being replaced, write down when its replacement starts and how reports spanning that date will be interpreted.
3. Review the settings that change interpretation
Inspect the available controls for counting, value, attribution, measurement windows and campaign goals, using . Record their actual settings and compare them with the conversion contract.
For controls labelled primary or secondary, inspect their current meaning and campaign use rather than treating the label as sufficient proof. Also review campaign-specific or custom goal selections where present. The practical question is which actions the campaign is actually configured to pursue.
Where the interface offers choices such as counting one or every conversion, consult the current explanation before selecting a rule. Do not assume “one” means one unique person across your CRM.
4. Implement the confirmed-success signal
Ask the developer to expose a reliable success condition from the application. Define the measurement signal around that condition, not around the visual location of a submit button.
For an asynchronous form, test whether the proposed trigger distinguishes a successful response from a validation error or server failure. For a purchase, verify the signal against the agreed order or payment milestone.
5. Review the payload
Maintain a field-level specification: field purpose, source, expected format, whether it is optional and whether it is permitted to leave the application.
Use only the fields supported by the selected implementation method. If transaction references are required, prefer opaque operational references and review their privacy implications. Never substitute an email address for an order reference.
6. Publish with a rollback record
Save the previous configuration, identify the release owner and record the deployment time. Note which actions or integrations were enabled, disabled or changed.
A release without a change log is difficult to reconcile later. When a discrepancy appears, you need to distinguish changed customer behaviour from changed measurement.
Put consent and data minimisation into the design
Consent is not a final banner check after implementation. Establish which collection is permitted in each relevant jurisdiction, how the site records choices and how those choices should affect the selected measurement route.
Translate those requirements into acceptance tests with the privacy owner and developer. Test the relevant states, including an initial visit, a declined choice, an accepted choice and a changed choice. Record expected behaviour for each state rather than assuming all visitors should produce identical measurement records.
Do not send names, email addresses, telephone numbers or free-text enquiries in ordinary analytics events. Inspect page addresses, event parameters and dynamically populated fields for accidental disclosure. A harmless-looking field name can still contain personal information.
If enhanced conversions are being considered, make them a separate privacy and implementation workstream. Verify current Google requirements, permitted data handling, eligibility and consent obligations before enabling them. Hashing should not be treated as permission to collect or transmit data.
Keep any customer-level reconciliation inside appropriately restricted systems. A spreadsheet shared with a marketing vendor should not become an uncontrolled copy of the CRM.
Finally, do not “fix” a consent-related measurement limitation by bypassing a visitor’s choice. The reporting limitation belongs in the reconciliation notes and decision context.
Test the business event, not just the tag
A useful acceptance test has three pieces of evidence: what happened in the application, what the measurement layer attempted to send and what the receiving system subsequently made available for inspection.
Those are separate observations. A debugging screen alone does not establish that an advertising report should contain a credited conversion. Equally, a dashboard increase does not prove that a particular implementation path is correct.
Use a test register like this:
These are proposed test cases, not statements about automatic platform protections. Do not assume a repeated identifier or a counting setting will correct a duplicate signal in every route. Test the chosen implementation and verify its documented behaviour.
Also test navigation that changes the implementation context: an external booking tool, a payment provider, an embedded form or a separate confirmation domain. Assign ownership for every boundary. If a third-party tool cannot expose reliable completion evidence, record that limitation instead of presenting a click to the tool as a completed booking.
Use the diagnostics available for the selected route and account. Follow current guidance on processing expectations rather than declaring failure after an arbitrary waiting period. Avoid repeatedly clicking live ads simply to test website behaviour.
Reconcile with a bridge, not a single percentage
Before comparing totals, align their scope. Write down the date range, time zone, business event, status filters, traffic population and reporting date basis for each extract.
Then inspect attribution settings, eligible measurement windows and any documented modelling or reporting treatment relevant to the selected reports. Confirm these from the current product documentation and account configuration; do not assign every unexplained difference to “attribution.”
Most importantly, compare like populations. All accepted website enquiries are not automatically equivalent to outcomes credited to Google Ads. CRM qualification is not the same event as form acceptance. Net revenue is not necessarily the same measure as the value attached to an initial purchase signal.
Hypothetical lead reconciliation
Suppose a business has 120 submission records in its operational system during a defined period. Its documented review finds 10 internal tests and 10 repeated submissions that do not represent additional enquiries. That leaves 100 accepted enquiries under its business definition.
The CRM records 72 as sales-accepted and 28 as unsuitable or awaiting review. Separately, a Google Ads report shows 64 conversions for the relevant action.
The difference between 100 and 64 is not automatically 36 missing tags. The first total covers accepted enquiries in the operational system. The second comes from an advertising report whose population and settings still need examination.
Build the bridge in stages:
- Confirm which of the 100 accepted enquiries had a valid success signal.
- Inspect whether the approved collection route handled those signals as expected.
- Identify which records can legitimately be investigated within the advertising measurement scope, using permitted data.
- Align report dates, action filters and documented settings.
- Leave unresolved or unobservable differences explicitly labelled.
These numbers are illustrative, not benchmarks. The exercise demonstrates why subtracting two totals is only the beginning of diagnosis.
Hypothetical revenue reconciliation
Suppose 40 accepted orders total ₹200,000 at the agreed purchase milestone. Later, cancellations and returns reduce recognised revenue to ₹175,000. A report using the original purchase values and a finance report using adjusted revenue now answer different questions.
The ₹25,000 difference should first be assigned to the documented financial adjustment. Only the remaining unexplained difference belongs in a tracking investigation.
If changes need to be reflected in advertising measurement, assess the currently supported adjustment process for the selected route. Do not assume editing the commerce database automatically updates every downstream report.
Use discrepancy patterns to choose the next investigation
When advertising conversions look too high
Start by separating actions. Look for multiple representations of the same outcome, obsolete actions, weak success definitions and diagnostic events included in the business total.
Inspect confirmation-page reloads, repeated success callbacks and overlapping installations. Compare operational outcomes with emitted signals in a controlled test. Do not disable all tracking simply because the aggregate looks inflated; isolate the responsible route first.
When advertising conversions look too low
Test whether accepted outcomes produce the intended signal across devices and completion routes. Check destination configuration, deployment coverage, consent behaviour and third-party boundaries.
Next, inspect report scope and current processing guidance. A smaller advertising total is not proof of missing collection. If the comparison uses all-channel outcomes, correct that comparison before rewriting tags.
When counts look credible but values do not
Check the value source, currency, units and financial definition. Inspect a sample of permitted test orders from operational value through to the outgoing payload.
Look for stale fixed values, inconsistent handling of discounts or taxes, and differences between gross and adjusted revenue. Test decimal formatting explicitly rather than trusting a formatted amount displayed on the page.
When platform leads rise but sales acceptance falls
Verify measurement first, then inspect the quality-stage definition and CRM process. Did qualification rules change? Are records awaiting review? Is the campaign pursuing an early action that is easier to produce than a useful enquiry?
Only after those checks should the team treat the pattern as an acquisition problem. The addresses that next decision layer; a cheaper reported lead is not inherently a better commercial result.
Decide what is safe to use for optimisation
Treat a conversion action as a candidate for optimisation only after its definition, collection, privacy handling and campaign role have been reviewed.
Prefer an outcome that represents genuine business progress. However, a later-stage outcome also requires a dependable operational process. If CRM qualification is inconsistent or rarely updated, calling it a better signal does not make its data trustworthy.
An earlier accepted-enquiry event may be the more usable starting point while the downstream workflow is repaired. Keep the limitation visible and measure sales acceptance alongside acquisition cost. Do not inflate estimated values to make return metrics look stronger.
Avoid changing the success event, its value basis and campaign settings simultaneously unless there is a compelling operational reason. Otherwise, subsequent changes become harder to interpret.
A repaired setup can change reported performance without changing customer behaviour. Annotate the release and explain the discontinuity. A before-and-after dashboard comparison is not causal proof that the repair improved acquisition.
How Anurag would deliver the reconciliation work
Through his , Anurag would approach this as a scoped measurement engagement rather than a promise to make every platform display the same number.
Inputs: He would request appropriate account access, the existing conversion-action inventory, website and form architecture, consent requirements, CRM stage definitions, order-value rules and aggregate discrepancy examples. Access would be limited to what the investigation requires.
Actions: He would map the operational outcome to each collection route, review campaign goal usage, inspect available diagnostics and reproduce representative journeys. With the developer and privacy owner, he would specify corrected triggers, permitted payloads and acceptance tests. Proposed changes would include a release and rollback plan.
Outputs: The deliverables would include conversion contracts, an implementation map, a settings register, test evidence, a discrepancy bridge and an unresolved-issues log. Any recommended downstream lead-quality measurement would have explicit ownership and operational prerequisites.
Measurement: Acceptance would be assessed against the agreed tests and definitions: whether failures are excluded, valid outcomes produce the intended signals, repeats follow the contract, values match their stated basis and consent behaviour matches the approved design. Remaining differences would be classified as explained, unresolved or not observable with the available permitted data.
The commercial value is a clearer basis for campaign decisions. It is not a guarantee of lower acquisition costs or complete visibility into every customer journey.
Close the file with an operating decision
Finish reconciliation with a short decision record: which action is trusted, what it represents, which campaigns use it, what limitations remain and who owns the next review.
Reopen that record after a form replacement, checkout release, consent change, CRM migration, integration update or conversion-setting change. Attach new evidence rather than relying on an old “tracking works” message.
If the current setup cannot explain the journey from accepted outcome to reported conversion, with the business event, affected systems and a non-identifying description of the mismatch.
The final acceptance question is simple: Can the team explain what this conversion number means well enough to act on it? Matching totals may help, but an auditable explanation is the stronger foundation.
Source
- - supports the discussion of goal-based campaigns and the role of conversion goals and values in optimisation. The reconciliation contracts, test register and delivery process above are recommended operating practices; account-specific implementation options should be checked against the current instructions for the selected measurement route.
- - current official setup reference.
- - current official settings reference.