OpenPartner
Sign in Start free
For brands For creators Storefronts New MarketplacePricing Resources DocsQuickstartAPI referenceEvaluating OpenPartnerBlogChangelogRoadmap
Join as a creator Sign in
← Blog
brandsattributiontechnical

Affiliate tracking software: how tracking works in 2026, and what to check before you buy

Affiliate tracking software has one job: connect a partner's click to the revenue it led to. Browsers have made that harder every year. Here's how each tracking method works today, where each one loses sales, and the questions that show whether a tool will credit your partners for the customers they send.

By OpenPartner

Every piece of affiliate marketing software, from a $15-a-month plugin to an enterprise affiliate tracking platform, is built on the same promise: when a partner sends you a customer, the partner gets credit. Everything else, like the dashboard, the commission rules and the payouts, depends on that one link between a click and a sale holding up.

It’s harder than it sounds. The click happens on a partner’s site, a social app or an email. The sale might happen weeks later, on another device, after the visitor’s browser has cleared the storage that remembered the click. Browsers have spent years making it harder for one site to follow a visitor to another, on purpose. Tracking that worked in 2018 quietly loses sales today, and the partner never finds out why.

This post explains how affiliate tracking works in 2026, method by method, where each one loses sales, and what to ask a vendor before you trust it with your partners’ commissions. We build OpenPartner, which takes one particular approach. We’ll say where it fits, but most of this applies to any tool.

The job: connect a click to revenue

Strip away the features and affiliate tracking does three things:

  1. Record the click. Who sent the visitor, from which link, when.
  2. Carry the click to the conversion. Keep that information somewhere until the visitor signs up or buys, which can be minutes or months later.
  3. Credit the conversion, and everything after it. Tie the sale to the click, apply your attribution rules, and, for a subscription business, keep crediting renewals.

Step 1 is easy: the tracking link goes through a server that writes down the click. Step 3 is bookkeeping. Step 2, the gap between the click and the conversion, is the hard part. The methods below are different answers to the question of where the click is kept.

The original approach. The partner’s link goes through the tracking provider’s domain, which sets a cookie. When the visitor later buys on your site, a script on your checkout page asks the tracking domain, “did this browser click a partner link?”, and the cookie answers.

That cookie belongs to a third party: a different site from the one the visitor is on. As of October 2026:

  • Safari has blocked all third-party cookies by default since 2020.
  • Firefox has kept each site’s third-party cookies in a separate jar since 2022 (Total Cookie Protection), so a tracking domain can’t read the cookie it set while the visitor was on another site.
  • Brave blocks third-party cookies by default.
  • Chrome leaves the choice to users. Google dropped its plan to phase third-party cookies out in 2024 and, in 2025, decided against a new prompt asking users to choose. Chrome blocks them by default in Incognito, and users can block them in settings.

So third-party cookie tracking can still work for Chrome visitors who haven’t blocked them, and fails in Safari, Firefox and Brave. If a tool still relies on it, it’s losing sales, and it won’t tell you which.

Method 2: the click id in the URL, kept by your own site (first-party)

Here the tracking link records the click, then redirects to your site with a click id in the URL, like ?ref=abc123. A script on your site reads the id and stores it in a cookie or local storage on your own domain. That’s first-party storage, which browsers treat far more kindly than the third-party kind.

It still has limits:

  • Safari deletes script-written storage after 7 days. Cookies created by JavaScript, and local storage, are deleted after seven days of Safari use without the visitor interacting with your site. A visitor who clicks today and comes back to buy in three weeks may arrive with nothing stored.
  • Sometimes it’s 24 hours. WebKit’s documentation describes a one-day cap on cookies your scripts create on the landing page, when link decoration is detected. Its 2019 write-up of the rule gives the conditions: the visitor was sent there by a domain Safari has classified as a tracker, and the URL has a query string. A redirect through a tracking domain could be at risk, if Safari has classified it.
  • Server-set cookies are treated differently, with a catch. WebKit doesn’t list the 7-day cap for cookies your own server sets. It does document a 7-day cap on cookies set through a subdomain that really points at a third party’s servers, by a CNAME or a third-party IP address. If a vendor puts its tracking “on your domain”, ask whether it works that way and how they’ve tested it in Safari.
  • Some click IDs get stripped. Safari’s Link Tracking Protection removes a list of known tracking parameters from URLs in Private Browsing and links shared in Messages, and in normal browsing only if the user turns it on. Firefox strips a similar list in Strict mode. Brave strips 65 known parameters by default, including impact.com’s irclickid. None of these strips arbitrary parameters, but a vendor’s click ID with a well-known name can disappear before your page loads.
  • It can’t cross devices. Storage on a phone isn’t visible on a laptop.

First-party tracking is the right default, but on its own it has a time limit and it can’t cross devices. The longer your buying journey, the more those limits matter.

Method 3: tie the click to the customer’s account (identity stitching)

This step is easy to miss in a comparison. When the visitor creates an account, or signs in, on the browser that still holds the click id, your app tells the tracking system: this click belongs to user 4821. From then on, the click is attached to the customer, not to a browser.

What that fixes:

  • Storage limits stop mattering. Once the click is tied to the account, it doesn’t matter if the browser clears storage a week later. Payments are credited by user id.
  • Devices stop mattering. The customer can click on a phone, sign up on that phone, and pay from a laptop. The payment arrives with the user id, so the partner is credited.
  • Renewals keep working. A renewal in month 14 arrives from your billing system with the customer’s id, not from a browser, so there’s nothing left to expire.

