PostHog App Tracking: Was native Apps wirklich brauchen (Teil 1)

Warum App-Tracking anders tickt als Web-Tracking

Im Web ändert sich ein Tracking-Snippet in Minuten. Fertig. In eurer nativen App sitzt das Analytics-SDK im Code, und das ändert die Spielregeln komplett. Ein neues Custom Event, eine geänderte Property, zusätzliche Consent-Logik: All das braucht fast immer eine Codeänderung, einen Store-Review und danach die tatsächliche Installation durch eure Nutzer. Deshalb gehören Tracking-Anforderungen in den Kickoff Workshop, nicht in die Woche vor dem Launch.

Eine Ausnahme gibt es, und sie lohnt sich: Feature Flags. Ist ein Flag-Check einmal im Code veröffentlicht, ändern sich Zielgruppen, Rollout-Prozente und Payloads remote, ganz ohne neuen Release.

Kein Browser-Kontext, aber nicht kontextlos

Eure App kennt keine Adresszeile und keine Web-Cookies. Kontextlos ist sie trotzdem nicht: Deep Links transportieren URL-, Query- und Referrer-Informationen. Android erfasst das Event “Deep Link Opened” automatisch [1], beide Plattformen liefern zusätzlich Lifecycle- und teils Screen-Events von selbst.

Für die Produktanalyse zählt die Werbe-ID trotzdem nicht. Warum? Weil PostHog beim ersten Start eine anonyme, lokal gespeicherte distinct_id erzeugt und sie später über identify mit einer stabilen Account-ID verbindet [2]. IDFA und GAID gehören in eine andere Welt: die der Werbe-Attribution.

Klick, Store und erster Start: getrennte Systeme

Anzeigenklick, Store-Besuch, Installation, erster App-Start: Das läuft nicht in einem durchgehenden Browserkontext ab wie im Web. Install-Attribution wird dadurch zur eigenen Messaufgabe. PostHog analysiert In-App-Verhalten und vorhandenen Deep-Link-Kontext, mehr nicht. Eine belastbare, kanalübergreifende Install-Zuordnung braucht ein separates Konzept.

OS- und SDK-Versionen setzen Grenzen

Apple und Google geben den technischen Rahmen vor. Zusätzlich unterscheiden sich Fähigkeiten nach SDK, Plattform und installierter App-Version. Ein Event-Rename in Version 5 ändert nicht die Daten aus Version 4, Mischdaten über mehrere Versionen bleiben normal. Deshalb bekommen Events feste Namen. Ergänzungen statt Umbenennungen halten die Historie sauber. app_version und build laufen als Analysekontext mit, die Event-Taxonomie bleibt eine gemeinsame Aufgabe von Marketing, Product und Development.

PostHog und Attribution: zwei Fragen, zwei Systeme

“Was tun Nutzer in der App?” und “Woher kam der Install?” klingen nach derselben Frage. Technisch sind es zwei ganz getrennte Systeme.

App-Messung beantwortet im Kern zwei Fragen. Nur eine davon ist PostHogs Job: die erste.

Ohne bezahlte Install-Kampagnen reicht oft die saubere Erfassung von In-App-Verhalten, organischen Deep Links und eigenen Kampagnenparametern. Bei relevantem Paid-App-Budget lohnt sich Install-Attribution als eigener Workstream.

Der MMP als Zwischeninstanz

Ein Mobile Measurement Partner führt Klick- und Install-Signale aus mehreren Werbenetzwerken zusammen, dedupliziert sie und spielt sie an Werbeplattformen zurück. Bekannte Anbieter: AppsFlyer, Adjust, Branch, Singular. Ob ein MMP notwendig ist, hängt von Kampagnenmix, Budget, Plattformen, Datenschutzanforderungen und gewünschtem Detailgrad ab. Nicht davon, dass es sich um eine App handelt.

Was der ATT-Dialog wirklich betrifft

Apples ATT-Dialog regelt Tracking über Apps und Websites anderer Unternehmen sowie den Zugriff auf Werbe-Identifikatoren [3]. Analytics-Consent deckt er damit nicht automatisch ab. Läuft PostHog ohne Cross-App-Tracking und ohne Werbe-ID rein für First-Party-Produktanalyse, bleibt die PostHog-Identität davon technisch getrennt. Die rechtliche Grundlage für Analytics klärt trotzdem der Datenschutzbeauftragte des Projektpartners separat.

