O que é a Protected Audience API e como ela afeta o remarketing?

A possivel descontinuação do GAID pelo Google em 2024 é uma grande notícia para empresas e profissionais de marketing de aplicativos do mundo todo. Para aqueles que usam o remarketing como estratégia principal para retenção e engajamento, essa mudança chega a ser preocupante.  

No entanto, é importante enfatizar que o Sandbox não é tão assustador quanto parece, e os profissionais de marketing não vão ficar desamparados. Essa atualização traz uma inovação tecnológica que garante a existência de soluções que podem ajudar os profissionais de marketing a atingirem os seus objetivos. 

Juntamente com a redução da dependência de IDs de dispositivos, novas tecnologias de proteção à privacidade estão sendo implementadas. Na AppsFlyer, trabalhamos em estreita colaboração com o Google e parceiros do setor para projetar uma solução focada na privacidade que, ao mesmo tempo, permita que as empresas cresçam e retenham seus usuários por meio do remarketing. 

A Protected Audience API (anteriormente conhecida como FLEDGE) é a estrutura do Google para um remarketing centrado na privacidade, que atua no dispositivo e sem usar IDs no Android.

Mas será que a Protected Audience API muda o remarketing como o conhecemos? 

Olhando para além das equipes de marketing, como essa nova estrutura afetará os desenvolvedores de aplicativos e parceiros de publicidade? Nós temos as respostas.

Explicando a Protected Audience API

Então, como funcionará o remarketing daqui para a frente? Trouxemos uma explicação simplificada que compara o remarketing atual baseado em IDs de publicidade com o remarketing usando a Protected Audiences API. 

Remarketing com GAID

Hoje, o remarketing é habilitado pelo Google Advertising ID (GAID), um ID de dispositivo gerado pelo Android e comunicado através de ad networks que permite que os profissionais de marketing personalizem suas campanhas:

• Segmentação: os usuários de um app são agrupados em audiências personalizadas de acordo com características compartilhadas ou uso do aplicativo. Cada usuário é representado por seu GAID. 

• Comunicação: o GAID é usado para compartilhar o membership de público-alvo personalizado de um usuário com parceiros de publicidade (como ad networks e publisher apps).

• Direcionamento: as plataformas conseguem adaptar anúncios e bids personalizados para GAIDs específicos de acordo com o seu membership de público-alvo, exibindo um anúncio assim que o GAID fica disponível em um publisher app.  

• Atribuição e mensuração de audiências: o engajamento de um usuário com anúncios de remarketing é comunicado por meio do GAID, que é usado pela MMP em seus modelos de atribuição. Essas informações também são transmitidas para ad networks e publisher apps para ajudá-los a otimizar ainda mais sua lógica de anúncios em tempo real.

Agora, vamos explorar como o remarketing funcionará sem o GAID. 

Remarketing com a Protected Audience API

Com a Protected Audience API, o Android facilita a troca de informações entre anunciantes, publisher apps e suas plataformas adtech correspondentes de compra e venda. 

Em vez de depender de um identificador compartilhado, como acontece hoje, as audiências serão criadas no dispositivo para permitir a segmentação personalizada. Dessa forma, todos os dados ficam isolado no dispositivo, sem permitir que terceiros consigam acessá-los.  

O remarketing na Protected Audience API acontecerá da seguinte forma:

• Segmentação personalizada: os usuários serão agrupados em públicos personalizados de acordo com características compartilhadas ou uso do aplicativo. Cada usuário será adicionado à audiência no dispositivo pelo próprio aplicativo do anunciante por meio da Protected Audience API. 

• Comunicação personalizada: feito isso, uma plataforma de anúncios específica (como uma ad network DSP ou uma SRN, como o Meta) será configurada para exibir anúncios para esse público. Como o membership do público-alvo não pode ser comunicado fora do dispositivo, os processos de veiculação de anúncios que tradicionalmente ocorriam no servidor da plataforma de anúncios agora serão configurados para serem executados no próprio dispositivo.

Para isso, o aplicativo que exibe os anúncios deve configurar os seguintes elementos como parte da audiência:

• Criativos de anúncios: os anúncios serão mostrados a uma audiência em outros aplicativos .
• Sinais de bidding: fatores que são importantes para determinar um bid futuro, como localização, atividade, pontuação de LTV do usuário, etc. 
• Lógica de bidding: a lógica para usar as diferentes variáveis ​​recebidas do público-alvo personalizado e do publisher app para determinar um bid em tempo real. Como a lógica em si não está disponível no nível do usuário e está sujeita a atualizações em tempo real, ela é obtida de um servidor confiável na plataforma de anúncios.  
• Hora de ativação/expiração: a hora em que o público-alvo personalizado será ativado e a hora em que ele está configurado para expirar.

