FIELD GUIDE / CONVERSION TRACKING
Why your iGaming conversion reports disagree
Start with the same event, reporting period and status in every system. Then trace the postback path to separate reporting differences from delivery problems.
Assessing James for a Media Buyer role?
Discuss a role with JamesThis guide shows how I review conversion definitions, postback paths and reporting gaps. For hiring discussions, share the role, channels and tracking responsibilities you want to assess.
Work communication is in English.
Prefer to investigate first? Continue with the guide below.
S2S postback checks for missing or mismatched conversions
Backend records the event; tracker does not
Check whether the event was sent, whether the tracker click ID was retained, and what the receiver returned. If no shared ID or delivery log is available, record the gap as unresolved.
Tracker records it; ad network does not
First confirm that the event is configured to send a postback to the ad network. Then check this leg independently: traffic-source click ID, event mapping, delivery response and reporting filters. A successful first leg does not prove the second succeeded.
Both systems have it, but daily totals differ
Align time zones, date boundaries, visit versus postback receipt timestamps, approval status and attribution rules. Re-export after the known reporting delay before changing tracking settings.
1. Define the conversion before comparing CPA
A registration, an approved affiliate conversion and a first-time deposit (FTD) describe different outcomes. An approval status can also change after an event is first recorded. Write down the event and eligibility rules for each report before treating their totals as comparable.
- Name the event, its trigger and any approval requirements.
- Record whether the report counts events, unique users or approved actions.
- Calculate CPA using spend and the agreed conversion count for the same scope; registration CPA is not FTD cost.
2. Align dates, time zones and attribution rules
The day of the click, the day of the conversion and the time a postback arrives can differ. Voluum, for example, supports reporting by visit timestamp or postback timestamp. A late conversion can therefore appear on different dates without being missing.
- Use the same time zone and report boundaries across exports.
- Document the timestamp basis, attribution model and attribution window in each system.
- Record when each export was generated, then allow for known approval or reporting delays before comparing it again.
3. Trace the event through the postback path
A server-to-server (S2S) postback sends conversion information between systems. Check each relevant leg separately: backend or affiliate platform to tracker, then tracker to ad network. Success in one leg does not establish success in the next.
- Follow a permitted sample using the relevant click ID and event or transaction identifier.
- Compare the sent event type with the receiver’s mapping and the available response or error logs.
- Check duplicate handling, status updates and delayed delivery against that integration’s documentation. Different events from one click need not be duplicates.
Reference: Voluum: Parameters in postback URLs · Voluum: Custom conversions
4. Reconcile the data you can actually access
Start with one campaign and a bounded period. Match records where shared identifiers exist. Compare aggregates only after aligning events, filters and time settings. An affiliate team may have approved-conversion reports but no operator-level deposit data; document that limit instead of inferring deposits.
- Matched: the same event is identifiable in both systems.
- Explained difference: timing, status, filters or definitions account for the gap.
- Unresolved: evidence is insufficient, or a specific delivery or mapping issue needs investigation.
5. Turn the finding into a specific next action
A useful review states the finding, supporting evidence, owner and follow-up check. Correct a confirmed mapping issue or align a reporting view, then compare again. Avoid changing several tracking settings at once: that makes it harder to tell which change mattered.
Do not classify every unmatched record as lost revenue, or scale spend solely because one dashboard reports a lower CPA. Where the cause remains uncertain, state what data would resolve it.
CPA fell after a tracking fix: did performance improve?
A lower reported CPA after a tracking fix may reflect conversions that were previously missing. Before treating it as a reason to increase spend:
- Record the measurement change. Note what was fixed, when it changed and which events were affected. Keep the event definition, time basis and approval status visible in the before-and-after comparison; changed counting limits what that comparison can prove.
- Check advertiser-side outcomes. Where advertiser-side reports are accessible, use complete, equal-length reporting windows with the same campaign scope, event and approval rules. Compare spend and confirmed conversions, allowing for known reporting or approval delays. More tracked registrations do not establish more confirmed first-time deposits.
- Look beyond the first conversion where data is available. Check revenue or retention for the acquired users when those reports are accessible. If they are not, record the limit rather than inferring better customer quality from CPA alone.
- Set the next action from the evidence. If advertiser-side evidence does not support improvement, do not treat a lower dashboard CPA as a scaling signal. If the evidence supports a test, agree a limited budget increase and monitor the same outcomes; assess the test separately from the change in counting.
James on LinkedIn: tracking changes and reported CPA
Once reports are comparable, assess acquisition cost against customer value. Acquisition cost and customer value
A practical reconciliation checklist
For one campaign and a bounded period, keep one row per sampled event in your internal review. Use these fields:
- Campaign and report source; export time and time zone.
- Event definition, counting unit and approval status.
- Tracker click ID, source click ID and event or transaction ID, where available.
- Click time, conversion time and postback receipt time, where available.
- Match status: matched, explained difference or unresolved.
- Evidence, responsible team, proposed action and the next verification date.
Illustrative example, not a client result: a click occurs before midnight and its conversion arrives the next morning. Reports grouped by visit date and postback date can put that event on different days. Match the event and time basis before calling it missing.
Postback succeeded. Why do the conversion totals still differ?
A successful request does not by itself prove that the intended event was recorded against the correct click or included in the report you are viewing. Check both delivery stages, event mapping and the report’s date basis, filters and reporting delay.
Worked example: reconcile 10 / 9 / 10 conversions
Hypothetical training example. All counts, identifiers, timestamps and evidence references below are invented. They are not client results or platform defaults. Field names are in English to match the downloadable workbook.
1. Define the review in the Review sheet
Review one campaign and one registration event. In this scenario, all ten registrations belong to the selected source, meet the same validation rules and are within the same attribution window. Nine events already match. The tenth needs investigation.
Show all completed scope fields
| Field | Completed example value |
|---|---|
| Campaign / market | DEMO-01 / hypothetical market |
| Conversion event / trigger | registration / backend validates a completed registration |
| Counting unit | One unique event ID per validated registration |
| Period start (inclusive) | 2026-10-11 00:00:00 |
| Period end (exclusive) | 2026-10-12 00:00:00 |
| Time zone | UTC for all fields |
| Owner | Media buyer (hypothetical role) |
| Review date | 2026-10-13 |
| Currency | N/A: event-count reconciliation; no spend comparison |
| Approval / rejection rules | Include validated registrations only |
| Attribution model / window | Scenario assumption: last eligible click / 7 days |
| Expected reporting delay | Scenario assumption: up to 24 hours; verify actual integration |
| Reference system | Backend export B01 |
| Exclusions (QA, duplicates) | Exclude test events and repeated event IDs |
| Maturity cutoff / rationale | Export 2026-10-13 09:00 UTC, more than 24 hours after period end |
| Access / evidence gaps | Scenario assumes permitted access to all event logs and exports |
2. Compare the reports before calculating a difference
The initial reports were exported on 13 October at 09:00 UTC. The tracker initially groups by click date; the other two reports group by conversion date. Set Comparable? to No for the tracker, leaving its calculated difference blank. The raw 9 versus 10 is a prompt to investigate, not a count of lost conversions.
| Source | Initial date basis | Initial count | Comparable? | Aligned count / difference |
|---|---|---|---|---|
| Ad network (N01) | Conversion date | 10 | Yes | 10 / 0 |
| Tracker (T01 → T02) | Click date | 9 | No → Yes | 10 / 0 |
| Backend / reference (B01) | Conversion date | 10 | Yes | 10 / — |
The agreed reference is the backend export. After matching IDs and regrouping the tracker’s exported events by conversion time, all three contain the same ten event IDs. The tracker’s aligned count is 10 and its difference is 0. If your tools cannot supply the needed event data, keep the difference unresolved.
3. Complete the Event log for the cross-midnight event
The click occurred on 10 October at 23:58 UTC; registration followed on 11 October at 00:06 UTC. A report for 11 October grouped by click date excludes this event, although its conversion and both postbacks occurred that day. In this example, receiver records also confirm the intended event and click association; a success message alone would be insufficient.
Show the completed event row
| Field | Completed example value |
|---|---|
| Sample ID | S01 |
| Event / approval status | registration / validated |
| Tracker click ID | T001 |
| Source click ID | N001 |
| Event / transaction ID | E001 |
| Click time | 2026-10-10 23:58:00 |
| Conversion time | 2026-10-11 00:06:00 |
| Tracker receipt time | 2026-10-11 00:06:02 |
| Network receipt time | 2026-10-11 00:06:04 |
| Time zone | UTC |
| Match status | Explained difference |
| Evidence reference | DEMO B01 / T01 / N01: E001 mapped to T001 and N001; both receivers recorded registration |
| Finding | Click-date report excludes E001 from 11 October; conversion-date report includes it |
| Next action | Regroup tracker export by conversion time and compare the full event-ID set |
| Owner | Tracking analyst (hypothetical role) |
| Next check | 2026-10-13 10:00:00 UTC |
4. Record the finding and close only after verification
Show the completed action row
| Field | Completed example value |
|---|---|
| Issue ID | D01 |
| Finding / evidence | Date-basis mismatch for E001; see DEMO B01 / T01 / N01 |
| Status | Closed |
| Next action | Use conversion-time grouping for this review; preserve original exports |
| Owner | Tracking analyst (hypothetical role) |
| Due date | 2026-10-13 |
| Verification evidence | DEMO T02 at 10:00 UTC: 10 event IDs match B01 and N01. All Comparable? = Yes. Network and tracker deltas = 0. |
| Closed date | 2026-10-13 |
The explained difference is a reporting-date issue. It does not establish better campaign performance, recover lost revenue or justify a budget increase. An event total of zero difference is only the starting point; the event-ID comparison is the closing evidence here.
Fill in your own review using the Excel worksheet
If the totals still differ after alignment
Check whether both postback stages accepted the intended event and preserved the correct IDs. Then check event mapping, approval status, duplicate handling, filters and reporting maturity. Keep missing evidence unresolved and assign the next check to the team that can access it.
For example, PropellerAds documents separate conversion goals and notes that statistics can take up to 24 hours to register a conversion. This is platform-specific guidance, not a universal waiting period. Official S2S reference (checked 13 October 2026)
FTD is reported. Is the campaign actually optimizing for FTD?
Not necessarily. The business goal, the event your tracker sends, the goal recorded by the ad network and the signal used to optimize delivery are separate settings to verify. A report column proves neither that the event drives optimization nor that the campaign is profitable.
Hypothetical diagnostic example. The identifiers, counts and configuration below are invented, not client results or platform defaults.
An operator wants more accepted first-time depositors. In this example, the team has verified the following mapping for a PropellerAds CPA Goal campaign. Both registrations and FTDs are reported, but they serve different roles.
On narrow screens, scroll the table horizontally.
| Check | Verified example | Meaning |
|---|---|---|
| Business outcome | Accepted FTD | The operator’s desired outcome |
| Tracker → main postback | registration | The main event sent to the network |
| Tracker → secondary goal | first_deposit → goal=2 | A later event recorded separately |
| Optimization input | Main postback | In this configuration, registration |
PropellerAds states that only main-postback events affect CPA Goal campaign performance; secondary goals can track later events. This rule is specific to that platform and campaign type. Platform reference, checked 14 October 2026: PropellerAds: S2S / CPA Goal.
What to check next
- Inspect the outgoing event mapping and current campaign configuration together. An event name in a tracker alone is not enough; keep the dated evidence for the receiving goal.
- Compare registration and accepted-FTD results for equally mature cohorts. If FTD data is delayed or unavailable, record that gap before deciding whether cheaper registrations justify more spend.
- If the signal and business goal differ, agree the next test with the account owner. Verify platform support, event quality and available volume before changing any optimization setting.
What the evidence supports
The mapping explains what the campaign is being fed, not why deposits are weak. It does not establish a payment, KYC or traffic-quality failure. Keep the current setting, proposed change, approver and review condition in the decision record; there is no automatic instruction to switch the main goal to FTD.
How James can help
James can review event mapping and available source or placement reports, then document a supported test and the data still needed. Platform configuration access and any changes are agreed separately.
Compare registration CPA with accepted FTD outcomes
Record the evidence in the Tracking worksheet · See how I define events before comparing campaign costs
The tracker has a conversion, but the network does not: which ID is missing?
A tracker click ID and an ad-network click ID have different jobs. The first associates the event with the tracker visit; the second may be needed for the return path to the traffic source. Do not substitute one for the other just because both are called click IDs.
Hypothetical diagnostic example. The identifiers, counts and configuration below are invented, not client results or platform defaults.
The backend and tracker both contain registration E204. The tracker can link it to T204, but the permitted export does not show a source click ID. The network report has no matched event. At this point, the cause remains unresolved.
On narrow screens, scroll the table horizontally.
| Evidence point | Example observation | Next question |
|---|---|---|
| Backend event | E204 / registration / accepted | Was it linked to the correct tracker visit? |
| Tracker record | E204 linked to T204 | Was the traffic-source ID captured on arrival? |
| Source click ID | Not visible in the export | Is it missing, or merely absent from this view? |
| Outgoing request | Not yet inspected | What ID and event were actually sent? |
Voluum documents cid as its required click-ID parameter. PropellerAds separately documents its source-ID token. Actual field names and mappings depend on the integration. Platform reference, checked 14 October 2026: Voluum: postback parameters · PropellerAds: S2S tokens.
What to check next
- Check the permitted arrival record and token mapping. An empty value or an unexpanded placeholder is a reason to inspect configuration; an omitted export column alone is not proof of a broken journey.
- Trace the same event into the outgoing request and receiving result. Check the destination, source ID, event and timestamp; keep response evidence separate from report inclusion.
- If an ID was never captured, ask the responsible team whether a trustworthy mapping exists. Do not invent an ID or attach the event to another click. If evidence remains unavailable, leave the event unresolved.
What the evidence supports
A confirmed mapping defect supports a scoped correction and an authorised test. It does not prove that historical conversions can be recovered. Before any replay, the platform or integration owner must confirm the accepted procedure and duplicate behavior; keep test traffic out of performance totals.
How James can help
James can map the available evidence to each handoff and prepare the questions for the tracker, network or operator team. Missing backend access and platform-side failures remain with the teams able to investigate them.
Record the evidence in the Tracking worksheet · See how I define events before comparing campaign costs
Four postbacks: four conversions, two events, or one customer?
Count the business events you defined, not the number of notifications. A delivery retry, a new event and a status change require different treatment. Deduplicating everything by click ID can also remove legitimate later events.
Hypothetical diagnostic example. The identifiers, counts and configuration below are invented, not client results or platform defaults.
All four notifications below belong to one verified test journey, T031. The registration retry carries the same event ID and payload. The final notification changes that registration’s status; it is not a second registration. IDs and relationships are assumed verified for this example.
On narrow screens, scroll the table horizontally.
| Notification | Event ID / type | Interpretation |
|---|---|---|
| 1 | E101 / registration / pending | First report of the registration |
| 2 | E101 / same registration and status | Retry of notification 1 |
| 3 | D201 / first_deposit / accepted | A separate downstream event |
| 4 | E101 / registration / approved | Status update to the original event |
RedTrack exposes different duplicate-handling modes, including creating, ignoring or updating a conversion. Verify the configured mode and event identity; this example does not prescribe one universal setting. Platform reference, checked 14 October 2026: RedTrack: conversion types and duplicates.
What to check next
- Keep delivery attempts linked to their event. In this example there are four notifications, two distinct business events, one registration and one FTD—not four new customers.
- Check how the actual integration identifies retries and updates. Do not assume a pending-to-approved notification must create a new conversion, or that every repeated click ID is a duplicate.
- Verify the downstream report as well as the tracker. A correction in one system does not by itself prove the other system’s count or value changed. Record the expected result and compare after the documented delay.
What the evidence supports
If the selected metric is approved registrations, this example contains one; if it is accepted FTDs, it also contains one. Two event types must not be added together and called two acquired customers. Where IDs or update history are missing, the true unique-event count remains unknown.
How James can help
James can separate notifications, event types and status changes in a discrepancy log and review the configured counting rules. Use one event row per distinct event in the worksheet, with retry and update references in the evidence notes; do not delete records just to make totals match.
Record the evidence in the Tracking worksheet · See how I define events before comparing campaign costs
Download the tracking worksheet
Use this workbook to compare one campaign and one conversion event, then keep the evidence and next steps together.
Report downloads are not shared through this portfolio.
English · XLSX · 9 KB · Free download, no sign-up
- In Review, define the event, reporting period and comparison rules. Enter the three report totals only when their scope is aligned.
- In Event log, record sampled events, timestamps and evidence. Assign an owner and next check for unresolved differences.
A blank difference means the inputs are incomplete or incomparable. Zero means equal totals, not proof that every event matches. A hypothetical example is included.
Tracking questions before you change a campaign
Postback succeeded. Why do the conversion totals still differ?
A successful request does not by itself prove that the intended event was recorded against the correct click or included in the report you are viewing. Check both delivery stages, event mapping and the report’s date basis, filters and reporting delay. See the completed 10 / 9 / 10 example
Are registration and first-time deposit CPA comparable?
They measure different outcomes. Compare spend against the same defined event, counting unit and reporting scope. A lower registration CPA does not by itself show a lower deposit cost or better profitability.
What context helps when discussing tracking responsibilities?
Describe the role, market, tools and the tracking responsibilities involved. A high-level, anonymised example is enough for an initial discussion; do not send passwords, player data or confidential reports.
How this method relates to my work
My practical experience includes APAC paid traffic and RedTrack S2S tracking. This guide illustrates how I would define a reporting discrepancy, identify unresolved questions and choose the next checks. Hiring teams can use it to discuss my approach to measurement and campaign operations.
This is a diagnostic guide, not a client case or a promise that all systems will report identical totals.
Discuss a Media Buyer role
Share the company, role, working arrangement and the campaign or tracking responsibilities you want to discuss.
Work communication is in English.
For job opportunities, use the current contact page.
Discuss a role with James (English)