Blocklists de brand safety: como funcionam os bloqueios por categoria, domínio e palavra-chave

Todo comprador de mídia programática já viu isso acontecer pelo menos uma vez. O anúncio de um cliente aparece ao lado de uma matéria da qual nunca deveria ter chegado perto, alguém tira um print e a conversa deixa de ser sobre CPMs. A campanha pode ter batido todas as metas de performance, mas nada disso importa quando a marca se sente exposta.

A compra em open auction torna isso mais difícil do que parece. Sua plataforma pode avaliar milhares de bid requests por segundo, vindos de sites e apps que ninguém do seu time jamais visitou. A única forma de manter os anúncios longe dos lugares errados nessa velocidade é definir as regras com antecedência e deixar a plataforma de compra aplicá-las antes de cada lance. Essas regras são as suas blocklists de brand safety.

Este guia explica o que é uma blocklist de brand safety, como funcionam na prática os bloqueios por categoria, domínio, app e palavra-chave dentro de uma demand-side platform, onde cada método falha, como as blocklists se comparam às allowlists e como criar e manter uma lista que proteja os clientes sem sufocar o alcance das campanhas.

O que é uma blocklist de brand safety?

Uma blocklist de brand safety é um conjunto de regras que indica a uma plataforma de compra onde os anúncios de um anunciante não podem ser veiculados. Cada regra descreve algo que o comprador consegue identificar em um bid request: uma categoria de conteúdo, um domínio de site, um app mobile ou palavras que aparecem na página ou em seus metadados. Quando uma impressão recebida corresponde a uma regra, a plataforma não dá lance nela.

A palavra-chave aqui é “antes”. Uma blocklist atua no pré-bid. Não é um relatório que você lê depois que o dinheiro já foi gasto. A verificação acontece nos poucos milissegundos entre a chegada do bid request e o momento em que sua plataforma decide se vai respondê-lo. Se você quiser ver exatamente quais campos essa decisão utiliza, nosso guia sobre o que um bid request contém percorre todo o objeto OpenRTB.

Brand safety também é diferente de prevenção a fraudes, embora os dois temas sejam frequentemente discutidos juntos. A prevenção a fraudes pergunta se a impressão é real: existe uma pessoa de verdade, em um dispositivo de verdade, no site que o vendedor declara? Brand safety parte do princípio de que a impressão é real e faz outra pergunta: este é um lugar onde este anunciante quer ser visto? Uma campanha precisa das duas coisas. Uma audiência totalmente humana no tipo errado de página continua sendo um problema, e uma página totalmente segura cheia de bots continua sendo dinheiro desperdiçado.

Os quatro tipos de bloqueio dentro de uma DSP

A maioria das plataformas de compra oferece quatro tipos de regras de bloqueio. Elas atuam em níveis diferentes de detalhe, e cada uma depende de uma parte diferente do bid request estar presente e correta.

Bloqueio por categoria

O bloqueio por categoria é a ferramenta mais abrangente. No OpenRTB, o vendedor pode descrever o conteúdo de um site ou app com códigos de categoria, geralmente extraídos da IAB Tech Lab Content Taxonomy. O request pode trazer categorias para o site inteiro, para a seção atual e para a página atual. Versões mais recentes do protocolo também incluem um campo que indica de qual versão da taxonomia os códigos vêm, para que comprador e vendedor interpretem o mesmo código da mesma forma.

Do lado da compra, você seleciona as categorias que o anunciante deve evitar e a plataforma ignora qualquer request que traga uma delas. É rápido e fácil de configurar. O ponto fraco é que quem escolhe o rótulo é o vendedor. Um publisher interessado em vender mais impressões tem pouco motivo para marcar as próprias páginas como sensíveis, e muitos requests chegam com uma única categoria genérica para o site inteiro ou sem categoria nenhuma. O bloqueio por categoria é um bom primeiro filtro, não uma solução completa.

Bloqueio por domínio e por app

O bloqueio por domínio é a ferramenta mais precisa que você tem. Se um site já causou problema uma vez, você adiciona o domínio dele e sua plataforma nunca mais dará lance ali. O bloqueio por app faz o mesmo para apps mobile e de connected TV, usando o identificador de bundle ou da loja do app em vez de um domínio.

