Cualquier comprador de programmatic lo ha vivido al menos una vez. El anuncio de un cliente aparece junto a una noticia de la que nunca debería haber estado cerca, alguien hace una captura de pantalla y la conversación deja de girar en torno a los CPM. Puede que la campaña haya cumplido todos sus objetivos de rendimiento, pero nada de eso importa una vez que la marca se siente expuesta.

La compra en subasta abierta hace que esto sea más difícil de lo que parece. Tu plataforma puede evaluar miles de bid requests por segundo procedentes de sitios y apps que nadie de tu equipo ha visitado jamás. La única forma de mantener los anuncios lejos de los lugares equivocados a esa velocidad es dejar las reglas escritas de antemano y que la plataforma de compra las aplique antes de cada puja. Esas reglas son tus blocklists de brand safety.

Esta guía explica qué es una blocklist de brand safety, cómo funciona realmente el bloqueo por categoría, dominio, app y palabra clave dentro de una demand-side platform, dónde falla cada método, en qué se diferencian las blocklists de las allowlists y cómo crear y mantener una lista que proteja a los clientes sin dejar a las campañas sin alcance.

¿Qué es una blocklist de brand safety?

Una blocklist de brand safety es un conjunto de reglas que indica a una plataforma de compra dónde no deben publicarse los anuncios de un anunciante. Cada regla describe algo que el comprador puede detectar en una bid request: una categoría de contenido, un dominio web, una app móvil o palabras que aparecen en la página o en sus metadatos. Cuando una impresión entrante coincide con una regla, la plataforma no puja por ella.

La palabra clave es «antes». Una blocklist funciona pre-bid. No es un informe que lees después de haber gastado el dinero. La comprobación se produce en los pocos milisegundos que transcurren entre el momento en que llega una bid request y el momento en que tu plataforma decide si responderla. Si quieres ver exactamente qué campos utiliza esa decisión, nuestra guía sobre qué contiene una bid request recorre el objeto OpenRTB completo.

El brand safety también es distinto de la prevención del fraude, aunque ambos temas suelen tratarse juntos. La prevención del fraude se pregunta si la impresión es real: ¿hay una persona auténtica, en un dispositivo auténtico, en el sitio que el vendedor afirma? El brand safety da por hecho que la impresión es real y se plantea otra pregunta: ¿es este un lugar donde este anunciante quiere que lo vean? Una campaña necesita ambas cosas. Una audiencia perfectamente humana en el tipo de página equivocado sigue siendo un problema, y una página perfectamente segura llena de bots sigue siendo dinero desperdiciado.

Los cuatro tipos de bloqueo dentro de un DSP

Infografía que muestra los cuatro tipos de bloqueo de brand safety dentro de un DSP: categoría, dominio, app y palabra clave.

La mayoría de las plataformas de compra admiten cuatro tipos de reglas de bloqueo. Funcionan con distintos niveles de detalle y cada una depende de que una parte diferente de la bid request esté presente y sea precisa.

Tipo de bloqueo Qué detecta De dónde procede la señal Principal debilidad
Categoría Temáticas de contenido completas, como contenido para adultos, apuestas o noticias violentas Códigos de categoría que el vendedor incluye en la request, o una clasificación de terceros Solo es tan precisa como quien haya etiquetado la página
Dominio Sitios web concretos El dominio del sitio y la URL de la página en la request Los dominios nuevos y suplantados aparecen más rápido de lo que se actualizan las listas
App Apps móviles o de CTV concretas El bundle ID o el ID de tienda de la app en la request El vendedor puede declarar mal los bundle IDs
Palabra clave Palabras en la URL de la página, el título, las palabras clave del contenido o el texto Campos de palabras clave de la request, texto de la URL o análisis contextual de la página Bloquea páginas seguras que simplemente mencionan una palabra sensible

Bloqueo por categoría

El bloqueo por categoría es la herramienta más amplia. En OpenRTB, un vendedor puede describir el contenido de un sitio o una app con códigos de categoría, normalmente tomados de la IAB Tech Lab Content Taxonomy. La request puede incluir categorías para todo el sitio, para la sección actual y para la página actual. Las versiones más recientes del protocolo incluyen además un campo que indica de qué versión de la taxonomía proceden los códigos, para que comprador y vendedor interpreten el mismo código de la misma manera.

En el lado de la compra, seleccionas las categorías que un anunciante debe evitar y la plataforma descarta cualquier request que incluya alguna de ellas. Es rápido y fácil de configurar. El punto débil es que la etiqueta la elige el vendedor. Un publisher interesado en vender más impresiones tiene pocos motivos para marcar sus propias páginas como sensibles, y muchas requests llegan con una única categoría genérica para todo el sitio o sin ninguna categoría. El bloqueo por categoría es un primer filtro útil, no una solución completa.

