Google has opened a beta that lets advertisers attach a second data source to an existing website conversion action, pulling transaction records from CRMs, order databases, or ecommerce platforms alongside the signals already collected by Google tags.

The mechanic is additive. A conversion action you already run for bidding and reporting stays intact. The backend data feeds into that same action through Google Ads Data Manager or the Data Manager API. Tag measurement continues as normal.

Google says the setup recovers conversions that browser restrictions, privacy settings, or ad blockers prevented the tag from capturing. Those recovered events then flow into Smart Bidding alongside tag-confirmed conversions, which is the practical upside for PPC teams: the bidding algorithm sees a fuller signal set without requiring a new conversion action.

What qualifies

The beta applies to a narrow scope:

What each upload must contain

Every record sent from the backend must include a transaction ID and a conversion date and time. At least one attribution identifier is also required: either hashed customer information or a Google click identifier.

Google deduplicates using transaction IDs, matching backend records against tag-fired events within the same conversion action to prevent double-counting. That deduplication is Google’s stated mechanism. It has not been independently verified at scale.

Three operational rules Google recommends

Google recommends adding the data source to an existing conversion action rather than creating a new one. Creating a new action for this purpose introduces double-counting risk because the same conversion would then appear in two separate actions. Google also recommends uploading records as quickly as possible after a conversion occurs, and matching the currency format the website tag already uses. Mismatched currency formats are a documented failure point in enhanced conversions uploads and will likely cause similar problems here.

Where this sits in the measurement stack

This is not a replacement for tagging. Google is explicit on that point. The intent is resilience: a tag fires when it can, the backend upload fills gaps when it cannot. The two streams reconcile at the transaction ID level.

For measurement teams, the implication is that data quality upstream now shapes bidding quality downstream. A backend dataset with inconsistent transaction IDs, missing timestamps, or currency format drift will degrade the signal rather than strengthen it. The supplemental data amplifies whatever accuracy exists in your order system.

For PPC teams managing Performance Max or automated bidding strategies, cleaner conversion counts translate to better cost-per-acquisition targeting. Recovered conversions that were previously invisible to Smart Bidding become part of the training signal. That is the concrete value case Google is making.

What to do in the next 90 days

If your organization has clean backend transaction data with reliable transaction IDs, this beta is worth piloting against a high-volume conversion action. Audit your order database or CRM export for ID consistency and currency format alignment before connecting it. Start with one conversion action that already has stable tag performance so you have a baseline to compare against. Teams without clean transaction IDs should fix that infrastructure first. Attaching messy backend data to a bidding-optimized conversion action will produce noise, not recovery.

Search Engine Land reported this development on June 18, 2026, in a piece by Paid Media Editor Anu Adegbola.