Für die Praxis bedeutet das: Kampagnenzahlen auf iOS wirken aggregierter, verzögerter und weniger nutzerbezogen als vergleichbare Web-Zahlen. Kommuniziert das am besten vor Kampagnenstart mit eurem Projektpartner, nicht danach.

Events, Identität und die Person-Profile-Falle

Ein Event beschreibt eine Handlung, Event-Properties liefern den Kontext dazu. Das Modell gleicht dem Web, die Erfassung unterscheidet sich: Mobile SDKs liefern bestimmte technische und Lifecycle-Events automatisch, fachliche Kernhandlungen entstehen als Custom Events im Code.

Für Kotlin Multiplatform gibt es inzwischen ein offizielles PostHog-SDK, das die nativen Android- und iOS-SDKs kapselt und Capture aus gemeinsamem Kotlin-Code erlaubt. Passt inhaltlich direkt zu unserer eigenen Cross-Plattform Entwicklung mit Kotlin Multiplatform. Der Haken: Der aktuelle Stand ist Early Access, eine 0.x-Vorabversion, APIs ändern sich zwischen Minor-Releases [4]. Wer produktiv damit arbeitet, pinnt die Version, beobachtet den Changelog und plant Upgrade-Tests fest ein. Blind aktualisieren ist keine Option.

Drei Regeln für die Event-Taxonomie

1. Event-Namen stehen früh fest, Punkt. Nicht ohne Migrationsplan umbenennen.
2. Pro Event gehören Trigger, Pflicht-Properties, Datentypen und Beispielwerte in eine gemeinsame Dokumentation.
3. Bei Änderungen zählen Mischdaten aus alten und neuen App-Versionen von Anfang an zur Planung dazu.

Identität: die PostHog-ID ist keine Werbe-ID

Beim ersten Start vergibt PostHog eine anonyme ID und speichert sie lokal. Sobald eine stabile Nutzer-ID feststeht, meist beim Login, ruft die App identify auf. PostHog verbindet die anonyme Historie mit dem identifizierten Profil, ab diesem Moment zählen folgende Events als identifizierte Events. Beim Logout löst reset aus, damit das nächste Profil nicht in denselben Datensatz schreibt [2].

Eine stabile distinct_id bleibt eindeutig. Sonst verschmelzen kollidierende IDs Daten verschiedener Personen, ein Fehler, der sich später kaum sauber korrigieren lässt.

Anonym bleibt günstiger, identifiziert bleibt aussagekräftiger

Android und iOS erfassen standardmäßig anonyme Events, solange kein Person Profile existiert. Ein Profil entsteht nicht nur durch identify, sondern je nach SDK auch durch alias, group oder gesetzte Person-Properties. Anonyme Events fallen laut PostHog wegen der einfacheren Verarbeitung bis zu viermal günstiger aus [5]. Das spricht nicht gegen identify, sondern dafür, Person Profiles gezielt dort anzulegen, wo Personen-, Kohorten- oder Cross-Device-Analysen wirklich Substanz liefern.

Was PostHog wirklich kann: Session Replay, Flags und Experimente im Realitätscheck

Person Profiles bündeln die Event-Historie und Eigenschaften einer identifizierten Person, Cohorts segmentieren Personen nach Verhalten oder Merkmalen, Groups aggregieren auf Ebene von Unternehmen, Projekten oder Channels. Bei Android und iOS verknüpft ein group-Aufruf nach aktuellem SDK-Verhalten auch die folgenden Events der Session mit der Group. Bei anderen SDKs braucht jedes relevante Event die Group-Information einzeln, ein Detail, das sich pro verwendeter Library lohnt zu prüfen.

Mobile Session Replay: maskiert, aber nicht überall gleich

Session Replay ist für Android, iOS, React Native und Flutter allgemein verfügbar, startet im mobilen SDK aber nicht automatisch. Projekt und SDK-Konfiguration schalten die Aufzeichnung explizit ein. Sensible Eingaben wie Passwortfelder maskiert PostHog automatisch, die Maskierung läuft direkt auf dem Endgerät [6].

