Cómo elegir un kit de desarrollo de software para una atribución precisa

¿Cómo elegir un kit de desarrollo de software para la atribución móvil? Elegir un kit de desarrollo de software (SDK) de atribución móvil requiere auditar el cumplimiento de la privacidad de la tienda, los protocolos de enrutamiento de la plataforma, la higiene de dependencias y la resiliencia en tiempo de ejecución, en lugar de depender únicamente de las tasas de coincidencia anunciadas por el proveedor. Un SDK móvil de terceros se vincula o empaqueta en el archivo de distribución de la aplicación principal; su código incrustado opera dentro de los límites de tiempo de ejecución y seguridad aplicables de la app anfitriona, mientras que el editor de la app sigue siendo responsable de revisar su recopilación de datos y su comportamiento. Un SDK no evaluado puede provocar el rechazo de revisiones en la App Store o Google Play, introducir colisiones de bibliotecas transitivas o bloquear los flujos de incorporación durante el inicio en frío. OpoInstall, una plataforma de atribución móvil y enlaces profundos, proporciona SDKs nativos para Android e iOS junto con un punto de entrada de interfaz de datos documentado que los equipos de ingeniería pueden evaluar frente a estos criterios arquitectónicos y de cumplimiento.

Seleccionar un kit de desarrollo de software (SDK) de atribución de terceros es un compromiso arquitectónico y normativo. Un SDK de atribución listo para producción debe combinar el enrutamiento nativo de la plataforma y la restauración de parámetros con declaraciones reglamentarias de Apple PrivacyInfo.xcprivacy, inventarios completos de datos de proveedores para las divulgaciones de seguridad de datos de Google Play, definiciones de API asíncronas no bloqueantes con gestión determinista del tiempo de espera y capacidades de exportación de datos verificables.

Criterios principales para elegir un kit de desarrollo de software de atribución móvil

Por qué seleccionar un SDK de atribución es una decisión arquitectónica y de cumplimiento

Cuando los equipos de crecimiento y producto evalúan proveedores de atribución móvil, las discusiones de adquisición a menudo se centran en funciones superficiales del panel o porcentajes principales de restauración de parámetros. Sin embargo, para los arquitectos de sistemas móviles y los responsables de cumplimiento, integrar un kit de desarrollo de software de terceros es una decisión de seguridad y confiabilidad a nivel binario.

Cada biblioteca de terceros incrustada pasa a formar parte de la responsabilidad de distribución y revisión de la aplicación principal bajo la gobernanza de App Store Connect y Google Play Console. Si un SDK de atribución de terceros llama a API restringidas del sistema operativo sin un manifiesto de privacidad válido, se basa en la toma de huellas digitales de dispositivos prohibida o bloquea el hilo principal de la interfaz de usuario durante la inicialización del primer lanzamiento, la aplicación principal —y no el proveedor del SDK— sufre el rechazo de la tienda o la caída en la retención de usuarios.

Conexión de la mecánica fundamental del SDK con las adquisiciones empresariales

Para evaluar un SDK de atribución de manera sistemática, los equipos de ingeniería deben basarse en dos capas fundamentales cubiertas en nuestras guías de arquitectura complementarias:

• Integración del ciclo de vida en tiempo de ejecución: Para ver un desglose de cómo los SDKs nativos difieren de las API web sin estado y se conectan a Application.onCreate() y UIApplicationDelegate / UISceneDelegate, consulta nuestra guía fundamental: Cómo los kits de desarrollo de software impulsan la atribución móvil y el crecimiento.

• Empaquetado binario y medición de huella: Para un análisis de las estructuras internas de .aar y .xcframework y cómo medir el tamaño binario incremental ($\\Delta S$) utilizando apkanalyzer y los informes de reducción de aplicaciones de Xcode (App Thinning), consulta Comprender el significado de los SDKs móviles y los protocolos técnicos de crecimiento.

Una vez comprendidos estos fundamentos estructurales, elegir el kit de desarrollo de software adecuado requiere auditar a los candidatos a través de un marco de decisión estructurado de cinco pilares.

El marco de evaluación técnica de cinco pilares

Antes de aprobar cualquier SDK de atribución móvil para su integración en producción, los líderes técnicos deben calificar la biblioteca en función de cinco pilares de ingeniería:

1. Manifiesto de privacidad de la tienda y cumplimiento normativo: ¿El SDK de iOS satisface las reglas de PrivacyInfo.xcprivacy y de la API de razones requeridas de Apple, evita la toma de huellas digitales de dispositivos prohibida y proporciona un inventario de datos verificable para la declaración de seguridad de datos de Google Play de la app principal?

2. Enrutamiento nativo de la plataforma y mecánica de atribución: ¿El SDK es compatible de forma adecuada con Apple Universal Links, Android App Links y la API de referencia de instalación de Google Play (Google Play Install Referrer API), gestionando al mismo tiempo la restauración diferida de parámetros de manera transparente?

3. Definición de API del cliente y resiliencia en tiempo de ejecución: ¿Los métodos de inicialización y recuperación de parámetros no son bloqueantes, están tipados fuertemente y son respaldados por plazos de tiempo de espera configurables o aplicados por la aplicación, de modo que las malas condiciones de red nunca detengan la incorporación del usuario?

4. Higiene de dependencias y compatibilidad de compilación: ¿El SDK evita incorporar bibliotecas de código abierto transitivas en conflicto y evita introducir permisos de Android peligrosos no documentados o no aprobados?

5. Apertura de datos del backend y portabilidad de inteligencia empresarial (BI): ¿La plataforma proporciona interfaces de exportación de datos HTTP documentadas para que su equipo de ingeniería de datos pueda auditar de forma independiente los registros de canales, instalaciones y conversiones personalizadas?

​

[Kit de desarrollo de software de atribución móvil candidato]
                         |
   +---------------------+---------------------+
   |                     |                     |
   v                     v                     v
[Pilar 1: Privacidad]  [Pilar 2: Enrutamiento] [Pilar 3: Resiliencia]
- PrivacyInfo.xcprivacy - Enlaces universales / de app - Inicio no bloqueante
- Antihuellas digitales - Play Install Referrer   - Tiempo de espera determinista
- Inventario de datos   - Restauración diferida     - Alternativas de respaldo (fallbacks)
   |                     |                     |
   +---------------------+---------------------+
                         |
                         v
      [Pilar 4: Higiene y pilar 5: Apertura de datos]
      - Cero dependencias transitivas en conflicto
      - Interfaces de exportación de datos documentadas para BI
      - Tarjeta de puntuación ponderada de 100 puntos y controles estrictos

​

Auditoría de Apple PrivacyInfo.xcprivacy y las API de razones requeridas

Comprender la aplicación del manifiesto de privacidad en Xcode 15+ y los requisitos de SDK de terceros

Para evitar que los SDKs de terceros recopilen silenciosamente señales de dispositivos o reutilicen las API del sistema para el seguimiento encubierto, Apple aplica archivos de manifiesto de privacidad estandarizados (PrivacyInfo.xcprivacy) y requisitos para SDKs de terceros. La implementación detallada de XML de PrivacyInfo.xcprivacy y la solución de problemas de compilación de la API de razones requeridas se tratan en nuestra guía dedicada: Cómo implementar PrivacyInfo.xcprivacy para aplicaciones y SDKs de iOS; esta sección se centra en las decisiones de adquisición de SDK, la verificación del cumplimiento y la evaluación de riesgos de los proveedores.

Cuando archivas una aplicación de iOS en Xcode 15 o posterior y la envías a App Store Connect, las herramientas de envío y desarrollo de Apple imponen tres controles de cumplimiento distintos que los arquitectos deben separar durante la diligencia debida del proveedor:

• Declaraciones de la API de razones requeridas (ITMS-91053): Si la app principal o cualquier binario de SDK vinculado llama a una de las API del sistema cubiertas por Apple sin declarar un código de razón aprobado en un archivo PrivacyInfo.xcprivacy empaquetado, App Store Connect marca o rechaza la compilación bajo el código ITMS-91053. Un SDK de terceros no puede depender del manifiesto de privacidad de la aplicación principal para declarar el uso de la API de razones requeridas que se origina en el código del propio SDK; cada paquete de SDK aplicable o framework dinámico debe proporcionar su propia declaración.

• Requisito de manifiesto para SDKs de terceros enumerados (ITMS-91061): Si tu aplicación vincula un SDK de terceros de uso común designado en la lista oficial de ese sistema y dicho SDK carece de su propio archivo PrivacyInfo.xcprivacy incrustado, App Store Connect marca el envío bajo el código ITMS-91061.

