Le 21 septembre 2026, Google a ajouté un bouton qui peut détruire vos données sans que rien n’apparaisse jamais dans un rapport. Il s’appelle le mode Include du filtre hostname GA4, et Google le présente comme la fin du spam fantôme « avec un minimum d’entretien ». La réalité est plus retorse : ce filtre ne bloque pas le principal vecteur de spam, et le moindre domaine légitime oublié dans votre liste voit ses hits effacés à la collecte, invisibles dans les rapports comme dans l’export BigQuery, sans rattrapage possible. Avant de toucher à ce réglage (que vous cherchiez « filtre hostname GA4 » ou « filtre nom d’hôte GA4 », c’est le même écran), voici ce qu’il fait vraiment, ce qu’il ne fait pas, et le protocole pour l’activer sans vous tirer une balle dans le pied à neuf semaines du Black Friday.
Filtre hostname GA4 : ce qui a changé le 21 septembre 2026
Depuis le 11 juin 2026, GA4 permettait de filtrer le trafic par nom d’hôte en mode Exclude : vous listiez les domaines à bloquer, un par un, et tout le reste passait. C’est une logique de liste noire, réactive, que vous alimentez au fil des intrus repérés.
Le mode Include inverse la logique. Vous déclarez une fois pour toutes la liste des domaines autorisés, votre allowlist, et GA4 refuse tout ce qui n’y figure pas. Sur le papier, c’est plus propre : vous n’avez plus à courir après chaque nouveau spammeur. Dans les faits, vous venez de transformer un filet à mailles larges en mur aveugle. Tout ce que vous avez oublié de lister est perdu, et perdu pour de bon.
Les deux exceptions écrites dans la note de version
Google documente deux comportements du filtre qui méritent qu’on s’y arrête, parce que ce sont eux qui décident si l’outil tient sa promesse.
« Les événements Measurement Protocol ne sont pas filtrés »
C’est écrit noir sur blanc dans la note de version : le filtre hostname ne s’applique pas aux événements envoyés via le Measurement Protocol. Or c’est précisément par là que passe une grande partie du spam fantôme, ce trafic injecté directement dans votre propriété par quelqu’un qui a récupéré votre measurement ID. Autrement dit, si votre spam arrive par le Measurement Protocol, votre allowlist ne le verra jamais. Vous croyez fermer la porte, elle n’a pas de mur autour.
Soyons honnêtes sur ce point, parce que les sources divergent. Certains praticiens décrivent le spam fantôme comme une injection Measurement Protocol pure ; d’autres l’attribuent à une simple réutilisation de votre measurement ID dans un gtag.js copié sur un autre domaine. Google ne tranche pas, et les deux routes n’ont pas le même remède. Le filtre hostname attrape la seconde (un vrai hit web depuis un domaine étranger porte bien un hostname) mais pas la première. La seule façon de savoir laquelle vous frappe, c’est de regarder dans votre propre propriété. Pour comprendre ce qu’est le Measurement Protocol et pourquoi son exemption compte, notre guide sur le Measurement Protocol GA4 et la boucle CRM pose les bases.
« Les hostnames vides sont bloqués automatiquement »
Deuxième mention de Google : les hostnames vides sont bloqués d’office, « such as gtag.js traffic ». Cette parenthèse est ambiguë, et l’ambiguïté coûte cher quand la suppression est définitive. Lecture littérale : seuls les hits sans aucun hostname sont concernés. Lecture restrictive : une partie de votre trafic gtag.js légitime pourrait tomber dans ce panier si le hostname n’est pas résolu au moment de la collecte. Tant que Google ne précise pas, traitez cette phrase comme une inconnue à vérifier, pas comme une garantie. Un hostname (not set) dans vos rapports est justement le symptôme à surveiller ici.
Le vrai risque : Include supprime, Exclude laisse passer
Voici la nuance que Google ne met pas en avant et qui devrait guider votre décision. Une erreur dans un filtre Exclude et une erreur dans un filtre Include n’ont pas du tout le même coût.
Si vous vous trompez dans un Exclude (vous oubliez de bloquer un domaine spam), le pire qui arrive, c’est que du bruit entre dans vos rapports. C’est agaçant, mais c’est récupérable : la donnée est là, vous pouvez la segmenter, l’exclure a posteriori en exploration, la filtrer dans BigQuery. Rien n’est perdu.
Si vous vous trompez dans un Include (vous oubliez d’autoriser un domaine légitime), la donnée de ce domaine est détruite à la collecte. Elle n’entre jamais. Elle n’est nulle part : ni dans les rapports, ni dans la Data API, ni dans l’export BigQuery. Vous ne pouvez pas la récupérer, parce qu’elle n’a jamais existé côté Google. Et comme le filtre n’est pas rétroactif, activer l’allowlist ne touche pas le passé, mais chaque jour où elle tourne incomplète creuse un trou permanent.
| Critère | Filtre Exclude | Filtre Include (allowlist) |
|---|---|---|
| Logique | Liste noire : bloque ce que vous nommez | Liste blanche : bloque tout le reste |
| Coût d’une erreur | Du spam passe, segmentable après coup | De la donnée légitime détruite, irrécupérable |
| Réversibilité de l’erreur | Oui, la donnée reste collectée | Non, rien n’est collecté |
| Entretien | Continu, à chaque nouvel intrus | Ponctuel, mais inventaire exhaustif requis |
| Bon cas d’usage | Quelques domaines parasites connus | Périmètre de domaines stable et parfaitement connu |
Un filtre hostname GA4 en mode Include n’est donc pas un « Exclude en mieux ». C’est un outil plus tranchant, réservé aux propriétés dont vous connaissez le périmètre de domaines au hostname près.
Protocole d’activation en 5 étapes
Si vous décidez de passer en Include, ne le faites pas à l’aveugle. Voici la méthode pour construire une allowlist complète et la valider avant qu’elle ne coupe quoi que ce soit.
Étape 1 : inventoriez tous vos hostnames légitimes sur 12 mois
C’est l’étape qui fait tout. Vous ne pouvez pas autoriser ce que vous n’avez pas listé, donc listez tout. Si vous avez l’export BigQuery, cette requête agrège chaque hostname vu sur un an, avec son volume et ses dates d’apparition :
SELECT
device.web_info.hostname AS hostname,
COUNT(*) AS events,
MIN(PARSE_DATE('%Y%m%d', event_date)) AS first_seen,
MAX(PARSE_DATE('%Y%m%d', event_date)) AS last_seen
FROM `votre_projet.analytics_XXXXXX.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20250922' AND '20260922'
GROUP BY hostname
ORDER BY events DESC
Sans export, reconstituez le même inventaire en exploration libre avec la dimension Hostname en lignes et le nombre d’événements en valeur, sur la plage la plus longue disponible. Cette requête d’inventaire est une onzième requête naturelle à ajouter à votre boîte à outils : voyez nos requêtes BigQuery indispensables pour GA4 et, si l’export n’est pas encore branché, notre guide de l’export GA4 vers BigQuery.
Puis traquez les oubliés classiques : les sous-domaines (blog, checkout, help, app), les domaines de landing de vos campagnes, les versions traduites ou mises en cache servies par Google, vos environnements de préprod qui portent le même conteneur, et vos flux application si la propriété est mixte. Un hostname à faible volume sur douze mois n’est pas forcément du bruit : ce peut être une landing de campagne qui ne tourne que six semaines par an.
Étape 2 : passez le filtre en Testing, 7 à 14 jours
GA4 propose un état Testing qui applique le filtre sans supprimer la donnée : il tague simplement ce qui aurait été filtré. Utilisez-le, ce n’est pas optionnel. Et laissez-le tourner plus longtemps que les 24 à 48 heures souvent conseillées : visez 7 à 14 jours. La raison est simple, il faut couvrir au moins un cycle hebdomadaire complet et idéalement une mise en ligne de campagne, sinon les domaines épisodiques n’apparaissent pas dans la fenêtre de test et vous les découvrirez le jour où vous les aurez supprimés.
Étape 3 : lisez la dimension « Test data filter name »
Pendant le test, GA4 remplit la dimension Test data filter name sur les événements qui auraient été filtrés. Ouvrez une exploration, croisez cette dimension avec le Hostname, et regardez ce qui serait tombé. Chaque hostname listé ici est une décision à prendre : légitime oublié à ajouter à l’allowlist, ou vrai indésirable à laisser filtrer. Ne basculez pas tant que cette liste contient un seul domaine dont vous n’êtes pas certain.
Étape 4 : vérifiez les inconnues dans votre propre propriété
Google ne documente pas tout, et sur un réglage irréversible, l’inconnu est un risque. Trois questions restent ouvertes, testez-les chez vous plutôt que de croire une réponse inventée. Le matching se fait-il sur le hostname exact, ou les sous-domaines sont-ils inclus automatiquement ? Comment sont traités les événements de la Data Manager API, par laquelle transitent désormais les achats Shopify server-to-server depuis juillet 2026 ? Et les flux application dans une propriété web plus app ? La méthode : isolez chaque cas en Testing et lisez le Test data filter name avant de conclure. Sur le traitement server-to-server, notre comparatif Measurement Protocol ou Data Manager API et notre guide Shopify GA4 server-side natif donnent le contexte.
Étape 5 : intégrez les contraintes d’exploitation
Trois limites à connaître avant de compter sur ce filtre. Vous êtes plafonné à 10 filtres de données par propriété, et ce quota est partagé avec vos filtres de trafic interne et développeur. Il faut le rôle Éditeur pour créer ou activer un filtre. Et le filtre n’est pas rétroactif : il ne nettoie pas l’historique, il ne fait qu’agir sur la collecte à venir. Le filtre hostname est justement le nouveau point à ajouter à toute checklist d’audit : voyez nos 11 erreurs de configuration GA4 à corriger.
Les cas où il ne faut PAS passer en Include
Mon avis de praticien : pour beaucoup de propriétés, le mode Exclude reste le bon choix, et Include est un piège. Restez en Exclude si vous êtes dans l’un de ces cas.
Vous avez un setup cross-domain ou plusieurs sous-domaines actifs, où l’inventaire bouge. Votre propriété est alimentée par plusieurs sites que vous ne maîtrisez pas tous. Vous êtes une agence qui gère des propriétés dont vous ne connaissez pas le calendrier de lancement des domaines de vos clients. Votre propriété est mixte web plus app, terrain où le comportement du filtre n’est pas documenté. Et surtout, la règle qui prime sur toutes les autres : ne passez jamais en Include une propriété à moins de huit semaines d’un pic commercial. Le risque de destruction dépasse de loin le bénéfice d’un reporting un peu plus propre. Un filtre Include mal réglé devient d’ailleurs une cause de données manquantes qu’aucun diagnostic ne remonte, puisque la donnée n’existe pas : c’est exactement le scénario décrit dans notre article GA4 données manquantes : bug Google ou votre tracking ?.
Ce que ça change pour la saison Black Friday
Nous sommes à environ neuf semaines du pic. En octobre et novembre, vos équipes multiplient les landing pages, les domaines de campagne, les opérations éphémères. C’est exactement la période où une allowlist figée fin septembre devient obsolète, et où chaque domaine oublié détruit de la donnée sur la fenêtre commerciale la plus chère de l’année. Le calcul est simple : le gain d’un reporting propre ne vaut pas le risque de perdre définitivement les conversions du 28 novembre. Si vous préparez le pic, gardez ce chantier pour après, et concentrez-vous sur l’essentiel avec notre checklist tracking Black Friday 2026.
Conclusion : qui porte le risque
Le 20 septembre, Google publiait une page rappelant que ses filtres de trafic invalide ne suffisent pas contre les faux leads, et que la validation revient à l’annonceur. Le filtre hostname Include suit exactement le même schéma : Google fournit le contrôle, vous portez le coût de l’erreur. La différence, c’est qu’ici l’erreur est irréversible. Une allowlist incomplète ne se corrige pas, elle laisse un trou permanent dans votre historique.
Alors avant d’appuyer sur Active, posez-vous une seule question : connaissez-vous vraiment, au hostname près, tous les domaines légitimes qui alimentent votre propriété ? Si la réponse n’est pas un oui net, restez en Exclude, faites votre inventaire, testez deux semaines, et gardez le mode Include pour le jour où votre périmètre sera stable et documenté. Un reporting un peu bruité se nettoie toujours. Une donnée jamais collectée, non.