Google Ads reports more purchases after you connect backend order data. Before raising spend, check when that source becomes eligible for bidding and whether its order values agree with your records. Google’s multi-source conversions beta has a 14-day trial; a higher reported total during that period does not establish that advertising created more customers.
Put the transition on the calendar
Google’s multi-source conversion guidance covers coded website conversion actions using the Google tag or Google Tag Manager. Imported Google Analytics conversions and URL-based actions are excluded. Availability is still limited by the beta, so check the action and account before planning an implementation.
The FAQ describes the changeover: existing tag conversions remain eligible for bidding during the trial. The additional source contributes to reporting and diagnostics, then its conversions automatically become biddable after 14 days.
Record the connection time, expected transition, responsible person, and an earlier decision meeting. Treat that meeting as a deadline for resolving discrepancies. Do not assume the reporting period lasts until someone chooses to end it.
Check which source owns the value
Google matches transaction IDs within the same conversion action. It does not deduplicate two separate actions. After the trial, an uploaded value can replace the tag’s value for a matched purchase. Value updates are disabled during the trial, so an unchanged value then is not evidence that the later overwrite will be correct.
Compare currency and units as well as totals. Define whether your purchase value includes discounts, shipping, taxes, cancellations, or refunds, and keep that definition attached to each source. A finance export can be accurate for its own purpose while still being the wrong input for the purchase value you intend to use.
Keep the paid-order definition and reporting window attached to that check. The browser and server-side paths can observe the same action without answering the same reporting question.
Google documents row-level consent fields and account defaults for missing consent data. Have the responsible owner check those mappings against the permitted data use before connecting a source. A backend record is not permission to send it.
Bring one conversion-source record to the decision
Use this record for the conversion action under review. It is a way to expose unresolved differences, not a score that certifies a setup.
Record | Evidence and decision |
|---|---|
Action and timing | Evidence to bring: Action identity, beta availability, connection time, trial end, review owner Decision it supports: Is this the intended purchase action, with time to correct a problem? |
Order identity | Evidence to bring: A small sample traced from paid order to tag and upload; exceptions and duplicate-action checks Decision it supports: Are both paths describing the same purchase? |
Value ownership | Evidence to bring: Currency, units, value definition, refund handling, and expected replacements Decision it supports: Is the source that will replace values fit for that job? |
Permissions and delivery | Evidence to bring: Consent mapping, source permissions, upload schedule, rejected rows, diagnostic alerts Decision it supports: Are missing or invalid rows explained? |
Commercial baseline | Evidence to bring: Paid orders, new-customer definition, returns-adjusted revenue, media spend, and relevant costs for a consistent period Decision it supports: What business change would justify a spending decision? |
Unresolved action | Evidence to bring: Named owner, correction, verification step, and next review time Decision it supports: What must be resolved before relying on the new input? |
Start with ordinary orders and known edge cases. Add examples when an exception reveals a different failure mode. A smaller brand does not need an elaborate dashboard to discover that one path sends a different order identifier or treats refunds differently.
Work through a discrepancy before scaling
Consider a synthetic example. Your tag records a paid order as 125.00 USD. The proposed upload contains 12500 with the same transaction ID and currency because the export stores cents. The two records refer to the same order, but their units disagree. Correct the mapping and verify a fresh sample before trusting it as a bidding input. Extra reported purchases elsewhere do not cancel out that error.
Now suppose identifiers and values agree, yet reported conversions rise while paid orders remain steady. Recovered observation is one possible explanation. Attribution timing, delayed uploads, and a changing mix of new and returning customers are others. Track them separately; none requires pretending the extra reported conversions are new sales.
If paid orders or contribution also deteriorate, investigate that business change. Promotions, inventory, creative, spend, and traffic mix can move at the same time as the connection. A clean data sample cannot dismiss those alternatives.
Leave with a decision and a way to revise it
Unexplained identifiers, values, permissions, or diagnostics mean the setup needs correction. If the transition is approaching, escalate to the account owner and resolve the available source or goal controls before the deadline; do not assume an automatic pause exists.
When the input checks pass, keep the source review separate from the budget review. Use consistent paid-order and cost definitions to assess affordability. A before-and-after rise in platform ROAS cannot isolate the effect of the connection.
Revise the measurement-only explanation if commercial deterioration persists in comparable periods or a reproducible purchase-path failure appears. To claim that the added feedback created incremental customers, design a comparison that measures that outcome. The first decision is whether the input is trustworthy enough to inform bids; the next is whether those bids earn acceptable business results.
