Publicidade programática in-app: como as DSPs compram inventário de apps mobile

A maioria dos media buyers começa na open web. O modelo mental que vem junto — uma URL de página, um cookie, um referrer, um domínio que você pode colocar em uma whitelist — funciona bem o suficiente ali. Então o mesmo comprador ativa o inventário de apps mobile, e metade desses sinais desaparece silenciosamente. Não há URL. Não há cookie de terceiros. O campo de domínio vem vazio e, no lugar dele, chega um bundle ID que parece uma sequência de palavras invertidas.

Isso não é uma versão menor da compra na web. O inventário in-app percorre uma cadeia de suprimentos diferente, carrega outro conjunto de identificadores, usa formatos de anúncio que a web nunca teve e é verificado com um arquivo diferente. Uma DSP que trata uma impressão em app como uma impressão na web vai comprar as coisas erradas, interpretar mal os próprios relatórios e gastar dinheiro em posicionamentos que não consegue enxergar.

Este guia explica como a publicidade programmatic in-app realmente funciona: o que contém um bid request de app, como a camada de SDK e mediação fica entre o publisher e a sua plataforma, quais formatos uma DSP precisa suportar, como a identidade e a mensuração mudaram depois que as plataformas mobile endureceram as regras de privacidade e o que um proprietário deve configurar antes de comprar tráfego de app em escala.

O Que É Publicidade Programmatic In-App?

Publicidade programmatic in-app é a compra automatizada de posicionamentos de anúncios dentro de aplicativos mobile — jogos, apps de notícias, utilitários, apps de streaming — por meio de leilões em tempo real, em vez de insertion orders diretas. A mecânica é a mesma dos leilões usados em todo o restante do programmatic: um posicionamento fica disponível, um bid request o descreve, os compradores conectados respondem com um preço e o maior lance elegível vence a impressão.

O que muda é o ambiente. Um app mobile não é um navegador. Ele não tem um repositório de cookies compartilhado, não tem barra de endereços e não tem um document object model que o anúncio possa inspecionar. Tudo de que o anúncio precisa — renderização, mensuração, tratamento de cliques — precisa ser fornecido por código que o publisher compilou dentro do próprio app, e é por isso que o software development kit (SDK) é a característica que define esse canal.

O leilão subjacente ainda segue a mesma sequência descrita no nosso guia sobre como funciona o real-time bidding. Se você entende um leilão OpenRTB na web, já entende noventa por cento do leilão in-app. A parte restante é o tema deste post.

Como um Bid Request In-App Difere de um Bid Request Web

No OpenRTB, um bid request descreve seu inventário usando um objeto site ou um objeto app. Ele nunca deve carregar os dois. Essa única bifurcação é o que informa ao seu bidder em qual mundo ele está comprando, e quase todas as diferenças práticas decorrem dela.

O objeto app identifica o aplicativo pelo bundle ID — o nome do pacote no Android ou o ID numérico da App Store no iOS —, além de uma URL da loja, um nome de app e um bloco de publisher. Em vez de uma URL de página e um referrer, sua lógica de segmentação e bloqueio precisa trabalhar a partir do bundle. Em vez de um cookie, o dispositivo é identificado por um advertising ID redefinível, enviado no objeto device, quando o usuário permite.

Dois campos merecem atenção especial do lado da compra. O primeiro é o device.lmt, a flag de limit-ad-tracking: quando ela está ativada, o usuário optou por não receber publicidade personalizada, e qualquer segmento de audiência vinculado àquele dispositivo deve ser ignorado, e não reutilizado discretamente. O segundo é o app.bundle, porque um bundle malformado ou inconsistente é o sinal mais comum de tráfego de app falsamente representado.

A Cadeia de Suprimentos In-App: SDK, Mediação e Exchange

Na web, um publisher pode adicionar um parceiro de demanda colando uma tag. Em um app, adicionar demanda historicamente significava integrar mais um SDK e lançar uma nova versão do app passando pela revisão da loja. Esse atrito moldou todo o canal, e é por isso que uma camada intermediária — a mediação — se tornou padrão.

