O SDK Runtime do Android no Privacy Sandbox é um divisor de águas
O ambiente de execução SDK proposto pelo Google no Privacy Sandbox do Android é revolucionário e representa uma enorme oportunidade para reduzir fraudes publicitárias e aumentar a privacidade dos usuários. Não me surpreenderia se a Apple também o implementasse no iOS, mas antes do prazo mínimo de dois anos estipulado pelo Privacy Sandbox.
Esta é a primeira parte de uma série mais longa de análises detalhadas sobre o Privacy Sandbox para Android, onde examinarei a nova tecnologia do Google para privacidade e marketing:
- Tempo de execução do SDK (este post)
- API de Tópicos (como o Privacy Sandbox fará a segmentação de anúncios)
- FLEDGE no Android (como o Privacy Sandbox fará o retargeting de anúncios)
- Relatórios de atribuição (como o Google propõe que a mensuração de anúncios funcione)
Veja também Mobile via Android Privacy Sandbox e sem GAID , o estudo aprofundado de Gadi Eliashiv, CEO Singular mobile após a implementação do GAID.
E, por fim, inscreva-se na transmissão ao vivo do LinkedIn que Gadi e eu faremos na quinta-feira.
SDKs e aplicativos: a promessa e o perigo
No princípio, havia o aplicativo. Um desenvolvedor disse: "Preciso de mais recursos e funcionalidades para o aplicativo, mas não tenho a receita, nem a habilidade para fazer o bolo sozinho". Os fornecedores de soluções preencheram essa lacuna com recursos pré-codificados e deliciosos que os desenvolvedores de aplicativos podiam simplesmente criar em código, sem precisar fazer muito esforço.
Maravilhoso?
Claro.
Mas os SDKs com extenso código de identificação de dispositivos foram a causa da rejeição de atualizações de aplicativos pela Apple nos primórdios do iOS 14.5. Eles são um dos motivos pelos quais alguns aplicativos foram removidos da App Store . Além disso, SDKs de redes de publicidade fraudulentas foram acusados de impulsionar fraudes de atribuição em bilhões de dispositivos e de orquestrar a exfiltração de dados que ameaça a privacidade… incluindo a espionagem de comunicações dentro dos aplicativos.
O ecossistema de aplicativos moderno não funcionaria sem SDKs. Eles são absolutamente essenciais para o software do qual todos que usam um smartphone ou tablet hoje dependem.
Mas também são uma faca de dois gumes.
O Google acredita ter uma solução.
Vá para o seu quarto agora mesmo (os SDKs estão sendo colocados de castigo)
Como alguns SDKs têm se comportado de maneira realmente problemática — e pode apostar que temos menos informações sobre o quão problemáticos eles são do que o próprio Google — o Google está os bloqueando.
Ou, ainda, confiná-los a uma caixa de areia.
Um “ambiente de execução”, por assim dizer.
Nesse ambiente de execução, os SDKs terão permissões específicas e serão executados fora do processo principal do aplicativo. Em outras palavras, os SDKs terão muito menos visibilidade implícita sobre o que os aplicativos estão fazendo, e os desenvolvedores de aplicativos terão controle total e explícito — ou pelo menos mais controle — sobre o que um SDK vê e faz.
No Privacy Sandbox para Android, os processos são isolados.
Os SDKs vivem em um mundo à parte. Os SDKs de tecnologia de publicidade não conseguem mais visualizar e rastrear o uso do aplicativo por meio de identificadores persistentes sem o conhecimento e consentimento do desenvolvedor, e também terão muito mais dificuldade em coletar identificadores perecíveis, ou seja, fatores que podem ser resumidos em um identificador temporário.
Além disso, o Google está dificultando que os SDKs manipulem a funcionalidade de outros SDKs.
Ao mesmo tempo, porém, o Google está deixando espaço para que os SDKs detectem e previnam fraudes publicitárias e tráfego inválido, onde os desenvolvedores permitirem.
O Google agora é seu mensageiro, SDKs
No modelo antigo (o atual), os aplicativos e SDKs se comunicam sem impedimentos. Afinal, eles existem no mesmo espaço e podem conversar quando e como quiserem.
No novo mundo, que o Google disponibilizará em versão beta até o final de 2022, o Google criará uma "camada de serialização" que os desenvolvedores poderão chamar de dentro de um aplicativo.
- O aplicativo precisa do SDK para funcionar.
- O código do aplicativo chama a camada de serialização e entrega um pacote
- A camada de serialização entrega a solicitação ao SDK (presumivelmente verificando primeiro sua legitimidade)
- O SDK envia uma resposta de volta para o serviço de serialização
- A camada de serialização completa o ciclo com os dados ou funcionalidades necessários para o aplicativo
Um ponto importante: isso pode ser assíncrono. Conforme definido atualmente pelo Google, o “SDK atende às solicitações de forma assíncrona e responde usando callbacks”. Isso pode potencialmente interferir em funcionalidades que exigem resposta instantânea, o que é um pouco confuso: praticamente tudo em um aplicativo requer resposta instantânea, pois o aplicativo precisa apresentar opções aos usuários e, em seguida, fornecer respostas com base em suas decisões e entradas.
No entanto, tudo isso ainda está em fase pré-beta, então não há motivo para se preocupar muito com isso por enquanto.
Além disso, o Google está implementando funcionalidades para comunicação entre SDKs em cenários como mediação e lances. Essa é uma parte essencial do ecossistema de adtech para mobile , com redes de SDKs que oferecem serviços de mediação, como os novos gigantes do setor : ironSource, Liftoff+Vungle, AppLovin, Digital Turbine e Unity. O Google afirma que os SDKs poderão oferecer impressões de anúncios ou realizar leilões de anúncios comunicando-se com outros SDKs, estejam eles dentro ou fora do ambiente de execução do SDK.
No entanto, há claramente questões em aberto: observe a linguagem usada pelo Google, como "deveria" e "investigação".
“O SDK de coordenação, habilitado para tempo de execução (RE) ou não, deve ser capaz de acessar todos os SDKs, RE ou não, para operação normal. A renderização, neste contexto, é uma área ativa de investigação.”
Desenvolvedores de SDK: preparem-se para enviar
De certa forma, os criadores de SDKs têm recebido um tratamento diferenciado. Enquanto os próprios aplicativos precisam passar por um processo de aprovação na App Store do iOS ou no Google Play, os SDKs simplesmente passam por esse processo sem grandes dificuldades, graças aos esforços de seus clientes ou desenvolvedores.
Provavelmente não mais.
Considerando o ambiente de execução isolado e exclusivo em que os SDKs agora existirão, o Google propõe que os desenvolvedores de SDKs os enviem para o Google Play e, em seguida, os disponibilizem para uso pelos aplicativos por meio do próprio Google Play. O Google afirma que isso garantirá qualidade e consistência, simplificará a publicação e tornará as atualizações menores de SDKs — que não exigem alterações no código do aplicativo para funcionar — mais rápidas e eficientes.
As ideias do Google aqui são bastante nebulosas, e neste momento a empresa não está afirmando explicitamente que este é o futuro da distribuição para todos os SDKs.
No entanto, os desenvolvedores de software conseguem interpretar as entrelinhas tão bem quanto qualquer outra pessoa, e uma vez que esse mecanismo esteja implementado e disponível, não é difícil imaginar que ele se tornará o método preferido — e com o tempo, provavelmente obrigatório — de distribuição de SDKs.
Há muito mais para explorar
Como mencionei acima, há muito mais para explorar aqui. Inscreva-se em nossa newsletter e ser notificado quando publicarmos mais conteúdo.
Além disso, farei uma transmissão ao vivo com Singular , Gadi Eliashiv, sobre esse assunto na quinta-feira, 24 de fevereiro. Inscreva-se aqui .
Mantenha-se atualizado sobre os últimos acontecimentos em marketing digital
