Fraude de dominio: impresiones falsas en tu medición

Una impresión que compras parece venir de un sitio publicador, pero en realidad pasó a través de cinco intermediarios antes de llegar a ti. Cada uno tomó su porcentaje, sin dejar rastro. El sitio que crees que visitó el usuario no es el real: es un dominio falsificado que se parece lo suficiente para engañar a la verificación superficial. Esto no es raro. Es lo que ocurre cuando el registro de quién tocó la venta se rompe en la mitad del camino.

El problema empieza cuando tratas de medir. Los datos de conversión llegan sin contexto claro de dónde vinieron. ¿Fue realmente el tráfico que pagaste? ¿O llegó a través de una cadena tan ofuscada que tu platform no puede reconciliar el gasto con el ingreso real? Cuando la cadena de suministro es invisible, tu medición de atribución colapsa. No importa cuánto dinero inviertas en inteligencia artificial para modelar la ruta de conversión: si la entrada está envenenada, el modelo aprende a falsificar.

Qué se rompió en la cadena de suministro

En 2017, ads.txt fue un paso adelante. Permitía que los publicadores declararan públicamente quién estaba autorizado a vender su inventario. Pero resolvía una sola pregunta: quién tiene permiso. No respondía la más importante: cuántas manos tocaron la impresión en el camino hacia ti, y en qué orden.

Un publicador podría autorizar a una SSP, y esa SSP podría revender a través de tres intermediarios más, todos autorizados, antes de que el bid llegue a tu DSP. Ads.txt confirma quiénes están permitidos, no la ruta real que tomó la impresión. Ese punto ciego es donde florecen las cadenas ofuscadas y el suplantación de dominio: SSPs que resuelven impresiones a través de intermediarios que nunca fueron registrados como parte de la cadena de pago.

Cada mano invisible es una oportunidad para que un fraude se oculte. Un sitio ficticio en el que nadie verificó que existiera. Un dominio que parece legítimo pero que dirige a una granja de contenido. Un intermediario que se insertó él mismo en la cadena sin estar autorizado por el publicador original.

Cómo entra el fraude cuando no hay registro

El fraude de dominio depende de un mecanismo muy simple: que nadie mire demasiado cerca la ruta que la impresión tomó. Si tu DSP nunca pregunta "¿quién realmente tocó esto?", entonces un intermediario puede reclamar que viene de un publicador de alto valor cuando en realidad viene de una granja de contenido. El bid request contiene un identificador que parece ser del dominio real, pero si nadie valida ese identificador contra la realidad, el fraude persiste.

La cadena de suministro del anuncio digital fue diseñada para ser rápida, no verificable. Cada intermediario tenía incentivos para dejar pasar el tráfico oscuro: comisiones más altas, volumen más rápido. La validación requería trabajo de ambos lados, y durante años nadie lo hizo.

Qué es schain y por qué cambia esto

El objeto SupplyChain (schain) es un mecanismo que entra en cada bid request y registra quién tocó la venta, en orden, comenzando con el publicador original. Cada intermediario que toca la impresión tiene que insertar su propio nodo en la cadena. Si salta ese paso, la cadena se invalida.

Lo inteligente de esta especificación es que no puedes simplemente pasar la cadena adelante sin declararte. Si tomas custodia de un bid request, tienes que insertarte a ti mismo. Es una regla pequeña que mantiene todo el sistema honesto: no puedes desaparecer silenciosamente de tu propia cadena de suministro.

Pero tener un objeto schain en el bid request no prueba nada por sí solo. Cualquiera puede meter un dominio y un ID en JSON. El valor aparece solo cuando alguien verifica si lo declarado concuerda con la realidad.

Cómo se valida realmente una cadena

La validación es un proceso de tres capas: cada nodo en la cadena schain debe ser verificado contra ads.txt y sellers.json del sistema publicitario. Ads.txt dice quién un publicador autoriza para vender. Sellers.json dice quién, desde el lado del sistema publicitario, realmente es ese ID de vendedor.

A escala industrial, una impresión válida debe pasar esto: cada intermediario declarado en schain tiene que existir en sellers.json de su propio sistema, y si es un nodo de pago (hp=1), tiene que aparecer en ads.txt del publicador original como alguien autorizado a manejar el pago.

Esto suena manejable para un bid request. Es un problema completamente diferente a escala de miles de millones de bids por día, con archivos ads.txt y sellers.json cambiando constantemente en miles de dominios. Por eso IAB Tech Lab construyó un servicio de validación automatizado. Sin validación continua, una entrada faltante o incorrecta en estos archivos puede costarle ingresos a un publicador sin que él lo sepa. O puede permitir que alguien no autorizado venda su inventario, también en silencio.

Qué atrapó la validación: los fraudes que iba a encontrar

