Refonte du tracking d'authentification multi-partenaire

Deux titres de presse à modèle d'abonnement reposent sur la création de compte comme étape clé du funnel. L'authentification passe par plusieurs partenaires (Piano ID, Google SSO, Apple SSO, Google One Tap). Or l'événement de création de compte comptait 259 inscriptions quand le système d'identité natif en enregistrait 8 067 sur la même période — un ratio de 1 pour 31 — et Google One Tap remontait 0 inscription. Impossible, dans ces conditions, d'attribuer les inscriptions à leur source ni de mesurer le ROI des campagnes d'acquisition.

Comprendre pourquoi la collecte décrochait à ce point, puis concevoir un dispositif fiable et exhaustif distinguant correctement login et register quel que soit le partenaire — sans double-comptage — et le valider avant tout déploiement en production.

• Quantifier l'écart : comparaison événements de tracking vs système d'identité natif sur 30 jours pour objectiver le 1:31 et isoler le trou One Tap.
• Identifier 4 causes racines : login par token Piano ne déclenchant aucun handler, dépendance de timing au consentement, comptes créés côté serveur hors navigateur, désalignement d'identifiants client/server-side.
• Concevoir la v3 : callbacks Piano directs, file en sessionStorage survivant au rechargement, et une matrice exhaustive de 9 cas (action × partenaire).
• Spécifier le backend (enrichissement du callback One Tap) et coordonner l'équipe technique du client.
• Implémenter et valider : 12 tests E2E couvrant les flux réels, tous au vert, + plan de réplication production.