Postback URL Explained: S2S Postback Tracking for Dating

A postback URL is the address an advertiser's server calls to tell your tracker that a click has turned into a registration, a confirmed account or a sale. This guide is for media buyers, publishers and affiliate managers working with dating offers. After reading it, you will understand how S2S postbacks work, be able to build and test one, and recognize the errors that quietly break conversion data.

What is a postback URL?

A postback URL is an endpoint on the receiving side, usually a tracker or an affiliate platform, that the advertiser's server calls whenever a conversion happens, passing the click ID and event details as URL parameters.

Because the request runs from server to server, it does not depend on the user's browser, cookies or ad blockers. That matters in dating, where valuable events such as an email confirmation or a first payment often happen hours later and sometimes on another device.

How S2S tracking works, step by step

S2S tracking connects a click and a later conversion through one shared identifier:

1. A user clicks your ad. Your tracker records source, sub-IDs, GEO, device and time, and generates a unique click ID.
2. The tracker redirects the user, often via a prelander, to the offer URL with the click ID in a parameter.
3. The advertiser stores the click ID with the new registration.
4. When an event happens, the advertiser's server calls your postback endpoint with the click ID filled in.
5. Your tracker matches the click ID, records conversion and payout, and can forward the conversion to the traffic source for optimization.

Step 2 is a frequent failure point: if a prelander or an extra redirect drops the parameter, the conversion can never be matched. Our guide to dating prelanders covers how to pass parameters through.

Postback URL structure: parameters and macros

Two links work as a pair. The offer link in your tracker sends the click ID out:

https://offer.example.com/signup?pid={partner_id}&sub1={click_id}

The postback you hand to the advertiser brings it back:

https://tracker.example.com/postback?cid={sub1}&event={event}&payout={payout}&currency={currency}&txid={transaction_id}

Values in curly braces are macros: placeholders the sending system replaces with real values. Your tracker fills in {click_id} at the click, and the advertiser's platform fills in {sub1} with the value it received. In this example:

• cid is the click ID echoed back; without it, nothing can be attributed.
• event names the conversion, for example soi, doi or sale. Some platforms use goal IDs or one URL per event instead.
• payout and currency carry the amount; if they are missing, many trackers fall back to the offer's default payout.
• txid is a unique transaction ID that prevents double counting.

Macro syntax and parameter names differ between platforms, so copy them from each side's documentation instead of guessing. If your tracker supports a secret token or an allowlist of sender IPs, use it, so that nobody else can push conversions into your stats.

Tracking SOI, DOI and sales as separate events

One click can produce several conversions over time: an SOI at registration, a DOI at confirmation, a sale at the first payment and, on RevShare deals, recurring revenue. Set each up as its own conversion type and agree with the advertiser which ones are paid and which are informational; the business side is covered in SOI vs DOI leads.

Three rules keep the data clean:

• Keep click IDs alive long enough. DOIs and sales can arrive days after the click, so the tracker's attribution window must cover the full conversion window.
• Deduplicate. Count one conversion per click and event type, and reject repeated transaction IDs. Sending systems may retry after a timeout, so respond quickly with HTTP 200.
• Handle status changes. Agree in advance how rejections and chargebacks are reported, for example as a status postback or a negative adjustment.

Pixel vs S2S tracking

A pixel is still useful for a quick test or when an advertiser cannot integrate server calls. If you run both methods, deduplicate between them, or every conversion counts twice.

How to test a postback before launch

1. Click your own tracking link and check the offer URL: is the click ID in the parameter the advertiser expects?
2. Ask the advertiser to fire a test postback for that click ID, or to flag a test conversion, so no test is counted as a real lead.
3. Check the tracker's postback log: HTTP 200, all parameters parsed, no unreplaced macros.
4. Confirm the conversion shows up under the right campaign, sub-ID, event, payout and currency.
5. Resend the same postback and make sure it is rejected as a duplicate.
6. Repeat for every event (SOI, DOI, sale) and for status updates.
7. If you forward conversions to a traffic source, check that they arrive there.

In the first days live, reconcile your tracker with the advertiser's statistics daily.

Common postback errors and how to fix them

• Unreplaced macros: a literal {sub1} arrives instead of a value, so the macro name or syntax on the sender's side is wrong.
• Parameter mismatch: the offer expects subid, you send sub1, and the click ID never reaches the advertiser's database.
• Lost click IDs: a prelander, link shortener or extra redirect strips the query string.
• Encoding: special characters in click IDs or sub-IDs break the URL, so URL-encode values.
• Wrong event mapping: a DOI arrives as an SOI, or all events share one name.
• Duplicates: retries without a transaction ID inflate conversions.
• Number formats and currencies: a payout with a decimal comma or in the wrong currency distorts revenue.
• Time zones: daily totals never match because tracker and partner cut the day at different hours.

Nearly all of these show up in a pre-launch test. Clean data is also the basis for every metric in our guide to EPC, CR and CPL for dating traffic.

Privacy: keep personal data out of postbacks

A postback should carry identifiers and event data, never personal data. Email addresses, names, phone numbers, dates of birth and IP addresses do not belong in a postback: URLs end up in server logs and analytics tools and are often forwarded to further partners. Hashing an email address does not make it anonymous either.

Under the GDPR, even pseudonymous identifiers such as click IDs can be personal data when they can be linked to a person, so tracking needs a lawful basis and should collect only what attribution requires. Client-side pixels that rely on cookies generally need consent in the EU. Our guide to GDPR-compliant lead generation in dating covers the wider picture. This section is general information, not legal advice.

FAQ

What is the difference between a postback and a pixel?

A pixel fires in the user's browser and depends on cookies, so ad blockers and browser restrictions can stop it. A postback is a server-to-server request matched by click ID, which also works for delayed and cross-device events.

Why is my postback not firing?

Check the chain in order: is the click ID in the offer URL, does the advertiser store it in the expected parameter, is the postback set up for this event, and does your tracker log the request? Unreplaced macros and mismatched parameter names are common causes.

Do I need a tracker for S2S tracking?

You need an endpoint that can receive postbacks and match them to clicks. That can be a self-hosted or cloud tracker, or the affiliate platform you work with, if it accepts postbacks and reports at click level.

Conclusion

S2S postbacks connect dating conversions to the right click even when they happen hours or days later. Map parameters carefully, track each event separately, test before launch and keep personal data out of every URL. If you sell dating traffic and want to align tracking directly with your partners, talk to Leadpartner.