Mediação de anúncios mobile para os seus apps ou a sua rede de anúncios: usar uma plataforma de mediação, licenciar uma ou construir a sua própria

A mediação de anúncios é um código dentro do app que pede um anúncio a várias fontes de anúncios toda vez que o app tem um espaço para preencher. Em seguida, ela tenta exibir o que paga mais. Uma fonte de anúncios é qualquer rede ou exchange capaz de fornecer anúncios. Um publisher de apps ou uma rede de anúncios in-app pode usar uma plataforma pronta, como Google AdMob, AppLovin MAX ou Unity LevelPlay. Também pode licenciar o produto de um fornecedor e operá-lo com a própria marca (white-label) ou construir uma camada de mediação própria. A escolha depende principalmente do que você precisa que seja seu. Depende também de o seu time conseguir manter um SDK, o pacote de código que exibe os anúncios, atualizado em todos os apps.

O que a mediação faz dentro de um app?

Um app exibe anúncios por meio de um SDK (software development kit, ou kit de desenvolvimento de software), um pacote de código que os desenvolvedores adicionam ao app. Com a mediação, um único SDK fica no comando. Ele chama várias fontes de anúncios por meio de adaptadores, pequenos trechos de código que o conectam ao SDK próprio de cada rede.

A central de ajuda do AdMob, do Google, resume assim: “A mediação permite gerenciar em um só lugar as fontes de anúncios usadas para veicular anúncios nos seus apps.” A Unity descreve o LevelPlay como “uma solução de monetização que permite aos desenvolvedores de apps gerenciar e otimizar várias redes de anúncios com um único SDK.” Todas as fontes deste artigo foram consultadas em 6 de novembro de 2026.

Qual é a diferença entre o waterfall e o in-app bidding?

O waterfall é o método mais antigo. O publisher classifica as fontes de anúncios por eCPM, a receita por mil anúncios exibidos, e o SDK as consulta uma após a outra até que uma devolva um anúncio. O guia do AdMob diz: “A mediação em waterfall chama as fontes de anúncios uma a uma com base no eCPM médio que você define, e não no que a fonte de anúncios está disposta a pagar.”

O in-app bidding consulta todas as fontes de bidding no mesmo instante, e cada uma informa um preço para aquele anúncio específico. O mesmo guia diz: “As fontes de bidding dão lances em tempo real e competem em um único leilão, enquanto as fontes de waterfall são chamadas individualmente na ordem do seu eCPM, que é definido por você.”

Muitas configurações misturam os dois. Na configuração híbrida do AdMob, o lance vencedor ocupa um lugar no waterfall “de acordo com o valor de eCPM”, e as fontes de waterfall classificadas acima dele são chamadas primeiro.

A AppLovin chama o leilão do MAX de “primeiro preço” (first-price), o que significa que o vencedor paga o valor do próprio lance. Os lances chegam “pelo protocolo OpenRTB 2.5”. O OpenRTB é o padrão de bid requests do IAB Tech Lab, a entidade sem fins lucrativos que escreve padrões técnicos para a publicidade digital. Os lances precisam chegar dentro de um limite de tempo chamado tmax, e o “servidor de leilão do MAX os combina com as fontes de demanda sem bidding no waterfall do publisher.”

Quais são as três formas de operar a mediação?

• Usar uma plataforma de mediação pronta. Você adiciona aos seus apps o SDK dela e um adaptador para cada fonte de anúncios, e configura o waterfall e o bidding no painel dela. A plataforma roda o leilão.
• Licenciar um produto white-label. Um fornecedor licencia para você o SDK de mediação dele e o servidor por trás, com a sua marca. Os publishers instalam o SDK com o seu nome, e o fornecedor mantém o código.
• Construir a sua própria camada. O seu time, ou uma empresa que você contrata, escreve o SDK, os adaptadores e o servidor de leilão, normalmente sobre padrões abertos como o OpenRTB. O código é seu, e você o opera.

Os caminhos podem ser combinados. O Prebid Mobile, que o Prebid.org chama de “uma biblioteca de código aberto para iOS e Android”, lista o AdMob e o MAX entre as plataformas de mediação que suporta. Ele obtém os lances de um Prebid Server, explicado no artigo sobre construir o seu próprio SSP (supply-side platform). Um SSP é o sistema que oferece o espaço publicitário de um publisher aos compradores.

Quando uma plataforma de mediação pronta é suficiente?

Use uma plataforma pronta quando a maioria destas condições for verdadeira:

• Você publica os seus próprios apps, e a receita de anúncios importa mais para você do que ser dono de tecnologia de anúncios
• Ninguém no seu time consegue manter um SDK atualizado a cada nova versão do iOS e do Android
• As redes de anúncios que você quer já têm adaptadores para a plataforma

