Atribuição granular compatível com o iOS 14

Este post do blog foi atualizado em 29 de julho de 2020 para incluir mais informações sobre como a Adjust dará suporte a clientes e parceiros após introdução do iOS 14, outros cenários possíveis para uma solução on-device confiável e nossa posição sobre o Attribution Hash.

Conforme descrito no nosso último post no blog, a Adjust tem pesquisado extensivamente opções para fornecer uma atribuição precisa e granular sob as novas regras propostas que serão introduzidas no iOS 1

A Adjust dará suporte para nossos clientes e parceiros usando três métodos distintos:

• Atribuição determinística opcional usando o framework AppTrackingTransparency
• Mensuração probabilística gerada através de diversos sinais determinísticos
• SKAdNetwork como conjunto de dados adicional

Nossa solução de atribuição está em total conformidade com as regras da Apple até no caso de usuários que não dão consentimento. Contudo, independentemente da atribuição, nós damos suporte e recomendamos aos desenvolvedores de aplicativos implementar um fluxo de consentimento que use o framework AppTrackingTransparency, , introduzido pela Apple WWDC2020, em seus aplicativos para ganhar vantagens competitivas tanto do lado da oferta quanto da demanda.

Este post apresenta a pesquisa que temos conduzido, especificamente, sobre a solução proposta que chamamos de "Attribution Hash". Com este texto, queremos iniciar discussões e coletar feedback sobre o que a atribuição on-device pode ser. Nosso objetivo a longo prazo é incentivar a Apple a validar uma solução on-device confiável que a indústria possa usar respeitando as regras da Apple mesmo tempo.

Nós acreditamos que a Apple deve ser a única a controlar IDs dos dispositivos, assim como o API na atribuição on-device conforme definido na privacidade do iOS 14. Esperamos que nossa solução evolua nessa direção.

Abaixo encontram-se os passos necessários e seus respectivos players no ecossistema.

O lado da oferta

Primeiro, vamos começar pelos ad publishers. Isso inclui todos os aplicativos, de mídias sociais a jogos, que geram receita de anúncios e redes de anúncios que eles usam para monetizar.

Se os próprios usuários do aplicativo tiverem que decidir ativamente se compartilham ou não seu IDFA no iOS 14, então agora depende dos app publishers demonstrar o valor ou o benefício que eles podem oferecer aos consumidores. A Apple não prescreveu nenhuma limitação sobre como comunicar essa troca de valor com os usuários, o que abre novas oportunidades.

Os app publishers podem, por exemplo, oferecer aos usuários a escolha entre uma versão gratuita e suportada por anúncios ou uma versão paga e sem anúncios no aplicativo.

Os aplicativos de mídias sociais poderiam simplesmente adicionar aos seus Termos e Condições que o usuário permite que lhe sejam mostrados anúncios e que ele aceita o compartilhamento do seu IDFA, a fim de poder usar o aplicativo inteiro.

No final, enquanto a houver demanda, a oferta será incentivada a inovar. Os publishers que puderem provar o valor dos seus aplicativos obterão mais consentimento do usuário - e esses publishers serão recompensados com um inventário mais valioso.

Nós acreditamos que esse princípio econômico básico impulsionará o lado da oferta.

O lado da demanda

O maior desafio de fornecer atribuição baseada no IDFA no iOS 14 é que você precisa do IDFA de cada dispositivo que instala o aplicativo de um anunciante, assim que o aplicativo for aberto.

Não há forma lógica de obter a permissão dos usuários tão cedo, especialmente nos aplicativos que não exibem anúncios, monetizando, em vez disso, por meio de assinaturas e compras no aplicativo.

Esse é o problema central e uma das principais razões pelas quais alguns da indústria o proclamaram como a “morte do IDFA”.

Mas a Apple delineou uma exceção crucial no framework AppTrackingTransparency.

Então, como você atribui uma instalação ou um reengajamento sem enviar dados do dispositivo que possam identificar o usuário ou dispositivo?

Nós criamos uma possível solução: o Attribution Hash.

Os detalhes técnicos do Attribution Hash

A ideia é bastante simples: uma vez aberto, o aplicativo do anunciante lê o IDFA e o IDFV.

Em seguida, calcula um SHA256 (Hash seguro) do IDFA e IDFV no que chamamos "Attribution Hash".

Por exemplo, se o IDFA for 236A005B-700F-4889-B9CE-999EAB2B605D e o IDFV for C305F2DB-56FC-404F-B6C1-BC52E0B680D8, o Attribution Hash se torna a5a884a5dd3758ae7f0d333f56933df76d4a609a77e54ecc5db51ac8651fb5658.

Então, qual é a natureza desse hash?

Primeiro, vamos relembrar o que é um hash. Simplificando, é uma função unidirecional que sempre produz o mesmo output para um determinado input, mas não permite reverter output de volta para o input. Este vídeo dá uma explicação simples sobre o que é o hash e como ele funciona.

O input do Attribution Hash herda a natureza do input mais volátil. Isso significa que nosso hash vai se comportar muito como o IDFV: nunca será o mesmo entre dois aplicativos diferentes no mesmo dispositivo, a menos que sejam do mesmo app publisher, assim como o IDFV.

Isso, por sua vez, significa que você não pode usá-lo para redirecionar ou criar o perfil de um usuário em aplicativos diferentes. Isso também significa que não é um identificador de usuário ou de dispositivo, assim como o IDFV.

Agora vamos imaginar que um SDK de uma MMP pega esse hash e o IDFV, enviando-o para o backend da MMP.

Nenhum identificador de usuário ou de dispositivo saiu do dispositivo, e o IDFA foi usado apenas localmente para calcular o hash.

Para atribuir usando esse hash, uma MMP examinaria todos os IDFAs recebidos do lado do fornecimento para contratos de anúncios que possam ter impulsionado essa atividade do aplicativo. E lembre-se - todos esses IDFAs foram enviados para a MMP com o consentimento coletado no aplicativo que publica o anúncio.

A MMP então calcula todos os hashes SHA256 de cada IDFA e IDFV correspondentes potenciais que ela recebeu. Se um desses hashes for igual ao Attribution Hash do dispositivo, você terá uma identificação exata - e pode atribuir quase como se identificasse um IDFA hoje.

A beleza dessa solução é que mesmo a combinação de IDFV e Attribution Hash não permite que você reverta o IDFA, a não ser que você já saiba qual ele é. A menos que você tenha recebido um IDFA aprovado pelo usuário, não há como fazer algo com o Attribution Hash.

Devido à sua natureza limitada, o Attribution Hash só seria usado internamente por MMPs.

Em resumo

Dado o acesso ao IDFA no lado da oferta, a Adjust propõe usar um hash de IDFA e IDFV (ou qualquer outro "salt" aleatório), calculado localmente no aplicativo do lado da demanda, para ser usado para atribuição. Isso significa que a permissão do usuário não é necessária para transferir o IDFA para fora do dispositivo, resolvendo o problema do consentimento do lado da demanda.

O Attribution Hash tem várias vantagens:

• Privacidade: Nenhuma ID do dispositivo ou ID de usuário é enviada do dispositivo, e o IDFA é adquirido com consentimento, de acordo com os novos regulamentos da Apple.
• Transparência: Para os responsáveis pela implementação técnica em toda a indústria, essa solução é fácil de entender e de comunicar.
• Precisão: Esse método fornece o mesmo nível de identificação que a identificação de IDFA pura. Em alguns casos, ele pode até fornecer um nível melhor, considerando que a Apple descontinuou o LAT, e ler o IDFA no aplicativo do anunciante sempre funciona.
• Segurança: É impossível descobrir à força o IDFA, mesmo sabendo metade do input do hash.
• Simplicidade: Essa solução exige apenas pequenas alterações nos SDKs das MMPs. Todas as MMPs devem ser capazes de adaptar seu backend para esse tipo de identificação sem investir recursos significativos.

Há outros cenários possíveis para o on-device:

• Um análogo ao Google Referrer no Android: Poderia ser até necessário o consentimento do lado da oferta no qual somente se o usuário aceitar o rastreamento do lado da oferta, o lado da demanda do site recebe um callback delegado depois de uma instalação que pode ser lida pelo nosso SDK. A carga pode ser uma click ID (nossa reftag interna da Adjust, por exemplo), a informação da campanha ou o IDFV do aplicativo-fonte.
• Identificando IDs no próprio dispositivo: Em vez de IDFAs indo do SDK para os servidores da Adjust, os servidores enviariam todos os IDFAs recebidos no engajamento ao SDK ao lado do click tracker, que é um ponto de dados agregado. O SDK identifica o IDFA e devolve somente o tracker.
• Attribution Hash gerado pela Apple: Nosso SDK nem chegaria a ler o IDFA, nós só receberíamos o hash e o salt da Apple.

Por fim, o ponto principal é que há várias soluções para a atribuição on-device que podem ser pesquisadas e investigadas, e algumas delas podem se tornar disponíveis como parte das melhorias futuras da SKAdNetwork.

Nós nos comunicamos constantemente com a Apple, desenvolvedores de aplicativos e parceiros de marketing para encontrar uma solução que possa levar a indústria para frente sem comprometer a privacidade do usuário.

Se você quiser se juntar a nós ou saber mais como nos apoiar, escreva para ios14@adjust.com. Nós gostamos muito de compartilhar informações e ouvir opiniões de outras partes da indústria!