Enregistrer une application lance-t-il la collecte de données ?

Non. L’enregistrement crée l’identifiant public de propriété de l’application, et rien d’autre. Les événements apparaissent une fois que l’application a installé le SDK, l’a démarré avec la décision de consentement de l’utilisateur, envoie des événements et les transmet.

Quand les événements quittent-ils l’appareil ?

Environ 5 secondes après leur enregistrement, sur iOS comme sur Android, sans aucun appel de l’application ; aussi quand l’application passe en arrière-plan (sans garantie : le système peut la suspendre avant) et, après le lancement suivant, pour ce qui est encore en file d’attente. Tant que l’application s’exécute, les requêtes en échec sont relancées d’elles-mêmes ; une application suspendue ou fermée n’envoie rien avant de s’exécuter à nouveau. Avant le SDK iOS 1.3.0 et webmasterid_flutter 0.4.0, iOS n’envoyait que lorsque l’application appelait flush() ou passait en arrière-plan ; la mise à jour apporte la transmission automatique.

Faut-il un site pour utiliser l’analyse d’applications ?

Non. Après le paiement, ouvrez Applications iOS ou Applications Android dans le tableau de bord et enregistrez l’application. Les rapports d’applications ne dépendent pas d’un site.

WebmasterID remplace-t-il AppsFlyer ou Adjust ?

Non. Ce sont des partenaires de mesure mobile : ils attribuent les installations aux réseaux publicitaires et aux campagnes. Les SDK de WebmasterID n’envoient ni source, ni campagne, ni référent, et WebmasterID ne se connecte ni aux réseaux publicitaires, ni à SKAdNetwork, ni à AdServices, ni à l’Install Referrer.

Les données sont-elles anonymes ?

Non. Les identifiants d’installation et les clés de compte sont stockés sous forme de hachages à clé, ce qui les rend pseudonymes, pas anonymes. Avec le consentement restreint, les événements ne portent qu’un identifiant de session : une identification réduite, qui n’est toujours pas l’anonymat.

Utilisez-vous l’IDFA ou demandez-vous App Tracking Transparency ?

Non. Le serveur refuse les identifiants publicitaires et d’appareil, et WebmasterID ne demande pas l’ATT. Une réponse à l’ATT ne vaut pas consentement à l’analyse : l’application transmet au SDK sa propre décision concernant l’analyse.

Puis-je voir l’activité d’une même personne sur le site et dans l’application ?

Non. Les sites et les applications apparaissent côte à côte dans un espace de travail, mais les identifiants sont hachés par site et par application : un visiteur et un utilisateur de l’application ne sont jamais reliés, pas plus que le même utilisateur entre une application iOS et une application Android.

Quels achats comptent comme revenu ?

Uniquement les achats vérifiés auprès d’Apple ou de Google : transactions de production porteuses de revenu, en brut avant remboursements et par devise. Les achats de bac à sable et de test ne comptent jamais. Les événements de paiement déclarés par l’application apparaissent comme des déclarations de l’application elle-même, séparés du revenu.

Est-ce compatible avec RevenueCat ?

Non. La vérification des achats fonctionne avec StoreKit 2 sur iOS et Google Play Billing sur Android. RevenueCat et les autres frameworks d’achat ne sont pas pris en charge.

Est-ce compatible avec React Native ou Unity ?

Non. Il existe des SDK natifs pour iOS (Swift) et Android (Kotlin ou Java), et un plugin Flutter pour les applications iOS et Android. React Native, Unity et .NET ne sont pas pris en charge.

Analyse d’applications mobiles respectueuse de la vie privée

Analyse d’applications mobiles pour iOS, Android et Flutter

Installez un SDK public, transmettez-lui la décision de consentement de chaque utilisateur et envoyez des événements. WebmasterID affiche les événements, les sessions, les installations, la rétention et les conversions de vos applications iOS et Android dans le même espace de travail que vos sites, et les rapports indiquent ce à quoi ils ne peuvent pas répondre.

Voir les tarifs Guide d’installation (en anglais)

Plateformes

Des SDK natifs pour iOS et Android, et un plugin pour Flutter

Ils s’installent depuis le canal public de paquets de chaque plateforme : pas de dépôt privé, pas de jeton d’accès, pas d’identifiants à ajouter à votre serveur de compilation.

iOS
Swift Package Manager. SDK WebmasterID pour iOS 1.3.0, pour iOS 15.0 ou ultérieur, depuis un paquet Swift public sur GitHub.
Android
Gradle, avec Kotlin ou Java. SDK WebmasterID pour Android 0.3.0, pour l’API 24 ou ultérieure, depuis le dépôt Maven public webmasterid.com/sdk/maven.
Flutter
pub.dev : webmasterid_flutter 0.4.0, pour Flutter 3.47.0 ou ultérieur, dans les applications iOS et Android. Il s’appuie sur les SDK natifs.

