Beginnt die Registrierung einer App mit der Datenerfassung?

Nein. Die Registrierung erzeugt die öffentliche Property-ID der App und sonst nichts. Ereignisse erscheinen, sobald die App das SDK installiert hat, es mit der Einwilligungsentscheidung des Nutzers startet, Ereignisse sendet und sie zustellt.

Wann verlassen die Ereignisse das Gerät?

Etwa 5 Sekunden nach ihrer Erfassung, unter iOS wie unter Android, ohne Aufruf durch die App; außerdem, wenn die App in den Hintergrund wechselt (ohne Garantie: das System kann die App vorher anhalten), und nach dem nächsten Start für alles, was noch gepuffert ist. Solange die App läuft, werden fehlgeschlagene Anfragen von selbst wiederholt; eine angehaltene oder geschlossene App sendet nichts, bis sie wieder läuft. Vor dem iOS-SDK 1.3.0 und webmasterid_flutter 0.4.0 sendete iOS nur, wenn die App flush() aufrief oder in den Hintergrund wechselte; ein Update bringt die automatische Zustellung.

Brauche ich eine Website, um die App-Analyse zu nutzen?

Nein. Öffnen Sie nach dem Bezahlen iOS-Apps oder Android-Apps im Dashboard und registrieren Sie die App. Die App-Berichte hängen nicht von einer Website ab.

Ersetzt WebmasterID AppsFlyer oder Adjust?

Nein. Das sind Mobile Measurement Partner: Sie ordnen Installationen Werbenetzwerken und Kampagnen zu. Die SDKs von WebmasterID senden weder Quelle noch Kampagne noch Referrer, und WebmasterID verbindet sich weder mit Werbenetzwerken noch mit SKAdNetwork, AdServices oder dem Install Referrer.

Sind die Daten anonym?

Nein. Installationskennungen und Kontoschlüssel werden als Hashes mit geheimem Schlüssel gespeichert, das macht sie pseudonym, nicht anonym. Mit eingeschränkter Einwilligung tragen Ereignisse nur eine Sitzungskennung: eine reduzierte Identifizierung, die trotzdem keine Anonymität ist.

Wird die IDFA verwendet oder App Tracking Transparency abgefragt?

Nein. Der Server lehnt Werbe- und Gerätekennungen ab, und WebmasterID fragt ATT nicht ab. Eine ATT-Antwort ist keine Einwilligung in die Analyse: Die App übergibt dem SDK ihre eigene Analyse-Entscheidung.

Kann ich die Website- und App-Aktivität derselben Person sehen?

Nein. Websites und Apps erscheinen nebeneinander in einem Workspace, aber die Kennungen werden pro Website und pro App gehasht, deshalb werden ein Besucher und ein App-Nutzer nie verknüpft, und auch nicht derselbe Nutzer zwischen einer iOS- und einer Android-App.

Welche Käufe zählen als Umsatz?

Nur bei Apple oder Google verifizierte Käufe: Produktionstransaktionen mit Umsatz, brutto vor Erstattungen und pro Währung. Sandbox- und Testkäufe zählen nie. Zahlungsereignisse, die die App meldet, erscheinen als Angaben der App selbst, getrennt vom Umsatz.

Funktioniert es mit RevenueCat?

Nein. Die Kaufprüfung funktioniert mit StoreKit 2 unter iOS und Google Play Billing unter Android. RevenueCat und andere Kauf-Frameworks werden nicht unterstützt.

Funktioniert es mit React Native oder Unity?

Nein. Es gibt native SDKs für iOS (Swift) und Android (Kotlin oder Java) und ein Flutter-Plugin für iOS- und Android-Apps. React Native, Unity und .NET werden nicht unterstützt.

Die App-Analyse ist in Pro (499 USD pro Monat) und Agency (1.199 USD pro Monat) enthalten, ebenso in individuell vereinbarten Business-Tarifen. Die SDK-Pakete sind öffentlich herunterladbar; Ereignisse senden und die Berichte ansehen erfordert einen aktiven Tarif. Für neue Konten gibt es keinen kostenlosen Tarif.

Datenschutzfreundliche Mobile-App-Analyse

