Funktioniert AppsFlyer in China? Datenresidenz, ICP und Grenztransfer-Regeln

Was die offizielle AppsFlyer-Dokumentation über China sagt

Fakt	Primärquelle
In AppsFlyers eigenen Worten beruht seine China-PIPL-Lösung „based on 3 principles: Prevent the SDK from collecting device IDs. Mask and hash IPs of SDK events, S2S events, and clicks and impressions. Enable auditing all app events on a relay server in China“ (auf 3 Prinzipien: das SDK vom Sammeln von Geräte-IDs abhalten; die IPs von SDK-Events, S2S-Events sowie Clicks und Impressions maskieren und hashen; das Auditieren aller App-Events auf einem Relay-Server in China ermöglichen). Die Erhebung ist standardmäßig an — die Seite vermerkt, dass „to disable identifiers specifically for the Chinese market, you must implement custom logic“, eine App, die AppsFlyer einbettet und keine Handlung vornimmt, liest also standardmäßig die Geräte-IDs der China-Nutzer und verschifft ihre Events.	AppsFlyer Knowledge Base — Apply China Personal Information Protection Law (PIPL) solution, abgerufen 2026-10-12
AppsFlyers Services Privacy Policy listet die Endnutzerdaten, die sein SDK sammelt — Werbe- und Gerätekennungen („IDFA (identifier for advertisers), Android ID (in Android devices); Google Advertiser ID“), IP-Adresse, Geräteattribute und Install-/Engagement-Events — und gibt an, dass „AppsFlyer may need to transfer Customer Data to countries other than the country from which the Data originated“, mit Transfers in die Vereinigten Staaten, die durch Standardvertragsklauseln geregelt sind. Es nennt keine Festlandchina-Speicherregion; AppsFlyer positioniert sich als Auftragsverarbeiter, der auf Weisung seines Kunden handelt, die PIPL-Pflichten fallen also Ihnen zu, dem App-Herausgeber.	AppsFlyer Services Privacy Policy, abgerufen 2026-10-12
China reguliert den Tracker selbst: Die MIIT- und CAC-Regeln zu Apps und Dritt-SDKs, die personenbezogene Daten rechtswidrig sammeln und nutzen, verlangen, zu deklarieren, was gesammelt wird, und vor der Erhebung eine Einwilligung einzuholen. PIPL Art. 13 und 23 verlangen Mitteilung und eine spezifische, gesonderte Einwilligung für diese Art Tracking — keine gebündelte (一揽子) Einwilligung —, und Gerätekennungen und Verhaltensprofile können sensible personenbezogene Daten nach Art. 28–29 sein, was einen Notwendigkeits- und Gesonderte-Einwilligung-Test hinzufügt.	Gesetz zum Schutz personenbezogener Daten der VR China — 21YunBox gov-doc-Übersetzung
Die Gerätekennungen und Attributions-Events der China-Nutzer an Offshore-Server zu senden, ist ein grenzüberschreitender Transfer personenbezogener Daten nach PIPL Art. 38–40, der einen rechtmäßigen Transfermechanismus erfordert — eine CAC-Sicherheitsbewertung, den CAC-Standardvertrag oder eine Zertifizierung. Für einen Betreiber kritischer Informationsinfrastruktur oder einen Verarbeiter großer Mengen verlangt Cybersicherheitsgesetz Art. 39 (vormals Art. 37), dass in China erzeugte personenbezogene Daten im Festland gespeichert werden.	Grenztransfer-Regeln und das Cybersicherheitsgesetz der VR China — 21YunBox gov-doc-Übersetzungen

Quellen vom 21YunBox Compliance-Team am 12. Oktober 2026 geprüft.

Für eine mobile App, die Nutzer in Festlandchina erreicht, ist die Frage selten, ob AppsFlyers SDK nach Hause telefonieren kann. AppsFlyer hat sich besondere Mühe gegeben, dass es das kann — es veröffentlicht Attributionslinks für den China-Markt, routet Events über einen Relay-Server innerhalb Chinas und greift auf den Android-Geräten ohne Google-Advertising-ID auf OAID und IMEI für die Attribution zurück. Das SDK feuert. Genau deshalb ist „funktioniert AppsFlyer in China?“ der falsche Ort zum Innehalten. AppsFlyer ist ein Mobile-Measurement- und Attribution-SDK, das Sie in Ihre App einbetten, und nach seiner eigenen Beschreibung liest es die Gerätekennungen Ihrer Nutzer und verschifft ihre Install-, Event- und Attributionsdaten zurück an AppsFlyer. In China entscheidet darüber, ob Sie es betreiben können, nicht die Latenz — sondern, ob Sie diese Erhebung vor ihrem Geschehen deklariert und eingewilligt haben, ob die Geräte- und Verhaltensdaten, die es exportiert, das Land rechtmäßig verlassen dürfen, und auf wessen Beian die auf China ausgerichtete App sitzt. Das sind Compliance-Fragen, und eine Erreichbarkeitsprüfung beantwortet keine davon.

