Capability · Attribution & MMP
Attribution engineering, not an attribution dashboard tour.
We implement, migrate and audit mobile measurement partners, and we design the conversion-value schemas and event models underneath them. This is the work that decides whether the rest of your growth programme is making decisions or guesses.
We work across AppsFlyer, Adjust, Branch, Singular, Kochava, Tenjin and Airbridge inside our clients’ own accounts and contracts. Goloporim is independent: we are not a reseller, and we hold no partnership, certification or endorsement from any of them. Vendor choice is a recommendation we make on the merits, and it is yours.
- 01Demand sources
Apple Ads · Google App campaigns · Meta · TikTok · Unity · AppLovin
- 02Click & impression layer
Tracking links, deep links, deferred deep links, SKAN / AdAttributionKit signatures
- 03Device & store signals
SDK sessions · Play Install Referrer · SKAN postbacks · Apple Ads attribution API
- 04MMP
Attribution logic, conversion-value schema, fraud rules, cost and ad-revenue ingestion
- 05Warehouse & reporting
Raw-data exports, cohorted LTV, blended and incremental views, the number you act on
Every layer loses or distorts something. Most reporting disagreements are a layer-04 configuration question wearing a layer-01 costume.
iOS · SKAdNetwork 4 & AdAttributionKit
Sixty-four states, three postbacks, and a randomised delay you cannot shorten.
AdAttributionKit is Apple's current framework and works alongside SKAdNetwork, adding re-engagement postbacks. The mechanics below are the constraints every iOS decision is made inside — so they are the first thing we read in an account.
fine CV + coarse CV
coarse CV
coarse CV
Conversion values
The fine conversion value is a 6-bit field: 64 states, 0 to 63, and it can only appear in the first postback. The coarse value is one of none, low, medium or high — aggregated buckets that survive into the later windows when the fine value does not.
Source identifier
A hierarchical value of two, three or four digits — 10,000 combinations — which replaced the SKAN 3 campaign ID. How you allocate those digits is a campaign structure decision made once and very expensive to change, because low-volume sources get truncated to the first two digits.
Lock window
lockWindow finalises a conversion value before its window closes, so the postback is sent sooner. Faster signal, less of the user’s early life measured — a trade we make explicitly and write down, rather than inheriting from a default.
Crowd anonymity decides what you actually receive
Apple grades every install into one of four tiers based on how much volume stands behind it. The tier, not your configuration, determines how much of your schema survives the trip. A campaign structure that splits volume too finely pushes its own installs down a tier and loses the fine value it was built around.
| Tier | First postback carries | Later postbacks | What it means in practice |
|---|---|---|---|
| Tier 0 | 2-digit source identifier only | No postback | You learn the campaign group and nothing else. |
| Tier 1 | 2 digits + coarse conversion value | Coarse value | Low / medium / high. Enough to separate good from bad, not to bid on revenue. |
| Tier 2 | 2–4 digits + fine conversion value | Coarse value | The first postback carries the full six-bit value. This is the tier a schema is designed for. |
| Tier 3 | 2–4 digits + fine CV + source app ID or domain | Reduced data | You also learn where the ad ran. Reachable only at real volume. |
Scroll the table sideways →
Schema design is the deliverable
Six bits is not very many. Every dimension you encode — revenue band, plan type, onboarding depth, predicted retention — competes for the same sixty-four states, and any dimension you include has to be worth more than the one it displaced.
So we design the schema against your event model and your actual revenue distribution, we write down what each state means, and we write down what the schema deliberately cannot tell you. The second document is the one that prevents somebody six months from now reading meaning into a number that never had it.
We also design the coarse mapping on purpose. It is what the day 3–7 and day 8–35 postbacks carry, which makes it the only SKAN signal about users who take a while to become valuable.
| Fine CV | Encodes | Coarse |
|---|---|---|
| 0 | Install, no qualifying event in window 1 | none |
| 1 | Onboarding completed | low |
| 2–7 | Account created, bucketed by signup path | low |
| 8–23 | Trial started, bucketed by plan × placement | medium |
| 24–47 | First payment, bucketed by revenue band | high |
| 48–63 | Revenue band × predicted retention tier | high |
Android · Play Install Referrer
Android still gives you a referrer string and two pairs of timestamps. Most accounts use one of them.
The Install Referrer API returns a small, specific set of fields. Referrer data stays available for 90 days and does not change unless the app is reinstalled, and the API is meant to be called once on first run after install — read it twice and your click-to-install interval stops meaning anything.
| Field | Type | Why it matters |
|---|---|---|
| install_referrer | String | The referrer URL of the installed package — where your campaign parameters arrive. |
| referrer_click_timestamp_seconds | long | Client-side time of the referrer click. |
| install_begin_timestamp_seconds | long | Client-side time the install began. |
| referrer_click_timestamp_server_seconds | long | Server-side time of the click. The one to trust when the device clock is wrong. |
| install_begin_timestamp_server_seconds | long | Server-side time the install began. Pairs with the above for a reliable click-to-install interval. |
| install_version | String | App version at first install — the field that tells a reinstall from a first install. |
| google_play_instant | boolean | Whether an instant experience was launched in the last 7 days. |
Scroll the table sideways →
The server-side timestamp pair is the one that matters for fraud work: comparing it to the client-side pair is how a device with a manipulated clock gives itself away, and the interval between a server-side click and a server-side install start is the cleanest click-to-install signal Android offers.
Implementation & migration
What we actually build.
SDK integration review
Version, initialisation order, consent gating, session definition, and whether the SDK is being asked questions it cannot answer.
Event taxonomy
One naming scheme, one parameter contract, one owner. Written down so a new platform integration does not invent its own.
Server-to-server events
Backend-sourced events for anything that must not depend on the app being open — subscriptions, renewals, refunds, verified revenue.
Partner postbacks
Which events each network receives, with what mapping, and which ones should be withheld because they are being used to bid against you.
Deep & deferred deep links
Universal links, App Links, routing rules and the fallback chain for every state the app can be in.
Cost & ad-revenue ingestion
Spend in, publisher revenue in, so ROAS is computed from one dataset rather than three spreadsheets.
Raw-data exports
Install, event and postback-level exports into your warehouse, with a schema your analysts can query.
MMP migration
Dual-running both vendors through a defined overlap, with a variance report, so the switch is a decision and not a leap.
Handover documentation
A specification, a runbook and a reconciliation method. If we leave, your measurement does not degrade.
Fraud & validation
Install fraud is caught at the MMP layer, and the default rules are not tuned for you.
These are the patterns we look for, the signal each one leaves, and the evidence needed to reject traffic in a way a network will accept rather than argue about.
Click spam / click flooding
A partner fires a large volume of clicks hoping to be the last touch before an organic install. Shows up as a flat, long click-to-install distribution and an implausible share of organic uplift claimed.
Click injection
A malicious app on the device notices an install starting and injects a click moments before it completes. Shows up as a click-to-install time measured in seconds, on Android, concentrated in a handful of sub-publishers.
SDK spoofing
Fabricated or replayed postbacks sent to the attribution endpoint without a real install behind them. Caught at the integration layer with signature verification and replay detection, not in a dashboard.
Install hijacking
A last-touch hijacker inserting itself into the attribution path between ad exposure and install, taking credit for a conversion another partner earned.
Device farms & proxy networks
Real devices and residential-proxy traffic behaving close enough to human that volume-based rules miss them. Found in behavioural cohorts: installs that never reach day-1, never retain and never pay.
The audit
Four weeks, one document, no obligation to continue.
This is how most engagements start. It is fixed in scope and fixed in price, quoted in USD before it begins, and the deliverable is yours whether or not you hire us for anything afterwards.
- Week 1
Inventory
SDK versions per platform, event taxonomy, link structure, partner list, current fraud rules, raw-data export configuration, who has admin on what.
- Week 2
Signal tracing
Trace a real install end to end on both platforms: click, attribution, postback, event, export, dashboard. Every point the number changes gets written down.
- Week 3
Reconciliation
MMP against App Store Connect and Play Console, MMP against ad platforms, MMP against warehouse and finance. Variances are quantified, not hand-waved.
- Week 4
Findings & plan
A written document: every misconfiguration, what it is costing, the fix, who has to do it, and the order to do it in. Delivered whether or not you retain us afterwards.
We need read access, and in a few places admin, to run it — the full list is on the approach page, so procurement can start on it before the first call.