Essa precisão tem dois limites. Primeiro, uma lista de domínios só cobre os lugares que você já conhece, e novos sites surgem todos os dias. Segundo, o domínio no request é uma declaração feita pelo vendedor. Inventário fraudulento pode declarar um domínio respeitável enquanto exibe o anúncio em outro lugar. É por isso que o bloqueio por domínio deve sempre vir acompanhado de verificações da supply chain. Nosso guia sobre ads.txt, app-ads.txt e sellers.json explica como os compradores verificam se um vendedor está de fato autorizado a vender determinado domínio ou app.

Bloqueio por palavra-chave

O bloqueio por palavra-chave procura palavras ou expressões específicas ligadas à impressão. Na forma mais simples, a plataforma analisa a URL da página e eventuais campos de palavras-chave do request. Configurações mais avançadas usam um serviço de análise contextual que lê o texto real da página, muitas vezes antes do leilão, e retorna um sinal que a plataforma de compra pode usar.

As palavras-chave pegam o que as categorias deixam passar, como uma notícia urgente em um site que, de modo geral, é seguro. Mas também são a forma mais fácil de bloquear demais. Uma lista com palavras como “shooting”, “attack” ou “crash” vai bloquear reportagens policiais, mas também a cobertura de basquete, notícias de cibersegurança e comentários sobre o mercado de ações. As listas de palavras-chave exigem mais cuidado do que qualquer outro tipo de regra, e voltaremos a esse ponto mais adiante.

Blocklists vs. allowlists: qual usar?

Uma blocklist diz “dê lance em todo lugar, exceto aqui”. Uma allowlist, também chamada de lista de inclusão ou whitelist, diz “dê lance somente aqui”. São abordagens opostas para o mesmo problema, e a maioria das equipes de compra mais maduras usa as duas, em campanhas diferentes.

Um modelo comum é manter uma blocklist compartilhada que vale para todas as campanhas da plataforma e, por cima dela, adicionar allowlists para os clientes que precisam de um controle mais rígido. Um banco ou uma marca infantil pode rodar apenas em uma lista aprovada de algumas centenas de domínios. Um anunciante de performance que vende um produto de massa pode rodar em open supply com a blocklist compartilhada e uma lista curta específica do cliente.

Como a verificação da blocklist acontece antes do lance

Do ponto de vista da plataforma, brand safety é apenas mais um filtro no pipeline de lances. A ordem das operações é a seguinte:

1. O request chega. Uma SSP ou exchange envia um bid request com o domínio ou app, a URL da página, eventuais códigos de categoria, dados do dispositivo e a supply chain.
2. A plataforma verifica as regras compartilhadas. Os bloqueios de toda a plataforma são aplicados primeiro: domínios, apps, vendedores e categorias sabidamente ruins, que nenhuma campanha deveria comprar.
3. Cada campanha elegível aplica as próprias regras. Blocklists, allowlists e regras de palavras-chave no nível do cliente eliminam as campanhas que não podem dar lance nessa impressão.
4. Sinais opcionais de terceiros são adicionados. Se houver um serviço contextual ou de verificação conectado, o veredito pré-bid dele é usado como mais uma regra.
5. A plataforma dá lance ou passa. Se ainda houver alguma campanha elegível, ela precifica a impressão e responde. Caso contrário, não envia lance, e nenhum dinheiro é gasto.
6. Os resultados alimentam as listas. Relatórios de placements e verificações pós-bid mostram onde os anúncios realmente rodaram, e tudo o que não deveria ter passado é adicionado às listas.

Daí vêm duas consequências práticas. As regras compartilhadas devem rodar antes das regras de campanha, porque um request que nenhuma campanha pode comprar deve ser descartado o mais cedo e da forma mais barata possível. E toda verificação precisa ser rápida. Uma plataforma de compra que demora demais filtrando vai sofrer timeout e perder leilões que queria ganhar, por isso as regras de brand safety normalmente ficam em memória como consultas simples, em vez de serem avaliadas do zero a cada request.