Native Android- und iOS-Apps nutzen standardmäßig den Wireframe-Modus mit maskiertem Text und maskierten Bildern, der Screenshot-Modus bleibt optional. React Native und Flutter arbeiten immer im Screenshot-Modus [7]. Jetpack Compose [9] und SwiftUI [8] verlangen für Replay ebenfalls Screenshots und damit besondere Sorgfalt bei sensiblen Views. Drittanbieter-, Authentifizierungs- und Payment-Screens gehören bei Bedarf komplett aus der Aufzeichnung heraus, Sampling und kurze Retention ersetzen die pauschale Vollaufzeichnung.

Feature Flags und Experimente: Exposure entscheidet

Ein Feature Flag ist ein remote auswertbarer Schalter. Der zugehörige Code ist einmal veröffentlicht, danach ändern sich Zielgruppen, Rollout-Prozente, Varianten und Payloads ohne neuen Release. PostHog weist Nutzer deterministisch anhand ihrer Identität Buckets zu, die Zuordnung bleibt dadurch stabil.

Für saubere Experimente zählt der Flag-Wert beim Exposure-Event. Mit PostHog-SDKs erfasst $feature_flag_called die Exposure in der Regel automatisch, Metrik-Events vor der ersten Exposure fließen nicht in die Auswertung ein [10]. PostHog rechnet standardmäßig bayesianisch; frequentistische Auswertung steht als Alternative bereit [11]. Klingt nach viel Statistik, ist aber vor allem Handwerk: Hypothese, Primärmetrik, Guardrail-Metriken, Laufzeit und benötigte Stichprobe gehören vor dem Launch auf den Tisch. Bei kleinen Nutzerzahlen bringt ein qualitativer Replay- oder Research-Ansatz oft mehr als ein dauerhaft unterpowertes Experiment.

Consent, Hosting und die DSGVO-Realität

Apples ATT-Zustimmung und die Analytics-Einwilligung sind zwei getrennte Gates. Ob am Ende Einwilligung, berechtigtes Interesse oder eine andere Rechtsgrundlage greift, klärt der Datenschutzbeauftragte des Projektpartners, nicht das Analytics-Tool selbst. PostHogs eigene GDPR-Anleitung empfiehlt einen Consent-Mechanismus und weist ausdrücklich darauf hin, dass sie keine Rechtsberatung ersetzt.

Technisch stellt PostHog einen zentralen Opt-in/Opt-out-Schalter bereit. Ein Opt-out verhindert manuelle Events, Autocapture und Session Replay gleichermaßen. In Android und iOS setzt sich optOut bereits beim SDK-Setup auf true, sofern das Consent-Konzept das verlangt, optIn folgt erst nach gültiger Entscheidung. Bei Widerruf greift optOut, Consent-Version, Zeitpunkt und Zweck landen zusätzlich in der eigenen Consent-Lösung. Session Replay verdient dabei aus Prinzip eine strengere Bewertung als reine Event-Analyse.

Wo die Daten tatsächlich liegen

PostHog Cloud EU läuft auf Servern in Frankfurt und gilt laut aktueller Privacy-Dokumentation als EU-Datenresidenz, PostHog empfiehlt die Option für robuste GDPR-Setups [12]. Das Unternehmen dahinter sitzt trotzdem nicht in Europa: PostHog Inc. ist ein US-Unternehmen mit San Francisco als offizieller Adresse in der Privacy Policy [13]. EU-Datenresidenz und EU-Unternehmenssitz sind zwei verschiedene Dinge, ein Missverständnis, das in Projekten regelmäßig für Verwirrung sorgt.

Für neue EU-Organisationen ist die IP-Erfassung standardmäßig deaktiviert, bestehende Projekte behalten ihre bisherige Einstellung und verdienen einen Blick vor dem Go-live [12]. PostHog löscht auf Anfrage Personen und deren Events, die Löschung läuft asynchron [14]. Wer volle Infrastrukturkontrolle statt eines Managed-Angebots sucht, hostet PostHog selbst, trägt dann aber Betrieb, Skalierung, Security und Updates komplett in Eigenregie.

Vom Konzept zur Produktion: ein Tracking-Setup, das den Launch übersteht

