Postback

Reporting conversions to ad platforms was the browser's job for a long time. A few lines of code sitting on the site fired a signal to the platform from the order confirmation page. That arrangement works only while the device and the browser cooperate.

They stopped cooperating. Browsers began blocking third-party cookies by default, phones started requiring separate consent for tracking in each app, and something like half the signal disappeared. It became routine to see three conversions in the ad dashboard against eleven rows in your own database. Nothing in the dashboard says the number is partial, which is what makes it dangerous.

The undercount was not the worst of it. Platforms use conversion records as the raw material for finding more people like the ones who converted, and with half the material arriving they optimize toward the wrong people. Budget gets pulled off an ad that was actually working, because nothing told the platform it worked, and an ad producing nothing takes that budget.

So a path that skips the user's device took hold: your server tells the platform's server, and no device setting can close that route. It also changed who owns the accuracy of the number, which turns out to matter as much as the recovery itself.

Four things, concretely.

1. It restores the lost signal. When someone clicks an ad, the platform appends a click identifier to the destination URL; you store that identifier on your side. Later, when that person pays, you send the stored identifier along with the conversion type and the amount to the endpoint the platform provides. The browser plays no part in any of it.
2. It sends only real conversions. What a browser can establish is that a confirmation page rendered. Your server knows the card was declined afterward, or the order was cancelled the same day, or the same person paid twice — so those can be filtered out before anything is reported. Reporting a conversion you later reversed teaches the platform to go find more people who will also reverse it.
3. It sends conversions that happen late. The first payment after a 14-day trial is the standard case. At that moment the person's browser has no memory of which ad they clicked two weeks earlier, while your server still holds the identifier and can join the two.
4. It feeds the platform's automatic optimization. The more accurate the conversion signal, the closer the people the platform finds are to actual customers. Send first payment rather than free signup and the platform starts hunting for people who pay. The signal you pick is effectively the instruction you hand the platform.

The limits are just as clear. A gap opens between the moment a conversion happens and the moment the platform knows about it, so yesterday's performance can't be finalized this morning. And because your server is the sender, a wrong definition on your side accumulates as wrong numbers on the platform's side. The conversion tracking setup that decides what counts as a conversion has to come first for any of this to be worth having.

Four other approaches address the same problem.

1. Code embedded in the site. A tracking pixel placed on pages to record visits and conversions is easy to install and shows results immediately. When it's blocked, that much is simply missing. In practice teams run both and attach the same key to a conversion so the platform can drop the duplicate. Dropping the pixel entirely also drops the only same-day feedback available.
2. Aggregated frameworks on mobile. Rather than following one person, you receive summary values bucketed over several days. Less personal data changes hands, at the cost of not knowing who came from which ad, and the values arrive days later.
3. Tagging links and keeping the analysis in-house. UTM parameters appended to links let you read channel performance in your own analytics. Nothing goes to the platform, so none of its automatic optimization applies.
4. Skipping individual records entirely. Gather channel spend and total revenue over a few years and estimate contribution statistically, or deliberately withhold ads from a group and measure the incremental lift. Neither answers anything at the level of one conversion, but on which channel actually moved revenue, they answer more honestly.

Three questions decide it: whether you need the platform's automatic optimization, whether the spend justifies engineering time, and whether your conversion definition has settled. For a team spending $2,300 a month on ads, two weeks of server integration usually doesn't pay for itself. And a definition still changing every month will poison a server integration faster than any blocked pixel did.

"The dashboard says three, our side says eleven. We need postbacks."

The browser signal is broken and the undercount is large.

"Let's send first payment as the postback instead of free signup."

Move the people the platform hunts for toward actual customers.

"Keep the pixel and just line up the deduplication key."

Run both without counting the same conversion twice.

Pagedeck did this work over one quarter. Ravi measured the gap between the ad dashboard and internal counts for two months and found an average shortfall of 58 percent. Theo spent two weeks storing the click identifier and reporting it to the platform at first payment. Those two months of measurement are what made the two-week build easy to justify.

The two numbers didn't become equal afterward. The shortfall went from 58 percent to 12 percent, and the rest stayed. The platform only credits conversions within seven days of a click, while the internal count had no window at all. Rather than force them together, Ravi decided which number goes where: budget allocation runs on the platform's number, overall performance reporting on the internal one.

The most common belief is that adding this makes the numbers agree. The shortfall drops, so it looks like convergence. But a platform's number and an internal number cannot match. The attribution rule assigning credit to a touchpoint differs on each side, and so does the counting window. Keep editing definitions to force agreement and you lose the ability to compare last month with this one. Matching them isn't the goal; knowing which one to trust for which decision is. Deciding what each number is for works better.

The other frequent move is removing the pixel once postbacks are live. It looks like the same job done twice, so it reads as tidying. But the pixel reports behavior the server never sees, like where someone went after the click, and it's the side that shows results immediately. Remove it and there's no way to see a reaction on the day you change an ad, which makes fast creative iteration impossible.