De un vistazo: la compartición de datos de Advanced Matching permite reenviar identificadores de Usuario con hash, como el correo electrónico y el número de teléfono, de AppsFlyer a las ad network seleccionadas, lo que permite a los Partners atribuir eventos a engagement con anuncios sin un ID de dispositivo.
Acerca de la compartición de datos de Advanced Matching
A medida que los identificadores de dispositivo están menos disponibles, las ad network dependen cada vez más de datos propios para hacer coincidir el engagement con anuncios. La compartición de datos de Advanced Matching cubre esta carencia reenviando identificadores con hash a los Partners compatibles en un formato conforme con la privacidad.
La función es opcional y se configura por Partners. Cuando está habilitada en una red compatible, AppsFlyer reenvía identificadores con hash junto con datos de evento para instalaciones, re-engagements y eventos in-app.
Dos puntos (:)
Todos los identificadores deben someterse a Hashing con SHA-256 antes de llegar a AppsFlyer, ya sea en el dispositivo mediante el SDK o en el servidor mediante la API S2S. Los datos en texto sin formato nunca se reciben, almacenan ni reenvían, y cualquier valor que no supere la validación se descarta durante la ingesta.
Partners compatibles
El alcance de la compartición de datos de Advanced Matching varía según los Partners. Snapchat y TikTok admiten instalaciones, re-engagements y eventos in-app, mientras que Google y Meta se limitan a la coincidencia de eventos in-app. La función está disponible actualmente con las siguientes redes:
| Fuente de medios | Tipo de integración | Eventos admitidos |
|---|---|---|
| Google (googleads_int) | OCI | Eventos dentro de la aplicación |
| Meta (facebook_int, metaweb_int) | SRN + CAPI | Eventos dentro de la aplicación |
| OpenAI (openai_int) | CAPI | Instalaciones, re-engagements, eventos in-app |
| TikTok (tiktokglobal_int, tiktokweb_int) | SRN + CAPI | Instalaciones, re-engagements, eventos in-app |
| Snapchat (snapchat_int, snapweb_int) | SRN + CAPI | Instalaciones, re-engagements, eventos in-app |
| Pinterest (pinterest_int) | CAPI | Instalaciones, re-engagements, eventos in-app |
| Reddit (reddit_int) | CAPI | Instalaciones, re-engagements, eventos in-app |
| Roku (rokuads_int) | SRN + CAPI | Eventos dentro de la aplicación |
Flujo integral
Esto es lo que ocurre desde el momento en que se recupera un identificador hasta el momento en que llega a un partner:
- Se recupera un identificador (dirección de correo electrónico, número de teléfono u otro tipo compatible) en la aplicación o en el backend.
- El identificador se normaliza y se somete a hashing con SHA-256: automáticamente mediante el SDK de AppsFlyer o en el servidor antes de enviarlo mediante la API S2S.
- El identificador sometido a hashing se envía a AppsFlyer junto con el evento (instalación, reinstalación, re-engagement o evento in-app).
- Si Advanced-Matching Data Sharing está habilitado para el partner, AppsFlyer reenvía el hash junto con la carga útil del evento.
- El partner usa el hash para asociar el evento a un usuario conocido, lo que mejora la precisión de la atribución y la calidad de la coincidencia.
Advertencia
Los identificadores con hashing solo se reenvían a los partners para los que Advanced-Matching Data Sharing está habilitado. Cuando el interruptor de activación/desactivación está desactivado, no se comparte ningún dato sometido a hashing con ese partner, aunque haya identificadores presentes en el evento.
Cómo llegan los identificadores de usuario con hashing a AppsFlyer
Los identificadores con hashing llegan a AppsFlyer mediante dos métodos: el SDK o la API de servidor a servidor (S2S). En ambos casos, solo se aceptan valores correctamente sometidos a hashing. Las pestañas de abajo describen cada método.
El SDK V7.0.1 incorpora un método para pasar identificadores sin procesar a los SDK de AppsFlyer para Android e iOS. El SDK normaliza la entrada y le aplica hashing antes de enviarla a AppsFlyer:
El SDK realiza los siguientes pasos en orden:
- Normaliza la entrada según los requisitos de cada partner.
- Aplica hashing al valor normalizado con SHA-256.
- Envía solo el valor con hashing a AppsFlyer. La entrada sin procesar nunca sale del dispositivo.
El SDK rechaza los valores no válidos con un error y no los envía a AppsFlyer.
Advertencia
Hay soporte para Android e iOS a partir del SDK V7.0.1.
Para ver los detalles de implementación, consulta la guía de integración del SDK de Android y la guía de integración del SDK de iOS.
Al enviar eventos in-app mediante la API de eventos in-app S2S, los identificadores deben normalizarse y aplicarles hashing en el Servidor antes del envío. La API acepta los siguientes campos:
| Campo | Nota |
|---|---|
email_hashed |
Dirección de correo electrónico con hashing |
phone_number_hashed |
Número de teléfono con hashing, solo dígitos |
phone_number_e164_hashed |
Número de teléfono con hashing en formato E.164 |
first_name_hashed |
Nombre con hashing |
last_name_hashed |
Apellido con hashing |
fb_login_id |
ID de login de Facebook (sin hashing; se envía tal cual) |
Dos puntos (:)
Todos los campos de esta tabla (excepto fb_login_id) se validan con el formato SHA-256. Los valores que no coinciden se descartan sin avisar y no se reenvían a ningún Partners. Los demás campos del evento se procesan con normalidad.
¿Por qué hay dos campos de número de teléfono? Las redes comparan eventos al cotejar el hash que AppsFlyer reenvía con el hash del número de teléfono del usuario que tienen almacenado. Como el mismo número, al normalizarse en un formato diferente, genera un hash distinto, ambas partes deben aplicar el hash a partir del mismo formato para que haya coincidencia. Dado que las redes normalizan los números de teléfono de forma distinta y AppsFlyer recibe valores ya hasheados, deben enviarse ambas versiones para cubrir todos los partners compatibles.
-
phone_number_hashed: para Meta y Snapchat. Formato de normalización antes de aplicar el hash:16501234567 -
phone_number_e164_hashed: para Google y TikTok. Formato de normalización antes de aplicar el hash:+16501234567
Normalizar y aplicar hashing a los identificadores
Normaliza el valor sin procesar exactamente como se describe a continuación; después, aplica hashing con SHA-256 y envía el resumen hexadecimal en minúsculas.
Correo electrónico (email_hashed)
- Elimina todos los espacios en blanco.
- Convierte a minúsculas.
- Aplica hashing con SHA-256.
Fecha y hora del toque del contributor[n]
User@Example.COM → user@example.com → hashing con SHA-256
Número de teléfono, solo dígitos (phone_number_hashed)
Usa esto para Meta y Snapchat.
- Añade delante el código de país.
- Elimina todos los símbolos, letras y ceros iniciales.
- Aplica hashing con SHA-256.
Fecha y hora del toque del contributor[n]
+1 (650) 123-4567 → 16501234567 → hashing con SHA-256
Número de teléfono, E.164 (phone_number_e164_hashed)
Usa esto para Google y TikTok.
- Añade delante el código de país.
- Elimina todos los símbolos, letras y ceros iniciales.
- Añade el signo
+al principio. - Aplica hashing con SHA-256.
Fecha y hora del toque del contributor[n]
+1 (650) 123-4567 → +16501234567 → Hashing SHA-256
Nombre (first_name_hashed) y apellido (last_name_hashed)
- Elimina todos los espacios en blanco.
- Convierte a minúsculas.
- Aplica hashing con SHA-256.
ID de login de Facebook (fb_login_id)
Envía el ID de login de Facebook sin procesar tal como lo proporciona el SDK de Facebook Login. Este campo no se aplica hashing.
Activa el uso compartido de datos de Advanced Matching
El uso compartido de datos de Advanced Matching se controla por partner y por aplicación, y debe activarse explícitamente para cada red.
Para activar Uso compartido de datos de Advanced Matching:
- En AppsFlyer, en el menú lateral, selecciona Collaborate > Active Integrations.
- Busque al socio y selecciónelo.
- Activa Uso compartido de datos de Advanced Matching.
- Haz clic en Guardar integración.
Cuando el uso compartido de datos de Advanced Matching está activado, cualquier evento que incluya uno o más campos de identificador compatibles reenviará esos campos al partner.
Advertencia
Desactivar el uso compartido de datos de Advanced Matching detiene inmediatamente el uso compartido de datos con Hashing con ese partner. No afecta a otros ajustes de integración, incluidos los postbacks y los datos de eventos.
Privacidad y tratamiento de datos
Cuando el uso compartido de datos de Advanced Matching está activado para un partner, AppsFlyer empieza a reenviar a esa red identificadores de usuario con Hashing junto con los datos de eventos. Antes de activarlo, confirma lo siguiente:
- Existe una base legal (conforme a las leyes de privacidad aplicables, como el Reglamento general de protección de datos (RGPD) o la California Consumer Privacy Act (CCPA)) para compartir estos datos con el partner.
- Tu política de privacidad se ha actualizado y, cuando es necesario, se ha obtenido el consentimiento del usuario.
- Tus prácticas de uso compartido de datos se ajustan a los términos del partner.
Dos puntos (:)
AppsFlyer no procesa ni almacena información de identificación personal (PII) en texto sin formato. Todos los campos de ID se validan en la ingesta: los valores que no se ajustan al formato SHA-256 se descartan y nunca se reenvían a ningún Partner.
Preguntas frecuentes
¿Es Advanced-Matching Data Sharing lo mismo que la función de correo electrónico y teléfono con hash de las audiencias?
N.º Son mecanismos distintos. Las audiencias crean listas de Usuario para Ad Targeting. Advanced-Matching Data Sharing reenvía identificadores con hash junto con eventos individuales para mejorar las tasas de coincidencia a nivel de Partner. AppsFlyer tiene previsto consolidar ambos métodos y usar el nuevo método de recuperación de datos tanto para Advanced-Matching Data Sharing como para audiencias.
¿Qué ocurre si envío un valor con hash no válido?
El campo se descarta en la ingesta y no se reenvía a ningún Partner. Los demás campos del evento se procesan con normalidad.
¿Tengo que enviar todos los campos compatibles?
N.º Solo es necesario incluir los identificadores disponibles y relevantes para los Partners configurados. Los campos que faltan no se reenvían.
¿Mejorará Advanced-Matching Data Sharing la Atribución de instalación?
Para Snapchat y TikTok, sí. Estos Partners admiten reclamaciones de instalación y re-engagement basadas en correo electrónico y teléfono con hash. Para Google y Meta, actualmente solo mejora las tasas de coincidencia de los eventos in-app.
¿Recibe AppsFlyer alguna vez identificadores de usuario en texto sin formato?
N.º Al usar el SDK, el hashing se realiza en el dispositivo antes de que se envíe nada a AppsFlyer. Al usar la API S2S, el hashing se realiza en el servidor antes del envío. AppsFlyer solo acepta valores con hash.
This article was translated automatically and may contain errors. The English version is the most accurate - use the language selector below to switch.