Your Terms Ban Browser Extensions. The Extension Never Signed Them. (#28)

TL;DR

Nearly every set of affiliate program terms I’ve read covers paid search and trademark bidding in forensic detail. Clause after clause on brand bidding, domain variants, ad copy, direct linking. Then nothing at all on browser extensions, sub-affiliate transparency, or what happens when a second partner claims a sale another one already earned.

That isn’t an oversight by any one brand. It’s inheritance. Program terms get adapted from a larger brand’s terms, which were adapted from somebody else’s, and the whole industry ends up defending against the same 2012 problems.

The obvious fix doesn’t hold on its own either. A clause saying partners must not override an existing click is aimed at the extension, and in every chain I’ve tested, the extension isn’t the party in your program. It never agreed to anything, because nobody ever asked it to.

What your terms actually bind is the sub-network whose ID appears in your report. They didn’t do the overriding.

So the clause that works doesn’t rely on prohibition. It makes payment conditional on an answer: tell me where this traffic came from, or don’t get paid for it. Below is the language, and the objection you’ll get the first time you use it.

The Clause Everyone Writes, and Why It Doesn’t Hold

Say you read the Trainline piece and decide to act. The natural response is to write something like this into your terms:

Partners shall not use browser extensions, toolbars or similar software to apply tracking to a user’s session.

Now follow where that lands.

In that test, the navigation went through six intermediary domains and ten redirects before it reached the merchant. The extension sat at the front of that chain. The party that appears in the merchant’s affiliate reporting sits at the back of it.

They aren’t the same company, and nothing I found connected them by ownership or shared infrastructure.

The extension didn’t apply to your program. It isn’t in your partner list, and in the chains I traced, its identity never reached the network’s reporting at all. Your terms are a contract, and a contract binds the people who signed it.

The sub-network that did sign is a monetization platform with a marketing site and thousands of merchants. It holds the network relationship on behalf of a large number of publishers at once. That’s a legitimate and genuinely useful structure, and plenty of the traffic running through it is entirely ordinary.

It also means nobody holds the whole picture. Each layer sees its immediate supplier and not the one above it, and the party with the clearest view of the traffic is the one earning on it.

So your new clause prohibits conduct by a company you have no contract with, and leaves the company you do have a contract with able to say, truthfully, that it did not do the thing you prohibited.

Responsibility Isn’t the Missing Piece

There’s a fair objection at this point. Make the partner responsible for everything its sub-publishers do, and the problem goes away.

That’s exactly what the Flow-down clause below does, and most networks already require something similar of the sub-networks they host. It’s necessary. It still isn’t sufficient.

Flow-down creates liability. It doesn’t create visibility.

A partner can be fully responsible for conduct four hops down its own supply chain, have no idea that conduct happened, and leave you with no way to show that it did. A prohibition you cannot show was broken is very hard to enforce, regardless of who’s liable for it.

The gap isn’t responsibility. It’s evidence.

Who Your Terms Actually Reach

You have no contract with the extension. You do have one with the partner being paid.

And there’s exactly one thing that partner can do which you cannot do yourself: tell you where the traffic came from.

That reframes the problem. Stop relying on a prohibition against behavior you cannot observe, performed by a party you have no contract with. Instead, require an account of every transaction you pay for, and make the commission conditional on getting one.

A partner who can explain their traffic is unaffected. A partner who cannot, or will not, stops being paid for the part they can’t explain.

That’s the whole mechanism. It isn’t aggressive, and it doesn’t require you to prove what happened inside somebody else’s browser.

The Language

I’m an affiliate manager, not a lawyer. This is the language I’d want in a program, written from two decades of watching which clauses get argued about and which ones hold. Have your own counsel look at it before it goes into your terms.

Six clauses. The first three set the standard, the fourth is the one with teeth, and the last two close the gaps.

Qualifying Click. A click is a Qualifying Click only where the user deliberately selected a promotional link or placement, understanding that doing so would take them to the Merchant. Tracking requests generated in the course of an onward redirect following such a selection remain part of that Qualifying Click. A tracking request initiated without such a selection is not a Qualifying Click, including one generated by a page load, by a script or extension activating by reference to the Merchant’s domain, by a hover, by an iframe, or by a dialog the user did not affirmatively accept. Commission is payable only on transactions preceded by a Qualifying Click, or attributed by a method the Merchant has approved in writing.

Displacement. Where a Qualifying Click is already recorded for a user within the attribution window, a subsequent tracking request does not displace it unless that request is itself a Qualifying Click. The Partner shall not cause or permit tracking to be applied to a user’s session other than in response to a Qualifying Click, or under an attribution method the Merchant has approved in writing. Approved methods follow the eligibility and priority rules agreed for them.

Disclosure. On the Merchant’s request, and within five business days, the Partner shall identify, for any transaction or session specified: (a) the publisher, sub-publisher or traffic source that delivered it; (b) the placement type and the URL or application on which the promotional link appeared; and (c) whether a user action was required for tracking to be applied, and what that action was. The Partner shall ensure the information provided is accurate and complete, shall produce the supporting records reasonably necessary to substantiate it, and shall retain those records for at least twelve months from the date of the session. Where identifying a sub-publisher would disclose personal data, the Partner may substitute a stable identifier for that sub-publisher, provided it confirms that the identifier refers to the same party across every request. This obligation extends to the identity of businesses in the Partner’s supply chain and the placements they operate. It does not require the Partner to disclose personal data relating to any individual user.

Forfeiture. Commission on any transaction for which the Partner does not provide the information and records required under Disclosure or Click path, within the period stated, is forfeit and may be reversed by the Merchant. The same applies where a response is materially false or incomplete. This applies equally where the failure is a refusal, an inability, or a lack of visibility into the Partner’s own supply.

Flow-down. The Partner shall impose obligations no less onerous than these on every sub-publisher and traffic source it permits to promote the Merchant, and remains responsible for their conduct as if it were its own.

Click path. The Merchant may require the Partner to demonstrate, within five business days, the full click path for a sample of transactions, including every intermediate redirect. The Partner shall retain records of the path in use at the time of each transaction for the period set out in Disclosure, and shall produce them on request. A demonstration of the path in use when the request is made is not, by itself, evidence of the path used historically.

Two parts of that are doing most of the work.

The last sentence of Forfeiture closes the most common exit a partner has. Without it, “we asked our sub-publishers, and they didn’t tell us” is a complete answer. With it, their visibility problem becomes their commercial problem rather than yours.

And the closing lines of Disclosure pre-empt the objection you are definitely going to get.

They Will Say Privacy

I have asked affiliates and sub-networks for traffic source detail many times over twenty years. Most requests get no answer at all. When one does come back, it is almost always a refusal, and the reason given is almost always privacy.

It sounds unanswerable, which is why it works. It shouldn’t.

You’re not asking for user data. No names, no email addresses, no IP addresses, no device identifiers. You’re asking which business delivered a session and what kind of placement it ran on. That’s a commercial fact about a supply chain.

As I understand it, and I’m not a lawyer, data protection law protects people rather than companies. GDPR and CCPA are built around personal data relating to identifiable natural persons. The trading identity of a company in a commercial supply chain doesn’t obviously sit inside that. If a partner tells you it does, ask which provision they’re relying on. The answer, or the absence of one, will tell you a lot.

The edge cases are real, and they have workable answers. Where a sub-publisher is an individual trading under their own name, the name itself may be personal data. Placement URLs can carry parameters that tie back to a person. And swapping a name for a stable pseudonym doesn’t make the question disappear, because pseudonymized data is still personal data in the hands of anyone who holds the key.

So ask for what you actually need. A stable publisher identifier, the placement type, and a URL with user-level parameters stripped out. That tells you which source the partner is reporting and where the placement sat, without anyone handing over a shopper’s browsing history.

It doesn’t tell you what fired in the browser, or when. A source name and a placement URL can’t establish that. The supporting records sometimes can, if a partner’s logs run deep enough. But the contract and the controlled test are separate tools doing separate jobs, and confusing them is how people end up disappointed with both.

Offer that version in the same message you send the request. It takes the common form of the objection off the table, and the reply tells you something either way.

Then ask about the real reason. A sub-network’s supply list is its business. If you knew who its publishers were, you could go direct. That’s a legitimate commercial interest, and it’s worth getting on the table, because then you’re having an honest negotiation rather than a legal argument neither side believes.

Sometimes the refusal is genuine. A partner may have real confidentiality obligations to its own suppliers, or may simply never have kept the records. Those are reasons. None of them is an entitlement to be paid on a transaction nobody can account for, and that is the point of the clause. You never have to decide whether a refusal is honest.

That’s where Forfeiture does its job. It never forces anyone to disclose anything. It prices the decision not to.

A partner who would rather protect its supply list can carry on doing exactly that. It simply isn’t paid for transactions it declines to account for. Nobody has to be accused of anything, no one has to prove what happened inside a browser, and the conversation stops being a fight.

What This Doesn’t Do

It doesn’t catch anyone. These clauses create an obligation and a consequence. They don’t tell you what fired in a user’s browser, and no contract can. For that you need a controlled test: a clean browser profile, a run with and without, and a record of what the browser actually requested.

It only works going forward. The requirements apply to activity after your new terms properly take effect, so set an effective date and decide explicitly how pending and already-approved transactions are treated. Expect a notice period for existing partners, and expect to negotiate it with the larger ones.

Your network agreement sits above your program terms. This is the one that catches people out. Validation timing, the grounds on which you can reject a transaction, and whether you can recover a commission that has already been approved and paid are usually governed by the network’s agreement rather than yours. A five-business-day disclosure window is no use if transactions auto-validate in three. Check the holds, the validation period, and the rejection grounds you actually have before you write a deadline that assumes them.

Check what your network shows you, and what your partner must keep. Those are different things. Some platforms expose sub-publisher identifiers, and some don’t, and a field your dashboard never displays may still exist in your partner’s own systems. The clause requires the partner to keep the record and produce it, not your network to surface it. Set that expectation prospectively, before you make it a condition of payment.

Most of your partners will not blink. A content site, a review publisher, an email partner: these can usually tell you where a click came from. But some legitimate publishers will struggle, because placements rotate and old campaign records go missing, and a sophisticated bad actor will answer smoothly. Treat the quality of the answer as the signal rather than the speed of it. What matters is the partner that repeatedly cannot account for its traffic at all.

It isn’t legal advice. Said once already, worth saying twice.

What a Merchant Should Do About It

Read your own terms today. Count the words spent on paid search. Then search the document for “extension” and for “sub-affiliate.” Most people are surprised, and it takes two minutes.

Add the clauses before you need them. The worst time to introduce a disclosure requirement is in the middle of a dispute about a specific transaction, when it reads as an accusation. Added as housekeeping, it’s a term.

Send one disclosure request this month. Pick ten transactions from your largest sub-network and ask the three questions. You will learn more about your program from the reply, or the absence of one, than from a quarter of reporting.

Decide what you’ll do with a refusal before you get one. If the answer is nothing, don’t send the request. A clause you won’t enforce is worse than no clause, because it tells your partners exactly how much your terms are worth.

Don’t write it at extensions. The mistake I see most often is naming the technology. Extensions are this year’s shape. Write it at the behavior, which is tracking applied without a deliberate user action, and the clause still works when the shape changes.

I’ve used a version of this approach on a program where coupon and cashback partners held 68% of attributed affiliate revenue. Six months later it was 19%. That came from the program’s existing terms, partner removal, and tighter approval standards working together rather than from the six clauses above, and those figures describe attributed revenue mix rather than a profit improvement. But the terms came first, because without them the other two are just an argument.

---

Written from program management experience rather than legal practice. Have your own counsel review any contractual language before adopting it, and check it against your network agreement. The browser extension findings referenced here come from my own testing, published in full across the previous pieces. Disclosure: Marcode and I have agreed a referral arrangement under which they pay me a fee on clients I introduce to them. They had no involvement in this piece.

Need Help Reviewing Affiliate Fraud and Leakage Risk?

Affiliate Manager Expert provides founder-led affiliate program management, audits, tracking reviews, compliance reviews, and program cleanup for SaaS, software, fintech, e-commerce, and digital product brands.

If you want to know what’s actually firing inside your program, I can help you review where it’s exposed: browser extensions, coupon leakage, partner overlap, sub-affiliate opacity, attribution rules, program terms, commission logic, and partner quality.

Book a free affiliate program review, and I’ll tell you what I find.