Mobile-App-Analyse für iOS, Android und Flutter

Installieren Sie ein öffentliches SDK, übergeben Sie ihm die Einwilligungsentscheidung jedes Nutzers und senden Sie Ereignisse. WebmasterID zeigt Ereignisse, Sitzungen, Installationen, Bindung und Conversions Ihrer iOS- und Android-Apps im selben Workspace wie Ihre Websites, und die Berichte sagen, was sie nicht beantworten können.

Preise ansehen Installationsanleitung (auf Englisch)

Plattformen

Native SDKs für iOS und Android und ein Plugin für Flutter

Sie werden über den öffentlichen Paketkanal der jeweiligen Plattform installiert: kein privates Repository, kein Zugangstoken und keine Zugangsdaten, die Sie Ihrem Build-Server hinzufügen müssten.

iOS
Swift Package Manager. WebmasterID iOS SDK 1.3.0, für iOS 15.0 oder neuer, aus einem öffentlichen Swift-Paket auf GitHub.
Android
Gradle, mit Kotlin oder Java. WebmasterID Android SDK 0.3.0, für API 24 oder neuer, aus dem öffentlichen Maven-Repository unter webmasterid.com/sdk/maven.
Flutter
pub.dev: webmasterid_flutter 0.4.0, für Flutter 3.47.0 oder neuer, in iOS- und Android-Apps. Es baut auf den nativen SDKs auf.

React Native, Unity und .NET werden nicht unterstützt. Das Flutter-Plugin deckt iOS- und Android-Apps ab, nicht Flutter für Web oder Desktop.

Was Sie messen können

Fünf Berichte aus den Ereignissen, die Ihre App sendet

Jeder Bericht zählt nach dem Zeitpunkt, zu dem WebmasterID das Ereignis empfangen hat, nicht nach der Uhr des Geräts, und die wichtigsten Kennzahlen sind auf der Seite definiert.

Übersicht
Ereignisse, Sitzungen, aktive Installationen, erstmals beobachtete Installationen und identifizierte Nutzer, mit Ereignissen pro Tag, den häufigsten Ereignissen und dem Tracking-Zustand: wann das letzte Ereignis ankam.
Ereignisse
Jeder Ereignisname mit seinen Anzahlen und Sitzungen, die häufigsten Bildschirme und Länder sowie die 50 neuesten Ereignisse mit gekürzten pseudonymen Kennungen.
Conversions
Die Funnel-Ereignisse, die Ihre App meldet, in einer Tabelle; bei Apple oder Google verifizierte Käufe in einer anderen. Die beiden werden nie addiert.
Bindung (Beta)
Retention-Kohorten für Tag 1, 7 und 30 pro Installation, in Ihrer Berichtszeitzone. Ein Tag, der noch nicht vergangen ist, erscheint als noch nicht beobachtbar, nie als 0 %.
Attribution
Was über die Herkunft der App-Aktivität bekannt ist und was nicht. Die SDKs senden weder Quelle noch Kampagne noch Referrer, deshalb erscheint die Herkunft von Installationen als unbekannt, nie als organisch.

Ein festes Vokabular aus 14 Ereignissen, damit die Berichte jeder App dasselbe bedeuten: app_open, session_start, screen_view, cta_tap, search_performed, filter_applied, signup, login, checkout_started, booking_started, payment_started, booking_completed, cancellation, refund_requested.

Ereignisse halten den Bildschirm fest, auf dem sie passiert sind, sofern es einen gibt. Eigene Ereignisnamen und Eigenschaften werden nicht unterstützt, und App-Version, Betriebssystemversion und Einwilligungsstatus werden beim Eingang geprüft, aber nicht gespeichert, deshalb gibt es keine Aufschlüsselung danach.

Websites und Apps

Ihre Websites und Apps in einem Workspace, nebeneinander

Teams mit einer Website und einer App sehen beides an einem Ort und mit einem Tarif. Die Berichte bleiben getrennt: WebmasterID führt einen Website-Besucher und einen App-Nutzer nicht zu einer Person zusammen.

