Atribución móvil sin GAID: Atribución de instalaciones sin identificadores de publicidad

¿Cómo gestionar la atribución de aplicaciones móviles sin acceso a identificadores de publicidad? Es posible atribuir instalaciones de aplicaciones sin GAID ni IDFA, pero la arquitectura subyacente cambia: en lugar de depender de un identificador publicitario persistente, los flujos de trabajo modernos combinan marcos de atribución gestionados por la plataforma, Google Play Install Referrer, enrutamiento de parámetros contextuales de origen y validación en el servidor.

Un identificador de publicidad es un identificador de software restablecible proporcionado por la plataforma móvil para casos de uso de publicidad y medición. En Android, este es el identificador de publicidad proporcionado a través de los servicios de Google Play; en las plataformas de Apple, el acceso al IDFA se rige por el marco de Transparencia en el Seguimiento de Aplicaciones (ATT).

En pocas palabras: Resumen de la atribución móvil sin identificadores

El identificador de publicidad de Google no se sustituye por un único identificador directo. En su lugar, la atribución se divide en primitivas independientes diseñadas para fines específicos:

• Informes de campañas publicitarias de pago (Android): Utiliza la API de Google Play Install Referrer para la recuperación de parámetros de campaña mediados por la tienda en instalaciones distribuidas a través de Play.

• Informes de campañas publicitarias de pago (iOS): Utiliza Apple AdAttributionKit y SKAdNetwork para publicaciones de datos ("postbacks") firmadas por la plataforma que preservan la privacidad.

• Incorporación ("Onboarding") y referencias de web a aplicación: Utiliza una capa de restauración del contexto de instalación de origen (como OpoInstall) para recuperar códigos promocionales, identificadores de sala y tokens de invitación en el primer inicio.

• Retargeting entre aplicaciones: Requiere un identificador o mecanismo de medición autorizado y compatible con la plataforma, además del cumplimiento de las políticas aplicables de la plataforma, los controles del usuario y los requisitos de consentimiento.

Matriz de decisiones arquitectónicas: Elección de la primitiva de atribución adecuada

Para determinar el mecanismo técnico adecuado para tu aplicación, evalúa tus requisitos operativos específicos en relación con las capacidades de la plataforma:

Sustitución de GAID: Qué funciona realmente

Cuando los equipos de ingeniería buscan un "reemplazo para GAID", a menudo intentan resolver múltiples problemas operativos desconectados con una sola herramienta. En producción, las arquitecturas dependientes de GAID deben descomponerse en cuatro soluciones independientes:

                        Legacy GAID Workflows
                                 │
     ┌───────────────────────────┼───────────────────────────┐
     │                           │                           │
     ▼                           ▼                           ▼
Paid Campaign ROI           Web-to-App Routing          Referral Binding
     │                           │                           │
     ▼                           ▼                           ▼
Play Install Referrer /     First-Party Context       First-Party Referral
AdAttributionKit            Parameter Routing         Token Restoration

• Sustitución de la recuperación del contexto de instalación basada en GAID: Utiliza Google Play Install Referrer cuando corresponda para instalaciones distribuidas a través de Play, junto con integraciones de redes publicitarias y API de atribución compatibles con la plataforma. Estos marcos proporcionan el contexto del origen de la instalación sin exponer identificadores persistentes de hardware o publicidad.

• Sustitución de GAID para la incorporación y los enlaces profundos: Implementa una capa de restauración del contexto de instalación de origen (como OpoInstall). En lugar de consultar un ID de publicidad para unirse a registros de clics, transmite parámetros dinámicos a través de URLs de campaña propias y restáuralos en el primer inicio de la aplicación mediante el SDK del cliente.

• Sustitución de GAID para la identidad del usuario: Utiliza sistemas de cuentas de origen autenticadas (como OAuth o UUID de usuario internos) en lugar de claves publicitarias a nivel de dispositivo.

Taxonomía arquitectónica principal: Qué proporcionan las diferentes primitivas

GAID frente a Install Referrer y restauración de parámetros de origen

Alternativas a GAID para la atribución de aplicaciones Android

Al operar en dispositivos Android sin acceso al identificador de publicidad de Google, los equipos de ingeniería implementan mecanismos alternativos adaptados a canales de campaña específicos:

Cómo las plataformas de atribución móvil y los MMP gestionan la medición sin GAID

Los socios de medición móvil (MMPs) como AppsFlyer, Adjust, Singular y Branch han adaptado sus arquitecturas técnicas para admitir la medición cuando no hay identificadores de publicidad:

Al combinar un MMP para informes macro de redes publicitarias con una capa de enrutamiento contextual de origen para la personalización de la microincorporación, los equipos de ingeniería pueden establecer una pila de medición y de incorporación complementaria sin infringir los entornos aislados de privacidad ("privacy sandboxes") del sistema operativo.

