What is a conversion signal and why algorithms need them
Written by The Pixamp Team
PixampModern ad platforms do not really bid on clicks. They bid on predictions about who will convert, and those predictions are only as good as the events you feed back.
What is a conversion signal?
A conversion signal is an event you report back to an ad platform to tell it a specific outcome happened: a purchase, an add-to-cart, a lead form submit, a subscription. It is the ground truth the delivery algorithm trains on.
Every signal carries two things. First, the fact that the outcome occurred. Second, enough identity data (hashed email, click ID, device info) to match that outcome to a person the platform already showed an ad to. Without the match, the event is noise. With it, the platform learns what a buyer looks like.
The part that trips people up: a click is not a conversion signal. A click is an action on the ad itself. A conversion signal is an action that happens after, usually on a page or checkout the platform never sees directly, which is why it has to be reported.
Why do delivery algorithms depend on them?
Meta's delivery system, Google's Smart Bidding, and TikTok's optimization all run on the same loop. You pick an objective, the algorithm serves impressions to people it predicts will complete that objective, and then it checks its predictions against the conversion signals you send. Each signal corrects the model.
Feed it purchase events and it learns the traits of buyers: the lookalike seed, the time of day, the creative, the price sensitivity. Feed it nothing but clicks and it does the only thing it can, which is find more people who click. Those are rarely the same people.
This is why buyer-intent signals matter more than raw traffic numbers. The algorithm does not reward volume. It rewards signal quality, because quality is what its machine-learning bidding was built to consume.
What happens when the signals go dark?
Three failures stack up, and they compound.
- The model drifts toward the wrong audience. With no purchase events, the objective quietly collapses from "find buyers" to "find clickers," and budget follows.
- Winning ads look like losers. An ad driving real sales reports zero conversions, so it gets paused first in every automated and manual review.
- Lookalikes degrade. Seed audiences built from incomplete signals produce lookalikes of the wrong people, and the error propagates into the next campaign.
The arithmetic is blunt. If 7 of every 10 purchases happen somewhere the platform cannot see, the model is training on 30% of the outcomes and guessing at the rest. Decisions made on that 30% are not cautious. They run on a biased sample.
How is a conversion signal actually sent?
There are two delivery paths, and they behave differently under privacy changes. A browser pixel fires client-side when a page loads. A server-side event fires from your own server to the platform's API, carrying matched identity data directly. The difference between browser pixels and server-side tracking decides how many of your events survive ad blockers and iOS settings.
A server-side purchase event sent to Meta's Conversions API looks roughly like this:
{
"event_name": "Purchase",
"event_time": 1761523200,
"action_source": "website",
"user_data": {
"em": "309a0a5baf0...e1c7",
"fbc": "fb.1.1761500000.IwAR2x"
},
"custom_data": {
"currency": "USD",
"value": 49.90
}
}The fbc field is the click ID that ties the purchase back to the ad that earned it. The hashed em is the identity match. Strip those and the event still arrives, but the platform cannot attribute it, so it teaches the model nothing.
What makes a signal high quality?
Not every reported event helps equally. Four properties separate a signal the algorithm can learn from a signal it discards.
| Low-quality signal | High-quality signal | |
|---|---|---|
| Identity match | Few fields, often unhashed | Email, click ID, device data |
| Timing | Reported days later | Within hours of the event |
| Completeness | Click or view only | Full purchase with value |
| Delivery path | Pixel only, blockable | Server-side through the API |
Freshness is its own lever. A purchase event reported within hours lands inside the attribution window the platform uses for training. The same event reported a week later arrives after the model has already moved on. Value matters too. An event that carries the order amount lets the algorithm chase high-value buyers instead of treating every conversion as identical.
When every property lines up, the model gets a clean correction and delivery improves. When they do not, you are paying full price for events the algorithm cannot read.
Where to start
- Website: www.pixamp.io. See how brands keep Meta learning from sales that happen off their own site. First 1,000 clicks free, no card required.
- How it works: www.pixamp.io/#how-it-works. The three-step setup: connect Meta Business Manager, add a retailer button, launch. Live in under an hour.
- Book a demo: www.pixamp.io/#contact. A 20-minute walkthrough on a real retailer page, with the founding team.
An algorithm only learns from the signals it receives. Audit what yours is actually getting, and the reason delivery stalls usually explains itself.