How to Set Up Affiliate Postback Tracking for Adult Traffic

Affiliate postback tracking in one diagram

A typical affiliate funnel looks like this:

traffic source → tracker or your site → affiliate link → offer → conversion → affiliate-network postback → tracker

With paid traffic, there is often one more callback:

tracker → conversion postback → traffic source

For the systems to connect the conversion to the original visit, they need an identifier that survives the trip through the funnel.

The most important rule is this:

do not infer meaning from a parameter name alone. One platform may call a reusable affiliate label subid, while a tracker such as Keitaro exposes its unique tracker click ID as subid. What matters is which value a field stores and whether the same value is returned later.

If you are still building the paid-traffic workflow itself, start with our guide to buying adult traffic. This page focuses on measurement and attribution after the funnel exists.

SubID, click ID and postback are not the same thing

These terms are often mixed together because affiliate platforms use different naming conventions. A reliable setup starts by separating the functions.

What is a SubID?

A SubID is an extra tracking value accepted by an affiliate link or affiliate network.

For a publisher, it can answer questions such as:

• which website sent the click;
• which article or ranking sent it;
• which CTA or table position was used;
• which campaign or creative produced it;
• which test variant the user saw.

For example, you might use values such as:

A reusable SubID can appear on thousands of clicks. That is fine when its job is to label a segment rather than uniquely identify a visitor.

Some affiliate platforms provide several SubID fields. In that case it is usually easier to keep major dimensions separate than to pack everything into one long value.

But there is an important complication: a field named SubID can also be used to carry a unique tracker click ID. Keitaro, for example, calls its own unique tracker click identifier subid in its postback workflow. This is why the data flow matters more than the label.

What is a click ID?

A click ID identifies one specific click.

Conceptually:

click 1 → abc123
click 2 → def456
click 3 → ghi789

A tracker stores the click ID together with the data it knows at click time, such as:

• campaign;
• traffic source;
• site, zone or placement;
• landing page;
• offer;
• GEO;
• device;
• cost or bid information where available.

The tracker then passes its click ID into a parameter that the affiliate network or advertiser can store.

When a conversion happens, the affiliate platform returns that same value through the postback. The tracker finds the original click and attaches the conversion to it.

The receiving field on the affiliate-network side may be named:

• clickid;
• click_id;
• subid;
• sub1;
• aff_sub;
• externalid;
• sid;
• or something completely different.

Do not guess the field or macro. Use the current documentation for that affiliate network, offer source or tracker template.

A transaction_id is often the identifier of the conversion, not the identifier of the original click. Treating the two as interchangeable can create broken attribution or duplicate handling.

What is an S2S postback?

A postback is an HTTP request sent by one system to another after an event.

A common affiliate sequence is:

1. the tracker receives a click and generates its click ID;
2. that click ID is passed to the affiliate network or advertiser;
3. the user completes a target action;
4. the affiliate platform calls the tracker’s Postback URL;
5. the callback includes the stored click ID and, when supported, payout, status, event or other conversion data;
6. the tracker matches the callback to the original click.

This is called server-to-server (S2S) tracking because the conversion notification is sent between systems rather than relying on a browser-side tag firing on a thank-you page.

The exact HTTP method and parameter format are platform-specific. Many affiliate integrations expose conversion values as URL parameters, but you should always use the format documented by the platform you are configuring.

How to read a postback URL

A conceptual URL can look like this:

https://track.example/postback?clickid={sub1}&payout={payout}&status={status}

Read it as a mapping between the system receiving the callback and the system sending it:

The text inside braces is only an example of network-side macros. One platform may use {sub1}, another {aff_sub}, {click_id} or a completely different token. The names on the left side of = must match the receiving system; the macros on the right must match the sending system.

This example uses query parameters because that is common in affiliate tracking. Some platforms use different URL formats or POST requests, so treat the pattern as a way to understand the mapping rather than a universal template to copy.

S2S postback vs tracking pixel

Both can report conversions, but they work differently.

• S2S postback is sent by a server and normally uses a previously stored click identifier to attribute the event.
• Tracking pixel or browser-side script fires in the user’s browser, usually on a confirmation page or through a client-side event.

S2S tracking reduces dependence on the user’s browser, but it does not magically repair a broken identifier chain. If the click ID never reached the affiliate network, there is nothing useful to return in the postback.