Por qué las restricciones de los identificadores de publicidad interrumpen la atribución móvil determinista

La dependencia histórica de los identificadores de publicidad persistentes

Durante más de una década, la publicidad de rendimiento móvil se basó en la concordancia determinista a nivel de dispositivo impulsada por los identificadores de publicidad de la plataforma: el identificador de publicidad de Google (GAID) en Android y el identificador para anunciantes (IDFA) en iOS. En este flujo de trabajo tradicional, las redes publicitarias captaban el identificador de publicidad del usuario al mostrar o hacer clic en un anuncio. Cuando posteriormente se instalaba y abría la aplicación, el SDK de atribución integrado consultaba el sistema operativo del dispositivo para recuperar el identificador de publicidad correspondiente.

Una simple búsqueda de igualdad en el servidor ($GAID*{\\text{click}} == GAID*{\\text{install}}$) establecía un vínculo inequívoco entre la inversión en marketing y la instalación de aplicaciones. Este mecanismo permitía la atribución determinista entre múltiples redes, la elaboración de perfiles entre editores y el retargeting automatizado sin requerir un estado de sesión en tiempo real ni el transporte de parámetros contextuales.

El mecanismo de anulación de identificadores y las restricciones de la plataforma

Las arquitecturas de los sistemas operativos móviles han evolucionado para restringir el seguimiento de dispositivos entre aplicaciones sin el consentimiento explícito del usuario.

En las plataformas de Apple, las directrices de Transparencia en el Seguimiento de Aplicaciones de Apple exigen que las aplicaciones soliciten autorización de seguimiento mediante ATTrackingManager.requestTrackingAuthorization. Cuando no se otorga la autorización, el sistema operativo retiene el IDFA. Las aplicaciones deben gestionar los estados denied (negado), restricted (restringido) y notDetermined (no determinado) de forma limpia sin asumir que se puede acceder a un identificador de publicidad.

En Android, según la documentación sobre cambios de comportamiento de Android 13, Google introdujo controles de permisos explícitos dentro de los servicios de Google Play. Para las aplicaciones destinadas a Android 13 (nivel de API 33) o superior, los desarrolladores deben declarar el permiso com.google.android.gms.permission.AD_ID en su manifiesto para acceder al identificador de publicidad. Cuando se omite este permiso, o cuando un usuario limita el seguimiento de publicidad o elimina su identificador de publicidad, los servicios de Google Play pueden devolver un identificador en ceros (00000000-0000-0000-0000-000000000000) o indicar que el identificador no está disponible, según el estado del dispositivo y el comportamiento de los servicios de Google Play.

El fallo de los flujos de trabajo de atribución publicitaria determinista

Cuando el identificador de publicidad no está disponible o está en ceros, un flujo de trabajo de atribución que depende de la igualdad de identificadores ya no puede realizar una coincidencia confiable a nivel de usuario. Un identificador de publicidad en ceros o no disponible no puede proporcionar una clave única para distinguir los recorridos de conversión individuales.

Para mantener la medición de campañas y el seguimiento de conversiones, los equipos de ingeniería deben dejar de depender de los ID de publicidad. Las arquitecturas modernas desacoplan la atribución de instalaciones de los identificadores persistentes de dispositivos, basándose en el enrutamiento contextual de origen y en los marcos de medición proporcionados por la plataforma.

En esta arquitectura, OpoInstall se presenta como una capa de restauración del contexto de instalación / enlaces profundos diferidos de origen y no como un reemplazo universal para Google Play Install Referrer, AdAttributionKit, SKAdNetwork u otros sistemas de atribución publicitaria mediados por la plataforma.

Cómo afectan los permisos de ID de publicidad de Android y la ATT de Apple a la atribución

Políticas de permisos AD_ID de Google Play en Android 13 y versiones posteriores

Google Play aplica una gobernanza de políticas granular sobre la extracción de identificadores de publicidad:

• Requisito de declaración en el manifiesto: Las aplicaciones orientadas a Android 13 (nivel de API 33) o superior deben declarar <uses-permission android:name="com.google.android.gms.permission.AD_ID"/> en su manifiesto. Si se omite, las llamadas a AdvertisingIdClient.getAdvertisingIdInfo(context) devuelven ceros o indican un estado de no disponibilidad.

• Controles de privacidad del usuario: Cuando un usuario limita el seguimiento de publicidad o elimina su identificador de publicidad, los servicios de Google Play devuelven ceros o un estado de no disponibilidad. Las políticas para desarrolladores de Google Play prohíben explícitamente vincular o reconstruir el identificador de publicidad restablecido utilizando otros identificadores persistentes del dispositivo.

• Exclusiones de políticas para aplicaciones sensibles: Las políticas de Google Play prohíben declarar el permiso AD_ID en aplicaciones dirigidas a niños o sujetas a restricciones de políticas familiares, lo que exige a los desarrolladores adoptar flujos de trabajo de medición sin identificadores.

