Postback URL Setup: Sending Conversions Back to an Affiliate's Tracker

It usually turns up on a partner's second or third day with you, once the tracking links are working and the first clicks have gone through. The partner buys traffic and runs it through a tracker of their own, Keitaro or Voluum or RedTrack or something they had built, and they send across one long line of text with a lot of curly brackets in it and a note asking you to fire it on reg and FTD. Nothing about that line is complicated. It still tends to take three or four goes before it works, mostly for reasons that are nobody's fault in particular.

The line is the partner's postback URL, an address on their tracker that your affiliate platform calls, server to server, whenever one of their players does something worth counting. The partner's own click ID gets filled in on the way out, so their tracker can tie the player back to the ad or the page or the placement they came from. Over here at MAP it is one of the first jobs an affiliate manager does for any partner who buys media, and one of the jobs we get asked about most. How your platform hears about the registration and the deposit in the first place is in our piece on S2S postbacks and pixels, and everything here starts from the point where your platform already knows.

The line that arrives looks something like the first rows of the table further down, an address on the partner's tracker, a question mark, and then three or four pairs joined up with ampersands, a click ID, a status, maybe a payout. Each pair has two halves. The name on the left of the equals sign belongs to the partner's tracker and has to stay exactly as they typed it, capital letters and all, on account of it being the name their tracker listens for. The bit in curly brackets on the right is a placeholder. The trouble is that it is very often written in the partner's tracker's own language rather than yours. One partner sends you subid in brackets, the next one sends clickid, and neither means a thing to your platform until somebody swaps it for the placeholder your platform actually fills in.

Most of the setup, truth be told, is going through the line pair by pair and swapping each right-hand side for something your side recognises. The click ID pair is the one that matters. Event and payout can come after, and plenty of partners are happy enough with a postback that carries nothing but the click ID for the first week while the rest of it gets sorted.

There is a step before the postback that partners sometimes skip, and nothing works without it. Their tracker makes a click ID for every click, and that ID has to be put onto your tracking link on the way through, in whichever parameter your platform reads it from, so the platform can keep it against the player. If the partner sends traffic to a bare tracking link, the player still gets credited to the partner. There is just no click ID stored against them, and when they deposit there is nothing to send back. The postback goes out with an empty value, or it does not go out at all.

This comes up most with partners who set their links up months ago for a content site and then started buying traffic on the very same links. The links work. The commission works and the partner gets paid. Their tracker never sees a single conversion, though, on account of nobody having added the click ID to the links when the paid traffic started. Partners running several placements often put more than one value on the link as well, a click ID plus a campaign or placement name, and those travel the same way and can go back out in the postback alongside it.

Usually the first test goes something like this. The partner clicks their own tracking link, which gives them a real click ID in their tracker, registers a test account, and the two of you watch. Something does arrive at their end. When they open it the click ID reads subid in curly brackets, the placeholder its self, letter for letter, and their tracker has filed it under a click that does not exist.

That means the placeholder never got swapped, and nearly always it is something small. The partner's own placeholder might still be sitting in the URL where yours should be. Yours might be in there spelt slightly off, a capital letter that should not be there, or round brackets where the platform wants curly ones. Now and again the value did get swapped and then broke the line, an ampersand inside a campaign name for instance, which the tracker reads as the start of a brand new pair. Each of those is a two minute fix once somebody spots it.

What wastes the afternoon is testing with a click ID somebody made up, which a lot of people go and do first. The tracker has never heard of that click, so it quietly throws the whole conversion away, and from both ends it looks exactly as if the postback never fired.

With the placeholders fixed, the partner puts ten pounds onto the test account and their tracker shows two conversions for the one player. One came from the registration and one from the deposit, both sent to the same address with nothing in them to say which was which, so the tracker counted each one as a sale. The partner asked for reg and FTD, and that is exactly what they got, fired at the one URL.

Trackers handle this one of two ways. Some take a single postback URL with an event or status pair in it, so the registration goes out with one status and the deposit with another, and the partner sets up a goal in the tracker for each. Others want a separate URL for every event. The partner will know which kind theirs is, or their tracker's help pages will.