React Native, Unity et .NET ne sont pas pris en charge. Le plugin Flutter couvre les applications iOS et Android, pas Flutter pour le web ou le bureau.

Ce que vous pouvez mesurer

Cinq rapports construits à partir des événements envoyés par votre application

Chaque rapport compte selon le moment où WebmasterID a reçu l’événement, pas selon l’horloge de l’appareil, et les indicateurs principaux sont définis sur la page.

Vue d’ensemble
Événements, sessions, installations actives, installations observées pour la première fois et utilisateurs identifiés, avec les événements par jour, les principaux événements et l’état de la collecte : quand le dernier événement est arrivé.
Événements
Chaque nom d’événement avec ses volumes et ses sessions, les principaux écrans et pays, et les 50 événements les plus récents avec des identifiants pseudonymes abrégés.
Conversions
Les événements d’entonnoir déclarés par votre application dans un tableau ; les achats vérifiés auprès d’Apple ou de Google dans un autre. Les deux ne sont jamais additionnés.
Rétention (bêta)
Cohortes à J1, J7 et J30 par installation, dans votre fuseau horaire de rapport. Un jour qui n’est pas encore passé apparaît comme pas encore observable, jamais comme 0 %.
Attribution
Ce que l’on sait de l’origine de l’activité de l’application, et ce que l’on ne sait pas. Les SDK n’envoient ni source, ni campagne, ni référent : l’origine des installations apparaît donc comme inconnue, jamais comme organique.

Un vocabulaire fixe de 14 événements, pour que les rapports de chaque application aient le même sens : 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.

Les événements enregistrent l’écran où ils se sont produits, lorsqu’il y en a un. Les noms d’événements et les propriétés personnalisés ne sont pas pris en charge, et la version de l’application, la version du système et l’état du consentement sont vérifiés à l’arrivée de l’événement mais ne sont pas conservés : il n’y a donc pas de ventilation selon ces critères.

Sites et applications

Vos sites et vos applications dans un même espace de travail, côte à côte

Les équipes qui ont un site et une application voient les deux au même endroit, avec une seule formule. Les rapports restent séparés : WebmasterID ne fusionne pas un visiteur du site et un utilisateur de l’application en une même personne.

En commun
Un compte, un espace de travail et une formule. Un tableau de bord avec les sections Sites web et Applications dans la barre latérale. La période choisie est conservée quand vous passez de l’une à l’autre, avec un seul fuseau horaire de rapport.
Séparé
Il n’y a ni rapport combiné site et application, ni parcours d’une visite du site vers l’application, ni rapprochement d’une personne entre appareils : la clé de compte est stockée sous un hachage différent dans chaque application, donc le même utilisateur compte une fois dans l’application iOS et une autre fois dans l’application Android.

Installation

De l’installation au premier événement

Enregistrer une application ne collecte rien. Les événements apparaissent une fois que le SDK est installé, démarré avec la décision de consentement de l’utilisateur, et que l’application envoie des événements et les transmet.

Avant de commencer

Une formule Pro, Agency ou Business active dans l’espace de travail ; le rôle Propriétaire, Administrateur ou Éditeur pour enregistrer une application ; iOS 15.0 ou ultérieur compilé avec Xcode 26.0 ou ultérieur, Android API 24 ou ultérieure avec Gradle, ou Flutter 3.47.0 ou ultérieur ; et un endroit de votre application où l’utilisateur se prononce sur l’analyse, et dont l’application transmet la réponse au SDK. Ni compte GitHub, ni jeton d’accès, ni dépôt privé ne sont nécessaires.

1. Choisir une formuleCréez un compte et choisissez Pro ou Agency lors du paiement. L’analyse d’applications est incluse dans les deux.
2. Enregistrer l’applicationDans Applications iOS ou Applications Android, dans le tableau de bord. Vous obtenez un identifiant public de propriété : il peut être intégré à l’application, ce n’est pas un secret et, à lui seul, il ne collecte rien.
3. Ajouter le SDKDepuis Swift Package Manager, le dépôt Maven de WebmasterID ou pub.dev.
4. Le démarrer avec une décision de consentementInitialisez le SDK avec l’identifiant de propriété et transmettez-lui la décision de l’utilisateur. Tant qu’il n’y a pas de décision, rien n’est mis en file d’attente ni envoyé.
5. Envoyer des événementsAffichages d’écran, appuis et les étapes d’entonnoir qui comptent pour vous. Avec Flutter, les observateurs de cycle de vie et de navigation du plugin enregistrent app_open et screen_view pour vous.
6. Les transmettreLe SDK s’en charge seul, sur iOS comme sur Android : environ 5 secondes après un événement, quand l’application passe en arrière-plan et, après le lancement suivant, pour ce qui restait en attente. flush() ne sert qu’à un moment choisi par l’application.
7. Confirmer le premier événementDans Applications → Vue d’ensemble des applications, l’état de la collecte affiche le dernier événement reçu. Si rien n’arrive, les étapes de vérification du guide et les diagnostics du SDK expliquent pourquoi.

