Does AppsFlyer Work in China? Data Residency, ICP & Cross-Border Rules

For a mobile app reaching users in mainland China, the question is rarely whether AppsFlyer’s SDK can phone home. AppsFlyer has gone out of its way to make sure it can — it publishes China-market attribution links, routes events through a relay server inside China, and falls back to OAID and IMEI for attribution on the Android devices that have no Google Advertising ID. The SDK fires. That is precisely why “does AppsFlyer work in China?” is the wrong place to stop. AppsFlyer is a mobile measurement and attribution SDK you embed inside your app, and by its own description it reads your users’ device identifiers and ships their install, event and attribution data back to AppsFlyer. In China, what decides whether you can run it is not latency — it is whether you declared and obtained consent for that collection before it happened, whether the device and behavioral data it exports may lawfully leave the country, and on whose filing the China-facing app sits. Those are compliance questions, and a reachability check answers none of them.

AppsFlyer in China at a glance

What the SDK collects — and why “on by default” is the whole problem

Start with what actually leaves the device. AppsFlyer’s Services Privacy Policy describes the SDK reading device and advertising identifiers — “IDFA (identifier for advertisers), Android ID (in Android devices); Google Advertiser ID” — alongside IP address, device and OS attributes, and the stream of installs, launches and in-app events a marketer chooses to measure. In the Chinese domestic market the identifier mix shifts rather than shrinks: because Google Play Services is absent on most devices, AppsFlyer’s own guidance attributes installs using OAID and, on Android 28 and earlier, the device IMEI. Either way, the raw material of attribution is a persistent handle on a real person’s phone plus a behavioral trail of what they did after install.

The compliance problem is not that this is possible — it is that it is the default. AppsFlyer’s China PIPL page spells out that stopping the SDK from collecting device IDs requires developers to set specific flags, and that to scope that suppression to China alone “you must implement custom logic.” Read plainly: an app that embeds AppsFlyer and takes no deliberate action reads China users’ device identifiers and sends their events off the handset by default. China’s rules are built around the opposite premise — that nothing should be collected until it has been declared and consented.

China governs the tracker itself, not just the destination

Here is the part a reachability check cannot reach, and the part that makes an attribution SDK different from an ordinary offshore app. China does not only ask where personal data ends up; it regulates the act of a tracker collecting it. The MIIT and CAC rules aimed at apps and third-party SDKs that “illegally collect and use personal information” require a tracker to declare what it collects and to secure the user’s consent before collection begins. PIPL Articles 13 and 23 reinforce this: processing personal information needs a lawful basis and clear notice, and sharing it with a third party — which is what an attribution SDK does by sending events to AppsFlyer — needs specific, separate consent. A single bundled “agree to everything or leave” prompt (一揽子同意) does not satisfy it.

Layer on sensitivity. Persistent device identifiers and the attribution and behavioral profiles the SDK assembles can constitute sensitive personal information under PIPL Articles 28–29, which demand a specific purpose, demonstrated necessity, and their own separate consent. A default-on SDK that quietly reads a device ID and a behavioral trail is, almost by definition, the conduct these rules were written to stop. No amount of fast ingestion changes that — the violation, if there is one, happened at the moment of silent collection, before any server round-trip.

Cross-border by design — and what AppsFlyer’s China relay does and does not promise

The second regulated event is the border crossing. The device identifiers and events the SDK collects in China do not simply sit on the phone; they move to AppsFlyer, and AppsFlyer’s Services Privacy Policy is candid that it “may need to transfer Customer Data to countries other than the country from which the Data originated,” with United States transfers governed by Standard Contractual Clauses. That is a cross-border transfer of personal information under PIPL Articles 38–40, and it requires one of the law’s transfer mechanisms — a CAC security assessment, the CAC standard contract, or certification. For a critical information infrastructure operator or a high-volume handler, Cybersecurity Law Article 39 (formerly Article 37 — the 2025 Cybersecurity Law amendment, in force January 1, 2026, renumbered the data-localization article from 37 to 39, its substance unchanged) requires personal information generated in China to be stored in the mainland.

