Aller au contenu principal
Analytics & GA4

Filtre Include hostname GA4 : nettoyer sans casser

FB

Fabien Bourgois

Expert Data & IA

2 novembre 20264 min de lecture
Filtre Include hostname GA4 : nettoyer sans casser

Filtre Include par hostname dans GA4 : nettoyer sans casser Activez ce filtre sans inventaire préalable, et le domaine de paiement de votre client disparaît de vos rapports, sans retour possible. C’est le vrai risque de cette nouveauté. Ce que Google documente, et ce qu’il laisse dans le flou Le 21 septembre 2026, la release … Lire la suite

Filtre Include par hostname dans GA4 : nettoyer sans casser

Activez ce filtre sans inventaire préalable, et le domaine de paiement de votre client disparaît de vos rapports, sans retour possible. C’est le vrai risque de cette nouveauté.

Ce que Google documente, et ce qu’il laisse dans le flou

Le 21 septembre 2026, la release note de Google Analytics a annoncé des filtres Include pour les hostnames, c’est-à-dire une liste de domaines autorisés à envoyer des événements à votre propriété. Le filtre Exclude existait déjà. Google l’avait ajouté le 11 juin.

La note précise deux points. Les événements envoyés par Measurement Protocol ne sont pas touchés par un filtre Include. Les événements dont le hostname est vide sont bloqués automatiquement, la note citant le trafic gtag.js.

Le reste n’est pas documenté. La note n’explique pas comment la correspondance fonctionne pour les sous-domaines ou pour une propriété qui reçoit plusieurs hostnames. Elle ne dit pas non plus comment le blocage des hostnames vides traite les flux d’application dans une propriété mixte. Aucun détail de déploiement n’est fourni, donc l’option peut ne pas être encore visible chez vous, et le comportement décrit ici peut évoluer.

Pourquoi un filtre actif ne se rattrape pas

Je dois être précis sur BigQuery, parce que c’est le point qui coûte le plus cher. Un auteur japonais indique que les données stoppées par le filtre n’apparaissent ni dans les rapports ni dans l’export BigQuery. La release note ne le dit pas en toutes lettres. Cela découle pourtant du principe du filtre, que Loves Data résume ainsi : un filtre actif affecte définitivement les données entrantes. Considérez donc qu’il n’existe aucune copie brute à retrouver dans votre dataset.

Ces filtres ne sont pas rétroactifs : ils n’agissent que sur les données collectées après leur activation. Ils ne nettoient donc pas l’historique non plus. Si vous cherchez à assainir vos anciens rapports, ce n’est pas le bon outil.

L’ordre des opérations pour tester avant d’appliquer

Je procède toujours dans cet ordre.

D’abord, l’inventaire. Ouvrez le rapport par hostname sur la plus longue période possible. Cherchez les suspects habituels : le sous-domaine de paiement, l’outil de réservation, le staging que quelqu’un a oublié, le proxy de traduction, l’AMP. Un hostname oublié dans la liste, et les données de la période sont irrécupérables.

Ensuite, la création. Le chemin est Admin, Collecte et modification des données, Filtres de données, avec un accès Éditeur minimum. Laissez le filtre en état Testing.

Puis l’attente. Google recommande d’attendre 24 à 36 heures avant de valider. En test, les données concernées sont marquées par la dimension « Test data filter name » au lieu d’être supprimées. Comparez ce volume marqué à ce que vous attendiez. Si un domaine légitime apparaît dans le lot, corrigez la liste. Je n’ai trouvé aucune documentation indiquant si les hostnames vides sont aussi marqués en test, donc vérifiez-le sur votre propriété.

Enfin, l’activation, de préférence un mardi matin plutôt qu’un vendredi soir, pour surveiller l’effet tant que l’équipe est là.

Filtre GA4 ou blocage GTM : deux métiers différents

Le filtre GA4 agit après l’envoi. Le hit est parti de la page et a atteint Google, qui le jette ensuite au traitement. Un blocage dans GTM, avec une condition sur le hostname de la page ou sur le consentement, agit avant : rien ne part. Le raisonnement est le mien et Google ne le formule pas, mais il a une conséquence nette. Pour la conformité, c’est le blocage amont qui compte. Le filtre est un outil d’hygiène, pas un mécanisme de consentement.

Le GTM a un autre avantage : il est réversible. Versions, rollback, prévisualisation. Un filtre actif n’offre rien de tout cela. En revanche, GTM ne protège pas contre les hits envoyés directement avec votre identifiant de mesure, sans passer par votre conteneur. Là, le filtre Include fait ce que GTM ne peut pas faire.

Aucun des deux ne touche Measurement Protocol. Si un spam arrive par ce canal, vous devrez le traiter ailleurs, par exemple en protégeant votre secret d’API.

Voici le flux logique, du navigateur au rapport :

Page ou serveur tiers
  -> [GTM : condition hostname / consentement]  bloque ici : rien n'est envoyé, réversible
  -> hit vers Google Analytics
  -> [Filtre Include : hostname absent de la liste ou vide]  bloque ici : irréversible
  -> rapports GA4 + export BigQuery
Measurement Protocol -> contourne le filtre Include

Où l’IA aide, et où elle ne remplace rien

L’IA est utile pour l’inventaire. Exportez la liste des hostnames avec leur volume d’événements, soumettez-la à votre assistant et demandez-lui de regrouper les domaines par propriétaire probable, puis de signaler ceux qu’il ne sait pas classer. Il ira plus vite que vous sur 200 lignes. La décision de garder ou non un domaine reste la vôtre, car le modèle ne connaît pas votre architecture.

Faites-le aujourd’hui : exportez vos hostnames sur 90 jours et demandez-vous lesquels vous ne sauriez pas justifier devant votre client. Ce sont ceux qu’il faut investiguer avant de toucher au filtre.

Catégories

Google AnalyticsSolutions