Umami ou Google Analytics : ce que vous perdez en quittant GA4

Si vous comparez Umami et Google Analytics, vérifiez deux choses : ce que GA4 fait et qu'Umami ne fait pas, et ce que devient votre historique. Si vous n'avez pas encore choisi votre outil, consultez Umami ou Plausible, en auto-hébergement et Le prix de Plausible selon votre trafic. Ce guide porte sur la migration elle-même.

En avril 2024, un développeur qui passait de Mixpanel à Umami a demandé au projet un moyen d'importer ses anciennes données. Le mainteneur d'Umami lui a répondu qu'Umami auto-hébergé n'a pas de fonction d'import, car un import dépend de la base de données et la personne qui auto-héberge Umami a déjà un accès complet à celle-ci. Le développeur a donc écrit son propre outil. Il lui a fallu environ 6 heures pour faire correspondre ses données au format d'Umami, et quelques heures de plus pour les charger.

Ce qui reste dans GA4 une fois que vous ne l'utilisez plus

Le paramètre de conservation des données de GA4 conserve les données d'événements d'une propriété standard pendant 2 ou 14 mois ; les durées plus longues sont réservées aux propriétés GA4 360 payantes. La même page d'aide précise au sujet de ce paramètre : does not affect standard aggregated reports. Il ne limite que les explorations et les rapports sur l'entonnoir. Le trafic, les pages, les sources et les conversions de vos rapports standards ne sont donc pas soumis à ce délai. Les chiffres Google Ads font exception : GA4 les affiche sur une période glissante de 36 mois.

Les explorations conservent les données d'âge, de sexe et de centres d'intérêt pendant 2 mois, quel que soit votre paramètre. Les propriétés Large et XL sont limitées à 2 mois de données au niveau des événements.

Pourquoi votre historique ne peut pas vous suivre

Umami Cloud importe bien des données, à partir de la formule Pro. L'équipe d'Umami s'en charge après que vous avez écrit au support, et les sources qu'elle mentionne sont des bases de données Umami auto-hébergées et des exports CSV. GA4 n'est pas cité : renseignez-vous auprès d'elle avant de compter dessus. Umami auto-hébergé ne propose rien de comparable. Même transférer les données d'Umami Cloud vers un serveur auto-hébergé nécessite un script que vous écrivez vous-même, d'après le mainteneur en janvier 2025.

Le point de collecte d'Umami accepte un horodatage, ce qui ressemble à une porte d'entrée. Ce champ a été ajouté pour importer d'anciens journaux d'accès. Les rapports standards de GA4 et leurs téléchargements contiennent des totaux, comme le nombre de sessions par jour. Transformer le nombre de sessions d'une journée en autant de visites factices reviendrait à inventer les visiteurs, les visites et le taux de rebond qu'Umami calcule à partir de chaque session, et le mainteneur a indiqué que les données de session sont la partie délicate d'un import par API. Nous le déconseillons : les graphiques se remplissent, mais les chiffres de visiteurs de ces mois-là ne sont pas réels.

L'export des événements de GA4 vers BigQuery fait exception. Si vous l'avez associé il y a plusieurs mois, ses tables quotidiennes contiennent vos événements bruts, et un développeur qui maîtrise SQL peut écrire un script pour les charger dans la base de données d'Umami. Cela ne remonte qu'au jour où vous avez associé BigQuery, et c'est un projet à planifier et à tester avant de vous fier aux chiffres.

Ce que vous perdez, et ce qu'Umami couvre

Les deux premières colonnes s'appuient sur la documentation de Google et d'Umami ainsi que sur le GitHub d'Umami, cités dans les sources ci-dessous et vérifiés au 15 octobre 2026. Lorsque la documentation d'Umami ne mentionne pas une fonctionnalité, la ligne indique qu'il n'en dispose pas. La ligne Search Console s'appuie sur une pull request clôturée par Umami en octobre 2026. Si vous utilisez Google Ads, accordez le plus de poids à la ligne Ads, car Umami n'offre rien pour la remplacer.

Où transférer votre historique GA4

Pour la plupart des sites, le téléchargement des rapports suffit. BigQuery vous convient si vous voulez des tables à interroger longtemps après la mise en sommeil de la propriété GA4, et si une facture BigQuery pour leur stockage et leurs requêtes ne vous gêne pas.

Passer à Umami étape par étape

Nous n'avons pas migré de vraie propriété GA4 pour ce guide, car nous n'avons utilisé aucun compte Google dans nos tests. Lorsqu'une étape s'appuie sur la documentation de Google ou d'Umami, elle renvoie vers la page concernée, vérifiée au 15 octobre 2026, pour que vous puissiez confirmer les détails avant de modifier quoi que ce soit.