Bloqueo por dominio y por app

El bloqueo por dominio es la herramienta más precisa de la que dispones. Si un sitio ha causado un problema una vez, añades su dominio y tu plataforma no volverá a pujar por él. El bloqueo por app hace lo mismo con las apps móviles y de televisión conectada, utilizando el identificador de bundle o de tienda de la app en lugar de un dominio.

La precisión tiene dos límites. En primer lugar, una lista de dominios solo cubre los sitios que ya conoces, y cada día aparecen sitios nuevos. En segundo lugar, el dominio de la request es una afirmación del vendedor. El inventario fraudulento puede declarar un dominio respetable mientras sirve el anuncio en otro lugar. Por eso el bloqueo por dominio siempre debe combinarse con comprobaciones de la cadena de suministro. Nuestra guía sobre ads.txt, app-ads.txt y sellers.json explica cómo verifican los compradores que un vendedor está realmente autorizado para vender un dominio o una app determinados.

Bloqueo por palabra clave

El bloqueo por palabra clave busca palabras o frases concretas relacionadas con la impresión. En su forma más sencilla, la plataforma analiza la URL de la página y cualquier campo de palabras clave de la request. Las configuraciones más avanzadas utilizan un servicio de análisis contextual que lee el texto real de la página, a menudo antes de la subasta, y devuelve una señal sobre la que la plataforma de compra puede actuar.

Las palabras clave detectan cosas que las categorías pasan por alto, como una noticia de última hora en un sitio por lo demás seguro. También son la forma más fácil de bloquear en exceso. Una lista que contenga palabras como «shooting», «attack» o «crash» bloqueará noticias de sucesos, pero también la cobertura de baloncesto, las noticias de ciberseguridad y los comentarios sobre bolsa. Las listas de palabras clave son el tipo de regla que más cuidado requiere, y volveremos sobre ello más adelante.

Blocklists vs. allowlists: ¿cuál deberías usar?

Una blocklist dice «puja en todas partes excepto aquí». Una allowlist, también llamada lista de inclusión o whitelist, dice «puja solo aquí». Son enfoques opuestos para el mismo problema, y la mayoría de los equipos de compra con experiencia utilizan ambos, en campañas distintas.

Factor Blocklist Allowlist
Comportamiento por defecto Puja por todo lo que no está en la lista Puja solo por lo que está en la lista
Alcance Amplio, crece a medida que aparece nuevo inventario Limitado a la lista aprobada
Protección frente a sitios desconocidos Débil: los sitios nuevos se permiten hasta que alguien los añade Fuerte: los sitios nuevos se excluyen hasta que alguien los aprueba
Esfuerzo de mantenimiento Incorporaciones continuas a medida que se detectan problemas Revisiones continuas para añadir nuevo inventario de calidad
Uso habitual Campañas de performance y de prospecting Marcas sensibles, sectores regulados, acuerdos premium

Un patrón habitual es mantener una blocklist compartida que se aplica a todas las campañas de la plataforma y añadir allowlists por encima para los clientes que necesitan un control más estricto. Un banco o una marca infantil puede publicar únicamente en una lista aprobada de unos pocos cientos de dominios. Un anunciante de performance que vende un producto de consumo masivo puede publicar en inventario abierto con la blocklist compartida y una lista breve específica para ese cliente.

Cómo se realiza la comprobación de la blocklist antes de la puja

Infografía que muestra cómo se realiza la comprobación de una blocklist de brand safety antes de la puja, desde la request entrante hasta la decisión de pujar o pasar y la revisión de la lista.

Desde el punto de vista de la plataforma, el brand safety es simplemente otro filtro dentro del proceso de puja. El orden de las operaciones es el siguiente:

  1. Llega la request. Un SSP o un exchange envía una bid request con el dominio o la app, la URL de la página, los códigos de categoría que haya, los datos del dispositivo y la cadena de suministro.
  2. La plataforma comprueba las reglas compartidas. Primero se aplican los bloqueos a nivel de plataforma: dominios, apps, vendedores y categorías conocidos como problemáticos que ninguna campaña debería comprar nunca.
  3. Cada campaña elegible aplica sus propias reglas. Las blocklists, allowlists y reglas de palabras clave a nivel de cliente eliminan las campañas que no deben pujar por esta impresión.
  4. Se añaden señales opcionales de terceros. Si hay conectado un servicio contextual o de verificación, su veredicto pre-bid se utiliza como una regla más.
  5. La plataforma puja o pasa. Si alguna campaña sigue siendo elegible, pone precio a la impresión y responde. Si no, no envía ninguna puja y no se gasta dinero.
  6. Los resultados alimentan de nuevo las listas. Los informes de ubicaciones y las comprobaciones post-bid muestran dónde se publicaron realmente los anuncios, y todo lo que no debería haber pasado se añade a las listas.