Também vale saber que os publishers fazem bloqueios no sentido oposto. O OpenRTB permite que o vendedor envie listas de categorias de anunciantes, domínios de anunciantes e apps que ele não aceita. Sua plataforma precisa respeitar essas listas também, ou os lances simplesmente serão rejeitados. Brand safety é um acordo de mão dupla, aplicado no mesmo request.

Erros comuns em blocklists

A maioria dos problemas de brand safety não vem da falta de uma lista. Vem de listas que foram configuradas uma vez e nunca mais revisadas. Estes são os erros que mais vemos:

• Bloquear demais com palavras-chave genéricas. Listas longas de palavras-chave copiadas de campanhas antigas eliminam silenciosamente grandes volumes de inventário seguro, principalmente de notícias. O resultado é menos alcance, preços mais altos e menos publishers de qualidade no mix.
• Confiar apenas nas categorias declaradas. Se quem escolhe o rótulo é o vendedor, um bloqueio por categoria só protege você dos vendedores que classificam com honestidade.
• Bloquear o domínio, mas não o caminho. Um domínio pode ser vendido diretamente, por vários revendedores ou ser totalmente falsificado. Verificar quem está autorizado a vendê-lo importa tanto quanto o próprio domínio. Nosso guia sobre supply path optimization mostra como cortar rotas arriscadas para o mesmo inventário.
• Uma única lista para todos os clientes. Uma marca de games e uma marca farmacêutica têm definições muito diferentes do que é seguro. As listas compartilhadas devem cobrir o que ninguém compra; as listas de cliente devem cobrir o resto.
• Não registrar por que algo foi bloqueado. Sem um motivo e uma data ao lado de cada entrada, ninguém tem coragem de remover nada, e a lista só cresce.
• Ignorar apps e CTV. Equipes que montaram suas listas pensando na web muitas vezes esquecem que o inventário de apps e TV é identificado por bundle IDs, não por domínios, e precisa de entradas próprias.

Como criar e manter uma blocklist de brand safety

Uma boa blocklist é enxuta, específica, documentada e revisada. O processo a seguir funciona para agências e ad networks que operam muitos anunciantes em uma única plataforma.

1. Defina com a marca o que é inseguro

Comece pelo anunciante, não pela ferramenta. Pergunte quais temas são sempre inaceitáveis, quais são aceitáveis em alguns contextos e quais não são problema. Notícias pesadas sobre um conflito podem ser inaceitáveis para uma marca e combinar perfeitamente com uma oferta de assinatura de jornal. Registre as respostas por escrito para que a lista possa ser rastreada até uma decisão.

2. Crie uma camada-base compartilhada

No nível da plataforma, bloqueie o que nenhum cliente deveria comprar: conteúdo ilegal, conteúdo adulto quando esse não for o negócio do anunciante, domínios e apps sabidamente fraudulentos e vendedores que não passam nas verificações de supply chain. Essa camada raramente muda e protege todas as campanhas automaticamente.

3. Adicione camadas por cliente

Para cada anunciante, adicione as categorias, os domínios, os apps e uma lista curta e precisa de palavras-chave que reflitam a política dele. Prefira expressões exatas a palavras soltas e, quando a plataforma permitir, prefira sinais de categoria ou contextuais a palavras-chave.

4. Teste o custo em alcance

Antes de ativar uma lista nova, compare quantos requests ela elimina. Se uma lista de palavras-chave remover muito mais inventário do que o esperado, analise uma amostra das páginas bloqueadas. Com muita frequência, uma única palavra genérica é responsável pela maior parte da perda.

5. Revise com uma periodicidade definida

Estabeleça uma revisão regular: mensal para a maioria das equipes e semanal para anunciantes sensíveis. Adicione novos placements problemáticos a partir dos relatórios de placements e do feedback dos clientes. Remova entradas cujo motivo não se aplica mais. Mantenha um histórico de auditoria de quem alterou o quê, e quando, para que cada decisão possa ser explicada ao cliente.

Brand safety caminha ao lado da qualidade de tráfego, e não no lugar dela. Se você quiser se aprofundar no lado das fraudes, nossos artigos sobre por que a qualidade de tráfego deve ser sua prioridade número 1 e sobre proteção contra ad fraud e tráfego inválido cobrem a outra metade do problema.