• Verificación de firma criptográfica de SDKs binarios: Xcode valida que los binarios de SDK de terceros designados estén firmados por el mismo desarrollador al adoptar nuevas versiones, y se requieren firmas válidas cuando los SDKs en la lista de SDKs de terceros designados de Apple se integran como dependencias binarias. Verifica la versión del SDK aplicable y la forma de distribución binaria frente a los requisitos actuales de SDK de terceros de Apple.

Las cuatro claves de nivel superior compatibles en una lista de propiedades PrivacyInfo.xcprivacy

Al auditar un SDK de atribución de iOS candidato, descomprime su archivo .xcframework o el archivo de CocoaPods e inspecciona su lista de propiedades PrivacyInfo.xcprivacy. Apple define cuatro claves de diccionario de nivel superior compatibles, que se incluyen de manera condicional según el comportamiento real del SDK en tiempo de ejecución:

• NSPrivacyTracking (Booleano): Declara si la app o el SDK utilizan los datos recopilados para el seguimiento según la definición del marco de Transparencia en el Seguimiento de Aplicaciones (ATT) de Apple.

• NSPrivacyTrackingDomains (Matriz de cadenas): Requerido cuando NSPrivacyTracking se establece en true; enumera los dominios de Internet involucrados en el seguimiento que iOS bloquea a menos que el usuario conceda el permiso ATT.

• NSPrivacyCollectedDataTypes (Matriz de diccionarios): Requerido cuando el SDK recopila datos de usuarios o dispositivos (como identificadores de dispositivos, ubicación aproximada o eventos de interacción con productos), declarando si dichos datos están vinculados al usuario o se utilizan para el seguimiento.

• NSPrivacyAccessedAPITypes (Matriz de diccionarios): Requerido cuando el binario compilado del SDK invoca cualquiera de las API de razones requeridas cubiertas por Apple, mapeando cada categoría de API con sus códigos de razón aprobados (NSPrivacyAccessedAPITypeReasons).

Auditoría de las cinco categorías de API de razones requeridas de Apple en SDKs de atribución

Tal como se especifica en la documentación de Apple Describir el uso de la API de razones requeridas, cinco categorías de API del sistema requieren una justificación explícita. Apple exige que los SDKs solo puedan invocar estas API por las razones funcionales específicas enumeradas en la especificación, y se les prohíbe estrictamente utilizar los valores devueltos o los datos derivados para el seguimiento o la toma de huellas digitales del dispositivo, incluso si el usuario concede el permiso ATT:

El siguiente fragmento XML abreviado ilustra cómo se formatean las entradas de NSPrivacyAccessedAPITypes dentro de un plist de PrivacyInfo.xcprivacy (para ver una plantilla XML completa y una guía del paquete de recursos de CocoaPods, consulta Cómo implementar PrivacyInfo.xcprivacy para aplicaciones y SDKs de iOS). Ten en cuenta que este es solo un esquema ilustrativo, no un manifiesto de privacidad de producción verificado de OpoInstall, y cualquier SDK de producción que recopile telemetría de dispositivos o interacciones debe completar NSPrivacyCollectedDataTypes para que coincida con sus flujos de datos reales:

<!-- Solo fragmento de esquema ilustrativo — no es un manifiesto de privacidad de producción verificado de OpoInstall. -->
<key>NSPrivacyAccessedAPITypes</key>
<array>
    <dict>
        <key>NSPrivacyAccessedAPIType</key>
        <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
        <key>NSPrivacyAccessedAPITypeReasons</key>
        <array><string>CA92.1</string></array>
    </dict>
    <dict>
        <key>NSPrivacyAccessedAPIType</key>
        <string>NSPrivacyAccessedAPICategorySystemBootTime</string>
        <key>NSPrivacyAccessedAPITypeReasons</key>
        <array><string>35F9.1</string></array>
    </dict>
</array>

Evaluación de la mecánica de atribución frente a las normas de privacidad de Apple y Google

Diferenciación de las señales de plataforma permitidas frente a la toma de huellas digitales de dispositivos prohibida