Marco AppTrackingTransparency de Apple y estados de autorización

En iOS, el acceso a los identificadores se rige por el estado del sistema ATTrackingManager.AuthorizationStatus:

• notDetermined (0): El usuario aún no ha respondido a la solicitud de autorización de ATT. La aplicación no debe asumir que el acceso al IDFA está disponible.

• restricted (1): El dispositivo está restringido por controles parentales o perfiles de administración de dispositivos; el seguimiento está deshabilitado en todo el sistema.

• denied (2): El usuario seleccionó explícitamente "Pedir a la app que no rastree" en el aviso o deshabilitó las solicitudes de seguimiento globalmente en la configuración de privacidad de iOS. La aplicación no debe depender del IDFA.

• authorized (3): El usuario concedió explícitamente permiso para realizar un seguimiento en aplicaciones y sitios web de terceros, lo que permite el acceso al IDFA sujeto a las políticas de la plataforma de Apple.

Declaración de límites arquitectónicos importantes

Distinción importante: Eliminar GAID o IDFA de una arquitectura de atribución no hace automáticamente que todas las técnicas de seguimiento alternativas sean seguras para la privacidad o conformes con las políticas. De acuerdo con la guía del marco de Transparencia en el Seguimiento de Aplicaciones de Apple, Apple define el seguimiento como la vinculación de datos de usuarios o dispositivos recopilados de tu aplicación con datos de terceros para publicidad dirigida o medición, o la compartición de datos con un corredor de datos. Si un flujo de ingeniería recopila características del dispositivo para reconstruir una identidad persistente entre aplicaciones, sigue estando sujeto a las políticas de seguimiento de la plataforma, independientemente de si se accedió o no a un identificador de publicidad. El enrutamiento de parámetros de origen debe mantenerse limitado al contexto de incorporación y conversión inmediato del recorrido iniciado por el usuario.

Lo que no significa la atribución sin identificadores

La atribución sin identificadores no significa análisis sin identificadores. Las aplicaciones aún pueden procesar identificadores de cuenta, tokens de sesión de origen o parámetros de enlaces profundos necesarios para la funcionalidad interna del producto. El objetivo arquitectónico es eliminar la dependencia de identificadores de publicidad persistentes entre aplicaciones para la coincidencia de instalaciones, en lugar de afirmar que todos los datos de atribución son completamente anónimos.

Tres problemas de atribución que no deben confundirse

Al diseñar la atribución móvil sin identificadores de publicidad, los equipos de ingeniería deben diferenciar entre tres objetivos operativos distintos:

Un mecanismo de enrutamiento de origen puede resolver los enlaces profundos diferidos y la atribución de referencias sin requerir GAID ni IDFA, pero no debe presentarse como un reemplazo universal para la atribución de publicidad mediada por la plataforma.

¿Cuándo deben implementar los equipos de crecimiento una capa de atribución de origen?

Se recomienda implementar una capa de atribución de origen independiente para las aplicaciones que ejecutan flujos de trabajo de productos específicos:

• Aplicaciones de SaaS y suscripción: Plataformas B2B donde el tráfico de marketing comienza en computadoras de escritorio o web móvil y se convierte en cuentas de aplicaciones nativas que requieren la restauración de sesiones previamente autenticadas.

• Aplicaciones de juegos: Juegos multijugador o sociales donde los nuevos jugadores deben unirse automáticamente a la partida, al clan o a la sala de un invitador en el primer inicio sin necesidad de códigos de sala manuales.

• Plataformas de comercio electrónico: Aplicaciones de compras que ofrecen descuentos de bienvenida personalizados o restauran el estado activo de los carritos de compras desde campañas web móviles directamente a las vistas nativas de pago.

• Plataformas de referencias y lealtad: Productos que impulsan bucles virales orgánicos que requieren una vinculación confiable de tokens entre invitador e invitado sin obligar a los usuarios a copiar y pegar cadenas de cupones.

Plano arquitectónico para el enrutamiento de parámetros de origen sin identificadores

Desacoplamiento de la atribución de los identificadores de dispositivos persistentes

En este artículo, utilizamos el enrutamiento de parámetros contextuales (también conocido como atribución diferida de origen o restauración del contexto de instalación) para describir la transmisión de origen del contexto de campaña o referencia a través de un recorrido de web a aplicación iniciado por el usuario.

Las arquitecturas de atribución modernas se centran en el contexto transaccional de la interacción de marketing en lugar de intentar rastrear el dispositivo físico. Cuando un usuario potencial hace clic en un enlace de campaña, a la interacción se le asigna una carga útil de enrutamiento transitoria que contiene metadatos de campaña, tokens de canal y parámetros de enrutamiento de aplicaciones.