What it doesn’t fix: the click still has to survive until the account exists. If the visitor clicks on their phone and signs up on a laptop, this flow can’t connect the two, unless they later sign in on the phone or use the partner’s code. A trial or a free signup early in the journey helps, because it creates the account while the click is fresh.

It does need one line of work from you: calling the tool’s identify function, or its API, when an account is created. Ask whether the tool supports it at all.

Method 4: server-to-server (postback) tracking

Some conversions happen where no tracking script can run: a lender funds a loan, a sales rep closes a deal, a partner’s own system records a sale. In server-to-server tracking, the click id travels with the lead or order through those systems, and the system that sees the conversion reports it with the click id. Nothing in the browser is involved.

Performance marketing platforms use it heavily. Everflow, for example, recommends server-to-server postbacks or its JavaScript SDK, and advises against a plain HTML pixel. With a postback, the advertiser’s server sends the conversion, with the click ID, straight to the tracking platform’s server.

Once the click ID has reached your systems, reporting the conversion no longer depends on any browser. It does depend on every system in the chain keeping the click id, which takes some integration work.

Method 5: coupon codes

The partner gets a code, like ADA20, and any purchase that uses it credits them. No click, no cookie, no browser: the code itself is the tracking. It suits podcast and video sponsorships, where listeners type a code rather than click a link.

The trade-off is leakage. Codes get posted on coupon sites, so a customer who never heard of the partner can still credit them. And a customer who heard the partner but forgot the code credits nobody. Codes work best alongside links, not instead of them.

What else loses sales

Even with good tracking, a few things cost partners credit:

  • Ad and tracker blockers. uBlock Origin turns on the EasyPrivacy list by default, and EasyPrivacy blocks the domains and scripts of several affiliate networks and tools, including impact.com, Awin, CJ, Rakuten, Tapfiliate, FirstPromoter and Tolt. uBlock’s own privacy list goes further for some networks’ links: it skips the tracking redirect and sends the visitor straight to the destination, so the click is never recorded. A script loaded from a vendor’s domain can be blocked. Reading the click ID on your own server doesn’t depend on a script loading, as long as the click ID reaches your server.
  • Redirect chains that drop the parameter. If your landing page redirects (say, from example.com to www.example.com/en/) and the redirect drops the query string, the click id is gone before your script runs. Test every partner landing page.
  • Checkout on a different domain. If your marketing site and your app or checkout live on different domains, storage on one isn’t visible on the other. The click id has to be handed over, in the link or through your server.
  • Consent. If your site waits for consent before storing anything in the visitor’s browser, a visitor who declines leaves nothing there to carry the click id. Reading it on your server at signup doesn’t depend on browser storage. Whether you need consent, and for what, is a question for your own legal advice.

What to check before you buy

Bring these questions to any affiliate tracking software demo or trial:

  1. Where is the click kept between the click and the signup? A third-party cookie is a red flag. First-party storage on your domain is the baseline.
  2. Can the click be tied to the customer’s account at signup? Without it, every renewal and cross-device payment depends on browser storage.
  3. How do renewals get credited? By customer id from your billing system, or by looking for a cookie again?
  4. Can conversions be reported from your server, by click id or user id? You’ll need this for sales-led deals, offline conversions and anything a script can’t see.
  5. Are coupon codes supported, and do they appear in your billing system automatically?
  6. What’s the attribution window, and is it a policy or a cookie lifetime? “90-day cookie” means little if the browser deletes the cookie after seven days. A window is a rule about which clicks may win; it should be separate from how long storage lasts.
  7. Can you see the raw click and event behind each commission? When a partner disputes a missing sale, that’s what you’ll need.
  8. What happens without consent? Can tracking work from your server alone?

How OpenPartner tracks

For transparency, here’s the approach we took, in the terms above:

  • Click: partner links go through our click router, which records the click and redirects to your site with the click id as cref in the URL, or in any parameter your destination already reads, using a {click_id} macro.
  • Between click and signup: the optional script or SDK keeps the click id in first-party storage on your domain, which is subject to Safari’s limits above. Or skip the browser entirely: your server reads cref from the signup URL and passes it on, which also makes it easy to wait for consent.
  • At signup: your app calls identify with your user id, which can be pseudonymous, and the click is tied to the account. From then on, conversions are credited by user id, on any device, with no cookie involved.
  • Conversions: reported from your server, or read from your own Stripe account by the OpenPartner Stripe App, which is in beta. Systems that only know the click id, like a lender or a CRM, can report by click id. Partner coupon codes credit the partner too. With Stripe connected and a customer discount on the program, each partner’s code is created in your Stripe for you.
  • Window and renewals: the attribution window is a per-program rule, from 1 to 365 days (60 by default), measured from the click to the first conversion. Renewals then stay with the partner who won the customer, by default.
  • Audit: raw clicks, identities and events are kept next to the attributions and commissions derived from them, so any commission can be traced back to its click.

The details are in How attribution works and Cookies and cref. If you want to see it run, the pricing page has the plans: Revshare has no monthly fee, just 3% of partner-attributed revenue, or 10% of the partner’s commission when that’s higher.

Whichever tool you pick, run one test before you invite a single partner: click a partner link on your phone, sign up there, then pay on your laptop a day later. If the partner isn’t credited, find out why before your partners do.

Sources

Checked on October 23, 2026.