Verificación publicitaria: región e idioma

Una captura de verificación publicitaria responde una pregunta estrecha: qué creatividad y qué página de destino recibió en esta región una solicitud con estas propiedades declaradas. BotBrowser documenta valores geográficos derivados del proxy y anulaciones manuales de zona horaria, configuración regional e idiomas, que la documentación vincula a una licencia ENT Tier1, de modo que la región que una captura afirma puede declararse de forma explícita en lugar de heredarse de la máquina que la ejecutó. No genera tráfico publicitario, no puja y no controla lo que devuelve un servidor de anuncios; cada captura sigue dependiendo de que los términos de la plataforma la permitan.

Resumen

• Dos entradas deciden qué representa una captura: por dónde sale la solicitud y qué idioma declara el navegador. Una captura en la que no coinciden no describe ninguna región coherente.
• Un cambio de región de salida puede alterar la creatividad que recibe una solicitud. Un cambio del idioma declarado puede alterar la página de destino a la que se envía.
• Un desajuste que no altera ninguna de las dos sigue invalidando la comparación, porque las dos capturas ya no describen la misma solicitud.
• Ejecute una comprobación de alineación antes de capturar y guarde la clase de IP de salida, la zona horaria y la lista de idiomas junto a cada captura aceptada.
• ads.txt declara qué sistemas autoriza un editor para vender inventario. No dice nada sobre si una captura está permitida.

Contenido

• Las dos entradas que una captura declara
• Qué cambia un desacuerdo y qué no
• Ejecute la comprobación antes de la primera captura
• Registre la alineación en cada captura aceptada
• Dónde aplica ads.txt y dónde se detiene
• Términos y alcance antes de las herramientas
• Conclusión práctica

Las dos entradas que una captura declara

Toda solicitud HTTP lleva más que una URL. Lleva un valor Accept-Language que nombra los idiomas naturales que prefiere el cliente y llega desde una dirección de red que un servidor o un tercero puede resolver a una ubicación aproximada. RFC 9110 define la cabecera como el conjunto de idiomas naturales preferidos en una respuesta y define Vary como el campo que indica a una caché qué campos de la solicitud influyeron en la representación. Cuando una respuesta incluye Vary: accept-language, el servidor está declarando que la selección de idioma participó.

La referencia de MDN añade un detalle relevante para el trabajo de captura: los navegadores componen la cabecera a partir de su idioma de interfaz activo, y tanto Accept-Language como navigator.languages pueden omitir a propósito parte de la lista de preferencias por motivos de fingerprinting. Una captura observa, por tanto, una lista de preferencias declarada y no el perfil lingüístico completo de una persona.

El lado de red es independiente. Un proxy o una conexión directa determina desde qué dirección parece llegar la solicitud, y la guía GeoIP de BotBrowser describe la traducción de esa IP de salida en valores geográficos como zona horaria, configuración regional, idiomas y coordenadas aproximadas, con prioridad de las marcas manuales sobre los valores derivados. La documentación también enuncia el límite de precisión con claridad: la asignación por país suele ser sólida mientras que la de ciudad puede resolverse a una ciudad o región cercana.

De ese par se siguen dos consecuencias. La primera es que una captura puede ser internamente coherente o no: la lista de idiomas y la zona horaria pueden coincidir con la región de salida, o pueden describir un lugar del que la solicitud no procede. La segunda es que la alineación es una propiedad de la captura, no del binario del navegador, así que debe registrarse en lugar de suponerse.

Qué cambia un desacuerdo y qué no

La división útil no es «coherente frente a roto» sino «qué cambió realmente este desacuerdo en la respuesta». Los sistemas publicitarios varían, así que la tabla siguiente recoge tres clases de desacuerdo y una fila de control, con la observación que sostiene cada una. Es una ayuda de clasificación, no una afirmación sobre el comportamiento de ningún servidor de anuncios concreto.

Condición de la captura	Creatividad observada	Página de destino observada	Qué sostiene la captura
Cambia la región de salida, la lista no	Puede diferir	Puede diferir	Dos observaciones regionales; ninguna es la base de la otra
Cambia la lista de idiomas, la región no	Puede diferir	Puede diferir	Observación de negociación de contenido en una sola región
La lista concuerda con la zona, la salida no	Sin cambios observados	Sin cambios observados	Sin conclusión: la solicitud no describe un solo lugar
Control: las tres coinciden, la fuente cambió	Puede diferir	Puede diferir	Cambio del lado de la fuente, no efecto de región