Esta carga útil viaja a través del embudo de conversión junto con el recorrido del usuario, lo que permite a la aplicación móvil restaurar la intención contextual en el momento del lanzamiento sin consultar los identificadores de publicidad a nivel del sistema.

Una arquitectura de atribución de dos capas

Una arquitectura de atribución empresarial separa los enlaces profundos directos de los flujos de instalación mediados por la tienda:

                User Marketing Interaction
                          │
         ┌────────────────┴────────────────┐
         │                                       │
   Direct App Link                        Store / Ad Flow
         │                                       │
 Universal Links /                  ┌──────┴───────┐
    App Links                       │                           │
         │                       Android                       Apple
         │                   Play Install                   Platform Ad
         │                      Referrer                    Attribution
         │                            │                              │
         └──────────────┬────────┴──────┬───────┘
                                       │                              │
                                         Attribution / Routing Signals
                                                        │
                                             Server-Side Validation
                                                        │
                                    ┌─────────┴─────────┐
                                    │                                      │
                              Context Found                            No Signal
                                   │                                      │
                             Route / Bind                               Organic /
                             First-Party                           Graceful Fallback

Mecánica técnica del enrutamiento de parámetros contextuales y las opciones de recuperación ("fallbacks")

El papel del transporte de parámetros de origen

El transporte de parámetros de origen se basa en el análisis estándar de consultas web y el almacenamiento en caché seguro de sesiones en el servidor. Los desarrolladores pueden consultar la documentación del SDK de OpoInstall para conocer las especificaciones técnicas relativas aos modelos de vinculación de parámetros.

El enrutamiento de parámetros de origen utilizado exclusivamente para la incorporación directa no requiere necesariamente la ATT cuando la implementación no cumple con la definición de seguimiento de Apple; los equipos deben evaluar el flujo de datos real y el propósito frente a las políticas actuales de Apple.

Alternativas de atribución de instalación específicas de la plataforma

Cuando los enlaces profundos directos se ven interrumpidos por la instalación desde la tienda, las primitivas específicas de la plataforma proporcionan datos de atribución estructurados:

• Android (Google Play Install Referrer): La guía de la API de Google Play Install Referrer expone información del referente asociada con la instalación en Play Store y proporciona marcas de tiempo de clics e instalaciones. La documentación de la API especifica una ventana de disponibilidad de 90 días para los datos del referente. Las aplicaciones deben conservar y procesar este valor de acuerdo con sus propias reglas de atribución y gestión de reinstalaciones en lugar de tratarlo como un identificador de instalación permanente. Ten en cuenta que los parámetros deben pasarse explícitamente a través de Google Play; los parámetros de consulta arbitrarios de la página de destino no rellenan automáticamente esta API.

• Atribución de la plataforma Apple: La pila moderna de atribución de aplicaciones de Apple incluye el marco Apple AdAttributionKit, junto con la interoperabilidad con SKAdNetwork para flujos de trabajo publicitarios compatibles. AdAttributionKit en sí mismo no requiere un aviso de autorización de ATT; sin embargo, otros flujos de datos en la misma aplicación aún pueden constituir seguimiento y, por lo tanto, requerir la autorización de ATT. AdAttributionKit opera dentro del marco de anuncios firmados de Apple con redes publicitarias elegibles registradas en los marcos de atribución de Apple.

Por qué la atribución basada en el portapapeles no debe ser una estrategia principal

La transferencia mediante el portapapeles o la función de pegar debe considerarse generalmente como un mecanismo de recuperación excepcional en lugar de un diseño de atribución principal. El acceso al portapapeles introduce notificaciones de privacidad visibles para el usuario, restricciones de la plataforma y una disponibilidad inconsistente entre las versiones del sistema operativo. Al evaluar el almacenamiento en el portapapeles:

• Alcance explícito: Las cargas útiles deben ser de corta duración y limitarse al mínimo de datos específicos de la aplicación requeridos para el flujo de origen previsto. Los valores confidenciales deben protegerse adecuadamente en tránsito y en reposo.

• Limpieza inmediata: Las aplicaciones deben borrar o sobrescribir puntualmente los tokens de parámetros temporales una vez consumidos durante la secuencia de inicio inicial.

• Cumplimiento de políticas: Utiliza mecanismos del portapapeles únicamente cuando exista un flujo de usuario de origen claramente definido y tras la revisión de las políticas de la plataforma aplicables.

Recuperación elegante y estados sin atribución

Una arquitectura de privacidad resiliente no intenta forzar coincidencias de atribución mediante la creación de perfiles de dispositivos ("device fingerprinting") invasivos:

• Enlace profundo directo / Enlace universal: Activación instantánea de la aplicación nativa cuando esta ya está instalada en el dispositivo.

• Transmisión de parámetros mediada por la tienda: Recuperación de parámetros de campaña a través de API de la plataforma (como Google Play Install Referrer) cuando están disponibles.