Uma plataforma de mediação fica dentro do app como um único SDK e gerencia todas as fontes de demanda conectadas por trás dele. A mediação inicial funcionava como um waterfall ranqueado, chamando as redes uma de cada vez pelo preço médio histórico. As configurações modernas usam in-app bidding, que pede a todas as fontes conectadas que deem lances na mesma impressão simultaneamente — a mesma mudança estrutural descrita na nossa comparação entre header bidding e waterfall.

Do ponto de vista da sua DSP, a consequência prática é a distância. Entre o app e o seu bidder pode haver uma plataforma de mediação, uma supply-side platform e um ou mais revendedores, cada um ficando com uma parte e cada um capaz de adicionar ou perder sinais pelo caminho. Encurtar e auditar essa cadeia é justamente o objetivo do supply path optimization, e isso importa mais em app do que na web porque a cadeia costuma ser mais longa.

A cadeia de suprimentos também determina o que você consegue fazer valer. Uma conexão direta com a SSP permite negociar um feed limpo no nível do bundle e responsabilizar alguém por ele. Um feed de revendedor no quarto salto raramente oferece qualquer uma dessas coisas. Nosso checklist sobre como conectar SSPs à sua DSP se aplica integralmente aqui, com um acréscimo: pergunte especificamente se o feed é de supply de app direto ou agregado.

Formatos de Anúncio In-App Que uma DSP Precisa Suportar

O inventário de apps é orientado por formato de um jeito que o display na web não é. Os jogos, em particular, monetizam com posicionamentos em tela cheia e baseados em recompensa, e uma plataforma que só entrega banners fica excluída da maior parte do supply valioso antes mesmo de o bidding começar.

• Banner. Posicionamentos pequenos e fixos, ancorados na parte superior ou inferior da tela. Custo baixo, volume alto e renderização feita pelo container MRAID, e não por um iframe simples.
• Interstitial. Uma unidade em tela cheia exibida em uma pausa natural, como entre fases de um jogo ou depois de um artigo. Mais atenção, preço mais alto e requisitos de criativo mais rígidos.
• Rewarded video. O usuário opta por assistir a um vídeo em troca de moeda do app ou de uma vida extra. As taxas de conclusão são altas porque a troca é explícita, e o formato é dominado pelo supply de games.
• Native. Um anúncio renderizado com o layout e o estilo do próprio app, montado a partir de assets separados de título, imagem e call-to-action, em vez de um criativo fixo.
• Playable. Uma demo interativa curta, usada com mais frequência em campanhas de instalação de apps, entregue como um criativo interativo autocontido.

Dois padrões técnicos sustentam a maior parte disso. O MRAID define como um criativo rich media se comunica com o SDK hospedeiro — como ele se expande, fecha ou abre um click-through. O VAST define como um criativo de vídeo e seus eventos de tracking são descritos. Uma DSP que compra inventário de apps precisa dos dois, além da estrutura de assets native, ou uma grande parte das respostas será simplesmente descartada por incompatibilidade.

O suporte a formatos também muda a forma de ler a performance. Uma conclusão de rewarded video não é comparável a uma visualização de banner, e juntar as duas em um único número combinado esconde qual formato está realmente funcionando. Separar win rate, CPM e relatórios de conversão por formato é o recorte mínimo útil de relatório para campanhas em apps.

Identidade e Mensuração Dentro dos Apps

Os apps nunca usaram cookies de terceiros. Eles usavam um identificador de publicidade emitido pela plataforma: o IDFA no iOS e o Google Advertising ID no Android. Ambos podem ser redefinidos pelo usuário, e ambos têm escopo de dispositivo, e não de navegador, o que historicamente tornava a segmentação em apps mais estável do que a segmentação na web, e não menos.

Isso mudou com o App Tracking Transparency. Desde o iOS 14.5, um app precisa pedir permissão ao usuário antes de acessar o IDFA para tracking entre apps e, sem essa permissão, o identificador não fica disponível. O Android seguiu em direção semelhante, com seu próprio opt-out e o trabalho do Privacy Sandbox. O resultado é um grande volume de tráfego de apps que é genuinamente anônimo no nível do dispositivo.

