Vérification publicitaire : région et langue cohérentes

Une capture de vérification publicitaire répond à une question étroite : quelle création et quelle page de destination une requête portant ces propriétés déclarées a-t-elle reçues dans cette région. BotBrowser documente les valeurs géographiques dérivées du proxy ainsi que les remplacements manuels de fuseau horaire, de paramètres régionaux et de langues, que la documentation associe à une licence ENT Tier1, si bien que la région revendiquée par une capture peut être énoncée explicitement au lieu d’être héritée de la machine qui l’a exécutée. Il ne génère pas de trafic publicitaire, ne place pas d’enchères et ne contrôle pas ce que renvoie un serveur publicitaire ; chaque capture dépend encore des conditions de la plateforme qui l’autorisent.

Résumé

• Deux entrées décident de ce que représente une capture : le point de sortie de la requête et la langue déclarée par le navigateur. Une capture où elles divergent ne décrit aucune région cohérente.
• Un changement de région de sortie peut modifier la création reçue par une requête. Un changement de langue déclarée peut modifier la page de destination vers laquelle elle est envoyée.
• Un désaccord qui ne modifie ni l’une ni l’autre invalide malgré tout la comparaison, car les deux captures ne décrivent plus la même requête.
• Exécutez une vérification d’alignement avant de capturer, puis stockez la classe d’IP de sortie, le fuseau horaire et la liste de langues auprès de chaque capture acceptée.
• ads.txt déclare quels systèmes un éditeur autorise à vendre son inventaire. Il ne dit rien sur l’autorisation d’une capture.

Sommaire

• Les deux entrées qu’une capture déclare réellement
• Ce qu’un désaccord modifie, et ce qu’il ne modifie pas
• Exécuter la vérification avant la première capture
• Enregistrer l’alignement avec chaque capture acceptée
• Là où ads.txt s’applique et là où il s’arrête
• Conditions et périmètre avant l’outillage
• Conclusion pratique

Les deux entrées qu’une capture déclare réellement

Toute requête HTTP transporte plus qu’une URL. Elle porte une valeur Accept-Language qui nomme les langues naturelles préférées par le client, et elle arrive depuis une adresse réseau qu’un serveur ou un tiers peut résoudre en une localisation approximative. La RFC 9110 définit cet en-tête comme l’ensemble des langues naturelles préférées dans une réponse, et définit Vary comme le champ qui indique à un cache quels champs de la requête ont influé sur la représentation. Quand une réponse contient Vary: accept-language, le serveur indique que la sélection de langue a joué un rôle.

La référence MDN ajoute un détail déterminant pour le travail de capture : les navigateurs composent cet en-tête à partir de leur langue d’interface active, et Accept-Language comme navigator.languages peuvent volontairement omettre une partie des préférences pour limiter le fingerprinting. Une capture observe donc une liste de préférences déclarée, pas le profil linguistique complet d’une personne.

Le versant réseau est distinct. Un proxy ou une connexion directe détermine l’adresse depuis laquelle la requête semble provenir, et le guide GeoIP de BotBrowser décrit la traduction de cette IP de sortie en valeurs géographiques telles que fuseau horaire, paramètres régionaux, langues et coordonnées approximatives, les options manuelles primant sur les valeurs dérivées. La documentation énonce aussi clairement la limite de précision : la correspondance au niveau du pays est généralement solide, tandis que celle au niveau de la ville peut désigner une ville ou une région voisine.

Deux conséquences découlent de ce couple. D’abord, une capture peut être cohérente en interne ou non : la liste de langues et le fuseau horaire peuvent concorder avec la région de sortie, ou décrire un lieu d’où la requête ne provient pas. Ensuite, l’alignement est une propriété de la capture et non du binaire du navigateur ; il doit donc être enregistré plutôt que supposé.

Ce qu’un désaccord modifie, et ce qu’il ne modifie pas

La distinction utile n’est pas « cohérent contre cassé » mais « qu’est-ce que ce désaccord a réellement changé dans la réponse ». Les systèmes publicitaires varient, aussi le tableau ci-dessous liste trois classes de désaccord et une ligne témoin, avec l’observation que chacune permet. C’est une aide au classement, pas une affirmation sur le comportement d’un serveur publicitaire nommé.