Por exemplo, vamos supor que um aplicativo de compras deseja fazer remarketing para usuários que compraram recentemente para incentivá-los a fazer a próxima compra. Depois que o “usuário do aplicativo A” concluir uma compra, o aplicativo chamará a Protected Audience API para associar o “usuário do aplicativo A” ao público-alvo personalizado “comprou nos últimos 7 dias”. 

No dispositivo, o público-alvo personalizado incluirá o nome da ad network onde o aplicativo de compras configurou sua campanha, os anúncios dessa campanha, a pontuação de atividade para um bid competitivo, o pointer para buscar a lógica de bids da ad network em tempo real e o prazo de validade de 7 dias a partir do momento da compra. 

• Direcionamento personalizado: assim que um publisher app solicitar a exibição de um anúncio, ele chamará a Protected Audience API para receber um anúncio e um bid derivado dos públicos-alvo personalizados configurados no dispositivo. Aqui, os elementos necessários também serão comunicados pelo publisher app e seu parceiro de vendas para determinar um anúncio vencedor:
  • Sinais de seller e ad auction: fatores importantes para determinar o melhor anúncio e bid, como o tipo de aplicativo, posicionamento do anúncio e informações contextuais abrangentes. 
  • Lógica de decisão: a lógica para pontuar um anúncio com base nas variáveis ​​compartilhadas pelos lados de compra e venda.

Por exemplo, vamos supor que um aplicativo de notícias deseja exibir um anúncio em sua seção de moda. Assim que o “usuário do aplicativo A” abrir um artigo na seção de moda, o aplicativo de notícias chamará a Protected Audience API para verificar se há anúncios baseados em público-alvo personalizado direcionados para esse usuário específico. 

Essa solicitação inclui a seller ad network/SSP por meio da qual a ação é realizada, o aplicativo que fez a solicitação, sua vertical, o formato e as dimensões do anúncio, a categoria de conteúdo e um pointer para buscar a lógica de pontuação do seller ad em tempo real. Essas informações serão usadas para definir bids em outros anúncios personalizados com base no público-alvo, bem como em outros inventários de anúncios.

Receba notícias de marketing e insights de especialistas direto em seu e-mail

A Protected Audience API responde com um anúncio vencedor e um bid que será veiculado pelo publisher app

• Atribuição e mensuração de audiências personalizadas: as impressões vencedoras serão informadas aos lados de compra e venda para fins de mensuração e otimização. Esse elemento ainda está em fase de design. Por isso, compartilharemos mais detalhes de acordo com a sua evolução.

Como a Protected Audience API pode me afetar? 

Vamos começar com os desafios mais óbvios:

• Os usuários só podem ser adicionados a públicos personalizados enquanto estiverem ativos: ao contrário do GAID, onde os públicos podem ser criados retroativamente, a Protected Audience API exige que o aplicativo esteja ativo (ou seja, que ele esteja aberto em primeiro plano do dispositivo) para adicionar o usuário a uma audiência. Para isso, os desenvolvedores de aplicativos terão que definir uma estratégia robusta de segmentação personalizada ao longo do ciclo de vida do usuário, uma vez que muitas das estratégias de público-alvo só podem ser definidas antecipadamente.

Por exemplo, se um anunciante pretende mostrar um anúncio de remarketing a um usuário após 7 dias de inatividade, ele deve definir esse público antecipadamente, a cada vez que o usuário iniciar o aplicativo (com o tempo de ativação configurado para o futuro) e remover o usuário caso ele interaja com o aplicativo antes do período de inatividade de 7 dias.

• Calcular a audience membership com rapidez: com um prazo limitado para adicionar usuários a um público-alvo, a segmentação exige agilidade e velocidade. 
• Detalhes de controle do usuário ainda serão definidos: os usuários do Android poderão controlar quais aplicativos têm permissão para adicioná-los a públicos personalizados. O Android ainda não divulgou todos os detalhes de como isso vai funcionar. No entanto, considerando o seu compromisso com o ecossistema, demonstrado em todas as iniciativas do Sandbox, não prevemos taxas de opt-out disruptivas.
• Os públicos-alvo personalizados originados pelo anunciante devem utilizar um SDK: as equipes de BI e CRM de um anunciante são tradicionalmente capazes de realizar a segmentação de audiências personalizadas e, em seguida, fazer o upload manual de públicos personalizados para plataformas de anúncios usando uploads de arquivos CSV ou de forma programática, usando integrações diretas de API. 

