Tracking Referrals End to End: Links, Cookies and Attribution

Cookies are no longer something you can count on for referral attribution. Safari's tracking prevention blocks all third-party cookies by default and caps JavaScript-set first-party cookies at 7 days, or 24 hours for link-decorated traffic; Firefox partitions cookies per site by default; and Google confirmed it would maintain third-party cookie choice in Chrome rather than roll out a new standalone prompt the Extole cookieless tracking guide. Privacy law adds a second constraint: GDPR in Europe and CCPA in California require consent before setting many types of cookies, and EU regulators jointly issued over 1.2 billion euros in GDPR fines in 2024, subject to appeal the Extole cookieless tracking guide.

The resilient pattern uses three layers, and you should build all three rather than picking one:

The URL parameter is the source of truth at the moment of arrival. On the landing page, read it, validate it against your referrers table, write it into a first-party cookie, and immediately attach it to the session or server-side identifier you will use at signup. The cookie exists only to bridge page views where the parameter is no longer in the address bar.

The server-side event is what closes the loop. Server-side attribution means recording the referral event on your own servers rather than in the visitor's browser, sent from your systems to your platform via an API, so the data survives browser limits and ad blockers the Extole cookieless tracking guide. Fire it from your signup handler, not from the client, so a blocked script cannot erase a legitimate referral. A minimal payload looks like this:

{
  "event": "signup_completed",
  "signup_id": "s_88213",
  "account_id": "acct_4410",
  "ref_code": "AB12CD",
  "ref_source": "cookie",
  "clicked_at": "2025-03-04T10:12:44Z",
  "signed_up_at": "2025-03-04T10:19:02Z",
  "consent_referral": true
}

A worked example of why all three layers matter. Suppose 1,000 people click referral links in a month, and 60 percent of clicks are in Safari or Firefox. If you rely on third-party cookies only, a meaningful share of the 24-hour link-decorated cap cases will fail. If you pass the parameter to signup and fire server-side, the only loss is people who click a link, leave, and return more than 7 days later without the URL. You can measure that gap directly: compare signups where ref_source is url against those where it is cookie and those where it is none. The none count is your floor of unattributed referrals, and it should be small and stable.

If you are building this plumbing yourself rather than patching a third-party platform, Quanta can take a written spec for the tracking service and build it with you, including the cookie handling and the server-side signup event.

Two codes on one signup is normal, not an edge case. A person clicks a friend's link on Monday, ignores it, clicks a different friend's link from a group chat on Wednesday, and signs up on Thursday. Both codes exist in your logs. You need a written rule, applied by code, not by judgment.

The three defensible rules are:

• Last code entered wins. The most recent code before signup gets credit. This matches the intuition that the last nudge caused the conversion, and it is simple to explain to customers. It can reward a referrer who did very little.
• First code seen wins. The earliest code in the window gets credit. This protects the original advocate and discourages code sniping, where someone pushes their code at people who are already about to sign up.
• First touch in a rolling window, tie broken by last touch. The code seen first within, say, 30 days wins, unless it has expired, in which case the most recent valid code wins. This is more work but avoids the "I referred them six months ago and never spoke to them again" complaint.

Whichever you pick, write it into the program terms. Referral Factory's guidance on program best practices emphasizes clear rules as a foundation for programs that scale the Referral Factory best practices guide. Whatever you choose, the tie-break must be deterministic and reproducible from stored data alone.

Here is a decision rule worth adopting: choose last code entered wins when your reward is small and your sharing is frequent (consumer apps, ecommerce), because speed and simplicity matter more than perfect fairness. Choose first code seen wins when rewards are large or your advocates are B2B partners who invest real effort in an introduction, because the effort, not the last click, is the contribution.

The data model that makes any rule auditable:

create table referral_touches (
  id            bigserial primary key,
  visitor_id    text not null,
  ref_code      text not null,
  seen_at       timestamptz not null,
  source        text not null  -- 'url' | 'cookie' | 'manual'
);

create table signup_attribution (
  signup_id     text primary key,
  winner_code   text,          -- null if unattributed
  rule_applied  text not null, -- e.g. 'last_touch_30d'
  decided_at    timestamptz not null
);

Every touch is written as an append-only row with a timestamp. The winning code is computed once at signup and stored with the rule name, so six months later you can explain any payout without re-litigating history. When a support ticket arrives, you show the customer their own touch list with times, which ends most disputes quickly. Note also that self-referral and fraud are the real margin risk in two-sided programs: without strict rules for what counts as a valid conversion, who qualifies as "new," and how many rewards one advocate can earn, programs attract self-referrals and leakage the Voucherify guide to double-sided referrals. A duplicate-code case is usually an accident; a pattern of duplicates from one device is a signal.

