Your first affiliate site probably tracked itself without much effort. One domain, one analytics install, one set of links, and every click and sale belonged to the same place. Add a second domain and that arrangement stops working in ways that are easy to miss.
Browsers keep cookies and storage separate for each domain. A reader who visits your second site is a stranger to the analytics on the first, even though you know it is the same audience. Your affiliate network sees the same thing from its side: it receives a click and later a sale, with no idea which of your sites sent the reader unless you tell it.

The usual fix is to identify the reader across sites with a shared tracker, a third-party cookie, or a fingerprinting script. That costs trust. Readers who find out that a niche hobby blog and a finance blog are quietly linked to each other do not usually react well, and browsers and privacy rules increasingly block this approach anyway.
You do not need to follow people to get a reliable picture. You need to know which site and which page produced each sale. The rest of this article describes how to get that using labels you attach to your own links, data stored on domains you own, and plain wording about what you collect. This is affiliate tracking across multiple domains without a cross-site profile of anyone.
If you have not set up basic click and conversion tracking on a single site yet, start with how to track affiliate clicks and conversions, because everything below builds on it.
Decide what you actually need to know before you collect anything
Every data point you collect has to be explained in a privacy policy, protected, and eventually deleted. Collecting less is the cheapest way to stay trustworthy, so settle the questions first and let them decide the tools.
For a multi-site affiliate operation, the useful questions are usually these:
- Which site produced this sale?
- Which page on that site produced it?
- Which link on that page, for example a top-of-article button or a comparison table row?
- Which product or merchant did it go to?
- How much did it pay, and when was it approved?
Notice what is missing: who the reader is, what else they read, and whether they also visited your other sites. None of those change what you publish next. If a page’s links produce sales and another page’s links do not, you can act on that without knowing a single reader’s identity.
Write the list down, with each question next to the decision it supports. “Which page produced it” supports the decision about which articles to update or expand. “Which site produced it” supports the decision about where to publish next. Any data point you cannot tie to a decision is a candidate to leave out.
The dashboard audit article goes through which numbers predict profit, which is a useful filter here. If a metric does not change what you do, you do not need to collect the data behind it.
Sub IDs and link naming: attributing a sale to the right site and page without following the reader
Most affiliate networks and many direct programs let you add a sub ID to a tracking link. It is a short piece of text you choose, passed along with the click and returned to you in the conversion report. The parameter name differs between networks, and some limit its length or the characters allowed, so check the documentation for each program before settling on a format.
A sub ID is the clean answer to attribution because it travels with the click rather than with the reader. The label is attached to the link on your page. Nothing about the person is stored anywhere. When the sale comes back, the label tells you where the click started.
Build a naming convention you can read in six months
Decide one format and apply it to every site. A workable pattern has three parts:

- A short site code, such as
btfor a boot-review site orgdfor a garden site. - A page identifier, usually a shortened version of the URL slug.
- A placement code, such as
top,table,bodyorend.
Joined together, a link might carry bt-winterboots-table. In a conversion report, that single value tells you the site, the article, and which element the reader clicked.
A few rules keep the convention usable:
- Use lowercase letters, numbers and hyphens only. Spaces and symbols get mangled by some networks.
- Keep each value short enough to fit the strictest network you use.
- Never put anything about the reader in a sub ID: no email addresses, names, or user IDs. Sub IDs show up in reports and in the merchant’s systems.
- Keep a spreadsheet of site codes and placement codes so a new page or site gets a consistent label.
If you rename a page’s URL, decide whether the sub ID changes too. Keeping the old identifier preserves the history of that page’s sales. Changing it splits one page into two rows in your report. Pick one policy and note it in the spreadsheet.
Tracking at the link layer: redirects and link managers that keep data on domains you own
Typing sub IDs into hundreds of links by hand does not scale. A link manager or redirect layer lets you write the link once and add the labels automatically. It also creates a place to record clicks on a server you control.
The mechanism is simple. Your page links to something like yoursite.com/go/winter-boots. That address is a redirect on your own domain, which sends the reader on to the merchant’s tracking link with the right sub ID appended. The click is logged on your server at the moment of the redirect.

