Definición profesional
El SupplyChain object es un objeto definido por IAB Tech Lab dentro de la especificación OpenRTB que registra, en cada bid request, la secuencia completa de sistemas publicitarios que participan en la venta o reventa del inventario antes de que la solicitud llegue al comprador.
Cada eslabón de esa secuencia se llama nodo y contiene, como mínimo, el dominio del sistema publicitario (asi) y el identificador del vendedor dentro de ese sistema (sid), los mismos valores que ese sistema declaró en su archivo ads.txt. El objeto viaja en el atributo Source.schain a partir de OpenRTB 2.6, en Source.ext.schain en OpenRTB 2.5 y en ext.schain en versiones anteriores. Un indicador adicional (complete) declara si la cadena documentada llega hasta el propietario original del inventario o si representa solo un tramo conocido de la reventa.
Explicación sencilla
Pensemos en el schain como el recibo de una cadena de reventa. Cuando una impresión pasa por varias manos antes de llegar a la subasta, cada mano deja su firma en ese recibo. El comprador que recibe la puja abre el recibo y ve, en orden, quién vendió el espacio primero, quién lo revendió después y quién se lo entregó finalmente a su sistema. Sin ese recibo, el comprador solo ve al último eslabón y no tiene forma de confirmar si el resto de la cadena es legítimo.
¿Por qué existe este concepto?
Antes del schain, un bid request identificaba al publisher a través de los campos Publisher.name y Publisher.domain, pero esos campos se completaban de forma inconsistente o se omitían directamente, sobre todo cuando el inventario pasaba por varios revendedores antes de llegar a la subasta.
Esa opacidad abría espacio para inventario falsificado, domain spoofing y cadenas de reventa infladas que encarecían el CPM sin beneficio real para el anunciante. IAB Tech Lab publicó el schain junto con sellers.json con el mismo objetivo, dar a los compradores una forma de verificar quién participa realmente en la transacción antes de pujar, en lugar de confiar en la declaración de un solo intermediario.
¿Cómo funciona?
Cuando el publisher genera el primer bid request de una impresión, crea el objeto schain con un único nodo (el propio) y marca complete en 1 si es el propietario original del inventario. Si un revendedor recibe esa solicitud y la reenvía a otro sistema, aplican dos reglas. Primero, el revendedor no puede copiar el schain existente sin insertar su propio nodo, hacerlo invalida la cadena. Segundo, si el revendedor recibe inventario que no traía un schain previo, debe crear uno nuevo, marcar complete en 0 y agregar solo su propio nodo.
Cada nodo incluye también hp, que indica si esa entidad participa en el flujo de pago (en la versión 1.0 de la especificación este valor siempre es 1), y el campo ver, que documenta la versión de la especificación empleada. El resultado es una cadena ordenada donde el primer nodo representa al propietario original del inventario y el último nodo representa a quien envía la solicitud final al comprador.
¿Quién lo utiliza?
- Publishers y propietarios de inventario generan el primer nodo del schain y necesitan declarar en ads.txt los mismos identificadores (asi y sid) que aparecerán en ese nodo, de modo que ambos documentos coincidan cuando un comprador los cruce.
- SSP y exchanges reciben el inventario, agregan su propio nodo cuando revenden o transmiten la solicitud y son responsables de no romper la cadena heredada de los nodos anteriores.
- DSP y trading desks leen el schain antes de decidir si pujan, lo usan como filtro para descartar cadenas con reventa excesiva o nodos no reconocidos, y lo cruzan contra sellers.json para confirmar que cada nodo corresponde a una entidad verificada.
- Proveedores de verificación y prevención de fraude auditan schains a gran escala para detectar patrones de domain spoofing, cadenas incompletas recurrentes o nodos que no coinciden con lo declarado en ads.txt.
Caso práctico
Un publisher vende directamente parte de su inventario a un exchange y, además, autoriza a un revendedor externo a comercializar el resto del inventario que no coloca de forma directa. Cuando la impresión sale de forma directa, el bid request incluye un schain con complete en 1 y un único nodo, el del propio publisher.
Cuando la misma impresión sale a través del revendedor, este agrega su propio nodo al final de la cadena y conserva el nodo original del publisher, de modo que el comprador recibe una solicitud con dos nodos y puede confirmar que la reventa está autorizada. Si el comprador ve una solicitud con cinco o seis nodos para el mismo inventario, ese volumen de intermediación es una señal que suele evaluarse dentro de una estrategia de supply path optimization antes de decidir si conviene pujar por esa ruta.
Error frecuente
Un error habitual es dar por sentado que basta con incluir el schain para garantizar que el inventario es legítimo. El objeto documenta quién participa, no certifica que esos participantes sean honestos. Un revendedor puede insertar un nodo válido en la forma pero declarar un sid que no corresponde a la entidad real y esa inconsistencia solo se detecta cruzando el schain contra sellers.json, no leyendo el schain de forma aislada.
¿Qué no es?
Ads.txt autoriza revendedores a nivel de dominio, antes de que ocurra cualquier subasta. El schain documenta la cadena real dentro de cada bid request individual, transacción por transacción. Confundir ambos lleva a pensar que uno reemplaza al otro cuando en realidad operan en capas distintas y complementarias.
Sellers.json es un archivo público que cada sistema publicitario expone para identificar a todos los vendedores que representa, en cualquier momento. El schain es un objeto que viaja dentro de una transacción puntual y expone solo los nodos involucrados en esa transacción específica. Uno funciona como directorio permanente, el otro como bitácora de una sola solicitud.
Supply path optimization es la decisión estratégica de qué rutas de compra priorizar. El schain es el dato crudo que alimenta esa decisión, no la decisión en sí misma. Activar la lectura del schain no optimiza rutas de forma automática, solo aporta la visibilidad que otro proceso necesita para tomar esa decisión.
Términos relacionados
Evolución histórica
IAB Tech Lab finalizó la especificación original del SupplyChain object junto con sellers.json para adopción de la industria el 31 de julio de 2019, como respuesta directa a los límites de ads.txt para revelar intermediarios más allá del vendedor final.
Durante los años siguientes la adopción creció de forma dispareja, entre otras razones porque la versión 1.0 obliga a que el campo hp valga siempre 1, lo que deja fuera a entidades que participan en el flujo técnico de la solicitud sin cobrar por el inventario.
En junio de 2026 IAB Tech Lab anunció SupplyChain v1.1, una actualización que permite incorporar nodos de custodia técnica directamente en la cadena principal usando la marca hp en 0 para las entidades que no forman parte del flujo de pago, con el objetivo de dar a los compradores una vista más completa de quién controla la solicitud además de quién cobra por ella. Esa actualización fue desarrollada por el grupo de trabajo de OpenRTB dentro de IAB Tech Lab.
Estándares relacionados
| Estándar | Organización | Relevancia |
|---|---|---|
| ads.txt | IAB Tech Lab | Declara qué vendedores están autorizados a nivel de dominio, usando el mismo par asi y sid que después confirma cada nodo del schain. |
| sellers.json | IAB Tech Lab | Permite verificar la identidad de cada nodo declarado en el schain contra el registro público que publica el sistema publicitario correspondiente. |
| OpenRTB | IAB Tech Lab | Define el protocolo del bid request donde el schain se transporta, dentro del objeto Source a partir de la versión 2.6. |
| DemandChain object | IAB Tech Lab | Aplica la misma lógica de transparencia al lado de la demanda, documentando quién compra en lugar de documentar quién vende. |
Empresas y tecnologías asociadas
Los principales SSP y exchanges del mercado, entre ellos Google Ad Manager, Magnite, PubMatic, Index Exchange y OpenX, son compatibles de forma nativa con la lectura y la propagación del schain dentro de sus bid requests.
Los wrappers de header bidding, con Prebid.js como el más extendido en implementaciones open source, incluyen módulos específicos para construir y transmitir el objeto desde el navegador o la app hacia cada demand partner conectado.
Del lado de la verificación, proveedores especializados en calidad de inventario auditan schains a escala junto con ads.txt y sellers.json para identificar inconsistencias entre lo declarado y lo transaccionado.
Pregunta frecuente
¿Un schain incompleto, con complete en 0, significa que el inventario es fraudulento?
No necesariamente. Un valor de complete en 0 indica que la cadena documentada no llega hasta el nodo original conocido, algo que ocurre cuando algún sistema en la cadena todavía no es compatible con la especificación completa, no necesariamente porque exista intención de ocultar algo. Ese dato debe leerse junto con la longitud de la cadena y la reputación de los nodos declarados, nunca de forma aislada.