You searched for iOS 14 - AppsFlyer

Tudo o que você precisa saber sobre fraudes no iOS 14+

Heloisa Cristina da Conceição — Thu, 26 May 2022 18:26:14 +0000

O lançamento do iOS 14 em abril de 2021 iniciou um processo de transformação em todo o ecossistema de marketing mobile.

De repente, vários recursos foram removidos ou se tornaram extremamente limitados. Limitações ao acesso do ID dos usuários, diferentes prazos de mensuração, a SKAdNetwork (SKAN) e seu mecanismo de valores de conversão, são todos fatores que mudaram completamente o cenário do iOS.

Em um ecossistema que está acostumado com as mudanças, a maioria das empresas se adaptou rapidamente à nova realidade.

Algumas decidiram mudar seu foco e realocar seus orçamentos de marketing, o que gerou uma redução de 25% nos orçamentos do iOS, enquanto outras decidiram adotar uma abordagem inovadora e alterar seus métodos de trabalho para se adequar à nova realidade.

Novos produtos e soluções foram introduzidos ao mercado, em um esforço para solucionar os problemas de privacidade na mensuração. No entanto, uma questão fundamental ainda não foi respondida.

Qual é o status da fraude de anúncios no iOS desde o lançamento do iOS 14?

Para responder a essa pergunta, vamos analisar o panorama geral.

Um panorama multidimensional

Desde o lançamento do iOS 14, a grande maioria das instalações atribuídas na SKAN se originaram de fontes de tráfego direto, sendo que a maioria absoluta do tráfego vem de redes de autorrelato (SRNs) e redes de SDK.

O tráfego das SRNs inclui canais de mídia bem estabelecidos, como Google e Facebook (dentre outros), nos quais, historicamente, as taxas de fraude têm sido significativamente menores do que a média do setor, de quase 0% especificamente no iOS.

O Protect360 analisa todo o tráfego que passa pelo ecossistema da AppsFlyer, independentemente de sua origem, e o mesmo ocorre com as SRNs. Como elas mantêm taxas de fraude muito baixas de forma consistente ao longo do tempo, além do alto nível de comunicação e integração que temos com esses parceiros de mídia, podemos afirmar que elas se encaixam na categoria de “tráfego seguro” quando se trata da fraude de atribuição mobile.

Quanto ao restante das fontes ativas na SKAN, elas podem ser separadas em dois tipos principais de parceiros de mídia: Redes de SDK, que representam 49% do tráfego na SKAN, e outras fontes, que incluem principalmente DSPs e ad networks.

Enquanto as ad networks possuem um volume de tráfego relativamente baixo, e por isso ainda estão testando novas estratégias, as principais redes de SDK do mercado estão mais interessadas em se adaptar à nova realidade da SKAN. Esse ainda é um grupo relativamente pequeno de empresas de mídia que também estão completamente integradas com a AppsFlyer, e historicamente apresentaram um tráfego bastante limpo, com taxas de fraude bem menores do que a média.

Atualmente, esses dois grupos de parceiros de mídia dominam o cenário da SKAN, o que nos faz acreditar que esse novo ambiente da Apple ainda está “livre de fraudes”. Lembre-se de que os dados apresentados acima refletem o mix de mídia atual e podem muito bem mudar no futuro. Por isso, é preciso estar sempre atento.

No entanto, a atividade do iOS não ocorre apenas na SKAN. Ainda há muitas atividades que não dependem apenas desse novo framework. Na realidade, as atividades que ocorrem fora da SKAN correspondem à maioria das atividades no iOS, como mostra o gráfico abaixo:

Para entender isso melhor, vamos explorar como a mensuração pode ser dividida no iOS.

Opções de mensuração de atribuição no iOS

Atualmente, existem três tipos de estruturas de atribuição no iOS que estão disponíveis para profissionais de marketing:

Somente SKAN
É a atribuição de campanhas de aplicativos mobile que dependem somente da mensuração na SKAN.
Somente MMP
A atribuição pode ser feita por meio da correspondência de ID para usuários consentidos (usuários que permitiram que as empresas compartilhassem seu IDFA) ou por meio da modelagem probabilística entre todos os usuários.
Modelo híbrido
A atribuição será feita por meio da combinação entre os dois modelos descritos acima. Nesse cenário, as redes continuam enviando dados de engajamento para seu MMP, mesmo para atividades na SKAN.

Exemplo: quando um publisher relata um engajamento de visualização de um anúncio por um determinado usuário na SKAN, uma URL de impressão também será enviada para o MMP.

O modelo híbrido permite que os anunciantes e parceiros de mídia aproveitem inúmeros recursos de mensuração da AppsFlyer, ao mesmo tempo em que cumprem com os requisitos de privacidade da Apple. No entanto, isso também cria um problema de duplicação nos registros de mensuração. Para resolver esse problema, recentemente lançamos nossa nova solução, o Single Source of Truth (SSoT).

Sempre que uma atribuição de instalação for registrada pela AppsFlyer e pela SKAN, a AppsFlyer registrará a atribuição apenas uma vez, seguindo um processo exclusivo de desduplicação. Assim, nossos clientes conseguem acessar uma única fonte confiável sobre sua atividade.

Monitoramento da fraude com dados limitados

Os clientes da AppsFlyer que usam o Protect360 e que também mensuram suas campanhas no iOS por meio da atribuição probabilística (em modelos híbridos ou somente MMP) continuarão desfrutando da proteção contra fraudes do Protect360.

No momento, quase todos os modelos antifraude e lógicas de detecção do Protect360 podem ser aplicados aos modelos de atribuição probabilística. A lógica antifraudes evoluiu drasticamente ao longo dos anos e não depende mais de identificadores do usuário para detectar padrões de comportamento fraudulentos.

Técnicas avançadas de detecção, como as redes bayesianas, permitem que o Protect360 baseie sua lógica antifraudes em padrões de comportamento de grande escala, aplicando a lógica de detecção em uma única ocorrência, independentemente da identidade específica. Essas técnicas avançadas baseadas em machine learning aprendem com eventos passados e aplicam uma lógica sofisticada para detecção futura com precisão máxima.

O comportamento do cluster de usuários, a análise biométrica e os modelos estatísticos em grande escala utilizam várias técnicas de mensuração que se correlacionam com modelos de atribuição probabilística, aplicando limites de precisão muito rígidos para garantir que a ocorrência de falsos positivos seja mínima.

O uso da atribuição da AppsFlyer também significa que os anunciantes têm total transparência sobre os dados de engajamento e timestamps de data/hora da instalação. Eles não apenas desempenham um papel importante no mecanismo de detecção de fraudes como também fornecem maior valor para os anunciantes, pois podem ser utilizados para análise e otimização adicionais.

É fundamental entender que todos os métodos comuns de proteção contra a fraude estão inclusos no Protect360 diante do novo cenário do iOS, enquanto que confiar exclusivamente na SKAN deixará você muito exposto. Esses métodos incluem:

Flooding de cliques: As duas métricas básicas necessárias para a detecção de flooding de cliques são a quantidade de cliques e o tempo entre o clique e a instalação (CTIT). Essa fraude pode ser detectada com dados completos de cliques que estão disponíveis por meio de MMPs e da atribuição híbrida.

Atualmente, a SKAN não fornece aos anunciantes dados completos de engajamento, impossibilitando a detecção de flooding de cliques.

Injeção de cliques: A detecção de fraudes por injeção de cliques é feita principalmente por meio da análise de anomalias nos timestamps de data/hora do clique e da instalação. Esses sinais só estão disponíveis quando a atribuição do MMP está envolvida, pois a SKAN não relata nenhum dado de timestamp de data/hora para a atribuição.
Instalações falsas: A falsificação de todo o ciclo de atribuição por meio de emuladores, bots ou farms de dispositivos só pode ser detectada por meio de uma análise abrangente de todos os pontos de mensuração disponíveis, como os timestamps de data/hora.

A atribuição do MMP garante que esses dados sejam relatados e monitorados pelo anunciante e pelo Protect360.

Por último, mas não menos importante, o uso do SSoT da AppsFlyer permite que os anunciantes tenham a capacidade de identificar discrepâncias relacionadas a fraudes entre a atribuição da SKAN e a atribuição do MMP.

Vigilância inovadora

Embora tenhamos a lógica, os modelos e a capacidade necessária para detectar fraudes no novo ecossistema do iOS, é fundamental que todos os profissionais da área de marketing participem ativamente do esforço na luta contra a fraude.

Anunciantes e parceiros de mídia devem se esforçar para estabelecer um relacionamento aberto e transparente, garantindo que seus melhores interesses sejam mantidos e que a fraude seja eliminada.

Recomendamos que todos os anunciantes usem da atribuição probabilística da AppsFlyer como parte de suas campanhas ao iniciar as campanhas na SKAN. Isso permitirá a ação da proteção contra fraudes do Protect360 (para clientes do Protect360) e disponibilizará mais recursos de mensuração e insights por meio do SSoT da AppsFlyer e de outras soluções.

Diferentes tipos de cenários de fraude na SKAN têm sido identificados e discutidos por nossa equipe, assim como soluções técnicas e relevantes contra a fraude.

A equipe do Protect360, impulsionada pelas soluções inovadoras da AppsFlyer, como o SSoT, está de olho nos desenvolvimentos do iOS e no ecossistema como um todo, conforme avançamos rapidamente para um futuro centrado na privacidade.

SAIBA MAIS

O status da fraude no iOS 14

Baixe o infográfico

The post Tudo o que você precisa saber sobre fraudes no iOS 14+ appeared first on AppsFlyer.

O impacto do IOS 14 e da ATT sobre o ecossistema mobile

Jonathan Ydov — Thu, 10 Mar 2022 09:23:56 +0000

The post O impacto do IOS 14 e da ATT sobre o ecossistema mobile appeared first on AppsFlyer.

