In CPA marketing, tracking is not infrastructure — it is the contract made technical. The postback decides what gets paid. This page explains how conversion tracking works between your system and ours: postback mechanics, deduplication, anti-fraud signals, and the reporting loop that keeps both sides looking at the same numbers.
You submit the offer with vertical, GEOs, payout model and KPI definition.
Both sides confirm in writing what is billable, what is capped and what is prohibited.
A capped pilot on agreed sources with postback verification.
Sources and creatives are filtered by your approval data, not just conversion counts.
Volume grows only on cohorts that meet the agreed KPI.
The mechanics: when a user clicks, the click is recorded with a unique identifier (click ID). When that user completes the billable event, your system fires a server-to-server postback — an HTTP call to the buyer's tracker carrying the click ID and event parameters. Server-to-server matters: unlike pixels, postbacks do not depend on the user's browser, cookies or ad blockers, which is why they are the standard for CPA validation. The parameters that must pass cleanly: the click ID, the event type, the payout or revenue value where applicable, and any qualifier your KPI needs (deposit amount, order ID, subscription status). A postback that fires late, duplicates, or drops parameters corrupts the entire validation chain — which is why end-to-end testing before launch is mandatory, not a formality.
Every conversion must count once. Deduplication rules — how repeat postbacks for the same user or order are handled — are agreed upfront: typically the first valid postback wins, and re-fires are logged but not double-counted. The attribution window defines how long after the click a conversion is still yours to pay: too short and you underpay the buyer for real influence; too long and you pay for users who would have converted anyway. Both parameters are commercial terms as much as technical ones — they are fixed in the written KPI definition, and changes apply only going forward.
Tracking data is the first line of fraud defense. The signals that matter: duplicate device and click identifiers, conversion timing distributions that no human produces, click-to-install or click-to-registration anomalies, GEO mismatches between click and conversion, and conversions from placements with systematically empty downstream behavior. On top of detection, the structural defense is reconciliation: conversions are matched against your system of record — cleared deposits, confirmed orders, active subscriptions — within the hold window, so fraudulent conversions are caught before payment, not argued about after. Sources that systematically produce rejected conversions are removed from rotation; that feedback loop is what keeps a CPA supply chain clean.
Reporting is the transparency layer of the deal. At minimum you should have: conversions per day with their validation status, and the ability to trace any conversion back to its source attributes. The granularity of source detail — placement, sub-source, creative — is defined by the transparency agreement for your engagement; the principle is that quality questions always have a data answer. Your approval data flowing back per conversion is what lets the buying side optimize toward cohorts that retain and pay. Reporting cadence and format are agreed during onboarding; disputes are resolved against the logs described on the KPI and payout terms page.
We integrate with the common affiliate tracking platforms — Keitaro, Everflow, Affise, TUNE (HasOffers), CAKE, Binom, RedTrack — and with in-house postback setups. If you have no tracker yet, we will tell you honestly what a minimal reliable setup looks like for your funnel. If you use something uncommon, compatibility is confirmed during onboarding: what matters is that the billable event fires a reliable server-to-server postback with clean parameters. The offer brief template lists the tracking fields a launch needs.
Reports, postbacks and disputed conversions are handled against written KPI terms and logs on both sides. Payout models, schedules and hold periods are agreed individually per offer and confirmed in writing before traffic starts.
A server-to-server call from your system to the buyer's tracker when a user completes the billable event, carrying the click ID and event parameters. It is browser-independent, which is why it is the trusted mechanism for CPA validation.
Because every failure mode — late firing, duplicates, dropped parameters — corrupts payment validation. An untested postback means disputes about real money. End-to-end testing before traffic starts is mandatory.
By deduplication rules agreed upfront: the first valid postback for a user or order counts, re-fires are logged but not double-paid. The exact rules are part of the written KPI definition.
How long after the click a conversion still counts as billable. It is a commercial term fixed in the agreement — changes apply only going forward, never retroactively.
Duplicate identifiers, impossible conversion timing, GEO mismatches, and systematic downstream emptiness per placement — plus reconciliation against your system of record within the hold window, so fraud is caught before payment.
Conversions with validation status and traceability to source attributes; source-level granularity follows the transparency agreement for your engagement. Your per-conversion approval data closes the optimization loop.
Keitaro, Everflow, Affise, TUNE (HasOffers), CAKE, Binom, RedTrack and in-house postbacks. Other setups are checked for compatibility during onboarding.
Traffic is paused or capped until tracking is restored — delivering unmeasurable conversions serves neither side. Validation after recovery follows the logs and the written terms.
Short brief — we reply through your messenger.