De aquí se derivan dos consideraciones prácticas. Las reglas compartidas deben ejecutarse antes que las reglas de campaña, porque una request que ninguna campaña puede comprar debe descartarse lo antes y con el menor coste posible. Y cada comprobación tiene que ser rápida. Una plataforma de compra que dedica demasiado tiempo al filtrado agotará el tiempo de espera y perderá subastas que quería ganar, por lo que las reglas de brand safety suelen mantenerse en memoria como búsquedas sencillas en lugar de evaluarse desde cero en cada request.

También conviene saber que los publishers aplican bloqueos en sentido contrario. OpenRTB permite a un vendedor enviar listas de categorías de anunciantes, dominios de anunciantes y apps que no aceptará. Tu plataforma también debe respetarlas, o sus pujas simplemente serán rechazadas. El brand safety es un acuerdo bidireccional que se aplica en la misma request.

Errores habituales con las blocklists

La mayoría de los problemas de brand safety no se deben a no tener ninguna lista. Se deben a listas que se configuraron una vez y nunca se volvieron a revisar. Estos son los errores que vemos con más frecuencia:

  • Bloquear en exceso con palabras clave amplias. Las listas largas de palabras clave copiadas de campañas antiguas eliminan silenciosamente grandes cantidades de inventario seguro, sobre todo de noticias. El resultado es menos alcance, precios más altos y menos publishers de calidad en el mix.
  • Confiar solo en las categorías declaradas. Si la etiqueta la elige el vendedor, un bloqueo por categoría solo te protege de los vendedores que etiquetan con honestidad.
  • Bloquear el dominio pero no la ruta. Un dominio puede venderse directamente, a través de varios revendedores o suplantarse por completo. Comprobar quién está autorizado para venderlo importa tanto como el propio dominio. Nuestra guía sobre supply path optimization explica cómo recortar las rutas de riesgo hacia el mismo inventario.
  • Una sola lista para todos los clientes. Una marca de videojuegos y una marca farmacéutica tienen definiciones muy distintas de lo que es seguro. Las listas compartidas deben cubrir lo que nadie compra; las listas de cliente deben cubrir el resto.
  • No registrar por qué se bloqueó algo. Sin un motivo y una fecha junto a cada entrada, nadie se atreve a eliminar nada y la lista no para de crecer.
  • Ignorar las apps y la CTV. Los equipos que crearon sus listas para la web suelen olvidar que el inventario de apps y de televisión se identifica mediante bundle IDs, no dominios, y necesita sus propias entradas.

Cómo crear y mantener una blocklist de brand safety

Una buena blocklist es pequeña, específica, está documentada y se revisa. El siguiente proceso funciona para agencias y ad networks que gestionan muchos anunciantes en una sola plataforma.

1. Acuerda la definición de inseguro de la marca

Empieza por el anunciante, no por la herramienta. Pregunta qué temas son siempre inaceptables, cuáles son aceptables en ciertos contextos y cuáles no plantean problema. Las noticias duras sobre un conflicto pueden ser inaceptables para una marca y encajar de forma natural con una oferta de suscripción a un medio de noticias. Deja las respuestas por escrito para que la lista pueda vincularse a una decisión.

2. Crea una capa base compartida

A nivel de plataforma, bloquea lo que ningún cliente debería comprar nunca: contenido ilegal, contenido para adultos cuando no sea el negocio del anunciante, dominios y apps fraudulentos conocidos y vendedores que no superan las comprobaciones de la cadena de suministro. Esta capa rara vez cambia y protege automáticamente todas las campañas.

3. Añade capas por cliente

Para cada anunciante, añade las categorías, los dominios, las apps y una lista de palabras clave breve y precisa que reflejen su propia política. Da preferencia a las frases exactas frente a las palabras sueltas, y a las señales de categoría o contextuales frente a las palabras clave cuando la plataforma lo permita.

4. Mide el coste en alcance

Antes de activar una lista nueva, compara cuántas requests elimina. Si una lista de palabras clave elimina mucho más inventario del esperado, revisa una muestra de las páginas bloqueadas. Muy a menudo, una sola palabra demasiado amplia es responsable de la mayor parte de la pérdida.

5. Revisa de forma periódica

Establece una revisión regular: mensual para la mayoría de los equipos y semanal para los anunciantes sensibles. Añade las nuevas ubicaciones problemáticas a partir de los informes de ubicaciones y del feedback de los clientes. Elimina las entradas cuyo motivo ya no sea válido. Mantén un registro de auditoría de quién cambió qué y cuándo, para poder explicar cada decisión al cliente.

El brand safety va de la mano de la calidad del tráfico, no la sustituye. Si quieres profundizar en la parte del fraude, nuestros artículos sobre por qué la calidad del tráfico debería ser tu primera prioridad y sobre la protección contra el fraude publicitario y el tráfico no válido cubren la otra mitad del problema.