Em troca, você aceita as regras da plataforma. Ela decide como o leilão funciona e quais bidders podem participar, e o SDK dela muda no ritmo que ela define. A empresa que opera o leilão também pode vender anúncios nele. Em 6 de novembro de 2026, a página do MAX da AppLovin dizia: “Todas as redes, incluindo a AppLovin, competem em igualdade de condições no leilão unificado.” Confira essa afirmação do fornecedor com os seus próprios dados de receita por fonte de anúncios.

Uma rede de anúncios ainda pode chegar aos publishers dentro de uma plataforma: o AdMob oferece eventos personalizados, que permitem ao publisher adicionar “uma fonte de anúncios que a mediação do AdMob não suporta”.

Quando faz sentido um produto licenciado ou white-label?

SDKs de mediação white-label são oferecidos a empresas que operam uma plataforma de anúncios, como uma rede de anúncios in-app ou um SSP que quer que os publishers enviem as requisições de anúncio diretamente para ele. Adote um quando:

• Os publishers devem instalar um SDK com o seu nome, para que as requisições de anúncio deles cheguem primeiro à sua plataforma
• Você tem equipe para cadastrar e dar suporte a publishers, mas não tem engenheiros para escrever e manter um SDK

A Teqblaze, um fornecedor de ad tech, mostra como esses produtos são descritos. A página de SDK dela chama a oferta de “um kit de desenvolvimento de software com marca própria” e diz que ele foi “feito para empresas que querem controlar a monetização de anúncios mobile sem desenvolver um SDK do zero.” Um post de junho de 2024 no blog da empresa diz que os publishers podem “enviar requisições diretamente para a plataforma da solução white-label”. A página do SDK não mostra preços. Essas são afirmações do próprio fornecedor.

A marca é sua, mas o código continua sendo do fornecedor. O Xcode é a ferramenta da Apple para criar apps. Quando um app adota uma nova versão de um SDK de terceiros, o Xcode verifica “se ela foi assinada pelo mesmo desenvolvedor”, então pergunte de quem é a assinatura que o seu SDK leva. Se o fornecedor parar de atualizar o SDK, cada publisher terá de lançar uma atualização do app para deixar de usá-lo.

Quando vale a pena construir a sua própria camada de mediação?

Construa quando pelo menos um destes pontos for verdadeiro:

• A mediação é o que você vende, por exemplo como uma rede de anúncios que roda leilões nos apps de muitos publishers
• Você precisa de regras que as plataformas testadas não conseguem aplicar, como os seus próprios preços mínimos para cada grupo de usuários. O preço mínimo (floor price) é o menor lance que você aceita.
• As taxas e as participações na receita já custam mais do que custaria um time operando o seu próprio sistema
• Os dados brutos de cada impressão (um anúncio exibido uma vez) precisam ficar nos seus próprios sistemas

O trabalho continua depois do lançamento. Cada rede continua atualizando o próprio SDK, e o adaptador precisa acompanhar. O AdMob lança um novo adaptador para cada nova versão do SDK de uma rede “depois de ser testado com esse novo SDK”. Na sua própria camada, é o seu time que faz esses testes, e cada rede precisa concordar em trabalhar com você sob um contrato próprio.

O que é nosso em cada caminho?

Verifique quatro pontos antes de assinar ou de começar a construir.

• Dados de impressão e de receita. As três plataformas informam a receita de cada impressão, e duas delas guardam esses dados por tempo limitado. O SDK do AdMob informa a receita “quando ocorre uma impressão”, e um comentário no código de exemplo do Google diz para enviá-la ao “seu servidor de analytics preferido diretamente dentro deste callback.” A User-Level Ad Revenue API da AppLovin, a interface dela para extrair esses dados, “tem uma janela de requisição de 45 dias.” A Unity mantém os dados em nível de impressão do LevelPlay de cada data “disponíveis por apenas 14 dias.” Copie esses dados para o seu próprio armazenamento todos os dias. Com um fornecedor white-label, garanta por escrito que os logs brutos são seus e podem ser exportados a qualquer momento.
• Relacionamentos com as fontes de anúncios. A página de configuração da Unity diz: “Você precisa ter uma conta ativa nessa rede para veicular o inventário de anúncios dela no seu app.” No MAX, os bidders enviam os lances ao servidor de leilão da AppLovin. Pergunte a cada plataforma quais conexões continuam sendo suas se você sair. Com um produto white-label, verifique em nome de quem estão os contratos com os compradores. No seu próprio sistema, você assina cada um deles.
• O SDK nos seus apps. Uma plataforma é dona do próprio SDK e das atualizações dele, e um fornecedor white-label é dono do próprio código. Se você construir, o código pode ser seu, junto com cada atualização e cada arquivo de privacidade.
• O custo de trocar. As diretrizes de revisão da App Store (App Review Guidelines) dizem que os apps não podem “baixar, instalar ou executar código que introduza ou altere recursos ou funcionalidades do app”. A política do Google Play diz que um app “não pode modificar, substituir ou atualizar a si mesmo por nenhum método que não seja o mecanismo de atualização do Google Play.” Um novo SDK de mediação só chega às pessoas em uma nova versão do app, e quem não atualiza continua com a antiga.

