Novidades do AdAttributionKit

Olá! Meu nome é Mike. Sou engineer na equipe App Store Engineering. Hoje vou compartilhar novos recursos do AdAttributionKit para desenvolvedores de apps promovidos. Olá! Meu nome é Yuchi. Sou engineer na equipe Commerce Engineering. Vou falar sobre os novos recursos para consumidores de postbacks para configurar a atribuição e receber novos dados.

Na Apple, acreditamos que privacidade é um direito fundamental. Por isso, criamos o AdAttributionKit para ajudar os anunciantes a avaliar o sucesso das campanhas publicitárias e manter a privacidade dos usuários. Vou começar mostrando como o AdAttributionKit funciona. Um fluxo AdAttributionKit consiste em três partes diferentes. A rede de anúncios é responsável por criar e fornecer conteúdo de anúncio a um app editor.

O app editor cuidará da exibição de um anúncio para o app promovido. Por fim, o app promovido avalia o engajamento a partir de ações que as pessoas tomam no app. Cada agente desempenha um papel em pontos diferentes em um fluxo do AdAttributionKit. Um fluxo começa com uma rede de anúncios criando um conteúdo para um app. Em seguida, ela entrega o payload ao app editor, que exibirá um anúncio para alguém.

Alguém pode interagir com um anúncio visualizando-o ou tocando nele, o que leva a uma conversão de instalação ou reengajamento.

Em uma conversão de instalação, alguém instala o app na App Store ou outro marketplace como resultado da interação com o anúncio.

As conversões de reengajamento ocorrem quando alguém interage com um anúncio de um app já instalado, indo diretamente para o app promovido.

Depois da conversão, o anunciante avalia as interações e o engajamento das pessoas dentro do app. Após o período de conversão, os dados das avaliações de conversão e engajamento são transmitidos na forma de um postback para a rede de anúncios. E isso completa um fluxo do AdAttributionKit. O AdAttributionKit foi lançado com o iOS 17.4 e inclui suporte para conversões de instalação. Adicionamos suporte para reengajamento no iOS 18. Para saber mais sobre como começar a usar o AdAttributionKit, confira nossa sessão da WWDC24, “Conhecer o AdAttributionKit”. Com isso em mente, vamos mostrar os novos recursos para melhorar diferentes partes do fluxo.

Se você é desenvolvedor de um app promovido, vou mostrar recursos novos e poderosos para fluxos de avaliação e teste que podem ser usados no app. Se for uma rede de anúncios ou consumidor downstream de dados de postback, Yuchi compartilhará melhorias para fluxos de atribuição e novos dados em postbacks.

Dividimos essa palestra em quatro partes. Primeiro, vou abordar as tags de conversão, que permitem avaliar a conversões de reengajamento sobrepostas no seu app.

Depois Yuchi vai mostrar como personalizar as regras de atribuição para seu app e detalhar os novos dados geográficos que adicionamos aos postbacks.

Para terminar, vou mostrar como testar sua implementação do AdAttributionKit com o novo recurso em Ajustes do iOS.

Vamos falar como você pode avaliar períodos de conversão sobrepostos.

Vamos ver o fluxo de reengajamento dentro do nosso diagrama completo.

Até o iOS 18.3, seu app só podia ter uma conversão de reengajamento ativa.

A partir do iOS 18.4, ele poderá ter vários períodos de conversão de engajamento ativos ao mesmo tempo. Ele também pode receber tags de conversão, que é tipo um marcador de conversão. Você pode usar tags de conversão para definir a conversão de reengajamento a ser atualizada. Vamos analisar um cenário em que você usaria tags de conversão. Como desenvolvedor, você pode veicular várias campanhas de reengajamento para promover diferentes promoções no seu app.

