Affiliate de-duplication across networks

One Shopify order, two commissions, two invoices from two companies that have never spoken to each other. It is the quietest line item in a multi-network programme, because nothing in either network looks wrong: each one recorded a click and a sale, and each one is invoicing you correctly for what it saw.

This guide is for Shopify brands running more than one affiliate network, or one network with several publisher types. It covers how a duplicate claim happens, what network de-duplication actually covers, how to find duplicates in your exports and how to decline one without upsetting the publisher whose claim stays.

How one order gets claimed twice

A shopper rarely takes one path. A realistic January purchase:

1. She reads a review on a content site — a publisher on network A — and clicks through. Her session is tagged.
2. She leaves, thinks about it, comes back two days later and searches for a discount code.
3. She lands on a coupon site — a publisher on network B — clicks through and checks out.

Network A recorded a click and, inside its cookie window, a sale. Network B recorded a click and a sale. Both are right about their own data. You get two commissions on one order, plus each network's fee.

The same thing happens without two networks at all:

• A publisher's feed and its coupon page both fire, and the network records the transaction twice.
• An order is cancelled and re-created by customer service, and the re-created order tracks again.
• A subscription or a split shipment produces two transactions for one purchase.

What network de-duplication actually covers

Networks do de-duplicate — inside their own platform. That is a genuine protection against the same publisher claiming the same order twice, and it is worth having.

What no network can do is see the other network's data. There is no shared ledger of clicks between Awin, CJ, impact.com and Rakuten, and there is no reason there would be: they are competitors holding their own attribution. So a duplicate within a network is usually caught, and a duplicate across networks survives all the way to your invoices.

Both networks know this is your problem to solve, which is why both give you a reason to raise it. Awin lists a sale that came through the wrong marketing source among the legitimate reasons to decline.¹ CJ's correction file has a dedicated code for it: DUPO, a duplicate order.²

Finding duplicates by order id

The Shopify order number is the join. Every network export carries an order reference; for a correctly configured Shopify integration it is the order name or the order id.

Export pending transactions from every network for the same period, then:

1. Stack them. One sheet, one row per transaction, with a column for which network it came from. Keep the transaction id, order reference, transaction date, publisher and commission.

2. Normalise the reference. Strip a prefix or a # if one network stores #1041 and another 1041. This step is where most manual de-duplication quietly fails.

3. Count the claims per order. A pivot on the order reference, or:

   =COUNTIF(B:B, B2)
   

   Anything above 1 is a group to look at.

4. Sort by order reference so the competing claims sit next to each other, and read them as pairs: which publisher, what type, what date, how much.

Do this before the refund check, not after. A duplicate claim on an order that was also refunded should be declined once, for the clearest reason, not twice.

Which claim to keep

One claim should stand. The order happened, and somebody in the chain contributed to it — declining every claim on a duplicated order is how a programme loses its good publishers.

Decide the rule once and write it into your programme terms, rather than deciding case by case:

• Last click before the order. The common default, and the one that matches how most networks attribute internally. It usually favours the coupon or cashback publisher, which is worth being honest with yourself about.
• First click, or the content publisher. Some brands deliberately protect the publisher who created demand. If that is you, say so in your terms and expect to explain it every month.
• By publisher type. For example: a content publisher's claim outranks a coupon site's on the same order. Defensible, but only if it is written down.
• By network. Simplest to administer if one network is your primary and another is a small test, and the least defensible to a publisher on the wrong side of it.

Whatever you pick, apply it every cycle in the same direction. Publishers tolerate a rule; they do not tolerate a coin flip.

Two practical notes. Keep the claim on the network you would rather grow — you are paying a fee to that network either way. And remember the fee: the commission you see is not the full cost of keeping a claim.

Declining the other claim

Use the network's own mechanism and its own word:

And write a reason a publisher can check in a minute:

"Order #1041 was also claimed on [other network] by publisher 123456, tracked 12 January. Under our programme terms §5 the last click before the order is credited; this claim is declined as a duplicate."

That sentence does three things: it names the order, it names the other claim, and it points at the rule. A decline that does none of those reads as an arbitrary clawback, and Awin's own guidance is blunt about the consequence — "Inaccurate or unexplained declines can damage partner relationships."¹

If the publisher comes back with evidence that their click was genuinely last, take it seriously. A publisher arguing with a dated, specific decline is a conversation about attribution. A publisher arguing with a vague one is a conversation about trust.

Duplicates inside one network

These are rarer, because the network's own de-duplication catches most of them, but they do reach the pending list:

• The same transaction id twice in one export. Usually an export artefact rather than two claims. Check the pending list in the platform before declining anything.
• Two transaction ids on one order reference. Two tracked events for one purchase — a split shipment, a re-created order, a double-fired tag. One is real.
• The same order across two programmes on one network. Two brands or regions on one platform, if your orders share a numbering scheme.

The first is an export problem, the second is a tracking problem worth fixing at the source, and only the third is really a claim to correct.

What a click id would fix

Spreadsheet de-duplication answers "was this order claimed twice?" It does not answer "whose click was last?", because the click data sits inside each network and never leaves.

A first-party click id changes that: your storefront records every affiliate click — network, publisher, timestamp — against the session that eventually converts, and you own the order of events rather than reconstructing it. Then "last click before the order" is a fact in your own data instead of a rule you assert.

AffCheck's click-id pixel is planned rather than built, and this guide does not assume it. Everything above works with exports alone, which is the situation nearly every brand is actually in.

Questions

Two things worth settling before next cycle. Does your programme terms document say what happens when two networks claim one order? If not, that clause is the highest-value paragraph you will write this quarter. And do your networks store the same order reference? If one stores #1041 and another stores an internal id, fix the integration before you build a process on top of the mismatch.

More: reason codes explained, CJ commission corrections and duplicate claims across networks.