A mensuração se adaptou por meio de frameworks de atribuição operados pelas plataformas — o SKAdNetwork da Apple e seu sucessor, o AdAttributionKit —, que reportam conversões de instalação de forma agregada e com atraso, em vez de expor um caminho clique-instalação no nível do usuário. Para o comprador, isso significa que os dados de performance de instalação de apps chegam mais tarde e com menos granularidade do que os dados de conversão da web, e o pacing das campanhas precisa tolerar essa defasagem.

A resposta prática não é correr atrás do identificador ausente. É apoiar-se nos sinais que sobrevivem: o bundle, o posicionamento, o formato, a geografia, o horário e os seus próprios dados de conversão first-party. A otimização contextual e no nível do inventário faz a maior parte do trabalho em apps hoje, e esse é um dos motivos pelos quais ser dono da lógica de bidding importa — você pode ponderar esses sinais por conta própria, em vez de aceitar o modelo fixo de um fornecedor.

Verificando o Supply de Apps: app-ads.txt e Higiene de Bundles

O inventário de apps tem um padrão de fraude específico: a falsa representação de bundle ID. Um app de baixo valor ou inexistente se declara como um app popular, e o comprador que segmenta esse app popular paga um preço premium por uma impressão que nunca aconteceu onde dizia ter acontecido. Como o comprador não pode abrir uma URL e olhar a página, a fraude é mais difícil de identificar manualmente do que na web.

A resposta do setor é o app-ads.txt. O desenvolvedor publica um arquivo de vendedores autorizados no domínio informado na página do app na loja, e qualquer comprador pode buscar esse arquivo e confirmar que o vendedor que oferece a impressão está de fato autorizado a vendê-la. A mecânica, e o arquivo sellers.json que completa a cadeia na direção oposta, são abordados no nosso post sobre ads.txt, app-ads.txt e sellers.json.

Além do arquivo, algumas verificações pegam a maior parte do restante. Confirme que o bundle realmente existe na app store correspondente. Compare o nome declarado do app com o bundle. Fique atento a um mesmo bundle aparecendo em uma variedade implausível de vendedores sem relação entre si. E trate requests com bundle ausente ou malformado como não compráveis, e não como tráfego mobile genérico.

O Que Configurar Antes de Comprar Tráfego de Apps em Escala

Ativar o supply de apps é um exercício de configuração, não um simples botão. A lista abaixo segue a ordem que costuma gerar menos surpresas.

1. Separe campanhas de app e de web. Formatos diferentes, identificadores diferentes, benchmarks diferentes. Misturá-las torna as duas ilegíveis.
2. Ative os formatos que você realmente consegue entregar. Confirme o suporte de ponta a ponta a MRAID, VAST e assets native antes de dar lances nesses posicionamentos, e não depois.
3. Ative a verificação de app-ads.txt. Faça dela uma condição de bidding, e não um relatório pós-campanha.
4. Comece com uma allowlist de bundles. Compre primeiro um conjunto conhecido de apps, aprenda o que performa e depois amplie. A segmentação aberta em todo o supply de apps é a forma mais cara de descobrir uma blocklist.
5. Defina frequency caps por dispositivo, não por cookie. A lógica de frequência em apps se baseia no advertising ID e precisa se degradar de forma controlada quando esse ID estiver ausente.
6. Dê às campanhas de instalação uma janela de mensuração mais longa. A atribuição agregada reporta com atraso; avaliar o primeiro dia com dados do mesmo dia vai enganar você.
7. Gere relatórios por bundle e por supply path. O bundle mostra o que você comprou; o path mostra quanto você pagou para chegar até ele.

Cada item dessa lista fica mais fácil quando a plataforma é sua. Em um seat alugado, o suporte a formatos, as regras de verificação e a lógica de bidding são o que o fornecedor decidiu disponibilizar. Em uma plataforma própria, são configurações que você controla — e a compra em apps é justamente o canal em que esses controles decidem se o investimento funciona.