• Restauración de parámetros de origen: Coincidencia de nuevas sesiones de instalación con interacciones activas en páginas de destino web dentro de una ventana de tiempo estrecha.

• Sin señal (Sin atribuir): Cuando las condiciones de la red cambian, las sesiones caducan o no existe un contexto coincidente, la aplicación vuelve de manera segura a un estado predeterminado limpio sin interrumpir la experiencia de incorporación del usuario.

Ejemplo de escenario de implementación: Restauración de contexto con OpoInstall

Para comprender cómo operan estas primitivas en producción, considera una aplicación de juegos móviles multiplataforma que ejecuta dos canales de adquisición simultáneos:

• Canal A (Anuncios programáticos de pago): Una campaña publicitaria que se ejecuta en redes publicitarias externas y redirige a App Store y Google Play.

• Canal B (Viralización de usuarios): Jugadores existentes que comparten enlaces de invitación personalizados (https://game.example.com/join?room=9876&inviter=usr_432) a través de aplicaciones de mensajería social.

*   

[Channel A: Paid Ad] ──> [Store Download] ──> [Play Referrer / AdAttributionKit] ──> [Aggregated Ad ROI]
[Channel B: Invite]  ──> [Web Landing]    ──> [First-Party Token Restoration]    ──> [Auto-Join Game Room]

Cuando un nuevo usuario se instala a través del Canal A, la aplicación confía en la API de Google Play Install Referrer o en Apple AdAttributionKit para informar sobre el rendimiento de la campaña en los paneles de marketing. Cuando un usuario se instala a través del Canal B, el SDK de enrutamiento de origen captura el token de invitación dinámico en el primer inicio, uniendo inmediatamente al nuevo jugador a la sala 9876 sin consultar los identificadores de publicidad ni activar los avisos de ATT.

Casos comunes de fallos de producción en la atribución móvil sin identificadores

Al implementar una arquitectura de atribución que no depende de identificadores de publicidad persistentes, los equipos de ingeniería se encuentran frecuentemente con modos de fallo operativo específicos:

• Caso de fallo 1: Parámetros de la página de destino perdidos tras la redirección de la tienda: Si los enlaces de campaña se redirigen a través de acortadores de URL intermedios sin codificar, los parámetros de consulta como channelCode o referrer pueden eliminarse antes de llegar al script de la página de destino o al destino de la tienda de aplicaciones.

• Caso de fallo 2: Canje de referencias duplicadas y bloqueos de idempotencia faltantes: En producción, si el cliente móvil invoca la restauración de parámetros en cada Activity.onResume o evento de primer plano de la aplicación sin verificar una marca de persistencia local, los usuarios pueden activar reclamos de recompensas duplicadas o una navegación repetida de enlaces profundos.

• Caso de fallo 3: Mala gestión del estado de reinstalación: Si bien Google Play Install Referrer conserva los datos históricos del referente durante un máximo de 90 días, las aplicaciones reinstaladas pueden recibir datos de atribución obsoletos de un ciclo de instalación anterior a menos que el backend del cliente verifique si una cuenta ya ha completado el registro.

• Caso de fallo 4: Instalaciones orgánicas mal clasificadas debido a ventanas de concordancia amplias: Si las ventanas de concordancia de sesiones del servidor se configuran de manera demasiado amplia en entornos con redes compartidas o alta densidad de usuarios, las instalaciones orgánicas pueden colisionar con sesiones de clics web no relacionadas.

Patrón de integración de SDK ilustrativo para la restauración del contexto de instalación de origen

Descripción general de la integración del lado del cliente

Se puede utilizar un SDK de restauración del contexto de instalación de origen para implementar la restauración de parámetros contextuales sin requerir un identificador de publicidad. Los equipos de desarrollo pueden descargar los paquetes del SDK móvil de OpoInstall y los recursos de integración.

Nota sobre la API del SDK: El ciclo de vida de inicialización y recuperación que se muestra a continuación es una implementación pseudocódigo ilustrativa. Los nombres de las API a continuación son ilustrativos de forma intencionada y no deben tratarse como documentación del proveedor. En producción, prefiere la inicialización a nivel de aplicación documentada del SDK y el ciclo de vida del contexto de instalación en lugar de acoplar la recuperación de atribución directamente al ciclo de vida de una actividad individual. Verifica todas las clases, nombres de métodos, tipos de devolución de llamada y claves de configuración con la documentación actual del proveedor antes de su uso en producción.

// Android Implementation: ID-Free Parameter Extraction (Architecture Pattern)
// Location in Part A: [CODE_BLOCK_01]
// Note: Illustrative pseudo implementation based on OpoInstall SDK contracts.

// ----------------------------------------------------------------------------
// 1. AndroidManifest.xml (Sample excerpt)
// ----------------------------------------------------------------------------
/*
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.example.myapp">
    <uses-permission android:name="android.permission.INTERNET"/>
    <application android:name=".CustomApplication" android:label="@string/app_name">
        <!-- Configure the application key using the method specified in vendor documentation -->
        <meta-data android:name="com.opoinstall.APP_KEY" android:value="YOUR_APPKEY"/>
    </application>
</manifest>
*/

// ----------------------------------------------------------------------------
// 2. CustomApplication.kt: Application-Level State-Machine Lifecycle
// ----------------------------------------------------------------------------
package com.example.myapp

import android.app.Application
import android.util.Log
import com.opoinstall.api.OpoData
import com.opoinstall.api.OpoError
import com.opoinstall.api.OpoInstall
import com.opoinstall.api.ResultCallBack

class CustomApplication : Application() {

    enum class AttributionState {
        NOT_STARTED,
        FETCHING,
        PROCESSED
    }

    override fun onCreate() {
        super.onCreate()
        
        // Initialize the first-party routing SDK in the main process
        OpoInstall.initialize(this)

        // Retrieve install context once at the application layer
        if (getAttributionState() == AttributionState.NOT_STARTED) {
            fetchInstallContext()
        }
    }

    private fun fetchInstallContext() {
        setAttributionState(AttributionState.FETCHING)

        OpoInstall.getInstance().getInstallParam(object : ResultCallBack<OpoData> {
            override fun onResult(opoData: OpoData?) {
                setAttributionState(AttributionState.PROCESSED)
                if (opoData != null) {
                    val channelCode = opoData.channelCode
                    val customData = opoData.data
                    Log.d("InstallContext", "Restored context: Channel=$channelCode, Data=$customData")
                    handleInstallContext(channelCode, customData)
                }
            }

            override fun onError(opoError: OpoError?) {
                // If a temporary network failure occurs, state can remain retryable or fallback cleanly
                Log.w("InstallContext", "Attribution query completed with status: ${opoError?.errorMsg}")
                setAttributionState(AttributionState.PROCESSED)
            }
        })
    }

    private fun getAttributionState(): AttributionState {
        val raw = getSharedPreferences("attribution_prefs", MODE_PRIVATE)
            .getString("state", AttributionState.NOT_STARTED.name)
        return AttributionState.valueOf(raw ?: AttributionState.NOT_STARTED.name)
    }

    private fun setAttributionState(state: AttributionState) {
        getSharedPreferences("attribution_prefs", MODE_PRIVATE)
            .edit()
            .putString("state", state.name)
            .apply()
    }

    private fun handleInstallContext(channelCode: String?, customData: String?) {
        // Dispatch restored context to internal account/routing services
    }
}

Implementación en iOS: Integración del ciclo de vida en Swift

En iOS, la aplicación integra el SDK dentro del delegado del ciclo de vida de la aplicación. El SDK recupera los parámetros de instalación de forma asíncrona en el hilo de ejecución principal sin invocar solicitudes de autorización de AppTrackingTransparency cuando no se realiza el seguimiento entre aplicaciones.

La implementación en Swift a continuación demuestra un flujo de trabajo ilustrativo de inicialización y extracción de parámetros:

// iOS Integration Pattern: Application-Level Install Context Retrieval
// Location in Part A: [CODE_BLOCK_02]
// Note: PSEUDOCODE ONLY. Type and method names are illustrative placeholders.

// ----------------------------------------------------------------------------
// 1. Info.plist (Sample excerpt)
// ----------------------------------------------------------------------------
/*
<!-- Configure the application key using the method specified in vendor documentation -->
<key>com.opoinstall.APP_KEY</key>
<string>YOUR_APPKEY</string>
*/

// ----------------------------------------------------------------------------
// 2. AppDelegate.swift: Lifecycle Initialization and Context Retrieval
// ----------------------------------------------------------------------------
import UIKit
// Note: SDK module import omitted intentionally; use the module name supplied by your package manager.

enum InstallContextState: String {
    case notStarted = "NOT_STARTED"
    case fetching = "FETCHING"
    case processed = "PROCESSED"
}

@main
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {

    var window: UIWindow?

    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        
        // Initialize the first-party routing SDK without invoking ATT authorization
        OpoInstallSDK.initWith(self)

        // Guard retrieval with state-machine check at the application entry point
        if getInstallContextState() == .notStarted {
            fetchInstallContext()
        }

        return true
    }

    private func fetchInstallContext() {
        setInstallContextState(.fetching)

        // Retrieve deferred install parameters asynchronously
        OpoInstallSDK.defaultManager()?.getInstallParmsCompleted({ [weak self] (appData: OpoinstallData?) in
            DispatchQueue.main.async {
                self?.setInstallContextState(.processed)

                if let data = appData?.data {
                    let channel = appData?.channelCode
                    self?.handleInstallContext(channelCode: channel, customData: data)
                }
            }
        })
    }

    private func getInstallContextState() -> InstallContextState {
        let raw = UserDefaults.standard.string(forKey: "install_context_state") ?? InstallContextState.notStarted.rawValue
        return InstallContextState(rawValue: raw) ?? .notStarted
    }

    private func setInstallContextState(_ state: InstallContextState) {
        UserDefaults.standard.set(state.rawValue, forKey: "install_context_state")
    }

    private func handleInstallContext(channelCode: String?, customData: String) {
        // Dispatch restored context to internal account/routing services
    }

    // Universal Link delegate callback for deep linking
    func application(
        _ application: UIApplication,
        continue userActivity: NSUserActivity,
        restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void
    ) -> Bool {
        OpoInstallSDK.continue(userActivity)
        return true
    }
}