Condition de capture	Création observée	Page de destination observée	Ce que la capture permet de conclure
Région de sortie changée, liste inchangée	Peut différer	Peut différer	Deux observations régionales ; aucune n’est la base de l’autre
Liste de langues changée, région inchangée	Peut différer	Peut différer	Observation de négociation de contenu dans une seule région
Liste cohérente avec le fuseau, sortie non	Aucun changement observé	Aucun changement observé	Aucune conclusion : la requête ne décrit pas un seul lieu
Témoin : les trois concordent, la source a changé	Peut différer	Peut différer	Changement côté source, pas effet de région

La première ligne est celle qui est le plus souvent mal lue. Une équipe conserve la liste de langues en-US,en et déplace la sortie d’un pays à un autre. Si la création change, la conclusion tentante est que le système publicitaire cible la géographie. L’observation ne permet d’affirmer que la différence entre les deux captures, laquelle peut tout autant venir de la programmation, d’un changement de budget de campagne, d’une règle de fréquence ou d’un état de consentement régional. Distinguer ces causes exige une troisième capture dans la région d’origine au même moment, non une affirmation plus forte sur les deux premières.

La deuxième ligne est l’inverse. En gardant la sortie fixe et en passant la liste de langues de en-US,en à de-DE,de, on peut changer la page de destination vers laquelle une requête est redirigée, car la négociation de langue est exactement ce que décrit la RFC 9110. Une différence de page de destination devient donc le résultat attendu d’un changement déclaré, et non la preuve de quoi que ce soit d’inhabituel.

La troisième ligne est celle qui consomme le plus de temps d’analyse. Rien de visible ne change, la capture semble donc correcte, et deux mois plus tard la série sert à comparer un marché avec lui-même. Une capture dont la liste de langues nomme une région alors que la requête sort d’une autre ne décrit ni l’une ni l’autre : elle n’appartient à aucune série.

La quatrième ligne couvre un véritable changement côté source. Si les trois entrées sont identiques et que la création diffère malgré tout, la différence réside dans l’état propre du système publicitaire : modifications de ciblage, planification, plafonds ou affectation d’expérience. Enregistrer correctement l’alignement est ce qui rend cette conclusion disponible, car cela écarte la capture comme explication.

Un état de consentement est le facteur de confusion qui survit le plus souvent aux trois premières lignes. Une requête provenant d’un pays où un cadre de consentement s’applique peut renvoyer une création différente ou un interstitiel avant la page de destination, et cette différence peut ressembler à un ciblage régional alors qu’il s’agit d’un verrou réglementaire. Comme ce verrou dépend généralement de la région et non de la langue, comparer les listes de langues ne le détectera pas. Conservez un champ distinct indiquant si une interaction de consentement a eu lieu et dans quel mode ; une série mêlant exécutions avec et sans verrou n’est pas une série régionale, quelles que soient ses entrées géographiques.

La fréquence et la planification créent un piège similaire entre les exécutions plutôt qu’à l’intérieur d’une seule. Une campagne peut plafonner le nombre de diffusions d’une création à un identifiant donné, si bien qu’une série capturée depuis un profil peut voir la création disparaître sans aucun changement de région ou de langue. Savoir si cela s’applique à une capture de vérification dépend de l’identifiant auquel le système rattache son plafond, ce qui est une question de plateforme et non de navigateur. La défense pratique ne change pas : enregistrez l’alignement, conservez l’heure d’observation et n’attribuez pas à la géographie une différence inexpliquée que la source pouvait produire seule.

Exécuter la vérification avant la première capture

La vérification ci-dessous s’exécute avant toute capture et échoue de manière explicite en cas de désaccord. Elle compare trois valeurs : la région attendue, la langue principale déclarée par le navigateur et le fuseau horaire rapporté. C’est la première entrée qui décide, car une liste commençant par une autre langue demande d’abord cette langue même si une étiquette correspondante apparaît plus loin. La comparaison entre étiquettes et régions est volontairement grossière, car le but est de repérer une requête décrivant deux lieux différents, non de valider une base de géolocalisation.

const EXPECTED = 'DE';
const REGION_LANGUAGES = { DE: ['de-DE', 'de'], US: ['en-US', 'en'], JP: ['ja-JP', 'ja'] };
const REGION_TIMEZONES = { DE: 'Europe/Berlin', US: 'America/New_York', JP: 'Asia/Tokyo' };

