Firebase est une plateforme, et l'analytics n'en est qu'une partie. La plupart des articles sur « remplacer Firebase » veulent discrètement dire remplacer le tout, ce qui est une décision différente et bien plus vaste. Il s'agit ici de la seule partie analytics : ce qui change si vous retirez Google Analytics for Firebase d'une application, ce qu'il faut garder, et ce qui n'a vraiment aucun remplaçant.

Pourquoi on se pose la question

Mesurer une application ne devrait pas exiger d'adhérer à une plateforme publicitaire. Firebase Analytics conserve un identifiant d'instance d'application sur l'appareil et est conçu pour fonctionner avec les identifiants publicitaires des plateformes (l'identifiant publicitaire d'Android, l'IDFA d'Apple) parce que l'attribution aux campagnes publicitaires est une bonne part de sa raison d'être. Si vous ne faites pas de publicité, vous transportez la machinerie quand même.

Le consentement. Un identifiant sur l'appareil entraîne avec lui une exigence de consentement dans l'EEE et au Royaume-Uni, et une application qui demande au premier lancement perd une part de ses propres utilisateurs dans ses propres chiffres. Le même raisonnement qu'une bannière de cookies sur un site web, avec une plus mauvaise première impression.

Le modèle d'événements. Firebase Analytics est un système d'événements et de paramètres. Il récompense une équipe qui modélise ses événements avec soin et donne très peu à celle qui ne le fait pas, ce qui est le cas de la plupart des équipes pendant la plus grande partie de la vie d'un produit.

Un fournisseur, une relation. Certaines organisations ne peuvent tout simplement pas envoyer l'usage de leur application à Google. C'est un fait d'achat plutôt qu'un argument, et c'est la raison pour laquelle une grande part des gens qui lisent ceci le lisent.

Ce qu'envoie à la place un SDK d'application qui privilégie la vie privée

La question utile n'est pas « est-ce privé » mais « qu'y a-t-il dans la charge utile ». Les SDK d'application de Skomi envoient :

  • le nom d'écran que vous lui avez donné, vos propriétés, et s'il a ouvert la session
  • la plateforme, la version de l'OS, et si l'appareil est mobile ou de bureau
  • la version d'application que vous avez passée, et quelle compilation du SDK l'a envoyée
  • quand cela s'est produit selon l'horloge de l'appareil, et quand le lot a été vidé
  • une identité : un UUID aléatoire que l'installation se génère à elle-même

Rien d'autre. Pas d'identifiant publicitaire, pas d'identifiant d'appareil, pas de localisation, pas de compte, pas de contacts, et donc aucune autorisation à l'exécution sur aucune plateforme au-delà de l'accès à Internet, parce qu'aucune des choses qui en exigeraient une n'est demandée.

C'est l'échange en une ligne : vous ne pouvez plus rapprocher l'usage de l'application d'une campagne publicitaire, et vous n'avez plus à demander la permission de qui que ce soit pour les compter.

Gardez votre rapporteur de plantages

C'est la partie que les gens se figurent de travers, et la documentation des SDK de Skomi le dit franchement plutôt que de vous laisser le découvrir.

Un SDK d'analytics d'application peut rapporter les erreurs que votre code lui remet et celles que le framework lève. Il ne peut pas rapporter un plantage natif (un segfault dans le C++ d'un plugin, un arrêt pour manque de mémoire, une NSException venue d'un canal de plateforme) parce que le processus qui ferait le rapport a déjà disparu.

Crashlytics, Sentry ou le rapport du store restent donc en place. Ce que vous obtenez du côté analytics, c'est un taux sans plantage posé à côté de vos chiffres de version, qui répond à une autre question : non pas « qu'est-ce qui a cassé » mais « cette compilation est-elle pire que la précédente ». Bon à savoir : ce taux penche du côté pessimiste, parce qu'une session qui a planté avant son premier écran compte comme plantée et non comme une session, ce qui est la bonne direction dans laquelle se tromper.

Il n'y a pas non plus de téléversement de fichier de correspondance : une pile d'appels issue d'une compilation de production minifiée arrive telle qu'elle a été levée. Une raison de plus pour que le rapporteur de plantages reste.

Ce qui n'a aucun remplaçant

Soyons honnêtes sur le reste de la plateforme, parce qu'« alternative à Firebase » veut souvent dire bien plus que l'analytics :

  • Remote Config, les tests A/B, Cloud Messaging, Authentication, Firestore : rien de tout cela n'est de l'analytics et rien de tout cela n'est remplacé par un outil d'analytics.
  • Les audiences et l'attribution publicitaire. Construire une audience dans Firebase et l'utiliser dans Google Ads est l'intégration pour laquelle Firebase Analytics existe. Retirez l'identifiant publicitaire et cela part avec lui, par construction.
  • L'export brut des événements. Firebase peut déverser chaque événement dans BigQuery. L'API d'application de Skomi répond par des agrégats (résumés, séries temporelles, répartitions) et non par une table d'événements à modéliser vous-même.

Si l'un de ces trois points est porteur pour vous, ce n'est pas un échange que vous voulez faire.

Ce que vous obtenez et que Firebase ne vous donne pas

  • Les mêmes rapports pour votre site et votre application, dans un seul compte. Une livraison et une campagne marketing la même semaine sont deux courbes sur la même page plutôt que deux produits et une supposition. Voir un seul endroit pour l'analytics des applications et des sites.
  • Une file hors ligne qui ne compte pas deux fois. Chaque écran porte un identifiant émis une fois : un lot réessayé après quinze jours sans signal est donc reconnu plutôt que compté de nouveau.
  • Un interrupteur de consentement qui le pense vraiment. Enabled = false n'enregistre rien et n'envoie rien : le SDK peut donc exister dès le démarrage et ne commencer qu'une fois que quelqu'un a donné son accord.

Le résumé honnête

Si vous utilisez Firebase pour l'authentification, la messagerie et une base de données, ceci en remplace un composant et vous gardez le reste, Crashlytics compris.

Si vous avez ajouté Firebase à une application uniquement pour savoir combien de gens l'ouvrent et quels écrans ils atteignent, vous transportez une plateforme publicitaire pour répondre à une question qui n'en a pas besoin, et la retirer est un petit changement avec un effet disproportionné sur ce que vous avez à déclarer.

L'installation tient en un appel : Flutter, .NET MAUI, ou l'un des huit SDK.

Ce qui arrive une fois qu'elle rapporte est sur la page App analytics : écrans, sessions, versions et le taux sans plantage. Le reste du champ, y compris les produits qui nous battent sur le prix, est exposé sur les alternatives à Firebase.