Keep repeated event delivery separate from repeated financial effects

A conversion-reporting request can be repeated for ordinary technical reasons. The sender may not receive a response, a connection may fail or a reporting process may retry an earlier attempt. Those repeated deliveries should not automatically describe several distinct customer actions. Begin by defining which identifier represents one real conversion. That identifier needs to remain stable across retries of the same event. If it changes each time, the receiver cannot reliably distinguish repeated delivery from genuinely different actions using that field alone. The measurement contract should make the distinction explicit before the integration is used in production. Idempotency concerns the effect of repeating an operation. In a conversion workflow, the important question is whether one reported event can cause more than one intended financial effect. Receiving the same information twice is not itself the problem; applying the payable result twice would be. Keep the event identity connected to the relevant campaign and processing context. A retry response should be interpreted as part of the same event's history rather than as an invitation to generate a fresh identity. The sender and receiver need a shared understanding of what constitutes the original action. Do not confuse click and conversion identifiers. A click supplies referral context, while the conversion identifies the later event being reported. Several legitimate events may have their own rules for relating to an earlier visit, depending on the campaign. Reusing an arbitrary value because it is already available can erase the distinction between those stages. Document which field identifies the event and which field connects it to the referral. When investigating duplicates, compare the actual identifiers and campaign context instead of deciding from the closeness of timestamps alone. Similar timing can be a clue, but it is not a complete event definition. Retries also need a deliberate operational policy. A validation error should lead to correction of the relevant input rather than an endless loop of unchanged requests. A temporary transport problem may call for a later attempt using the same event identity. Keep enough request context to reconcile what happened without logging secrets or unnecessary customer details. If the first attempt may have succeeded, check the recorded result before manually creating another event. The purpose of a recovery procedure is to restore the intended outcome, not to increase the number of financial records until a response looks successful. Test the behavior using an authorized non-production setup or the permitted testing process. Submit an event, repeat its delivery and examine whether the recorded outcome remains consistent with one event. Then use a genuinely distinct event identity to check the separate case. Include malformed and unauthorized requests so a success-path test does not hide problems in error handling. A useful test records what was received, how it was classified and which financial effect followed. Avoid assuming that a successful HTTP response alone proves the accounting behavior you intended. When a discrepancy is found, preserve the references needed for reconciliation and explain the sequence of attempts. Changing identifiers after the fact can make the issue harder to understand. Review the sender's retry behavior and the receiver's handling together, because the boundary between the two is where event meaning is established. Reliable conversion accounting comes from stable event identity, explicit validation and traceable processing. The practical goal is straightforward: retries should preserve the original action's meaning, while new actions should remain clearly distinguishable.

Keep repeated event delivery separate from repeated financial effects

Comments