What an affiliate platform will not do for you, and what to build around it

The affiliate platform an agency buys — Impact.com, PartnerStack, CJ Affiliate, Awin, ShareASale or Refersion, to take the common names — is bought as though it were the whole system, and it is one component of about five. The other four are usually assembled by accident, from whatever was to hand, by whoever was free. This page is about those four: what they are, which of them you have to own rather than rent, how to tell when the answer is a spreadsheet, and which products sit in each layer. No platform is ranked here, for reasons set out below; a product named on this page is an example of a layer, not a winner.

What to take away

Why no ranking is offered

A ranking implies the products are substitutes. Across this set they are not: what an agency needs from the reconciliation layer depends entirely on what its client's finance function already runs, and what it needs from storage depends on how many programs it operates. Two agencies with identical partner programs can correctly reach opposite conclusions.

Rankings also age at the speed of the market rather than the speed of the page. Any list that claims a current order is either being rewritten continuously or is stale, and you cannot tell which from reading it. What can be written down is the shape of the decision, and which product belongs to which piece. The chain the platform itself covers is a click becoming a payout, and it ends where the four pieces below begin.

The five pieces, and who owns each

The bottom two rows are where agencies lose the most. Both are dull, neither is a product decision, and both are what makes leaving a platform possible. A record you can read after the subscription ends is the whole of data portability in practice, and an export you have never opened is not one. The recruitment row above is a sourcing job of its own, with intermediaries and economics to match, set out in the guide to creator marketplaces.

Which products sit in which layer

The tracking layer is sold by the platforms themselves. Impact.com, PartnerStack, CJ Affiliate, Awin, ShareASale and Refersion are the common names an agency is choosing between, and what decides between them is commercial rather than technical: Impact.com and PartnerStack sell partner management software around the tracking, while CJ Affiliate, Awin and ShareASale are affiliate networks first, and Refersion is built for smaller merchants with their own checkout. Recruitment has its own products on the creator side — CreatorIQ, Aspire, Grin, Upfluence, Izea and Traackr — none of which is a partner platform, and none of which will reconcile a payout. For the smallest programs the tool is Google Sheets or Excel, and that is a legitimate answer rather than a fallback. The reconciliation layer is the one with a real build-or-buy question, and it is treated below.

Payments and tax: who files what

Payment handling is the layer people assume is included, and the tax half of it is where that assumption gets expensive. In the United States the payer of partner commissions is the one who collects a W-9 from a domestic partner and a W-8BEN or W-8BEN-E from a partner abroad, files Form 1099-NEC for nonemployee compensation, and answers to the IRS for that reporting. Where a client's own sales tax or marketplace-facilitator obligations touch the program, that is a state question, and no platform answers it for you.

What to standardize and what to let each team pick

The instinct in an agency is to standardize everything, and it is half right.

Standardize the things that make an account transferable: naming conventions, the rule document, the reporting layout, the review cadence, and the location of the written record. A new person should be able to pick up any program on a Monday and know where to look. That is worth a real amount of money and it is invisible until somebody leaves.

Let each account keep the things that touch the client's own systems: the export cadence their finance calendar needs, the fields their checkout can carry, the report format their team already reads. Forcing uniformity there converts a small monthly inconvenience for you into a permanent manual step for them.

The middle case is the interesting one. Where a team has quietly built something outside the standard because the standard did not fit, the useful response is to find out what it does before removing it. Unrecorded workarounds are the visible part of shadow work, and they are usually a symptom of a real gap rather than a discipline problem.

Build against buy, honestly

The reconciliation layer is where this question arrives, because the platform's report and the client's ledger never agree by themselves. Which account of the month is the true one is the question the guide to measurement tooling works through.

Buying means a managed pipeline such as Fivetran, Airbyte or Stitch landing in a warehouse such as Snowflake, BigQuery or Redshift, plus a recurring subscription that grows with volume. Building means a scheduled job somebody wrote, which works perfectly until the platform changes an export column. The cost of the build is not the build. It is the maintenance, the documentation, the day the schema changes silently, and the day the author leaves.

A fair test: would you still choose to maintain this if the person who wrote it were not here? If the answer is no, buy it or keep it manual, because a script nobody understands is worse than a spreadsheet somebody does. Accumulated shortcuts of that kind are technical debt with no engineering team attached to service it, which is a worse position than the same debt inside a software company.

The spreadsheet is a legitimate finalist

For a program with few partners and a predictable month, a maintained spreadsheet plus the platform's own export outperforms most of what you could buy, because the failure mode is visible and anyone can fix it.

Put it in the comparison on purpose. A comparison with no cheap option in it concludes with a purchase every time, which is the structural flaw in feature grids described in the guide to structured supplier comparison. The point at which the spreadsheet genuinely fails is worth naming in advance: usually the month when two people need to edit it at once, or when a client asks a question about a period nobody archived.

What none of these tools will do for you

Recruitment is a person writing to people. Rule enforcement is a person having a conversation nobody enjoys. Deciding what a partner type is worth is a judgment about your own margin. Checking whether the program adds sales at all is a test rather than a report.

Where the partners are creators, sourcing them has its own economics and its own intermediaries. Buying a partner platform and expecting any of that to be included is the single most common disappointment in the category, and it is a reading error rather than a product defect.

Where the concern is whether traffic is real, that is a different product category with different evidence, treated in the guide to detection and audience quality.

Common questions

Do we need a data warehouse for this?

Not for one program. For several programs across several clients, some shared store beats eleven exports in eleven formats, and the deciding factor is usually how often somebody has to answer a question about last year.

Can the platform's own reporting be the client report?

It can be an input. Sending it unedited means sending the platform's account of its own performance, which is a fair thing to show and a poor thing to rely on.

What is the minimum we should own?

The tracking domain, a current partner list with contact details, and a readable copy of historical performance. With those three you can change platform. Without them you cannot.

Our client's finance team wants a different export format. Who pays for that?

Whoever asked, but agree it before launch. Retrofitting a format is a week of somebody's time and it recurs every time the platform changes an export.