This is where AppsFlyer’s China posture needs stating precisely, because it is genuinely different from a pure offshore tracker — and genuinely short of full residency. AppsFlyer publishes a China-market PIPL configuration whose stated principles are to prevent the SDK from collecting device IDs, to mask and hash IPs of SDK, server-to-server, click and impression events, and to audit “all app events on a relay server in China.” That is a meaningful collection-and-ingestion edge inside the country. But it is a configuration you apply to reduce and route data, not a declaration that your China users’ attribution data is stored and kept in mainland China. AppsFlyer’s own privacy policy names cross-border transfer and no mainland storage region. So a China-resident path may exist — and it is worth exploring — but its exact scope, and whether it satisfies your Article 38–40 and Article 39 duties, is something to confirm with counsel and with AppsFlyer before your China program relies on it.

Why “does the pixel fire?” misses all of this

AppsFlyer is not a tracker that fails to load in China — the opposite. It ships China domains, a China relay, and OAID/IMEI attribution precisely so that it does fire. That is exactly why a reachability test is the wrong instrument. “Did an event reach the server?” tells you nothing about whether the collection was declared and separately consented, whether persistent device identifiers and a behavioral profile were read as sensitive personal information without the Article 28–29 basis, whether the data lawfully crossed the border under Articles 38–40, or whether the China-facing app that carries the SDK is filed. The exposure is quiet and durable: it lives in the consent the SDK never asked for and the data it exports by default, not in a latency number.

This is a risk map, not a verdict that AppsFlyer is “blocked” or “illegal” in China. Which duties bite your case turns on your entity, which AppsFlyer SDKs and flows your app actually ships, what each collects, your role under Chinese law, and your data volumes — worth settling the specifics with counsel before your China measurement depends on it.

The lawful path — map, localize, deliver

There is a compliant way to run mobile attribution for a China audience, and it sits in front of the AppsFlyer setup your team already uses — no rebuild, no second measurement stack, no migration off AppsFlyer.

First, map: our China team inventories exactly what your AppsFlyer integration collects — which identifiers the SDK reads (IDFA/IDFV, Google Advertiser ID, Android ID, OAID, IMEI), which install and in-app events it sends, where those events are hosted and transferred, and the consent basis each flow relies on — along with the filing status of the China-facing app or surface that embeds it. We build the technical picture; the legal conclusions are settled with counsel.

Then localize / govern: we help you put the declare-then-consent basis China’s law requires in front of collection — the Article 13/23 notice and the specific, separate consent these trackers need, with the Article 28–29 treatment where device identifiers and behavioral profiles are sensitive — and keep the regulated China data on a lawful in-country path rather than letting the SDK exfiltrate device data by default. Localize means keeping the data in-country; it never means a route that quietly ships personal information across the border.

Then deliver: any China-facing app or public surface you publish to mainland users is an internet information service, so it carries an ICP filing (备案) duty bound to a mainland hosting resource and needs compliant, in-country delivery. 21YunBox stands that up — the 21YunBox Optimizer — in front of what you already run. 21YunBox never uses or suggests circumvention of any kind — we keep in-country what the law says must stay, deliver the rest compliantly from inside the mainland, and never move personal information across the border by stealth. Making an offshore tracker merely reachable is not the answer — AppsFlyer is already reachable in China; keeping the regulated data in-country on a declared, consented, and (where needed) filed path is. 21YunBox is a compliance overlay and partner to AppsFlyer, not a competitor to it.

Get a compliance assessment →

Related reading:

• China’s Personal Information Protection Law (PIPL)
• Cross-border data transfers under PIPL
• China’s Cybersecurity Law
• How to get an ICP filing for China

RELATED TECHNOLOGIES

Adjust

Adjust

Hootsuite

Hootsuite

Khoros

Khoros

Sprout Social

Sprout Social

TikTok Pixel

TikTok Pixel