Retries cause the other sort of double. If the partner's tracker is slow to answer, a platform will often send the same postback again, which is what you want it to do, since the alternative is the conversion getting lost. It does mean the tracker needs some way of recognising the repeat. A transaction ID in the URL, a unique reference for that one conversion and nothing else, gives it one, and most trackers will ignore a second hit carrying an ID they have seen already.

Which events go out comes down to what the partner does with them. A partner with a content site might only want the first deposit, to see which of their pages turn readers into customers. A partner buying paid social or search traffic usually wants the registration and the deposit both, and wants them quickly, because their tracker passes the conversion on to the ad platform and the ad platform uses it to decide who to show the next ad to. A postback that arrives the following afternoon still gets counted. It does a good deal less for the partner's bidding than one that landed a minute after the deposit, mind you.

Qualified CPAs are the awkward ones. A CPA only exists once the player has cleared the baseline and the wagering, which might be days or weeks after the deposit, and by then a good few trackers and traffic sources have stopped accepting conversions on that click. If the partner is paid on CPA and wants to see paid players in their tracker, it is worth asking how long their tracker keeps a click open before anybody goes and promises to send it. The conditions behind that CPA, and why some players never get there, are in our piece on CPA qualification criteria.

Plenty of postback URLs come with a payout pair on the end, and partners like having one, since their tracker can then work out return on spend without waiting for the statement. On a CPA deal that is simple once the player qualifies. The figure is the CPA, everybody already knows it, and sending it does no harm.

Revenue share is less tidy. There is no honest commission figure to send at the moment of a first deposit, on account of nobody knowing yet what that player will be worth. Some operators send the deposit amount instead. That is a real number, but it tells the partner what each of your players put in, one player at a time, and a lot of operators would sooner keep that to the monthly totals. Others leave the payout empty and let the statement do that job, or send a fixed figure the partner has agreed to treat as a marker and nothing more. Any of those works as long as the partner knows which one they are getting.

Currency is the quiet one. A payout in euros landing in a tracker set to pounds gets read as pounds, and the partner's figures end up out by whatever the rate was that week, so wherever there is a payout figure it is worth sending the currency right alongside it.

A postback only needs to carry the partner's own click ID and whatever you have agreed about the event and the payout. It should never carry anything about the player as a person, their email or username, their name, the account number on your platform, their IP address. A partner will occasionally ask for the account number, usually with a perfectly sensible reason about matching their reports up, and the answer is still no. The GDPR names identification numbers and online identifiers in its definition of personal data, so an account number counts, and sending it to a partner's tracker means sharing it with a system you have no say over whatsoever. The transaction ID is the safe version of the very same thing. It means nothing outside of that one conversion, and both sides can still match a row with it when there is a dispute.

A few conversions come undone later on. A deposit gets charged back a fortnight later, a CPA gets turned down as a duplicate account, or a player your fraud scoring picked out turns out to be one of nine sharing a phone. On your platform the conversion comes off and the partner's statement shows it. In the partner's tracker it stays exactly where it was unless something goes and tells it otherwise, and their return on spend for that campaign stays a little better than the truth for as long as they keep looking at it.

Quite a few trackers will accept a second postback for the same transaction with a status saying it was rejected or reversed, which pulls the conversion back out of their figures. Not every partner wants that, and not every tracker takes it. For partners buying traffic at any real scale it is worth offering, because the gap between their tracker and your statement at month end then shrinks down to reversals they already know about. The patterns behind most of those reversals are in our piece on how to spot iGaming affiliate fraud.

Here is a made-up postback URL from a made-up partner, split into its pieces. The parts in square brackets stand in for whatever your platform calls its placeholders.

Put back together that is the tracker address, a question mark, and the pairs joined with ampersands, in whatever order the partner likes, since most trackers do not care about the order. Only the names on the left come from the partner. Everything inside the brackets gets filled in by your platform when the event happens, and that is the whole of it.