Gemeinsam
Ein Konto, ein Workspace und ein Tarif. Ein Dashboard mit den Bereichen Websites und Mobile Apps in der Seitenleiste. Der Zeitraum bleibt beim Wechsel zwischen beiden erhalten, mit einer einzigen Berichtszeitzone.
Getrennt
Es gibt keinen kombinierten Website-und-App-Bericht, keinen Weg von einem Website-Besuch in die App und keinen geräteübergreifenden Abgleich einer Person: Der Kontoschlüssel wird pro App als anderer Hash gespeichert, deshalb zählt derselbe Nutzer einmal in der iOS-App und noch einmal in der Android-App.

Installation

Von der Installation zum ersten Ereignis

Eine App zu registrieren, erfasst noch nichts. Ereignisse erscheinen, sobald das SDK installiert ist, mit der Einwilligungsentscheidung des Nutzers gestartet wird, Ereignisse sendet und sie zustellt.

Bevor Sie beginnen

Ein aktiver Pro-, Agency- oder Business-Tarif im Workspace; die Rolle Inhaber, Admin oder Bearbeiter, um eine App zu registrieren; iOS 15.0 oder neuer, gebaut mit Xcode 26.0 oder neuer, Android API 24 oder neuer mit Gradle, oder Flutter 3.47.0 oder neuer; und eine Stelle in Ihrer App, an der der Nutzer über die Analyse entscheidet und deren Antwort die App an das SDK weitergibt. Kein GitHub-Konto, kein Zugangstoken und kein privates Repository nötig.

1. Tarif wählenErstellen Sie ein Konto und wählen Sie beim Bezahlen Pro oder Agency. Die App-Analyse ist in beiden enthalten.
2. App registrierenUnter iOS-Apps oder Android-Apps im Dashboard. Sie erhalten eine öffentliche Property-ID: Sie darf in der App ausgeliefert werden, ist kein Geheimnis und erfasst für sich allein nichts.
3. SDK hinzufügenÜber den Swift Package Manager, das Maven-Repository von WebmasterID oder pub.dev.
4. Mit einer Einwilligungsentscheidung startenInitialisieren Sie das SDK mit der Property-ID und übergeben Sie ihm die Entscheidung des Nutzers. Solange es keine Entscheidung gibt, wird nichts gepuffert oder gesendet.
5. Ereignisse sendenBildschirmaufrufe, Tipps und die Funnel-Schritte, die Ihnen wichtig sind. In Flutter erfassen die Lifecycle- und Navigations-Observer des Plugins app_open und screen_view für Sie.
6. ZustellenDas SDK erledigt das selbst, unter iOS und Android: etwa 5 Sekunden nach einem Ereignis, wenn die App in den Hintergrund wechselt, und nach dem nächsten Start für alles, was noch aussteht. flush() ist nur für einen Zeitpunkt, den die App selbst wählt.
7. Erstes Ereignis bestätigenUnter Mobile Apps → App-Übersicht zeigt der Tracking-Zustand das zuletzt empfangene Ereignis. Kommt nichts an, erklären die Prüfschritte der Anleitung und die SDK-Diagnose, warum.

Einwilligung und Identität

Einwilligung und Identität, verständlich erklärt

WebmasterID erfasst, was Ihre App sendet, mit der Entscheidung, die die App übergibt. Ob eine Einwilligung nötig ist und auf welcher Rechtsgrundlage, entscheiden Sie; das SDK macht eine App nicht von sich aus rechtskonform.

Keine Entscheidung, keine Daten
Bis Ihre App die Entscheidung des Nutzers übergibt, puffert das SDK nichts und sendet nichts.
Erlaubt
Ereignisse tragen eine Sitzungskennung, eine Installationskennung und, wenn die App identify() aufruft, einen Kontoschlüssel. Installationskennungen und Kontoschlüssel werden als Hashes mit geheimem Schlüssel gespeichert: pseudonym, nicht anonym.
Eingeschränkt
Ereignisse tragen nur eine Sitzungskennung: weder Installationskennung noch Kontoschlüssel. Das ist eine reduzierte Identifizierung, keine Anonymität: Sitzungskennung, genaue Zeitpunkte und Land bleiben erhalten.
Abgelehnt
Es wird nichts gesendet.
Keine Werbe-IDs
Der Server lehnt IDFA, IDFV, die Android-Werbe-ID und andere Gerätekennungen ab. App Tracking Transparency wird nicht abgefragt, und eine ATT-Antwort ist keine Einwilligung in die Analyse.
Keine gespeicherte IP-Adresse
Das Land wird beim Eingang des Ereignisses am Netzwerkrand ermittelt. Weder IP-Adresse noch User-Agent werden gespeichert.