Ein belastbares Tracking-Konzept beginnt mit Messfragen, und eben nicht mit Event-Namen. Vor dem ersten Event-Namen steht die Frage: Welche Entscheidung ermöglicht diese Kennzahl später? Aus der Antwort entstehen Kern-Funnel und Signatur-Events der jeweiligen Journey, im E-Commerce etwa product_viewed, add_to_cart, checkout_started und order_completed, im Sportumfeld eher favorite_team_set, push_opt_in_completed oder ticket_purchase_completed.

Für jedes Event gehören Trigger, Pflicht-Properties, Plattform, Identity-Status und Consent-Status in die Dokumentation, bevor das erste Ticket in die Entwicklung geht. Property-Namen bekommen dabei bewusst Klarheit.

Nach der Konzeptphase wandert das Event-Schema in Development-Tickets, Plattformparität zwischen Android und iOS steht dabei von Anfang an fest. Vor dem Release folgt eine Staging-QA, die Event, Trigger, Datentyp, Wert, Identity und Consent einzeln prüft. Nach dem Launch behaltet ihr app_version im Blick und haltet alte von neuen Event-Versionen bewusst auseinander, bevor überhaupt ein Dashboard entsteht.

Was vor dem Go-live geprüft wird

• Jedes Event feuert genau am definierten fachlichen Moment.
• Pflicht-Properties sind vollständig, korrekt typisiert und frei von personenbezogenen Daten.
• Android und iOS liefern vergleichbare Semantik.
• identify, reset und Group-Verknüpfungen funktionieren über die relevanten Journeys hinweg.
• Ein Opt-out verhindert Events, Autocapture und Replay zuverlässig.
• Session Replay zeigt keine sensiblen Inhalte.
• Experiment-Exposure verknüpft sich korrekt mit den Zielmetriken.

Der Nordstern dahinter bleibt einfach: nicht möglichst viel messen, sondern die kleinste belastbare Datengrundlage schaffen, mit der Product, Marketing und Design tatsächlich Entscheidungen treffen.

Fazit

PostHog macht aus einer nativen App kein Web-Analytics-Projekt mit anderem Icon. Wer Attribution, Produktanalyse und Datenschutz von Anfang an sauber trennt, bekommt ein Tool, das Android, iOS und Kotlin Multiplatform ernst nimmt, ohne eine Kampagnen-Attribution zu versprechen, die es technisch nicht leistet. Genau diese Trennschärfe entscheidet darüber, ob ein Tracking-Setup nach dem Launch noch Vertrauen genießt oder schon in der zweiten Sprintwoche repariert werden muss. Baut es gleich richtig.

Du willst mehr aus deiner App herausholen?

Discovery Call mit Christian buchen

Quellen

1. PostHog. (o. D.). Android – Docs. PostHog. Abgerufen am 18. August 2026.

2. PostHog. (o. D.). Identifying users – Docs. PostHog. Abgerufen am 18. August 2026.

3. Apple Inc. (o. D.). If an app asks to track your activity. Apple Support. Abgerufen am 18. August 2026.

4. PostHog. (o. D.). Kotlin Multiplatform – Docs. PostHog. Abgerufen am 18. August 2026.

5. PostHog. (o. D.). Anonymous vs identified events – Docs. PostHog. Abgerufen am 18. August 2026.

6. PostHog. (o. D.). Session replay privacy controls – Docs. PostHog. Abgerufen am 18. August 2026.

7. PostHog. (o. D.). Mobile session replay – Docs. PostHog. Abgerufen am 18. August 2026.

8. PostHog. (o. D.). iOS session replay installation – Docs. PostHog. Abgerufen am 18. August 2026.

9. PostHog. (o. D.). Android session replay installation – Docs. PostHog. Abgerufen am 18. August 2026.

10. PostHog. (o. D.). Exposures – Docs. PostHog. Abgerufen am 18. August 2026.

11. PostHog. (o. D.). Frequentist statistical method – Docs. PostHog. Abgerufen am 18. August 2026.

12. PostHog. (o. D.). PostHog & GDPR compliance – Docs. PostHog. Abgerufen am 18. August 2026.

13. PostHog, Inc. (2026, 29. Juni). Privacy policy, PostHog style. PostHog. Abgerufen am 18. August 2026.

14. PostHog. (o. D.). People – Docs. PostHog. Abgerufen am 18. August 2026.