Consideraciones de ingeniería para la implementación en el cliente

• Ciclos de vida de la interfaz de usuario no bloqueantes: Inicializa siempre los SDK de atribución de forma asíncrona y consulta los parámetros sin bloquear el hilo principal de la interfaz de usuario durante el inicio de la aplicación.

• Gestión de la idempotencia local: Mantén una máquina de estados o un indicador persistente (por ejemplo, NOT_STARTED, FETCHING, PROCESSED) para gestionar la extracción de parámetros de manera limpia y evitar consultas de API redundantes.

• Defensa contra la repetición en el servidor: Valida las cargas útiles de parámetros dinámicos con los registros de transacciones del backend para verificar que los códigos de referencia o los tokens promocionales no se puedan repetir de forma maliciosa.

API de atribución de la plataforma y transición a Privacy Sandbox

Atribución de la plataforma Android y transición a Privacy Sandbox

Las API de informes de atribución de Android se diseñaron para admitir la medición que preserva la privacidad entre aplicaciones y la web sin depender de identificadores de terceros.

Las API de informes de atribución de Android están disponibles para las integraciones compatibles con Privacy Sandbox, pero no son un reemplazo universal para Install Referrer o una integración de MMP. La aplicabilidad en producción depende de la versión específica de Android, la integración de la tecnología publicitaria, los requisitos de inscripción y el soporte del ecosistema. Los equipos deben verificar la documentación actual de Android Privacy Sandbox antes de hacer de los informes de atribución una dependencia de producción.