Com a mudança para o gerenciamento de audiências no dispositivo, os anunciantes precisariam implementar essas capacidades diretamente nos SDKs de seus aplicativos ou usar plataformas de ad tech especificas. Com o SDK da AppsFlyer, os anunciantes podem usar o Audiences para gerenciar públicos personalizados da mesma forma que ele já e usado hoje.

Para revisar o fluxo gerado pelo anunciante, veja o diagrama acima.

• Públicos-alvo personalizados originados na plataforma de anúncios: o GAID permitia que os anunciantes delegassem a segmentação de audiências a plataformas de anúncios (por exemplo, DSPs ou ad networks) sem serem obrigados a implementar SDKs em seus aplicativos. Por outro lado, a Protected Audience API requer um SDK para adicionar usuários a públicos personalizados, o que pode criar uma sobrecarga técnica e operacional para anunciantes e plataformas de anúncios. Para ajudar a preencher essa lacuna, a AppsFlyer está construindo integrações de parceiros que também permitirão a criação de públicos personalizados definidos por parceiros – veja o Gráfico C para mais informações. 

Agora vamos nos concentrar em suas vantagens exclusivas

• Proteção da privacidade do usuário: a Protected Audience API representa um grande avanço no que diz respeito à privacidade do usuário. Essa solução permite que as marcas personalizem a comunicação com seu público-alvo sem compartilhar informações do usuário com terceiros, desbloqueando o remarketing para muitas empresas que evitam usar essa estratégia por receio de compartilhar dados do usuário. Para além do remarketing, a Protected Audience API representa um avanço significativo para a indústria, mostrando como podemos usar a tecnologia para proteger a privacidade, sem comprometer a experiência do usuário ou a otimização de anúncios.
• Filtragem de anúncios de instalação: a Protected Audience API inclui um recurso dedicado que permite que os desenvolvedores de aplicativos ativem dispositivos para filtrar anúncios de instalação. Com essa lógica de filtragem, as plataformas de anúncios podem excluir usuários existentes das suas campanhas de UA, otimizando custos de aquisição. 
• Sinais de user bidding: a Protected Audience API permite que as plataformas de anúncios façam a otimização granular de bids no nível do dispositivo por meio do uso de sinais de user bidding que são adicionados a cada audiência personalizada. Essa funcionalidade permite a otimização de lógicas de bidding, que podem ser enriquecidas com detalhes adicionais. Por exemplo, os aplicativos agora podem predefinir um bid mais competitivo para um usuário que gera receitas maiores. 

O que eu preciso fazer?

Essas mudanças trazem diversas implicações, a depender de que lado da equação você está. Embora esteja claro que o remarketing terá uma continuidade bem-sucedida graças à Protected Audience API, você terá que adotar diferentes estratégias para o seu sucesso.

Profissional de marketing

A Protected Audience API introduz grandes mudanças tecnológicas no Android. Por isso, é muito importante se educar para uma preparação de sucesso. Isso inclui a ação de muitos stakeholders internos, como equipes de marketing, BI e dev. Os anunciantes terão que mapear sua infraestrutura e estratégias de retargeting e garantir que elas se ajustem ao novo fluxo. Como sua parceira de crescimento, a AppsFlyer está aqui para te ajudar a compreender e concretizar o potencial das mudanças que a Protected Audience API traz.

Além das equipes internas, os profissionais de marketing precisarão garantir que suas plataformas de publicidade e tecnologia estejam preparadas para essa mudança. A AppsFlyer está desenvolvendo assets tecnológicos e parcerias em toda a indústria para ajudar a ampliar seu crescimento dentro dessa nova estrutura. 

Plataformas de anúncios

As plataformas de anúncios terão que se adaptar a muitos elementos novos, com grandes mudanças de mecanismos de servidores on-device. Embora entidades de venda, como SSPs e SDKs de monetização, já exijam uma presença on-device, plataformas de compra, como ad networks e DSPs, tradicionalmente não exigem que seus anunciantes implementem um SDK para executar campanhas. 

A AppsFlyer está colaborando com plataformas de anúncios para permitir a segmentação personalizada dentro da estrutura da Protected Audience API utilizando o SDK da AppsFlyer. Isso agilizará a conectividade entre anunciantes e parceiros de anúncios, necessária para a execução desses fluxos de marketing.

Conectando o ecossistema para redefinir o remarketing

Embora o remarketing esteja mudando, ele não está extinto. Através da colaboração, podemos promover o sucesso dessa estratégia e garantir a proteção da privacidade do usuário final. 

Foi essa visão que levou a AppsFlyer a colaborar com o Google, nossos clientes e parceiros para ajudar a criar uma estrutura para a Protected Audience API. Espero que nós, como uma comunidade, possamos colaborar ainda mais, para que continuemos a avançar em nossas práticas de privacidade e no crescimento de diversos negócios.