const languages = navigator.languages.slice();
const timezone = Intl.DateTimeFormat().resolvedOptions().timeZone;

// The primary language decides the region, not any match anywhere in the list:
// ["en-US", "de-DE"] still asks for English first, which is the mix this check must reject.
const languageOk = REGION_LANGUAGES[EXPECTED].includes(languages[0]);
const timezoneOk = timezone === REGION_TIMEZONES[EXPECTED];
// navigator.languages is the preference list, not the transmitted header; some browsers add
// fallback tags. Treat this as an estimate and read the real header from the captured request.
const acceptLanguageEstimate = languages
  .map((tag, i) => (i === 0 ? tag : `${tag};q=${(1 - i * 0.1).toFixed(1)}`))
  .join(',');

console.log(
  JSON.stringify({ expected: EXPECTED, languages, timezone, acceptLanguageEstimate, languageOk, timezoneOk }, null, 2)
);
if (!languageOk || !timezoneOk)
  throw new Error('capture would describe more than one region; fix inputs before capturing');

C’est la première entrée qui donne son sens à la vérification. Une liste en-US,de-DE contient aussi une étiquette allemande, mais la requête demande toujours l’anglais en premier : une vérification qui accepterait n’importe quelle correspondance laisserait donc passer exactement la requête mixte qu’elle doit arrêter. Sur un cas construit où le navigateur déclare en-US,en et rapporte America/New_York alors que l’opérateur attend DE, la sortie nomme les deux échecs :

{
  "expected": "DE",
  "languages": ["en-US", "en"],
  "timezone": "America/New_York",
  "acceptLanguageEstimate": "en-US,en;q=0.9",
  "languageOk": false,
  "timezoneOk": false
}
Error: capture would describe more than one region; fix inputs before capturing

La vérification ne prouve pas le point de sortie de la requête, car une page ne peut pas lire sa propre adresse publique de manière fiable. Gardez la vérification de sortie séparée : confirmez la classe d’IP de sortie côté opérateur, via les rapports du fournisseur de proxy ou une valeur --proxy-ip explicite comme le décrit le guide GeoIP de BotBrowser, et écrivez cette valeur dans l’enregistrement de capture. La vérification dans la page couvre les deux entrées qu’une page peut observer ; celle de l’opérateur couvre celle qu’elle ne peut pas.

Exécutez les deux avant la première capture d’une série, et de nouveau chaque fois qu’un proxy, un profil ou un réglage de langue change. Une vérification exécutée uniquement à la configuration cesse de décrire l’exécution dès que quelqu’un modifie une option.

Deux modes de défaillance subsistent avec une vérification écrite si personne ne lit sa sortie. Le premier est une attente obsolète : l’opérateur change la région cible dans la procédure mais laisse EXPECTED à la valeur précédente, si bien que la vérification passe alors que le script et la capture décrivent le mauvais lieu. Le second est un remplacement partiel : un proxy est changé tandis qu’une option --bot-timezone explicite d’une exécution antérieure reste dans les arguments de lancement, et le fuseau dérivé perd silencieusement face à l’option. Les deux se détectent en imprimant les valeurs résolues plutôt qu’un simple booléen, et c’est pourquoi l’exemple journalise la liste de langues, le fuseau horaire et l’en-tête composé avant de lever l’erreur.

Un journal de valeurs résolues donne aussi à l’enregistrement une source à citer. Quand un relecteur demande plus tard pourquoi une exécution a été marquée alignée, la réponse est le fuseau horaire et l’en-tête imprimés lors de cette exécution, non le souvenir de la configuration. Conservez cette ligne dans le journal et référencez-la depuis alignment_result afin que les deux artefacts restent liés.

Enregistrer l’alignement avec chaque capture acceptée

Un enregistrement de capture n’est comparable à un autre que s’il énonce les propriétés qui ont sélectionné la réponse. Les champs ci-dessous gardent les trois entrées d’alignement auprès de l’observation, afin qu’un relecteur puisse voir si une différence peut plausiblement relever de la région ou doit relever de la source.