Consentement et identité

Consentement et identité, en termes simples

WebmasterID enregistre ce que votre application envoie, avec la décision que l’application lui transmet. C’est à vous de déterminer si un consentement est nécessaire et sur quelle base légale ; le SDK ne rend pas une application conforme à lui seul.

Sans décision, pas de données
Tant que votre application n’a pas transmis la décision de l’utilisateur, le SDK ne met rien en file d’attente et n’envoie rien.
Autorisé
Les événements portent un identifiant de session, un identifiant d’installation et, si l’application appelle identify(), une clé de compte. Les identifiants d’installation et les clés de compte sont stockés sous forme de hachages à clé : pseudonymes, pas anonymes.
Restreint
Les événements ne portent qu’un identifiant de session : ni identifiant d’installation ni clé de compte. C’est une identification réduite, pas l’anonymat : l’identifiant de session, les horaires exacts et le pays sont conservés.
Refusé
Rien n’est envoyé.
Aucun identifiant publicitaire
Le serveur refuse l’IDFA, l’IDFV, l’identifiant publicitaire Android et les autres identifiants d’appareil. App Tracking Transparency n’est pas demandé, et une réponse à l’ATT ne vaut pas consentement à l’analyse.
Aucune adresse IP conservée
Le pays est déterminé en périphérie du réseau à l’arrivée de l’événement. Aucune adresse IP ni aucun user-agent n’est conservé.

Le guide d’installation (en anglais) détaille les états de consentement, les identifiants et ce que les SDK envoient, pour les informations de confidentialité de l’App Store et la section Sécurité des données de Google Play.

Conversions

Conversions déclarées et achats vérifiés sont des faits différents

Votre application peut déclarer un paiement commencé. Seuls Apple ou Google peuvent confirmer un achat. Le rapport de conversions les présente dans des tableaux séparés et ne les additionne jamais.

Conversions déclarées par l’application
Les événements d’entonnoir que votre application envoie, comptés comme des déclarations de l’application elle-même : signup, login, checkout_started, booking_started, payment_started, booking_completed, cancellation et refund_requested.
Achats vérifiés par la boutique
Sur iOS, des transactions StoreKit 2 signées par Apple, vérifiées avec les certificats d’Apple, et les App Store Server Notifications. Sur Android, des jetons d’achat Google Play vérifiés auprès de Google et les notifications en temps réel pour les développeurs. Chacune nécessite une connexion à la boutique configurée sur la page de l’application dans le tableau de bord. Uniquement les transactions de production porteuses de revenu, en brut avant remboursements et par devise. Les achats de bac à sable et de test ne comptent jamais.

Où en est la vérification des achats

La réception des notifications de l’App Store est vérifiée en production. La partie Google Play est déployée mais n’a pas encore été prouvée de bout en bout par un achat test, et aucun achat n’a encore traversé le bac à sable de l’une ou l’autre boutique jusqu’à la vérification. RevenueCat et les autres frameworks d’achat ne sont pas pris en charge.

Est-ce pour vous ?

À quoi elle sert, et à quoi elle ne sert pas

Adaptée à
Les équipes qui mesurent déjà un site avec WebmasterID et publient une application iOS ou Android. Les applications dont les moments clés tiennent dans les 14 événements : écrans, appuis, recherche, filtres, inscription et connexion, et les étapes de réservation, de paiement et d’achat. Les équipes qui veulent une analyse d’applications pseudonyme, avec consentement et sans identifiants publicitaires. Les agences qui gèrent les sites et les applications de plusieurs clients (la formule Agency ajoute des espaces de travail et des membres d’équipe).
Pas conçue pour
L’attribution des installations : postbacks des réseaux publicitaires, SKAdNetwork, Apple AdServices, le Google Play Install Referrer, les campagnes de liens profonds, le coût ou le ROAS ; WebmasterID n’est pas un partenaire de mesure mobile (MMP). Les noms ou propriétés d’événements personnalisés, ou un parcours unique qui suivrait une personne du site vers l’application ou d’un appareil à l’autre. Les téléchargements de l’App Store ou de Google Play : une installation observée pour la première fois est le premier événement d’un identifiant d’installation, pas un téléchargement. Les rapports de plantage, l’enregistrement de sessions, les notifications push ou les tests A/B. Les applications React Native, Unity ou .NET. Les données d’applications dans l’Explorateur d’événements, les exports ou les outils MCP et de l’agent, qui fonctionnent avec les données web.