Um cliente pode ver um anúncio de um produto com desconto no seu app e decidir tocar nele. Essa interação vai direcioná-los em seu app e criar uma conversão de reengajamento no sistema. Depois de alguns minutos, eles saem do seu app sem comprar o item. Continuando o cenário, algumas horas depois, o mesmo cliente vê outro anúncio promovendo outro item com desconto no seu app e decide tocar nele. Isso cria outra conversão de reengajamento no sistema. Depois de algum tempo, eles decidem voltar e comprar o primeiro item com desconto. Com as tags de conversão, você pode atualizar o valor de conversão para a conversão original do Desconto 1. Isso será muito útil se você veicular campanhas de reengajamento para vários produtos no app ao mesmo tempo. Para começar a avaliar os períodos de conversão sobrepostas, defina EligibleForAdAttributionKitOverlappingConversions como YES no Info.plist do seu app.

Sem isso, as conversões anteriores continuarão sendo bloqueadas quando sobrepostas, como antes.

A seguir, vou mostrar como gerar tags de conversão no app.

Depois de ativar no app, as tags de conversão serão anexadas ao URL de reengajamento que o AdAttributionKit entrega ao app em um novo engajamento. URLs de reengajamento são links universais enviados para as APIs quando um anúncio personalizado ou StoreKit renderizados estão na tela. A tag é enviada como o valor do parâmetro aberto de reengajamento do AdAttributionKit. Neste exemplo de URL, a tag é igual a 1.

Quando o app recebe um URL de reengajamento, você pode extrair a tag de conversão com uma função assim. Vou detalhar o que acontece aqui. Primeiro, a função obtém os componentes da URL que foram passados com URLComponents. Ela obtém a lista de itens de consulta. AdAttributionKit sempre adiciona um parâmetro de abertura de reengajamento se o app foi aberto em um novo engajamento.

Depois ele examina a lista de parâmetros de consulta anexados na URL. Se encontrar o parâmetro de abertura de reengajamento no URL, retornará o valor desse parâmetro. Se não, a função retornará zero.

Agora que você tem uma tag de conversão, pode usá-la para atualizar essa conversão diretamente.

É recomendável associar as tags de conversão à conversão de reengajamento que a criou para vincular eventos significativos que ocorrem como resultado dessa conversão.

Armazene a tag de conversão no seu app ou em um armazenamento de dados no lado do servidor. Depois que um cliente executar uma ação no app que você quer avaliar para essa conversão específica, obtenha a tag dessa conversão.

Agora vou mostrar como usar uma tag de conversão para fazer uma atualização para uma conversão no código.

Essa função usa um valor de conversão na tag de conversão para atualizar um postback. Ao inicializar PostbackUpdate, passe a tag de conversão para a conversão que você deseja atualizar. Depois pode chamar a API Postback para atualizar o valor de conversão.

Também pode chamar a API updateConversionValue sem uma tag de conversão, e o sistema atualizará os postbacks de conversões mais recentes. É assim que você pode usar tags de conversão para atualizar postbacks quando tiver períodos de conversão sobrepostos. Avaliar os valores de conversão para postbacks é apenas um recurso do AdAttributionKit. Interpretar os dados de postback que você recebe downstream é outro aspecto importante e pode ajudar a embasar as decisões de marketing a serem tomadas para seu app. Yuchi, tem algo para compartilhar sobre isso? Tenho, sim. Aqui estão alguns novos recursos que ajudarão você a consumir e interpretar melhor os dados de postback. Para capturar os sinais mais significativos nos seus dados de postback, adicionamos a capacidade de personalizar as regras de atribuição para ajustar seu fluxo de atribuição.

Há duas maneiras pelas quais você pode ajustar o fluxo de atribuição. A primeira é o período de atribuição configurável.

Voltando ao fluxo completo de atribuição, o AdAttributionKit realiza a atribuição com base na recência e no tipo de anúncio.

Os dois tipos de anúncio compatíveis são anúncio de clique e de visualização completa.

Tipos diferentes geralmente segmentam um tempo diferente. Por exemplo, um anúncio de clique pode segmentar conversões em até 10 dias. E quando uma conversão acontece depois do período desejado, digamos 20 dias após o tempo de exibição da impressão, ela não deve mais ser considerada impulsionada por esse anúncio. E esse período de segmentação de anúncios é o que chamamos de período de atribuição. O período de atribuição começa na hora de exibição do anúncio até o último momento em que ele ainda pode ser considerado para atribuição. Se a conversão acontecer dentro do período, o anúncio competirá pela atribuição dessa conversão. Se não, esse anúncio não competiria pela atribuição dessa conversão. Antes, todos os anúncios clicados com menos de 30 dias e anúncios visualizados com menos de 1 dia eram considerados para atribuição. Queríamos tornar esse período flexível, então estamos introduzindo o período de atribuição configurável.