Algumas mudanças não exigem atualização do app. A ordem do waterfall e as configurações de bidding ficam no painel da plataforma. O arquivo app-ads.txt, que lista todas as empresas autorizadas a vender o espaço publicitário de um publisher, fica no site do desenvolvedor. O AdMob lembra aos publishers: “Se você usa outra rede de anúncios, lembre-se de adicionar essa rede ao seu arquivo app-ads.txt.”

Quais obrigações de loja de apps e de privacidade vêm com qualquer SDK de anúncios?

Essas obrigações valem em qualquer caminho. A Apple diz: “Os desenvolvedores são responsáveis por todo o código incluído nos seus apps.” As próprias páginas da Apple e do Google dizem:

• App Tracking Transparency (ATT). No iOS, a Apple diz que “você precisa receber a permissão do usuário por meio do framework App Tracking Transparency (ATT) para rastreá-lo ou acessar o identificador de publicidade do dispositivo dele.” A Apple define rastreamento como vincular dados do seu app a dados de apps, sites ou propriedades offline de outras empresas “para fins de publicidade direcionada ou de medição de publicidade”. Compartilhar dados do usuário ou do dispositivo com corretores de dados também conta como rastreamento.
• AdAttributionKit e SKAdNetwork. Esses frameworks da Apple informam quais anúncios levaram a instalações. A página do SKAdNetwork da Apple agora diz: “Use o AdAttributionKit para campanhas de anúncios de apps na App Store e em marketplaces alternativos.” As redes de anúncios “se registram na Apple para obter um ID de rede de anúncios”. A Apple também diz: “Somente anúncios de redes de anúncios que tenham uma entrada na Information Property List do app são elegíveis para a validação de instalação.” Essa lista vai dentro do app, então uma nova rede significa uma nova versão do app.
• Manifestos de privacidade e assinaturas. Um manifesto de privacidade é um arquivo em que um app ou SDK declara quais dados coleta e por quê. A Apple lista certos SDKs pelo nome. Quando você envia um app que contém um deles, precisa incluir o manifesto de privacidade desse SDK. Se o SDK for adicionado como arquivo binário (código já compilado, e não código-fonte), você também precisa incluir a assinatura dele. Para os outros SDKs, a Apple orienta os desenvolvedores a incluir um manifesto se, entre outros casos, o SDK “coleta dados sobre a pessoa que usa apps que incluem o SDK de terceiros” ou “se conecta a domínios de rastreamento”.
• Formulários de privacidade das lojas. A Apple pede as suas práticas de privacidade, “incluindo as práticas de parceiros terceiros cujo código você integra ao seu app”, e cita as redes de publicidade entre esses parceiros. O Google diz que “todos os desenvolvedores que têm um app publicado no Google Play precisam preencher o formulário Segurança dos dados”. O formulário abrange os dados “coletados e tratados por meio de quaisquer bibliotecas ou SDKs de terceiros usados nos apps deles.”
• Apps para crianças. O Google Play diz: “Se você veicula anúncios no seu app e o seu público-alvo inclui apenas crianças, deve usar somente versões de SDKs de anúncios autocertificadas para Famílias.” Apps voltados ao mesmo tempo para crianças e para usuários mais velhos precisam usar uma triagem de idade, como uma tela neutra que pergunta a idade sem induzir a resposta. Esses apps só podem mostrar anúncios a crianças por meio de versões de SDKs de anúncios autocertificadas. O Google exige que os “SDKs de anúncios e as plataformas de mediação se autocertifiquem como adequados para crianças”. O AdMob diz que as suas fontes de bidding “não oferecem suporte à veiculação de anúncios para apps ou requisições de anúncio direcionados a crianças.” A Apple diz que os apps da categoria Kids “não devem incluir analytics de terceiros nem publicidade de terceiros”. E acrescenta que a publicidade contextual de terceiros, ou seja, anúncios escolhidos pelo que o app mostra, e não por dados sobre o usuário, “também pode ser permitida em casos limitados”.

As políticas das lojas mudam, e a legislação de privacidade varia de país para país. Confirme esses pontos com um advogado antes de adicionar ou trocar um SDK de anúncios, especialmente em apps usados por crianças.