Tarifs

Incluse dans Pro et Agency

Les paquets des SDK sont téléchargeables publiquement. Envoyer des événements et consulter les rapports d’applications nécessite une formule active. Il n’existe pas de formule gratuite pour les nouveaux comptes.

Pro coûte 499 USD par mois et Agency 1 199 USD par mois ; Business se négocie sur mesure. Les trois incluent l’analyse d’applications. Facturation mensuelle en USD, résiliable à tout moment.

Questions fréquentes

Enregistrer une application lance-t-il la collecte de données ?: Non. L’enregistrement crée l’identifiant public de propriété de l’application, et rien d’autre. Les événements apparaissent une fois que l’application a installé le SDK, l’a démarré avec la décision de consentement de l’utilisateur, envoie des événements et les transmet.
Quand les événements quittent-ils l’appareil ?: Environ 5 secondes après leur enregistrement, sur iOS comme sur Android, sans aucun appel de l’application ; aussi quand l’application passe en arrière-plan (sans garantie : le système peut la suspendre avant) et, après le lancement suivant, pour ce qui est encore en file d’attente. Tant que l’application s’exécute, les requêtes en échec sont relancées d’elles-mêmes ; une application suspendue ou fermée n’envoie rien avant de s’exécuter à nouveau. Avant le SDK iOS 1.3.0 et webmasterid_flutter 0.4.0, iOS n’envoyait que lorsque l’application appelait flush() ou passait en arrière-plan ; la mise à jour apporte la transmission automatique.
Faut-il un site pour utiliser l’analyse d’applications ?: Non. Après le paiement, ouvrez Applications iOS ou Applications Android dans le tableau de bord et enregistrez l’application. Les rapports d’applications ne dépendent pas d’un site.
WebmasterID remplace-t-il AppsFlyer ou Adjust ?: Non. Ce sont des partenaires de mesure mobile : ils attribuent les installations aux réseaux publicitaires et aux campagnes. Les SDK de WebmasterID n’envoient ni source, ni campagne, ni référent, et WebmasterID ne se connecte ni aux réseaux publicitaires, ni à SKAdNetwork, ni à AdServices, ni à l’Install Referrer.
Les données sont-elles anonymes ?: Non. Les identifiants d’installation et les clés de compte sont stockés sous forme de hachages à clé, ce qui les rend pseudonymes, pas anonymes. Avec le consentement restreint, les événements ne portent qu’un identifiant de session : une identification réduite, qui n’est toujours pas l’anonymat.
Utilisez-vous l’IDFA ou demandez-vous App Tracking Transparency ?: Non. Le serveur refuse les identifiants publicitaires et d’appareil, et WebmasterID ne demande pas l’ATT. Une réponse à l’ATT ne vaut pas consentement à l’analyse : l’application transmet au SDK sa propre décision concernant l’analyse.
Puis-je voir l’activité d’une même personne sur le site et dans l’application ?: Non. Les sites et les applications apparaissent côte à côte dans un espace de travail, mais les identifiants sont hachés par site et par application : un visiteur et un utilisateur de l’application ne sont jamais reliés, pas plus que le même utilisateur entre une application iOS et une application Android.
Quels achats comptent comme revenu ?: Uniquement les achats vérifiés auprès d’Apple ou de Google : transactions de production porteuses de revenu, en brut avant remboursements et par devise. Les achats de bac à sable et de test ne comptent jamais. Les événements de paiement déclarés par l’application apparaissent comme des déclarations de l’application elle-même, séparés du revenu.
Est-ce compatible avec RevenueCat ?: Non. La vérification des achats fonctionne avec StoreKit 2 sur iOS et Google Play Billing sur Android. RevenueCat et les autres frameworks d’achat ne sont pas pris en charge.
Est-ce compatible avec React Native ou Unity ?: Non. Il existe des SDK natifs pour iOS (Swift) et Android (Kotlin ou Java), et un plugin Flutter pour les applications iOS et Android. React Native, Unity et .NET ne sont pas pris en charge.
Combien cela coûte-t-il ?: L’analyse d’applications est incluse dans Pro (499 USD par mois) et Agency (1 199 USD par mois), ainsi que dans les formules Business négociées sur mesure. Les paquets des SDK sont téléchargeables publiquement ; envoyer des événements et consulter les rapports nécessite une formule active. Il n’existe pas de formule gratuite pour les nouveaux comptes.