Un error crítico durante la adquisición de SDKs es asumir que tres comprobaciones separadas (si existe un archivo PrivacyInfo.xcprivacy, si los códigos de la API de razones requeridas son válidos y si la coincidencia de atribución del lado del servidor del SDK cumple con las reglas de la plataforma) se pueden fusionar en una sola comprobación de archivos. Deben auditarse de forma independiente.

La documentación pública de productos de OpoInstall describe un canal H5 y un flujo de trabajo de instalación de parámetros en el que el SDK web recopila huellas digitales del dispositivo y ID de canal en la página de aterrizaje H5, y el SDK nativo de Android o iOS vuelve a recopilar la huella digital del dispositivo en el primer lanzamiento para hacerla coincidir con la fuente de instalación. Al evaluar cualquier SDK de atribución que describa coincidencias basadas en huellas digitales o probabilísticas, los arquitectos de cumplimiento deben hacer cumplir un límite de plataforma estricto:

• Prohibición antihuellas digitales de Apple: Según las Directrices de privacidad de usuario y uso de datos de Apple, no puedes derivar datos de un dispositivo (como combinar propiedades del navegador, direcciones IP o configuraciones del sistema) con el propósito de identificar unívocamente a un usuario o dispositivo. Las aplicaciones que participan en la toma de huellas digitales prohibida, o que hacen referencia a SDKs de terceros que lo hacen, se arriesgan al rechazo durante la revisión de la App Store.

• Alcance de la Transparencia en el Seguimiento de Aplicaciones (ATT): La autorización de ATT es obligatoria cuando una aplicación realiza el seguimiento de usuarios o dispositivos según la definición de seguimiento de Apple, incluido vincular datos de usuarios o dispositivos recopilados de la app con datos recopilados de apps, sitios web o propiedades fuera de línea de otras empresas para publicidad dirigida o medición publicitaria, o compartir dichos datos con intermediarios de datos. La presencia o ausencia de un identificador único explícito no determina de forma independiente si una implementación constituye seguimiento. Crucialmente, obtener el consentimiento del usuario para ATT no hace que la toma de huellas digitales de dispositivos prohibida sea permisible, ni permite que las API de razones requeridas se utilicen para el seguimiento.

• Auditoría obligatoria de proveedores previa al despliegue: La descripción general del proveedor sobre la coincidencia de huellas digitales de dispositivos no establece el conjunto exacto de señales de iOS ni demuestra de forma independiente una infracción de la política; obtén los detalles de implementación específicos de la versión (como para la versión v2.1.0 en el centro de descargas de SDKs móviles) y evalúalos de forma independiente frente a las restricciones de huellas digitales de Apple. Si un proveedor no puede demostrar que su mecanismo de coincidencia en iOS evita la toma de huellas digitales de dispositivos prohibida, los desarrolladores no deben implementar ese mecanismo de atribución en iOS hasta que se verifique de forma independiente una alternativa compatible, restringiendo el uso en iOS a los enlaces universales de Apple (Apple Universal Links) verificados para el enrutamiento de aplicaciones instaladas.

Evaluación de la atribución en Android: Google Play Install Referrer y mapeo de seguridad de datos

