Análise detalhada: Atribuição Mobile via Android Privacy Sandbox e sem GAID

A Google vem trabalhando na iniciativa Privacy Sandbox há algum tempo, focada principalmente na web. Ontem a Google também anunciou planos de expandir o projeto para a plataforma Android. Enquanto o sandbox da web tenta remover cookies de terceiros (principalmente por pressão externa), o Android Privacy Sandbox projeto’s objetivo seria descontinuar o GAID.

Fazer isso afetaria muitos sistemas de marketing mobile , desde a mensuração e segmentação até o remarketing e muito mais.

A boa notícia é que a proposta do Google para métricas — pelo menos no momento — parece muito boa. Aliás, é melhor do que boa. É surpreendentemente ponderada, flexível e prova que é possível se livrar do GAID sem causar estragos no ecossistema de aplicativos.

Isso talvez não seja muito surpreendente, considerando as raízes profundas e a sólida presença do Google no ecossistema da publicidade, seu conhecimento intrínseco da área e seu desejo de manter a integridade do sistema. Provavelmente, as cicatrizes de batalha adquiridas em tentativas semelhantes na web também contribuíram para que chegassem a um primeiro esboço bastante eficaz.

O Google afirma que o cronograma previsto para o projeto é de mais de dois anos – e suspeitamos que o que vemos hoje continuará mudando nesse período. Mesmo assim, quero parabenizar o Google por apresentar essas ideias como propostas, com antecedência, e por buscar feedback! Não tivemos essa oportunidade com o SKAdNetwork, e acho uma pena..

O próprio Android Privacy Sandbox possui alguns tópicos que abordam segmentação e retargeting, mas este artigo se concentrará principalmente na atribuição… porque, bem… é algo que nos interessa muito aqui na Singular 🙂

Mas primeiro, uma ressalva:

Este post é baseado na minha interpretação inicial de um documento divulgado pelo Google. Se você acha que errei em algum detalhe, por favor, me avise!

 

Resumindo: Atribuição com o Sandbox de Privacidade do Android

A ideia principal aqui é que o Google eventualmente desativará o GAID, mas ainda quer que os anunciantes possam realizar aquisições de usuários de forma eficaz. Como a maior rede de anúncios do planeta, o Google sabe que a mensuração é fundamental para isso.

Para isso, o Google criará um serviço integrado ao sistema operacional Android. Esse serviço será chamado de "API de Relatórios de Atribuição" e terá algumas tarefas:

• Visualizações e cliques em lojas relatados por redes de anúncios (o Google chama isso de “fontes”)
• Eventos de conversão da loja, como instalações, compras e cadastros, relatados pelo Apps/Singular (o Google chama isso de "gatilhos")
• Associar os eventos de conversão relatados às visualizações/cliques relatados que estão armazenados no dispositivo
• Envie os dados para redes/parceiros de medição/anunciantes de duas formas:
  • Relatórios em nível de evento: relatórios que contêm detalhamentos extremamente precisos da parte superior do funil (campanha, subcampanha, criativo, até o próprio ID do clique) combinados com dados extremamente limitados da parte inferior do funil (valor de conversão de 1 a 3 bits)
  • Relatórios agregáveis ​​– um relatório mais equilibrado que contém dados selecionados da parte superior do funil (GEO, campanha, etc.) com dados mais detalhados da parte inferior do funil (receita, número de compras, etc.)

 

Os relatórios de nível de evento me lembram um pouco o SKAdNetwork. Eles são semelhantes?

À primeira vista, parece muito melhor que o SKAdNetwork.

Os "relatórios em nível de evento" fornecerão uma análise extremamente detalhada dos dados do topo do funil (pense em campanha, subcampanha, criativo, até o próprio click_id), juntamente com valores de conversão bastante limitados (valores de conversão de 3 bits – em comparação com os 6 bits do SKAN).

