Server-to-Server Conversion Tracking: Why Postbacks Beat Pixels

Every conversion pixel is a small act of faith. You drop a snippet on the order-confirmation page, and from that moment you are trusting the single most hostile computer in the entire transaction — a stranger's browser, on a network you don't control, running extensions you can't see — to faithfully report back that a sale happened and how much it was worth. When the pixel fires, great. When it doesn't, you don't get an error. You get silence. And silence, in conversion tracking, reads exactly like "no sale."

That asymmetry is the whole problem. A pixel that fails costs a publisher a commission they earned, or hands one to a fraudster who tampered with the amount. You usually find out weeks later, when a payout looks wrong and nobody can reconstruct why. Server-to-server conversion tracking — postbacks — exists to take the count out of the browser entirely and put it somewhere you can actually stand behind. Here is why the browser is the wrong place to count money, and how TrackingMD records conversions instead.

The four ways a browser pixel quietly loses money

Client-side conversion pixels fail in ways that share one nasty property: they are invisible at the moment of failure. There is no 500, no alert, no retry. The event simply never arrives.

• Ad and tracking blockers. A large slice of users run content blockers or privacy-hardened browsers that strip requests to anything that looks like a tracking host before the script ever executes. The conversion is real; the pixel is gone.
• Cookie loss and short retention. Pixel attribution leans on a cookie set at click time and read back at conversion. Major browsers now cap or purge client-set cookies aggressively — sometimes within days. A sale that closes after a normal consideration window can arrive with the attribution cookie already expired, orphaning a legitimate conversion.
• Tab-close race conditions. A confirmation-page pixel has to load, execute, and complete its request before the user closes the tab, hits back, or the checkout redirects to a bank or wallet. On a slow connection the tab wins the race and the request is aborted mid-flight.
• Client-side tampering. Anything running in the browser can be read, replayed, or edited. A determined actor can fire your conversion pixel by hand, inflate the order amount, or replay it a hundred times. You are counting revenue on the honor system, in an environment with no honor.

None of these are exotic. They are the default behavior of the modern web. Any measurement approach that depends on JavaScript executing to completion in an adversarial browser is going to under-count real conversions and over-count fake ones at the same time.

What a postback actually is

A postback moves the report off the user's machine. Instead of asking the browser to phone home, the advertiser's own server — the system that just processed the order and knows for certain it succeeded — makes a direct, server-to-server call to record the conversion. In TrackingMD that call is a single public endpoint:

POST /track/conversion

The user's browser is never in the loop. There is no script to block, no cookie that has to survive, no tab that has to stay open. The request originates from a backend that already has the authoritative order record in hand, so it fires exactly once, with the real amount, at the moment the sale is confirmed — including sales that finalize hours later in a back-office batch, which a confirmation-page pixel could never capture.

The payload is deliberately small. You send a conversion_type of either "sale" or "lead", and for sales an order_amount (numeric, at least 0, and capped to reject absurd values). Then you send exactly one attribution key so TrackingMD knows which click earned the credit. That key is where the design gets interesting.

The attribution key: click_id first, with fallbacks

Every redirect through a TrackingMD tracking link — /r/{code} — mints a unique click_id at the moment of the click. That id is the strongest possible attribution signal because it is server-generated, opaque, and tied to exactly one click event. The postback endpoint accepts three keys in a strict priority order, and you supply exactly one:

The happy path is click_id, and TrackingMD gives you a clean way to get it into your own system. When a program enables pass_click_id_to_destination, the redirect appends ?click_id=... to the destination URL. Your landing page or checkout reads that parameter, stashes it against the session or the order, and hands it back verbatim on the postback when the sale closes. That round trip — mint on redirect, carry through the funnel, return on conversion — is what lets you attribute a conversion to one specific click with no cookie involved at all.

When you can't carry the click_id end to end, the endpoint degrades gracefully. publisher_code, read from a first-party cookie, still credits the right publisher. link_id is the coarse last resort. The priority order means richer signals always win when present, but a conversion is never dropped just because the strongest key didn't survive.

Signing the postback so it can't be forged

Moving the count server-side closes the tampering hole only if you also close the forgery hole. A public, pre-authentication endpoint is reachable by anyone — which is exactly what you want for a legitimate advertiser backend calling in, and exactly what a fraudster would love to abuse by posting fake sales.

That is what signed postbacks are for. Each program carries a require_signed_postback flag and an encrypted postback_secret. Turn it on, and TrackingMD will only honor conversions that arrive with a valid signature derived from that shared secret — proof that the call came from a system holding the key, not from someone who guessed your endpoint. The secret is stored encrypted and scoped to the program, so trust is granted per program rather than resting on one global credential you can never safely change.

The practical guidance: for anything that moves money, require signing. An unsigned postback endpoint is a coupon anyone on the internet can print. A signed one is a claim only your infrastructure can make.

Idempotency and abuse control

Server-to-server doesn't mean fire-and-forget. Real backends retry. A timeout, a dropped connection, or an over-eager job runner can send the same conversion twice, and without protection you'd pay a commission twice for one sale.

TrackingMD suppresses duplicates within a per-program window, duplicate_click_window_seconds, which defaults to 3600 (one hour). Inside that window, a repeat conversion that looks like the same event is collapsed rather than double-counted, so your retry logic stays simple and safe: send it again if you're unsure, and the platform absorbs the redundancy. Programs that legitimately see rapid repeat conversions can tune the window; the default is a sane starting point for most sales flows.

Because the endpoint is public and pre-authentication by necessity, it is also rate-limited against abuse. That protects the ingestion path from floods and brute-force probing without putting a login in front of the one call your advertiser backend needs to make automatically, thousands of times a day, with no human present.

The shift worth making

The instinct to measure conversions in the browser is a holdover from an era when the browser was a cooperative place. It isn't anymore, and it isn't going back. Blockers, cookie purges, and privacy defaults are getting stricter every release, which means client-side pixels don't fail at a fixed rate — they fail at a rate that climbs every year, silently, in the direction of under-counting the publishers who actually drive your revenue.

The shift is to stop treating the browser as a source of truth and start treating your own order system as one. It already knows, with certainty, that a sale happened and what it was worth. A postback simply lets that system say so directly:

• Mint a click_id on every redirect, and pass it to your destination so it can ride the funnel and come back on the postback.
• Send one authoritative POST /track/conversion from your backend the instant an order is confirmed — including delayed and back-office sales a pixel would miss.
• Require signed postbacks on anything that pays out, and lean on the duplicate window instead of hand-rolling idempotency.

Pixels ask a hostile machine to please report back. Postbacks let the one system that actually knows do the reporting. For anything you're going to pay a commission on, that difference is the whole game.