En la práctica, cuando los exchanges y DSPs empezaron a validar schain contra el registro público, encontraron cosas recurrentes: nodos cuyo par asi/sid (sistema publicitario e ID de vendedor) nunca existe en el sellers.json real de ese sistema. Eso es generalmente un salto fabricado. Intermediarios cuyo ID de vendedor nunca aparece en ads.txt del publicador pero se declara como pagadores. Cadenas que silenciosamente se degradan a "incompletas" cuando la validación falla, perdiendo la señal en la que los compradores estaban contando. Identificadores de bundle u app que se refieren a tiendas de aplicaciones que no existen, o dominios que no resuelven.

También: mera implementación descuidada. IDs de vendedor duplicados señalando a diferentes entidades. Campos requeridos faltando. Cada uno de esos errores es invisible mirando un solo bid. Pero cuando validás continuamente contra el registro público, cada uno de esos problemas salta a la vista.

Por qué importa esto en tu medición

Para ti como anunciante, la validación de schain es una señal de que el inventario realmente es lo que dice ser. No es una garantía de rendimiento. Pero es la diferencia entre poder rastrear dónde fue realmente tu dinero y simplemente esperar que tus números concuerden con los de tu DSP.

Cuando tu DSP valida schain, puede decirte con confianza: esta impresión vino de la cadena que dice que vino. O esta impresión vino de una cadena que no puedo validar, así que la filtro. En el segundo caso, estás viendo fraude o negligencia capturados antes de que el dinero se gaste.

Sin validación, esa impresión simplemente se mezcla con el resto. No sabes si tu tasa de conversión es baja porque el tráfico es real pero de baja calidad, o porque es un fraude de dominio que nunca vio a un usuario real. No puedes separar ambas cosas.

Lo que tienes que revisar esta semana

Pregunta a tu DSP: ¿valida schain en tiempo real antes de que hagas la puja? No como un análisis posterior, sino como un filtro de bid-time que descarta o desestima las cadenas que no reconcilian contra ads.txt y sellers.json. Si la respuesta es que tienen schain pero no lo validan en tiempo real contra el registro público, entonces estás comprando con dos ojos cerrados. Si dicen que sí lo hacen, pídeles que te muestren el volumen de impresiones que filtraron la semana pasada por cadena no validable. Si ese número es cercano a cero, o si no pueden decirte, entonces posiblemente no lo estén haciendo bien.

También pregunta: ¿tienes la opción de excluir o desestimar bids con cadenas incompletas? Una cadena "incompleta" significa que se rompió en algún punto: no puede ser validada completamente hasta el publicador original. Eso debería ser una razón para no confiar en ese inventario, especialmente si viene de un partner sin un trato directo.

Cómo esto afecta tu decisión de presupuesto

Si la medición que estás usando está hecha sobre impresiones que no puedes validar hasta su origen, entonces estás optimizando sobre números tóxicos. Un modelo que dice "este canal convertía 30%" puede estar viendo un 20% fraude silencioso. Tu decisión de aumentar o reducir inversión en ese canal se basa en un número falso.

Schain validation es el filtro de fraude más barato y más determinista que existe antes de que el dinero salga. Casi toda la detección de fraude es posterior: patrones observados después de que el daño está hecho. Schain validation es diferente porque es determinista. La cadena reconcilia contra el registro público, o no reconcilia. Eso se sabe en tiempo real.

Si hoy estás escalando inversión en canales porque el ROAS reportado se ve bien, pero tu DSP no está validando schain, entonces estás escalando basado en números que podrían estar envenenados. Un intercambio que puede garantizar schain validado en cada bid está, funcionalmente, ofreciendo mejor inventario, incluso si nada sobre la impresión misma cambió.

El trabajo para la próxima trimestre

El estándar sigue evolucionando. Hay una versión 1.1 de schain propuesta que maneja mejor los nodos que toman custodia pero no manejan el pago. Pero el punto central no va a cambiar: en lugar de que cada DSP intente manualmente reconciliar cadenas contra el registro público, eso va a ocurrir continuamente, a escala, como otra señal de calidad más.

La dirección del viaje es clara: los compradores sofisticados van a dejar de perseguir esto manualmente en auditorías cada seis meses, y van a empezar a requerirlo continuamente, en tiempo real, a todos sus partners.

Para un anunciante, eso significa: empieza a exigir que tu DSP y tus exchanges validen schain. Si no lo hacen, o dicen que es muy complicado, eso es una razón para no confiar en sus números. Una cadena que no puedes verificar contra el registro público debería tratarse de la misma manera que cualquier otra bandera roja: un motivo para pasar, salvo que tengas un trato directo y completamente transparente con ese partner.

Hoy el margen de inventario sin validar sigue siendo grande. Pero ese margen se va a achicar. La pregunta es si quieres estar del lado que ve venir ese cambio, o del lado que se sorprende cuando tu medición ya no cuadra con la realidad.