Attribution looks straightforward on paper: an ad click leads to an app store visit, the user installs, opens the app, and you see events in your MMP. In real life, this chain breaks for very “non‑marketing” reasons: redirects, country‑specific store fronts, browser limitations, privacy changes on iOS, and even IP range blocks. That’s why geo QA often relies on dedicated mobile proxies and an end‑to‑end test flow: click → store → install → first open → in‑app event.
This article explains how AppsFlyer (as an MMP) measures installs and events, where issues usually happen, where proxies are configured (not inside AppsFlyer, but in your test environment/profile), which proxy fields matter (host/port/username/password + protocol), and how to validate that the test is really running from the intended country using IP→Country and ASN checks—and that the session didn’t “jump” mid‑flow.
MMP basics: what AppsFlyer does
An MMP (mobile measurement partner) provides a neutral measurement layer: it receives engagement data (clicks/impressions), matches them to installs, and attributes in‑app events to the right media source and campaign. AppsFlyer typically uses attribution links (OneLink or single‑platform links) and the AppsFlyer SDK inside the app.
How the click → install → event matching works
1) Attribution link and redirects
Users click an attribution link. AppsFlyer receives the click and its parameters (media source, campaign, adset, UTM tags, etc.), then redirects the user to the correct destination: app store, web page, or the app itself (when installed).
2) First open and the SDK
After install, the SDK sends install/first open and subsequent in‑app events. Matching relies on device identifiers where available (e.g., IDFA/IDFV on iOS, GAID on Android) plus additional signals.
3) Geo in reporting: IP‑based location
AppsFlyer generally determines user location from the device IP address and maps it to a country/city. In QA, note that the “true” IP can be masked by VPN‑like mechanisms (for example, iOS Private Relay) or postback proxy layers, which can make geo interpretation tricky. That’s why IP validation belongs in every geo QA report.
Where the chain typically breaks
| Step | Expected outcome | Common breakpoints | How to verify |
|---|---|---|---|
| Click | Click is recorded with correct campaign parameters | Bad parameters, link wrapping, script blocks, rate limiting | Inspect the long URL, validate parameters, try another browser |
| Store redirect | Correct country storefront and listing | Geo redirects, country availability, IP/ASN blocks | Check store availability settings and redirect behavior |
| Install | App installs from the intended listing | Store cache, different account/region, delayed install | Run a clean test (uninstall, clear caches where applicable) |
| First open | SDK sends install/first open | SDK init issues, blocked domains, consent flow, network constraints | SDK debug logs, network checks, send a test event |
| Deep/deferred deep link | User lands on the intended in‑app screen | Universal/App Links misconfig, browser context limitations | Test matrix by OS × browser × “installed/not installed” |
Why dedicated mobile proxies help in geo QA
“Mobile proxy” usually means an IP coming from a mobile carrier network (carrier ASN), not from a data center. For geo QA, this matters because many third‑party systems behave differently depending on IP type: data‑center IPs are more likely to be flagged, blocked, or redirected. A dedicated endpoint reduces noise from other users sharing the same pool.
| Proxy type | Best for | Trade‑offs |
|---|---|---|
| Mobile (carrier) | Store flows, deferred deep links, retargeting QA | Higher cost; you need sticky sessions |
| Residential | Web‑to‑app landing pages, localization QA | Variable speed and stability |
| Data center | Quick smoke tests | Most likely to be blocked or treated as suspicious |
Where proxies are configured (profile‑level) and what to set in AppsFlyer
Important: AppsFlyer doesn’t have “proxy host/port” settings in its UI for your tests. AppsFlyer receives events and the device IP. So the proxy is configured in your test environment:
- on the test phone (network proxy/VPN solution),
- in browser profiles used for the click/redirect part,
- in an emulator or device farm if that’s your setup.
AppsFlyer setup that makes QA predictable
- Create a OneLink (or app‑specific link) for your scenario.
- Register test devices so you can reinstall and test safely (and avoid false fraud flags during repeated tests).
- For retargeting tests, enable retargeting and use links that include
is_retargeting=true.
Proxy fields you’ll typically enter
- Host
- Port
- Username
- Password
- Protocol: HTTP/HTTPS or SOCKS5
If your provider rotates IPs, use a sticky session long enough to cover the whole funnel, and watch out for request limits (rate limiting).
Geo validation: IP→Country + ASN, and session stability
1) IP→Country
- Check the external IP and country in at least two independent services.
- Record IP before click, before install, and before first open.
- If the country differs between services, treat the geo test as unstable.
2) ASN check
ASN (Autonomous System Number) tells you who owns the network. This is a practical signal to distinguish carrier networks from cloud hosting/VPN pools. Many geo policies and security systems can filter by IP ranges, countries, or ASNs, so ASN is part of “proof” that the traffic is what you think it is.
3) Session persistence (no “jumps”)
- Use sticky sessions.
- Avoid long pauses between steps.
- Run one scenario per profile/device to avoid mixing cookies and context.
- Keep context consistent: timezone, locale, and Accept‑Language should not strongly contradict the IP country, otherwise you may get misleading redirects or content.
FAQ
Mobile proxies for AppsFlyer: what’s the simplest rule of thumb?
mobile proxies for AppsFlyer are most valuable when the user journey is geo‑sensitive (storefronts, availability, localization, deferred deep links) and data‑center IPs produce false negatives due to blocks or different routing.
Can I set a proxy inside AppsFlyer?
No. Configure the proxy on the test device or in the browser profile/emulator. In AppsFlyer, focus on link setup, test device registration, and validation via dashboards/raw data.
Sources
- AppsFlyer: attribution link structure and parameters
- AppsFlyer: attribution model and device ID matching
- AppsFlyer: location determined by IP and limitations
- AppsFlyer: creating OneLink links
- AppsFlyer: registering test devices
- AppsFlyer: SDK testing and retargeting test notes
- Google Play: country availability/targeting for testing tracks
- Google Cloud Media CDN: filtering by IP ranges/country/ASN