Google Ads counted three conversion actions on one lead. Target CPA optimised to the sum

There is one number on the campaign overview that everything else is judged against. Cost per conversion is spend divided by it. Smart bidding sets every bid to hit a target expressed in it. Clients ask about it by name. It is the Conversions column, and in most accounts almost nobody knows what it is made of.

We pulled it apart for a mid-sized search account. Over eleven days the account reported 251.9 conversions. Here is what they were.

Six actions. Two of them fire on the same web form submission. One of them is the same person, days later, once someone in the office has marked them as worth calling back. One human filling in one form could register three times.

Why two actions on one form

The web form has two conversion actions on it because the tracking was built in two different eras.

Both are primary. Both count. Nobody retired the old one when the new one went live, and because the two actions have different names, the interface shows them as two different things.

The GA4 action counts roughly three times as many as the Ads-tag action, 77.4 against 25.0, which seems to contradict the idea that they fire on the same event. The gap has a specific cause, which the next post in this series covers: the GA4 event was set to count every pageview of the thank-you page, and the thank-you page could be reached by anyone, including on refresh. The Ads tag was set to count once per click. Same page, different counting rules, wildly different totals.

Why the CRM upload is a third count

The third action is an offline conversion import. Someone in the business exports leads, marks the ones that were real, and uploads them back to Google Ads matched by click ID. That's good practice. It tells the platform which leads were worth having.

But it was configured as a primary action, in the Qualified lead category, which the campaigns were set to bid on. So a person who submits the form (count one, GA4), whose submission also fires the old tag (count two), and who is later uploaded as qualified (count three) contributes three conversions to the number smart bidding is chasing.

What it looks like at campaign level

One campaign, thirty days, 33 conversions in the column:

The unique lead events are the web form submissions (14) and the phone calls (5). The Ads-tag count is a subset of the GA4 count. The qualified-lead count is a subset of everything above it. So the plausible unique-lead figure is 19, not 33, an inflation factor of about 1.7×.

What that does to smart bidding

That campaign had just been moved to Target CPA with a $150 target. The algorithm sets bids to achieve $150 per conversion as counted in the column. If the column is inflated 1.7×, then:

Nobody set a $260 target. It emerged from the counting. And it's invisible on every report, because every report divides by the same inflated number.

There is a trap on the other side too. Fix the counting and the column drops from 33 to ~19, which puts the campaign under the ~30 conversions per 30 days that Target CPA wants to work properly. You can fix the accuracy and break the bidding in the same move. That's not a reason to leave it broken; it's a reason to fix it deliberately, one action at a time, with the target adjusted alongside.

The API will tell you the wrong thing

If you audit this through the Google Ads API rather than the interface, there is a specific trap.

The CRM upload action returns this:

Read the fifth row and you'd conclude this action is not counted in the Conversions column. We did, initially. It is counted. primary_for_goal is the field that decides under the goals-based conversion system Google moved to in 2022; include_in_conversions_metric is the legacy flag and it no longer governs.

We proved it the only way that's conclusive:

Every action in the segmented list, including the one flagged include_in_conversions_metric = false: is inside the unsegmented total. If you're building an audit script, do not filter on the legacy flag. Filter on primary_for_goal, and then confirm by summing.

How many actions the account actually had

Before any cleanup, the account carried 27 live conversion actions. Twelve were archived in the first pass. Some of what was in there:

Four of the twelve were marked primary. Every one of those had been contributing to the column and to the bid strategy's learning.

This is what happens over nine years and several agencies. Every migration adds actions; nobody removes the old ones because nobody is sure what depends on them. The column becomes an archaeology.

The fix, in order

Do these one at a time. Each change moves the number smart bidding is learning from, and moving several at once makes it impossible to tell which one did what.

Step 3 is a genuine strategic choice, not a bug. Bidding to qualified leads instead of raw leads is arguably what most businesses actually want. But it means far fewer conversions per month, and the campaign has to be able to survive that. Decide it consciously.

How to check your own account

Ten minutes, standard interface:

1. Campaigns → Segment → Conversions → Conversion action. You now see the column split by action.

2. Tools → Conversions. Note which actions are marked Primary.

3. For every pair of primary actions, ask: could one person trigger both? Same form, two tags. A form and a later CRM upload. A call from the ad and a call from the website number, if the same person does both.

4. If the answer is yes, one of them shouldn't be primary.

The principle

Cost per conversion is a ratio. Everyone scrutinises the numerator, spend, because it arrives as an invoice. Almost nobody scrutinises the denominator, because it arrives as a number in a column with a reassuring name.

The denominator is a sum of things someone configured, at some point, for some reason. It is only as honest as the least honest thing in it. Pull it apart before you optimise toward it.