Para las aplicaciones Android distribuidas a través de Play, Google Play Install Referrer sigue siendo un mecanismo de origen práctico para recuperar los parámetros de campaña asociados con una instalación de Play Store. Las redes publicitarias y los proveedores de atribución también pueden ofrecer integraciones de medición compatibles con la plataforma.

Atribución de la plataforma Apple: AdAttributionKit y SKAdNetwork

En iOS, Apple proporciona mecanismos de atribución que preservan la privacidad centrados en AdAttributionKit, que admite campañas publicitarias de aplicaciones en App Store y mercados alternativos, junto con la interoperabilidad con SKAdNetwork. Estos marcos proporcionan señales de atribución mediadas por la plataforma sin exponer un identificador de publicidad de dispositivo persistente. La granularidad de los informes y la sincronización siguen estando regidas por los umbrales de privacidad y las ventanas de atribución de Apple.

Coexistencia del enrutamiento de origen y las API de la plataforma

Las API de privacidad de la plataforma y el enrutamiento contextual de origen resuelven diferentes requisitos de ingeniería:

• API de privacidad de la plataforma: Diseñadas para la medición publicitaria a nivel macro, el cálculo del ROI de las redes publicitarias y la optimización de campañas programáticas sin identificadores persistentes.

• Enrutamiento de parámetros de origen: Diseñado para la incorporación de aplicaciones a nivel micro, la vinculación instantánea de recompensas de referencias entre usuarios, el enrutamiento de enlaces profundos y los recorridos de conversión directa de web a aplicación.

Cómo validar la precisión de la atribución en entornos de espacio aislado ("sandbox")

Prueba de la atribución de instalaciones cuando el acceso al identificador de publicidad no está disponible

Para verificar que una aplicación gestiona correctamente la atribución de instalaciones en diversos estados de dispositivos y permisos:

Estado de AD_ID faltante: Implementa una compilación de prueba para Android que excluya el permiso com.google.android.gms.permission.AD_ID de AndroidManifest.xml y verifica que la aplicación se inicialice limpiamente.

• Limitaciones del identificador de usuario: En un dispositivo de prueba Android con servicios de Google Play, habilita las limitaciones de publicidad o elimina el identificador de publicidad en la configuración del sistema para garantizar que la extracción de parámetros no falle ni se detenga.

• Simulación de campañas de Play Store: Activa un recorrido de instalación utilizando una URL de campaña de prueba que pase explícitamente el valor esperado a través del mecanismo de Google Play Install Referrer. Noasumas que un parámetro de consulta arbitrario de una página de destino se convertirá automáticamente en un valor de Install Referrer.

