What to do

Store campaign details separately from tracking instructions. The campaign contains its name, country and MTL/VTL links. The tracking setup contains the platform preset, the incoming click parameter and the postback for each conversion event.

How it works

Assign one saved tracking setup to the campaign. Redsoft gives that setup a neutral internal ID, such as TRACKING-SETUP-1. This ID points to the saved set of event rules. It is never sent to the external platform. One setup can be reused by several campaigns. Each campaign has exactly one setup.

Why this is needed

The campaign name is only descriptive. The assigned setup, not a name such as “ExoClick”, tells Redsoft how to capture the click ID and where to deliver conversions.

What to do

Let the affiliate create a campaign, then add every MTL or VTL link that belongs to it. Give the campaign a unique campaign ID and each link a unique link ID.

How it works

Each link sends visitors to a chosen place on DarkRoseDating, such as a model page, a profile or a landing page. A routing value such as srcm=gg selects that experience. Routing is separate from S2S tracking. When a tracking setup is assigned, Redsoft automatically adds its click-ID parameter (e.g. cid={conversions_tracking}) to every link in the campaign.

* Testing option: different links could be compared in an A/B test to see which page produces more registrations or purchases.

Why this is needed

The campaign ID groups the activity. The link ID shows which exact link produced the visit. The affiliate sets up tracking once per campaign, not once per model link.

What to do

Offer a list of platform presets (ExoClick, TrafficStars, PropellerAds, EvaDav, BeMob, Voluum, RedTrack, Binom, Keitaro) plus “Custom”. Each preset fills in the URL parameter, the platform’s click macro and a postback template. Custom lets the affiliate type both.

How it works

ExoClick replaces {conversions_tracking} with the real click value before sending the visitor. Redsoft reads the configured cid parameter and stores that value as external_click_id. PropellerAds uses ${SUBID}, RedTrack uses {clickid}, and so on. All of them end up in the same internal field.

Why this is needed

Most setup mistakes are a wrong macro name. Presets remove that risk. A consistent internal field lets the delivery process work the same way for every platform. Preset values must be verified against each platform’s documentation before release.

What to do

On the first request, identify the campaign link from its reference in the URL (today ref_ids). Then save a click record: the full external click ID, campaign, exact link, tracking-setup ID and time. Keep it connected to the visitor (first-party cookie + server-side record). At signup, find the winning click and save it on the new user permanently.

How it works

30 days: only clicks from the last 30 days count. Last click: if there are several, the newest wins. Locked at signup: once the user exists, every future conversion uses the click saved on the user, even if they later click another affiliate’s link. This also works when they buy later on another device, because the click is on the account, not in the browser. Note that each ad network only accepts conversions for a limited time after its click. Redsoft still records and logs late purchases.

Why this is needed

A click ID identifies the visit, not the platform or setup. Saving the setup ID with the click means Redsoft never guesses. Locking at signup means purchases days or weeks later still reach the right affiliate.

What to do

Define a fixed list of events: registration (signup completed), first_purchase, purchase (every purchase) and package_1…package_4. Connect each to the backend action that confirms it. For purchases, that is the confirmed payment, not the button click.

How it works

One confirmed payment can produce several events. A user’s first payment for Package 3 produces first_purchase, purchase and package_3. Redsoft records all of them internally, then sends a postback only for those the affiliate turned on. Each event uses its own postback URL.

Why this is needed

Affiliates optimise in stages: signups first, then first purchases, then repeat or high-value buyers. Giving them separate events supports every stage. The ⚠ notes in the editor, and a warning when two events share the same goal URL, protect them from counting one payment twice.

What the affiliate does once

Picks a preset, turns on an event such as Registration and pastes the postback URL from the platform (or fills in the goal ID in the template). The URL marks where Redsoft inserts the click ID with {external_click_id}.

What the backend does later

After Redsoft confirms the registration, it takes the saved URL, replaces {external_click_id} with the complete stored value (URL-encoded), sends the request, and writes the result to the postback log. Purchase events work the same way with their own URLs.

Why this is needed

Redsoft needs to know when to send (the event), where to send (the saved URL) and which click it belongs to (the stored click ID).

What to do

Load the main Google tag once. Save the relevant Google Ads send_to value against each Redsoft event, for example one for registration and separate values for Package 1 and Package 2.

How it works

After the application receives the verified Redsoft result, browser code selects only that event’s send_to value and runs one gtag('event', 'conversion', ...) command with the correct transaction ID. If the payment is confirmed after the visitor left the page, the event can fire on their next page load (to be agreed with the developers).

Why this is needed

If every snippet ran from the header, Google would receive conversions that did not happen. Only the confirmed event may fire. This is a browser event, not S2S.

What to do

Always record the event internally. Before sending, check that the user has a click ID and that this exact conversion was not already delivered. If the platform fails, retry automatically. A click ID that is empty, or is still the unfilled macro text (for example the literal {conversions_tracking} when someone opens the link directly), counts as missing.

How it works

Build an idempotency key such as TRACKING-SETUP-1 + first_purchase + USER-5531 (or + ORDER-1001 for purchases). If a delivered row with that key exists, skip it. On a timeout or 5xx answer, retry after 1 min, 5 min, 30 min, 2 h and 6 h. A 4xx answer means a wrong URL, so mark it Failed straight away.

Why this is needed

Networks must not receive invented IDs. Payment providers often send the same notice twice, and visitors reload pages. Without these checks, purchases would be counted twice.

What to do

Write one log row per postback (retries update the same row): time, event, campaign, link, click ID, final URL, HTTP status, response body (first 500 characters), attempts and status. Show it to the affiliate, filtered to their own campaigns.

How it works

Statuses: Delivered, Retrying, Failed, Skipped · no click ID, Skipped · duplicate, Test. A failed row has a Retry button after the affiliate fixes the setup.

Why this is needed

When an affiliate says “ExoClick shows fewer conversions than you”, the log answers it in seconds. Without it, every question becomes a developer ticket.

What to do

Check that every URL is valid and contains {external_click_id}. Then let the affiliate press “Send test” for each event. Redsoft sends a real request and shows the answer.

How it works

Platforms ignore conversions for click IDs they don’t know. So the affiliate first makes one test click on their own ad or tracker link and pastes that click ID. The test then appears in the platform’s report, which proves the goal is correct. Without a real ID, Redsoft uses a dummy one, which only proves the URL is reachable. Tests are logged with the status Test and never count as conversions in Redsoft.

Why this is needed

A valid-looking URL can still have the wrong goal. Testing catches that before real money is spent. Roll out on one campaign first, compare numbers, then expand.