Pronto para Comprar Inventário de Apps na Sua Própria DSP?

A AdTech Europe fornece a tecnologia de demand-side platform por trás de agências, ad networks e equipes de compra de mídia que preferem ser donas da própria infraestrutura a alugar acesso à de outra empresa. Todos os planos incluem escalabilidade ilimitada de QPS, branding white-label e acesso a mais de 1.000 integrações de SSP cobrindo web, app e canais emergentes, de modo que o supply de apps faz parte da plataforma, e não é um adicional que você negocia separadamente.

Em setembro de 2026, a White Label DSP custa $500 por mês, sem taxa de setup e com contrato mensal, com implantação em até 24 horas. Uma DSP License custa $25,000 em pagamento único, e uma DSP Acquisition com propriedade total do código-fonte custa $50,000 em pagamento único, ambas disponíveis em cinco parcelas mensais e ambas implantadas em cinco a sete dias úteis. Os detalhes atualizados estão sempre na página de preços.

Se você está planejando adicionar inventário de apps ao seu mix de compra e quer analisar formatos, verificação de supply e configuração do bidder com base nas suas próprias campanhas, você pode agendar uma reunião de estratégia programmatic com a equipe.

Perguntas Frequentes

O que é publicidade programmatic in-app?

Publicidade programmatic in-app é a compra automatizada de posicionamentos de anúncios dentro de aplicativos mobile por meio de leilões em tempo real. A mecânica do leilão é a mesma do restante do programmatic, mas o inventário é descrito por um bundle ID do app em vez de uma URL de página, e o anúncio é renderizado por um SDK dentro do app, e não por um navegador.

Como um bid request in-app difere de um bid request web?

Um request in-app carrega um objeto app do OpenRTB em vez de um objeto site. Isso significa bundle ID e URL da loja no lugar de domínio e URL da página, um advertising ID do dispositivo no lugar de um cookie e sinais de formato para unidades interstitial, rewarded ou playable que a open web não usa.

O que é app-ads.txt e por que ele importa na compra em apps?

O app-ads.txt é um arquivo publicado no site do desenvolvedor do app que lista os vendedores autorizados a vender o inventário daquele app. Os compradores o utilizam para confirmar que quem está oferecendo uma impressão em app realmente tem o direito de vendê-la, o que é a principal defesa contra a falsa representação de bundle ID.

Ainda é possível segmentar audiências em apps depois do App Tracking Transparency?

A segmentação de audiência no nível do dispositivo só funciona quando o usuário concedeu permissão e o identificador de publicidade está presente no request. Para o restante do tráfego de apps, a segmentação depende de sinais contextuais e de inventário, como o bundle, o posicionamento, o formato, a geografia e o horário, além dos seus próprios dados de conversão first-party.

Por que uma DSP precisa de suporte a MRAID e VAST para inventário de apps?

O MRAID define como um criativo rich media interage com o SDK do publisher, e o VAST define como os criativos de vídeo e seus eventos de tracking são descritos. Sem os dois, uma grande parte dos posicionamentos em apps vai rejeitar ou descartar o seu criativo, e essas respostas de lance nunca se transformam em impressões entregues.

O que é mediação na publicidade em apps mobile?

A mediação é uma camada dentro do app que gerencia várias fontes de demanda por meio de um único SDK, poupando o publisher de integrar cada parceiro separadamente. A mediação mais antiga funcionava como um waterfall ranqueado; o in-app bidding moderno pede a todas as fontes conectadas que deem lances na mesma impressão ao mesmo tempo.

Você precisa da sua própria DSP para comprar inventário in-app?

Não, mas ser dono da plataforma muda o que você consegue controlar. Em uma plataforma própria, você mesmo define o suporte a formatos, as regras de verificação de supply, as allowlists de bundles e a lógica de bidding, em vez de trabalhar dentro da configuração que um seat alugado disponibiliza.