---
title: "Eventos para enviar a integraciones de terceros"
description: "Realiza el seguimiento de los eventos clave de suscripción con las herramientas de análisis de Adapty."
---

Apple y Google envían los eventos de suscripción directamente a los servidores mediante las [Notificaciones del servidor de App Store](enable-app-store-server-notifications) y las [Notificaciones de desarrollador en tiempo real (RTDN)](enable-real-time-developer-notifications-rtdn). Como resultado, las apps móviles no pueden enviar eventos a los sistemas de análisis en tiempo real de forma fiable. Por ejemplo, si un usuario se suscribe pero nunca vuelve a abrir la app, el desarrollador no recibirá ninguna actualización del estado de la suscripción sin un servidor.

Adapty cubre esta brecha recopilando datos de suscripción y convirtiéndolos en eventos legibles. Estos eventos de integración se envían en formato JSON. Aunque todos los eventos comparten la misma estructura, sus campos varían según el tipo de evento, el store y la configuración específica. Puedes consultar los campos exactos incluidos en cada evento en las páginas de integración correspondientes.

Para entender cómo determinar si un evento se procesó correctamente o si algo salió mal, consulta la página de [estados de eventos](event-statuses).

## Tipos de eventos \{#event-types\}

La mayoría de los eventos se crean y envían a todas las integraciones configuradas si están habilitadas. Sin embargo, el evento **Access level updated** solo se activa si la [integración de webhook](webhook) está configurada y este evento está habilitado. Este evento aparecerá en el [Event Feed](https://app.adapty.io/event-feed) y también se enviará al webhook, pero no se compartirá con otras integraciones.

Si no hay ninguna integración de webhook configurada o este tipo de evento no está habilitado, el evento **Access level updated** no se creará y no aparecerá en el [Event Feed](https://app.adapty.io/event-feed).

| Nombre del evento | Descripción |
|:-----------------------------------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| subscription_started | Se activa cuando un usuario activa una suscripción de pago sin período de prueba, es decir, se le cobra de inmediato. |
| subscription_renewed | Ocurre cuando se renueva una suscripción y se cobra al usuario. Este evento comienza a partir de la segunda facturación, tanto en suscripciones con prueba como sin ella. |
| subscription_renewal_cancelled | El usuario ha desactivado la renovación automática de la suscripción. El usuario conserva el acceso a las funciones premium hasta el final del período de suscripción pagado. |
| subscription_renewal_reactivated | Se activa cuando un usuario reactiva la renovación automática de la suscripción. |
| subscription_expired | Se activa cuando una suscripción finaliza por completo tras ser cancelada. Por ejemplo, si un usuario cancela una suscripción el 12 de diciembre pero esta permanece activa hasta el 31 de diciembre, el evento se registra el 31 de diciembre cuando la suscripción expira. |
| subscription_paused | Ocurre cuando un usuario activa la [pausa de suscripción](https://developer.android.com/google/play/billing/lifecycle/subscriptions#pause) (solo Android). |
| subscription_deferred | Se activa cuando una compra de suscripción se [aplaza](https://adapty.io/glossary/subscription-purchase-deferral/), lo que permite a los usuarios retrasar el pago manteniendo el acceso a las funciones premium. Esta función está disponible a través de la Google Play Developer API y puede usarse para pruebas gratuitas o para ayudar a usuarios con dificultades económicas. |
| non_subscription_purchase | Cualquier compra que no sea una suscripción, como el acceso de por vida o productos consumibles como monedas del juego. |
| trial_started | Se activa cuando un usuario activa una suscripción de prueba. |
| trial_converted | Ocurre cuando finaliza una prueba y se cobra al usuario (primera compra). Por ejemplo, si un usuario tiene una prueba hasta el 14 de enero pero se le cobra el 7 de enero, este evento se registra el 7 de enero. |
| trial_renewal_cancelled | El usuario desactivó la renovación automática de la suscripción durante el período de prueba. El usuario conserva el acceso a las funciones premium hasta que finalice la prueba, pero no se le cobrará ni comenzará una suscripción. |
| trial_renewal_reactivated | Ocurre cuando un usuario reactiva la renovación automática de la suscripción durante el período de prueba. |
| trial_expired | Se activa cuando finaliza una prueba sin convertirse en suscripción. |
| entered_grace_period | Ocurre cuando falla un intento de pago y el usuario entra en un período de gracia (si está habilitado). El usuario conserva el acceso premium durante este tiempo. |
| billing_issue_detected | Se activa cuando ocurre un problema de facturación durante un intento de cobro (p. ej., saldo insuficiente en la tarjeta). |
| subscription_refunded | Se activa cuando se reembolsa una suscripción (p. ej., por parte del soporte de Apple). |
| non_subscription_purchase_refunded | Se activa cuando se reembolsa una compra que no es una suscripción. |
| access_level_updated | Ocurre cuando se actualiza el nivel de acceso de un usuario. |

Los eventos anteriores cubren completamente el estado de los usuarios en cuanto a compras. Veamos algunos ejemplos.

### Ejemplo 1 \{#example-1\}

_El usuario activó una suscripción mensual el 1 de abril con un periodo de prueba de 7 días. El día 4, se dio de baja._

En ese caso, se enviarán los siguientes eventos:

1. `trial_started` el 1 de abril
2. `trial_renewal_cancelled` el 4 de abril
3. `trial_expired` el 7 de abril

### Ejemplo 2 \{#example-2\}

_El usuario activó una suscripción mensual el 1 de abril con un periodo de prueba de 7 días. El día 10, se dio de baja._

En ese caso, se enviarán los siguientes eventos:

1. `trial_started` el 1 de abril
2. `trial_converted` el 7 de abril
3. `subscription_renewal_cancelled` el 10 de abril
4. `subscription_expired` el 1 de mayo

Para un desglose detallado de qué eventos se activan en cada escenario, consulta los [flujos de eventos](event-flows).