En Android, la evaluación técnica se centra en la integración determinista con la tienda y la alineación completa con la sección de seguridad de datos de Google Play (Google Play's Data Safety Section).

Primero, verifica que el SDK de Android se integre con la API oficial de referencia de instalación de Google Play (com.android.installreferrer:installreferrer) para las descargas elegibles de Google Play Store, al tiempo que admite paquetes de canales de Android exportados (archivos APK que contienen metadatos de channelCode incrustados) para distribuciones que no provienen de Play.

Segundo, debido a que Google Play considera que el editor de la aplicación es el único responsable de enviar una declaración de seguridad de datos precisa que cubra todos los SDKs de terceros incrustados, exige que el proveedor del SDK proporcione un mapeo completo de seguridad de datos en seis dimensiones de auditoría de ingeniería derivadas del formulario oficial de seguridad de datos de Google:

Evaluación de definiciones de API, resiliencia ante tiempos de espera y apertura de datos

Inspección de la definición de API del cliente: contratos de hilos, devoluciones de llamada tipadas y tiempos de espera deterministas

Un SDK de atribución se encuentra directamente en la ruta crítica de tu flujo de incorporación de usuarios. Cuando un nuevo usuario inicia tu app por primera vez, tu controlador de incorporación consulta al SDK para verificar si el usuario llegó a través de un enlace de invitación (?ref=usuarioA) o de una sala de juegos específica (room_id=402).

Al inspeccionar los archivos de encabezado públicos (.h) y las interfaces Kotlin/Java de un SDK candidato, siguiendo las mejores prácticas del proyecto de seguridad de aplicaciones móviles de OWASP (OWASP Mobile Application Security Project) para la revisión de bibliotecas de terceros, verifica que el archivo de SDK descargado real (como la versión v2.1.0) exponga cuatro propiedades de resiliencia:

1. Inicialización asíncrona no bloqueante: La inicialización debe registrar el contexto local sin ejecutar E/S de red sincrónica en el hilo principal de la interfaz de usuario.

2. Tiempo de espera configurable o impuesto por la aplicación: El SDK debe exponer un tiempo de espera de solicitud documentado o admitir un límite de tiempo de la experiencia de usuario (UX) impuesto por la aplicación principal. La app principal debe poder continuar con la incorporación predeterminada cuando expire el plazo, sin esperar indefinidamente a la recuperación de parámetros.

3. Contratos de hilos de finalización determinista y devolución de llamada (callback): El SDK debe documentar el contexto de ejecución de las devoluciones de llamada y el comportamiento de finalización. Si el límite de tiempo de UX impuesto por la app principal expira antes de que el SDK responda, la aplicación debe continuar con la incorporación predeterminada, marcar la solicitud como caducada y omitir o gestionar de forma segura cualquier devolución de llamada tardía. Las actualizaciones de la interfaz de usuario deben enviarse al hilo principal, y la finalización por tiempo de espera no debe activar acciones comerciales duplicadas.

4. Protección del estado local idempotente: Una vez recuperados los parámetros de instalación, la aplicación principal debe proteger su lógica de recompensas de incorporación con un indicador de finalización local para que las invocaciones repetidas no activen acciones comerciales duplicadas.

Evaluación de la apertura de datos del backend: interfaces seguras de exportación de datos HTTP

Una trampa de adquisición común al elegir una herramienta de atribución SaaS es el bloqueo de datos del proveedor, donde las estadísticas de campañas solo se pueden ver dentro de un panel web propietario. Para los equipos de crecimiento empresarial que ejecutan almacenes internos de inteligencia empresarial (BI) o auditorías de retención por cohortes, la exportación programática de datos es esencial.

OpoInstall proporciona un punto de entrada de interfaz de datos documentado en la documentación de su producto; los equipos de ingeniería deben verificar los puntos finales de exportación HTTP exactos, los requisitos de autenticación, los esquemas de respuesta y la disponibilidad en su edición implementada a través de la documentación técnica de OpoInstall antes de la aprobación de la adquisición. Al integrar cualquier API de exportación de datos de backend a través de HTTPS según la norma IETF RFC 9110, haz cumplir dos límites de seguridad:

• Clave de aplicación del cliente (AppKey) frente a credenciales de la API del servidor: La AppKey del inquilino incrustada dentro del archivo AndroidManifest.xml o Info.plist de la aplicación móvil es un identificador de aplicación público, no una credencial secreta. Los puntos finales de exportación de datos del backend deben llamarse exclusivamente desde los servidores de tu backend utilizando credenciales dedicadas del lado del servidor.

• Higiene en el transporte de credenciales: Prefiere pasar las credenciales de la API del servidor en los encabezados de solicitudes HTTP (como Authorization o encabezados de token especificados por el proveedor) en lugar de cadenas de consulta de URL sin procesar siempre que sea compatible con el contrato de API del proveedor, y asegúrate de que los registros del proxy y de la aplicación redacten los parámetros de autenticación.

# Comandos de auditoría previos a la integración ilustrativos para evaluar un SDK candidato

# 1. iOS: Localiza cualquier archivo PrivacyInfo.xcprivacy empaquetado dentro del XCFramework descargado
find libOpoInstallSDK.xcframework -name "PrivacyInfo.xcprivacy"

# 2. iOS: Valida la sintaxis de la lista de propiedades XML e inspecciona las claves declaradas (ajusta la ruta para que coincida con la estructura del archivo)
plutil -lint path/to/PrivacyInfo.xcprivacy
plutil -p path/to/PrivacyInfo.xcprivacy

# 3. Android: Inspecciona el archivo AndroidManifest.xml empaquetado dentro del archivo AAR para auditar los permisos heredados
unzip -p opoinstall-android-sdk.aar AndroidManifest.xml

# 4. Apertura de datos del backend: Patrón de solicitud ilustrativo del lado del servidor (verifica el punto final exacto y el esquema de autenticación en la documentación del proveedor)
curl -X GET "https://api.attribution-vendor.example/v1/exports/channel-growth?startTime=2026-11-01&endTime=2026-11-08" \
  -H "Authorization: Bearer $SERVER_DATA_API_TOKEN" \
  -H "Accept: application/json"

Matriz de evaluación del kit de desarrollo de software de atribución móvil

Tarjeta de puntuación ponderada ejecutable de cinco pilares y controles estrictos

Para transformar la revisión arquitectónica en una decisión objetiva de adquisición de tipo Proceder / No proceder (Go / No-Go), los líderes de ingeniería y cumplimiento deben calificar cada SDK de atribución candidato utilizando una escala de calificación estandarizada de 0–5 en los cinco pilares:

• Puntuación 0: No compatible o el proveedor se niega a proporcionar evidencia de verificación.

• Puntuación 1: Defecto importante de arquitectura o cumplimiento presente.

• Puntuación 2: Soporte parcial con limitaciones operativas significativas o alternativas manuales requeridas.

• Puntuación 3: Cumple con los requisitos básicos de producción con la documentación estándar.

• Puntuación 4: Soporte completo respaldado por artefactos de compilación verificables y contratos de API claros.

• Puntuación 5: Soporte completo para el pilar de evaluación específico, verificado de forma independiente utilizando artefactos técnicos relevantes, pruebas en entornos de prueba (staging) o evidencia documentada.

Para producir una puntuación compuesta normalizada de 0–100, divide la puntuación sin procesar de cada pilar (S\_i \\in \[0, 5\]) entre $5$ y multiplícala por su peso porcentual ($W\_i$):

Por ejemplo, un SDK candidato que obtenga $S\_1 = 5$ ($30\\text{ pts}$), $S\_2 = 4$ ($16\\text{ pts}$), $S\_3 = 4$ ($16\\text{ pts}$), $S\_4 = 4$ ($12\\text{ pts}$) y $S\_5 = 2$ ($6\\text{ pts}$) logra una puntuación compuesta de $80 / 100$. Sin embargo, las puntuaciones compuestas se rigen por controles estrictos de adquisición no negociables (Procurement Hard Gates):

Regla de decisión: Un kit de desarrollo de software candidato debe superar los cuatro controles estrictos de adquisición (Procurement Hard Gates) y lograr una puntuación compuesta normalizada de $\\ge 80 / 100$ antes de ser aprobado para su integración en producción. Ten en cuenta la distinción entre un control normativo (Regulatory Gate) (donde evidencia independiente confirma una infracción de la política de Apple) y un control interno de evidencia de privacidad (Privacy Evidence Gate): la falta por parte de un proveedor de proporcionar evidencia suficiente del cumplimiento de las señales de iOS activa un control interno de evidencia de privacidad; una decisión de adquisición basada en riesgos para retener la implementación de la atribución en iOS, en lugar de una infracción de la política de Apple establecida de forma independiente.

Errores comunes al seleccionar un SDK de atribución móvil

• Error 1: Equiparar la presencia de un archivo PrivacyInfo.xcprivacy con el cumplimiento total de la privacidad de Apple: Incluir un archivo PrivacyInfo.xcprivacy en un .xcframework satisface la comprobación de archivos estáticos de Xcode para las API de razones requeridas, pero no autoriza al SDK a realizar la toma de huellas digitales de dispositivos. Apple prohíbe explícitamente el uso de API de razones requeridas (como SystemBootTime o DiskSpace) o rasgos de red/navegador para tomar huellas digitales de los dispositivos.

• Error 2: Seleccionar un SDK basándose únicamente en los porcentajes principales de tasas de coincidencia: Las afirmaciones de marketing sobre una alta precisión en la restauración de parámetros a menudo reflejan condiciones ideales de laboratorio. Los arquitectos deben probar cómo se comporta el SDK en casos extremos del mundo real: primeros lanzamientos con retraso, modos de navegación privada, vistas web sociales dentro de aplicaciones (WebViews) y primeros lanzamientos sin conexión.

• Error 3: Pasar por alto la compatibilidad de compilación de versiones y el mantenimiento multiplataforma: Un SDK que funciona en una compilación de depuración (debug) puede fallar en una compilación de producción minificada si sus interfaces de devolución de llamada son eliminadas por Android R8/ProGuard o si sus complementos contenedores multiplataforma se retrasan con respecto a las actualizaciones nativas del sistema operativo.

Resumen y lista de verificación de selección técnica

Saber cómo elegir un kit de desarrollo de software para la atribución móvil requiere equilibrar los objetivos de medición de marketing con un estricto cumplimiento del sistema operativo y confiabilidad en tiempo de ejecución. Al auditar los SDKs candidatos a través de manifiestos de privacidad, protocolos de enrutamiento nativos de la plataforma, resiliencia ante tiempos de espera de devoluciones de llamada, higiene de compilación y apertura de datos (y al aplicar controles estrictos de adquisición no negociables), los líderes técnicos pueden proteger sus aplicaciones contra rechazos de revisión en las tiendas y regresiones en la incorporación.

Antes de aprobar cualquier integración de SDK de atribución, ejecuta esta lista de verificación de adquisiciones de cuatro pasos:

• Verifica el manifiesto de privacidad y el cumplimiento de señales: Confirma que el archivo descargado para iOS (como la versión v2.1.0) contenga un manifiesto PrivacyInfo.xcprivacy sintácticamente válido (plutil -lint), verifica que todos los códigos de la API de razones requeridas coincidan con las reglas aprobadas fuera del dispositivo y confirma con el proveedor que la atribución en iOS evita la toma de huellas digitales de dispositivos prohibida.

• Completa el mapeo de seguridad de datos de Google Play: Inspecciona el archivo AndroidManifest.xml empaquetado dentro del archivo .aar en busca de permisos peligrosos no aprobados, y obtén el inventario de datos completo del proveedor para mapear todos los campos de respuesta de Install Referrer, identificadores de dispositivos y propósitos de recopilación/compartición en tu declaración de seguridad de datos de Google Play Console.

• Prueba la resiliencia ante tiempos de espera y respaldos (fallbacks): Verifica todas las firmas de métodos reales en tu entorno de compilación limpia y simula condiciones de red fuera de línea y de alta latencia durante el primer lanzamiento para confirmar que la devolución de llamada de recuperación de parámetros del SDK o el límite de tiempo de UX de la aplicación principal se completan de manera determinista sin bloquear la interfaz de usuario.

• Calcula la puntuación de adquisición normalizada: Verifica las capacidades de exportación de la interfaz de datos documentada de la plataforma y confirma que el candidato supera los cuatro controles estrictos de adquisición con una puntuación compuesta normalizada de $\\ge 80 / 100$.

Los equipos de ingeniería pueden registrar una aplicación de prueba en la consola para desarrolladores de OpoInstall para inspeccionar los archivos actuales del SDK, probar el comportamiento de los tiempos de espera y evaluar la idoneidad de la integración en un entorno aislado (sandbox).

Materiales relacionados

• Conceptos: Selección de kits de desarrollo de software, manifiesto de privacidad de Apple, API de razones requeridas, seguridad de datos de Google Play

• Tecnologías: PrivacyInfo.xcprivacy, informe de privacidad de Xcode, API de referencia de instalación de Google Play (Google Play Install Referrer API), interfaces de exportación de datos HTTP

• Estándares: Semántica HTTP IETF RFC 9110, Sintaxis genérica URI IETF RFC 3986, Proyecto de seguridad de aplicaciones móviles de OWASP (OWASP Mobile Application Security Project)

• Interfaces de plataforma e integración: NSPrivacyAccessedAPITypes, UserDefaults (CA92.1), SystemBootTime (35F9.1), DiskSpace (E174.1)

• Documentación oficial y referencias:

  • Documentación para desarrolladores de Apple sobre archivos de manifiesto de privacidad

  • Documentación para desarrolladores de Apple sobre cómo describir el uso de la API de razones requeridas

  • Soporte para desarrolladores de Apple sobre los requisitos de SDKs de terceros

  • Directrices de privacidad de usuario y uso de datos de Apple

  • Ayuda de Google Play Console sobre la sección de seguridad de datos

  • Guía técnica de la API de referencia de instalación de Google Play