Payout reports drift from signup records for four reasons: the report counts rewards, the signup table counts people; reversals (refunds, chargebacks, cancellations) land in one but not the other; a retry in the payout job pays twice; a manual adjustment gets forgotten. Reconciliation is therefore a join, not a vibe check.

The check runs in three passes.

First, one winning code per paid signup. Join the payout table to the signup table on signup ID and confirm each paid signup has exactly one row in signup_attribution and that its winner_code matches the code in the payout. Any signup with a payout but no attribution row is a bug in the event pipeline. Any signup with a payout and two attribution rows means your signup handler is not idempotent.

Second, no winning code goes unpaid. The reverse join finds attributed signups with no payout row after your qualified period elapses. Referral economics depend on paying only for conversions you define, so a missing payout is often a qualification rule working as intended, but you need to see the list to tell the difference the Salesforce referral guide.

Third, no payout without a qualifying event. This catches manual payouts and reversals that were never applied. A reconciliation query looks like this:

-- one winning code per paid signup
select p.signup_id, count(*) as payout_rows
from payouts p
join signup_attribution a on a.signup_id = p.signup_id
group by p.signup_id
having count(*) <> 1;

-- paid signups with no attribution
select p.signup_id
from payouts p
left join signup_attribution a on a.signup_id = p.signup_id
where a.signup_id is null;

Run both queries before every payout cycle and keep the outputs for a year. The count of rows in each result is a run metric: a jump means something in the pipeline changed. This matters because referral value is real and measurable. In a study tracking roughly 10,000 customers of a German bank for almost three years, referred customers had a higher contribution margin and a higher retention rate, and the average referred customer was at least 16 percent more valuable than a similar nonreferred customer the Wharton referral program study. If you are paying for referrals, you want the paid set to match the set you are measuring.

A simple worked example. A month closes with 4,000 rewards paid and 3,960 attributed signups. The 40-row gap splits into 25 refund reversals that were queued but not applied and 15 retries that paid twice. Fix the reversal job, refund the 15 duplicate payouts, and add a unique index on payouts(signup_id) so a retry fails loudly instead of quietly. From then on, the first query should return zero rows on every run.

Reward design and attribution design are coupled: the more you pay per referral, the more correctness matters. Double-sided programs reward both the referrer and the friend. Referral Factory reports that over 90 percent of the programs run on its platform are double-sided, and argues the reciprocity makes sharing feel like a gift rather than a pitch the Referral Factory double-sided guide. A double-sided reward can be identical for both parties or different, for example a gift card for the referrer and a discount for the friend the Referral Rock rewards guide.

Before you set a number, size the reward against what a referred customer is worth to you. Customer lifetime value is conventionally computed as average order value times purchase frequency times customer lifespan minus acquisition cost; worked example from one guide: spending 50 to acquire a customer who spends 100 per purchase, three times a year, for five years yields a lifetime value of 1,450 the Mention Me lifetime value guide. Note the arithmetic is stated in the guide's own example, so redo it with your own numbers rather than borrowing theirs.

A decision rule for the reward ceiling: set the total two-sided reward at no more than half of the first-year contribution margin of a referred customer, and set the qualification event where fraud is cheapest to detect. If you reward on signup, self-referral is trivial to attempt; if you reward on first payment, the reward is smaller because fewer signups qualify, but every payout maps to real revenue. The Voucherify analysis is blunt on this: double-sided referrals are not twice as expensive unless you design them that way, and the real risk is weak validation and missing guardrails the Voucherify guide to double-sided referrals.

Whatever you choose, the qualification event must be recorded in the same server-side pipeline that fires the signup event, so the payout table and the signup table speak the same language. If your qualification is "first payment within 60 days," store that timestamp on the signup record, not only in the payments system.

If your next step is deciding which referral value metric to optimize and which experts should own the payout policy, Quanta Experts can take your context, work it and hand back a finished deliverable such as a reward-policy memo or a reconciliation runbook. And if you have coding agents building or maintaining the tracking service, Quanta Intelligence skills for coding agents keep them working from the same definitions of winning code, qualification and payout.

Before you turn the program on, verify each of these items. Each one maps to a failure seen in practice.

Two final habits pay off. Keep the touch log append-only: never update a row, only insert, because the whole point is to be able to replay the decision. And measure your unattributed share monthly. Referral Factory's core thesis that referrals are exceptionally cost-effective applies only when you can actually see which referrals happened the Referral Factory best practices guide. An unattributed share that creeps up means one of the three layers has quietly stopped working, and the reconciliation queries will not catch it, because they only see signups you already attributed.