Parece, no entanto, que será possível enviar até 3 eventos de conversão em momentos distintos, cada um atribuído à visualização ou ao clique. Portanto, provavelmente o primeiro evento de conversão será usado para a instalação, enquanto os 2 eventos de conversão subsequentes serão para KPIs relevantes que podem ocorrer mais tarde no ciclo de vida do usuário. Isso é incrível… e era um dos principais recursos que queríamos do SKAdNetwork.

Aqui está um resumo dos relatórios de nível de evento vs. SKAN:

 

 

Que tipo de relatórios podemos criar com relatórios de nível de evento?

Para facilitar a compreensão, aqui está um exemplo de como um conjunto de postbacks em nível de evento poderia ser:

 

 

O “ID do evento de origem” é definido pela rede e é essencialmente o ID de clique/visualização definido por ela. Isso significa que existe uma correspondência direta com todos os dados que os profissionais de marketing consideram importantes, como nome da campanha, nome do criativo, país, sistema operacional, público-alvo etc.

O "tipo de gatilho" é definido pelo anunciante/MMP e é muito semelhante aos valores de conversão do SKAN. Ele possui menos bits que o SKAN, mas permite o envio de até 3 gatilhos em momentos diferentes... uma ótima notícia para relatórios de coorte!

Aqui está um exemplo extremamente simplificado de como um anunciante/MMP pode definir o “tipo de gatilho”:

• 001 = instalar
• 010 = nível concluído
• 101 = Receita de 7 dias > $10

Ao reunir tudo isso, o resultado em um painel Singular poderia ser semelhante a este:

 

 

Assim, embora o "tipo de gatilho" (valor de conversão) seja mais limitado do que no SKAN, você obtém uma granularidade incrível nos dados do topo do funil e a possibilidade de enviar vários eventos de conversão... e isso por si só já fornece um relatório mais poderoso do que o que estamos obtendo atualmente do SKAdNetwork.

E sabe de uma coisa? Tem mais. 

Confira a próxima seção sobre “Relatórios Agregáveis”

 

Que tipo de relatórios podemos criar com os dados "agregáveis"?

Essa área é particularmente interessante e tem uma implementação bastante inteligente, conforme proposto pelo Google, mas ainda apresenta algumas lacunas de informação.

 

 

O conceito geral é o seguinte:

1. Quando uma rede de anúncios relata cliques e visualizações à API de Atribuição Android, inclui “chaves de agregação” que representam certas segmentações. Essas chaves podem ter até 128 bits, o que é super útil (128 bits é MUITO). Por exemplo, imagine que a rede de anúncios “MobCool” sempre usa 16 bits para o ID da Campanha e 16 bits para o ID da Criatividade. E vamos dizer, sem criatividade, que ID da Campanha é 1 e ID da Criatividade é 2. Para criar a segmentação, eles convertem o ID da Campanha e o ID da Criatividade em bits e os concatenam. Isso resultaria em uma string de 32 bits:
   0000 0000 0000 0001 0000 0000 0000 0010