Por que ter a própria plataforma muda o brand safety

Quando você compra pela plataforma de outra empresa, suas blocklists ficam dentro do produto dela. Você pode usar os tipos de regra que ela oferece, no nível de detalhe que ela permite, com as integrações de terceiros que ela escolheu. Se um cliente perguntar por que um anúncio rodou em determinado lugar, a resposta depende de logs que talvez você não consiga ver por completo.

Ter a própria plataforma traz essas decisões para o seu lado da mesa. Você decide quais regras valem para toda a plataforma, quais fontes de inventário são aprovadas ou rejeitadas, quais parceiros de verificação estão conectados e por quanto tempo os dados de placement são guardados. Você pode montar sua própria blocklist compartilhada com tudo o que suas campanhas aprenderam e aplicá-la a todos os clientes desde o primeiro dia.

A plataforma DSP da AdTech Europe inclui controle de inventário no nível de admin para aprovar, rejeitar ou priorizar zonas de publishers, camadas antifraude configuráveis por parceiro de tráfego e por campanha, integrações antifraude incluindo IAS e análise semântica, whitelisting de domínios e logs de auditoria de todas as ações de usuários e admins. Esses são os pilares de uma política de brand safety controlada por você.

Pronto para controlar o brand safety em uma plataforma que é sua?

A AdTech Europe fornece tecnologia de demand-side platform de nível enterprise para agências, ad networks, equipes de compra de mídia e empreendedores de adtech que querem ser donos do seu stack de compra em vez de alugá-lo. Todos os planos incluem escalabilidade ilimitada de QPS, mais de 1.000 integrações com SSPs, branding white-label e upgrades gratuitos vitalícios, para que suas regras de brand safety, suas escolhas de inventário e suas listas de clientes fiquem sob seu controle.

Em outubro de 2026, as opções são uma White Label DSP gerenciada por $500 por mês, sem taxa de setup, uma DSP License por $25,000 em pagamento único ou uma DSP Acquisition completa, com propriedade total do código-fonte, por $50,000 em pagamento único, com opção de parcelamento nos dois planos de propriedade. Os valores atualizados estão sempre na página de preços da DSP. Para planejar uma estrutura de brand safety pensada para seus próprios clientes e inventário, agende uma reunião de estratégia programática com nossa equipe.

Perguntas frequentes

O que é uma blocklist de brand safety?

Uma blocklist de brand safety é um conjunto de regras que indica a uma plataforma de compra onde os anúncios de um anunciante não podem aparecer. As regras podem ter como alvo categorias de conteúdo, domínios de sites, apps ou palavras-chave, e a plataforma as verifica antes de cada lance.

Qual é a diferença entre uma blocklist e uma allowlist?

Uma blocklist permite que a plataforma dê lance em todo lugar, exceto nos locais listados. Uma allowlist permite que ela dê lance apenas nos locais listados. Blocklists mantêm o alcance alto; allowlists oferecem proteção mais forte para marcas sensíveis.

Brand safety é a mesma coisa que prevenção a ad fraud?

Não. A prevenção a fraudes verifica se uma impressão é real e está descrita corretamente. O brand safety verifica se uma impressão real está em um lugar adequado para o anunciante. As campanhas precisam das duas coisas.

Por que o bloqueio por palavra-chave reduz tanto o alcance?

Palavras soltas aparecem em muitos contextos seguros. Uma palavra como “shooting” bloqueia notícias policiais, mas também páginas de esportes e fotografia. Usar expressões exatas, listas curtas e sinais contextuais mantém a proteção com uma perda de inventário muito menor.

De onde uma DSP obtém as categorias de conteúdo?

Os vendedores podem incluir no bid request OpenRTB códigos de categoria de conteúdo da IAB Tech Lab para o site, a seção e a página. Os compradores também podem usar serviços contextuais de terceiros que classificam a página de forma independente do vendedor.

Com que frequência uma blocklist deve ser revisada?

Mensalmente atende à maioria dos anunciantes, e semanalmente atende aos mais sensíveis. Cada revisão deve adicionar os placements problemáticos encontrados nos relatórios e remover as entradas cujo motivo não se aplica mais.