Exact vs Estimated Referral Matches: Evidence Fields

An exact referral match comes from evidence the person carried across the install: an invitation pasted on iPhone or the invitation inside the Play install referrer on Android. An estimated match comes from probabilistic matching on device signals, and it carries a confidence. Every referral records which one it is.

The difference decides how you pay. This guide defines each evidence field, shows where it appears in the webhook, and gives a rule you can paste into your reward logic.

The evidence table

Every referral stores a match object with a method, an exact flag, and a confidence. These are the values you will see:

confidence is 1 for an exact match and the matcher's score, a number between 0 and 1, for an estimate. The webhook event for an exact iPhone paste looks like this:

"match": { "method": "install_token", "exact": true, "confidence": 1 }

And an estimate:

"match": { "method": "probabilistic", "exact": false, "confidence": 0.82 }

Why exact is exact

An exact match does not guess. On iPhone, the invitation page copies an invitation that carries an install token. The person installs, taps the system paste button in your app, and the SDK hands that token to WarpLink. The token names one invitation, so the answer is one link. The paste step is covered in how a referral link survives the App Store install.

On Android, Google Play passes the install referrer to the SDK at first launch. The invitation rides inside it as the wl_rt value, so the SDK matches it with no screen of yours. Both paths put the proof inside something the install itself carries.

link_open is exact for a different reason. The person already had the app, so no install is involved. A tap on a referral link on that device is a record that the open happened. It counts only when Count people who already have the app is on for the app, which is off by default.

Why an estimate is an estimate

An iPhone install with no pasted invitation has nothing to read. We can still make a match from device signals: the request IP, the device language, and the timezone, hashed. That is probabilistic matching, and it returns a link with a confidence instead of a guarantee.

Estimates exist on iPhone only. They apply while the iOS handoff is off and probabilistic matching is on for the app. The claim goes out as a referral.claimed event with exact set to false and a confidence.

For referral rewards, the question is not an average. It is how much money you will pay on a single row, which is why the evidence flag exists. The method behind the general install match is on the attribution accuracy page.

What happens when an exact claim follows an estimate

A person can be credited once as an estimate and later claim again with an exact match, for example after they update to SDK 1.2.0 and paste the invitation. The referral keeps its id and moves to the exact link. We send referral.updated:

{
  "id": "evt_9d2f41ab_u",
  "type": "referral.updated",
  "data": {
    "referral_id": "ref_9d2f41ab",
    "reason": "exact_match",
    "previous": {
      "link": { "id": "0c4d9e21-1f8b-4e55-a0c7-6b2e7d3f1a44", "slug": "invite-ben" },
      "match": { "method": "probabilistic", "exact": false, "confidence": 0.82 }
    }
  }
}

The event id is the original id plus _u. The real event also repeats every field of data from the first one, with the new link and match. Treat previous as the old state to undo: take the credit from the previous link's owner and give it to the owner of the new link.

Two rules keep this stable. An exact claim is never replaced by an estimate. And a second estimate for the same installer stays a duplicate, recorded in the report with a link to the first referral, with no webhook.

Evidence class

The report and the API also carry evidence_class, a coarser label you can filter on:

Use exact in code that pays and evidence_class in reports that count.

A payout rule you can paste

This rule pays at once on exact evidence and holds estimates until they upgrade or a human checks them:

function rewardDecision(event) {
  const { match, flags } = event.data;

  if (event.type === 'referral.flagged' || flags.includes('outside_window')) {
    return 'review';
  }
  if (event.type === 'referral.updated') {
    return 'move'; // undo previous.link, credit data.link
  }
  if (match.exact) {
    return 'pay';
  }
  return match.confidence >= 0.8 ? 'pay_reduced' : 'hold';
}

The 0.8 threshold is an example, and the numbers are yours. Some teams pay a smaller reward on a high-confidence estimate and the full reward when the upgrade arrives. Others hold every estimate. WarpLink gives you the fields, and your backend applies the rule. The signature check that must run before this function is in verify a referral before you reward it.

How to raise your exact share

An estimate is an iPhone install with no pasted invitation, so each of these changes gives the person an invitation to paste. Four changes move them to exact:

1. Turn on the iOS handoff under Referral handoff, with an App Store URL on the app and an iOS build on SDK 1.2.0 or later.
2. Put the paste button on the first screen a new person sees, with a clear line such as "Did a friend invite you?"
3. Ship SDK 1.2.0 to every iOS build. Builds on 1.1.x keep working for links and installs but cannot read an invitation.
4. Keep the skip button. The paste step is an offer, not a gate, so sign-up stays open for every person.

Android needs no change. The Setup Check reports each requirement with the ids ios_recovery_store_url, ios_recovery_sdk, and android_recovery_fingerprint.

Frequently Asked Questions

What is the difference between an exact and an estimated referral match?

An exact match comes from evidence the person carried across the install: a pasted invitation on iPhone or the invitation inside the Play install referrer on Android. An estimated match comes from probabilistic matching on device signals, and it carries a confidence. The webhook says which one in match.exact.

Which devices produce estimated referral matches?

iPhone only. It applies while the iOS handoff is off and probabilistic matching is on for the app. Android referrals match exactly through the Play install referrer.

What happens when an exact claim follows an estimate?

The referral keeps its id and moves to the exact link. We send referral.updated with the new data, the reason exact_match, and a previous object that shows the link and match it replaced.

Can an estimate replace an exact match?

No. An exact claim is never replaced by an estimate, and a second estimate for the same installer stays a duplicate.

Related Guides

• The full path: Referrals covers links, claims, and the report.
• Privacy: Apple privacy rules and install matching.
• The install step: Make a referral link survive the App Store install.
• Install attribution in general: Install attribution without IDFA.
• Use case: App referral programs.

How WarpLink Helps

We record how every referral was matched and hand you the answer as a field, so your reward logic can treat an invitation pasted on iPhone differently from an estimate. When better evidence arrives, the referral upgrades in place and your backend hears about it.

One workflow, three pillars. Deep linking carries the invitation, install attribution credits the link that produced the new user, and real-time analytics shows referrals next to every other link. It covers installs that follow a tap on a WarpLink link, in any channel. Sub-10ms redirects on the way in, one SDK on the way out.

Create a free WarpLink account and get deep linking, install attribution, and real-time analytics in one SDK, with 10,000 clicks a month on the free plan.