Champ de l’enregistrement	Contenu	Pourquoi il est indispensable
expected_region	Code ISO 3166-1 alpha-2 visé par l’exécution	Donne un sujet fixe à chaque comparaison ultérieure
exit_ip_class	Adresse de sortie rapportée par le fournisseur	Sépare « même région » de « même fournisseur, autre ville »
accept_language_estimate	En-tête estimé depuis navigator.languages	Montre ce que la page croit envoyer ; lisez l’en-tête réel de la requête
timezone_reported	Fuseau IANA renvoyé par le navigateur	Détecte un profil qui contredit son propre proxy
creative_ref	Identifiant, empreinte ou référence de fichier	Permet de comparer sans redistribuer l’élément
landing_url	URL finale après redirections	Sépare la négociation de la redirection côté client
observed_at	Heure de capture en UTC	Ordonne les observations et révèle les changements de diffusion
alignment_result	aligned ou le désaccord nommé	Empêche une ligne non alignée d’entrer dans une série

Deux détails de ce tableau sont faciles à omettre et coûteux à reconstruire. Le premier est la différence entre l’URL demandée et l’URL finale. Une chaîne de redirections peut déplacer une requête après la négociation, et n’enregistrer que l’adresse demandée masque l’étape qui explique réellement une différence. Le second est la référence de création. Stocker une empreinte ou un identifiant côté éditeur garde l’enregistrement vérifiable tout en respectant les limites de conservation, et permet à une exécution ultérieure de distinguer « même création » de « même campagne, nouvel élément ».

C’est la même discipline de contexte que le modèle de capture de positions SERP applique aux résultats organiques : une valeur ordinale n’a pas de sens sans la signature de contexte qui l’a produite. Un emplacement publicitaire est comparable selon la même règle, même si les sorties diffèrent.

La conservation mérite sa propre décision, car les références de création peuvent peser plus qu’elles n’en ont l’air. Une empreinte d’un élément créatif suffit généralement à distinguer deux observations, mais une URL de destination peut contenir des identifiants propres à une requête de diffusion. Supprimez ou hachez les paramètres portant un identifiant de diffusion avant de stocker l’URL, et ne conservez la valeur intacte que si les conditions de la plateforme et votre politique de conservation le permettent. Le dossier de profil avec proxy rotatif applique la même approche à l’identité de session : garder une référence stable et écarter le détail par requête qui ajoute du risque sans ajouter de comparabilité.

Une série a aussi besoin d’une condition de fin déclarée. Les campagnes publicitaires changent selon des calendriers qu’une capture n’observe pas, si bien qu’une série sans terme finira par comparer deux états de la même campagne et l’appellera différence régionale. Déclarez la fenêtre d’observation au démarrage, marquez la dernière capture à la fermeture et traitez les captures suivantes comme une nouvelle série dotée de son propre enregistrement d’alignement. Cette seule discipline évite la plupart des conclusions qu’une capture longue et non étiquetée tend à produire.

Là où ads.txt s’applique et là où il s’arrête

ads.txt est souvent mal interprété dans le travail de capture, et dans les deux sens. La spécification décrit un mécanisme permettant à un éditeur de déclarer publiquement qui est autorisé à vendre son inventaire publicitaire, et le format de fichier enregistre les systèmes autorisés et les relations de revendeur au niveau du domaine. Consulter le fichier d’un éditeur répond donc à une question de chaîne d’approvisionnement : cette relation de vente est-elle déclarée.

Il ne répond pas à trois questions qu’un flux de capture tend à lui poser. Il n’indique pas si la collecte est autorisée, car la spécification porte sur la vente autorisée d’inventaire et non sur qui peut demander une page. Il n’établit pas qu’une impression observée était facturable, car le fichier décrit une autorisation déclarée et non un règlement. Et il n’indique pas comment une création est sélectionnée, car la sélection créative n’entre pas du tout dans son périmètre.

L’usage utile est plus étroit et vaut néanmoins d’être fait : lorsqu’une capture est comparée à l’emplacement déclaré par un partenaire, un enregistrement ads.txt peut montrer si la liste de vendeurs déclarée du domaine inclut le système nommé par le partenaire. Un désaccord y est une question de chaîne d’approvisionnement pour le partenaire, non une inférence sur le ciblage régional. Gardez les deux constats dans des champs séparés pour qu’un lecteur ultérieur ne les fusionne pas en un seul verdict.