La primera fila es el caso que más se malinterpreta. Un equipo mantiene la lista de idiomas del navegador en en-US,en y mueve la salida de un país a otro. Si la creatividad cambia, la conclusión tentadora es que el sistema publicitario segmenta por geografía. La observación solo sostiene que las dos capturas difieren, y la diferencia podría provenir igualmente de la programación, de un cambio de presupuesto de campaña, de una regla de frecuencia o de un estado de consentimiento regional. Separar esas causas requiere una tercera captura en la región original al mismo tiempo, no una afirmación más fuerte sobre las dos primeras.

La segunda fila es la inversa. Mantener la salida fija y cambiar la lista de idiomas de en-US,en a de-DE,de puede cambiar la página de destino a la que se redirige una solicitud, porque la negociación de idioma es exactamente lo que describe RFC 9110. Eso convierte una diferencia de página de destino en un resultado esperado de un cambio declarado, no en evidencia de nada inusual.

La tercera fila es la que más tiempo de análisis desperdicia. Nada visible cambia, así que la captura parece correcta, y dos meses después la serie se usa para comparar un mercado consigo mismo. Una captura cuya lista de idiomas nombra una región mientras la solicitud sale de otra no describe ninguna de las dos, así que no pertenece a ninguna serie.

La cuarta fila cubre un cambio genuino del lado de la fuente. Si las tres entradas son idénticas y la creatividad aun así difiere, la diferencia vive en el estado del propio sistema publicitario: ediciones de segmentación, planificación, límites o asignación de experimentos. Registrar la alineación correctamente es lo que hace disponible esa conclusión, porque descarta la captura como explicación.

Un estado de consentimiento es el factor de confusión que más a menudo sobrevive a las tres primeras filas. Una solicitud procedente de un país con un marco de consentimiento vigente puede devolver una creatividad distinta o un intersticial antes de la página de destino, y esa diferencia puede parecer segmentación regional cuando en realidad es una barrera regulatoria. Como la barrera suele depender de la región y no del idioma, comparar listas de idiomas no la detectará. Mantenga un campo separado para indicar si hubo una interacción de consentimiento y en qué modo; una serie que mezcla ejecuciones con y sin barrera no es una serie regional, digan lo que digan sus entradas geográficas.

La frecuencia y la planificación crean una trampa parecida entre ejecuciones y no dentro de una. Una campaña puede limitar cuántas veces se sirve una creatividad a un identificador dado, de modo que una serie capturada desde un perfil puede ver desaparecer la creatividad sin ningún cambio de región o idioma. Que eso aplique a una captura de verificación depende de a qué identificador vincula el sistema su límite, que es una pregunta de plataforma y no de navegador. La defensa práctica no cambia: registre la alineación, conserve la hora de observación y no atribuya a la geografía una diferencia sin explicar cuando la fuente pudo producirla por sí sola.

Ejecute la comprobación antes de la primera captura

La comprobación siguiente se ejecuta antes de cualquier captura y falla de forma visible ante un desajuste. Compara tres valores: la región esperada, el idioma principal que declara el navegador y la zona horaria que reporta. Decide la primera entrada, porque una lista que empieza por otro idioma pide ese idioma primero aunque más adelante aparezca una etiqueta coincidente. La comparación entre etiquetas y regiones es deliberadamente gruesa, porque el objetivo es detectar una solicitud que describe dos lugares distintos, no validar una base de datos de geolocalización.

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');

La primera entrada es lo que da sentido a la comprobación. Una lista en-US,de-DE también contiene una etiqueta alemana, pero la solicitud sigue pidiendo inglés primero, así que una comprobación que aceptara cualquier coincidencia en la lista aprobaría justo la solicitud mixta que debe detener. Sobre un caso construido en el que el navegador declara en-US,en y reporta America/New_York mientras el operador espera DE, la salida nombra ambos fallos:

{
  "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 comprobación no demuestra por dónde sale la solicitud, porque una página no puede leer su propia dirección pública de forma fiable. Mantenga separada la comprobación de salida: confirme la clase de IP de salida del lado del operador, mediante los informes del proveedor de proxy o un valor --proxy-ip explícito como describe la guía GeoIP de BotBrowser, y escriba ese valor en el registro de captura. La comprobación en la página cubre las dos entradas que una página puede observar; la del operador cubre la que no puede.

Ejecute ambas antes de la primera captura de una serie y de nuevo siempre que cambie un proxy, un perfil o un ajuste de idioma. Una comprobación que solo se ejecuta al configurar deja de describir la ejecución en cuanto alguien edita una marca.

Dos modos de fallo sobreviven a una comprobación escrita si nadie lee su salida. El primero es una expectativa obsoleta: el operador cambia la región objetivo en el manual pero deja EXPECTED en el valor anterior, así que la comprobación pasa mientras el script y la captura describen el lugar equivocado. El segundo es una anulación parcial: se cambia el proxy mientras una marca --bot-timezone explícita de una ejecución anterior permanece en los argumentos de inicio, y la zona derivada pierde silenciosamente frente a la marca. Ambos se detectan imprimiendo los valores resueltos en lugar de solo un booleano, y por eso el ejemplo registra la lista de idiomas, la zona horaria y la cabecera compuesta antes de lanzar el error.

Un registro de valores resueltos también da al registro algo que citar. Cuando un revisor posterior pregunta por qué una ejecución se marcó como alineada, la respuesta es la zona horaria y la cabecera impresas en esa ejecución, no el recuerdo de la configuración. Conserve esa línea en el registro de ejecución y referénciela desde alignment_result para que ambos artefactos queden unidos.

Registre la alineación en cada captura aceptada

Un registro de captura solo es comparable con otro si declara las propiedades que seleccionaron la respuesta. Los campos siguientes mantienen las tres entradas de alineación junto a la observación, de modo que un revisor pueda ver si una diferencia podría pertenecer a la región o debe pertenecer a la fuente.

Campo del registro	Qué contiene	Por qué no puede omitirse
expected_region	Código ISO 3166-1 alfa-2 que la ejecución apunta	Da a cada comparación posterior un sujeto fijo
exit_ip_class	Dirección de salida reportada por el proveedor	Separa «misma región» de «mismo proveedor, otra ciudad»
accept_language_estimate	Cabecera estimada desde navigator.languages	Muestra lo que la página cree enviar; lea la cabecera real en la solicitud
timezone_reported	Zona IANA que devolvió el navegador	Detecta un perfil que contradice su propio proxy
creative_ref	Identificador, hash o referencia de archivo	Permite comparar sin redistribuir el recurso
landing_url	URL final después de las redirecciones	Separa la negociación de la redirección del cliente
observed_at	Hora de la captura en UTC	Ordena las observaciones y expone cambios de planificación
alignment_result	aligned o el desajuste nombrado	Impide que una fila desalineada entre en una serie

Dos detalles de esa tabla son fáciles de omitir y costosos de reconstruir. El primero es la diferencia entre la URL solicitada y la URL final de destino. Una cadena de redirecciones puede mover una solicitud después de la negociación, y registrar solo la dirección solicitada oculta el paso que realmente explica una diferencia. El segundo es la referencia de creatividad. Guardar un hash o un identificador del lado del editor mantiene el registro revisable respetando los límites de retención, y permite que una ejecución posterior distinga «misma creatividad» de «misma campaña, recurso nuevo».

Esta es la misma disciplina de contexto que el modelo de captura de posiciones SERP aplica a los resultados orgánicos: un valor ordinal no significa nada sin la firma de contexto que lo produjo. Una ubicación publicitaria es comparable bajo la misma regla, aunque las salidas difieran.

La retención merece su propia decisión, porque las referencias de creatividad pueden pesar más de lo que parecen. Un hash del recurso creativo suele bastar para distinguir dos observaciones, pero una URL de destino puede incluir identificadores que pertenecen a una solicitud de entrega concreta. Elimine o transforme en hash los parámetros que llevan un identificador de entrega antes de guardar la URL, y conserve el valor sin modificar solo si los términos de la plataforma y su propia política de retención lo permiten. El registro de perfil con proxy rotativo usa el mismo enfoque para la identidad de sesión: conservar una referencia estable y descartar el detalle por solicitud que añade riesgo sin añadir comparabilidad.

Una serie también necesita una condición de cierre declarada. Las campañas publicitarias cambian según calendarios que una captura no observa, así que una serie abierta acabará comparando dos estados de la misma campaña y lo llamará diferencia regional. Declare la ventana de observación cuando empieza la serie, marque la última captura cuando la ventana se cierre y trate las capturas posteriores como una nueva serie con su propio registro de alineación. Esa sola disciplina evita la mayoría de las conclusiones que tiende a producir una captura prolongada y sin etiquetar.

Dónde aplica ads.txt y dónde se detiene

ads.txt se malinterpreta con frecuencia en el trabajo de captura, y en ambas direcciones. La especificación describe un mecanismo que permite a un editor declarar públicamente quién está autorizado a vender su inventario publicitario, y el formato de archivo registra sistemas autorizados y relaciones de revendedor a nivel de dominio. Consultar el archivo de un editor responde, por tanto, a una pregunta de cadena de suministro: si esa relación de venta está declarada.

No responde a tres preguntas que un flujo de captura tiende a plantearle. No dice si la recolección está permitida, porque la especificación trata de la venta autorizada de inventario y no de quién puede solicitar una página. No establece que una impresión observada fuera facturable, porque el archivo describe autorización declarada y no liquidación. Y no indica cómo se selecciona una creatividad, porque la selección creativa no está en el alcance del archivo en absoluto.

La aplicación útil es más estrecha y aun así vale la pena: cuando una captura se compara con la ubicación reportada por un socio, un registro de ads.txt puede mostrar si la lista de vendedores declarada del dominio incluye el sistema que el socio nombra. Un desacuerdo ahí es una pregunta de cadena de suministro para el socio, no una inferencia sobre segmentación regional. Mantenga ambos hallazgos en campos separados para que un lector posterior no los fusione en un solo veredicto.

El mantenimiento del propio archivo importa para esa comparación. Un registro puede listarse con un tipo de relación que cambia cómo se trata a un sistema, y la especificación espera que las entradas sean legibles en una ruta estable del dominio observado. Si un dominio devuelve un archivo distinto entre dos capturas, la pregunta sobre el vendedor ha cambiado con independencia de cualquier pregunta regional, y las dos capturas ya no describen la misma cadena de suministro. Registre la hora de obtención del archivo y un hash del cuerpo junto a la comparación de vendedores, para que un cambio de cadena de suministro no pueda confundirse más tarde con un cambio de entrega publicitaria.

Resista la tentación de tratar un vendedor declarado como señal de calidad. La especificación describe autorización para vender inventario y su alcance es deliberadamente estrecho: no es una afirmación sobre calidad creativa, visibilidad, seguridad de marca ni exactitud de ningún informe. Una conversación con un socio que necesite esas respuestas tiene que usar los informes del propio socio, y una consulta a ads.txt aporta exactamente un dato.

Términos y alcance antes de las herramientas

Una ejecución de verificación publicitaria toca la página de un editor, la respuesta de un sistema publicitario y posiblemente el script de un proveedor de medición, así que a una sola captura se le aplican tres conjuntos de términos y no uno. Cada conjunto decide más que las opciones de herramientas. Una captura técnicamente posible puede seguir estando fuera de lo que una plataforma permite, y ninguna cantidad de configuración de perfil o proxy cambia eso.

De ahí se siguen dos límites prácticos. Primero, observar no es participar: una petición GET que registra lo que devolvió una página es un acto distinto de emitir los balizadores de impresión y visibilidad que envía un script de medición, y el segundo queda fuera del alcance de un flujo de captura. Segundo, una diferencia entre dos capturas es una observación, no un hallazgo de fraude o entrega incorrecta; esas conclusiones pertenecen a las partes que tienen los registros de entrega y la relación contractual.

El límite de monitoreo de comercio electrónico traza la misma línea para la observación de precios y disponibilidad: una página renderizada y un feed de socio responden preguntas distintas y no deben fusionarse en una serie. La verificación publicitaria necesita esa separación con más nitidez, porque tres sistemas independientes pueden cambiar la respuesta cada uno.

Preguntas frecuentes

¿Un desajuste de región invalida una captura aunque la creatividad parezca idéntica?

Sí. La captura ya no describe un lugar coherente, así que no puede compararse con una captura bien alineada de ninguna de las dos regiones. Una salida idéntica hace que el registro parezca limpio mientras lo deja inutilizable para comparar.

¿Puede la comprobación de alineación sustituir a una verificación de salida?

No. Una página puede leer su lista de idiomas declarada y su zona horaria reportada, pero no puede leer de forma fiable su propia dirección pública. Confirme la salida del lado del operador y guarde ese valor en el registro de captura.

¿Indica ads.txt si una ubicación publicitaria es legítima?

No. Declara qué sistemas autoriza un editor para vender inventario en ese dominio. No describe selección creativa, entrega facturable ni permiso para recolectar.

¿Hace BotBrowser que una captura provenga de un país concreto?

Aplica una salida de proxy y deriva de esa dirección valores predeterminados de zona horaria, configuración regional e idiomas. La documentación indica que las anulaciones manuales de esos tres valores requieren una licencia ENT Tier1. La captura resultante sigue reflejando lo que el sistema publicitario decida devolver, y la derivación a nivel de ciudad puede ser aproximada.

Fuentes

• IAB Tech Lab ads.txt
• Especificación ads.txt versión 1.1
• MDN Accept-Language
• RFC 9110 semántica HTTP
• Base de datos GeoIP de BotBrowser
• Zona horaria, configuración regional e idiomas en BotBrowser

Conclusión práctica

Trate la región de salida, la zona horaria reportada y la lista de idiomas declarada como una sola propiedad de la captura. Ejecute la comprobación de alineación antes de la primera captura y de nuevo tras cualquier cambio de proxy, perfil o idioma. Guarde las tres entradas con la referencia de creatividad, la URL final de destino y la hora de observación, y marque una fila como alineada solo cuando las tres coincidan con la región que la ejecución afirma representar. Cuando aparezca una diferencia con la alineación intacta, la explicación está del lado de la fuente, y el registro es lo que hace disponible esa conclusión.