Affiliate tracking is data processing. Every click on an affiliate link that lands on your domain records something about a person who has not signed up for anything, and you keep that record for months. It still needs a purpose, a lawful basis, a retention period, and a way to object.
Most founders build the tracking, paste a generic privacy policy and move on. Then an affiliate asks what you can see about their audience, and the honest answer is "more than I intended".
This post covers what tracking collects, which role you play under GDPR, what belongs in your affiliate terms, cookies and consent on your own domain, hashed IPs, data subject requests, and what is defensible at five affiliates versus five hundred.
TL;DR
- You are the controller for your affiliate program. Your affiliate is a separate controller for their own audience, and your billing provider plus your affiliate tool act on your instructions.
- Affiliate tracking collects more than a click id. Click id, timestamp, landing page, referrer, user agent, a hashed IP, and on conversion the buyer's email and order value.
- Non-essential cookies need consent in the EU. An attribution cookie is not strictly necessary to deliver the page, so it belongs behind a consent choice.
- Write down purpose, retention, lawful basis and an opt-out. A short privacy section inside your affiliate terms covers most questions.
- Complexity scales with affiliate count, not revenue. Five affiliates is a document plus a log. Five hundred is a process with a named owner.
What affiliate tracking actually collects
The click. When a visitor follows an affiliate link, your tracking layer records the affiliate code and a click id, a timestamp, the landing page URL, the referrer header, a coarse device signature, the visitor's IP address in raw or hashed form, and a value that ties a later purchase back to this click. Nobody has an account yet, and the visitor cannot see the record just created about them.
The conversion. When that visitor later pays, the billing provider sends a webhook: email address, customer or subscription id, plan, amount, currency, first payment or renewal, and later any refund. That is ordinary customer data with an obvious purpose, and it already appears in your main privacy policy.
The first set deserves its own paragraph in the policy, because the person being tracked has no relationship with you. We record that an anonymous click happened, which page it landed on, and we try to connect it to a purchase. In Sled, click IPs are stored as hashes produced with a per-deployment salt, and IP plus email rate limiting stops one source flooding the click table.
The three roles: controller, processor, and your affiliate
GDPR names roles, and getting them wrong puts the wrong promises in the wrong document.
You are the controller. You chose the tool and set the commission rules, so purpose, retention and data subject requests are yours to answer even when software handles the mechanics.
Your affiliate is a separate controller for their own audience. They built the list and chose to promote you, so their subscribers are their processing, not yours. Send them a spreadsheet of buyers so they can "follow up" and you have created a joint controller problem.
Your billing provider is a processor for the payment data it handles for you, and often an independent controller for its own fraud and tax duties. Card numbers never reach your affiliate tool: send the identifiers needed to match a sale and nothing more. The tracking tool sits in the same bucket, a processor on your documented instructions.
| Party | Role for the affiliate program | What that means in practice |
|---|---|---|
| You, the SaaS | Controller | You own the purpose, the retention policy and the response to any request. |
| Your affiliate | Separate controller for their own audience | Their privacy notice covers their list. Do not hand them buyer data. |
| Your billing provider (Polar, Stripe, Paddle) | Processor for your payment data, controller for its own compliance | Send only the identifiers needed to match a conversion. |
| Your affiliate tracking tool | Processor | It stores clicks and conversions on your instructions. You still answer the requests. |
| Your email, analytics or CRM vendor | Processor, and sometimes an independent controller | Do not inject affiliate ids into tools you never listed in the policy. |
Lawful basis: legitimate interest is not a blank cheque
You need a lawful basis for the click record. The workable one is usually legitimate interest: you have a real reason to know which marketing produced a sale, the data is minimal, and attribution is a common expectation of the web. That is an argument, not a magic word. Weigh necessity (could you measure with less?) against the visitor's interests (would they be surprised, and does this intrude on their rights?). Write the reasoning down, because it is what you produce if someone asks.
Consent is the right basis for the promotional side: emailing a referred lead about your product, or letting an affiliate email your customers, is marketing and needs an affirmative choice, not an inference from a click.
Turkey's KVKK has its own processing conditions and transfer rules and does not map one to one onto GDPR, so read current guidance instead of copying a GDPR template. In California, CCPA and CPRA give consumers a right to opt out of the sale or sharing of personal information for cross context behavioral advertising. Attribution inside your own program is a different case from passing click ids to an ad network, but the rule is the same: be explicit about what leaves your stack, and give people a way to say no.
What belongs in your affiliate terms or privacy section
Your main privacy policy covers your customers. The affiliate program needs its own short section, inside the terms or linked from them, because the people asking questions are affiliates and the people being measured are strangers. Six clauses do most of it.
| Clause | What to write | Why it matters |
|---|---|---|
| Purpose | "We record clicks on affiliate links and match them to purchases to calculate commission." | One sentence removes most of the ambiguity. |
| Data collected | Click id, timestamp, landing page, referrer, user agent, hashed IP, and conversion details. | Affiliates ask what you can see. Answering here saves support time. |
| Lawful basis | Legitimate interest for attribution, consent where cookies require it. | Shows you did the analysis instead of assuming. |
| Retention | Click records for a stated number of months, conversion and payout records for as long as tax rules require. | "As long as needed" is not a retention period. |
| Opt out | A contact address or link that lets a visitor refuse attribution tracking. | Turns the right to object into something operable. |
Two more details belong in the terms: a disclosure requirement, so the affiliate tells their audience they earn a commission, and a ban on passing buyer data around, because affiliates get a dashboard, not a list of your customers. The clause structure in our affiliate program terms template is a reasonable starting point.
Cookies and consent when the click lands on your own domain
Does the affiliate cookie need consent? In the EU, storing information on a visitor's device or reading it back is exempt only when it is strictly necessary for the service the visitor asked for. Someone who clicks a link asked for a page, not to be measured or attributed. So the attribution cookie is non-essential, and non-essential cookies need consent.
Patterns that work at indie scale:
- Put attribution in the same consent category as measurement, and make sure the banner actually stores and honours that choice.
- If the tracker can record the click server side and match it later without writing a cookie, the consent burden shrinks.
- Never pre-tick the box and never treat scrolling as consent. It must be freely given, specific, informed, unambiguous, and easy to withdraw.
- Keep the banner honest. A policy claiming only necessary cookies, next to a tracker that sets an attribution cookie, is a written statement your code contradicts.
One subtlety: the cookie is first party, which is healthier under browser rules and changes nothing for consent. First party and third party is technical. Essential and non-essential is the legal test.
Hashing and truncating IPs
An IP address is personal data in the EU when you can reasonably link it to a person, and a click record plus a purchase plus a support email is exactly that link. You rarely need the raw value.
| Form of the IP | What it looks like | What you can still do | What you lose |
|---|---|---|---|
| Full address | Four octets, exact | City level reporting, tight abuse detection | Your most identifiable single field |
| Truncated | Last octet zeroed | Country and region reporting, coarse abuse signals | City accuracy, some network level detection |
| Hashed with a per-deployment salt | Long opaque string | Match repeat visitors, rate limit, spot self referral patterns | Nothing you need, if the salt stays secret |
| Hashed without a salt | Opaque but deterministic | Very little | Anyone can brute force the IPv4 space and reverse it |
| Not stored | Nothing | Nothing | No rate limiting, no abuse detection, no self referral block |
Two rules make hashing useful. The salt must be per deployment and secret, because a shared salt is a lookup table waiting to happen. And you should be able to re-hash a value later with the same salt, which is how you answer a visitor's request without storing the raw address. Salt plus hash is pseudonymisation, not anonymisation, so the field is still personal data. It is a much smaller liability than a plain IP, and it is the default Sled ships with.
Retention: how long to keep each record
Retention is where affiliate programs quietly fail. Click tables grow forever because nobody owns them, and "we keep everything" is exactly the kind of storage that storage limitation rules exist to stop.
Match the period to the reason the record exists:
- Click records only need to live as long as your attribution window, plus a short buffer for disputes. Sled's default cookie window is 90 days, and the cookie window mechanics are worth understanding before you pick a number.
- Conversion records tied to commission need to survive long enough to calculate, claw back refunds and pay out.
- Payout and tax records outlive everything else, because that is a legal obligation. The tax form rules decide how long.
- Raw IPs, if you ever store them, should go first. Hashing at ingest means you never have a deletion problem here.
Write the schedule into the privacy section as concrete numbers. "Click data is deleted after twelve months, payout records are kept for seven years for tax purposes" is a sentence you can defend. A vague sentence is a question you will answer in writing eventually.
Data subject requests that arrive because of your program
The affiliate asks about their own account. They are your user, so this is a normal access request: what you hold, why, and who received it. Easy, because the affiliate dashboard is already most of the answer.
A referred customer asks about their data. If they bought from you, they are your customer and your main process applies. Their record may carry an affiliate code, so confirm the commission fact without disclosing another affiliate's numbers.
A visitor who never bought asks about the click. This is the one that surprises people. A click record with a hashed IP holds nothing else identifying, and a salted hash means you cannot search by the raw address until you hash it with the same salt. If the click never matched a buyer, deleting the row costs you nothing.
An audience member of your affiliate asks you, not them. You are not the controller for the affiliate's mailing list, so route the request to the affiliate and say so. Do not play middleman for data you never had.
The deadline under GDPR is one month, so the work happens before a request arrives: know where click data lives, who can query it, and how to delete one row.
Five affiliates versus five hundred
The law does not change with scale. The amount of process you need does, and founders either over-engineer a program with four affiliates or run five hundred with a spreadsheet.
| Question | Five affiliates | Five hundred affiliates |
|---|---|---|
| Terms | One page, sent by email, accepted in a reply | Self serve acceptance with version history |
| Consent and cookies | One documented decision, reviewed once | Documented decision, owned, reviewed on a schedule |
| Retention | Manual cleanup once a year | Scheduled deletion with a log you can show |
| Data subject requests | You answer the same day | A queue, a template, a named owner |
| Records of processing | A page of notes in the repo | A maintained document with dates and owners |
The threshold is not a number, it is the moment you can no longer answer "who has this data and why" from memory. For most indie SaaS that lands in the twenties, roughly when an affiliate program audit starts paying for itself.
A minimum viable privacy checklist
If you want the shortest defensible version, this is it:
- A paragraph in your affiliate terms naming the data collected, the purpose and the lawful basis.
- Concrete retention numbers for clicks, conversions and payouts.
- A contact address that works, with a note that requests get an answer within a month.
- A documented cookie decision: attribution is non-essential, so it lives behind consent, or it does not need a cookie at all.
- Hashed IPs with a per-deployment salt, not raw addresses.
- Self referral and disposable email blocking on, because gaming the program is a data quality problem as well as the fraud problem it looks like.
- Refund and clawback events wired to the same record, so a deleted customer does not leave a dangling commission.
- A short log of what you decided and when, kept next to the code.
Sled covers the mechanical half of this by default: hashed IPs with a per-deployment salt, IP and email rate limiting, self referral blocking, disposable email blocking, a 90 day cookie window and a 30 percent commission default you can change per tenant. When partners are paid in several currencies, payout handling adds its own records to keep. The documentation half is still yours, and it is a two hour job for a program with a handful of partners. The free trial is enough to start: 10 days of the full product with no card, then $19/mo on Pro, and a read only MCP server on every plan.
FAQ
Do I need a DPA with my affiliate tracking tool? Yes. The tool is a processor, so you need a data processing agreement covering purpose, sub-processors, retention and deletion. Most SaaS tools attach one to their terms, and it is a link, not a negotiation.
Is an affiliate's email list my responsibility? No. The affiliate is a separate controller for their own audience, so their list, their consent records and their unsubscribes are theirs. Your responsibility starts when their click lands on your domain.
Can I email a customer because an affiliate referred them? The purchase is the relevant fact, not the referral. Marketing to a referred lead needs a basis of its own, usually an affirmative opt in, and the affiliate cannot grant it on the customer's behalf.
Does deleting a customer delete the commission record? Not entirely, and you should say so. The link between a conversion and a payout usually has to survive for accounting and tax reasons, so keep the minimum fields, drop the identifying ones, and state that in your retention section.
Related reading: Cookie Windows and Attribution Explained covers how long a click counts, and Affiliate Program Terms Template has the clauses to copy. Ready to run affiliate tracking that hashes IPs out of the box? Start a free trial on Sled.