Ad server para publishers e marketplaces: use o Google Ad Manager, licencie um ou construa o seu

Um ad server é o software que decide qual anúncio ocupa um espaço no seu site ou app e depois conta o resultado. Você pode usar o Google Ad Manager, pagar por um ad server hospedado como AdButler ou Kevel, operar um de código aberto como o Revive Adserver ou construir o seu. A escolha depende principalmente de quem define as regras de seleção do anúncio e de quem guarda os registros brutos do que foi exibido. O Google também vai mudar a forma como o Ad Manager conta banners a partir de 17 de fevereiro de 2027, então os publishers que o usam devem revisar seus contratos baseados em impressões antes dessa data.

O que faz um ad server?

Cada vez que uma página ou um app tem um espaço de anúncio a preencher, ele pergunta ao ad server o que mostrar. O ad server descarta os anúncios que não passam na segmentação ou que atingiram o limite de frequência e escolhe um dos restantes por prioridade e preço. Em seguida, registra a impressão, que é um anúncio contado como entregue uma vez. Esse registro vira o relatório que o publisher envia aos anunciantes e, muitas vezes, a base da fatura.

O Google Ad Manager dá a cada tipo de line item (uma reserva dentro do ad server) um número de prioridade, e a sua página de ajuda diz “Quanto menor o número, maior a prioridade.” Um line item de Patrocínio, vendido como uma fatia do tráfego, fica em 4. Os Standard, vendidos como um número fixo de impressões, recebem 6, 8 ou 10, e os House, que levam as suas próprias promoções, recebem 16. Todas as fontes deste artigo foram abertas em 9 de novembro de 2026.

Qual é a diferença entre um ad server e uma SSP ou uma DSP?

Uma demand-side platform (DSP) compra espaço publicitário para os anunciantes, e uma supply-side platform (SSP) oferece o espaço de um publisher a muitos compradores ao mesmo tempo. O ad server fica mais perto do publisher e, na maioria dos arranjos, tem a última palavra sobre cada espaço, inclusive sobre acordos que o seu próprio time comercial fechou com anunciantes.

No header bidding, a página pede lances a várias SSPs e só depois chama o ad server. O Prebid.org, que publica software gratuito de header bidding, diz que ele é “usado com mais frequência como uma biblioteca de header bidding” e descreve assim esse arranjo: “O Prebid coleta lances antes de o ad server ser chamado, e o ad server toma a decisão final.” Acrescenta que o Prebid também pode atuar como camada de decisão na página e escolher ele mesmo o anúncio vencedor. O Ad Manager deixa compradores dos leilões do próprio Google competirem com as suas outras reservas pelo CPM, o preço por mil impressões. A página de ajuda diz que o Ad Exchange ou o AdSense “só vão entregar se puderem oferecer um CPM maior do que os seus outros line items do Ad Manager”.

Anunciantes costumam operar um segundo ad server próprio para acompanhar onde os anúncios rodaram, então uma campanha geralmente produz dois conjuntos de números. Um exemplo é o Campaign Manager 360 do Google, que a página de ajuda chama de “um sistema de gestão de anúncios baseado na web para anunciantes e agências.”

O que fazem a segmentação, os limites de frequência e o pacing?

• A segmentação decide quem pode ver um anúncio. As regras costumam usar país, dispositivo e seção do site, além de listas de audiência que você possui. Um marketplace pode segmentar por termo de busca ou por categoria de produto.
• Limites de frequência restringem quantas vezes uma pessoa vê um anúncio. A página de ajuda do Ad Manager diz: “Se um limite baseado em tempo for definido sem um identificador disponível, o line item não é elegível para veiculação.” Ele também “aplica limites de frequência com base no código servido, por padrão”, ou seja, quando o código do anúncio é enviado, quer o anúncio tenha aparecido ou não.
• Na UE, os limites também dependem de consentimento. A documentação da Kevel diz “Sob o GDPR, o limite de frequência não é ativado para quem vê anúncios na União Europeia, a menos que o consentimento de rastreamento seja enviado na requisição.”
• O pacing distribui uma reserva ao longo das suas datas. O Ad Manager “determina o ritmo de entrega (pacing) do line item para garantir que ele atinja a sua meta”. A configuração Evenly aplica um parâmetro de 5%, então uma meta de 1.000 impressões por dia mira 1.050 no primeiro dia.
• Quando um limite ou uma meta de pacing se comporta de forma estranha, você precisa dos eventos brutos para entender por quê, então pergunte o que é registrado para cada impressão e por quanto tempo.

Quais são as quatro formas de ter um ad server?

• Google Ad Manager. O Google opera o software, e você configura espaços de anúncio e reservas na interface dele.
• Um ad server hospedado. Um fornecedor como AdButler, Kevel, Broadstreet ou Equativ opera o software e cobra uma mensalidade, por requisições de anúncio ou por contrato.
• Um ad server de código aberto. Você instala um software como o Revive Adserver nos seus próprios servidores e o mantém funcionando.
• O seu próprio ad server. Os seus desenvolvedores, ou uma empresa que você contrate, escrevem o sistema que toma a decisão e conta o resultado.

O Google Ad Manager é gratuito, e o que abrimos mão ao usá-lo?

A versão gratuita do Ad Manager não custa nada até um limite mensal definido pela localização do publisher, e coloca negócios diretos e a demanda de anúncios do próprio Google em uma única decisão. A página de cobrança do Google indica 90 milhões de impressões sem vídeo para publishers localizados nos Estados Unidos, Canadá, Austrália e Nova Zelândia. O número é de 200 milhões em uma longa lista de países que inclui o Reino Unido, a Alemanha e a Índia, e de 150 milhões nos demais. Os blocos de anúncio em vídeo têm “um limite de 800.000 impressões por mês, independentemente da localização.” Fora do inventário de apps e de vídeo, quando você usa o Google Publisher Tag, “o Ad Manager cobra tanto as impressões preenchidas quanto as não preenchidas”, e o Google diz que deixar o Ad Exchange ou o AdSense competir pode “garantir que as impressões monetizadas pelo Ad Exchange ou pelo AdSense não sejam cobradas.”

Acima desses números, o Google exige que os publishers “celebrem um contrato pago”. Um publisher que continua excedendo os limites sem adicionar uma forma de pagamento pode ser colocado em modo somente leitura, diz a página de cobrança. Mais tarde pode ser suspenso, “e, nesse momento, a veiculação dos seus anúncios pode cessar.” O Google diz que a seção Cobrança da sua conta do Ad Manager mostra as tabelas de preços da sua região, então leia-as antes de ultrapassar o limite.

Você também abre mão de algum controle:

• Registros brutos custam à parte e expiram. Os arquivos Data Transfer do Ad Manager “fornecem dados não agregados, no nível de evento, das suas campanhas de anúncios”. Eles “têm custo adicional”, e “Os arquivos Data Transfer com mais de 60 dias são excluídos do Ad Manager.” Copie-os para o seu próprio armazenamento de forma periódica.
• O Google define as regras de seleção e de contagem dos anúncios. O tipo e a prioridade são “apenas um fator na seleção de anúncios”, e o sistema do Google toma o resto da decisão. O método de contagem muda em fevereiro de 2027.
• Sair dá trabalho. As suas reservas e os seus espaços de anúncio vivem no Ad Manager e precisam ser configurados de novo em outro lugar, e o código de anúncio das suas páginas precisa ser substituído.

O que os processos antitruste contra o Google mudam para os publishers?

Para um publisher que escolhe um ad server, a pergunta prática é se, e quando, os ad servers concorrentes recebem lances do AdX, a ad exchange do Google. O comunicado de imprensa da Comissão Europeia de 5 de setembro de 2025 anunciou uma multa de € 2,95 bilhões contra o Google, citando “Favorecer a sua própria ad exchange AdX no processo de seleção de anúncios conduzido pelo seu ad server de publishers dominante, o DFP”. O Google disse em 14 de novembro de 2025 que discorda da decisão e que “vai recorrer.” A AdExchanger descreve o DFP e o AdX como agrupados no Google Ad Manager. O Departamento de Justiça dos EUA disse em 17 de abril de 2025 que um tribunal federal havia decidido que o Google “violou a lei antitruste ao monopolizar os mercados de publicidade digital da web aberta”.

O PPC Land informa que, em 2 de setembro de 2026, o juiz dos EUA decidiu que o Google “não será obrigado a vender a sua exchange AdX nem o seu ad server de publishers DFP”. A AdExchanger informou em 16 de setembro de 2026 que “o AdX também deve enviar lances em tempo real a ad servers de publishers concorrentes nos mesmos termos que concede ao DFP”. Em 2 de outubro de 2026, as duas partes apresentaram uma proposta de sentença final com as suas divergências ainda marcadas no texto. A AdExchanger informou em 5 de outubro de 2026 que o Departamento de Justiça quer a conexão com ad servers concorrentes em até seis meses após a entrada em vigor da ordem e o Google quer doze, e que, assim que o juiz assinar, “um prazo de 60 dias começará a correr antes de qualquer coisa entrar em vigor”. Uma cópia pública do andamento do processo, atualizada pela última vez em 29 de outubro de 2026, não lista nenhuma petição posterior. O Digiday informa que o Google pretende contestar a decisão sobre a responsabilidade.

Quando um ad server hospedado atende melhor?

Um ad server hospedado atende melhor quando o produto do Google é mais do que uma equipe comercial pequena precisa, ou quando os seus desenvolvedores querem colocar anúncios por meio de uma API. Na ponta mais simples, a página inicial da Broadstreet o chama de “The Ad Manager for Small Publishers”, e a página de preços indica um valor inicial de US$ 299 por mês. Peça para ver um relatório que você realmente enviaria a um anunciante.

Compare os preços com os adicionais incluídos. A página de preços da AdButler dimensiona os planos por requisições de anúncio e vende vários recursos à parte. A segmentação aparece como adicional a partir de US$ 275 por mês mais US$ 0,005 de CPM, e o Log Level Data, “dados granulares sobre cada requisição de anúncio”, a partir de US$ 1.100 por mês mais US$ 0,01 de CPM.

A Kevel funciona de outro modo. Ela é vendida como uma API, uma forma de o seu software chamar o de outra empresa, então os seus desenvolvedores a chamam a partir das suas páginas e apps. A página inicial diz “A Kevel é baseada em API, então tudo é totalmente flexível para se adequar à sua experiência de usuário.” A mesma página lista o Kevel Console, que, segundo ela, “facilita para os anunciantes planejar, comprar e gerenciar as suas próprias campanhas”, então pergunte quais telas vêm com o produto e quais o seu time precisa construir.

A Kevel se define como uma “plataforma de commerce media” e tem seções para varejistas, marketplaces, fintechs, marcas de viagem e apps de entrega, então um publisher de notícias ou de conteúdo deve perguntar se ela serve. Nenhum preço aparece nessa página, então espere uma conversa com o comercial.

Um fornecedor também pode operar uma SSP ao lado do ad server. A página da Equativ para publishers lista os dois juntos no seu produto de connected TV. Pergunte como eles são mantidos separados e confira a resposta com os seus próprios números.

Quando faz sentido um ad server de código aberto?

Um ad server de código aberto faz sentido quando você já tem gente capaz de cuidar dele. A página inicial do Revive Adserver diz “Download gratuito, uso gratuito.” O repositório no GitHub mostra a “licença GPL-2.0”.

A página de segurança do Revive lista três avisos até agora em 2026, o mais recente de 25 de junho de 2026. Alguém precisa aplicar cada atualização e manter os servidores no ar nos picos de tráfego. Se ninguém do seu lado vai fazer isso, o site do Revive oferece uma edição Hosted “com custos a partir de US$ 10 por mês”. Os fornecedores hospedados acima são a outra escolha.

Devemos construir o nosso próprio ad server?

Sim, se a decisão do anúncio fizer parte do seu produto, como em um marketplace que mostra listagens patrocinadas nos resultados de busca. Ali o anúncio e o resultado orgânico competem juntos no ranking, então a decisão precisa usar os seus próprios dados de relevância. Qualquer um destes também pode justificar uma construção:

• O seu espaço de anúncio é incomum, como telas nos seus próprios locais ou espaços dentro de um fluxo de reserva, e os produtos que você testou não conseguem contá-lo do jeito que os seus anunciantes precisam
• Contratos ou regras de dados mantêm a informação por trás de cada decisão dentro dos seus próprios sistemas
• Para anúncios dentro do seu próprio produto, as taxas no volume que você espera daqui a dois anos custariam mais do que um time para operar o seu próprio sistema, com plantão e relatórios auditados incluídos

Listagens patrocinadas também têm um caminho intermediário. A documentação da Kevel descreve um padrão que chama de Auction-as-a-Service, “em que você determina quais produtos ou listagens são elegíveis para exibição, e a Kevel executa o leilão, o pacing, o orçamento, o limite de frequência e o rastreamento sobre esse conjunto.” O artigo sobre redes de retail media trata desse arranjo.

Evite construir só para economizar a taxa de licença em anúncios display e de vídeo comuns de sites. Você estaria reescrevendo o fluxo de vendas diretas, o pacing, a previsão e os relatórios que os anunciantes contestam, e ainda precisaria de uma forma de chegar às ad exchanges. Uma disputa de contagem também é um mau motivo, já que um sistema novo só acrescenta mais um número para comparar. Mudanças de navegadores e de privacidade continuam chegando depois do lançamento, e cada uma exige alguém do seu lado para tratá-la.

Por que as contagens de impressões diferem entre ad servers?

Duas empresas contam a mesma campanha com sistemas diferentes, em momentos diferentes. O ponto de referência são as Desktop Display Impression Measurement Guidelines do Interactive Advertising Bureau (IAB) e do Media Rating Council (MRC), versão 7.1 de outubro de 2017. Elas dizem “O anúncio deve estar carregado e, no mínimo, ter começado a ser renderizado para ser contado como uma impressão de anúncio válida.” Contar no momento em que a página é servida “não é aceitável para contar impressões de anúncios”.

Essas diretrizes deixam em aberto se alguém poderia ver o anúncio, e dizem que o begin-to-render “não exige que nenhuma parte do anúncio esteja visível ou exibida na tela.”

Viewability é uma medida à parte. As Viewable Ad Impression Measurement Guidelines do MRC para desktop, versão 2.0 de agosto de 2015, contam um anúncio display como visível quando pelo menos 50% dos seus pixels estão à vista por um segundo contínuo, ou 30% para anúncios display de 242.500 pixels ou mais. Um anúncio em vídeo precisa de 50% à vista por dois segundos contínuos. O MRC tem diretrizes separadas para mobile. Combine qual das duas o seu contrato vende.

A página de ajuda do Google sobre discrepâncias em relatórios lista causas comuns, e elas valem para qualquer caminho:

• As regras de contagem diferem. “Os ad servers têm métodos diferentes para contar impressões e filtrar impressões inválidas.” Impressões inválidas vêm de bots e de outro tráfego que não deveria ser cobrado.
• O criativo, que é o próprio arquivo do anúncio, demora a aparecer. “O intervalo entre a requisição inicial do line item e o aparecimento do criativo pode levar a contagens diferentes.”
• Bloqueadores de anúncios podem impedir um anúncio “depois de o Ad Manager já ter contado uma impressão.”
• Os relatórios precisam cobrir as mesmas datas e o mesmo fuso horário antes de você compará-los.
• Em uma campanha pequena, poucas impressões podem parecer uma grande diferença. “Uma pequena discrepância numérica pode causar uma grande discrepância percentual se o line item entregou poucas impressões no total.”

A mesma página diz que, quando um ad server entrega line items hospedados por terceiros, “variações de até 20% nas campanhas são comuns”. Com o tipo de criativo tag do Campaign Manager 360, diz que “o Ad Manager coordena a contagem de impressões para reduzir as discrepâncias a até 2%.” A própria página de ajuda do Campaign Manager 360 dá a mesma faixa: “Discrepâncias de até 20% são consideradas normais.”

O que muda quando o Google passar para o begin-to-render em fevereiro de 2027?

A partir de 17 de fevereiro de 2027, a medição de impressões do inventário display no Ad Manager e no AdSense “passará da metodologia count-on-download (COD) para a begin-to-render (BTR)”, segundo a página de ajuda do Google. O count-on-download registra uma impressão quando um anúncio começa a ser baixado. O begin-to-render espera até que o criativo tenha carregado e começado a ser renderizado. Os inventários nativo, de app e de vídeo já estão em conformidade, então a mudança alcança os banners na web, na web mobile e na connected TV.

O Google avisa: “você pode notar uma queda no total de impressões display”. O mesmo tráfego passará a render menos impressões para vender. Uma reserva de um número fixo de impressões vai usar mais do seu tráfego para atingir a meta e pode ficar aquém onde o espaço é escasso. Antes de renovar qualquer contrato baseado em impressões, rode o relatório sugerido pelo Google, que compara as impressões do seu ad server com as impressões begin-to-render, a partir de 12 de agosto de 2026.

A mudança deve reduzir as diferenças em relação aos compradores, já que o Google diz que ela “foi desenhada para reduzir as discrepâncias com as impressões contadas pelos seus parceiros anunciantes e por provedores de medição de terceiros”. Se você usa outro ad server, pergunte ao fornecedor por qual método ele conta hoje.

De quem é o número que decide a fatura?

O contrato decide. O IAB publicou novos termos para compras diretas de anúncios em maio de 2026, e o seu Direct Buy Addendum versão 1.0 diz que as partes “designarão a Controlling Measurement no pedido”. Se um pedido não indica nenhuma, “o ad server ou sistema de medição que renderiza o anúncio servirá como a Controlling Measurement para fins de reconciliação e faturamento”, a menos que as partes combinem outra coisa por escrito.

Os antigos Standard Terms and Conditions da 4A's e do IAB, versão 3.0 de 2010, ainda estão no ar e cobrem compras de mídia de um ano ou menos. A Seção XIII desse modelo dá a “Controlling Measurement” a um ad server certificado como em conformidade com as diretrizes de medição do setor. Se ambos estiverem em conformidade, prevalece o ad server de terceiros do anunciante, desde que ele dê ao publisher uma “interface de relatórios diária e automatizada”. Se nenhum estiver em conformidade, ou se essa condição não puder ser cumprida, prevalece o ad server do publisher, a menos que as partes combinem outra coisa por escrito.

Os dois modelos iniciam uma reconciliação quando as contagens diferem em mais de 10% no período da fatura e a contagem que prevalece é a menor. Eles divergem sobre o que acontece depois. Na versão 3.0, se a reconciliação falhar, a agência pode tratar a diferença como entrega abaixo do contratado ou pagar pela contagem que prevalece “mais um ajuste de 10% para cima na entrega.” O adendo de 2026 não traz um valor fixo: as partes podem combinar um ajuste, usar a outra contagem ou tratar a diferença como entrega abaixo do contratado. O seu contrato pode dizer algo diferente, então indique a contagem que prevalece em cada pedido e verifique se o ad server escolhido consegue gerar os relatórios que ela exige.

O que devemos perguntar a um fornecedor ou a uma empresa que o construiria?

• Em que momento o seu sistema conta uma impressão, e isso segue as diretrizes do IAB e do MRC para cada formato que vendemos?
• Algum órgão externo auditou a sua contagem, e podemos ver o relatório atual?
• Podemos exportar registros no nível de evento, a que custo, e por quanto tempo vocês os guardam?
• O que um limite de frequência faz quando a pessoa não tem identificador ou não deu consentimento?
• Como vocês filtram o tráfego inválido, e como veríamos o que foi removido?
• Se vocês também operam uma SSP ou vendem demanda de anúncios, como evitam que esse negócio influencie qual anúncio vence?
• Vocês podem mostrar isso funcionando hoje em um site ou app em produção?

Onde a amBrain se encaixa?

A amBrain publica este blog e oferece este tipo de trabalho. Nas suas próprias palavras: “A amBrain constrói ad servers: segmentação, limite de frequência e relatórios.” Uma segunda linha trata da parte de contagem: “A amBrain constrói pipelines de analytics de eventos para ad tech: coleta, processamento e relatórios de eventos de impressão e de clique.”

A amBrain constrói software desde 2019. Sobre como trabalha com os clientes, ela diz: “Três formatos: entrega completa, time dedicado ou engenheiros embarcados no seu time.” A frase dela sobre propriedade é: “O cliente mantém a propriedade integral do produto e do código, exceto dos nossos componentes reutilizáveis.” Peça a lista desses componentes, nome por nome, antes de assinar.

Este artigo não é um estudo de caso e não descreve trabalho para nenhum cliente. As linhas acima não citam nenhum cliente, e nada aqui diz que a amBrain construiu um ad server para alguma empresa. O artigo não traz preços nem prazos da amBrain e não alega relação com nenhum fornecedor que cita. Google, Prebid.org, Equativ, Broadstreet, AdButler, Kevel, Revive Adserver, o IAB, o MRC, a 4A's, a Comissão Europeia e o Departamento de Justiça dos EUA são citados a partir das suas próprias páginas, a petição judicial a partir de uma cópia pública do andamento do processo, e PPC Land, AdExchanger e Digiday como reportagens da imprensa.

Também não é aconselhamento jurídico. Peça a um advogado que leia os contratos de fornecedores e os termos de publicidade, e verifique em que pé estão os processos do Google antes de assinar. Se a amBrain estiver na sua lista de candidatas, faça a ela as mesmas perguntas que faria a qualquer outra empresa.