Como anunciante, você pode especificar a duração desejada do período de atribuição no Info.plist. Este exemplo usa um JSON para ilustrar as configurações, mas as mesmas chaves e estrutura podem ser usadas ao editar o Info.plist do app. O período de atribuição pode ser definido por rede de anúncios e tipo de interação, como visualização ou clique. Aqui está um exemplo. Para a rede de anúncios com.example.adNetwork, o anunciante especificou um período de dois dias para anúncios de clique e um dia para anúncios de visualização. Se um parceiro da rede de anúncios usar principalmente um tipo de anúncio, convém ignorar os outros tipos de anúncios dessa rede. Para isso, especifique a chave ignoreInteractionType. Ela pode ser definida como view ou click, nunca ambas. Se você trabalha com várias redes de anúncios, especificar a duração do período individualmente pode ser trabalhoso. Você pode especificar uma duração para todas as redes com as quais trabalha adicionando a chave global, aplicada a todas as redes por padrão. Além da duração total do período, você pode configurar a duração do período de atribuição para redes específicas, que terá perioridade sobre a configuração global. Se nenhuma rede ou configuração global for encontrada, usaremos à duração padrão que usamos hoje. No exemplo, o período de atribuição para anúncios de clique em com.example.adNetwork será de cinco dias, e os anúncios de visualização dessa rede serão ignorados. Para todas as outras redes, o período de atribuição para visualização será de três dias. Observe que o conceito de período só se aplica a anúncios de instalação, não aos de reengajamento. Isso ocorre porque as interações e conversões de anúncios de reengajamento acontecem uma após a outra, sem intervalo. A segunda forma pela qual você pode ajustar seu fluxo é o período de espera configurável. Vamos revisitar o fluxo completo de atribuição de anúncios. Vamos focar a avaliação de engajamento após uma conversão em anúncios. Após uma rede veicular um anúncio e ocorrer uma conversão, há um período para que os anunciantes avaliem o engajamento do usuário. Chamamos de período de conversão. Os anunciantes podem avaliar o valor da conversão com base nas atividades realizadas no app, como assinatura e compra dentro do app, chamando a API updateConversionValue.

Muitas dessas atribuições podem acontecer simultaneamente para o mesmo app promovido no mesmo dispositivo. E os períodos de conversão podem se sobrepor, nesse caso, uma avaliação pode não ser registrada para a conversão adequada.

Vamos a um exemplo mais concreto. Alguém clicou em um anúncio e baixou o app promovido e, mais tarde, fez uma compra dentro do app, resultando na avaliação de alto valor para usuários em relação ao anúncio de instalação. Mas imagine que logo após a instalação do app, a mesma pessoa tocou em um anúncio de reengajamento e abriu o app. Depois, a compra dentro do app que deveria ter sido atribuída ao anúncio de nstalação foi atribuída ao anúncio de reengajamento. Esse pode não ser o objetivo de mensuração desejado.

O mesmo cenário pode ocorrer para um anúncio de reengajamento que acompanha outra conversão de reengajamento. O que teria sido atribuído ao primeiro anúncio de reengajamento, agora será atribuído ao segundo. Para evitar isso, convém definir um período após cada conversão para bloquear outro sinal e usar esse período apenas para avaliar o valor dos anúncios que geraram a conversão. Esse é o período de espera de atribuição configurável. Esse período pode ser especificado por tipo de conversão. Ele começará a partir de cada conversão desse tipo, e todas as outras conversões que aconteceram antes de esse período terminar totalmente não serão atribuídas a nenhuma conversão. Você pode especificar a duração desejada do período de espera no Info.plist. Aqui, um anunciante especificou um período de espera de seis horas para instalação e uma hora para reengajamento. Assim, digamos que alguém clicou no anúncio de instalação e, em seguida, instalou um app no tempo T. E o período de espera para a instalação é de seis horas. Se a mesma pessoa tocar no anúncio de reengajamento e abrir o app quatro horas após a instalação, essa conversão de reengajamento não será atribuída ao anúncio.

