Cómo identificar y evitar el abandono durante la incorporación para reducir la tasa de churn

¿Cómo calcular y reducir la tasa de churn de una aplicación? La tasa de churn de una aplicación debe calcularse sobre una cohorte de usuarios elegibles claramente definida y una ventana de inactividad: $C(W) = \frac{|U_{\text{inactive}}(W)|}{|U_0|} \times 100\%$ . El abandono en la incorporación antes de la activación debe medirse por separado como un abandono por paso, en lugar de mezclarlo con el churn del ciclo de vida.

La tasa de churn mide la proporción de usuarios que interrumpen el compromiso activo con una aplicación durante una ventana de medición designada. En analítica de productos móviles, gestionar con precisión el churn requiere separar el abandono durante la incorporación previa a la activación del churn del ciclo de vida post-activación, permitiendo a los equipos eliminar la fricción en la configuración inicial antes de que ocurra la pérdida a largo plazo.

Término	Definición	Entidad relacionada	Rol de intención de búsqueda
Tasa de Churn	La proporción de una base de usuarios activos que interrumpe el compromiso con el tiempo.	Retención de usuarios	Informativo / Comercial
Tasa de abandono en la incorporación	El porcentaje de usuarios que abandonan pasos secuenciales antes de la activación principal.	User Journey	Técnico / Informativo
Analítica de aplicaciones	La telemetría programática que rastrea el progreso del usuario y las transiciones del ciclo de vida.	Análisis de cohorte	Informativo

Por qué es fundamental distinguir el abandono en la incorporación del churn del ciclo de vida

El punto ciego de diagnóstico de las métricas de churn combinadas

Evaluar la pérdida de aplicaciones móviles a través de una métrica de churn única y agregada crea un punto ciego de diagnóstico crítico. Cuando los equipos de analítica miden el churn únicamente como la proporción agregada de usuarios recién adquiridos que no regresan después de 30 días, mezclan dos modos de falla fundamentalmente diferentes: los usuarios que abandonaron la aplicación durante la configuración inicial antes de experimentar el valor funcional, y aquellos que se activaron con éxito pero luego discontinuaron su uso por falta de utilidad recurrente.

Una tasa de churn combinada no ofrece ninguna perspectiva accionable sobre dónde ocurre la pérdida de usuarios. Si la pérdida ocurre principalmente durante la creación inicial de la cuenta, la verificación de identidad o las solicitudes de permisos en el Día 0, el cuello de botella es la fricción procedimental de la incorporación. Por el contrario, si los usuarios completan la configuración con éxito pero abandonan entre el Día 14 y el Día 30, el problema radica en la mecánica de retención a largo plazo, la profundidad de las funciones o la sustitución competitiva. Combinar el abandono del embudo pre-activación con el churn del ciclo de vida post-activación hace que los equipos asignen incorrectamente los recursos de ingeniería.

Pre-activación vs. Post-activación: Mapeo del abandono a lo largo del user journey

Para establecer una estrategia eficaz de conversión y retención, los equipos técnicos dividen el user journey en dos fases operativas distintas:

Fase de pre-activación (Embudo de incorporación): Abarca desde el lanzamiento inicial de la app hasta la finalización del hito de activación central (ej. crear un espacio de trabajo, vincular una cuenta o completar la primera transacción). La pérdida en esta fase se mide como tasa de abandono en la incorporación, evaluando la eficiencia de conversión paso a paso a través de una máquina de estados estructurada.
Fase de post-activación (Retención del ciclo de vida): Comienza una vez que el usuario completa con éxito el hito de activación central e ingresa a la base de usuarios activos. La pérdida en esta fase se mide como tasa de churn del ciclo de vida, evaluando la inactividad sostenida a través de ventanas de calendario rodantes ( $D_1 \dots D_{90}$ ) o eventos terminales explícitos.

[Mapeo del ciclo de vida del user journey]
┌───────────────────────────────────────────────────┬───────────────────────────────────────────────┐
│           EMBUDO DE PRE-ACTIVACIÓN                │          CICLO DE VIDA POST-ACTIVACIÓN          │
├───────────────────────────────────────────────────┼───────────────────────────────────────────────┤
│ Lanzamiento ──> Permisos ──> Autenticación ──> Activación │ Retorno D1 ──> Retorno D7 ──> Estado activo D30  │
│                                                   │                                                 │
│ Métrica: Tasa de abandono en la incorporación     │ Métrica: Churn por inactividad / Tasa de no retorno │
│ Foco diagnóstico: Fricción procedimental y de IU  │ Foco diagnóstico: Utilidad y retención continua │
└───────────────────────────────────────────────────┴───────────────────────────────────────────────┘