Nous avons en revanche testé Umami lui-même, lors de notre propre test du 21 octobre 2026, sur une machine de test à 2 vCPU et 4 Go (arm64), et non sur un serveur DreamHost. Umami 3.4.0 a comptabilisé les 30 000 pages vues de test envoyées à son point de suivi. Le résumé du tableau de bord pour ces 30 000 lignes s'est affiché en 0,03 seconde. La base de données a augmenté d'environ 1 Ko par page vue : un site personnel qui reçoit quelques dizaines de milliers de pages vues par mois ajoute donc bien moins de 1 Go par an. Il s'agissait d'événements synthétiques envoyés en quelques minutes ; des mois de trafic réel donneront des résultats différents.

1. Listez ce que vous utilisez dans GA4 et augmentez sa durée de conservation

   Notez les rapports que vous ouvrez chaque mois, vos événements clés, les campagnes UTM que vous balisez, et si Google Ads ou Search Console est associé. Ouvrez ensuite Administration, allez dans Paramètres des données > Conservation des données, et réglez la conservation des données d'événements sur 14 mois si elle est sur 2. Google applique une durée plus longue aux données qu'il n'a pas encore supprimées : vos explorations remontent ainsi plus loin pendant votre export. La modification prend effet au bout de 24 heures, et vous devez disposer du rôle Éditeur pour l'effectuer.

2. Exportez les rapports dont vous aurez besoin

   Exportez chaque rapport GA4 dont vous dépendez au format CSV ou vers Google Sheets. Nous vous suggérons de commencer par Pages et écrans, Page de destination et Acquisition de trafic, chacun sur toute la durée de vie de la propriété, ainsi que les événements clés de votre liste. Un fichier contient au maximum 100 000 lignes. Si un rapport en compte davantage, répartissez sa période sur plusieurs fichiers. Recréez et exportez en priorité tout ce que vous avez construit dans les explorations, car c'est la partie que le paramètre de conservation réduit.

3. Copiez davantage d'historique dans BigQuery, si nécessaire

   Exécutez le connecteur GA4 de BigQuery dans un projet BigQuery dont la facturation est activée. Évitez le bac à sable BigQuery gratuit : il n'exécute pas les transferts et supprime ses tables au bout de 60 jours. Si vous souhaitez aussi récupérer les événements bruts à partir de maintenant, configurez l'export BigQuery dès à présent. Une réponse sur le forum des développeurs Google confirme qu'il n'effectue pas de remplissage rétroactif.

4. Démarrez votre serveur Umami et mettez-le à jour

   Un VPS DreamHost avec Umami est livré avec Umami 3.2.0, PostgreSQL 15 et Caddy installés, et il demande un certificat Let’s Encrypt au premier démarrage. Connectez-vous à votre serveur en SSH et affichez vos identifiants d'administration :

   bashCopier

   sudo cat /root/.umami_credentials

   Connectez-vous, changez le mot de passe et ajoutez un site web. Passez à la dernière version avant la mise en production. La version 3.2.0 installée est antérieure à Umami 3.3.0, qui a ajouté la connexion à deux facteurs, et à 3.4.0, qui a ajouté les notes sur le graphique. Exécutez d'abord umami-backup, puis umami-update, qui récupère la version la plus récente et avertit qu'une migration de base de données peut être irréversible.

5. Ajoutez le script Umami à côté de GA4

   Collez le script de suivi d'Umami dans la balise <head> de votre site, à côté de la balise GA4. Si vos balises sont gérées dans Google Tag Manager, ajoutez Umami avec une balise HTML personnalisée, car Tag Manager supprime les attributs data du script.

6. Recréez vos événements clés sous forme d'objectifs Umami

   Umami ne compte un clic comme événement que si vous lui demandez de le suivre. Ajoutez un attribut data à chaque bouton ou lien de votre liste, avec un nom d'événement de 50 caractères maximum. Créez ensuite un objectif pour chaque événement ou page qui correspond à une conversion. Les visites avec des balises UTM apparaissent dans le rapport UTM sans configuration supplémentaire.

7. Faites tourner les deux pendant un mois et comparez les tendances

   Laissez les deux balises actives pendant un mois civil complet, puis comparez vos pages principales, vos principaux sites référents et l'évolution du trafic d'une semaine à l'autre. Les totaux ne concorderont pas, et la durée d'un mois est une suggestion de notre part. Le décompte des visiteurs d'Umami utilise un sel réinitialisé au début de chaque mois : un mois civil vous donne donc un décompte complet des visiteurs à mettre en regard de celui de GA4.

8. Retirez la balise GA4 et conservez la propriété

   Notez la date de la migration et ajoutez-la sous forme de note sur le graphique, puis retirez la balise GA4 de votre site et laissez la propriété en place. Configurez ensuite une copie régulière de chaque fichier umami-backup vers un emplacement extérieur au serveur, car le script l'enregistre sur le disque du serveur lui-même.

FAQ sur le passage de GA4 à Umami