This arrangement keeps the data on a domain you own, and the reader sees a link on a site they already chose to visit. WordPress plugins such as ThirstyAffiliates and Pretty Links do this, and the comparison in ThirstyAffiliates vs Pretty Links covers how they differ. A hand-built redirect script works too, if you are comfortable maintaining it.
One redirect per site, or one shared redirect domain?
Running the redirect on each site separately is the more private choice. Each site logs its own clicks, and no single server sees traffic from all of them. The cost is that you maintain the setup several times and merge the logs yourself, which is covered below.
A shared redirect domain is easier to manage, but it means one server receives clicks from every site. That is acceptable as long as it records only what you decided you need and sets no cookie, because a cookie on the shared domain would be a cross-site identifier by another name. If you go this way, say so plainly in the privacy text of every site that uses it.
What a click log needs to contain
For the questions listed earlier, a click record needs four fields: the time, the link slug, the source site, and the source page. You do not need the reader’s IP address to count clicks per link. Your hosting provider may keep server logs that include IP addresses by default, so check how long they are retained and whether you can shorten that. Your own click table should not add anything beyond the four fields.
Consent and cookies: what to ask, when to ask, and what to do when a reader says no
This section is a practical setup guide and not legal advice. Rules differ by country and change over time, and your obligations depend on where your readers live and what you collect. If you are unsure, a short consultation with a privacy professional is cheap compared with fixing a problem later.
The practical principle is that a setup that collects less asks for less. A site that sets no cookies for affiliate attribution and logs four fields per click has very little to ask a reader about on that count. A site that runs advertising pixels, session recordings and cross-site identifiers has a long list to explain and a consent banner to match.
What to ask, and when
If your analytics or any plugin does set cookies or store data on the reader’s device, a consent banner should appear before that happens, not after. The banner needs to describe the purposes in words a reader can follow, and “reject” should be as easy to find as “accept”.
Be careful with banners that say “we value your privacy” and then list forty partners. If the honest answer is that your sites use one analytics tool and a redirect log, the banner can say that.
What to do when a reader says no
Design the setup so that a refusal does not break anything important. Sub ID attribution works without any consent-based storage, because the label is part of the link itself and the click is logged on the redirect. A reader who declines cookies can still click your link, still be attributed to the right page, and still be counted. The only thing you lose is the optional extra: for example, detailed behavioral analytics for that visitor.
Test this yourself. Open each site in a private window, decline everything, click an affiliate link, and confirm that the redirect works and the click appears in your log. If tracking only works when the reader accepts cookies, the setup depends on consent more than it needs to.
Writing privacy and disclosure text that matches what your setup really does
The most common trust problem with tracking is a mismatch: the privacy policy was copied from a template, and the site does something different. Readers rarely audit this, but regulators, networks and the occasional curious reader do.
Write the privacy text after the setup is finished, by describing what actually happens. Go through the tools in use and note, for each one, what it collects, where that data is stored, and how long you keep it. A good privacy page for an affiliate site covers:
- What the site’s analytics collects and whether it uses cookies.
- That affiliate links go through a redirect on your domain, and what the redirect logs.
- That the merchant or network may set its own cookies once the reader arrives on their site, and that their policy governs that part.
- How long you keep click logs, and how a reader can ask about their data.
- Whether your other sites share a redirect or a reporting tool, in a sentence that names that fact directly.
Each site needs its own policy that reflects its own setup, even if the tools are the same. A reader who lands on one site should not need to guess that a different site is involved.
Disclosure is a separate matter from privacy but belongs in the same review. The affiliate relationship has to be stated clearly near the links, on every site. The wording and placement are covered in the disclosure placement playbook. When you add a site, copy the placement pattern, and adjust the text so it describes that site’s actual programs.
Update the privacy text whenever the setup changes. Adding a new plugin or analytics tool is a change that belongs in the policy before it goes live.
Pulling every site into one report and checking it against network payouts
Once each site labels its links and logs its clicks, the remaining job is to combine the data. A spreadsheet is enough for most operations with two to five sites. Use one tab per source and one summary tab.
Pull three things into the summary:

- Clicks, from your own redirect logs, grouped by sub ID.
- Conversions and commissions, from each network or program’s report, grouped by the same sub ID.
- Pageviews, from your analytics, grouped by site and page.
Because the sub ID contains the site code, page identifier and placement, you can split it into three columns and then summarize by any of them. Sales per site shows where the operation earns. Sales per page shows which content to update first. Clicks per pageview for each page, set against sales per click, shows whether the problem is reader interest or the merchant’s landing page.
Reconcile against what the networks pay
Your click counts and a network’s click counts will not match. Bots, link prefetching, ad blockers and redirects that fail partway all create differences. Treat the gap as normal unless it is very large or suddenly changes.
Payouts are the number that matters, so check them every month:
- Compare approved commissions in the network report with the payments you actually received.
- Keep pending, approved and reversed commissions in separate columns. Pending sales may never be approved, so counting them as income overstates results.
- Look for sales that arrive with a blank or unrecognized sub ID. A growing share means some links are missing the label, often from a template, an old page or a link pasted by hand.
- Check that every program’s report returns your sub ID. If one network drops it for certain offers, you will need a different way to attribute those sales, such as a separate tracking link per site.
If one program does not support sub IDs at all, create a separate link or account setup for each site where the program allows it. That gives you attribution at the site level, even without page-level detail.
A maintenance routine for when you add the next domain
A tracking setup tends to decay as sites are added, plugins updated and templates changed. A short routine keeps it accurate.
When you add a new site:
- Assign a site code and record it in your naming spreadsheet.
- Install the redirect layer with the same slug pattern and the same click-log fields.
- Confirm each program’s sub ID parameter and length limit, and test one live click per program.
- Write the site’s privacy text from its real setup and place the affiliate disclosure near the links.
- Add the site’s clicks and pageviews to the summary report, then verify that a test click shows up in it.
Monthly:
- Reconcile approved commissions against received payments.
- Check the share of conversions with a missing sub ID, and trace any increase to its source.
- Skim the click logs for odd spikes, which can point to a bot or a broken link.
Quarterly:
- Reread each privacy policy against the current plugin list and analytics settings.
- Delete click logs older than the retention period you stated.
- Open each site in a private window, decline consent, and confirm attribution still works.
If you later move a program from a network to a direct arrangement, the labeling convention carries over, since the sub ID is yours. The considerations for that move are in when to leave the affiliate network and ask a brand for a private deal.
The same routine works whether you run two sites or six. The naming convention, the four-field click log and honest privacy text do the work, and they get no more intrusive as the number of domains grows.