AppsFlyer in China auf einen Blick

Was das SDK sammelt — und warum „standardmäßig an“ das ganze Problem ist

Beginnen Sie mit dem, was tatsächlich das Gerät verlässt. AppsFlyers Services Privacy Policy beschreibt, wie das SDK Geräte- und Werbekennungen liest — „IDFA (identifier for advertisers), Android ID (in Android devices); Google Advertiser ID“ — neben IP-Adresse, Geräte- und OS-Attributen und dem Strom an Installs, Starts und In-App-Events, den ein Marketer zu messen wählt. Im chinesischen Inlandsmarkt verschiebt sich die Kennungsmischung eher, als dass sie schrumpft: Weil Google Play Services auf den meisten Geräten fehlt, attribuiert AppsFlyers eigene Anleitung Installs über OAID und, auf Android 28 und früher, die Geräte-IMEI. So oder so ist das Rohmaterial der Attribution ein persistenter Griff am Telefon einer realen Person plus eine Verhaltensspur dessen, was sie nach dem Install getan hat.

Das Compliance-Problem ist nicht, dass dies möglich ist — es ist, dass es der Standard ist. AppsFlyers China-PIPL-Seite legt dar, dass das Abhalten des SDK vom Sammeln von Geräte-IDs erfordert, dass Entwickler bestimmte Flags setzen, und dass, um diese Unterdrückung auf China allein zu beschränken, „you must implement custom logic“. Nüchtern gelesen: Eine App, die AppsFlyer einbettet und keine bewusste Handlung vornimmt, liest standardmäßig die Gerätekennungen von China-Nutzern und sendet ihre Events vom Gerät. Chinas Regeln sind um die entgegengesetzte Prämisse gebaut — dass nichts gesammelt werden soll, bevor es deklariert und eingewilligt wurde.

China reguliert den Tracker selbst, nicht nur das Ziel

Hier ist der Teil, den eine Erreichbarkeitsprüfung nicht erreichen kann, und der Teil, der ein Attribution-SDK von einer gewöhnlichen Offshore-App unterscheidet. China fragt nicht nur, wo personenbezogene Daten enden; es reguliert den Akt, in dem ein Tracker sie sammelt. Die MIIT- und CAC-Regeln, die auf Apps und Dritt-SDKs zielen, die „illegally collect and use personal information“, verlangen von einem Tracker, zu deklarieren, was er sammelt, und die Einwilligung des Nutzers vor dem Beginn der Erhebung einzuholen. PIPL Art. 13 und 23 bekräftigen das: Das Verarbeiten personenbezogener Daten braucht eine rechtmäßige Grundlage und klare Mitteilung, und ihre Weitergabe an einen Dritten — was ein Attribution-SDK tut, indem es Events an AppsFlyer sendet — braucht eine spezifische, gesonderte Einwilligung. Eine einzelne gebündelte „stimme allem zu oder geh“-Aufforderung (一揽子同意) erfüllt es nicht.

Legen Sie die Sensibilität obendrauf. Persistente Gerätekennungen und die Attributions- und Verhaltensprofile, die das SDK zusammensetzt, können sensible personenbezogene Daten nach PIPL Art. 28–29 darstellen, die einen spezifischen Zweck, nachgewiesene Notwendigkeit und ihre eigene gesonderte Einwilligung verlangen. Ein standardmäßig aktives SDK, das stillschweigend eine Geräte-ID und eine Verhaltensspur liest, ist fast per Definition das Verhalten, das diese Regeln aufhalten sollten. Keine noch so schnelle Ingestion ändert das — die Verletzung, wenn es eine gibt, geschah im Moment der stillschweigenden Erhebung, vor jedem Server-Roundtrip.

Grenzübertritt per Design — und was AppsFlyers China-Relay verspricht und nicht verspricht