Abandono en incorporación frente a no retorno y churn del ciclo de vida

Por qué tratar el abandono en la incorporación como una falla del producto conduce a intervenciones ineficaces

Cuando los equipos de producto diagnostican erróneamente el abandono temprano en la incorporación como una falta de adecuación producto-mercado, a menudo implementan cambios estructurales en el producto central, como rediseñar paneles, modificar niveles de precios o alterar flujos de trabajo principales. Sin embargo, si los nuevos usuarios abandonan la aplicación porque un formulario de registro requería la entrada manual de un código de invitación alfanumérico, los ajustes posteriores no resolverán la causa raíz.

Las barreras procedimentales impiden que los usuarios alcancen la propuesta de valor central. Resolver el abandono temprano del embudo requiere eliminar la fricción en el punto de entrada: simplificar la verificación de identidad, posponer permisos no esenciales y restaurar programáticamente el contexto de adquisición, asegurando que el tráfico adquirido pase a cohortes activadas elegibles para un análisis de retención a largo plazo.

Los desarrolladores que buscan integrar telemetría de cliente y SDKs de atribución pueden explorar paquetes a través del paquete SDK de analítica móvil.

Cómo calcular la tasa de churn en ventanas de inactividad y puntos de control de cohorte

Formulación del churn del ciclo de vida definido por inactividad

En la analítica del ciclo de vida post-activación, el churn se formula sobre una base de cohorte durante una ventana de inactividad predefinida $W$ (ej. 14, 30 o 60 días consecutivos).

Sea $U_0$ la cohorte base de usuarios calificados que completaron la activación principal en la fecha de anclaje $D_0$ :

U_0 = \{u : \text{ActivationMilestone}(u) = D_0\}

Sea $U_{\text{inactive}}(W)$ el subconjunto de la cohorte $U_0$ que registró cero sesiones activas calificadas durante la ventana de observación $W = [D_0 + t_1, D_0 + t_2]$ :

U_{\text{inactive}}(W) = \{u \in U_0 : \forall \, t \in [t_1, t_2], \; \text{HasQualifyingSession}(u, t) = \text{False}\}

La Tasa de Churn del Ciclo de Vida definida por Inactividad $C(W)$ se calcula como:

C(W) = \frac{|U_{\text{inactive}}(W)|}{|U_0|} \times 100\%

El churn basado en la inactividad es una clasificación operativa. Un usuario inactivo no está perdido permanentemente, ya que los usuarios inactivos pueden reactivarse en períodos posteriores tras gatillos de re-compromiso o actualizaciones del producto.

Las definiciones de retención de la plataforma pueden usar diferentes reglas de población. Por ejemplo, la retención de App Store Connect evalúa los dispositivos activos que instalaron la aplicación y finalmente la abrieron, por lo que los modelos de churn internos deben documentar su denominador por separado en lugar de asumir que las poblaciones de la plataforma y del almacén de datos son idénticas.

Cálculo de tasas de abandono paso a paso en la incorporación

La eficiencia de la incorporación pre-activación se mide secuencialmente a través de los pasos discretos del embudo de configuración.

Sea $U_k$ el conjunto de usuarios que ingresaron con éxito al paso $k$ de la secuencia de incorporación, y sea $U_{k+1}$ el subconjunto que avanzó con éxito al paso $k+1$ :

\text{Step Conversion Rate}_k = \frac{|U_{k+1}|}{|U_k|} \times 100\%

La tasa de abandono por paso en la incorporación $\text{DropOff}_k$ es el complemento de la conversión del paso:

\text{DropOff}_k = \left( 1.0 - \frac{|U_{k+1}|}{|U_k|} \right) \times 100\%

Rastrear los abandonos por paso permite a los equipos de ingeniería aislar cuellos de botella específicos en la interfaz, como tiempos de espera de la API de autenticación, entrada obligatoria de credenciales o solicitudes de permisos intrusivas.

Diferenciación del no retorno en el Día N de la pérdida permanente de usuario