Como verificamos a viewability e o tráfego inválido?

Viewability indica se um anúncio apareceu na tela em um lugar onde uma pessoa podia vê-lo. O Open Measurement SDK (OM SDK) do IAB Tech Lab permite que empresas de medição externas verifiquem os anúncios em apps. O IAB Tech Lab diz que ele “confirma quando os anúncios aparecem na tela, a porcentagem visível e por quanto tempo” e “facilita a verificação por terceiros do tráfego inválido e dos requisitos de marca”.

Em uma plataforma, pergunte quais das suas fontes de anúncios oferecem suporte ao OM SDK. No seu próprio SDK, você mesmo faz a integração, e o IAB Tech Lab oferece uma certificação que “verifica se a sua implementação do OM SDK funciona com os provedores de medição.”

O tráfego inválido é formado por visualizações e cliques em anúncios que não vêm de um interesse genuíno do usuário. A central de ajuda do AdMob diz que ele “abrange tanto o tráfego intencionalmente fraudulento quanto os cliques acidentais.” Dois artigos anteriores explicam como uma plataforma de anúncios o filtra e por que dois conjuntos de relatórios acabam divergindo.

Quanto custa cada caminho?

Os preços dependem do fornecedor e do seu volume, então compare como cada caminho é cobrado:

• Plataforma pronta: verifique como a plataforma ganha dinheiro. Em 6 de novembro de 2026, a página do MAX da AppLovin dizia: “A mediação do MAX é gratuita para publishers. As redes de bidding pagam à AppLovin uma taxa sobre a receita de anúncios gerada.” A página não dizia de quanto é essa taxa, e as páginas do AdMob e do LevelPlay consultadas para este artigo não informavam nenhuma taxa de mediação. Pergunte o que é retido entre o lance do anunciante e o valor que você recebe, e por quem.
• Produto white-label: uma taxa de implantação ou de licença, uma mensalidade, uma participação na receita ou uma combinação disso. Pergunte sobre o que a participação é calculada.
• Sistema próprio: engenheiros para o SDK, os adaptadores e o servidor de leilão. Depois do lançamento vêm os servidores e o tráfego, que crescem com as requisições de anúncio, as pessoas de plantão, a certificação do OM SDK e as atualizações dos adaptadores.
• Em qualquer caminho: o tempo dos desenvolvedores para testar cada atualização de SDK antes de lançar uma versão do app, e a revisão jurídica das suas declarações de privacidade.

Um sistema próprio concentra a maior parte do custo antes de o primeiro anúncio ser exibido, enquanto as participações na receita crescem a cada anúncio que você vende.

O que devemos perguntar a uma empresa que vá construir ou integrar a mediação para nós?

• Como os dados brutos de receita de cada impressão vão chegar ao nosso próprio armazenamento, e como vocês vão conferi-los com os relatórios de cada rede?
• Quais redes de anúncios terão adaptadores no lançamento, e quem atualiza cada adaptador quando uma rede lança um novo SDK?
• Como o SDK vai se comportar no iOS quando a pessoa recusar o rastreamento, e o que o manifesto de privacidade dele vai declarar?
• Quem assina o SDK, e com o nome de quem os publishers e as lojas de apps vão vê-lo?
• O SDK vai oferecer suporte ao OM SDK, e quem conduz a certificação dele no IAB Tech Lab?
• Como os anúncios para crianças e para usuários de idade desconhecida vão seguir a política para Famílias do Google Play?
• Vocês conseguem mostrar isso rodando em um app que está nas lojas hoje?

Onde a amBrain se encaixa?

A amBrain publica este blog. Três declarações da própria empresa tocam no lado de servidor dos caminhos descritos aqui. Uma diz: “A amBrain constrói supply-side platforms (SSP) para publishers.” Outra: “A amBrain constrói ad servers: segmentação, limite de frequência e relatórios.” Uma terceira: “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 nenhum trabalho para clientes. As frases da amBrain acima não mencionam uma plataforma de mediação, um SDK de anúncios mobile nem um adaptador para qualquer rede de anúncios. O artigo também não traz preços nem prazos da amBrain. O Google, a AppLovin, a Unity, a Teqblaze, o Prebid.org, a Apple e o IAB Tech Lab são citados com base nas suas próprias páginas. O artigo não recomenda nenhum deles e não afirma nenhuma relação com qualquer um deles.

Também não é aconselhamento jurídico. Peça a um advogado que leia os contratos com plataformas e fornecedores, e as suas declarações de privacidade, antes de assinar ou de lançar uma atualização. Se a amBrain estiver na sua lista curta, faça a ela as mesmas perguntas que a qualquer outra empresa.