Como o Tráfego SDK e Non-SDK se Diferenciam: O Mecanismo do Ad Request

Resumo (TL;DR)

• Um SDK é uma camada tecnológica que o dono do app integra ao produto para conectar a infraestrutura de anúncios: fontes de demanda (demand sources), formatos, monetização, eventos, mensuração e a troca técnica com a plataforma de adtech.
• O tráfego SDK e non-SDK difere não apenas na forma como o ad request é gerado, mas também na lógica de como a publicidade, as fontes de demanda, os formatos, a mensuração e a monetização são conectados.
• No ambiente de web/navegador, o ad request geralmente é formado pelo código da página, tags ou integrações server-side, enquanto a identificação pode depender de cookies, dados primários (first-party data), sinais contextuais e outros dados baseados no navegador.
• Em um app, a requisição é feita pelo SDK integrado, que passa os sinais do app, eventos e (quando há consentimento) identificadores de publicidade.
• No mercado de adtech, os SDKs são mais associados ao tráfego in-app por serem incorporados diretamente nos aplicativos móveis. No entanto, seu real valor não está no ambiente mobile em si, mas na padronização que trazem para a infraestrutura publicitária.
• Usar um SDK não garante um volume maior de dados, já que é o dono do app quem define o conjunto de sinais que serão compartilhados.

De acordo com a DataReportal, os navegadores representam menos de 6% de todo o tempo que as pessoas passam em seus smartphones. Como a maior parte do uso do celular ocorre dentro de aplicativos, os apps se tornaram um dos principais ambientes para a publicidade digital.

A publicidade na web e in-app diferem de duas maneiras: onde o anúncio aparece e como cada um se conecta à infraestrutura publicitária. Na web, essa lógica geralmente é construída em torno da página, de tags e de mecanismos baseados no navegador. Nos aplicativos móveis, essa conexão é gerenciada pelo SDK, que funciona como a ponte entre o aplicativo e a plataforma de anúncios. Vamos entender por que isso é tão crucial.

O que é um SDK na publicidade programática?

Na mídia programática, um SDK (Software Development Kit) refere-se a uma camada tecnológica universal que o dono do app integra ao seu produto para conectar a infraestrutura de anúncios dentro do aplicativo. Essa camada permite que o app se comunique com as plataformas de adtech por meio de um conjunto padronizado de regras técnicas. Ele define como os ad requests são estruturados, como eventos como impressões e cliques são reportados e como os diferentes participantes do ecossistema interagem.

Como funcionam os ad requests na publicidade programática

No ambiente de programática aberta (open programmatic), as requisições costumam ser formadas de acordo com o padrão OpenRTB. Grandes plataformas também usam extensões proprietárias e, em alguns casos, protocolos totalmente separados. Na publicidade em vídeo, o VAST e o VPAID também entram em jogo. Na prática, porém, a maioria dos leilões programáticos ainda se baseia no OpenRTB.

A diferença entre os cenários surge na etapa do leilão. Na web, os leilões são disparados por tags de anúncio (ad tags). Nos apps, esse papel é executado pelo SDK. Como os dois ambientes oferecem níveis diferentes de acesso, eles expõem tipos diferentes de sinais.

Por que os SDKs são estreitamente associados à publicidade in-app

Os SDKs existem tanto em ambientes de app quanto de web.

Na programática, eles são mais associados aos apps móveis, embora a lógica de um SDK seja mais ampla. Por exemplo, as ad tags fornecidas pelo Google Ad Manager cumprem muitas das mesmas funções na web.

A evolução da publicidade web e mobile foi diferente

Essa diferença ocorre porque a publicidade na web e no mobile evoluíram de forma independente. A web vende anúncios desde 1994 e, em seus primeiros quinze anos, não tinha um protocolo único. Os publishers e as redes de anúncios (ad networks) tinham que fazer integrações manuais, muitas vezes escrevendo códigos personalizados para cada site. O padrão da indústria, o OpenRTB, só surgiu em 2010.

Como as regras automáticas prontas demoraram a existir, a publicidade na web se desenvolveu seguindo a lógica da mídia impressa tradicional. Em muitos mercados, tudo dependeu de relações diretas por anos. Os sites vendiam banners direto para as marcas em pacotes semanais ou mensais, já que tecnicamente isso era mais simples do que configurar conexões externas complexas. 

A publicidade mobile seguiu um caminho diferente. Quando o inventário mobile começou a crescer rapidamente, os donos de apps precisavam de uma abordagem mais escalável para a monetização. Eles precisavam de acesso a uma gama mais ampla de fontes de demanda sem ter que construir relacionamentos diretos em cada mercado. Naquela época, o cenário tecnológico já havia mudado drasticamente em relação ao início dos anos 2000. É por isso que o ecossistema mobile adotou o modelo de SDK logo cedo.

Como os leilões diferem entre os ambientes de web e app

Com o panorama geral alinhado, vamos analisar as duas abordagens separadamente.

Como funciona o tráfego Non-SDK

Tráfego non-SDK é o tráfego publicitário gerado fora de um SDK mobile, ou seja, em um ambiente de web/navegador. Isso inclui anúncios em sites convencionais, na web mobile (mobile web) e em players de vídeo dentro das páginas — qualquer lugar onde a requisição seja montada pelo próprio código da página.

Na web, o ad request é montado diretamente no navegador do usuário enquanto a página carrega. Isso significa que parte do trabalho do sistema de anúncios roda no dispositivo de outra pessoa — um dispositivo que o publisher não controla — e o resultado depende de qual é o navegador e de suas configurações de privacidade.