Das zweite regulierte Ereignis ist der Grenzübertritt. Die Gerätekennungen und Events, die das SDK in China sammelt, sitzen nicht einfach auf dem Telefon; sie bewegen sich zu AppsFlyer, und AppsFlyers Services Privacy Policy ist offen, dass es „may need to transfer Customer Data to countries other than the country from which the Data originated“, mit US-Transfers, die durch Standardvertragsklauseln geregelt sind. Das ist ein grenzüberschreitender Transfer personenbezogener Daten nach PIPL Art. 38–40, und er erfordert einen der Transfermechanismen des Gesetzes — eine CAC-Sicherheitsbewertung, den CAC-Standardvertrag oder eine Zertifizierung. Für einen Betreiber kritischer Informationsinfrastruktur oder einen Verarbeiter großer Mengen verlangt Cybersicherheitsgesetz Art. 39 (vormals Art. 37 — die 2025er Novelle des Cybersicherheitsgesetzes, in Kraft seit 1. Januar 2026, nummerierte den Datenlokalisierungsartikel von 37 auf 39 um, inhaltlich unverändert), dass in China erzeugte personenbezogene Daten im Festland gespeichert werden.

Hier muss AppsFlyers China-Haltung präzise benannt werden, denn sie unterscheidet sich echt von einem reinen Offshore-Tracker — und bleibt echt hinter voller Residenz zurück. AppsFlyer veröffentlicht eine PIPL-Konfiguration für den China-Markt, deren erklärte Prinzipien sind, das SDK vom Sammeln von Geräte-IDs abzuhalten, die IPs von SDK-, Server-zu-Server-, Click- und Impression-Events zu maskieren und zu hashen und „all app events on a relay server in China“ zu auditieren. Das ist ein bedeutsamer Erhebungs- und Ingestion-Edge innerhalb des Landes. Aber es ist eine Konfiguration, die Sie anwenden, um Daten zu reduzieren und zu routen, keine Erklärung, dass die Attributionsdaten Ihrer China-Nutzer in Festlandchina gespeichert und gehalten werden. AppsFlyers eigene Datenschutzrichtlinie nennt grenzüberschreitenden Transfer und keine Festland-Speicherregion. Ein in China ansässiger Weg mag also existieren — und er ist das Erkunden wert —, aber sein genauer Umfang, und ob er Ihre Pflichten nach Art. 38–40 und Art. 39 erfüllt, ist etwas, das mit Rechtsbeistand und mit AppsFlyer zu bestätigen ist, bevor Ihr China-Programm darauf baut.

Warum „feuert der Pixel?“ all dies verfehlt

AppsFlyer ist kein Tracker, der in China nicht lädt — im Gegenteil. Es liefert China-Domains, ein China-Relay und OAID/IMEI-Attribution gerade deshalb, damit es feuert. Genau deshalb ist ein Erreichbarkeitstest das falsche Instrument. „Hat ein Event den Server erreicht?“ sagt Ihnen nichts darüber, ob die Erhebung deklariert und gesondert eingewilligt war, ob persistente Gerätekennungen und ein Verhaltensprofil als sensible personenbezogene Daten ohne die Grundlage nach Art. 28–29 gelesen wurden, ob die Daten die Grenze rechtmäßig nach Art. 38–40 überschritten haben oder ob die auf China ausgerichtete App, die das SDK trägt, gemeldet ist. Die Exponierung ist leise und dauerhaft: Sie liegt in der Einwilligung, nach der das SDK nie fragte, und in den Daten, die es standardmäßig exportiert, nicht in einer Latenzzahl.

Dies ist eine Risikokarte, kein Urteil, dass AppsFlyer in China „gesperrt“ oder „illegal“ sei. Welche Pflichten Ihren Fall treffen, hängt von Ihrer Gesellschaft ab, davon, welche AppsFlyer-SDKs und -Flüsse Ihre App tatsächlich ausliefert, was jedes sammelt, von Ihrer Rolle nach chinesischem Recht und Ihren Datenmengen — es lohnt, die Einzelheiten mit Rechtsbeistand zu klären, bevor Ihre China-Messung davon abhängt.

Der rechtmäßige Weg — kartieren, lokalisieren, ausliefern

Es gibt einen rechtskonformen Weg, mobile Attribution für ein China-Publikum zu betreiben, und er sitzt vor dem AppsFlyer-Setup, das Ihr Team bereits nutzt — ohne Neuaufbau, ohne zweiten Measurement-Stack, ohne Migration weg von AppsFlyer.

Zuerst kartieren: Unser China-Team inventarisiert genau, was Ihre AppsFlyer-Integration sammelt — welche Kennungen das SDK liest (IDFA/IDFV, Google Advertiser ID, Android ID, OAID, IMEI), welche Install- und In-App-Events es sendet, wo diese Events gehostet und transferiert werden und auf welcher Einwilligungsgrundlage jeder Fluss beruht — samt des Beian-Status der auf China ausgerichteten App oder Oberfläche, die es einbettet. Wir bauen das technische Bild; die rechtlichen Schlüsse werden mit Rechtsbeistand geklärt.