App Clips do iOS 14 – guia definitivo para desenvolvedores

nitzan chen — Wed, 02 Mar 2022 17:12:17 +0000

Introdução

Atualizado após o lançamento do iOS 14

Com o lançamento do iOS 14, nós encaramos os App Clips como um passo inovador para a Apple.

Na AppsFlyer, vemos os App Clips como o futuro e a evolução dos aplicativos, principalmente no caso daqueles que não usamos no nosso cotidiano. Elaboramos esse guia completo para te ajudar a desenvolver seu primeiro App Clip.

Por que fazer App Clips? Bem, por que não?

Vamos supor por um momento que você entra em uma cafeteria e percebe que a fila está bem longa.

Perto do caixa, você vê uma placa te convidando a evitar a fila e comprar seu café pelo aplicativo da cafeteria.

O que você pensaria?

Eu pensaria “claro que não vou baixar um aplicativo que vai ocupar espaço de armazenamento precioso no meu dispositivo”.

Depois, eu questionaria que tipo de dados eles vão coletar sobre a minha vida, que depois serão usados para me enviar spam.

Não, obrigado, eu passo. E tudo isso só para evitar uma fila…

Evitando a fila sem precisar abrir mão da privacidade

Os Apple App Clips estão prestes a mudar a maneira como você pensa. E, além disso, provavelmente vão mudar a maneira como interagimos com o ambiente quando usamos nossos dispositivos mobile. Os App Clips permitem que você realize atividades imediatas, usando instantaneamente o seu dispositivo, sem sacrificar sua privacidade ou compartilhar sua localização.

No exemplo da cafeteria, o QR Code habilita um App Clip no qual você é identificado através de um Apple Sign-in e, assim, você pode realizar sua compra com o Apple Pay, que permite que você complete a compra em poucos segundos, escapando da fila com sucesso.

Os App Clips exigem que os desenvolvedores entendam alguns novos conceitos e façam o desenvolvimento do App Clip junto do aplicativo em si. Ou seja, pode ser que uma reestruturação do app seja necessária.

*Aviso importante

Esse guia se baseia no desenvolvimento real de um App Clip, processo que foi cuidadosamente estudado com base em documentos feitos a partir de uma compilação de todos os vídeos da WWDC 2020 que abordavam os App Clips. Veja o App Clip pareado e completo aqui.

Capítulo 1

O fluxo de Ativação de um App Clip

Esta seção abrange o ciclo de vida do App Clip – desde um usuário que interage com um App Clip até os diversos métodos de transição para o aplicativo completo.

Os App Clips começam quando um usuário interage com uma Ativação (Invocation).

Ativações são um conceito muito importante para os App Clips, a qual explicamos em mais detalhes abaixo.

Vamos supor que um usuário usou uma tag NFC, que é uma Ativação de um App Clip.

Em seguida, isso acontece:

O sistema do iOS detecta que a tag NFC é uma Ativação de App Clip e extrai uma “URL de Ativação”.

A URL de Ativação define a funcionalidade esperada dessa Ativação. Ela será passada para o App Clip junto dos dados necessários para indicar ao usuário qual é a funcionalidade adequada para fazer a manutenção da tag NFC. Se o aplicativo já estiver instalado, ele será iniciado e a URL de Ativação será transmitida da mesma forma como ocorre a transmissão de um fluxo de Universal Link.

Aviso importante para desenvolvedores: A URL de Ativação não será transmitida para o aplicativo completo caso o usuário escolha instalar o aplicativo completo a partir do Card do App Clip ou dos banners do App Clip. Nessa situação, o usuário deve acionar a ativação novamente (ou seja, ele deve escanear o QR code ou clicar na tag NFC). Assim, a URL de Ativação será transmitida em NSUserActivity, como descrevemos acima.

O desenvolvedor pode transmitir a URL de invocação do App Clip para o aplicativo completo usando o armazenamento compartilhado.

Aqui estão alguns exemplos:
1. https://megacoffee.com/buy/paris/table/6 – O App Clip é aberto no menu de compra da filial de Paris, onde a mesa nº 6 já está configurada nas preferências. O usuário se identifica via Apple Sign-in, paga usando o Apple Pay e voilà, o pedido está completo. Esse fluxo requer verificação de localização, explicada em detalhes aqui.
2. https://scooter.me/rent?scooter_id=3456 – O App Clip é aberto no menu “de aluguel” com uma ID de scooter já configurada. O App Clip pode notificar o usuário de que o período de aluguel está prestes a terminar. Esse fluxo requer uma notificação de App Clip, explicada detalhadamente aqui.
O iOS verifica se a URL de Ativação realmente é válida através da leitura de um arquivo Apple-App-Site-Association (AASA) no domínio da URL de Ativação. A configuração do arquivo AASA está explicada em detalhes aqui.
Depois que a URL de Ativação é verificada, o iOS apresenta um Card de App Clip para o usuário.

Um aplicativo pode ter apenas um App Clip associado a ele, mas os desenvolvedores podem criar diversos cards para diferentes experiências do usuário.

Cada Card de App Clip está associado a uma única Experiência de App Clip (as experiências de App Clips estão explicadas detalhadamente no capítulo 5).

O sistema iOS exibe o Card de App Clip da experiência que mais se aproxima da correspondência da URL de Ativação na qual o usuário clicou.

O Card de App Clip é então apresentado pelo sistema, sem envolver nenhuma interação ou código do desenvolvedor.

O Card de App Clip serve para alguns propósitos:

Ele apresenta ao usuário uma introdução geral às funcionalidades do App Clip, que é semelhante à página do aplicativo da App Store em um fluxo de download completo do aplicativo. Por exemplo, isso pode ser representado como uma imagem da cafeteria com uma breve descrição do negócio.
Ele declara as permissões do desenvolvedor e dá ao usuário a opção de desativá-las. Tenha em mente que os App Clips do iOS 14 têm muito poucas permissões, que fazem parte de uma lista muito pequena. Como um bônus adicional, os usuários ganharão confiança no aplicativo graças à rigidez da política de privacidade do App Clip.
Possui um botão de call-to-action, que informa ao usuário as principais funcionalidades esperadas de um App Clip, tais como: alugar, comprar, compartilhar ou fazer check-in, etc.
Ele exibe um pequeno banner que direciona o usuário para a versão completa do aplicativo na App Store.

Quando o usuário clica no call-to-action do card, o iOS baixa o App Clip da App Store. Isso é feito rapidamente, pois o tamanho máximo de um App Clip é de 10 MB.

Como referência, esse é um tamanho bom, considerando que aplicativos mais recentes têm um tamanho médio de 38 MB.

A URL de Ativação é passada para o App Clip por meio do NSUserActivity. O desenvolvedor usa a URL para criar um deep link para as funcionalidades especificadas. O desenvolvedor pode usar parâmetros da URL, por exemplo. Ele também pode extrair o nome da filial e o número da tabela da URL, como no exemplo: https://megacoffee.com/buy/paris/table/

Inicialmente, quando o App Clip for carregado, ele exibirá um banner que direciona o usuário ao aplicativo completo na App Store. O desenvolvedor pode exibir o banner novamente usando o SKOverlay. Veja a explicação detalhada aqui.

Capítulo 2

Ativações e Experiências para os Apple App Clips

Esta seção descreve em detalhes como um App Clip é iniciado (invocado), qual Card de App Clip é exibido, quais dados são passados para o App Clip e como.

Um App Clip é gerado a partir de uma Ativação.

Uma Ativação não é apenas um clique, como você provavelmente sabe que ocorre nos Universal Links.

Uma Ativação é um objeto criado pela Apple, que, atualmente, pode ser criado apenas através das ferramentas e infraestrutura da Apple. Ainda não está claro como é possível obter uma ‘App Clip URL’, que permitiria que você simplesmente enviasse o App Clip via SMS ou colocasse por trás de um código QR (atualizaremos esse processo assim que a Apple oferecer mais informações).

Os métodos de Ativação

Safari Smart App Banner

Os metadados podem ser adicionados ao cabeçalho de um site para criar um Smart App Banner que será exibido no Safari.

Aqui está um exemplo de code snippet que você deve adicionar:

O app-id é incluído caso o dispositivo execute o iOS 13 ou uma versão anterior.

Nesse caso, o banner direcionará o usuário para o aplicativo completo na App Store.

Para esse clique, a URL que apresenta o banner é a URL de ativação.

Mensagens

Quando um usuário compartilha um link para um site que exibe um smart banner, a mensagem irá apresentar um banner que invoca um App Clip.

Nesse caso, a URL de Ativação será a URL do site compartilhada.

Tag NFC

Um clique em uma tag, que possui uma URL de Ativação associada a um App Clip, irá invocá-lo.
Uma URL de Ativação está configurada dentro da tag.
A tag NFC pode ser criada a partir de qualquer ferramenta ou infraestrutura que seja capaz de criar tags NFC legíveis para dispositivos da Apple.
A tag pode ser lida até mesmo quando a tela está bloqueada.

Códigos visuais

Os App Clips podem ser invocados por meio de qualquer QR code, que codifica a URL de Ativação associada ao App Clip.
Para abrir o App Clip, o QR code deve ser escaneado a partir do aplicativo Câmera ou por meio de um leitor de barras nativo da Apple.
A Apple planeja lançar um código visualmente distinto que hospedará uma tag NFC no meio, cercada por um código circular que pode ser escaneado. Um dos objetivos da Apple é familiarizar os usuários do iOS que, ao clicarem ou escanearem esse código, serão direcionados a um App Clip.

Localização

Sugestões baseadas em localização feitas pela Siri – A Apple ainda não compartilhou todas as informações acerca desse método (atualizações por vir).

Mapas

As tags em um mapa podem incluir uma tag que invoca um App Clip. A verificação da URL de Ativação de um App Clip é explicada detalhadamente aqui.

Toda Ativação de App Clip se associa a uma URL de Ativação.

A URL sempre começa com `https://mygreatapp.com/`. `https` é o esquema e `mygreatapp.com` é a hospedagem ou domínio.

O iOS deve verificar a URL de Ativação para ter a certeza de que o publisher do App Clip é realmente dono do domínio. Caso ele não seja, o usuário possivelmente está vulnerável à fraude e outras atividades maliciosas.

Como o esquema é ‘https` (e não ‘http’), a URL de Ativação será verificada com o uso de um certificado SSL, que assegura que o desenvolvedor do App Clip é o dono do domínio utilizado.

O iOS verifica o domínio através do acesso a um arquivo Apple-App-Site-Association (AASA). Esse arquivo costuma ser conhecido por verificar Universal Links para um determinado domínio.

Para verificar App Clips do iOS 14, você precisa adicionar a seguinte seção ao arquivo AASA:

{
“appclips”: {
“apps”: [“ABCED12345.com.fruitstore.feedmeapp.Clip”]
}
…
}

*Aviso importante sobre os arquivos AASA: A Apple anunciou na WWDC2020 que ela pretende melhorar os mecanismos de acesso aos arquivos AASA dos diferentes dispositivos. Ao invés de os dispositivos buscarem o AASA diretamente do domínio associado a determinado aplicativo, a Apple pretende extrair esses arquivos e armazená-los em uma CDN. Os dispositivos irão acessar a CDN da Apple e agregar a busca de arquivos AASA em leituras e operações mais otimizadas.

Como resultado, os App Clips podem aumentar o número de buscas de arquivos AASA, e esse mecanismo proposto pode ajudar a diminuir esse aumento.

(Imagem tirada da App Store Connect)

O estado desse cache em relação às URLs de Ativação definidas para um App Clip específico pode ser encontrado na App Store Connect, em ‘Domain URL Status’.

O domínio criado deve ter um App Clip válido (em ‘HAS APP CLIP’ o valor deve ser ‘YES’).

A coluna do status do cache é o que impulsiona a Ativação do App Clip nos dispositivos dos clientes. Ao clicar em Debug Status, você permite que a Apple acesse o seu arquivo AASA em tempo real e valida as URLs.

Capítulo 3

Experiências de App Clips

Provavelmente, os aspectos mais importantes que você precisa entender sobre os App Clips são as Experiências.

Uma Experiência de App Clip (App Clip Experience) é uma ação oferecia ao usuário, por exemplo, de compra, aluguel, check-in em um hotel e muitas outras. Cada Experiência exibe um Card de App Clip diferente. Caso você queira exibir um Card de App Clip específico, é necessário que você defina uma Experiência específica.

Então, como uma Ativação é combinada com uma Experiência, e como essa combinação exibe o Card de App Clip mais relevante?

Como vimos acima, cada Ativação carrega uma URL de Ativação. O iOS combina a URL de Ativação com as URLs que você registrou como parte da sua Experiência de App Clip. Ele mostrará a Experiência de App Clip junto da URL que tem o prefixo correspondente especificado.

Por exemplo, você poderia criar uma Experiência de App Clip que usa https://myrental.com/rent como URL que cobre outras URLs como https://myrental.com/rent/car, https://myrental.com/rent/suv e assim por diante.

No entanto, se um negócio tiver diversas operações, é recomendado que você faça a configuração da Experiência de App Clip para uma ou mais operações, usando um Card de App Clip e uma URL de Ativação diferente para cada operação.

Por exemplo, https://myrental.com/rent/car/il, https://myrental.com/rent/car/jp, etc.

Experiência Padrão (Default App Clip Experience)

Na App Store Connect, na página ‘new app version’, você deve configurar uma default App Clip Experience e fornecer os seguintes metadados para o card de App Clip:

Uma imagem de capa.
Uma legenda que dê mais informações sobre o App Clip.
Um call-to-action que aparece no botão no qual os usuários clicam para iniciar o App Clip.

Uma Experiência Padrão de App Clip é usada para executar App Clips a partir de Smart Banners e links que os usuários compartilham nos apps de mensagens quando Experiências Avançadas de App Clips não estiverem configuradas.

Nenhuma URL de Ativação é necessária para registrar uma Experiência Padrão de App Clip.

Se o sistema verificar um App Clip, ele exibirá a experiência padrão, mesmo que nenhuma URL de Ativação esteja definida (veja a próxima seção). Novamente, isso é válido apenas para Smart Banners no Safari ou links compartilhados por sites através do app de Mensagens.

Experiência Avançada (Advanced App Clip Experience)

Experiências Avançadas de App Clips oferecem:

Suporte a possíveis Ativações, incluindo Ativações de tags NFC e códigos visuais.
A associação do seu App Clip a uma localização física.
A associação de uma URL de Ativação ao seu App Clip.

Como explicamos anteriormente, isso permite que você use diversos Cards de App Clip para vários cases de negócios. Cada experiência levará a um card específico, que foi customizado na App Store no momento de criação da Experiência de App Clip.

(Imagem tirada da App Store Connect)

Capítulo 4

Desenvolvendo um App Clip

Para testar facilmente os App Clips, nós criamos um exemplo simplificado de aplicativo, demonstrando o uso dos App Clips e sua integração com um aplicativo completo.

O exemplo mostra os seguintes recursos de um App Clip:

Criação de um App Clip.
Direitos de Domínios Associados configurados tanto para App Clips e Universal Links do iOS 14 no aplicativo completo.
Compartilhamento de recursos entre o aplicativo completo e o App Clip.
Extração da URL de Ativação do NSUserActivity tanto no aplicativo completo quanto no App Clip.
Notificações.
Transmissão de dados do App Clip para o aplicativo completo usando um grupo de Apps.
Verificação de localização.
Recomendação do aplicativo completo no App Clip através do uso do SKOverlay.

Capítulo 5

Limitações dos App Clips

A Apple impôs diversas limitações sobre os App Clips para permitir que os usuário aproveitem funcionalidades instantâneas com privacidade e transparência máximas.

Essas limitações servem para oferecer aos usuários maior controle sobre sua privacidade, tendo maior confiança nos padrões de privacidade do aplicativo.

App Clips têm um limite de tamanho de 10MB.
Os App Clips não estão inclusos nos backups do iOS (isso na realidade é mais um recurso do que uma limitação).
As estruturas a seguir não estão disponíveis para os App Clips: CallKit, CareKit, CloudKit, HealthKit, HomeKit, ResearchKit, SensorKit, e Speech. O uso de qualquer uma dessas estruturas em um App Clip não resulta em erros de tempos de compilação, mas suas APIs retornam valores que indicam indisponibilidade, dados vazios ou códigos de erro no tempo de execução.
O Limit App Tracking está sempre habilitado nos App Clips da Apple, para proteger a privacidade do usuário e evitar o rastreamento do usuário em aplicativos e App Clips. Os App Clips não podem solicitar autorização para rastrear um usuário com AppTrackingTransparency, e tanto name quanto IdentifierForVendor retornam uma string vazia.
Os App Clips não podem realizar atividades em segundo plano, como uma rede em segundo plano com URLSession ou manter conexões Bluetooth quando o App Clip não está em uso.
Para proteger os dados do usuário, os App Clips da Apple não podem acessar:
- Dados de movimento e de condicionamento físico.
- Apple Music e Mídias.
- Dados de aplicativos como Contatos, Arquivos, Mensagens, Lembretes e Fotos.
Um App Clip não pode compartilhar dados com nenhum outro aplicativo, exceto com o aplicativo completo correspondente.
Uma limitação importante é o acesso à localização. App Clips não podem solicitar acesso contínuo a dados de localização. Isso pode criar um problema no caso de Ativações associadas à localização geográfica. Por exemplo, no caso da URL de Ativação https://mybigcup/seattle/table/17, é importante verificar se ela se baseia de fato em Seattle, para evitar uma possível confusão na qual o usuário acaba pagando pela conta de outra pessoa. Para isso, os Apple App Clips permitem que os usuários verifiquem a localização do dispositivo dentro do perímetro de um polígono, em vez de acessar um local exato. No entanto, para acesso contínuo à localização, eles podem solicitar a autorização , que é automaticamente resetado às 4h do dia seguinte, horário local.

Capítulo 6

Testando os App Clips do iOS 14

Pode ser complicado testar os App Clips, pois o fluxo de Ativação começa dentro do sistema e envolve a App Store Connect. Portanto, ao criar inicialmente um App Clip, você precisará tomar as seguintes medidas para testar a ativação:

Teste do processamento da URL de Ativação

Um passo essencial para o teste de um App Clip é garantir que a URL de Ativação de entrada seja:

Extraída com sucesso do NSUserActivity.
Processada corretamente segundo os seus parâmetros.
Executada no fluxo correto.

Ao inserir uma URL de Ativação em um teste, você deve seguir os seguintes passos:

Clique em Product -> Edit Scheme…
Configure o Ambiente variável _XCAppClipURL para o valor da URL de Ativação.
Execute o esquema do App Clip no seu destino. O NSUserActivity lembrará desse valor.

Para ver um exemplo desse código, clique aqui.

Testando a aparência de um Card de App Clip usando as Experiências Locais

A aparência de um Card de App Clip é uma parte importante da interação do usuário. Ela é testada na fase inicial do desenvolvimento de um App Clip, em um estágio anterior ao envio do aplicativo para a App Store Connect e antes da configuração do arquivo Apple-App-Site-Association em seu domínio.

A configuração das Experiências Locais (ou Local Experiences) é equivalente à configuração das Experiências Avançadas na App Store Connect.

Limites das Experiências Locais:

Aqui, é impossível invocar a abertura do Card de App Clip Card usando os seguintes métodos:
- QR code (é preciso realizar a leitura usando o leitor de código de barras nativo do iOS)
- Tag NFC
Esse método é compatível apenas com sistemas a partir do iOS 14.2, combinado com o Xcode 12.2 e suas versões mais recentes.
As Experiências Locais substituem as Experiências Avançadas na App Store Connect.
As Experiências Locais somente permitem a abertura de um aplicativo caso ele esteja designado para Desenvolvimento, Ad Hoc, ou TestFlight. Esse método não permite a abertura de um aplicativo que já foi publicado na App Store Connect.

(Imagem tirada de um dispositivo iOS)

Como configurar as Experiências Locais:

Certifique-se de que o seu dispositivo está ativado no modo do desenvolvedor (developer mode).
Conecte seu dispositivo iOS 14.2+ ao Xcode 12.2 ou uma versão mais recente, usando um cabo.
Vá para Local Experiences – Settings -> Developer -> Local Experiences (ana seção ‘APP CLIPS TESTING’).
Crie uma nova experiência, selecionando `Register Local Experience…`
Crie a Experiência da mesma forma como você cria uma Experiência Avançada de App Clip na App Store Connect.

Como invocar uma ativação usando as Experiências Locais:

Adicione um App Clip ao seu dispositivo usando os métodos abaixo:
1. Crie e execute o App Clip usando o Xcode.
2. Crie um arquivo ipa para o App Clip usando a funcionalidade Archive no Xcode, e instale-o no dispositivo.
3. Faça a distribuição do App Clip para os usuários por meio do TestFlight.
Escaneie um QR code usando o leitor de código de barras nativo do iOS ou faça o tag de uma NFC. O QR code e a NFC devem codificar uma URL de Ativação, que substitui a URL definida na Experiência Local. Esse processo corresponde às mesmas regras de substituição das Experiências Avançadas na App Store Connect.

Teste após o envio à App Store Connect

Quando você enviar o aplicativo completo e o App Clip à App Store, você pode definir as Ativações do App Clip na tab TestFlight. Cada Ativação é definida em sua URL de Ativação.

(Imagem tirada da App Store Connect)

Os testadores beta do aplicativo reconhecem as Ativações no TestFlight e executam o App Clip caso uma Ativação tenha sido clicada a partir da URL de Ativação definida no estágio anterior.

Capítulo 7

Conclusão – O here-and-now está aqui

Os App Clips representam um novo estágio da maneira como os aplicativos serão consumidos e desenvolvidos, ao mesmo tempo em que oferecem aos usuários do iOS maiores funcionalidades instantâneas. Isso permite que os designers e desenvolvedores tenham maior liberdade.

A experiência do usuário com App Clips pode ser categorizada em duas fases:

‘Here-and-Now’ – Um App Clip para interações entre o usuário e seu ambiente imediato, que funciona de maneira simples mas altamente segura.
‘On-Going-Universal’ – Um aplicativo completo que permite que o usuário engaje constantemente com as funcionalidades do aplicativo, recebendo notificações e serviços em qualquer lugar do mundo.

A Apple fez um excelente trabalho na criação da infraestrutura para essas duas fases, além de fazer o design de transição ininterrupta entre as fases do App Clip para o aplicativo completo.

Nós acreditamos que muitos negócios podem e devem utilizar essa nova tecnologia, oferecendo maior valor e interações melhores aos clientes e usuários. Fizemos este guia para te ajudar a ampliar seu conhecimento sobre os Apple App Clips.

Para saber mais, visite a documentação oficial dos App Clips.

The post App Clips do iOS 14 – guia definitivo para desenvolvedores appeared first on AppsFlyer.

Um jogo totalmente novo: o marketing dos apps de jogos no iOS 14+ e na SKAN

Michal Wagner — Wed, 02 Mar 2022 12:44:38 +0000

O iOS 14 e a SKAdNetwork trouxeram novos desafios aos profissionais de marketing de jogos.

Como resultado, eles tiveram que reavaliar como mensurar, atribuir e otimizar suas campanhas na era da privacidade.

Para ajudar os aplicativos de jogos a entender como avançar nessa nova realidade, fizemos entrevistas completas com três grandes especialistas de estúdios muito conhecidos: CrazyLabs, Pixel Foundation e Product Madness.

Qual é o conteúdo?

Neste guia, mostraremos os principais desafios e estratégias para os aplicativos de jogos no iOS 14 e como os estúdios que participaram das entrevistas estão lidando com eles, incluindo:

A notificação (prompt) e a pré-notificação – quais técnicas foram utilizadas para aumentar as taxas de opt-in
A otimização do valor de conversão – como dividir os bits e quais insights você pode obter
O timer da SKAN – quando atrasá-lo ou prolongá-lo e quais eventos iniciais podem ajudar na previsão do LTV e do ROAS
E muito mais!

The post Um jogo totalmente novo: o marketing dos apps de jogos no iOS 14+ e na SKAN appeared first on AppsFlyer.

Estratégias para a monetização de apps no iOS 14: o guia completo

Jonathan Ydov — Wed, 02 Mar 2022 12:07:20 +0000

A privacidade se tornou o centro das atenções no marketing de aplicativos, especialmente no iOS 14 — com um grande impacto sobre as tecnologias de mensuração, retargeting, UX e dificultando ainda mais a monetização no iOS para as marcas no geral.

Para te ajudar a entender tudo isso, esse guia oferece dicas, truques e estratégias profissionais da indústria para que você possa explorar o iOS 14 e obter vantagens competitivas novas e ousadas para o seu negócio.

Qual é o conteúdo?

Uma visão geral sobre as mudanças introduzidas com o iOS 14 e o impacto sobre as tecnologias de mensuração.
Bastidores do mecanismo de timer da SKAdNetwork e como superar o desafio do limite de tempo.
Diversas estratégias para dividir os seus 6 bits e fazer com que os valores de conversão funcionem da melhor maneira para você.
Táticas que ajudam na otimização das taxas de opt-in ao IDFA.
O conjunto de soluções da AppsFlyer para iOS 14.

The post Estratégias para a monetização de apps no iOS 14: o guia completo appeared first on AppsFlyer.

Riscos imediatos da fraude no iOS 14 e na SKAdNetwork

roman gertsvolf — Thu, 11 Mar 2021 22:00:00 +0000

Em meio à confusão e às incertezas sobre a SKAdNetwork, uma questão ainda não foi respondida – existe o risco da fraude de atribuição com o novo protocolo de atribuição da Apple?

A Apple introduziu diversos mecanismos antifraude que têm como objetivo impedir diferentes tipos de manipulações de atribuição. Todas as transações que correspondem a um evento da SKAdNetwork são assinadas de maneira criptografada e verificadas pela Apple para comprovar que o postback está ligado a um evento de conversão reconhecido pela Apple.

O postback inclui um ID exclusivo de transação (um identificador único para uma transação, como uma compra ou um re-download) para a detecção de repetições de eventos de conversão válidos.

Os mecanismos acima têm o intuito de validar a autenticidade do postback, mas não validam a autenticidade da interação do usuário (impressão ou clique).

Esses mecanismos podem ser contornados? E os fraudadores conseguem encontrar formas criativas de contornar essas limitações sem serem notados?

Para responder a essas perguntas, vamos analisar os possíveis cenários de fraude de atribuição na SKAdNetwork:

Manipulação de um postback antes que ele chegue ao anunciante.
A assinatura e o ID de transação mencionados acima têm como objetivo evitar casos como esse. No entanto, tanto a assinatura como o ID de transação podem ser falsificados.
Exemplo: O valor de conversão não é parte da assinatura, e o ID de transação pode ser usado mais de uma vez (na esperança de que quem o recebe não armazene todo o histórico de IDs de transação para sempre).
A única solução real para isso é o envio do postback para o seu verdadeiro proprietário – o anunciante.
Manipulação da Apple a partir de uma atribuição errada a nível do dispositivo.
Os exemplos que vamos citar abaixo tratam de casos como esse.

Podemos afirmar que o protocolo de atribuição da SKAdNetwork oferece dados limitados tanto para mensuração como para otimização, ou seja, apenas o aplicativo de origem e o ID da campanha.

Os indicativos de tempo de interação do dispositivo também não estão disponíveis. Esses indicativos são essenciais para a mensuração de intervalos de tempo entre os principais eventos – principalmente o tempo de clique e o tempo de instalação. Sem esse indicativos, tendências normais de comportamento do usuário (que são muito difíceis de serem emuladas em escala por bots) não podem ser definidas – o que elimina os indicativos de comportamento anormal.

Mas, ao tentar identificar possíveis falhas que podem ser exploradas pela fraude, abordamos o problema a partir de outra perspectiva.

Imitar um possível comportamento fraudulento pode nos ajudar a descobrir o caminho de manipulação do fraudador e, em troca, nos permite analisar e identificar potenciais fraquezas enquanto tentamos proteger nossos anunciantes dessas fraudes.

Criação de instalações falsas

Qualquer um que tenha um ou mais dispositivos pode clicar, baixar, engajar com aplicativos e reiniciar seu ID de dispositivo para fazer com que pareça um dispositivo diferente. Isso é, em resumo, uma device farm. Assim que uma solução VPN é introduzida, o endereço de IP do fraudador também pode ser alterado ou ocultado.

Isso pode ser feito na SKAdNetwork?

A resposta curta é: sim.

A SKAdNetwork pode ter eliminado o uso do IDFA, mas o ID de conta de um usuário da Apple ainda é utilizado para fins de mensuração.

Reiniciar o ID de conta da Apple é algo que pode ser feito programaticamente através de diversas ferramentas e serviços, assim, a criação de inúmeros usuários falsos a partir de um único dispositivo é algo muito possível.

Além disso, ao usar um dispositivo desbloqueado, você também elimina a necessidade de usar um aplicativo de publisher, pois pode gerar cliques falsos sem ele.

O protocolo SK registra todos os cliques em um banco de dados interno do dispositivo. Com o conhecimento técnico certo, pode-se facilmente criar um ambiente semelhante a um aplicativo falso que se conecta ao servidor da ad network para obter sua assinatura exclusiva e detalhes de campanha.

Esse ambiente de aplicativo falso pode inserir os detalhes de clique na base de dados do SK – fazendo com que o iOS pense que o clique foi feito em um aplicativo real.

Fraude de atribuição no iOS 14 e SKAdNetwork

Dispositivos desbloqueados também oferecem aos fraudadores a capacidade de controlar programaticamente o timer do SK através desse ambiente de aplicativo falso, o que significa que os postbacks podem ser enviados dentro de 20 ou 30 segundos, e não dentro da janela esperada de 24 horas.

Como essa manipulação do timer ocorre no dispositivo, no qual não há dados de tempo do dispositivo com o qual trabalhar, o anunciante não consegue dizer se o tempo foi adulterado.

As manipulações acima mostram que device farms podem operar em escala, sem precisar de nenhuma interação humana contínua.

Inundando os portões

O flooding de cliques tem como objetivo “inundar” o anunciante com uma onda de relatórios de cliques falsos, na esperança de que um desses cliques seja de alguma forma associado a uma instalação orgânica (quando um usuário baixa o aplicativo por conta própria, sem interagir com um anúncio) ou a uma instalação não-orgânica (um clique que foi artificialmente inserido após o usuários visualizar um anúncio de outro publisher).

A SKAdNetwork atribui crédito por instalações que ocorreram através da Apple App Store. Quando um usuário visualiza um anúncio no aplicativo de um publisher e clica nele, a página do aplicativo dentro da store aparecerá no aplicativo do publisher.

Essa visualização da página da App Store é registrada como um clique pelo protocolo SK.

Quando o usuário baixa o aplicativo da página da App Store e o inicia, a instalação será atribuída ao aplicativo do publisher.

Como esse fluxo pode ser manipulado?

Nossos testes mostram que os publishers podem simplesmente acionar a página da App Store do anunciante para que ela apareça sem que seja necessário um clique de um usuário no anúncio, criando um relatório de cliques falso.

A página da App Store pode ser repetidamente acionada sem um único clique sobre o anúncio, criando um efeito parecido ao do flooding de cliques. Isso é muito semelhante a manipulações comuns, nas quais as impressões dos anúncios são falsamente relatadas como cliques.

Como isso é afetado pela recente adição de visualização completa da Apple?

Com a mais recente adição de visualização sobre o protocolo SK da Apple, o flooding pode se tornar ainda mais fácil. Teoricamente, um fluxo de cliques pode ser validado pela Apple através da verificação do fluxo completo (clique → App Store → instalação).

No entanto, com a atribuição de visualização, que elimina o clique da equação, essa validação do fluxo não pode ocorrer. Qualquer um pode, teoricamente, reivindicar impressões, na expectativa de que as instalações sejam atribuídas.

Com a SKAdNetwork, publishers podem determinar os tempos de início e fim de uma impressão. Embora a declaração oficial da Apple diga que esse período de tempo deve ser superior a 3 segundos, isso não se aplica de forma alguma. Isso significa que os publishers têm liberdade para gerar relatórios de impressão falsos e um flooding de impressões, aproveitando os fluxos de visualização.

Uma maneira ainda mais simples de tirar proveito da atribuição de visualização é o uso do acesso à base de dados do dispositivo mencionado acima, com a inserção de relatórios de impressão falsos – certificando-se de que o publisher seja sempre o único a oferecer a última impressão.

Isso abre a possibilidade para a criação de flooding de cliques ou flooding de impressões, acionando programaticamente relatórios de cliques ou de impressões.

Embora o pop up da página da App Store busque iniciar uma instalação real do usuário que visualiza a página, todas as outras manipulações buscam apenas roubar o crédito por uma instalação orgânica que não se relaciona a uma exposição a um anúncio ou a uma página de aplicativo.

Nossos testes mostram que até mesmo instalações que ocorrem dentro de 24 horas após o relatório de cliques recebem crédito pela atribuição na SKAdNetwork. Além disso, a documentação oficial da Apple menciona uma janela de lookback de 30 dias, aumentando a probabilidade de tal esquema obter sucesso.

Aplicativos de fontes maliciosas, como descrito acima, ainda podem ser identificados e bloqueados pelo Protect360 (a solução de proteção contra fraudes da AppsFlyer), com o uso de diversos métodos de detecção. O comportamento descrito acima ainda se desviará das tendências de comportamento padrão quando visto a partir de uma escala de base de dados ampla o suficiente, mesmo dentro da natureza agregada da SKAdNetwork.

Estamos apenas começando

Estamos entrando em uma nova era da mensuração de atribuição e, por isso, é muito provável que estejamos apenas olhando para a ponta do iceberg em termos de possíveis manipulações e métodos de fraude.

A AppsFlyer está trabalhando em conjunto com a Apple e o ecossistema como um todo para tratar desses problemas à medida que eles ocorrem, além de trabalhar duro para manter um ambiente livre de fraudes nessa nova era da atribuição.

Como pesquisadores da fraude, é nosso trabalho continuar a analisar mais detalhadamente possíveis áreas de fraqueza e identificar como elas podem ser exploradas, para que possamos continuar a nos adaptar e proteger nossos clientes.

Fique atento para mais novidades.

The post Riscos imediatos da fraude no iOS 14 e na SKAdNetwork appeared first on AppsFlyer.

iOS SDK v6.14.0: manifesto de privacidade

Vera Kopylova — Sun, 07 Apr 2024 05:59:18 +0000

Um SDK que contém o manifesto de privacidade da AppsFlyer e inclui o Framework Signature da Apple para XCode, que ajuda desenvolvedores de aplicativos a verificar se o SDK integrado de fato foi emitido pela AppsFlyer.

The post iOS SDK v6.14.0: manifesto de privacidade appeared first on AppsFlyer.

Guia completo para anúncios in-app

Heloisa Cristina da Conceição — Wed, 07 Aug 2024 13:11:38 +0000

Introdução

314,5 bilhões de dólares. Esse foi o valor previsto para o mercado mundial de anúncios in-app (IAA) em 2023 — com a expectativa de um crescimento anual de 10%.

Qual é o motivo desse boom? Em um mundo dominado por downloads gratuitos, os IAAs se tornaram um fluxo de receita essencial para aplicativos mobile, particularmente dos gêneros de jogos, redes sociais e entretenimento.

O que é publicidade in-app?

São anúncios pago exibidos em um app mobile.

Essa estratégia permite que os proprietários de aplicativos vendam um espaço publicitário em seu app para anunciantes, que por sua vez conseguem mostrar anúncios para uma audiência relevante e engajada.

Mas, com tantos aplicativos disputando para conquistar cada centavo nesse espaço, como você pode ter uma vantagem competitiva? Exibir muitos anúncios pode ser uma estratégia atraente, mas a exposição excessiva pode causar mais dano do que trazer bons resultados. Por isso, é importante engajar os usuários e melhorar a experiência oferecida, exibindo o anúncio certo no momento certo.

A boa notícia é que existe uma ampla variedade de formatos de anúncios disponíveis, a depender dos seus objetivos:

Anúncios em banner: excelentes para aumentar o reconhecimento da marca e testar criativos para a aquisição de usuários
Anúncios em vídeo: ideais para storytelling e gerar engajamento

Anúncios de rich media: semelhantes aos banners, mas com mais possibilidades de criativos e interação com os usuários
Anúncios nativos: bons para o engajamento e para gerar confiança, uma vez que combinam com o design da plataforma escolhida pelo usuário

Nesse guia, vamos falar sobre diferentes formatos de anúncios, explorar como a publicidade in-app funciona, falar sobre diferentes modelos de preços e explicar como você pode aproveitar essa fonte de receita.

Capítulo 1

O ecossistema in-app – como funciona?

O ecossistema mobile possui diversos players, cada um com um papel específico.

Do lado da compra, temos:

Anunciantes: são as pessoas que criam aplicativos, agências ou marcas que compram espaço publicitário.
Ad exchanges: funcionam como uma bolsa de valores, permitindo que os anunciantes escolham as audiências desejadas e façam ofertas por elas.
Demand-side platforms (DSP): permitem que os anunciantes acessem o inventário de várias ad exchanges.

No lado da venda, temos:

Publishers: aplicativos que vendem espaço publicitário.
Supply-side platforms (SSP): permitem que os publishers mostrem anúncios para a audiência selecionada.

Ad networks ficam no meio, atuando como intermediárias que vendem o espaço publicitário de um publisher (conhecido como inventário in-app) para diferentes anunciantes.

Além disso, temos também as parceiras de mensuração (MMPs), como a AppsFlyer: uma parte independente do ecossistema (ou seja, que não estão nem do lado da compra nem do lado da venda) e que ajuda os anunciantes a mensurar quais ad networks trazem os usuários mais valiosos.

O processo

O aplicativo que deseja mostrar um anúncio faz um pedido para a ad network, que usa algoritmos avançados para identificar quais anunciantes pagam mais.
Os anunciantes usam o ad exchange para fazer uma oferta pela audiência desejada.
O anúncio é mostrado a essa audiência em tempo real.
As ações do usuário são relatadas de volta para o anunciante: ele recebe um pagamento e pode otimizar futuras campanhas.

Capítulo 2

Vantagens (e desafios) dos anúncios in-app

Uma pesquisa realizada em 2022 mostrou que os usuários mobile nos principais mercados mundiais passam de quatro a cinco horas por dia dentro de aplicativos – o que constitui uma enorme oportunidade para os anunciantes.

Mas será que essa estatística é boa demais para ser verdade? Vamos explorar os prós e contras da publicidade in-app (IAAs). Começando com os prós:

1. Impulsione sua receita

Considerando que mais de 90% dos aplicativos são de download gratuito, os proprietários usam anúncios e compras in-app (IAP) como fontes de lucro.

IAPs podem ser bastante lucrativas quando um aplicativo implementa um modelo de assinatura. No entanto, alguns gêneros, como o de jogos, oferecem compras de baixo valor, enquanto a maior parte dos usuários preferem continuar usando um app gratuitamente, sem pagar por nada. Nesses casos, exibir anúncios entre níveis ou transições pode ser uma boa estratégia, gerando engajamento, impressões e receita sem afetar a experiência do usuário.

2. Aumente o engajamento dos usuários

Enquanto os anúncios mobile mais antigos eram bastante espalhafatosos, agora temos uma variedade de opções para engajar os usuários, que geram awareness e impulsionam a retenção.

Para começar, você deve exibir o anúncio quando o usuário está prestando atenção, mas não durante uma ação crítica. Você pode usar uma segmentação precisa para garantir que os seus anúncios sejam realmente relevantes e até explorar técnicas de gamificação – por exemplo, oferecer recompensas (como moedas no jogo) depois que um usuário assiste um vídeo ou acessa o app por vários dias consecutivos.

3. Impulsione a receita de compras in-app

IAAs e IAPs são métricas que estão diretamente correlacionadas. E, se você conseguir fazer com que elas trabalhem juntas, você estará avançando em direção ao sucesso.

Sabemos que os usuários que se engajam com anúncios in-app têm mais chances de fazer uma compra. Além disso, pesquisas feitas no mercado de jogos mostram que um modelo híbrido de IAA e IAP leva a receitas e a um lifetime value maiores.

4. Alcance seu público ideal

Pessoas que se dão ao trabalho de instalar um aplicativo já estão interessadas e engajadas com o que ele tem a oferecer. Por isso, alinhar seus anúncios com a demografia e os interesses dos usuários significa que você tem mais chances de conquistar resultados: a publicidade in-app tem o dobro do click-through rate dos anúncios mobile na web (0,54% vs. 0,23%).

5. Melhore a experiência oferecida aos usuários

Você pode escolher quando exibir o anúncio e qual formato será usado. Os anúncios in-app são otimizados para o mobile, por isso, eles são exibidos com perfeição aos usuários — o que nem sempre acontece com os anúncios na web.

6. Acompanhe a performance

Para publishers, e mais fácil acompanhar a performance da publicidade in-app do que a da publicidade em sites mobile, pois ela já faz parte das suas mídias. Isso significa que você pode agir rapidamente para otimizar suas campanhas.

Capítulo 3

Importância para os profissionais de marketing

Agora que você já sabe como a publicidade in-app funciona, você pode estar se perguntando como pode comprovar a eficácia da sua campanha.

Mensurar, testar e otimizar

Campanhas in-app bem-sucedidas exigem um delicado equilíbrio entre a ad network ideal, segmentação da audiência certa e precisão dos seus anúncios e mensagens. Se algum desses aspectos estiver fora de lugar, a campanha não atingirá seu potencial completo.

No entanto, ao mensurar cada elemento separadamente, você consegue avaliar quais canais ou criativos trazem os usuários mais valiosos e quais devem ser abandonados ou otimizados. Ou seja, quando você identifica os problemas, você consegue trabalhar para corrigi-los.

O desafio da atribuição

Outro desafio é a atribuição da receita de anúncios, que mostra qual ad network é responsável por trazer um usuário. Por exemplo, uma campanha de aquisição de usuários (UA) traz um usuário que gerou US$2 em IAP, mas que também gerou US$1 com a visualização de anúncios. O valor acumulado é de US$3.

Lembre-se que, com o iOS 14, os desenvolvedores precisam usar a SKAdNetwork, o mecanismo de atribuição agregado da Apple, para mensurar suas campanhas para usuários que não permitem o rastreamento. A SKAdNetwork tem várias limitações que reduzem a quantidade e a qualidade dos dados de LTV e ROAS.

Os dados no nível do usuário são mais avançados e ricos, contendo informações sobre o usuário como indivíduo. Por isso, é importante que você aproveite os dados que você consegue acessar para informar sua estratégia para aqueles que não permitem o rastreamento. Para mais informações sobre a atribuição na era da privacidade, veja esse guia.

Capítulo 4

Modelos de preços

Você pode escolher entre diferentes modelos de preços, cada um com suas vantagens e desvantagens. Por isso, é importante escolher a estratégia de monetização certa para o seu app e sua campanha.

Custo por mil (CPM)

O CPM é o preço que um anunciante paga a um publisher por cada 1.000 (mil) vezes que um anúncio é exibido.

CPM = (custo total da campanha / número de impressões) x 1000

Vantagens: o preço é baixo em relação a outros modelos.

Desvantagens: não há qualquer garantia de que o anúncio gere cliques ou conversões.

Recomendado quando: seu objetivo é aumentar a visibilidade da sua marca.

Custo por clique (CPC)

Com o CPC, o anunciante paga apenas quando um anúncio recebe um clique.

CPC = gasto total da campanha / número de cliques

Vantagens: como anunciante, você sabe quando há um sinal real de interesse – nesse caso, um clique.

Desvantagens: alguns cliques podem ser acidentais, o que significa que você pode acabar pagando sem receber nada em troca.

Recomendado quando: seu objetivo é direcionar o tráfego para o seu aplicativo com um orçamento específico.

Custo por ação (CPA)

Com o CPA, o anunciante paga quando um clique conduz a uma ação específica e predefinida em um aplicativo (como um cadastro ou uma compra).

CPA = total de gastos da campanha / número de vezes que a ação especificada foi concluída

Vantagens: o CPA é uma opção de baixo risco, que oferece a performance pura de uma ação específica.

Desvantagens: é um modelo difícil de escalar e, embora a performance seja importante, não se deve ignorar fatores adicionais como o reconhecimento da marca.

Recomendado quando: você tem uma ação específica que deseja que o usuário faça, como uma compra ou um cadastro.

Custo por instalação (CPI)

Com o CPI, o anunciante só paga quando a ação resulta em uma instalação.

CPI = gasto total da campanha / número de instalações do aplicativo

Vantagens: se você tiver um público específico e nichado, acabará pagando apenas pelos usuários que realmente querem usar o seu app.

Desvantagens: o CPI não informa se um usuário está engajado ou continua usando o seu app. Além disso, instalações de baixo custo atraem usuários de baixo valor e, potencialmente, instalações fraudulentas.

Recomendado quando: seu objetivo é aumentar o número de instalações ou promover e distribuir o seu app a um público mais amplo.

Custo por visualização (CPV)

O CPV é utilizado para anúncios em vídeo. Nesse caso, o anunciante só paga quando um usuário vê o vídeo por um determinado período de tempo.

CPV = custo total da campanha / número de visualizações do vídeo

Vantagens: é um modelo rentável, pois o pagamento só é feito quando alguém mostra interesse no seu vídeo.

Desvantagens: os custos variam de acordo com cada plataforma e, no geral, é mais caro focar em um público específico. Isso significa que usuários que não têm interesse no seu app podem deixar que os seus anúncios sejam reproduzidos e ignorem o seu conteúdo – fazendo com que você gaste o seu dinheiro para nada.

Recomendado quando: você pretende gerar engajamento ou fazer vendas, indo além do reconhecimento da marca.

Capítulo 5

Formatos de anúncios in-app

Há uma série de formatos de anúncios disponíveis, dependendo do que você pretende alcançar:

Banners

Os anúncios em banner são, provavelmente, os mais conhecidos dos usuários. Eles são exibidos no topo ou no fim da tela, junto com o conteúdo do aplicativo. Normalmente, incluem uma imagem, um texto e um botão de call-to-action.

Anúncios em vídeo

Os anúncios em vídeo são pequenos clipes que aparecem antes, durante ou depois de um outro vídeo (por exemplo: o anúncio antes de um vídeo começar no YouTube). Eles são altamente atraentes e têm bons clik-through rates.

Anúncios em vídeo com recompensa

Esse formato costuma ser mais usado por aplicativos de jogos. Quando um usuário vê um anúncio, ele recebe uma recompensa. Esse tipo de anúncio é bom para gerar engajamento, especialmente quando a recompensa aumenta se o usuário assiste esses vídeos em dias consecutivos.

Anúncios intersticiais

Os anúncios intersticiais (também conhecidos como anúncios de tela cheia) normalmente aparecem durante uma transição no aplicativo, por exemplo, entre níveis de um jogo. Eles podem ser anúncios estáticos ou em vídeo.

Anúncios nativos

Os anúncios nativos aparecem no fluxo de conteúdos, por exemplo, no feed de uma rede social, ou como uma recomendação identificada como conteúdo patrocinado. Como eles se misturam com a aparência do aplicativo onde eles são exibidos, os usuários costumam considerá-los mais confiáveis.

Anúncios jogáveis

Os anúncios jogáveis oferecem a oportunidade de “testar antes de comprar”, onde os usuários podem jogar uma mini versão do jogo antes de instalar. Eles são divertidos e interativos, o que faz com que eles conquistem taxas de CPM mais altas para os apps de jogos.

Anúncios em offerwalls

Assim como os vídeos com recompensa, anúncios em offerwalls costumam ser uma página com uma lista de ofertas. O usuário pode escolher uma oferta, como vidas extras ou moedas no aplicativo. Esses anúncios têm taxas de engajamento mais altas, pois eles são ativados pelo usuário e ajudam a ampliar o tempo da sessão.

Capítulo 6

7 práticas recomendadas

No que diz respeito a IAAs, há uma série de dicas e truques que podem te ajudar a alcançar o sucesso.

Testes, testes e mais testes

Para entender qual combinação de fatores entrega os melhores resultados, é importante fazer inúmeros testes.

Teste o formato de anúncio que funciona melhor para cada campanha. Teste diferentes modelos de preços e veja qual é o mais adequado para o seu aplicativo. E, por fim, teste diferentes ad networks e veja quais trazem os CPMs mais elevados.

Siga as diretrizes de privacidade

Com o avanço de preocupações com a privacidade e a evolução dos regulamentos, é fundamental se manter atualizado e garantir que o seu aplicativo funcione de acordo com os requisitos.

Foque nos usuários certos

Se IAAs forem um fluxo de receitas fundamental para o seu app, certifique-se de que os seus esforços de UA façam a segmentação de usuários com base na sua capacidade de rentabilização com anúncios.

Invista em seus criativos

Com tantos concorrentes tentando capturar a atenção dos usuários, visuais atraentes e textos convincentes são cruciais para aumentar o awareness, o engajamento e o retorno. Assim, os testes A/B são uma ótima forma de refinar os seus criativos.

Viewability

De acordo com as diretrizes definidas pelo Media Rating Council e pelo Interactive Advertising Bureau, uma impressão de um anúncio display mobile só é considerada viewable se:

50% ou mais dos pixels do anúncio estavam visíveis
O requisito de pixels foi cumprido durante pelo menos um segundo contínuo, após ad-render.

Sem esses dois requisitos, o seu anúncio não “conta”. Por isso, é fundamental que você faça testes e se certifique de que está cumprindo com esses limites.

Não faça publicidade excessiva

Com a segmentação certa da sua audiência, você pode dividir os usuários entre aqueles que instalaram ou compraram e aqueles que não o fizeram. Tente mostrar anúncios aos usuários que preferem não fazer compras ou pagamentos em vez daqueles que converteram.

Depois que um usuário é convertido, certifique-se de mudar a sua mensagem para focar no reengajamento.

Pense na UX

Lembre-se, o marketing não é sobre você – é sobre os seus clientes. Planeje cuidadosamente os seus anúncios e certifique-se de que eles de fato melhoram a experiência do usuário. Por exemplo, mostrar anúncios durante um vídeo não atrapalha a experiência, mas pode incomodar se um usuário estiver lendo um conteúdo. Da mesma forma, anúncios muito frequentes podem afastar os usuários da sua marca.

Principais conclusões

A publicidade in-app é um fluxo de receitas essencial para os anunciantes, especialmente em um mercado freemium. Para aproveitar as vantagens dos IAAs, lembre-se:

Os anúncios in-app podem te ajudar a aumentar sua receita, gerar engajamento, aumentar as compras in-app e oferecer uma experiência positiva à sua audiência. Os desafios dessa estratégia incluem a competitividade do ecossistema e as dificuldades de mensuração, enquanto os fraudadores e os bloqueadores de anúncios podem prejudicar sua performance.
No lado da compra, os aplicativos solicitam um anúncio através de uma ad network, que vende o espaço de anúncio para o anunciante que faz a maior oferta do lado da venda. Os anúncios relevantes são exibidos para o usuário em tempo real.
Os modelos de preços de IAA incluem CPM, CPC, CPA, CPI e CPV. Eles oferecem uma comparação do custo da sua campanha com o resultado desejado. Assim, o modelo ideal depende dos seus objetivos.
Os formatos de anúncios in-app incluem banners, vídeos, vídeos recompensados, intersticiais, anúncios jogáveis e offerwalls.
Teste diferentes formatos para descobrir quais geram um maior engajamento. Invista nos seus criativos, pense na experiência do usuário e não exagere na publicidade, pois isso pode afastar seus clientes.
Esteja atento a atividades fraudulentas e opere dentro das diretrizes de privacidade e das normas de viewability.

The post Guia completo para anúncios in-app appeared first on AppsFlyer.

Quantos postbacks da SKAN 4 são necessários para maximizar sinais de dados?

safa — Tue, 02 Apr 2024 00:24:34 +0000

Quando a Apple apresentou a SKAdNetwork (SKAN) em 4 de outubro de 2022, o mercado ficou muito entusiasmado. Pela primeira vez, uma atualização significativa da SKAN foi anunciada, incluindo a disponibilização de mais dados, uma melhora nas dimensões dos relatórios de campanhas e janelas pós-instalação mais longas.

No entanto, sua adoção foi lenta, principalmente do lado das ad networks.

Nas últimas semanas, finalmente começamos a ver uma aceleração. Agora, estamos em um momento no qual é muito importante que os anunciantes comecem a configurar seus esquemas da SKAN 4 e que as ad networks finalizem sua implementação.

Como muitos aplicativos e as principais ad networks já concluíram esse processo, agora temos dados suficientes – 240 milhões de postbacks da SKAN 4 de mais de 2.000 aplicativos entre agosto de 2023 e janeiro de 2024 – para compartilhar 5 aprendizados importantes.

1) Adoção: 27% dos postbacks vêm da SKAN 4

Em primeiro lugar, em que ponto estamos em termos de adoção?

Até ao final de janeiro de 2024, mais de 1 a cada 4 postbacks da SKAN (27%) vieram da versão 4. Do lado dos aplicativos, 1 a cada 3 apps com tráfego da SKAN já mapeou os seus esquemas na SKAN 4 – um aumento de 18% só no último mês.

No que diz respeito às ad networks, a situação é mista. Algumas grandes ad networks, como a Unity Ads, X e Mintegral, têm 70% de adoção ou mais, enquanto outras, como a Moloco e a Liftoff, já ultrapassaram os 50%. O Google Ads também está avançando rapidamente, chegando a quase 30%.

No entanto, o Meta e o TikTok ainda estão em modo de teste. Acreditamos que, quando essas ad networks partirem para a próxima etapa, chegaremos a um ponto de virada – quando a SKAN 4 se tornará fundamental.

Sua importância: a SKAN 4 é promissora em comparação com as versões anteriores no que diz respeito aos dados coletados. Com o aumento da sua adoção, os profissionais de marketing devem preparar os seus esquemas agora e pedir a colaboração de seus parceiros de mídia com a sua própria implementação.

2) 20 é o mínimo de instalações por campanha, aplicativo e dia, necessário para os tiers 2 ou 3

A Apple usa o conceito de crowd anonymity para definir como a SKAN 4 fornece dados de atribuição. Assim, o nível de crowd anonymity é determinado para cada postback, seguindo o princípio de que um maior número de instalações resulta no compartilhamento de mais dados.

Veja um resumo no quadro abaixo:

	Postback 1	Postbacks 2 e 3
Crowd anonymity tier 0	Source_identifier com apenas 2 dígitos	x
Crowd anonymity tier 1	Source_identifier com apenas 2 dígitos – valor de conversão parcial	Source_identifier com apenas 2 dígitos – valor de conversão parcial
Crowd anonymity tier 2	Source_identifier com 2, 3 ou 4 dígitos – valor de conversão total	Source_identifier com apenas 2 dígitos – valor de conversão total
Crowd anonymity tier 3	Source_identifier com 2, 3 ou 4 dígitos – valores de conversão totais valuesource_app_ID/ source_domain	Source_identifier com apenas 2 dígitos – valor de conversão total

De acordo com a nossa análise, o valor ideal para atingir os tiers 2 ou 3 é de 20 instalações (postbacks) por campanha, dia e aplicativo. Esse valor se aplica tanto a apps de jogos como de outras verticais, com um nível de precisão de 97%.

Para determinar esse valor, avaliamos a porcentagem de postbacks recebidos em um determinado intervalo de postbacks por campanha (em incrementos de 20). Para uma precisão de 100%, são necessárias 120 instalações, mas esse não é o procedimento recomendado.

Além disso, descobrimos que 5 IDs de aplicativos de origem, ou mais, provavelmente permitem que você alcance o tier 3.

Sua importância: com as restrições de dados, você deve aproveitar tudo o que puder ser acessado – em outras palavras, você deve maximizar seus sinais de dados. Na SKAN 4, isso significa garantir que as suas campanhas diárias sejam grandes o suficiente para evitar valores nulos (tier 0) e garantir que você consiga alcançar o tier 2 ou 3, que incluem mais dados.

O fato de que 20 instalações costumam ser o suficiente é uma excelente notícia para os profissionais de marketing, especialmente para desenvolvedores menores ou para aqueles que realizam muitas campanhas de testes criativos em uma escala muito menor do que suas campanhas normais.

3) O número de postbacks com CVs nulos diminuiu em quase 70% na SKAN 4

A média de postbacks por campanha e por aplicativo com um valor de conversão nulo caiu quase 70% no primeiro postback da SKAN 4 em comparação com as versões anteriores (lembrete: um valor nulo aparece quando o limite de privacidade definido pela Apple não é respeitado).

Embora isso fosse esperado, pois a Apple introduziu um meio-termo na SKAN 4 com os valores parciais no 1º postback, esse não deixa de ser um sinal positivo. O fato de que cerca de 7% dos postbacks voltam com um valor nulo na SKAN 3 era um verdadeiro problema para os desenvolvedores, principalmente porque a Apple nunca divulgou qual é o real limite de privacidade.

Sua importância: mais uma vez, maximizar os sinais de dados é fundamental, e obter um valor de conversão com pelo menos 3 valores parciais para indicar sua qualidade é certamente melhor do que não ter nenhum valor.

4) 82% e 76% dos postbacks de tier 2 e 3 contêm um identificador de origem de 4 dígitos

A tabela que apresentamos acima mostra porque os desenvolvedores e profissionais de marketing devem procurar alcançar o tier 2 ou 3 – há mais dados no 1º postback, incluindo relatórios de campanha bem mais granulares, com um identificador de origem de 4 dígitos.

A diferença entre identificadores de origem de 2 e 4 dígitos é significativa – de 100 a 10.000 opções de relatório. É importante lembrar que a ad network é responsável por usar essas opções (e não a MMP ou o anunciante) para obter uma maior granularidade nos relatórios.

Podemos ver que 82% dos postbacks no tier 2 contêm 4 dígitos de source_identifier, enquanto 76% dos postbacks no tier 3 também têm 4 dígitos.

Na vertical de jogos, os postbacks do tier 2 têm uma maior probabilidade de ter 4 dígitos do que os do tier 3, enquanto em outras verticais observamos o contrário.

Sua importância: em resumo, mais dígitos equivalem a mais opções para a elaboração de relatórios de campanha: em termos geográficos, análise do posicionamento do anúncio (feed ou reels, por exemplo), análise criativa (qual asset foi exibido), etc. Isso também demonstra por quê a precisão de 97% é boa o suficiente: pois o tier 2 é suficiente para que você receba 4 dígitos na maioria dos casos.

5) Mapeamento do esquema de valores de conversão na SKAN 4: o que e quando mensurar

Apesar das melhorias, o volume de dados continua limitado. Por isso, é importante que você escolha cuidadosamente quais métricas mensurar.

A análise dos dados dos primeiros 2.000+ aplicativos que já configuraram o seu esquema na SKAN 4 nos dá uma boa direção. Na SKAN 4, essa análise é particularmente importante, uma vez que existe uma lógica por trás da escolha de quais eventos devem ser configurados e quando, que permite a configuração do nosso esquema para diferentes períodos de tempo de diferentes postbacks.

Por exemplo, podemos ver uma porcentagem muito maior de mapeamento de um evento de “nível completo” em jogos no 1º postback em comparação com o 2º e 3º postbacks. Talvez a necessidade de obter esses dados iniciais seja utilizada para prever um valor futuro. Ou, em apps de finanças, um evento de compra é muito mais popular em uma fase mais avançada da jornada do consumidor.

Sua importância: O mapeamento do seu esquema de valores de conversão pode te ajudar a mensurar as métricas necessárias para atingir seus objetivos. E, embora as opções ainda sejam limitadas, você terá mais possibilidades de obter dados mais granulares que podem te ajudar a criar o funil ideal.

Lembre-se: o SSOT pode te ajudar com os limites da SKAN 4

A Apple ouviu o recado ao criar a SKAN 4: claramente, essa é uma versão significativamente melhor em comparação com a SKAN 3.

Dito isto, ela ainda não resolve o problema de grupos de dados isolados: as instalações de outras fontes não são desduplicadas, os dados são enviados com atrasos (de até 144 horas), os valores de conversão oferecem uma granularidade limitada, os relatórios são reduzidos pelo crowd anonymity e a atribuição web-to-app só é compatível com o Safari.

Para preencher essas lacunas, é necessária uma única fonte confiável (o SSOT) para otimizar a performance das suas campanhas no iOS. Essa solução oferece dados consolidados, incluindo mídias próprias, orgânicas e do Apple Search Ads, oferece dados modelados de métricas pós-instalação, não depende do crowd anonymity e funciona em todos os navegadores.

Resumindo

A SKAN 4 introduz muitas oportunidades, mas, ainda assim, os maiores desafios se encontram nos detalhes. Conhecer esses detalhes – por exemplo, quantas instalações são necessárias para alcançar o tier 2 ou 3 – pode te ajudar a maximizar o volume de sinais de dados, otimizando totalmente as suas campanhas no iOS.

Recomendamos que você não espere que as outras ad networks finalizem a sua implementação. Configure o seu esquema na SKAN 4 e peça a colaboração dos seus parceiros de mídia.

The post Quantos postbacks da SKAN 4 são necessários para maximizar sinais de dados? appeared first on AppsFlyer.

Unificando o engajamento com anúncios: o caminho para a padronização

safa — Wed, 29 Nov 2023 15:35:39 +0000

Em um mundo digital que não para de evoluir, o poder de diferentes criativos de anúncios não pode ser subestimado. Formatos inovadores, como os anúncios em vídeos curtos, jogáveis ou que podem ser pulados, revolucionaram a forma como as marcas se relacionam com suas audiências. No entanto, ainda que os anunciantes e os usuários tenham abraçado a nova realidade, o ecossistema não acompanhou essa variedade de engajamentos.

Há alguns anos, alertamos sobre a necessidade de padronizar a mensuração de visualizações e cliques em anúncios mobile. Na época, o grande desafio era a falta de transparência, pois as métricas de cliques e visualizações muitas vezes não capturavam toda a diversidade de comportamentos dos usuários. A indústria reconheceu esse problema, mas o progresso foi lento.

Desde então, a publicidade passou por uma transformação significativa, trazendo uma série de novos formatos de anúncios que oferecem experiências mais interativas e atraentes. Agora que entramos na era da privacidade, a qualidade dos criativos se tornou ainda mais importante, colocando as métricas de engajamento em uma posição de destaque para os anunciantes.

Atualmente, o desafio vai muito além da transparência: os anunciantes precisam de métricas enriquecidas para impulsionar seu sucesso. Boas ferramentas de mensuração oferecem sinais aprimorados de ad networks, resultando em anúncios mais relevantes. Consequentemente, isso gera um aumento no retorno sobre o gasto com anúncios (ROAS) e facilita o processo de tomada de decisões. O efeito flywheel garante que a mensuração continuará impulsionando o avanço e o sucesso da indústria mobile.

Hoje, a padronização das métricas de engajamento com anúncios deixou de ser uma opção para se tornar uma necessidade.

A origem do problema

As raízes dessa questão se encontram na fase inicial da publicidade digital, quando conceitos como cliques e impressões foram adaptados da web. A princípio, essas métricas serviam para avaliar a interação dos usuários com simples banners. No entanto, à medida que o ecossistema mobile evoluiu, a inadequação desse modelo ficou cada vez mais evidente.

Além disso, a limitação dessas métricas tradicionais colocou algumas ad networks em uma posição desafiadora. Na tentativa de fornecer bons resultados aos anunciantes, elas se depararam com a dura realidade de que certas “visualizações” apresentavam um engajamento do usuário bem mais significativo do que outras.

Diante do dilema de afirmar que esses engajamentos eram apenas “visualizações” (um sinal relativamente inferior, que pode indicar uma baixa exposição) ou defini-los como “cliques” (um sinal mais robusto associado a respostas diretas), algumas ad networks optaram pelo segundo caso.

A padronização dessas práticas destacou a importância de uma abordagem mais estratégica à mensuração do engajamento com anúncios, trazendo uma resposta aos desafios enfrentados até então.

É importante destacar que empresas como o Media Rating Council (MRC) e o Interactive Advertising Bureau (IAB) fizeram grandes esforços para padronizar as métricas de visualização. No entanto, as medidas estabelecidas não foram adotadas de forma universal.

Assumindo a liderança

Em vez de aceitar que o ecossistema se fragmentará em contradições, resolvemos ser proativos.

Nos juntamos a gigantes da indústria como o TikTok, Snap, Unity, Liftoff, Moloco, Digital Turbine e Chartboost para definir um novo padrão de qualidade que promete revolucionar a mensuração do engajamento com anúncios.

Acreditamos que devemos trazer clareza em vez de acrescentar mais complexidade e estamos assumindo a liderança para garantir uma visão clara, transparente e padronizada.

Nossa jornada começou com uma análise detalhada das diferentes definições dessas métricas, participando de conversas com especialistas e clientes, além de deliberações internas rigorosas. Nossos resultados revelaram uma falta gritante de consistência na mensuração. Muitos anunciantes não conhecem essas variações de engajamento e, às vezes, há falta de clareza mesmo entre as ad networks que atuam como intermediárias nesse processo. Assim, a necessidade de uma padrão universal é inegável.

Juntos, fizemos avanços consideráveis e estamos criando um conjunto de frameworks de engajamento qualitativo, uma lógica de atribuição e fluxos de integração que serão introduzidos em breve. Esse marco estabelece uma referência para a transparência e confiança em nosso ecossistema.

Esse novo padrão de qualidade não é estático; ele evoluirá com o tempo. Nos comprometemos a ouvir o feedback e seguir as atualizações da indústria, refinando e melhorando esse modelo para garantir sua relevância, eficácia e responsabilidade com as mudanças do ecossistema. Essa é uma jornada contínua de aperfeiçoamento, adaptação e evolução, tudo com o objetivo de fornecer as ferramentas mais eficazes para a mensuração do engajamento com anúncios.

Vamos falar um pouco mais sobre 2 tipos de engajamento que fazem parte das métricas que serão mensuradas seguindo esse novo padrão:

Visualização ativa

Uma visualização ativa ocorre quando uma interação significativa é identificada. Por exemplo, quando um usuário assiste a um mínimo de X segundos ou mais (a duração específica ainda será definida) de um anúncio que pode ser pulado, ou quando a visualização é concluída em menos de X segundos. Isso inclui vários cenários, incluindo anúncios em vídeo e SKOverlay.

Visualizações ativas em diferentes formatos de vídeos

Clique ativo

Um clique ativo é aquele no qual o usuário permanece em um mesmo contexto, garantindo uma interação contínua com o anúncio sem que ele seja redirecionado para a loja de aplicativos ou para outro app. Os exemplos incluem o redirecionamento para uma landing page, engajamentos em redes sociais como likes, comentários ou compartilhamentos e anúncios jogáveis.

Cliques ativos em anúncios jogáveis – também inclui likes, comentários e compartilhamentos

Junte-se ao movimento

O que temos pela frente é um esforço de colaboração generalizado. A AppsFlyer, juntamente com nossos parceiros, convida outras empresas a se juntarem à discussão, colaborando para definir o futuro da mensuração e a adoção universal de um novo padrão de qualidade. Juntos, podemos trazer transparência ao ecossistema, fornecendo uma mensuração completa e abrindo o caminho para estratégias mais eficazes.

Estamos empenhados em esclarecer uma das áreas menos transparentes da nossa indústria.

É hora de agir. O futuro da mensuração está aqui, e queremos que você faça parte dele.

The post Unificando o engajamento com anúncios: o caminho para a padronização appeared first on AppsFlyer.