Em resumo: o compartilhamento avançado de dados de correspondência avançada permite que identificadores de usuário com hash, como e-mail e número de telefone, sejam encaminhados da AppsFlyer para ad networks selecionadas, permitindo que os Parceiros atribuam eventos a engajamentos com anúncios sem um Device ID.
Sobre o compartilhamento avançado de dados de correspondência avançada
À medida que os identificadores de dispositivo se tornam menos disponíveis, as ad networks dependem cada vez mais de dados primários para corresponder a engajamentos com anúncios. O compartilhamento avançado de dados de correspondência avançada resolve essa lacuna encaminhando identificadores com hash para Parceiros compatíveis, em um formato em conformidade com a privacidade.
O recurso é opcional e configurado por parceiro. Quando habilitado em uma network com suporte, a AppsFlyer encaminha identificadores com hash junto com dados de evento de instalações, reengajamentos e eventos in-app.
Importante!
Todos os identificadores devem passar por hash com SHA-256 antes de chegar à AppsFlyer, seja no dispositivo via SDK ou no Servidor via API S2S. Dados em texto simples nunca são recebidos, armazenados nem encaminhados, e qualquer valor que falhe na validação é descartado na ingestão.
Parceiros compatíveis
O compartilhamento de dados de correspondência avançada está disponível para as seguintes networks:
| parceira | Tipo de integração | Eventos suportados |
|---|---|---|
| Google (googleads_int) | OCI | Instalações, reengajamentos, eventos in-app |
| Meta (facebook_int, metaweb_int) | SRN + CAPI | Instalações, reengajamentos, eventos in-app |
| OpenAI (openai_int) | CAPI | Instalações, reengajamentos, eventos in-app |
| TikTok (tiktokglobal_int, tiktokweb_int) | SRN + CAPI | Instalações, reengajamentos, eventos in-app |
| Snapchat (snapchat_int, snapweb_int) | SRN + CAPI | Instalações, reengajamentos, eventos in-app |
| Pinterest (pinterest_int) | CAPI | Instalações, reengajamentos, eventos in-app |
| Reddit (reddit_int) | CAPI | Instalações, reengajamentos, eventos in-app |
| Roku (rokuads_int) | SRN + CAPI | Instalações, reengajamentos, eventos in-app |
O fluxo de ponta a ponta
Veja o que acontece desde o momento em que um identificador é recuperado até o momento em que chega a um parceiro:
- O aplicativo ou backend recupera um identificador (endereço de e-mail, número de telefone ou outro tipo compatível).
- O SDK da AppsFlyer normaliza e aplica hashing automaticamente ao identificador usando SHA-256, ou o servidor faz isso antes de enviá-lo pela API S2S.
- O SDK ou servidor envia o identificador com hash para a AppsFlyer junto com o evento (instalação, reinstalação, reengajamento ou evento in-app).
- Se o Compartilhamento de dados de correspondência avançada estiver habilitado para o parceiro, a AppsFlyer encaminhará o hash junto com a carga útil do evento.
- O parceiro usa o hash para associar o evento a um usuário conhecido, melhorando a precisão da atribuição e a qualidade da correspondência.
Atenção
Identificadores com hash são encaminhados apenas para parceiros em que o Compartilhamento de dados de correspondência avançada está habilitado. Quando a configuração estiver desativada para um parceiro, nenhum dado com hash será compartilhado com esse parceiro, mesmo que haja identificadores no evento.
Como os identificadores de usuário com hash chegam à AppsFlyer
Os identificadores com hash chegam à AppsFlyer por dois métodos: o SDK ou a API servidor a servidor (S2S). Em ambos os casos, apenas valores com hash gerado corretamente são aceitos. As abas abaixo descrevem cada método.
O SDK V7.0.1 introduz um método para transmitir identificadores brutos aos SDKs Android e iOS da AppsFlyer. O SDK normaliza a entrada e aplica hashing antes de enviá-la à AppsFlyer:
O SDK executa as etapas a seguir em sequência:
- Normaliza a entrada de acordo com os requisitos de cada parceiro.
- Aplica hash ao valor normalizado usando SHA-256.
- Envia apenas o valor com hash para a AppsFlyer. A entrada bruta nunca sai do dispositivo.
Valores inválidos são rejeitados pelo SDK com um erro e não são enviados para a AppsFlyer.
Atenção
O suporte para Android e iOS está disponível a partir do SDK v7.0.1.
Para ver detalhes de implementação, consulte o guia de integração do SDK para Android e o guia de integração do SDK para iOS.
Ao enviar eventos pela API S2S de eventos in-app, os identificadores devem ser normalizados e ter hash aplicado no servidor antes do envio. A API aceita os seguintes campos:
| Campo | A descrição |
|---|---|
email_hashed |
Endereço de e-mail com Hashing |
phone_number_hashed |
Número de telefone com Hashing, somente dígitos |
phone_number_e164_hashed |
Número de telefone com Hashing no formato E.164 |
first_name_hashed |
Primeiro nome com Hashing |
last_name_hashed |
Sobrenome com Hashing |
fb_login_id |
ID de login do Facebook (sem Hashing; transmitido como está) |
Importante!
Todos os campos desta tabela (exceto fb_login_id) são validados em relação ao formato SHA-256. Os valores que não correspondem são descartados silenciosamente e não são encaminhados para nenhum parceiro. Os outros campos do evento são processados normalmente.
Por que há dois campos de número de telefone?
As networks fazem a correspondência de eventos comparando o hash que a AppsFlyer encaminha com o próprio hash armazenado do número de telefone do usuário. Como o mesmo número normalizado em um formato diferente gera um hash diferente, os dois lados precisam aplicar hash a partir do mesmo formato para obter uma correspondência. Como as networks normalizam números de telefone de maneiras diferentes e a AppsFlyer recebe valores já com Hashing, ambas as versões devem ser enviadas para cobrir todos os Parceiros suportados.
-
phone_number_hashed: para Meta e Snapchat. Formato de normalização antes do hashing:16501234567 -
phone_number_e164_hashed: para Google e TikTok. Formato de normalização antes do hashing:+16501234567
Normalizar e aplicar hash aos identificadores
Normalize o valor bruto exatamente como descrito abaixo, depois aplique Hashing com SHA-256 e envie o digest hexadecimal em letras minúsculas.
E-mail (email_hashed)
Normalize e aplique hash ao endereço de e-mail da seguinte forma:
- Remova todos os espaços em branco.
- Converta para minúsculas.
- Aplique hash com SHA-256.
Exemplo:
User@Example.COM → user@example.com → hash SHA-256
Número de telefone, somente dígitos (phone_number_hashed)
Use isto para Meta e Snapchat. Normalize e aplique hash ao número de telefone da seguinte forma:
- Adicione o código do país no início.
- Remova todos os símbolos, letras e zeros à esquerda.
- Aplique hash com SHA-256.
Exemplo:
+1 (650) 123-4567 → 16501234567 → hash SHA-256
Número de telefone, E.164 (phone_number_e164_hashed)
Use isto para Google e TikTok. Normalize e aplique hash ao número de telefone da seguinte forma:
- Adicione o código do país no início.
- Remova todos os símbolos, letras e zeros à esquerda.
- Adicione o sinal
+no início. - Aplique hash com SHA-256.
Exemplo:
+1 (650) 123-4567 → +16501234567 → hash com SHA-256
Primeiro nome (first_name_hashed) e sobrenome (last_name_hashed)
Normalize e aplique hash ao nome da seguinte forma:
- Remova todos os espaços em branco.
- Converta para letras minúsculas.
- Aplique hash com SHA-256.
ID de login do Facebook (fb_login_id)
Envie o ID de login do Facebook bruto, conforme fornecido pelo SDK de Login do Facebook. Este campo não recebe hashing.
Ative o Compartilhamento de dados de correspondência avançada
O Compartilhamento de dados de correspondência avançada é controlado por parceiro e por aplicativo e deve ser habilitado explicitamente para cada network.
Para habilitar o Compartilhamento de dados de correspondência avançada:
- Na AppsFlyer, no menu lateral, selecione Collaborate > Active Integrations.
- Pesquise o parceiro e selecione-o.
- Ative Advanced-Matching Data Sharing.
- Clique em Guardar integração.
Quando o Compartilhamento de dados de correspondência avançada está ativado, qualquer evento que inclua um ou mais campos de identificador compatíveis terá esses campos encaminhados ao parceiro.
Atenção
Desativar o Compartilhamento de dados de correspondência avançada interrompe imediatamente o compartilhamento de dados com hashing com esse parceiro. Outras configurações de integração, incluindo postbacks e dados de evento, não são afetadas.
Privacidade e tratamento de dados
Quando o Compartilhamento de dados de correspondência avançada é habilitado para um parceiro, a AppsFlyer começa a encaminhar identificadores de usuário com hashing para essa network junto com os dados do evento. Antes de ativá-lo, confirme o seguinte:
- Existe uma base legal (de acordo com as leis de privacidade aplicáveis, como o Regulamento Geral sobre a Proteção de Dados (GDPR) ou a California Consumer Privacy Act (CCPA)) para compartilhar esses dados com o parceiro.
- Sua Política de privacidade foi atualizada e, quando necessário, o consentimento do usuário foi obtido.
- Suas práticas de compartilhamento de dados estão alinhadas aos termos do parceiro.
Importante!
A AppsFlyer não processa nem armazena Informações de Identificação Pessoal (PII) em texto simples. Todos os campos de identificador são validados no momento da ingestão: valores que não estejam em conformidade com o formato SHA-256 são descartados e nunca encaminhados a nenhum parceiro.
Perguntas frequentes
O compartilhamento de dados de Advanced Matching é o mesmo que o recurso de e-mail e telefone com hash de audiências?
Sem. Esses são mecanismos separados. As audiências criam listas de usuários para segmentação de anúncios. O compartilhamento de dados de Advanced Matching encaminha identificadores com hash com eventos individuais para melhorar as taxas de correspondência no nível do parceiro. A AppsFlyer planeja consolidar os dois métodos, usando o novo método de recuperação de dados tanto para o compartilhamento de dados de Advanced Matching quanto para as audiências.
O que acontece se eu enviar um valor de hash inválido?
O campo é descartado no momento da ingestão e não é encaminhado a nenhum parceiro. Os outros campos do evento são processados normalmente.
Preciso enviar todos os campos compatíveis?
Sem. Só precisam ser incluídos os identificadores disponíveis e relevantes para os Parceiros configurados. Os campos ausentes não são encaminhados.
O Compartilhamento de Dados de Advanced Matching vai melhorar a atribuição de instalação?
A maioria dos Parceiros não usa e-mail com hash nem telefone com hash para correspondência de instalação, reengajamento ou reinstalação. O envio desses campos ajuda principalmente os Parceiros a melhorar a correspondência de eventos in-app no lado deles. Isso não afeta a atribuição da AppsFlyer.
A AppsFlyer alguma vez recebe identificadores de usuário em texto simples?
Sem. Como explicado no aviso "Importante!" perto do início deste artigo, os identificadores sempre passam por hash antes de chegar à AppsFlyer, seja no dispositivo por meio do SDK ou no servidor por meio da API S2S. A AppsFlyer aceita apenas valores com hash.
This article was translated using AI and may contain errors. For the most accurate information, please refer to the English version using the language selector.