Agora se o toque no anúncio de reengajamento e a abertura do app ocorrerem sete horas após a instalação, o reengajamento receberá uma atribuição. Para o período de atribuição configurável e o período de espera de atribuição, o formato JWS permanecerá inalterado para as impressões e os postbacks. Além desses recursos configuráveis, também adicionamos novas informações geográficas aos postbacks que avaliam o sucesso das suas campanhas publicitárias em diferentes países.

De volta ao fluxo completo de atribuição de anúncios. Agora vamos focar os postbacks.

Postbacks são as saídas do AdAttributionKit que transmitem informações sobre a conversão, como atribuição, e a avaliação do engajamento do usuário. Postbacks são entregues às redes de anúncios ou ao desenvolvedores dos apps promovidos. Sabemos que anunciantes e redes gostariam de acessar as informações geográficas das conversões para otimizar a entrega de anúncios. Hoje, algumas implementações dependem do identificador de origem dessas informações. Com o AdAttributionKit mais recente, o código do país é enviado como um novo campo no postback. Veja o que o código do país representa em diferentes contextos.

Para apps instalados da App Store, o código do país no postback é derivado da região da App Store da qual o app foi baixado segundo o local definido nos Ajustes da Conta. Para conversão de reengajamento, os postbacks usam o mesmo local de quando o app foi instalado inicialmente. No iOS 17.4, marketplaces alternativos podem enviar um token de verificação de instalação para informar um sinal de instalação com dispositivo Apple. O token de verificação de instalação é um JWS com informações sobre a instalação do app, como registro de data e hora do download e o App ID do app baixado. A partir da nova versão do iOS, marketplaces alternativos fornecerão um novo campo para o código do país no token de verificação de instalação. Assine e envie para Apple. Em seguida, a Apple validará o valor e preencherá o código no campo de código do país do postback. O código do país é um campo opcional no token de verificação. Se o sistema não conseguir encontrar um código de país no token de verificação, não haverá código de país no postback.

O valor do código de país para conversão por marketplaces alternativos é limitado aos locais onde esses marketplaces são aceitos.

É assim que o código do país será adicionado ao postback. O código do país será um campo não assinado paralelo a ad-interaction-type, um token JWS assinado e coarse-conversion-value. O campo código do país está sujeito ao algoritmo de anonimato coletivo imposto pelo AdAttributionKit aos postbacks. O algoritmo de anonimato coletivo está no centro da atribuição de anúncios voltada para privacidade, garantindo que os dados individuais sejam mesclados a dados gerais antes de liberar informações identificáveis para o anunciante e a rede.

Os postbacks só conterão o código do país se houver volume suficiente para conversões semelhantes dentro do mesmo país. O nível de anonimato coletivo liberado para o envio do código de país no postback será um nível bônus, além dos quatro níveis de anonimato coletivo aplicados hoje. Isso significa que, em nenhuma circunstância, os anunciantes e as redes perderão os dados recebidos. Isso conclui nossas atualizações nos dados de postback. Mike agora vai falar do novo recurso de teste de AdAttributionKit. Obrigado, Yuchi, por essas informações. Agora que abordamos todos os novos recursos do AdAttributionKit, vou mostrar como testar sua implementação.

Vamos voltar ao diagrama completo e focar a veiculação de anúncios e o fluxo de conversão.

Esse é um fluxo típico que você pode usar ao testar a implementação do AdAttributionKit.

Primeiro, você precisa criar e veicular um conteúdo para o app promovido. Depois, exibir e interagir com um anúncio em um app editor e, em seguida, executar uma conversão de instalação ou reengajamento para criar postbacks de desenvolvimento.

No iOS 18.4, você pode criar postbacks de desenvolvimento para seu app no app Ajustes do iOS.

Postbacks criados com ajustes de desenvolvedor permitem novos testes. Agora você pode testar a atualização de valores de conversão se o app foi criado com o Xcode ou outros mecanismos, como distribuição ad-hoc. Agora você também tem controle direto sobre os dados incluídos nos postbacks. Isso pode ser útil para testar a implementação do servidor para processar várias camadas de dados de postbacks.

