Faire un troisième audit des événements de parcours de simulation

[laem]

Pour ajouter une couche de confiance sur le fait que nos stats de funnel d'événement

"1ère réponse au bilan" -> "Progress > 50%" -> "Progress > 90%" -> "A terminé le test"

ne surestime pas le taux de succès.

[laem]

Chiffres semaine du 18 avril 2023.

Après la correction du bug de comptabilité de l'événement "1ère réponse au bilan", on est à 75% d'événements "A terminé la simulation" par rapport au nombre d'événements "1ère réponse au bilan". Soit pour 5 jours, 6 300 événements "simulation terminée" sur 8 450 "1ère réponse au bilan".

Pour le rapport entre "1ère réponse" et "Progress > 50%" on est à 84%. Pour le rapport entre "Progress > 50%" et "Progress > 90%", on est à 95%. Pour le rapport entre "Progress > 90%" et "A terminé" on est à 93%.

(Sous réserve bien sûr que ces métriques soient fiables)

[laem]

Chiffres tirés des sondages enregistrés dans la base de donnée, qui confirment l'évaluation côté Matomo

[laem]

• [ ] investiguer notamment : est-ce que notre code React/Redux marche bien ?

[bjlaa]

Résultats de mon audit :

• j'ai constaté que plusieurs trackers étaient lancés à des moments inopportuns ce qui fausse les évènement 50% de complétion, 90% de complétion et simulation terminée, il en résulte donc que les mesures faites sur ces trackers sont faussées ;
• j'ai constaté qu'après l'ajout de Plausible, les valeurs trackées par Plausible et Matomo différaient largement, sur la journée du 24 avril par exemple :

Je n'ai pas encore réussi à en déterminer la cause. Mis cela à part, le point important est que Plausible est trop limité pour le moment pour que l'on puisse en faire notre outil principal car il n'inclut pas la possibilité de créer des funnels et les recoupements de données sont quasiment inexistants. PLAUSIBLE OUT ! 🔥

[laem]

j'ai constaté que plusieurs trackers étaient lancés à des moments inopportuns ce qui fausse les évènement 50% de complétion, 90% de complétion et simulation terminée, il en résulte donc que les mesures faites sur ces trackers sont faussées ;

Ah, tu as réussi à déterminer quand et pourquoi les trackers sont lancés plusieurs fois ? C'est un problème assez urgent à corriger du coup.

[laem]

j'ai constaté qu'après l'ajout de Plausible, les valeurs trackées par Plausible et Matomo différaient largement, sur la journée du 24 avril par exemple :

Ah là clairement il y a un gros souci d'envoi d'événement côté plausible. 60 événements "NGC", c'est beaucoup trop peu par rapport aux visites.

[bjlaa]

Test Posthog

Superbe outil, correspond mieux à ce que l'on recherche : interface moderne, funnels intégré dans les fonctionnalités, possibilité de se passer de bannière de cookie (à confirmer). Malheureusement la version cloud est beaucoup trop chère (estimation à 30k par an). À priori, c'est éliminatoire. Il reste cependant une solution proposée par Chaïb, héberger une instance Posthog sur Scalingo ce qui la rendrait gratuite (si on exclut les frais Scalingo, qui restent à déterminer). Recherches en cours à ce jour sur ce dernier point.

[bjlaa]

Ah là clairement il y a un gros souci d'envoi d'événement côté plausible. 60 événements "NGC", c'est beaucoup trop peu par rapport aux visites.

Oui c'est bizarre, je soupçonne un bug côté Plausible.

[bjlaa]

Ah, tu as réussi à déterminer quand et pourquoi les trackers sont lancés plusieurs fois ? C'est un problème assez urgent à corriger du coup.

Oui mais je n'ai pas encore réfléchi au mode de correction. Je peux regarder ça aujourd'hui ! Ça me paraissait pas forcément urgent sachant qu'on a déjà des stats un peu faussées, mais c'est vrai que ça peut être intéressant de voir ce que ça donnerait sur quelques jours. 👍

[bjlaa]