Die Installationsanleitung (auf Englisch) beschreibt die Einwilligungszustände, die Kennungen und das, was die SDKs senden, für die Datenschutzangaben im App Store und den Abschnitt zur Datensicherheit bei Google Play.

Conversions

Gemeldete Conversions und verifizierte Käufe sind verschiedene Fakten

Ihre App kann einen begonnenen Bezahlvorgang melden. Nur Apple oder Google können einen Kauf bestätigen. Der Conversion-Bericht führt beides in getrennten Tabellen und addiert es nie.

Von der App gemeldete Conversions
Die Funnel-Ereignisse, die Ihre App sendet, gezählt als Angaben der App selbst: signup, login, checkout_started, booking_started, payment_started, booking_completed, cancellation und refund_requested.
Vom Store verifizierte Käufe
Unter iOS von Apple signierte StoreKit-2-Transaktionen, geprüft gegen Apples Zertifikate, und App Store Server Notifications. Unter Android bei Google verifizierte Google-Play-Kauftoken und Real-time Developer Notifications. Beides braucht eine Store-Verbindung, die auf der Seite der App im Dashboard eingerichtet wird. Nur Produktionstransaktionen mit Umsatz, brutto vor Erstattungen und pro Währung. Sandbox- und Testkäufe zählen nie.

Wo die Kaufprüfung heute steht

Die Zustellung der App Store Server Notifications ist in der Produktion verifiziert. Der Google-Play-Teil ist bereitgestellt, aber noch nicht durchgängig mit einem Testkauf nachgewiesen, und noch kein Kauf hat die Sandbox eines der beiden Stores bis zur Verifizierung durchlaufen. RevenueCat und andere Kauf-Frameworks werden nicht unterstützt.

Passt es zu Ihnen?

Wofür es gedacht ist und wofür nicht

Geeignet für
Teams, die eine Website bereits mit WebmasterID messen und eine iOS- oder Android-App veröffentlichen. Apps, deren wichtige Momente in die 14 Ereignisse passen: Bildschirme, Tipps, Suche, Filter, Registrierung und Anmeldung sowie die Schritte von Buchung, Bezahlung und Kauf. Teams, die eine pseudonyme App-Analyse mit Einwilligung und ohne Werbe-IDs wollen. Agenturen, die Websites und Apps mehrerer Kunden betreuen (der Agency-Tarif bringt Workspaces und Teammitglieder mit).
Nicht gedacht für
Installationsattribution: Postbacks von Werbenetzwerken, SKAdNetwork, Apple AdServices, den Google Play Install Referrer, Deep-Link-Kampagnen, Kosten oder ROAS; WebmasterID ist kein Mobile Measurement Partner (MMP). Eigene Ereignisnamen oder Eigenschaften, oder eine einzige Journey, die einer Person von der Website in die App oder über Geräte hinweg folgt. Downloads aus dem App Store oder von Google Play: Eine erstmals beobachtete Installation ist das erste Ereignis einer Installationskennung, kein Download. Absturzberichte, Sitzungsaufzeichnung, Push-Benachrichtigungen oder A/B-Tests. Apps mit React Native, Unity oder .NET. App-Daten im Ereignis-Explorer, in Exporten oder in den MCP- und Agent-Werkzeugen, die mit Web-Daten arbeiten.

Preise

In Pro und Agency enthalten

Die SDK-Pakete sind öffentlich herunterladbar. Ereignisse senden und die App-Berichte ansehen erfordert einen aktiven Tarif. Für neue Konten gibt es keinen kostenlosen Tarif.

Pro kostet 499 USD pro Monat und Agency 1.199 USD pro Monat; Business wird individuell vereinbart. Alle drei enthalten die App-Analyse. Monatliche Abrechnung in USD, jederzeit kündbar.