En el modelado clásico de retención por día exacto, el complemento de la tasa de retención del Día $n$ ( $1.0 - R_n$ ) representa la parte de no retorno para ese día calendario específico:

\text{NonReturn}_n = \left( 1.0 - \frac{|A_n|}{|U_0|} \right) \times 100\%

Donde $A_n$ es el subconjunto activo en el día exacto $n$ .

El no retorno en el Día $n$ no debe equipararse con churn permanente. En muchas aplicaciones de consumo y empresariales, los usuarios operan en cadencias episódicas o no diarias. Un usuario que no registra sesión activa en el Día 1 o Día 3 puede regresar el Día 7. Equiparar el no retorno diario con la deserción permanente infla las estimaciones de churn y engaña el modelado del ciclo de vida.

Continuación multi-punto de control y ratios de no retorno

Para evaluar si los usuarios activos en un hito temprano continúan su compromiso a través de hitos posteriores, los motores de analítica evalúan el ratio de continuación del punto de control $Q(t_1, t_2)$ .

Dados los subconjuntos de usuarios activos $A_{t_1}$ y $A_{t_2}$ en los hitos $t_1$ y $t_2$ (ej. Día 7 y Día 30):

Q(t_1, t_2) = \frac{|A_{t_1} \cap A_{t_2}|}{|A_{t_1}|}

El Ratio de No Retorno del Punto de Control se formula como:

\text{NonReturn}(t_1, t_2) = 1.0 - Q(t_1, t_2)

Esta métrica aísla la deserción que ocurre estrictamente entre los usuarios que previamente habían demostrado compromiso activo, separando la deserción continua del ciclo de vida del abandono temprano post-instalación.

Mecánica matemática del abandono del embudo y modelos de churn por inactividad

Comparación de métricas de deserción entre etapas del ciclo de vida

Para garantizar el rigor analítico entre los equipos de producto y de ingeniería, las métricas móviles deben categorizarse por etapa de evaluación, población objetivo y alcance diagnóstico.

La matriz a continuación contrasta las métricas primarias de abandono del embudo y del ciclo de vida:

Dimensión de medición	Fórmula de cálculo	Población de usuarios evaluada	Objetivo diagnóstico primario
Abandono paso a paso de la incorporación	$\text{DropOff}_k = 1.0 - \frac{\vert U_{k+1} \vert}{\vert U_k \vert}$	Usuarios entrando en el paso $k$ pre-activación	Identifica fricción de IU y procedimental
Cuota de no retorno Día-N	$\text{NonReturn}_n = 1.0 - \frac{\vert A_n \vert}{\vert U_0 \vert}$	Cohorte exacta en el Día $n$ post-instalación	Mide la varianza del retorno por día exacto
Churn del ciclo de vida por inactividad	$C(W) = \frac{\vert \{u \in U_0 : \text{NoActivity}(u, W)\} \vert}{\vert U_0 \vert}$	Cohorte a través de la ventana definida $W$	Mide la deserción sostenida del cliente
Churn de cuenta terminal	$C_{\text{terminal}} = \frac{\vert U_{\text{deleted}} \vert}{\vert U_0 \vert}$	Usuarios que activan eventos de eliminación	Mide la terminación explícita del ciclo de vida de la cuenta

Matriz comparativa de métricas de churn y abandono en la incorporación

¿Cómo reduce la incorporación parametrizada la fricción de conversión temprana?

La barrera de la entrada manual: cómo los códigos promocionales y los campos de formulario inflan los abandonos por paso

La entrada manual de datos puede introducir una fricción procedimental significativa en los flujos de incorporación impulsados por referencias, invitaciones y campañas, especialmente cuando los usuarios deben reconstruir el contexto tras la instalación. Los usuarios a menudo hacen clic en un enlace en la web móvil y son redirigidos a la tienda de aplicaciones. Al descargar y lanzar la aplicación por primera vez, encuentran un formulario de registro no configurado que les exige ingresar manualmente un código de invitación alfanumérico o buscar un ID de espacio de trabajo específico.

Requerir la entrada manual introduce fricción en una coyuntura crítica. Los usuarios deben salir de la aplicación, localizar el código de referencia en una aplicación de mensajería externa o correo electrónico, copiar la cadena al portapapeles del sistema, volver a la aplicación y pegarla en el formulario. En cada punto de transición, el cambio de contexto, la presión de memoria o la distracción aumentan la probabilidad de abandono de la sesión.