When SubIDs are enough and when a tracker helps

A dedicated tracker is useful, but not every affiliate website needs one from day one.

Scenario 1: an affiliate site with a few placements

Suppose you run SEO or direct traffic and mainly want to know which page or CTA produces revenue.

A simple setup can be enough:

page → placement → affiliate link with SubID → affiliate network

The network’s own reporting may then show clicks, registrations, sales and revenue by SubID.

This works well when:

• you have only a few traffic sources;
• click-level attribution is not essential;
• you do not need automated offer routing;
• you do not need to return conversions to an ad platform;
• the affiliate program provides enough SubID reporting for your decisions.

Scenario 2: paid traffic with direct S2S and no third-party tracker

Paid traffic does not automatically require Voluum, RedTrack, Keitaro or another dedicated tracker.

A simpler chain can work when the traffic source gives you a unique source click ID and the affiliate network can both store that value and call the traffic source’s Postback URL after conversion:

traffic source → affiliate network / offer → conversion → affiliate network → traffic-source postback

The data flow is:

1. the traffic source appends its click ID or conversion token to the outgoing campaign URL;
2. you pass that value into a SubID, click-ID or other custom field accepted by the affiliate network;
3. the affiliate platform preserves the value through the conversion;
4. after the target event, the affiliate network calls the traffic source’s Postback URL and returns the stored identifier;
5. the traffic source can attribute the conversion to the original click or placement.

If there is a prelander between the ad network and the offer, it still has to preserve the source identifier. Direct S2S removes the third-party tracker from the chain; it does not remove the need for a continuous click-ID path.

This setup can be enough for source-side conversion reporting and, where supported, conversion-based optimization. TrafficStars, for example, documents S2S conversion tracking that can receive a click ID back from an affiliate or CPA platform without requiring a separate third-party tracker.

The tradeoff is less central control. A dedicated tracker becomes more useful when you need to normalize several traffic sources and affiliate networks, rotate or route offers, join cost and revenue in one report, keep your own click-level logs or apply more complex attribution rules.

Scenario 3: paid traffic and placement-level optimization through a tracker

Paid media usually needs more detail.

You may need to know:

• what the click cost;
• which site, zone or placement sent it;
• which creative produced it;
• which landing page received it;
• which offer was selected;
• whether a conversion happened;
• how much that conversion paid;
• whether the event should be sent back to the traffic source.

A tracker becomes much more useful here because it joins cost, routing and conversion data around one click-level record.

If you are choosing a source for this workflow, see our comparison of adult ad networks.

Scenario 4: several traffic sources, networks and offers

A tracker becomes especially valuable when you combine:

• multiple traffic sources;
• several direct affiliate programs or adult CPA networks;
• split tests between offers;
• multiple landing pages;
• several conversion events;
• dynamic payouts;
• source-side conversion callbacks.

The tracker becomes the common layer that normalizes different parameter names and reporting models.

For adult traffic, the useful question is usually not whether a tracker markets itself as “adult.” What matters is whether it supports the mechanics you need: S2S postbacks, custom parameters, logs, routing, the required click volume and integrations with your actual traffic sources and affiliate platforms.

How to set up affiliate postback tracking step by step

Interfaces differ between Keitaro, Voluum, RedTrack, Binom and other trackers, but the underlying data flow is similar.

Step 1. Decide which dimensions you actually need

Do not begin with twenty parameters just because the traffic source exposes them.

For a first paid test, useful dimensions often include:

• campaign ID;
• site / zone / placement ID;
• creative ID;
• GEO;
• device;
• your own test or variant ID;
• cost, when the source can pass it accurately.

Your tracker may already detect some values, so duplicating them in every URL can add noise without improving analysis.

The most important source dimension is usually the one you can act on later: the ID that lets you block a weak placement, isolate a strong site or compare a creative.

Step 2. Pass traffic-source parameters into the tracker

Traffic sources normally expose dynamic macros or tokens.

A conceptual campaign URL might look like:

https://track.example/campaign?zone={zone_id}&creative={creative_id}&cost={cost}

Those macro names are examples only. Use the current token names from the traffic source you are actually running.

After a real click, confirm that the tracker reports the resolved values instead of the literal macro text.

Step 3. Generate the tracker click ID and send it forward

A tracker normally creates its own unique click ID automatically.

Assume the tracker exposes that value as:

{clickid}

Now determine which affiliate-network parameter can store it.

If the affiliate network expects a field named sub1, the offer URL inside the tracker may follow this pattern:

https://offer.example/?sub1={clickid}

After a real click, {clickid} is replaced with a unique value and the affiliate platform stores that value with the session or user record.

The exact mapping can look different in every platform. For example:

• Keitaro exposes its tracker click ID as {subid};
• Voluum exposes a tracker click ID as {clickid} and expects that value back through its own postback parameter;
• RedTrack also uses {clickid} for its tracker-generated click identifier in affiliate setups.

The principle is the same: send the tracker’s unique value into a field the affiliate platform will preserve and return.

Step 4. Do not lose the click ID on a prelander or custom landing page

A landing page creates an extra handoff.

A common failure looks like this:

tracker → prelander with click ID → hard-coded CTA without click ID → offer

The tracker recorded the click correctly, but the affiliate network never received the identifier. A perfect postback configuration cannot reconstruct it later.

Check every element between the incoming click and the offer:

• redirects;
• outbound buttons;
• JavaScript navigation;
• forms;
• link builders;
• server-side redirects;
• URL rewriting;
• multi-step landing pages.

If the funnel has several steps, verify the identifier at every step rather than checking only the first and last URL.

Step 5. Configure affiliate network → tracker postback

Your tracker provides a Postback URL. Conceptually it may look like:

https://track.example/postback?clickid={NETWORK_CLICK_MACRO}&payout={NETWORK_PAYOUT_MACRO}&status={NETWORK_STATUS_MACRO}

The parameter names on the left belong to your tracker. The macros on the right belong to the affiliate network.

The critical value is the identifier you sent in Step 3.

If the tracker sent its click ID into the affiliate network’s sub1 field, the postback must return the value stored in that same field. Returning sub2, an order number or another unrelated identifier will not match the original click.

Official tracker templates can reduce manual mapping, but you should still understand what they are doing. Templates can change, networks can add parameters, and custom offers may not follow the default configuration.

Step 6. If needed, configure tracker → traffic source postback

With paid traffic, the tracker often needs to send a second callback after it receives the affiliate conversion.

The chain becomes:

affiliate network → tracker → traffic source

The traffic source may have its own click token or conversion identifier. The tracker captures that source-side value when the ad click arrives, stores it with the tracker click ID, then uses it later when reporting a conversion back to the source.

This lets the source show conversion reporting and, where supported, use conversion data for bidding or campaign optimization.

ExoClick, for example, maintains first-party integration guides for trackers including Voluum and RedTrack. The specific Goal ID, token or postback format should be taken from the current ExoClick and tracker documentation rather than copied from an old campaign.

Step 7. Return only the conversion data you can use correctly

The required fields depend on the tracker and integration.

For click-level attribution, the tracker must receive the identifier it can match to the original click. Some trackers also require an event or status field for a conversion to be processed correctly. Keitaro’s current generic postback documentation, for example, treats its subid click ID and status as required parameters.

Other useful fields can include:

• payout;
• currency;
• conversion status;
• goal or event type;
• transaction / conversion ID.

You normally do not need to send GEO, device or source ID back with the postback if the tracker already stored them when the click happened.

Example 1: publisher or SEO traffic without a dedicated tracker

Suppose an adult dating affiliate program appears in three places on your site:

• a comparison table;
• an inline CTA inside an article;
• a button at the end of the page.

You could use three stable SubID values:

dating-table
dating-inline
dating-bottom

The flow is simple:

visitor → affiliate link with SubID → offer

Then compare the affiliate-network report by SubID:

• clicks;
• registrations;
• paid actions;
• approved revenue;
• EPC or another useful earning metric.

This already answers a valuable question: which placement actually earns money?

If the network supports several SubID fields, you can keep page and placement separate instead of encoding both into one string.

You do not need click-level infrastructure simply to learn that one CTA consistently outperforms another.

Example 2: paid adult traffic through a tracker

Now suppose you buy pop traffic to an adult dating offer.

A simplified funnel is:

adult ad network → tracker → prelander → affiliate network → advertiser

On the click:

1. the ad network passes a zone or placement ID and its own conversion token;
2. the tracker stores those source values and creates its own click ID;
3. the tracker click ID is passed through the prelander into the affiliate-network field;
4. the user registers, buys or completes another target action;
5. the affiliate network fires a postback containing the same tracker click ID;
6. the tracker records the conversion and payout;
7. when configured, the tracker sends a source-side conversion callback back to the adult ad network;
8. the report can now compare spend, conversions and revenue by zone.

That moves the analysis from:

“the campaign spent $100 and produced 12 conversions”

to something more actionable:

“zone A spent $18 and returned $44; zone B spent $21 and produced no approved conversion.”

Now you have data that can support a blacklist, whitelist, bid adjustment or a new isolated test. The broader optimization workflow is covered in our adult traffic buying guide.

Payout, statuses and multiple conversion events

A technically recorded conversion is not always the same thing as final revenue.

Dynamic payout

If the affiliate platform can return the real payout, use dynamic revenue instead of assigning one fixed value to every conversion whenever practical.

This matters when:

• payout changes by GEO;
• different events pay different amounts;
• the offer uses a hybrid model;
• sales or deposits vary in value;
• later events or upsells add revenue;
• conversion status can change after the initial callback.

If the tracker values every conversion at $5 while actual payouts are $2, $5 and $12, its ROI report is wrong even if the click IDs are mapped perfectly.

Multiple conversion events

Adult funnels can have several meaningful milestones:

click → registration → qualified action → purchase / deposit / subscription

Do not assume every event should be counted as the same conversion.

Depending on the offer, useful event names might include:

• registration;
• qualified_registration;
• sale;
• deposit;
• subscription.

The affiliate network decides which events it can expose. The tracker decides how those events are stored or mapped.

Pending, approved, rejected and chargeback states

If the affiliate platform sends status changes, configure the tracker so a rejected action does not remain in the report as final revenue.

This is especially important when comparing offers with different validation delays. One program may report raw leads almost immediately while another exposes only approved actions.

Keep raw events, approved events and actual revenue conceptually separate when you evaluate performance.

Transaction IDs and duplicate postbacks

A click ID identifies the original visit. A transaction or conversion ID identifies the conversion itself.

Those are different jobs.

A network may retry a postback, send a status update for the same conversion, or report several events for one click. A transaction ID can help a system decide whether the callback is:

• a new conversion;
• an update to an existing conversion;
• a duplicate delivery;
• a separate event that legitimately belongs to the same click.

The correct duplicate behavior is platform-specific. RedTrack, for example, provides duplicate-postback controls for conversion events. Do not invent your own deduplication rule by swapping click IDs and transaction IDs.

How to test a postback before you spend

Do not fund a meaningful campaign until the complete tracking path has been tested.

A practical pre-flight test:

1. create a small test campaign;
2. make a real click through the actual tracking URL;
3. confirm that the tracker recorded the source, zone and other required parameters;
4. find the tracker-generated click ID;
5. confirm that this exact value reached the affiliate platform in the intended field;
6. use the affiliate platform’s supported test method or coordinate a test conversion with the network/manager;
7. inspect the tracker postback or conversion log;
8. confirm that the conversion was attached to the correct click;
9. verify payout, currency, status and event type;
10. if the conversion should be sent back to the traffic source, verify that final callback as well.

Why use a real click? The tracker and traffic source may generate identifiers only after an actual campaign visit. A made-up ID can test whether an endpoint responds, but not necessarily whether the complete attribution chain is correct.

Keep a short integration note for each traffic source + tracker + affiliate-network combination. Record the accepted click-ID field, postback macro, payout macro, event mapping and any source-side conversion token. That is easier to audit later than reverse-engineering an old campaign.

Why conversions go missing and how to debug the chain

If the affiliate network shows an action but the tracker does not, the problem is usually at a specific handoff.

Debug from left to right.

Failure 1: the click ID was lost before conversion

This is the first thing to rule out.

If the affiliate platform never stored the tracker’s click ID, the postback cannot recreate the relationship afterward.

Verify the identifier on the forward journey before spending time debugging the callback.

Failure 2: macros from two systems were mixed up

Assume the tracker exposes {clickid} and the affiliate network accepts a field called sub1.

The conceptual mapping is:

offer URL: sub1={clickid}

postback: clickid={sub1}

The names are examples. The direction is what matters: the tracker value is stored by the network, then the network returns the value it stored.

Failure 3: the postback fires for the wrong event