https://matomo.org/faq/reports/user-id-privacy-considerations/ Okay sur Matomo, le fait de récupérer les id d'utilisateurs pour en dresser le profil, et lister leur parcours nécessite d'intégration d'une bannière de consentement. Donc à priori, sur Posthog on aurait le même problème !

[bjlaa]

Protocole de test pour reproduire les évènements envoyés en doublon

• sur la branche master, en local lancer yarn dev
• visiter localhost:8080, vider les données dans la console
• recharger la page
• cliquer sur Faire le test
• cliquer sur Passer le tutoriel
• rejoindre la première question, répondre et passer à la suivante pour arriver à cet état :
• recharger la page : dans la console ['trackEvent', 'NGC', '1ère réponse au bilan'] s'affiche à nouveau
• appuyer sur la touche Esc jusqu'à ce que l'évènement 50% se lance dans la console :
• recharger la page, 1ere réponse et 50% sont à nouveau envoyés :
• avancer avec Esc jusqu'à atteindre 90%, recharger la page, tous les évènements de progression sont re-déclenchés
• avancer avec Esc jusqu'à atteindre l'écran de fin du questionnaire :
• recharger la page, tous les évènements de progression sont envoyés à nouveau :
• retourner sur localhost:8080 via la barre d'url pour simuler le cas d'un utilisateur qui reviendrait regarder/mettre à jour son test, cliquer sur Reprendre mon test, tous les évènements de progression sont encore une fois renvoyés :

[laem]

OK je vois deux sujets séparés dans ton protocole.

1) Notre système d'envoi d'événement avec ses marqueurs "déjà envoyés" considère qu'un F5 recrée une session et donc redéclenche les événements, c'est vrai.

Mais c'est justement le boulot de Matomo et Plausible que de dédupliquer pour un visiteur unique ces événements. Sauf si j'ai pas compris quelque chose ?

Ici dans les données pour aujourd'hui, on voit qu'il y a ~10% de différence entre les événements totaux et uniques pour "A terminé la simulation".

Les stats Plausible maintenant que tu as corrigé le bug :pray: les confirment.

Autre point : il y a fort à parier que peu de gens fassent F5. On peut très bien stocker les événements dans le localstorage, via quelques lignes de code en plus, c'est très rapide. Mais je vois pas l'intérêt, ça reviendrait à recoder le système de décompte des utilisateurs de Matomo / Plausible.

2) (Dernière étape de ton protocole) Le fait qu'on ne stocke pas les marqueurs dans le localstorage fait qu'un utilisateur qui reviendrait sur NGC après quelques jours, semaines, ou mois se comporterait comme un F5 et redéclencherait en effet les événements, car il a bien effectivement complété le test, vu que ses données sont stockées dans le localstorage.

Pour ce point là, il reste donc à déterminer pendant combien de temps Matomo considère que c'est le même utilisateur, donc finalement combien de temps le cookies reste. Car si l'utilisateur supprime ses cookies, on peut considérer qu'il supprime aussi son localstorage. Tu as investigué ce point ?

Si je ne me trompe pas, ça correspond à pk_id, et la doc matomo dit qu'elles sont gardées pour 13 mois. https://fr.matomo.org/faq/general/faq_146. C'est aussi précisément ce que je constate dans mon navigateur sans ublock :

Ce qui voudrait dire que les utilisateurs qui reviennent sur NGC sont bien dédoublonnés dans la mesure des événements uniques.

Du coup, si tu es d'accord avec mes deux points, ça nous laisse bredouille sur la recherche d'une faille dans le suivi du nombre d'événements ?

[bjlaa]

Pour résumer les actions entreprises suite à ma phase de recherche :

• décision de garder Matomo en outil principal et Plausible en complément (à confirmer)
• centralisation de tous les évènements trackés dans un fichier
• envoi des évènements une seule fois, sauf cas particuliers (évènement pour suivre la session utilisateur par exemple) avec sauvegarde des évènements déjà envoyés dans le state persistant
• centralisation de la logique de tracking dans un context React MatomoContext