Mobile
Install attribution
The ordered ladder Metrixed uses to credit an install, with confidence scores, reinstall and re-attribution classification, and the click-injection guard.
When an app reports its first open, ingest tries to find the click that caused it. It walks a fixed ladder from the most certain identifier to the least certain and stops at the first match. The rung that matched and a confidence score are stored with the install (match_type).
The ladder
| # | Match type | How it matches | Confidence |
|---|---|---|---|
| 1 | referrer | The click id inside the Google Play Install Referrer (also Huawei, Samsung, Xiaomi and Vivo store referrers). Play referrers look like dtk_<click_id>&utm_*. | 1.00 |
| 2 | device_id | Hashed advertising id (IDFA, GAID, IDFV, Android id or OAID) matches a click recorded with the same id. | 0.98 |
| 3 | click_id | An explicit click id passed to the SDK or carried by a deep link. | 0.95 |
| 3 | deep_link | The install came through a deep link or unilink that carries the click. | 0.95 |
| 4 | san | A self-attributing network (a network such as Meta or Google that claims installs itself) claimed the install and its claim wins by priority. | 0.90 |
| 5 | preload | Matches a preinstall campaign. | 0.85 |
| 6 | probabilistic | IP address, user agent and locale fingerprint within the window (at most 24 hours), only when enabled on the app. Confidence decays from 0.7 to 0.5 as the window runs out. | 0.7 to 0.5 |
| 7 | organic | No match. | 0 |
Every rung enforces the app's click window, and a click that happened after the install began is never credited (click-injection guard). Zero or placeholder ids (a Limit-Ad-Tracking GAID of all zeros, null, unknown) are ignored.
For iOS devices that denied App Tracking Transparency, probabilistic matching is skipped unless the app explicitly allows it, and deferred deep links never upgrade a fuzzy match into a deterministic one: the content is delivered but the click id is withheld.
Installs, reinstalls and re-attribution
After matching, a known device is classified:
- install: the first time this device is seen.
- reinstall: the same device installs again inside
reinstall_exclusion_days; it is recorded but not credited as a new install. - reattribution: the device returns after
reattribution_inactivity_daysof inactivity through a new click insidereattribution_window_days. - re-engagement: an inactive but still-installed device opens via a link inside
reengagement_window_days.
Each can be switched on or off per app.
Events and revenue after the install
In-app events are matched to the device's install and therefore to the same partner and offer. Revenue is a six-decimal string with a currency, de-duplicated by the event's dedupe_id. Partner payouts for events work through goals and payout entries exactly as on the web; see billing and payouts.
Server-to-server
Without an SDK, post install, session and event bodies to the endpoints listed under mobile apps with the app token. The body carries a device block with the identifiers you have; raw ids are hashed on arrival.
Self-attributing networks
The SAN rung consults claims supplied for the app (san_config names the networks and their priority). Real network API clients are not included; claims are currently supplied through the API or an import, which makes this rung most useful for reconciliation workflows.
Where to see it
Installs list the match type, confidence, click, partner, offer, campaign and device. The Devices page shows the full history of one device, and the mobile reports slice installs and events by partner, campaign, country and cohort.