How tracking works
The end-to-end lifecycle of a single install.
Publisher generates a tracking link
Your dashboard creates https://trk.{domain}/r/{slug} with up to 5 subid slots. Link slugs are opaque so there's no enumeration risk.
User clicks the link
The edge tracking service parses UA → device type, captures IP → country via MaxMind headers, generates a UUIDv7 click_id signed with HMAC-SHA256, enqueues a click.writer job, and 302-redirects to the right store URL with ?click_id= appended.
User installs the app; your MMP fires
Your MMP (AppsFlyer / Adjust / Branch) calls POST /postback?click_id=…&idfa=…. The tracking service validates, normalizes, and enqueues a postback.processor job — returning 200 to the MMP within ~10ms.
Fraud engine evaluates
Seven rules run deterministically: CTIT window, IP blacklist, datacenter IPs, device dedup, VPN/proxy, CR anomaly (soft), geo mismatch (soft), new-publisher quarantine (soft). Every hit is persisted to fraud_events.
Money moves atomically
Advertiser balance debits, campaign spend meters increment, publisher earnings credit, daily budget cap auto-pauses the campaign if reached — all in one Postgres transaction.
Webhooks fire + MMP forwarded
Subscribed endpoints receive install.approved or install.rejected events with HMAC signatures. Original postback optionally forwarded to the advertiser's own MMP for downstream analytics.