2. Algum tempo depois, quando o aplicativo estiver instalado, o anunciante/MMP reportará os eventos de conversão do aplicativo para a API de Atribuição do Android. Esses eventos também podem adicionar suas próprias segmentações à chave de agregação. Por exemplo, se o anunciante quiser segmentar ainda mais seus relatórios de marketing por modelo de dispositivo, ele poderá criar uma chave com 10 bits (escolhi 10 arbitrariamente – eles podem usar 20 bits se quiserem), e ela terá a seguinte aparência:
3. Os bits da rede de anúncios e os bits do anunciante/MMP seriam concatenados.  Então, para um usuário que veio da Campanha 1, viu o Criativo 1 e usa o Acer Liquid A1, a chave de detalhamento seria: 0000 0000 0000 0001 0000 0000 0000 0010 0000 0010 E isso tem apenas 40 bits. Temos até 128 bits … então imagine as segmentações úteis possíveis com isso! (Note: we’re not sure yet if there’s a limit on how many different breakdowns you can have. 128 bits is very large.)
4. Ao reportar o evento de conversão, o anunciante/MMP também deve reportar um valor numérico para o próprio evento de conversão. Pode ser um contador simples para itens como instalações (ex.: 1) ou qualquer número para itens como receita (ex.: US$ 100). Esse valor é o que será somado quando a agregação ocorrer (veja mais sobre isso adiante). (Observação: existem limites para os valores que você pode passar aqui. Isso faz parte do mecanismo de privacidade diferencial que o Google utiliza).
5. Sempre que houver correspondência bem‑sucedida entre um evento de conversão (“gatilho”) e uma visualização/clique (“origem”), o serviço on‑device do Android armazenará essas informações, junto com a chave de agregação concatenada. Em seguida, enviará esses dados de usuário criptografados para a plataforma de tecnologia de anúncios do cliente (MMP, ad network).
6. Agora, as plataformas de tecnologia de publicidade do cliente (MMP, rede de anúncios, etc.) possuem muitos desses registros de "dados criptografados e agregáveis ​​em nível de usuário". Para agregá-los, o Google teve uma ideia interessante. Haverá um servidor de rede separado, chamado "Serviço de Agregação", que descriptografará e agregará simultaneamente os dados em nível de usuário, com base nessas chaves de agregação predefinidas. O resultado final do exemplo acima poderia ser algo como:
7. E isso é obviamente uma simplificação. Uma implementação adequada adicionaria muito mais dimensionalidade, e na Singular essa tabela também seria conectada a várias fontes de dados para gerar um ROI real. O Google permite que a chave de agregação tenha até 128 bits – o que significa que há muito espaço para adicionar detalhamentos significativos, e os relatórios resultantes poderiam ser realmente bons.

Além disso, no serviço de agregação: 

Este "Serviço de Agregação" é um programa desenvolvido e assinado pelo Google, mas será executado em servidores de outras empresas no que é chamado de "Ambiente de Execução Confiável". Isso significa que, se Singular estiver executando um "Serviço de Agregação", não podemos manipular seu funcionamento, e ele funcionará conforme o planejado pelo Google.

 

Como funcionará a lógica de atribuição em cascata?

Acreditamos que entendemos o que está acontecendo, mas, como dissemos no início deste artigo, há muita complexidade e algumas orientações pouco claras na documentação para desenvolvedores em seu estado atual. Isso provavelmente será esclarecido conforme o projeto avança, mas nem tudo está 100% definido ou totalmente explicado.

Eis o que pensamos que está acontecendo:

1. Cada rede de publicidade pode reportar as visualizações e/ou cliques (que o Google chama de "fontes") dos seus anúncios.
2. As redes também podem atribuir prioridades a cada um de seus pontos de contato (por exemplo, a maioria das redes provavelmente concordará que os cliques devem ter uma prioridade maior do que as impressões).
3. Quando um evento de conversão (o que o Google chama de "gatilho") é relatado pelo aplicativo instalado, o Android tentará corresponder esse evento de conversão a todas as visualizações e cliques relevantes e escolherá aquele com a maior prioridade.
4. Aparentemente, essa lógica é feita completamente separadamente para cada rede… o que parece indicar que se duas ou mais redes tiveram cliques e/ou visualizações (algo que acontece na vida real) ambas receberão retornos de atribuição (nível de evento e relatórios agregados).

Claramente, o item nº 4 acima levanta a questão da desduplicação entre as redes de anúncios. Não podemos permitir que todas as redes ganhem (e sejam pagas), pois isso distorceria consideravelmente a visão do profissional de marketing, causando dupla contagem.

A documentação aborda especificamente casos de uso de métricas de terceiros, permitindo redirecionamentos em eventos de visualização/clique. Portanto, acreditamos que empresas como Singular poderiam, dessa forma, obter a desduplicação entre redes para seus clientes:

1. Quando as Redes de Anúncios reportam cliques e visualizações, elas usariam o cabeçalho “Attribution-Reporting-Redirects” na resposta (veja a função registerAttributionSource) que incluirá’s Singular endpoint.
2. A API entrará em contato com os servidores da Singulare registraremos as mesmas visualizações e cliques com base na escolha de priorização e no modelo em cascata do nosso cliente (por exemplo, cliques são mais importantes que visualizações, o período de atribuição deve ser X, etc.).
3. Assim que um evento de conversão for reportado pelo nosso SDK no aplicativo do anunciante, a API do Android o comparará com todas as visualizações e cliques que reportamos e escolherá o ponto de contato relevante com base na priorização que fornecemos – alcançando, assim, a desduplicação em todas as redes de anúncios.

Se esse fluxo for implementado da maneira que propusemos, isso também teria o benefício adicional de fornecer alguns relatórios MTA!

 

Questões em aberto: ainda há muito a aprender

Ainda há muito a explorar e muita coisa que precisará de esclarecimentos do Google ou do ecossistema à medida que avançamos. Aqui estão algumas perguntas em aberto para mim:

1. Como faremos a detecção, gestão e mitigação de fraudes?
   Por enquanto, não está claro o que impede as empresas de alegarem que receberam uma resposta do Google. Não vimos menções a assinaturas criptográficas, como temos no SKAdNetwork. Além disso, como esta API impede que partes maliciosas registrem cliques e impressões infinitas sempre que quiserem? (Em outras palavras, spam de cliques.) Observamos que a função registerAttributionSource espera um “InputEvent” para registrar cliques, mas não temos certeza de como verifica se foi um Clique de Anúncio e não apenas um InputEvent. Também – para visualizações, não há necessidade de um evento.
2. Por que URLs em vez de parâmetros?
   Por que os métodos registerAttributionSource e triggerAttribution sempre exigem receber uma URL em vez dos parâmetros diretamente? (Assumimos que é uma proteção, já que a resolução da URL será feita em outro processo, mas não temos certeza.)
3. Como a indústria coordenará as chaves de agregação?Na seção acima, explicamos que as chaves de agregação combinam valores das redes de anúncios (que definem parte da chave em visualizações/cliques) e dos anunciantes/MMPs (que definem a outra parte da chave em eventos de conversão). A API permite que o anunciante/MMP sobrescreva todas as subdivisões, e é preciso cautela para que don’t sobrescreva algo que a rede de anúncios precise por acidente. Isso gera certa complexidade, e talvez o Google possa melhorar a API, de modo que won’t exija coordenação entre muitas empresas. (64 bits para redes, 64 bits para anunciantes/MMPs? :))
4. Como o Google Ads usará essa funcionalidade?
   A Apple tem um processo diferente para os anúncios de busca do que outras redes de publicidade. O Google Ads seguirá esse novo Privacy Sandbox para Android, assim como todas as outras redes de publicidade? Os primeiros indícios são de que sim, mas ainda há algumas dúvidas.
5. Como mobile aplicativo de deep linking diferido pode ser suportado?
   O deep linking diferido tem sido tradicionalmente suportado com processamento de atribuição no servidor, Google’s framework de referência de instalação atual, e até alguns métodos on‑device.  No entanto, todos eles também podem ser usados para contornar os objetivos de privacidade do Privacy Sandbox. Gostaríamos de ver uma solução de deep linking diferido integrada às APIs para ajudar os anunciantes a oferecer uma experiência de usuário simplificada aos novos usuários.

 

Resumindo

Ainda é cedo. O Google acabou de anunciar essa iniciativa e, claramente, haverá muitas iterações. Estamos animados com o fato de o Google estar buscando feedback e também com a possibilidade de colaborar com eles nessa iniciativa. Os documentos iniciais mostram uma abordagem muito mais robusta, capaz de oferecer relatórios significativamente melhores do que o SKAdNetwork, o que é muito encorajador. Quem sabe, talvez haja até alguns elementos aqui que a Apple possa incorporar ao SKAN…

Uma coisa é certa: podem contar connosco para continuarmos a acompanhar este assunto e a aprimorá-lo em conjunto com o Google e os nossos clientes.

Se você está procurando discutir isso mais a fundo, recomendamos fortemente que você se junte ao nosso grupo profissional no Slack sobre todas as questões de mobile privacidade de atribuição.