Postbacks on MAP run on MasterPostback™, our own S2S technology, and the affiliate manager sets them up in the platform without needing any technical knowledge and without anybody changing code on your site. Partners can put dynamic tracking parameters such as click IDs on their links, so each placement is tracked on its own, and those IDs are what go back out to their tracker when a player converts. Events come across from your platform in real time, which means the postback can leave as soon as your platform has reported the deposit.

For traffic that has no way of carrying a click ID, promo codes and QR codes come built in, and there is a JS pixel for the on-site measurement a postback plays no part in. Partners and networks who would sooner pull their numbers than have them sent can fetch them through the REST API into their own BI tools. Getting your platform connected in the first place is done with one of our account managers during onboarding, five days on average from start to finish, and affiliate managers on your side get full training on running the programme. Our operator's guide to tracking software has where postbacks sit next to everything else that gets tracked.

MAP sends the postback. What happens to it after it leaves is out of anybody's hands on your side. If the partner's tracker only takes one kind of request, or only accepts calls from addresses it has been told about, or stops counting conversions on a click after seven days, a perfectly good postback can arrive and get ignored. Usually the first anybody hears of it is the partner asking why their tracker is empty. Most of that comes out in the first test, and those are settings the partner has to go and change their own self.

Nor can a postback go out any quicker than the event behind it. If your own platform reports first deposits in a batch every hour, the partner gets them every hour, whatever their tracker would like, and that part of the speed question sits with your platform's own integration.

And whatever the partner does with the conversion afterwards is their business. Passing it on to an ad platform, bidding on it, building their own reports out of it, none of that is anything a postback setup can see or check. The payout figure you chose to send goes wherever they send it, which is one more reason to settle what goes in that figure before the first one leaves.

The partner who buys the most traffic is the one worth starting with. A week of their conversions out of their tracker, with click ID and event and time, laid next to your own figures for the same partner and the same week, sorts itself into three piles fairly quickly. Anything on both lists is a postback doing its job. Conversions only on your side never reached their tracker, which usually means a link without the click ID on it or a placeholder that never got swapped. The pile only on their side deserves the closest look of the three, since a conversion your platform has no record of is either a repeat their tracker counted twice or something that never happened at your end at all. Most of the time the first pile is the biggest by a distance and the other two are a handful of rows each, and those rows tell you which of the fixes above that partner still needs. You can run it your own self in an afternoon with nothing more than two exports. The size of those two small piles is a useful number to keep an eye on next to the other KPIs an affiliate manager tracks.

If the two smaller piles were bigger than you would like, a demo with one of your own partners' postback URLs is a fair way of seeing the same setup on MAP, and the rest of the platform is on the full feature list. Bringing partners over from another platform means setting every one of their postbacks up again on the new one, which our guide to migrating a programme without losing its history covers. And if you are still comparing platforms, the questions worth asking about postbacks before anybody signs anything are in our checklist for choosing iGaming affiliate software.

What is a postback URL in affiliate marketing

It is an address on an affiliate's tracker that the operator's affiliate platform calls when one of that affiliate's players converts, with the affiliate's own click ID filled in. The tracker matches the ID to the original click, so the affiliate can see which ad, page or placement produced the registration or the deposit.

What is the difference between a postback and a pixel

A pixel runs in the player's browser and reports the conversion from there, which leaves it exposed to blocked scripts and cookies that get deleted. A postback travels from one server to another with no browser anywhere in it, so it still arrives when the player was on Safari, behind an ad blocker, or switched devices halfway through. Most programmes keep a pixel for on-site measurement and leave anything to do with payment to postbacks.

What does S2S postback mean

Server to server. It is the same postback described above, and the name just spells out that it goes between two servers rather than through anybody's browser.

Should a postback fire on registration or on the first deposit

Whichever the partner needs, and quite often both, sent as two separate events. Partners on paid traffic tend to want registrations for speed and first deposits for value, while content partners can usually manage on the deposit alone. If both go to the one URL it needs an event or status pair in it, or the tracker will count every player twice.

Can a postback include the player's deposit amount

It can, though whether it should is more of a commercial decision than a technical one. A deposit amount tells the partner what each player put in, one at a time, which a lot of operators would rather leave to the statement. What should never go with it is anything that identifies the player, an email or an account number, since under GDPR those are personal data.