An affiliate platform may expose separate callbacks for registration, deposit, sale or another qualified action.

If only the registration event is configured, the tracker will never learn about the later sale even though the click-ID mapping is perfect.

Failure 4: reports use different dates

One platform may group by click date while another groups by conversion date.

Delayed conversions can then appear on different calendar days even when no data is missing. Compare the same cohort and understand which timestamp each report uses before treating a date-level mismatch as a tracking failure.

Failure 5: you compare raw and approved conversions as if they were identical

A pending lead is not the same as approved revenue.

If the tracker receives the initial event but the affiliate platform later rejects or changes it, the reporting logic must account for that update or your ROI will be overstated.

Privacy and security

Tracking parameters are a poor place to store personal or sensitive user data.

For adult traffic in particular, avoid putting information such as this into URLs, SubIDs or campaign labels:

• email addresses;
• phone numbers;
• usernames;
• profile content;
• sexual preferences;
• other data that directly identifies a person or reveals sensitive context.

A random click ID plus technical campaign identifiers is usually enough to connect systems for attribution.

Other useful safeguards include:

• use HTTPS throughout the tracking chain;
• protect postback endpoints with the tracker-supported key or token where available;
• use source/IP restrictions only when both sides support them and they do not break legitimate delivery;
• do not publish production Postback URLs that contain secret keys;
• retain only the dimensions you genuinely need for reporting and optimization;
• understand data retention and account access when using a cloud tracker.

Server-side tracking changes how conversion data is delivered. It does not remove privacy, consent or lawful-processing obligations that apply to the data you collect.

FAQ

Is a SubID the same as a click ID?

Not necessarily. A SubID is a platform-defined tracking field and is often used as a reusable label for a source, page, placement or campaign. A click ID uniquely identifies one click. However, a tracker can send its unique click ID through a field named subid, so always check what the field actually contains.

Can I track affiliate performance without a dedicated tracker?

Yes. If you run a small publisher site and the affiliate program gives you useful SubID reporting, you may be able to compare pages and placements without click-level tracking. With paid traffic, you can also sometimes use direct S2S: pass the traffic source’s click ID into a field the affiliate network preserves, then have the network return that ID directly to the source’s Postback URL. A dedicated tracker becomes more valuable with several traffic sources or affiliate networks, split tests, centralized cost/revenue reporting, custom routing and more complex click-level attribution.

What must a postback contain?

It depends on the receiving platform. For click-level attribution, the callback needs the identifier the tracker can match to an existing click. Some trackers also require a status or event field. Payout, currency, event type and transaction ID are added when supported and useful.

Why does the affiliate network show a conversion while my tracker does not?

First confirm that the tracker click ID reached the affiliate network before the conversion. Then check which network macro is being returned in the Postback URL and whether the tracker received the request. If the original click ID was lost earlier in the funnel, changing the callback alone will not solve the problem.

Should I send the conversion back to the ad network?

It is not required just to record the event in your tracker. But for paid media, a traffic-source postback can improve reporting and may feed conversion-based optimization features when the source supports them. Send only events and values that represent real outcomes.

Can I put source, GEO and creative into one SubID?

You can, but several structured SubID or custom fields are easier to analyze when the affiliate platform supports them. If you use one field, adopt a stable naming convention that you can decode months later.

Does S2S tracking mean browser restrictions no longer matter?

The conversion callback itself does not need a browser-side pixel to fire, but the full funnel can still contain browser-dependent steps, redirects, scripts and consent requirements. S2S tracking is not a substitute for testing the entire path.

Sources and current documentation

Parameter names, macros, event models and tracker interfaces can change. For a production integration, verify the current documentation for every system in the chain.

• Keitaro: affiliate networks and postback
• Keitaro: postback parameters and processing
• Keitaro: postback troubleshooting
• Voluum: S2S postback conversion tracking
• Voluum: postback URL parameters
• Voluum: submitting a postback URL to an affiliate network
• RedTrack: affiliate tracker setup
• RedTrack: dynamic parameters and click IDs
• RedTrack: conversion event and duplicate-postback handling
• ExoClick: conversion tracking with Voluum
• ExoClick: conversion tracking with RedTrack
• TrafficStars: conversion tracking and S2S postback

Always use the macro names and conversion events documented by the traffic source, tracker and affiliate platform you are configuring now rather than reusing values from an old integration without checking them.