Comment migrer les analyses de Matomo vers des analyses axées sur la confidentialité
Pourquoi migrer de Matomo
Le passage à une analyse axée sur la confidentialité commence généralement non pas par l'interface, mais par la question : pourquoi changer Matomo. Il y a trois réponses. La première — les exigences en matière de confidentialité, la deuxième — le désir de simplifier la collecte de données, la troisième — réduire la dépendance aux cookies. Si vous avez un site avec un public de l'UE, un projet médical ou simplement une équipe qui ne veut pas toucher aux consentements des utilisateurs, il y a déjà une raison.
Matomo est souvent pratique en tant que système familier, mais ses rapports et paramètres s'enrichissent progressivement d'exceptions, de plugins et de modifications manuelles. À un moment donné, le propriétaire du site a besoin non pas d'un « champ supplémentaire dans le formulaire de consentement », mais d'un schéma plus simple, où l'analyse est collectée proprement et sans traces inutiles. D'où la demande : comment transférer l'analyse de matomo vers une analyse axée sur la confidentialité.
Il y a aussi un argument pratique. Lorsque la collecte de données dépend moins des cookies, il est plus facile d'expliquer la logique aux marketeurs, aux juristes et aux développeurs. Pas à tout le monde. Mais le plus souvent — oui.
Si Matomo est utilisé uniquement pour des événements de base, sans personnalisation approfondie, et que les rapports sont nécessaires pour 5 à 7 décisions régulières, la migration se déroule généralement sans pertes dramatiques. C'est plus compliqué lorsque des segments, du e-commerce et de longues chaînes d'objectifs sont liés à Matomo ; un plan est alors nécessaire, et non pas de l'enthousiasme.
Que préparer avant le transfert
Avant le transfert, rassemblez 5 groupes de données : objectifs, événements, sources de trafic, rapports Matomo, intégrations et accès au site. Sans cela, la migration devient un jeu de devinettes. Et oui, deviner coûte presque toujours plus cher.
Commencez par une liste d'objectifs. Notez quelles actions sont considérées comme des conversions : envoi de formulaire, clic sur téléphone, inscription, téléchargement de fichier, achat. Pour chaque objectif, il est utile d'indiquer non seulement le nom, mais aussi la page où il se déclenche et les conditions de déclenchement. Un exemple vaut mieux que dix phrases générales.
Ensuite, passez en revue les événements. Dans Matomo, ils ont pu être marqués de différentes manières : certains via JavaScript, d'autres via GTM, d'autres encore via des appels serveur. Un tableau ou au moins un document avec les colonnes « événement », « catégorie », « action », « étiquette », « page », « note » sera utile. Une telle liste permet d'économiser des heures lors de l'analyse des anciennes configurations.
Bloc séparé — sources de trafic. Conservez quelles UTM-étiquettes sont réellement utilisées, quels canaux sont liés aux comptes publicitaires, quelles campagnes proviennent de liens courts ou de redirections. Sans cela, le nouveau système peut collecter des visites, mais vous ne comprendrez pas d'où vient l'utilisateur. Et cela devient un problème non pas d'analyse, mais de décisions.
N'oubliez pas les intégrations. CRM, suivi des appels, formulaires, chat, envoi d'événements serveur, tableau de bord BI — tout cela doit être énuméré avant le lancement. S'il manque des accès au site, GTM, CMS ou CDN, il vaut mieux les demander à l'avance. Sinon, le transfert s'arrêtera à la deuxième étape.
Correspondance des métriques Matomo et du nouveau système
Commencez la comparaison des métriques par des éléments simples : pages, événements, conversions, UTM-étiquettes et segments d'utilisateurs. Ne tentez pas de tout comparer immédiatement. D'abord les choses de base, puis les nuances. Cela réduit les chances de se perdre dans les différences de méthodologies.
Les pages dans Matomo et dans le nouveau système coïncident généralement par URL, mais pas toujours par les règles de normalisation. Vérifiez comment les barres obliques, les paramètres, les ancres et les redirections sont pris en compte. Un même chemin peut apparaître comme trois chaînes différentes si les règles diffèrent. Pour un magasin en ligne, cela est particulièrement visible sur les fiches produits et les filtres.
Il est préférable de vérifier les événements par paires. Par exemple, si Matomo enregistre un clic sur le bouton « Laisser une demande », dans le nouveau système, il faut créer le même déclencheur et comparer non seulement le nombre de déclenchements, mais aussi les conditions. Parfois, dans Matomo, l'événement était capturé au niveau du bloc parent, tandis que le nouveau système attend un sélecteur exact. La surprise est simple, les conséquences désagréables.
Les conversions et les objectifs nécessitent une liste distincte. Pour chaque ancien objectif, notez : le nom, la source de l'événement, la page, la condition, la valeur. Ensuite, comparez avec le nouveau modèle. Si dans Matomo, l'objectif était comptabilisé par la vue de la page « Merci », tandis que le nouveau système compte le formulaire par soumission, les chiffres divergeront déjà dès le départ. C'est normal, mais seulement si vous l'avez noté à l'avance.
Vérifiez les balises UTM à 2 niveaux : comment elles arrivent dans le système et comment elles apparaissent ensuite dans les rapports. Parfois, la différence apparaît à cause de la casse des lettres, parfois à cause de l'auto-complétion des campagnes, parfois à cause des redirections avec suppression des paramètres. Il vaut également la peine de décrire les segments internes : nouveaux utilisateurs, utilisateurs revenants, trafic par email, utilisateurs d'un pays spécifique. Un segment sans description est presque toujours une future erreur.
Configuration d'une analyse axée sur la confidentialité
La configuration de base commence par l'installation du compteur. Ensuite, activez le mode sans cookies, si votre plateforme le prend en charge. Après cela, activez la collecte sans consentement là où cela est autorisé par la politique de l'entreprise et le cadre juridique du projet. Ce n'est pas de la magie, mais une séquence de 3 à 4 étapes.
La filtration des visites internes est nécessaire dès le départ. Si une équipe de 12 personnes ouvre le site 20 fois par jour, l'analyse perd rapidement son sens. Excluez l'IP du bureau, les appareils de test, les domaines de staging et, si nécessaire, les comptes individuels des employés. Sinon, vous verrez une « augmentation » provenant de personnes qui vérifiaient simplement un bouton.
Ensuite, configurez les événements de base : vue de page, soumission de formulaire, clic sur le téléphone, clic sur l'email, téléchargement de fichier. Ne tentez pas de transférer tout depuis Matomo en une seule soirée. D'abord le noyau, puis les événements rares. À ce stade, il est particulièrement utile de se référer à la documentation et à l'environnement de test.
Si l'analyse axée sur la confidentialité choisie prend en charge les événements côté serveur, utilisez-les là où les événements côté navigateur échouent en raison de bloqueurs ou de scénarios complexes. C'est important pour les paiements, les espaces de travail fermés et les longs formulaires. Mais ne traînez pas tout avec le serveur, sinon vous perdrez la transparence dans le débogage.
Parfois, un domaine de test séparé ou un rapport de staging aide. Vous pouvez y cliquer en toute sécurité sur 7 à 10 boutons clés, vérifier les filtres et vous assurer que l'analyse privée ne collecte pas de déchets. Oui, c'est ennuyeux. Mais ensuite, il y a moins de corrections nocturnes.
Transfert des événements, des objectifs et des entonnoirs
Déplacez les événements par priorité : d'abord les 5 à 10 actions les plus précieuses, puis le reste. Si vous avez un e-commerce, commencez par ajouter au panier, commencer le paiement, acheter, puis connectez les vues de filtres et les clics sur les blocs recommandés. La logique est simple : ce qui influence l'argent, c'est ce qui est déplacé en premier.
Les objectifs dans Matomo étaient souvent construits autour des pages de remerciement ou d'URL spécifiques. Dans le nouveau système, cette approche est également possible, mais il est préférable de la revoir avec la mise en œuvre technique. Parfois, le formulaire est envoyé via AJAX et l'utilisateur ne se rend pas sur une page distincte — alors il faut enregistrer l'événement, et non la page. C'est plus précis et plus serein.
Vérifiez les entonnoirs étape par étape. Pour l'inscription, cela peut être 4 écrans : accès à la page d'atterrissage, clic sur le bouton, remplissage du formulaire, confirmation par email. Pour la commande — panier, livraison, paiement, confirmation. Chaque étape doit avoir son propre déclencheur et son propre test. Une étape manquée casse tout le tableau.
Si Matomo avait des objectifs composés ou des entonnoirs segmentés, ne tentez pas de les copier littéralement. Il vaut mieux décomposer la logique en événements distincts et reconstruire l'entonnoir dans une analyse axée sur la confidentialité. Parfois, cette reconstruction est même plus utile que l'ancien schéma : des étapes superflues et des clics morts apparaissent.
Pour les scénarios e-commerce, vérifiez les montants, la devise, l'ID de commande et d'annulation. En pratique, on confond souvent la transmission du prix et de la remise, et ensuite le rapport a l'air beau, mais ne correspond pas à la CRM. À ce moment-là, un document interne sur les règles de calcul sera utile.
Vérification de la qualité des données après migration
Les 3 à 7 premiers jours après le lancement ne sont pas pour « observer », mais pour comparer. Ouvrez les anciens et les nouveaux rapports côte à côte et comparez les pages, les événements, les conversions, les sources. Les divergences sont presque inévitables. La question est seulement de savoir si vous pouvez les expliquer.
Commencez la vérification par des tests manuels. Allez sur le site, ouvrez 2 à 3 pages, cliquez sur quelques boutons, envoyez un formulaire, suivez un lien UTM. Ensuite, vérifiez si des événements sont apparus dans le nouveau système et si le parcours utilisateur n'est pas cassé. Ce test peut sembler primitif, mais c'est lui qui attrape 80 % des erreurs.
Vérifiez séparément le trafic référent. Il disparaît souvent en raison de redirections, d'une liste d'exclusions incorrecte ou d'un paramètre de mode sans cookie. Il y a aussi des erreurs avec les clics publicitaires : les UTM sont lus, mais le canal passe en « direct » à cause d'une page intermédiaire. Si cela se produit, ne vous précipitez pas pour blâmer la plateforme ; regardez d'abord la chaîne de transitions.
Vérifiez les segments après les rapports de base. Si vous aviez 2 segments par pays et 3 par sources dans Matomo, vérifiez si la logique et le volume correspondent. De petites divergences sont acceptables, mais un effondrement soudain dans un segment indique généralement une erreur de filtre ou de règle.
Une bonne pratique consiste à tenir un journal des divergences. On y consigne la date, la page, l'événement, l'ancienne valeur, la nouvelle valeur et une explication. Cela aide lorsque, une semaine plus tard, quelqu'un demande pourquoi les achats ont diminué de 12. Il n'est plus nécessaire de chercher la réponse à nouveau.
Que faire de l'ancien Matomo après la transition
Après la transition, il n'est pas nécessaire de supprimer Matomo immédiatement. On laisse souvent 3 options : archive, gel de la collecte ou désactivation complète. Le choix dépend des exigences légales, des délais de conservation et de la fréquence à laquelle l'équipe revient aux anciens rapports.
Si une archive est nécessaire, laissez l'accès en lecture seule et notez la date d'arrêt de la collecte. C'est pratique pour les comparaisons historiques et les vérifications internes. Si les rapports ne sont plus utilisés dans le travail, on peut transférer les principales conclusions dans la documentation : liste des objectifs, sources, règles de segments, exceptions importantes. Le document est court, mais il est utile en cas de litige dans 6 mois.
La désactivation complète de l'ancienne installation ne convient pas à tout le monde. Parfois, Matomo reste en tant que réserve pendant 30 à 60 jours pour capturer les événements manqués ou les divergences contestées. Ensuite, il peut être retiré lorsque la nouvelle analyse collecte de manière stable toutes les actions nécessaires.
Liste de contrôle pour le lancement et suivi après la migration
Avant le lancement final, vérifiez 8 éléments : le compteur est installé, le mode sans cookies est activé, les visites internes sont exclues, les objectifs sont reconstruits, les UTM sont lisibles, les formulaires sont capturés, l'ecommerce est transmis, les rapports s'ouvrent. Si au moins un point est vide, il vaut mieux ne pas précipiter le lancement.
Dans les premiers jours après la migration, désignez une personne responsable de l'analyse. Pas une équipe, mais une seule personne. Elle examine les journaux, compare les rapports, collecte les erreurs et répond à la question de savoir pourquoi la page « Contacts » a soudainement 0 événements. Ce mode est particulièrement utile lorsque le projet a à la fois un lancement et une campagne publicitaire en cours.
Ensuite, mettez en place un audit régulier - toutes les 2 semaines ou une fois par mois, selon le trafic. Vérifiez les nouveaux formulaires, les nouveaux boutons, les nouvelles pages d'atterrissage, les nouveaux UTM publicitaires et les modifications dans la bannière de consentement. Toute modification sur le site peut affecter l'analyse, même si le développeur jure que « nous avons juste changé le texte ».
Et encore un petit point, mais fréquent : conservez une liste de tous les changements au même endroit. Lorsque dans 3 mois vous devrez expliquer pourquoi le flux d'événements de l'analyse axée sur la confidentialité a changé, vous serez heureux de ne pas avoir à rechercher l'historique dans des discussions, des tickets et la mémoire d'un marketeur fatigué.