Dann lokalisieren / steuern: Wir helfen Ihnen, die Deklarieren-dann-einwilligen-Grundlage, die Chinas Recht verlangt, vor die Erhebung zu setzen — die Mitteilung nach Art. 13/23 und die spezifische, gesonderte Einwilligung, die diese Tracker brauchen, mit der Behandlung nach Art. 28–29, wo Gerätekennungen und Verhaltensprofile sensibel sind — und die regulierten China-Daten auf einem rechtmäßigen inländischen Weg zu halten, statt das SDK Gerätedaten standardmäßig exfiltrieren zu lassen. Lokalisieren heißt, die Daten im Inland zu halten; es heißt niemals ein Weg, der personenbezogene Daten heimlich über die Grenze verschifft.

Dann ausliefern: Jede auf China ausgerichtete App oder öffentliche Oberfläche, die Sie Festland-Nutzern veröffentlichen, ist ein Internet-Informationsdienst, trägt also eine ICP-Beian-Pflicht (备案), gebunden an eine Festland-Hosting-Ressource, und braucht rechtskonforme, inländische Auslieferung. 21YunBox setzt das auf — der 21YunBox Optimizer — vor dem, was Sie bereits betreiben. 21YunBox verwendet und empfiehlt keine Umgehung welcher Art auch immer — wir halten im Inland, was das Recht sagt, dass es bleiben muss, liefern den Rest rechtskonform aus dem Festland heraus aus und bewegen personenbezogene Daten niemals heimlich über die Grenze. Einen Offshore-Tracker lediglich erreichbar zu machen, ist nicht die Antwort — AppsFlyer ist in China bereits erreichbar; die regulierten Daten im Inland auf einem deklarierten, eingewilligten und (wo nötig) gemeldeten Weg zu halten, ist es. 21YunBox ist eine Compliance-Overlay und Partnerin von AppsFlyer, keine Konkurrentin dazu.

Compliance-Einschätzung anfordern →

---

Weiterführend:

• Chinas Gesetz zum Schutz personenbezogener Daten (PIPL)
• Grenzüberschreitende Datentransfers nach PIPL
• Chinas Cybersicherheitsgesetz
• So erhalten Sie eine ICP-Beian für China

Häufige Fragen

Ist AppsFlyer in China gesperrt?

Nein. AppsFlyer veröffentlicht Attributionsdomains für den China-Markt und einen Relay-Server in China, und es attribuiert Android-Installs über OAID oder IMEI, wo Googles Advertising ID fehlt, das SDK ist also erreichbar und die Messung läuft. Erreichbarkeit ist nicht die Compliance-Frage — die Exponierung ist, dass das SDK standardmäßig die Gerätekennungen der China-Nutzer liest und Install- und Event-Daten an AppsFlyers Offshore-Server sendet, sofern Sie es nicht anders konfigurieren und einwilligen lassen.

Speichert AppsFlyer die Daten meiner China-Nutzer in Festlandchina?

Nicht als erklärte Garantie. AppsFlyers eigene Datenschutzrichtlinie beschreibt grenzüberschreitenden Transfer (mit US-Transfers unter Standardvertragsklauseln) und nennt keine Festlandchina-Speicherregion. Seine China-PIPL-Lösung ist eine Datenminimierungs-Konfiguration plus ein Ingestion-/Audit-Relay in China — bedeutsam, aber keine verifizierte End-to-End-Residenzzusage für gespeicherte Attributionsdaten. Ein in China ansässiger Weg mag existieren; bestätigen Sie seinen Umfang mit Rechtsbeistand und AppsFlyer, bevor Sie sich darauf verlassen.

Was verlangt China, bevor ein Attribution-SDK Daten sammelt?

Deklarieren, was gesammelt wird, und eine spezifische, gesonderte Einwilligung einholen, bevor die Erhebung beginnt. Chinas App-und-SDK-Governance-Regeln (MIIT/CAC) und PIPL Art. 13 und 23 akzeptieren keine gebündelte Alles-oder-nichts-Einwilligung, und Gerätekennungen und Verhaltensprofile können sensible personenbezogene Daten nach Art. 28–29 sein. Ein standardmäßig aktives SDK, das stillschweigend Geräte-IDs liest, ist das Verhalten, auf das diese Regeln zielen — weshalb AppsFlyer lediglich erreichbar zu machen, es nicht rechtskonform macht.