Tracking processing

This page explains what happens to a tracking request between the moment it arrives and the moment a transaction exists. Every method goes through the same steps: pixel, S2S postback, Tracking API, and manual import.

Step 1: the request is checked

• The request must pass validation. A request without an identifier, or with an unknown conversion type, is refused.
• If it was sent to a postback that has conditions on source, offer, advertiser, affiliate, or type, it must match them. If it does not, it is logged as Filtered and ignored.
• The conversion type must be allowed on that channel. Not every type can be created through every method. See Conversion type.

Step 2: PalDock finds the conversion

Every request has to be tied to something that already exists. PalDock looks in this order:

1. Advertiser ID together with External ID
2. Origin ID
3. If neither matches an existing conversion, the original click or lead is used as the parent

When several conversions already exist under one origin, PalDock narrows the search to the child conversions of the type in the request. If exactly one matches, that one is used. If several match, the request is logged as Unmatched and nothing happens, because PalDock cannot guess which conversion was meant.

• Affiliate links cannot use the External ID, because it does not exist yet at click time. Use the Origin ID.
• iFrame and API integrations can use either.
• Sending both is the safest option and works in every case.

See Conversion IDs explained.

Step 3: create or update

The action parameter decides what happens next.

• action=create records a new conversion. The type parameter is required.
• action=update changes an existing one, for example to set the result or the value.
• If action is missing, the request is treated as a create.

Two cases worth knowing:

• An update that finds no conversion returns an error and changes nothing.
• An update that lands on a click, lead, or send while carrying a different type creates a conversion of that type instead. This is how a sale reported against a click ends up as a sale conversion rather than overwriting the click.
• Send create=false when you want an update to fail rather than create anything.

Step 4: duplicates are filtered out

If the advertiser sends an External ID, PalDock checks whether a valid conversion with the same External ID, advertiser, and type already exists. If it does, the new one is stored as a duplicate and no transaction is created. See Deduplication based on advertiser’s ID.

If the first request arrived without an External ID and a later one brings it, PalDock saves it onto the conversion. A value that is already stored is never overwritten. Clicks, leads, and sends never carry an External ID.

Step 5: commissions run

Only now does PalDock look at commissions. A recorded conversion does not mean a payout.

• The conversion must match a commission’s conditions.
• The commission must be active, within its period, and within its recurrence limit.

See How PalDock picks a commission.

Combining tracking methods

Most setups run more than one method, because each fails in different circumstances.

• Pixel: fires immediately on the confirmation page, and is lost when the browser blocks it.
• S2S postback: arrives when the advertiser processes the order, from seconds to days later. Some send daily batches.
• Tracking API: PalDock asks the advertiser, so the timing is yours to control.
• Manual import: the fallback when nothing else is available.

The same conversion can therefore arrive up to four times. The External ID is what keeps it as one conversion, so agree on it with every advertiser before going live.

What to send

• Always: an identifier, either the Origin ID or the Advertiser ID with the External ID.
• When creating: type.
• When more than one commission exists for that type: Commission ID.
• When you have it: result, value, and the External ID, every time, even on updates.

The full list is on Tracking parameters.