Matching Engine Performance
How we connect a user's first click to their first app launch — even when the IP address changes, the browser hides fingerprints, or hours pass between the two events.
How It Works
When a user taps a Blainks deep link, the redirect page silently collects a set of browser signals — screen resolution, OS version, timezone, language, canvas fingerprint, and more. These signals are stored alongside the click record. Later, when the user opens the app for the first time, the SDK sends the same signals from the native side. The matching engine then scores each pending click against the claim and returns the best match above a configurable threshold.
Scoring Signals
Each signal carries a weight reflecting its reliability. The engine sums the raw scores, normalises to a 0–100 scale, and compares against the project's threshold. IP exact and IP subnet are mutually exclusive — only the better one counts.
Max possible score: 110 points (normalised to 100). The default threshold is 65, meaning a claim needs at least 65% signal agreement to be considered a match.
Confusion Matrix
We validated the engine against 1,200 synthetic click-claim pairs — 600 true matches (same device) and 600 true non-matches (different devices). Each pair was generated with a realistic device from a pool of 157 unique device classes across iPhone, Android, and iPad, spanning 10 locales from Istanbul to Tokyo.
| Engine: Match | Engine: No Match | |
|---|---|---|
| Actual: Same Device | 570 (TP) | 30 (FN) |
| Actual: Different Device | 10 (FP) | 590 (TN) |
Network Conditions
Real users don't stay on the same network. They switch from WiFi to cellular, use VPNs, or have Apple's iCloud Private Relay enabled. We tested every scenario:
| Condition | Pairs | Precision | Recall | F1 | FP |
|---|---|---|---|---|---|
| Same IP | 440 | 96.0% | 100.0% | 98.0% | 10 |
| CGNAT /24 Subnet | 190 | 100.0% | 100.0% | 100.0% | 0 |
| iCloud Private Relay | 270 | 100.0% | 100.0% | 100.0% | 0 |
| VPN | 110 | 100.0% | 100.0% | 100.0% | 0 |
| WiFi → Cellular | 110 | 100.0% | 100.0% | 100.0% | 0 |
| Relay + Degraded Signals | 80 | 100.0% | 0.0% | 0.0% | 0 |
Threshold Sensitivity
The match threshold controls the trade-off between precision and recall. A lower threshold catches more true matches but lets in more false positives. We tested every value from 30 to 80:
| Threshold | Precision | Recall | F1 | FP | FN |
|---|---|---|---|---|---|
| 30 | 71.0% | 100.0% | 83.0% | 245 | 0 |
| 40 | 81.4% | 100.0% | 89.8% | 137 | 0 |
| 50 | 94.6% | 99.8% | 97.2% | 34 | 1 |
| 60 | 97.6% | 95.0% | 96.3% | 14 | 30 |
| 65 (default) | 98.3% | 95.0% | 96.6% | 10 | 30 |
| 70 | 100.0% | 95.0% | 97.4% | 0 | 30 |
| 80 | 100.0% | 87.5% | 93.3% | 0 | 75 |
The best F1 (97.4%) is at threshold 70 with zero false positives and 95% recall. We ship at 65 as the default to give a small recall buffer for edge cases, but projects with strict fraud requirements can raise it to 70 or even 80 from the admin panel.
Time Decay Impact
The time proximity signal uses linear decay over a 24-hour window. A claim within a minute of the click gets the full 10 points; after 24 hours it drops to zero. Here's how time affects recall:
| Delay | Pairs | Recall | Avg Score | Note |
|---|---|---|---|---|
| < 1 minute | 187 | 92.5% | 87.5 | Best window — App Clips land here |
| 1 – 10 min | 176 | 94.9% | 88.7 | Typical install from store |
| 10 min – 2 h | 121 | 97.5% | 89.1 | User installs later, same session |
| 2 – 12 hours | 51 | 94.1% | 84.9 | Still solid |
| 12 – 24 hours | 44 | 97.7% | 84.4 | Low time bonus, fingerprint carries |
| > 24 hours | 21 | 100.0% | 80.2 | No time bonus at all |
Methodology
All numbers on this page come from an automated test suite running against the matching engine's scoring function directly — no database, no network, no mocks. The synthetic data generator produces deterministic pairs using a seeded random number generator (xorshift64, seed 42), so every run yields identical results.
The device pool covers 10 iPhone models × 10 locales, 8 Android models × 6 locales, and 3 iPad models × 3 locales — 157 unique device classes in total. Each device has a unique canvas fingerprint hash, as is the case in production (GPU + driver + OS build = unique rendering output).
True positive pairs use 6 network conditions (same IP, CGNAT, Private Relay, VPN, WiFi-to-cellular, degraded) and 6 time delay buckets (instant to expired). True negative pairs ensure the two devices always have different canvas fingerprints to guarantee they are genuinely distinct.