Häufige Fragen

Beginnt die Registrierung einer App mit der Datenerfassung?: Nein. Die Registrierung erzeugt die öffentliche Property-ID der App und sonst nichts. Ereignisse erscheinen, sobald die App das SDK installiert hat, es mit der Einwilligungsentscheidung des Nutzers startet, Ereignisse sendet und sie zustellt.
Wann verlassen die Ereignisse das Gerät?: Etwa 5 Sekunden nach ihrer Erfassung, unter iOS wie unter Android, ohne Aufruf durch die App; außerdem, wenn die App in den Hintergrund wechselt (ohne Garantie: das System kann die App vorher anhalten), und nach dem nächsten Start für alles, was noch gepuffert ist. Solange die App läuft, werden fehlgeschlagene Anfragen von selbst wiederholt; eine angehaltene oder geschlossene App sendet nichts, bis sie wieder läuft. Vor dem iOS-SDK 1.3.0 und webmasterid_flutter 0.4.0 sendete iOS nur, wenn die App flush() aufrief oder in den Hintergrund wechselte; ein Update bringt die automatische Zustellung.
Brauche ich eine Website, um die App-Analyse zu nutzen?: Nein. Öffnen Sie nach dem Bezahlen iOS-Apps oder Android-Apps im Dashboard und registrieren Sie die App. Die App-Berichte hängen nicht von einer Website ab.
Ersetzt WebmasterID AppsFlyer oder Adjust?: Nein. Das sind Mobile Measurement Partner: Sie ordnen Installationen Werbenetzwerken und Kampagnen zu. Die SDKs von WebmasterID senden weder Quelle noch Kampagne noch Referrer, und WebmasterID verbindet sich weder mit Werbenetzwerken noch mit SKAdNetwork, AdServices oder dem Install Referrer.
Sind die Daten anonym?: Nein. Installationskennungen und Kontoschlüssel werden als Hashes mit geheimem Schlüssel gespeichert, das macht sie pseudonym, nicht anonym. Mit eingeschränkter Einwilligung tragen Ereignisse nur eine Sitzungskennung: eine reduzierte Identifizierung, die trotzdem keine Anonymität ist.
Wird die IDFA verwendet oder App Tracking Transparency abgefragt?: Nein. Der Server lehnt Werbe- und Gerätekennungen ab, und WebmasterID fragt ATT nicht ab. Eine ATT-Antwort ist keine Einwilligung in die Analyse: Die App übergibt dem SDK ihre eigene Analyse-Entscheidung.
Kann ich die Website- und App-Aktivität derselben Person sehen?: Nein. Websites und Apps erscheinen nebeneinander in einem Workspace, aber die Kennungen werden pro Website und pro App gehasht, deshalb werden ein Besucher und ein App-Nutzer nie verknüpft, und auch nicht derselbe Nutzer zwischen einer iOS- und einer Android-App.
Welche Käufe zählen als Umsatz?: Nur bei Apple oder Google verifizierte Käufe: Produktionstransaktionen mit Umsatz, brutto vor Erstattungen und pro Währung. Sandbox- und Testkäufe zählen nie. Zahlungsereignisse, die die App meldet, erscheinen als Angaben der App selbst, getrennt vom Umsatz.
Funktioniert es mit RevenueCat?: Nein. Die Kaufprüfung funktioniert mit StoreKit 2 unter iOS und Google Play Billing unter Android. RevenueCat und andere Kauf-Frameworks werden nicht unterstützt.
Funktioniert es mit React Native oder Unity?: Nein. Es gibt native SDKs für iOS (Swift) und Android (Kotlin oder Java) und ein Flutter-Plugin für iOS- und Android-Apps. React Native, Unity und .NET werden nicht unterstützt.
Was kostet es?: Die App-Analyse ist in Pro (499 USD pro Monat) und Agency (1.199 USD pro Monat) enthalten, ebenso in individuell vereinbarten Business-Tarifen. Die SDK-Pakete sind öffentlich herunterladbar; Ereignisse senden und die Berichte ansehen erfordert einen aktiven Tarif. Für neue Konten gibt es keinen kostenlosen Tarif.

Verwandt