Method demonstration. This is a proposed method, not verified client results. Worked examples are fictional.
Start with the counting unit
A postback can arrive twice even when the underlying action happened once. Equally, one person can make two genuine deposits. Before changing a duplicate setting, decide what one conversion means and which system owns that definition. Otherwise, a fix for inflated notifications can quietly erase valid activity.
This method is for teams comparing operator events, a tracker and a traffic source. It is a framework for investigation, not a claim that a particular integration behaves this way or that any production test has been completed.
Give the business event a stable identity
Ask the event owner for an identifier assigned to the underlying transaction or event, stable across delivery attempts. Document who issues it, when it is created, and where it is unique: for example, only within one operator, account or event type. If uniqueness is local, include the agreed namespace in the key. Verify that a sender preserves the same identity on retry, and that a receiver actually uses the relevant field and scope. A tracker click ID helps attribution; it is not automatically a unique business-event ID.
Keep the event identity separate from the delivery-attempt ID and from mutable fields such as status, amount or timestamp. Pending and approved may describe the same event at different points in its lifecycle; making status part of the event key can create a second conversion when approval arrives. If each update has its own message ID or version, retain it for update processing while linking it to the stable event. Agree on ordering, correction and reversal rules with the event owner, including how to handle late or out-of-order updates. A newer arrival is not necessarily a newer business state.
If identifiers are absent, reused, or conflict with the payload, do not invent a key or silently discard a row. Mark it unresolved and ask the owner to reconcile it. Deduplicating on a user or click alone can suppress a legitimate second deposit; a timestamp or amount match alone does not prove a retry.
Use a decision table before changing a setting
| Evidence | Working interpretation | Next action |
|---|---|---|
| Same scoped event ID, same event data and state | Likely repeat delivery, if the sender confirms the ID contract | Keep the attempts; apply the agreed idempotent treatment once the receiver behavior is verified. |
| Same event ID, valid later state or correction | Update to an existing business event | Apply the documented update or reversal rules; verify the resulting state and downstream treatment. |
| Different verified event IDs, same person or click | Potentially separate actions | Preserve both; count each only for metrics whose definitions include it. |
| Same ID with incompatible identity or missing evidence | Collision or ambiguous record | Quarantine for review and ask the event owner; do not infer a duplicate. |
| Timeout or uncertain response | Delivery outcome is unknown | Check receiver records before any authorized replay; use the same event identity under the agreed retry contract. |
Idempotent treatment means processing a repeated delivery without repeating its intended business effect. It does not mean ignoring every later message about the event. If the destination cannot safely distinguish a retry from a legitimate update, stop and resolve that contract before replaying or changing duplicate handling.
A fictional trace: five messages, two deposits
All identifiers and relationships below are invented for illustration. Assume the operator confirms that the IDs are unique within this operator and that each deposit is a separate business event for the same person. The table is not a log or a completed test.
| Message | Event and state | Interpretation under the assumed contract |
|---|---|---|
| 1 | D-A, first deposit, pending | First report of deposit A. |
| 2 | D-A, first deposit, pending | Repeat delivery of message 1. |
| 3 | D-A, first deposit, approved | Status update to deposit A. |
| 4 | D-B, later deposit, approved | A second deposit event, not a second FTD. |
| 5 | D-B, later deposit, approved | Repeat delivery of message 4. |
On those assumptions there are five messages, two deposit events, one unique depositor, one FTD and one approved FTD. The approval count reflects the state shown and the example's assumed rules; an operator may define approval differently or later reverse it. A count of distinct depositors, a count of deposit transactions and an FTD count answer different questions. Define the eligible population, first-deposit rule, status cutoff, timezone and reporting window before comparing them.
Separate delivery from business approval
An HTTP 200 indicates that the request succeeded under HTTP semantics. Its precise meaning depends on the endpoint and response; it does not by itself establish that the operator approved an FTD, that a tracker attributed it correctly, or that a source included it in an optimization report. Inspect the response body and the receiver's documented contract, then check the actual event state and the downstream report. A timeout also does not prove that the receiver did nothing.
For RedTrack, the official duplicate-mode documentation describes options to create, ignore or edit conversions, and an event-ID-based ignore mode. It says type-level duplicate settings take precedence over status-level settings; confirm the actual configuration and supported behavior for your integration, including updates. An ignore-by-ID choice may prevent a later status update from being recorded. Do not infer the behavior of a traffic source from a tracker setting.
As an illustration of why repeat delivery must be planned for, Cloudflare documents at-least-once delivery for Queues and recommends an idempotency key where repeat processing would have unintended effects. That is a Queues-specific property, not evidence that a particular postback path uses Queues or that a Worker has been deployed.
Reconcile before replay or optimization
- Write down the selected metric, scope, maturity window and event owner. Align the backend, tracker and source on event time versus report time and on status filters.
- For a small authorized sample, connect each business event to its delivery attempts, response, tracker record, status history and source result. Record missing evidence and ownership without copying personal data into a shared report.
- Ask the receiving teams to confirm duplicate mode, identity scope, update and reversal support, retry window and downstream propagation. Compare expected with observed outcomes in an isolated test environment, where available.
- Before a replay, obtain the destination owner's approved procedure and verify whether previous attempts were applied. Keep synthetic events out of live reporting and optimization; never send a fake FTD into a live optimization signal.
- Reconcile again after the documented reporting delay. Keep unresolved rows visible. A corrected tracker total does not prove that a traffic source has corrected its own total.
For the broader handoff investigation, read the RedTrack S2S investigation and the downstream missing-conversion guide. To discuss a media buyer role involving measurement, contact James in English.
Source boundaries
RFC 9110: 200 OK describes HTTP request success; business-event acceptance still depends on the endpoint contract. The RedTrack and Cloudflare references above describe their own products, not a verified integration or James’s production implementation.
A decision record you can reuse
Download the plain-text measurement decision brief. It separates the observation, evidence, limits and next check. No account or email is required.
Browse James’s work and case studies, read the career background, or return to this week’s technical notes.