What is Conversion?

A conversion is an event an account configured itself to count. That is the whole definition, and the word hides how much is being chosen rather than observed.

In one account a conversion is a completed purchase. In another it is a form submission, a phone call over a threshold length, a chat opened, an app install, a page view on a thank-you URL, a file downloaded, a video watched, a quote requested, or a box ticked. All of them produce a number called conversions, and none of those numbers can be compared with each other.

This is not a reporting quirk. The conversion definition is the instruction that every automated part of an account follows, and it is followed exactly.

Bidding. A conversion-based strategy finds people likely to produce the nominated event. Nominate an add-to-cart in a business that sells things and the account will fill with people who add to carts and leave.

Reporting. Cost per acquisition, conversion rate, return on ad spend and every ratio built from them inherit the definition. Two accounts reporting different figures are usually counting different events.

Budget. Money follows the reported performance, so a badly chosen conversion moves real money toward activity that does not produce revenue.

Creative decisions. Which ad "won" is decided by which produced more of the counted event.

An account can have excellent targeting, sound bidding, strong creative and a conversion definition that points at the wrong thing, and every one of those strengths will be applied to producing the wrong outcome efficiently.

The tension is between representativeness and volume.

Deeper events represent the business better. A purchase is what the business wants. A qualified lead is close. A form fill is a proxy. A page view is almost unrelated.

Shallower events occur more often, which matters because a bidding model needs examples and a thin account cannot supply them at the deep end.

The working rule is to optimise on the deepest event that clears the platform's own volume threshold, and to revisit the choice as the account grows. An account producing four hundred registrations a week should not still be buying installs because it was set up that way two years ago.

Where the deep event is too rare, two moves help. Optimise on a shallower event and send the deeper one back as a signal the model can learn from over time. Or narrow what counts as the shallow event — a lead that answered the phone rather than any lead — so the proxy is closer to the outcome.

Most platforms distinguish the actions that drive optimisation from the actions merely recorded, and the distinction is worth using deliberately.

Counting many events is useful. It shows the funnel, catches drop-off, and provides the diagnostic detail that explains why the primary number moved.

Optimising toward many events is not. It tells the bidder that a newsletter signup and a sale are worth the same, and it will buy the cheaper one, which is always the signup.

An account with six actions in its primary set is not optimising for conversions; it is optimising for whichever of the six is easiest to produce.

Where conversions are worth different amounts, counting them equally discards the information that matters.

Sending a value with each conversion changes what a value-based strategy pursues, and the quality of that value decides what the campaign buys. Revenue is adequate where margins are even. Profit is better where they are not, because a model given revenue in a mixed-margin catalogue will find high-revenue, low-margin orders.

Even in lead generation, where every lead looks identical at the moment it arrives, a value can be attached later — a lead that reached a sales conversation, a lead that closed, a lead whose contract was large. Sending those back is the single most effective improvement available to most lead accounts and it requires no change to the advertising at all.

The conversion count is a measurement and measurements break quietly.

Duplicates. A tag firing twice halves the reported cost per acquisition. Nothing looks wrong; the account simply appears to have improved.

Gaps. A tag removed in a site deployment, a consent banner that blocks it, a checkout flow that changed. Reported performance collapses and the campaigns are fine.

Definition drift. A thank-you page reused for something else, a form repurposed, an event renamed. The count continues and means something different.

The defence is reconciliation against the system that actually holds the record — the order table, the CRM, the billing system — on a routine rather than in response to a surprise. Comparing against another advertising platform is not reconciliation; both are claims.

Before any bidding change, any budget argument and any creative test, the question is what the account is counting and whether that is what the business sells.

It is asked far less often than it should be, because the conversion definition is set once during implementation, frequently by somebody who has since left, and then inherited as a fact about the account rather than as the decision it was.

The same event can be reported by several systems and they will not agree.

A browser-side tag fires when a page loads or a button is clicked. A server-side event is sent by the advertiser's own systems when the order is actually recorded. A platform's modelled figure estimates conversions it could not observe. An offline import sends back what the CRM later confirmed.

Each has different coverage and different failure modes. Browser tags lose consented-out visitors, blocked scripts and in-app browsing contexts. Server events are more complete and depend on an integration nobody notices when it breaks. Modelled figures fill gaps with estimates that cannot be reconciled line by line. Offline imports are the most accurate and the slowest.

The account does not have to choose one, and it does have to know which is feeding the bidding and which is feeding the reporting. A campaign optimising against browser events while the business reports from the order table is two different conversion counts being used for two different decisions, which is workable as long as somebody knows it is happening.

Four questions, answerable in an afternoon, that catch most conversion problems.

What event is primary, and is it what the business sells?

How many actions are in the optimisation set, and would the bidder be happy buying the cheapest one?

Does the count reconcile with the order table or the CRM for last month?

Is a value attached, and does it reflect what the conversion is worth rather than what it billed?