Por qué ser dueño de la plataforma cambia el brand safety

Cuando compras a través de la plataforma de otro, tus blocklists viven dentro de su producto. Puedes usar los tipos de reglas que ofrece, con el nivel de detalle que permite y con las integraciones de terceros que ha elegido. Si un cliente pregunta por qué un anuncio se publicó en algún sitio, la respuesta depende de logs que quizá no puedas ver completos.

Ser dueño de la plataforma traslada esas decisiones a tu lado de la mesa. Tú decides qué reglas se aplican a toda la plataforma, qué fuentes de inventario se aprueban o rechazan, qué partners de verificación se conectan y durante cuánto tiempo se conservan los datos de ubicaciones. Puedes crear tu propia blocklist compartida a partir de todo lo que han aprendido tus campañas y aplicarla a cada cliente desde el primer día.

Control de brand safety Alquilar un seat Ser dueño de la plataforma
Blocklist a nivel de plataforma La define el proveedor, a menudo no es visible La defines y mantienes tú
Aprobar o rechazar fuentes de inventario Limitado a lo que expone el proveedor Control total sobre a qué partners y zonas compras
Integraciones de verificación Elección del proveedor Elección tuya
Registro de auditoría de cambios Parcial Completo, para todos los usuarios y administradores

La plataforma DSP de AdTech Europe incluye control de inventario a nivel de administrador para aprobar, rechazar o priorizar zonas de publishers, capas antifraude configurables para partners de tráfico y campañas, integraciones antifraude como IAS y análisis semántico, whitelisting de dominios y logs de auditoría de cada acción de usuarios y administradores. Son los elementos básicos de una política de brand safety que controlas tú mismo.

¿Listo para controlar el brand safety en una plataforma propia?

Imagen del dashboard de AdTech Europe que promociona un DSP propio con control total sobre las blocklists de brand safety y el inventario.

AdTech Europe proporciona tecnología de demand-side platform de nivel enterprise a agencias, ad networks, equipos de compra de medios y emprendedores de adtech que quieren ser dueños de su stack de compra en lugar de alquilarlo. Todos los planes incluyen escalado ilimitado de QPS, más de 1.000 integraciones con SSP, branding white-label y actualizaciones gratuitas de por vida, para que tus reglas de brand safety, tus decisiones de inventario y tus listas de clientes sigan bajo tu control.

A octubre de 2026, las opciones son un White Label DSP gestionado por $500 al mes sin cuota de alta, una DSP License por $25,000 en un único pago o una DSP Acquisition completa con propiedad total del código fuente por $50,000 en un único pago, con planes de pago a plazos disponibles en los dos niveles de propiedad. Las cifras actualizadas están siempre en la página de precios del DSP. Para planificar una configuración de brand safety adaptada a tus propios clientes e inventario, agenda una reunión de estrategia programmatic con nuestro equipo.

Preguntas frecuentes

¿Qué es una blocklist de brand safety?

Una blocklist de brand safety es un conjunto de reglas que indica a una plataforma de compra dónde no deben aparecer los anuncios de un anunciante. Las reglas pueden dirigirse a categorías de contenido, dominios web, apps o palabras clave, y la plataforma las comprueba antes de cada puja.

¿Cuál es la diferencia entre una blocklist y una allowlist?

Una blocklist permite a la plataforma pujar en todas partes excepto en los lugares de la lista. Una allowlist solo le permite pujar en los lugares de la lista. Las blocklists mantienen un alcance elevado; las allowlists ofrecen una protección más sólida para las marcas sensibles.

¿El brand safety es lo mismo que la prevención del fraude publicitario?

No. La prevención del fraude comprueba si una impresión es real y está descrita correctamente. El brand safety comprueba si una impresión real se encuentra en un lugar adecuado para el anunciante. Las campañas necesitan ambas cosas.

¿Por qué el bloqueo por palabra clave reduce tanto el alcance?

Las palabras sueltas aparecen en muchos contextos seguros. Una palabra como «shooting» bloquea noticias de sucesos, pero también páginas de deportes y de fotografía. Utilizar frases exactas, listas breves y señales contextuales mantiene la protección y hace perder mucho menos inventario.

¿De dónde obtiene un DSP las categorías de contenido?

Los vendedores pueden incluir códigos de categoría de contenido de IAB Tech Lab para el sitio, la sección y la página en la bid request de OpenRTB. Los compradores también pueden usar servicios contextuales de terceros que clasifican la página con independencia del vendedor.

¿Con qué frecuencia se debe revisar una blocklist?

Una revisión mensual es adecuada para la mayoría de los anunciantes, y una semanal para los sensibles. Cada revisión debe añadir las ubicaciones problemáticas detectadas en los informes y eliminar las entradas cuyo motivo ya no sea válido.