Server-to-Server Postbacks and Click ID Reconciliation

The first thing this engagement produces is a number: the share of conversions your partners invoiced last quarter that cannot be matched to a row in your own database. We have never opened an account where that number was zero. Three to twenty percent is ordinary, and above twenty there is almost always one broken parameter carrying the entire error. Finding it takes two to four days. Fixing it properly takes longer, because the fix is a chain rather than a tag. The chain: A click identifier is issued once, at the first hop, and then has to survive every redirect, every app store detour, every consent banner and every checkout that reloads the page. We map the macro for each partner by hand. Clickid, transaction_id, aff_sub and sub1 through sub10 mean different things on different platforms, and a single wrong mapping produces commission paid to a partner who did not send the click. The identifier is then written into your order or lead record as a column, not a cookie. Everything after that is reconciliation. Postbacks, written properly: Fired from your backend on the state change you are actually paying for, carrying a shared secret in the URL and rejected without it. Idempotent on the identifier, so a retry does not create a second commission. Status aware: pending, approved, reversed. Most programs we inherit have no reversal path at all, which is why their affiliate cost never falls when orders are cancelled, and why their finance team quietly stopped believing the channel two quarters ago. The long lag case: For a dealer group the event worth paying for is a signed contract, and that arrives weeks after the click. Nothing held in the browser survives that. We write the identifier into the CRM or DMS record at lead creation, post back on the sale carrying the original click timestamp, and configure Google Ads offline conversion import against gclid, gbraid and wbraid alongside enhanced conversions for leads on hashed phone and email, so one sale appears once in the tracker and once in the ad account rather than twice in either. Where else the same event has to arrive: Meta CAPI and TikTok Events API with a shared event_id, so the browser event and the server event deduplicate instead of doubling. GA4 through the Measurement Protocol where GA4 is the surface the business actually reads. Consent state passed through rather than assumed for traffic from the EU and the UK. We will not: Fire a conversion from a thank-you page and call it server-side. Accept a partner's word that their postback works because it returned 200; we send a test conversion with a known identifier and find it in their dashboard, partner by partner, before signing anything off. Configure postbacks for a program whose commission terms we are not allowed to read, because the terms decide which event fires and without them we are guessing in public. Not for you if: Your program is one network, one payout, one event, and the numbers already tie. That does not need this. Nor is it for a team that wants the work done but will not give an engineer two hours a week for a month. This touches your backend, and no one can do it entirely from the outside. What you hold at the end: A parameter map covering every partner and platform, a reconciliation query your analyst runs monthly against partner invoices, and a written rule for which system wins when two of them disagree. That last document is the one that ends the argument, and it is the reason most clients call us in the first place.