Comment une app de 3 millions d’utilisateurs a récupéré des conversions perdues grâce au server-side tracking
La vue d’ensemble
Quand ils ont commencé à collaborer avec TAGGRS, Flitsmeister avait un objectif clair : collecter les bonnes données de manière fiable. Le résultat ? Une implémentation server-side sur 6 mois, construite autour d’un pipeline Firebase vers TAGGRS, qui envoie des signaux first-party propres vers Google Analytics, Meta et Google Ads. Entièrement côté serveur.
Voici l’étude de cas complète, racontée par Ate Keurentjes, Head of Marketing chez TAGGRS, et Lynn van Eijk, Campaign Manager chez Flitsmeister, responsable du performance marketing sur Google Ads et Meta, avec un focus sur l’acquisition d’abonnements et l’optimisation des achats in-app.
Le défi
Les parcours cross-device et les conversions non attribuées
Le moment où Flitsmeister a compris qu’il fallait changer n’est pas venu d’un audit technique. C’était une simple comparaison qui ne collait pas. En comparant les visites du site avec les données CRM d’achats, une anomalie est apparue : tous les visiteurs n’étaient pas comptabilisés, et toutes les conversions n’étaient pas attribuées.
Le modèle de Flitsmeister fait que les utilisateurs passent souvent de l’app à un environnement web pour gérer leurs abonnements, accéder à des fonctionnalités premium ou finaliser un achat. Ces transitions ont créé un angle mort. Lorsqu’un utilisateur passait de l’app au site web, il disparaissait du tracking. Le tracking client-side sur le site ne le reconnaissait pas comme utilisateur existant. Les achats réalisés dans ce parcours n’étaient tout simplement pas enregistrés.
Avec le temps, cet écart s’est creusé : une dégradation progressive de la qualité des données, visible seulement lorsque l’équipe a analysé les chiffres en détail.
Contraintes du tracking mobile
Les contraintes classiques du tracking mobile ont aggravé la situation :
- Les bannières de consentement peuvent bloquer jusqu’à 60% des signaux de tracking
- Les restrictions des navigateurs (notamment sur Safari et iOS) réduisent la durée de vie des cookies et limitent la collecte de données tierces
- Les ad blockers empêchent les scripts client-side de se charger avant même qu’un événement ne soit déclenché
Les décisions budgétaires et d’optimisation reposaient sur des données de conversion incomplètes, et il était même impossible de mesurer précisément l’ampleur du problème.
Et le problème allait au-delà du marketing. Chez Flitsmeister, les données guident les décisions dans toute l’entreprise. Avoir des données fiables n’est pas seulement essentiel pour le marketing, mais aussi pour le produit.
Pourquoi la privacy rendait ce choix stratégique
Les utilisateurs de Flitsmeister partagent leur localisation en temps réel avec l’app. C’est une relation basée sur la confiance. L’entreprise a construit sa réputation sur une gestion responsable des données, donc toute évolution du tracking devait être réellement conforme au RGPD, pas seulement sur le papier.
Pour Flitsmeister, le server-side tracking était donc un choix évident, aligné avec ses valeurs. Les approches consistant à envoyer des données brutes massivement aux plateformes publicitaires étaient exclues. L’implémentation devait répondre à trois exigences :
- Traitement des données dans un environnement contrôlé par Flitsmeister
- Hashage et anonymisation corrects des données personnelles (PII) avant leur transmission
- Conformité totale au RGPD avec des flux de données auditables
Le server-side tracking via TAGGRS répond à ces trois critères. Comme les données transitent par un serveur contrôlé par Flitsmeister plutôt que par le navigateur, l’entreprise garde le contrôle total sur ce qui est envoyé, à qui et sous quelle forme.
La solution :
implémentation de Firebase vers TAGGRS
Flitsmeister app → Firebase
Firebase → TAGGRS server
TAGGRS Server → destinations
Avec cette configuration, le navigateur — avec ses limites liées au consentement, aux ad blockers et aux cookies — ne fait plus partie du chemin critique de mesure. Les événements sont générés côté serveur et transmis server-to-server.
Une implémentation sur mesure et fiable
Comparé à une implémentation web classique, ce projet impliquait davantage de systèmes :
- Schémas d’événements app : les événements Firebase ont été mappés et validés pour chaque plateforme
- Gestion du consentement : le consentement mobile fonctionne différemment des bannières web et a nécessité une logique spécifique
- Matching cross-environment : relier les données app et web d’un même utilisateur a demandé une gestion précise des identifiants
Les résultats : des signaux récupérés et des données fiables
L’augmentation de +6,5% des pages vues, +8,0% des ajouts au panier et +3,1% des achats correspond à des événements qui existaient déjà, mais n’étaient pas mesurés auparavant. Ce point est essentiel pour bien interpréter les résultats.
Les signaux récupérés améliorent les algorithmes. Lorsque des conversions server-side sont envoyées à Google Ads ou Meta, elles enrichissent les données sur lesquelles les algorithmes s’entraînent. De meilleures données permettent d’identifier des audiences plus qualifiées, d’allouer les budgets plus efficacement et d’optimiser vers des résultats réels.
L’attribution redevient fiable. Un problème fréquent du tracking client-side sur mobile est le trafic “direct” mal attribué. Lorsque les identifiants de clic (gclid, fbclid) sont perdus dans le parcours, les conversions sont attribuées à tort au direct. Le server-side tracking conserve ces identifiants et corrige l’attribution.
L’équipe peut à nouveau faire confiance aux données. Pour Lynn, c’est le changement le plus important : "Tu dois pouvoir faire confiance aux données." Quand tu sais que ton tracking est incomplet, chaque décision marketing comporte une incertitude. Avec le server-side tracking, l’équipe de Flitsmeister peut enfin s’appuyer sur des données fiables pour prendre ses décisions.
Découvrez d’autres études de cas
Voyez comment TAGGRS aide les entreprises à se développer dans le monde entier.