Preservación de datos contextuales: Restauración de tokens de referencia y campaña a través de la barrera de instalación

La incorporación parametrizada mitiga esta fricción preservando programáticamente el contexto de adquisición a través de la barrera de instalación de la tienda de aplicaciones.

OpoInstall, una plataforma de atribución móvil y enlaces profundos, implementa enlaces profundos diferidos capturando parámetros de consulta de URL (como ?inviter_id=usr_8842&promo_code=WELCOME50) en la página de aterrizaje web. Cuando el usuario instala y abre la aplicación por primera vez, el SDK móvil nativo recupera los parámetros almacenados en caché desde el backend de atribución.

La restauración de parámetros depende de los mecanismos de asociación admitidos disponibles para la implementación. En las plataformas de Apple, el flujo de trabajo subyacente debe cumplir con los requisitos de privacidad actuales de la App Store y no debe derivar una identidad estable de usuario o dispositivo mediante fingerprinting; los parámetros elegibles deben restaurarse solo a través de mecanismos compatibles y que cumplan con la política.

Los ingenieros pueden consultar la documentación de restauración de parámetros para obtener especificaciones técnicas sobre la recuperación y el manejo de cargas útiles de parámetros dinámicos dentro de los ciclos de vida de las aplicaciones nativas.

Aprovisionamiento automático de cuentas: Entrega de estados de bienvenida fluidos mediante el SDK de OpoInstall

Restaurar los parámetros de adquisición al lanzamiento inicial permite a las aplicaciones automatizar los pasos de configuración y eliminar los campos de formulario manuales. Cuando la aplicación recibe la carga útil de parámetros durante la inicialización, completa programáticamente las credenciales de referencia, aplica tokens de descuento promocional y redirige al usuario directamente al espacio de trabajo o vista de contenido relevante.

El diagrama a continuación ilustra el flujo operativo desde el clic promocional inicial hasta la evaluación de la incorporación:

[Clic en promo / referencia web] ──> [SDK web prepara contexto y tokens]
             │                                   │
             ▼                                   ▼
   [Instalar y abrir desde tienda]      ──> [SDK OpoInstall restaura contexto]
             │                                   │
             ▼                                   ▼
 [Credenciales autopobladas]    ──> [Evita formulario manual y fricción]
             │                                   │
             ▼                                   ▼
    [Activación núcleo Día 0]    ──> [Comparar abandono vs Control]

Al eliminar los requisitos de entrada manual y acelerar la transición desde el primer abierto hasta la activación principal, la incorporación parametrizada mitiga la fricción del embudo del Día 0, lo que permite a los equipos de crecimiento evaluar si una incorporación optimizada ofrece tasas de activación más altas en comparación con cohortes de control no asistidas.

Diagnóstico de cuellos de botella a nivel de paso desde el lanzamiento hasta la activación central

Instrumentación de telemetría secuencial desde el lanzamiento de la aplicación hasta el hito de primer valor

Para identificar las interfaces específicas donde los usuarios abandonan la incorporación, las arquitecturas de analítica modelan el flujo de trabajo de configuración como una máquina de estados finitos instrumentada. Cada paso distinto emite un evento de telemetría estructurado que contiene el identificador del paso, la duración de la transición y el estado de ejecución:

Paso 1 (onboarding_launch): Inicialización del cliente y ejecución de consulta de parámetros.
Paso 2 (onboarding_permission_prompt): Presentación de solicitudes de notificación o seguimiento en tiempo de ejecución.
Paso 3 (onboarding_auth_submit): Envío de credenciales de usuario o autenticación mediante inicio de sesión único.
Paso 4 (onboarding_profile_setup): Configuración de preferencias de usuario, selección de organización o unión a un espacio de trabajo.
Paso 5 (onboarding_activation_complete): Ejecución del hito de valor funcional principal.

Análisis de latencia de transición: separación de cuellos de botella técnicos de la resistencia del usuario

Medir solo los porcentajes de finalización proporciona una imagen diagnóstica incompleta. Los canales de telemetría deben rastrear la latencia de transición: el tiempo transcurrido entre pasos consecutivos del embudo ( $\Delta t = t_{k+1} - t_k$ ).

Evaluar la latencia de transición ayuda a separar las fallas técnicas de la fricción del usuario:

Patrón ilustrativo de baja latencia ( $\Delta t < 3\text{s}$ ): Los usuarios abandonan el paso casi de inmediato. Este patrón a menudo sugiere una resistencia inmediata a los requisitos obligatorios (ej. solicitudes inesperadas de tarjeta de crédito o permisos intrusivos) o errores de navegación de la interfaz del lado del cliente.
Patrón ilustrativo de latencia prolongada ( $\Delta t > 45\text{s}$ ): Los usuarios pasan mucho tiempo antes de abandonar. Este patrón indica dificultad cognitiva, diseños de formularios confusos, complejidad en la validación de contraseñas o tiempos de respuesta lentos de la API del backend en los puntos finales de verificación.

Los umbrales deben calibrarse a partir de la propia distribución de latencia del producto en lugar de tratarse como puntos de referencia universales.

Matriz de diagnóstico de abandono de incorporación y latencia de transición

Estructuración de cargas útiles de telemetría de diagnóstico para la optimización del embudo

Cada evento de telemetría de incorporación debe incluir propiedades de metadatos contextuales que vinculen el rendimiento del paso con el estado del dispositivo, las condiciones de la red y los parámetros de adquisición.

La carga útil a continuación demuestra un evento de telemetría ilustrativo orientado a la producción diseñado para el análisis de abandono de incorporación y latencia:


```json
{
  "schema_version": "1.2.0",
  "event_id": "evt_dropoff_9a8b7c6d-5e4f-3a2b-1c0d-8f7e6d5c4b3a",
  "event_name": "onboarding_step_telemetry",
  "client_event_timestamp_utc": "2026-08-30T14:20:10.150Z",
  "session_elapsed_monotonic_ms": 48200,
  "server_received_timestamp_utc": "2026-08-30T14:20:10.820Z",
  "user_identity": {
    "app_instance_id": "inst_anon_a1b2c3d4-e5f6-7890-abcd-ef1234567890",
    "is_first_launch": true
  },
  "funnel_telemetry": {
    "session_id": "sess_onboarding_9876543210fedcba",
    "event_sequence_index": 4,
    "step_index": 3,
    "step_name": "onboarding_auth_submit",
    "step_transition_duration_ms": 4250,
    "is_step_completed": true,
    "has_input_validation_error": false
  },
  "attribution_context": {
    "acquisition_channel": "referral_invite",
    "campaign_id": "cmp_q3_onboarding_drive",
    "channel_code": "partner_affiliate_tier1",
    "inviter_token_pseudonymous": "ref_tok_anon_77665544",
    "parameter_restoration_status": "restored_success"
  },
  "device_telemetry": {
    "platform": "Android",
    "os_version": "16.0",
    "app_version": "3.2.0",
    "sdk_version": "<installed_sdk_version>",
    "network_type": "WIFI",
    "device_tier": "mid_range"
  },
  "diagnostic_metadata": {
    "is_background_wake": false,
    "memory_pressure_state": "normal",
    "ui_render_latency_ms": 16
  }
}

¿Cuándo son efectivas las intervenciones automatizadas para la prevención del churn?

Prompts in-app activados por acción vs. mensajes de difusión prematuros

Las intervenciones automatizadas (como tooltips contextuales, modales de guía en la app y notificaciones transaccionales) son efectivas cuando se activan por un comportamiento específico del usuario en lugar de programas de difusión genéricos. Si la telemetría indica que un usuario se estancó en el Paso 4 (onboarding_profile_setup) durante un intervalo prolongado, un tooltip adaptativo en la app puede ofrecer asistencia contextual.

Por el contrario, enviar notificaciones de difusión genéricas a usuarios que no han experimentado un valor funcional principal crea molestia. Las intervenciones deben ser relevantes para el progreso actual del usuario dentro del flujo de trabajo de configuración.

Enlaces profundos contextuales: Guiar a usuarios inactivos directamente a flujos de trabajo incompletos

Desplegar enlaces profundos contextuales (Universal Links en iOS y App Links en Android) permite a la aplicación dirigir a un usuario que regresa y está autorizado al flujo de trabajo incompleto relevante. La aplicación sigue siendo responsable de validar el destino y restaurar cualquier flujo de trabajo, autenticación o estado de sesión requerido.

Por ejemplo, si un usuario creó una cuenta el Día 0 pero no completó la configuración del proyecto, una notificación de re-compromiso puede redirigirlo directamente a la pantalla de configuración del proyecto con parámetros autopoblados.

Límites de permisos de notificación del sistema operativo

Toda comunicación de re-compromiso debe cumplir estrictamente con los marcos de permisos de la plataforma móvil. En iOS, las aplicaciones deben solicitar autorización antes de presentar alertas, sonidos o insignias orientadas al usuario a través de UNUserNotificationCenter.current().requestAuthorization(options: [.alert, .badge, .sound]). En Android 13+, las aplicaciones deben obtener el permiso de tiempo de ejecución android.permission.POST_NOTIFICATIONS.

Además, los equipos de ingeniería deben implementar una gestión persistente del estado de exclusión y límites de frecuencia. Enviar notificaciones de alta frecuencia sin el consentimiento del usuario puede crear fatiga de notificación, contribuyendo a la desinstalación inmediata y elevando el churn a largo plazo.

Evaluación de cuándo intervenir: Equilibrio entre recordatorios oportunos y fatiga del usuario

Intervenciones efectivas: Asistencia de configuración activada por acción, enlaces profundos personalizados que devuelven a los usuarios a formularios incompletos y restauración automática de parámetros tras el primer lanzamiento.
Intervenciones ineficaces: Mensajería de difusión de alta frecuencia, exigir permisos de push antes de demostrar valor y obligar a los usuarios a completar pasos de configuración no esenciales antes de acceder a las funciones principales.

Preguntas Frecuentes (FAQ)

¿Cuál es la diferencia entre la tasa de abandono en la incorporación y la tasa de churn de la aplicación?

La tasa de abandono en la incorporación mide el porcentaje de usuarios que abandonan pasos secuenciales durante el flujo inicial de configuración o registro antes de alcanzar el hito de activación central. La tasa de churn de la aplicación mide la proporción de usuarios previamente activados que dejan de interactuar con la aplicación durante una ventana de observación posterior a la activación.

¿Puede una aplicación evitar todo el churn de usuarios mediante la optimización de la incorporación?

No. Optimizar la incorporación elimina la fricción procedimental (como la entrada manual de códigos o flujos de configuración confusos) y reduce el abandono temprano, pero la retención a largo plazo depende de la utilidad sostenida del producto, la relevancia continua de las funciones, la fiabilidad técnica y un compromiso efectivo con el ciclo de vida.

¿Cómo reduce el abandono del registro la restauración de parámetros?

La restauración de parámetros captura tokens de referencia, metadatos de campaña o claves de destino de clics web previos a la descarga y los pasa automáticamente a la aplicación en el primer lanzamiento. Esto elimina la necesidad de que los usuarios escriban manualmente códigos de invitación o busquen contenido específico, eliminando la fricción procedimental y reduciendo los abandonos a nivel de paso.

Resumen y marco de decisión

Reducir eficazmente el churn de las aplicaciones móviles requiere desacoplar los abandonos en la incorporación pre-activación de la deserción en el ciclo de vida post-activación. Mientras que el churn a largo plazo refleja la adecuación continua producto-mercado y la utilidad recurrente, los abandonos tempranos a menudo surgen de la fricción procedimental durante el user journey inicial.

El diagnóstico y la mitigación de la pérdida temprana de usuarios depende de establecer una telemetría de embudo estructurada, rastrear la latencia de transición paso a paso y eliminar barreras de entrada manual innecesarias. Mediante la implementación de una integración ligera de SDK y la restauración de parámetros contextuales, plataformas como OpoInstall proporcionan la infraestructura necesaria para agilizar la incorporación inicial y respaldar la retención de usuarios a largo plazo.

Para evaluar cómo la infraestructura unificada de atribución y paso de parámetros puede optimizar el embudo de incorporación de su aplicación, explore la referencia de implementación de atribución móvil o regístrese en la consola de desarrollador de OpoInstall.

Materiales relacionados

Conceptos: Tasa de Churn de App, Tasa de abandono en la incorporación, Telemetría de embudo, Incorporación parametrizada, Latencia de transición
Tecnologías: Analítica de aplicaciones móviles, Enlaces profundos diferidos, Telemetría del ciclo de vida del cliente, Webhooks S2S
APIs e interfaces de datos: Android ProcessLifecycleOwner, iOS UIWindowSceneDelegate, API getInstallParam del SDK de OpoInstall
Documentación oficial y referencias: