Google Analytics ajoute un contrôle utile pour un problème connu de reporting: les filtres Include de hostnames. Au lieu de poursuivre les domaines indésirables un par un, une propriété GA4 peut définir les domaines approuvés autorisés à envoyer des événements. Search Engine Journal a couvert le changement le 22 septembre, en renvoyant à la note Google du 21 septembre.
Pour les équipes marketing, le titre n’est pas seulement “anti-spam”. Le titre exact est plutôt “changement de gouvernance de la mesure”. Les filtres actifs affectent définitivement les nouvelles données entrantes, donc la fonctionnalité mérite une checklist avant activation.
Ce qui change
La note Google indique qu’Analytics prend désormais en charge les filtres Include pour les hostnames. L’objectif est de garder les domaines approuvés et de réduire la maintenance des listes d’exclusion. Google précise aussi deux points: les filtres Include ne s’appliquent pas aux événements envoyés via Measurement Protocol, et les événements sans hostname sont bloqués automatiquement, car un hostname manquant indique souvent du spam ou un trafic anormal.
Cette combinaison est puissante mais pas universelle. Elle peut aider contre des données browser-side qui ne viennent pas de vos domaines. Elle ne résout pas automatiquement tous les scénarios server-side, app, Measurement Protocol ou intégrations partenaires.
Pourquoi l’activation demande de la prudence
Les filtres GA4 s’appliquent à partir de leur création. Ils ne nettoient pas l’historique. Surtout, lorsqu’un filtre est actif, les données filtrées ne sont pas traitées et ne seront pas disponibles plus tard dans Analytics ou BigQuery. Une allowlist trop rapide peut supprimer des événements légitimes issus de pages de campagne, sous-domaines, parcours checkout ou sites régionaux.
C’est pourquoi l’état Testing compte. Il permet d’observer ce qui correspondrait au filtre avant de supprimer réellement les données. Traitez cette étape comme obligatoire.
Checklist avant activation
D’abord, inventariez les hostnames légitimes: domaine principal, sous-domaines, checkout ecommerce, centre d’aide, moteur de réservation, microsites de campagne, webviews d’application et domaines régionaux. Si des agences lancent des landing pages, demandez-les avant activation.
Ensuite, cartographiez les exceptions. Quels événements arrivent via Measurement Protocol, tagging server-side ou intégrations de plateformes? Lesquels portent un hostname, et lesquels contournent le filtre Include? Ne supposez pas que la règle navigateur couvre toute la stack de mesure.
Puis lancez le filtre en Testing. Examinez la dimension de test, comparez avec les logs de landing pages et de checkout, et vérifiez si des conversions importantes seraient retirées. Enfin, nommez un propriétaire: qui met à jour l’allowlist lorsqu’un domaine, une locale, un microsite ou un parcours de paiement apparaît?
Quand ne pas activer
N’activez pas si l’équipe ne peut pas nommer tous les domaines légitimes, si un prestataire checkout est encore en test, si des microsites sortent sans revue analytics, ou si les utilisateurs BigQuery n’ont pas été prévenus. Attendez aussi si la propriété reçoit des événements server-side critiques et que personne ne sait comment ils seront traités.
Le point opérationnel
Les filtres Include de hostnames sont une avancée utile pour nettoyer GA4. Mais ce n’est pas un simple interrupteur. Le bon modèle est: allowlist, test, vérification, activation et ownership. Des données propres ne valent que si l’équipe sait exactement ce qu’elle garde et ce qu’elle jette.