Vou mostrar como usar os ajustes de desenvolvedor para criar postbacks.

Antes de começar, verifique se o Modo de Desenvolvimento está ativado. Depois, acesse os ajustes de desenvolvedor em Ajustes.

Nos ajustes de desenvolvedor, role até Teste de Atribuição de Anúncio. Há uma nova página Postbacks de Desenvolvimento acima do Modo de Desenvolvimento do AdAttributionKit. Nela, você verá opções para configurar postbacks para seu app, transmitir todos os postbacks qualificados ou limpar todos os postbacks de desenvolvimento do seu dispositivo. Para configurar postbacks de desenvolvimento, digite o identificador do pacote e toque em Configurar.

O app deve estar instalado no dispositivo para que você possa criar postbacks.

Primeiro, especifique um destino para seu postback. Ele deve ser o URL do seu servidor. Recomenda-se usar um URL de desenvolvimento durante o teste, diferente do URL na qual você recebe postbacks de produção. Você também pode buscar o URL da cópia de postback automaticamente. Use isso para confirmar se o URL conhecido que o sistema gera corresponde o URL que seu servidor expõe.

Depois preencha as propriedades do postback. Você pode configurar o postback para representar qualquer tipo de conversão editando as propriedades.

Agora, você poderá configurar o código do país como uma nova propriedade. Isso ajudará você a testar o código do país em postbacks, o que Yuchi falou.

Depois de configurar as propriedades, você pode ajustar a granularidade dos dados de cada postback. Essa granularidade controla a quantidade de informações enviadas ao servidor. Use isso para validar se a implementação do servidor processa corretamente os níveis de dados de postback.

Quando terminar de configurar seus postbacks, toque no botão para criá-los para seu app.

Agora que seu app tem postbacks de desenvolvimento, você pode atualizar os valores de conversão.

Durante o teste, chame a API updateConversionValue(_:) para atualizar os postbacks de desenvolvimento. Você pode esperar que o postback de desenvolvimento seja enviado ou pode tocar no botão Transmitir Postbacks de Desenvolvimento quando o período de conversão terminar.

Postbacks criados em ajustes de desenvolvedor têm diferenças em relação aos criados em fluxos completos. Vou mostrar as alterações na Assinatura Web JSON do postback.

Este é um trecho do cabeçalho que você receberia no postback.

Postbacks de desenvolvedor usam uma nova chave, indicada por um novo valor kid. Confira nossa documentação sobre verificação de postbacks para obter a nova chave pública para validar a assinatura deles.

Mudando o foco, a carga útil do postback também tem diferenças que vale a pena mencionar. O identificador da rede sempre será definido como development.adattributionkit. Isso ajuda a distinguir ainda mais os postbacks de desenvolvedor dos postbacks de produção.

O identificador do item anunciado no postback também pode ser zero. Por exemplo, se você executou seu app no Xcode durante o teste.

E isso encerra os novos recursos de teste que adicionamos ao AdAttributionKit. Acreditamos que essa nova capacidade de teste ajudará a simplificar o fluxo ao desenvolver e testar a implementação do AdAttributionKit. Falamos muita coisa hoje sobre os novos recursos do AdAttributionKit. Desde a avaliação de períodos de conversão sobrepostas até recebimento de código do país e postbacks, essas atualizações afetam várias partes da atribuição de anúncios. Algumas próximas etapas: Para configurar regras de atribuição para seu app, comece adicionando as novas chaves de configuração ao Info.plist do app. Teste sua implementação do AdAttributionKit desde o início do ciclo de desenvolvimento, antes de levá-la à produção. E se estiver usando o SKAdNetwork, agora é um ótimo momento para migrar para o AdAttributionKit e começar a criar com os novos recursos. Obrigado à comunidade de desenvolvedores pelo feedback sobre os frameworks de anúncios com foco em privacidade. Isso nos ajuda a criar e a pensar em como oferecer boas experiências de anúncios para seu app, mantendo a privacidade do usuário. Nossos agradecimentos!