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

O Google vem trabalhando há algum tempo em sua iniciativa Privacy Sandbox, focada principalmente na web. Ontem, o Google também anunciou seus planos de expandir o projeto para a plataforma Android. Enquanto o sandbox da web busca remover cookies de terceiros (principalmente devido à pressão externa), o Android Privacy Sandbox 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.

Segue um resumo dos relatórios em nível de evento em comparação com o 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 reporta cliques e visualizações para a API de Atribuição do Android, ela inclui "chaves de agregação" que representam determinadas segmentações. Essas chaves podem ter até 128 bits, o que é extremamente útil (128 bits é MUITA coisa). 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 do criativo. Digamos, sem muita criatividade, que o ID da campanha seja 1 e o ID do criativo seja 2. Para criar a segmentação, eles convertem o ID da campanha e o ID do criativo 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.  Assim, para um usuário que veio da Campanha 1, viu o Anúncio 1 e usa um Acer Liquid A1, a chave de segmentação seria: 0000 0000 0000 0001 0000 0000 0000 0010 0000 0010. E isso com apenas 40 bits. Temos até 128 bits… então imagine as segmentações úteis possíveis com isso! (Observação: ainda não temos certeza se há um limite para a quantidade de segmentações diferentes que podem ser criadas. 128 bits é um número muito grande.)
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 uma correspondência bem-sucedida entre um evento de conversão ("gatilho") e uma visualização/clique ("origem"), o serviço no dispositivo Android armazenará essas informações, juntamente com a chave de agregação concatenada. Em seguida, enviará esses dados em nível de usuário, de forma criptografada, para a plataforma de tecnologia de anúncios do cliente ( MMP , rede de anúncios ).
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 de forma completamente separada para cada rede… o que parece implicar que, se duas ou mais redes tiverem cliques e/ou visualizações (algo que acontece na vida real), ambas receberão relatórios de atribuição (relatórios de eventos e 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 usam o cabeçalho “Attribution-Reporting-Redirects” na resposta (veja a função registerAttributionSource ), que incluirá o endpoint da Singular .
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, o gerenciamento e a 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 nenhuma menção a assinaturas criptográficas, como ocorre no SKAdNetwork. Além disso, como essa API impede que agentes maliciosos registrem cliques e impressões indefinidamente, quando quiserem? (Em outras palavras, spam de cliques.) Notamos que a função registerAttributionSource espera um "InputEvent" para registrar cliques, mas não temos certeza de como ela verifica se foi um clique em um anúncio e não apenas um InputEvent qualquer. Além disso, 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 o recebimento de uma URL em vez de receber os parâmetros diretamente? (Supomos que seja alguma medida de segurança, já que a resolução da URL será feita em outro processo, mas não podemos ter certeza.)
3. Como o setor coordenará as chaves de agregação? Na seção anterior, explicamos como as chaves de agregação são uma combinação de 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 divisões, e é preciso ter cuidado para não sobrescrever acidentalmente algo necessário para a rede de anúncios. Isso cria certa complexidade e talvez seja algo que o Google possa aprimorar na API, para que não seja necessária a coordenação entre diversas 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 podemos implementar a funcionalidade de deep linking diferido em aplicativos mobile Tradicionalmente, o deep linking diferido era suportado por meio do processamento de atribuição no servidor, da estrutura de referência de instalação atual do Google e até mesmo por alguns métodos no dispositivo.  No entanto, todos esses métodos também poderiam ser usados ​​para burlar as metas 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 otimizada para seus 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ê deseja discutir isso mais a fundo, recomendamos fortemente que participe do nosso grupo profissional no Slack sobre todos os assuntos relacionados à privacidade da atribuição mobile .