Conversion Deduplication

In affiliate marketing, conversion deduplication prevents multiple records of the same eligible action from producing duplicate conversions or commissions. It is needed when events are retried, thank-you pages reload, or browser and server tracking report the same order. The matching key and event scope must distinguish duplicates from legitimate repeat activity.

Why can the same conversion arrive twice?

A customer may refresh a confirmation page, a server may retry a timed-out request, or a program may use browser and server delivery together. Two integrations can also submit the same business event. These are delivery scenarios, not necessarily two different purchases.

Duplicate event versus legitimate new event

The desired treatment depends on which action is commissionable. A program paying separate eligible events from one order may need more detailed keys than an order-only program.

What should the key contain?

Use stable source identifiers and appropriate scope, such as merchant account, event type, and transaction or invoice ID. Do not use a timestamp alone: separate events can share a time, and retries can arrive later. Keep matching rules consistent across integrations.

What should be tested?

• Repeated delivery with identical data.
• Browser and server events arriving in either order.
• Concurrent requests for the same action.
• A new order or renewal for the same customer.
• A corrected amount or later refund.

Decide which source is authoritative if two reports disagree. Silently accepting the first event may retain the wrong amount, while accepting both may overpay. Deduplication resolves event identity; validation resolves the business eligibility and correct values.

What does it not solve?

Deduplication does not determine which of two genuinely different referrals deserves credit. Nor does it establish that a transaction is real or a promotional method is permitted. Those questions need attribution and fraud-review rules alongside duplicate handling.

How can an administrator investigate a duplicate?

Compare the source identities

Look for the merchant, order or invoice, event type, original value, and delivery source. Two records arriving at similar times may be two real sales, while one action arriving several minutes apart can be a retry. Use the stable business identity rather than a time proximity rule alone.

Questions for a dual-tracking setup

1. Do browser and server reports use the same source order identity?
2. Are their currencies and commissionable values consistent?
3. Which source is authoritative if amounts differ?
4. How are updates distinguished from new conversions?
5. Are renewal and refund events identified separately?
6. Can the applied decision be reproduced from an audit record?

Post Affiliate Pro’s repeating-event protection documentation describes platform controls. Check their actual matching rules instead of assuming that one setting resolves every browser-and-server overlap.

What happens when the same event changes?

A correction can require an update rather than suppressing the second report entirely. For example, a $100 order might later have a $20 refund. The original sale should not disappear, and the refund should not become a new sale.

Stripe’s refund reference illustrates separately identified payment adjustments. Connect those source records to the appropriate original transaction and apply the affiliate policy. Deduplication needs to retain meaningful updates while preventing repeated reports from creating additional rewards.

Choose an identity for each commissionable event

A transaction ID is useful only within a defined scope. The same identifier might appear in different merchant accounts or event types. For subscriptions, use a billing event or invoice identity rather than suppressing every payment with the same customer or subscription ID.

In a hypothetical dual-tracking checkout, both the pixel and postback report order order-1042. The tracker should create one sale commission. A later eligible renewal needs its own identity; a refund needs an adjustment event tied to the original sale, not another sale.

Keep a record of accepted events and make retries idempotent. Stripe’s webhook guidance illustrates why event IDs and event context matter when deliveries repeat. Test concurrent arrivals and delayed retries as well as simple page refreshes.

For the corresponding Post Affiliate Pro settings, consult the fraud protection documentation . Confirm the configuration and integration requirements against your program’s rules.