Devido às limitações dos navegadores, o ambiente web possui menos sinais estáveis para identificar os usuários. Os cookies continuam sendo um desses sinais, mas estão atrelados a um navegador específico e podem ser bloqueados por políticas de privacidade ou pelos próprios usuários (como no caso do iOS).

Como funciona o tráfego SDK

O processo começa dentro do app quando surge uma oportunidade de anúncio. O SDK detecta o evento e determina que um anúncio deve ser exibido. Ele então se comunica com a plataforma de anúncios por meio de um conjunto predefinido de funções responsáveis por diferentes ações:

• Solicitar um criativo para um slot de anúncio específico;
• Rastreamento de impressão (impression tracking);
• Rastreamento de clique (click tracking);
• Rastreamento de conclusão de vídeo (video completion).

Os desenvolvedores não precisam implementar essas ações manualmente. Em vez disso, eles contam com funções predefinidas que oferecem um comportamento previsível. Na maioria dos apps de grande porte, o publisher trabalha com dezenas de redes de anúncios ao mesmo tempo; por isso, entre o SDK e os compradores (buyers), existe uma camada intermediária chamada mediação (mediation). Ela coleta os lances (bids) de várias ad networks e direciona cada impressão para quem pagar mais.

A identificação do usuário merece atenção especial. Os apps podem usar identificadores de publicidade — principalmente o IDFA (Identifier for Advertisers) no iOS ou o GAID (Google Advertising ID) no Android —, mas o SDK por si só não garante o acesso a esses IDs. Quando um SDK monta um ad request, a disponibilidade do identificador depende do sistema operacional, dos mecanismos de consentimento (opt-in), das políticas de privacidade, das configurações do usuário e da implementação específica do SDK.

Tráfego SDK e Non-SDK: Principais Diferenças

Por que um SDK não significa necessariamente mais dados

Um SDK pode transmitir dados, mas ele não os cria. O que realmente vai na requisição depende de dois fatores:

1. Quais informações o publisher realmente tem acesso (um app pequeno sabe muito menos sobre um usuário do que uma grande plataforma com milhões de usuários ativos).
2. Quanto dessa informação o publisher escolhe compartilhar com as plataformas de anúncios. 

No final das contas, são os publishers que decidem quais sinais serão expostos através do SDK:

• o ID de publicidade do dispositivo (ou a recusa em compartilhá-lo),
• geolocalização precisa (ou apenas a região aproximada),
• dados de comportamento in-app,
• parâmetros técnicos do dispositivo,
• sinais de sessão.

É por isso que dois aplicativos que utilizam o mesmo SDK podem expor volumes de informações completamente diferentes. Enquanto um compartilha quase tudo o que está na lista, o outro se limita a um identificador e a apenas alguns campos técnicos.

O que os anunciantes devem considerar

Essas diferenças técnicas ganham relevância assim que a campanha vai ao ar, impactando diretamente três áreas principais:

Identificação do Usuário:

Na web, a identificação depende de cookies e sinais padrão, que são constantemente limitados por limpezas de cache e regras rígidas de privacidade. Já os apps utilizam IDs de publicidade e sinais específicos que, quando autorizados pelo usuário, trazem a clareza necessária para controlar a frequência de anúncios (frequency capping) e gerenciar a exposição da audiência com alta precisão.

Geotargeting:

A precisão da geolocalização depende inteiramente do tipo de dado disponível em cada ambiente.

• Na web, o geotargeting geralmente depende do endereço de IP, de modo que a precisão pode se limitar ao nível da cidade ou região.
• Em apps, o consentimento do usuário pode liberar o acesso a dados de localização mais precisos (via GPS) — o que é crucial, especialmente para campanhas de anúncios locais.

Fraude

Os padrões de fraude também variam conforme o ambiente: na web, o calcanhar de Aquiles são as redes de bots e o domain spoofing (falsificação de domínios), enquanto nos apps o desafio são as instalações falsas (fake installs), emuladores de dispositivos e a manipulação de sinais do SDK.

É aqui que as DSPs desempenham um papel fundamental. A Fusify avalia a qualidade do tráfego diariamente, tanto em ambientes web quanto in-app. Isso nos permite identificar o comportamento de cada fonte e ajudar as marcas a alocar suas verbas de mídia de forma eficaz.

Quais formatos de anúncio performam melhor em apps e por quê

Alguns formatos de anúncio tradicionalmente apresentam melhor performance em aplicativos móveis. A maior parte desses formatos está tecnicamente disponível também na web, mas geralmente eles são menos eficazes por lá.

Esses formatos se misturam naturalmente à experiência do usuário, surgindo exatamente quando a atenção está totalmente voltada para a tela.

Conclusão

Nenhum tipo de tráfego possui uma vantagem inerente ao outro. Os inventários SDK e non-SDK competem no mesmo leilão, embora por caminhos técnicos diferentes.

O real valor do SDK está na padronização e eficiência que ele traz para o processo de compra e venda. Para o publisher, oferece uma forma simples de conectar sua infraestrutura. Para uma DSP, abre um acesso padronizado a milhares de aplicativos por meio de uma única conexão.

Dito isso, os anunciantes não precisam dominar cada detalhe técnico. Identificar qual tipo de tráfego atende melhor aos seus objetivos, configurar a campanha e monitorar a qualidade do inventário é uma tarefa para um parceiro especializado. A Fusify cuida de toda a parte técnica para que você possa focar no seu negócio.

Se você está planejando sua próxima campanha e quer entender qual estratégia se alinha melhor aos seus objetivos, venha conversar com o nosso time.