Does Google Ads Backfill a GA4 Conversion Imported After the Click? In One Test, Yes

The question

On a recent project, a booking site on WordPress, the Google Ads account had a stale purchase conversion action and the GA4 property had a working purchase key event. The plan was simple: delete the stale Ads action and import the GA4 key event in its place.

Between fixing the tracking and creating the import, a booking came through from a paid click. So: does that booking ever arrive in Google Ads against the new conversion action, or is it gone?

This is a decision, not a curiosity. Anyone who has inherited a broken or stale conversion setup faces the same fork: fix it now, mid-month, mid-flight, or wait for a clean start date on the assumption that everything in the gap is lost. The assumption is the load-bearing part, and I could not find it addressed clearly anywhere. Here is what happened in the one case I can report, stated as one case throughout.

The setup, briefly

The conditions are what make the result interpretable, so, briefly:

• The underlying tracking was fixed first. The site's tracking plugin was repaired and verified with a small card test transaction before any Ads configuration was touched, so the purchase event was known to fire with the right value.
• A real booking then arrived from a natural paid click. The payload carried a click ID, a valid session ID, and consent was granted. A clean conversion by every criterion except one: the import that would carry it to Google Ads did not exist yet.
• The legacy Google Ads purchase conversion action was deleted.
• The GA4 purchase key event was imported as a new Ads conversion action, after that booking had already happened.

To state the variable plainly: the conversion occurred first, and the import was created afterwards. Everything else about the chain was healthy.

The result

The booking appeared in Google Ads against the newly imported conversion action, at a value that matched the GA4 event value exactly. Google Ads backfilled a conversion into an import that did not exist when the conversion happened.

What that does and does not establish:

• Observed once, on one account, with a click ID present, and with a short window between the conversion and the import.
• Not documented vendor behaviour, as far as I can find, and not a promise about how far back the reach extends.
• The lookback that matters is the conversion window on the action. Nothing in this test supports assuming an arbitrarily long one.

Two readings of that list are available. The optimistic one: fixing the setup mid-flight did not cost the conversion in the gap. The cautious one: a single observation under favourable conditions is a reason to stop assuming the data is lost, not a reason to assume it is safe. Both readings point the same way on the actual decision, which is the useful part: neither supports waiting for a clean start date.

The trap worth more than the answer

The same account held a second finding, and it is the one I would send to a colleague.

The conversions list included an action named as though it were the Ads purchase action. Opened up, it was nothing of the sort. It was a synthetic GA4 event: a page view where the path started with the thank-you page. It was not tied to purchase data at all. Anyone reading the account list would conclude purchase tracking existed. What existed was a thank-you page proxy. This was inherited configuration, the kind of thing that accretes in any account that has passed through a few hands, and it matters for three reasons:

• It counts page views, not transactions. Refreshes, bookmarks, back-button revisits and direct hits to the confirmation URL all count as purchases.
• It carries no order value, so value-based bidding has nothing real underneath it. A target ROAS strategy pointed at it is steering on a number that means nothing.
• It looks correct in the conversions list, which is where most audits stop. The name says purchase, the column has numbers in it, on to the next thing.

A proxy like this is rarely anyone's mistake in the moment. It is usually sediment: at some point somebody needed purchase numbers before a real ecommerce event existed, the thank-you URL was the quickest route to a number, and the workaround outlived whoever knew it was a workaround. That is exactly why opening each action beats reading its name.

The hygiene step that followed: the legacy contact action was moved from primary to secondary, leaving the imported GA4 purchase as the only primary conversion action. Primary is what bidding optimises to. Everything else belongs in secondary, where it still reports but no longer steers, so nothing is lost by demoting it. Two overlapping primary actions recording the same underlying event is how double counting starts, and double counting in the primary column is bidding on fiction.

What to check if you are doing this

1. Verify the underlying event fires with the right value before touching any Ads action. Reproduce it yourself with a real transaction, not a debug preview.
2. Check whether an existing conversion action is a real event or a URL proxy. Open it, do not read its name.
3. Check whether a native Ads tag and an imported GA4 event are both live for the same action. That is a dedupe problem waiting to happen.
4. Confirm the value in Ads matches the value in GA4 to the penny, not approximately. Approximate agreement is how value bugs hide.
5. Expect the new action's reporting history to start empty even if individual conversions backfill, and do not read that gap as a failure.
6. Decide which action is primary before you switch bidding strategies, not after.

Fix it now, not at the month boundary

The clean start date is a comfort, not a strategy. The reason to fix a stale conversion setup now rather than waiting for a tidy month boundary is that the data in the gap may not be lost, as this one case shows, while the cost of running bidding against a proxy for another fortnight is certain. One of those risks is speculative. The other is on the invoice. Verifying this kind of chain end to end, from the event on the site to the value in the Ads column, is the core of my tracking and measurement work.