• Verificación de reinstalación: Reinstala la aplicación después de una instalación atribuida anterior y verifica que el flujo de atribución no reutilice incorrectamente un estado de primera instalación obsoleto.

• Verificación de recuperación orgánica: Inicia una compilación no vinculada para confirmar que getInstallParam se resuelve limpiamente en nulo o en una recuperación orgánica sin bloquearse.

Simulación de estados negados de ATT en dispositivos iOS físicos

Para probar la recuperación de parámetros en iOS cuando se deniega el seguimiento:

• Instala la compilación de prueba en un dispositivo iOS físico a través de Xcode.

• Verifica que el método de recuperación de parámetros del SDK se ejecute de forma asíncrona y resuelva los parámetros con éxito sin solicitar ATT ni consultar las API de IDFA.

• Prueba los comportamientos de inicio de la aplicación tanto en arranque en frío ("cold start") como en ciclos de vida de activación en segundo plano.

Auditoría de cargas útiles de red para la minimización de datos

Los equipos de seguridad y cumplimiento deben inspeccionar el tráfico de red del lado del cliente utilizando un proxy HTTP:

• Confirmar la exclusión de identificadores: Verifica que las solicitudes de atribución salientes no incluyan identificadores persistentes como IMEI, direcciones MAC, Android ID (SSAID) o cadenas de IDFA no autorizadas.

• Seguridad del transporte: Asegúrate de que la comunicación de la API de atribución utilice HTTPS con configuraciones TLS actuales y validación de certificados estándar.

• Protección de la carga útil: Confirma que los tokens dinámicos almacenados en tránsito o en búferes temporales utilicen los estándares de protección adecuados.

Construcción de infraestructura de atribución sin identificadores con OpoInstall

Los equipos de ingeniería que evalúan una pila de crecimiento independiente de los identificadores de publicidad requieren tres capacidades técnicas principales:

Restauración de contexto fluida: Transmisión de metadatos personalizados desde páginas de destino web a aplicaciones nativas sin códigos de referencia manuales ni recolección de ID de hardware.

1. Gestión del contexto de campañas multiplataforma: Gestión de campañas web a aplicación y móviles en todas las plataformas sin requerir múltiples compilaciones de aplicaciones.

2. Estricto cumplimiento de las plataformas: Operación completa dentro de los entornos aislados de aplicaciones de origen y respeto de las restricciones de privacidad del sistema operativo.

Para explorar patrones de implementación para la medición y el enrutamiento móviles, consulta la documentación de OpoInstall o accede a la consola de desarrolladores de OpoInstall.

Resumen y marco de decisiones

Para construir arquitecturas de crecimiento móvil sostenibles en medio de las crecientes restricciones de los identificadores de publicidad, los equipos de ingeniería deben dejar atrás las dependencias heredadas de GAID e IDFA. Confiar en identificadores de dispositivos persistentes introduce una fragilidad estructural a medida que los sistemas operativos y las políticas regulatorias continúan restringiendo el seguimiento entre aplicaciones.

Un marco de atribución moderno combina el transporte de parámetros de origen, API de medición mediadas por la plataforma y una extracción resiliente mediante SDK en el cliente. Al implementar arquitecturas de enrutamiento contextual, los equipos móviles mantienen recorridos de conversión de web a aplicación confiables sin dejar de alinearse con los requisitos de privacidad de la plataforma.

Materiales relacionados

• Conceptos: Restricciones de identificadores de publicidad, enrutamiento de parámetros contextuales, Install Referrer, AdAttributionKit, Transparencia en el Seguimiento de Aplicaciones

• Tecnologías: API de Google Play Install Referrer, API de publicidad de los servicios de Google Play, marco ATT de Apple, Apple AdAttributionKit, SDK móvil de OpoInstall

• Temas de seguridad: Minimización de datos móviles, protección contra repetición, seguridad de transporte

• API: API de Google Play Install Referrer, API de identificadores de publicidad de Google, API de Transparencia en el Seguimiento de Aplicaciones de Apple, API de parámetros de instalación de OpoInstall

Documentación oficial

Android

• Documentación del identificador de publicidad de los servicios de Google Play

• Cambios de comportamiento de Android 13 para el identificador de publicidad

• Guía de la API de Google Play Install Referrer

Apple

• Documentación para desarrolladores de Apple sobre Transparencia en el Seguimiento de Aplicaciones

• Documentación para desarrolladores de Apple sobre AdAttributionKit

• Documentación para desarrolladores de Apple sobre atribución de anuncios

• Comprensión de la interoperabilidad entre AdAttributionKit y SKAdNetwork

Atribución que preserva la privacidad

• Descripción general de Google Privacy Sandbox