La maintenance du fichier compte pour cette comparaison. Un enregistrement peut être listé avec un type de relation qui change le traitement d’un système, et la spécification attend des entrées lisibles à un chemin stable sur le domaine observé. Si un domaine renvoie un fichier différent entre deux captures, la question du vendeur a changé indépendamment de toute question régionale, et les deux captures ne décrivent plus la même chaîne d’approvisionnement. Enregistrez l’heure de récupération du fichier et une empreinte du corps auprès de la comparaison de vendeurs, afin qu’un changement de chaîne d’approvisionnement ne puisse plus tard être confondu avec un changement de diffusion publicitaire.

Résistez à la tentation de traiter un vendeur déclaré comme un signal de qualité. La spécification décrit une autorisation de vendre de l’inventaire et son périmètre est volontairement étroit : ce n’est pas une affirmation sur la qualité créative, la visibilité, la sécurité de marque ou l’exactitude d’un rapport. Une conversation avec un partenaire qui a besoin de ces réponses doit utiliser les rapports du partenaire, et une consultation ads.txt n’apporte qu’un seul fait.

Conditions et périmètre avant l’outillage

Une exécution de vérification publicitaire touche la page d’un éditeur, la réponse d’un système publicitaire et éventuellement le script d’un fournisseur de mesure : trois ensembles de conditions s’appliquent donc à une seule capture, et non un seul. Chacun décide plus que les options d’outillage. Une capture techniquement réalisable peut rester hors de ce qu’une plateforme autorise, et aucune configuration de profil ou de proxy n’y change rien.

Deux limites pratiques en découlent. D’abord, observer n’est pas participer : une requête GET qui enregistre ce qu’une page a renvoyé est un acte différent de l’émission des balises d’impression et de visibilité qu’envoie un script de mesure, et le second est hors du périmètre d’un flux de capture. Ensuite, une différence entre deux captures est une observation, non un constat de fraude ou de mauvaise diffusion ; ces conclusions appartiennent aux parties qui détiennent les journaux de diffusion et la relation contractuelle.

La limite de surveillance du commerce électronique trace la même ligne pour l’observation des prix et de la disponibilité : une page rendue et un flux partenaire répondent à des questions différentes et ne doivent pas être fusionnés en une seule série. La vérification publicitaire exige cette séparation plus nettement encore, car trois systèmes indépendants peuvent chacun modifier la réponse.

Questions fréquentes

Un désaccord de région invalide-t-il une capture même si la création semble identique ?

Oui. La capture ne décrit plus un lieu cohérent et ne peut donc pas être comparée à une capture correctement alignée de l’une ou l’autre région. Une sortie identique donne au dossier une apparence propre tout en le rendant inutilisable pour la comparaison.

La vérification d’alignement peut-elle remplacer une vérification de sortie ?

Non. Une page peut lire sa liste de langues déclarée et son fuseau horaire rapporté, mais pas son adresse publique de manière fiable. Confirmez la sortie côté opérateur et conservez cette valeur dans l’enregistrement de capture.

ads.txt indique-t-il si un emplacement publicitaire est légitime ?

Non. Il déclare quels systèmes un éditeur autorise à vendre de l’inventaire sur ce domaine. Il ne décrit ni la sélection créative, ni une diffusion facturable, ni une autorisation de collecte.

BotBrowser fait-il provenir une capture d’un pays précis ?

Il applique une sortie proxy et dérive de cette adresse des valeurs par défaut de fuseau horaire, de paramètres régionaux et de langues. La documentation indique que les remplacements manuels de ces trois valeurs exigent une licence ENT Tier1. La capture obtenue reflète encore ce que le système publicitaire décide de renvoyer, et la dérivation au niveau de la ville peut être approximative.

Sources

• IAB Tech Lab ads.txt
• Spécification ads.txt version 1.1
• MDN Accept-Language
• RFC 9110 sémantique HTTP
• Base GeoIP de BotBrowser
• Fuseau horaire, paramètres régionaux et langues dans BotBrowser

Conclusion pratique

Traitez la région de sortie, le fuseau horaire rapporté et la liste de langues déclarée comme une seule propriété de la capture. Exécutez la vérification d’alignement avant la première capture et de nouveau après tout changement de proxy, de profil ou de langue. Stockez les trois entrées avec la référence de création, l’URL finale et l’heure d’observation, et ne marquez une ligne alignée que lorsque les trois concordent avec la région que l’exécution prétend représenter. Lorsqu’une différence apparaît alors que l’alignement est intact, l’explication se trouve côté source, et c’est l’enregistrement qui rend cette conclusion disponible.