Le journal des événements d’abonnement fournit des données d’abonnement au niveau des événements pour votre chaîne Prime Video. Accédez aux événements bruts liés aux abonnements, notamment les changements de statut Start, Renewal, Cancel et Auto Renew, avec des identifiants clients anonymisés, afin de créer des analyses personnalisées adaptées aux besoins de votre entreprise. Ce guide présente le modèle de données, les dimensions, les métriques et les meilleures pratiques pour élaborer des analyses des abonnements.
Pourquoi utiliser le journal des événements d’abonnement ?
Le journal des événements d’abonnement fournit un historique des modifications des analyses d’abonnement allant au-delà de ce qui est disponible dans les tableaux de bord prédéfinis :
- Analyses personnalisées : créez des métriques adaptées à vos définitions commerciales spécifiques et à vos besoins de reporting à l’aide de données brutes au niveau des événements
- Intégration de l’entrepôt de données : intégrez les données d’abonnement Prime Video à vos systèmes internes et à d’autres sources de données pour une analyse complète
- Logique métier flexible : appliquez vos propres règles de consolidation, votre logique de déduplication et vos calculs de métriques pour répondre aux besoins de votre entreprise
- Suivi du cycle de vie des clients : suivez les parcours individuels des clients via les événements d’abonnement grâce à des identifiants anonymes stables
Comment ça marche
Le journal des événements d’abonnement fournit les données d’abonnement sous forme de flux d’événements à ajouter uniquement via une API. Chaque enregistrement représente un événement distinct dans le cycle de vie de l’abonnement d’un client. Les données contiennent des événements bruts sans logique métier préappliquée, ce qui vous donne une flexibilité totale pour calculer les métriques en fonction de vos besoins.
Choisir la bonne méthode d’accès aux données
Slate Insights propose deux manières d’accéder aux données d’abonnement :
Fonctionnalité |
Tableau de bord Slate Analytics |
Journal des événements d’abonnement (API) |
Idéal pour |
Informations rapides, rapports exécutifs |
Analyses personnalisées, ingénierie des données |
Format de données |
Métriques pré-agrégées |
Données brutes au niveau des événements |
Logique de consolidation |
Appliqué automatiquement |
Vous appliquez votre propre logique |
Déduplication |
Géré pour vous |
Vous dédupliquez à l’aide de last_update_time_utc |
Flexibilité |
Définitions de métriques fixes |
Personnalisation complète |
Fréquence de mise à jour |
Toutes les 8 heures environ |
Toutes les 4 heures environ |
Données historiques |
Jusqu’à 2 ans |
Jusqu’à 2 ans |
Méthode d’accès |
Interface utilisateur Web |
API REST |
Utilisez le tableau de bord lorsque vous avez besoin de réponses rapides ou de visualisations prédéfinies. Utilisez l’API Event Log lorsque vous devez créer des métriques personnalisées, les intégrer à votre entrepôt de données ou appliquer une logique spécifique à votre entreprise.
Concepts clés
La compréhension de ces concepts fondamentaux vous aidera à utiliser efficacement le journal des événements d’abonnement.
Concept |
Description |
Événement |
Une action d’abonnement discrète (Start, Renewal, Cancel, Auto Renewal On/Off). Chaque événement est identifié par un subscription_event_id unique. |
Dimension |
Attribut qui décrit le contexte d’un événement, tel que la date à laquelle il s’est produit, le client concerné ou le type d’offre. Les dimensions sont utilisées pour filtrer et regrouper les données. |
Métrique |
Mesure calculée dérivée d’événements tels que le nombre d’abonnés actifs, le taux de désabonnement ou le taux de conversion. Les métriques ne sont pas stockées directement : vous les calculez à partir des données des événements. |
Modèle d’historique des modifications |
Les données sont en mode ajout uniquement. Si les attributs d’un événement changent, un nouvel enregistrement est publié avec le même subscription_event_id mais un last_update_time_utc plus récent. |
Consolidation |
Logique métier qui filtre le bruit généré par les événements bruts. Par exemple, en excluant les paires Start/Cancel ayant eu lieu le même jour, qui ne représentent pas des abonnements significatifs. |
Cycle de vie |
Un « cycle » d’abonnement représentant une période d’abonnement continue. Un nouveau cycle de vie commence après chaque événement Cancel consolidé. |
Remarque : Commencez par les événements et les dimensions pour extraire les données, appliquez la logique de consolidation et de cycle de vie pour les nettoyer, puis calculez les métriques correspondant à vos définitions commerciales.
Dimensions
Les dimensions sont des attributs qui décrivent le contexte de chaque événement d’abonnement. Elles sont utilisées pour filtrer les données, regrouper les résultats et créer des rapports.
Dimension de l’événement
Subscription_event_type est le type d’événement d’abonnement qui s’est produit. Il s’agit de la principale dimension permettant de comprendre les actions du cycle de vie des clients.
Valeur |
Description |
Cas d’utilisation |
Start |
Le client s’est abonné à votre chaîne pour la première fois. Au moment de la vente, aucun enregistrement Start antérieur n’existe pour ce client. |
Compter les acquisitions de nouveaux abonnés |
Renewal |
L’abonnement du client s’est poursuivi depuis n’importe quelle période précédente. Les événements de renouvellement se produisent même lorsqu’il existe des intervalles entre les périodes d’abonnement, à condition que le client dispose d’un historique d’abonnement. |
Compter les abonnés retenus |
Cancel |
L’abonnement du client a pris fin. Cela peut être dû à l’initiative du client ou à un échec de paiement. |
Calculer le taux de désabonnement |
Active - AR ON |
Le renouvellement automatique a été activé par le client. L’abonnement sera renouvelé à la fin de la période. |
Suivre le taux de renouvellement automatique |
Active - AR OFF |
Le client a désactivé le renouvellement automatique. L’abonnement expirera à la fin de la période à moins d’être réactivé. |
Identifier les abonnés à risque |
Suspended |
L’abonnement du client est temporairement suspendu en raison de problèmes de paiement (fonds insuffisants ou informations de facturation non valides). L’abonnement reprendra automatiquement et générera un événement de renouvellement une fois que le client aura mis à jour ses informations de facturation et que le paiement aura été traité avec succès. |
Aide à suivre les abonnements en état d’échec temporaire pouvant être rétablis (devenant des Renewal) ou convertis en Cancel |
Remarque : Un événement Start se produit uniquement lorsque, au moment de la vente, nous n’avons aucun enregistrement Start antérieur pour ce client sur votre chaîne. Pour un comptage fiable des abonnés actifs, considérez les événements Start et Renewal comme des indicateurs d’un abonnement actif. Cette approche traite tous les cas limites de manière cohérente.
Dimensions de l’offre
Ces dimensions décrivent l’offre d’abonnement associée à chaque événement.
Dimension |
Type |
Format |
Description |
is_promo |
nombre entier |
0 ou 1 |
Indique si l’événement d’abonnement s’est produit pendant une période d’offre promotionnelle. 0 = Offre standard (aucune promotion active), 1 = Offre promotionnelle (remise ou tarification spéciale active). |
offer_type |
chaîne de caractères |
Texte |
Représente la classification de l’offre pour Amazon. Ce sera toujours « 3P_SUBS » pour les chaînes. |
offer_marketplace |
chaîne de caractères |
Code du site de vente |
Le site de vente Amazon sur lequel l’offre d’abonnement est disponible. Valeurs : US (États-Unis), UK (Royaume-Uni), DE (Allemagne), JP (Japon), ROE (Reste de l’Europe), ROW_NA (Reste du monde — Amérique du Nord), ROW_EU (Reste du monde — Europe), ROW_FE (Reste du monde — Extrême-Orient). offer_marketplace indique l’endroit où l’offre a été achetée, qui peut être différent de la localisation actuelle du client. |
offer_name |
chaîne de caractères |
Texte |
Le nom lisible par l’homme de l’offre d’abonnement tel que configuré dans la configuration de votre chaîne. |
offer_payment_amount |
valeur numérique |
Valeur numérique (par exemple, « 4,99 », « 9,99 ») |
Le prix catalogue de l’offre d’abonnement dans la devise locale. Ce champ contient uniquement les métadonnées de l’offre et ne représente pas les revenus transactionnels. Ce champ indique le prix de l’offre associée à l’événement. Il ne représente pas les revenus réels ni les sommes reçues. La même valeur apparaît pour chaque type d’événement (Start, Renewal, Cancel, AR changes), que le paiement ait été effectué ou non. Vous ne pouvez pas additionner ce champ pour calculer le chiffre d’affaires. Pour des données sur les recettes réelles, reportez-vous à vos systèmes d’information financière. |
offer_billing_type |
chaîne de caractères |
FT ou HO |
Le modèle de paiement de l’offre d’abonnement. FT = Essai gratuit (période d’essai sans frais), HO = Offre ferme (abonnement payant). |
offer_id |
chaîne de caractères |
Identifiant |
L’identifiant unique de l’offre d’abonnement. Utilisez-le pour associer des métadonnées à une offre ou pour suivre les performances par offre. |
Remarque : offer_marketplace indique où l’abonnement a été acheté et détermine le prix, la devise et la disponibilité du contenu. Un même client peut avoir des abonnements sur plusieurs sites de vente. Utilisez offer_billing_type pour faire la distinction entre les événements d’essai gratuit et les abonnements payants lors du calcul des métriques de conversion.
Dimensions du client
Ces dimensions identifient et décrivent l’abonné.
Dimension |
Type |
Format |
Description |
cid |
chaîne de caractères |
Identifiant anonymisé |
Un identifiant client anonyme et stable. Cet identifiant reste le même pour tous les événements d’un client donné sur votre chaîne, ce qui vous permet de suivre l’intégralité du cycle de vie du client. Le cid reste stable au sein de votre chaîne mère. Le même client aura le même cid pour toutes les offres et offres groupées qui relèvent de la même chaîne mère au sein d’un site de vente (par exemple, un client qui s’abonne à « Prime Ad-Supported (US) » et passe ensuite à « Prime Ad-free (US) » conservera le même cid, car les deux offres partagent la chaîne mère « Prime (US) »). Les clients seront associés à des valeurs cid différentes sur chaque chaîne partenaire, ce qui garantit la confidentialité tout en permettant une analyse par chaîne. |
benefit_id |
chaîne de caractères |
Identifiant |
L’identifiant d’avantage Prime Video associé à l’abonnement. Il associe l’abonnement à des droits d’accès à des contenus spécifiques. |
channel_label |
chaîne de caractères |
Texte |
Le nom de la chaîne à laquelle appartient l’abonnement. |
channel_tier_label |
chaîne de caractères |
Texte |
Le nom du niveau spécifique au sein de la chaîne, le cas échéant. Si votre chaîne n’utilise pas de niveaux, cette valeur peut être nulle ou correspondre à channel_label. |
Remarque : Le cid permet de suivre le cycle de vie des clients tout en préservant la confidentialité. Utilisez le cid pour analyser les schémas comportementaux individuels des clients, calculer des métriques de fidélisation et identifier les événements de réabonnement.
Dimensions temporelles
Ces dimensions fournissent un contexte temporel pour les événements d’abonnement.
Dimension |
Type |
Format |
Description |
subscription_event_time_utc |
horodatage |
ISO 8601 : AAAA-MM-JJTHH:MM:SS.sssZ |
L’horodatage auquel l’événement d’abonnement s’est produit, stocké en UTC. Tous les horodatages des événements sont stockés en UTC pour des raisons de cohérence. Utilisez subscription_event_time_zone pour convertir en heure locale pour les rapports. |
subscription_event_time_zone |
chaîne de caractères |
Identifiant de fuseau horaire (par exemple, Amérique/New_York, Europe/Londres) |
Fuseau horaire du site de vente sur lequel l’événement d’abonnement s’est produit. Le tableau de bord de Slate Analytics présente les données dans le fuseau horaire local. |
create_time_utc |
horodatage |
Format ISO 8601 |
Horodatage auquel l’enregistrement de l’événement d’abonnement a été créé pour la première fois dans l’historique des modifications, stocké en UTC. Cela représente la date à laquelle l’enregistrement a été ajouté à l’historique des modifications, et non la date à laquelle l’événement s’est produit. Utilisez subscription_event_time_utc pour l’heure réelle de l’événement. |
last_update_time_utc |
horodatage |
Format ISO 8601 |
Horodatage de la dernière mise à jour de l’enregistrement de l’événement d’abonnement dans l’historique des modifications, stocké en UTC. Utilisez toujours ce champ pour dédupliquer les enregistrements. Lorsque plusieurs enregistrements existent pour le même subscription_event_id, ne conservez que l’enregistrement contenant le dernier last_update_time_utc. |
Exemple de conversion (Athena SQL) :
-- Parse ISO 8601 string and convert to local timezone
CAST(DATE_FORMAT(
AT_TIMEZONE(
parse_datetime(subscription_event_time_utc, 'yyyy-MM-dd''T''HH:mm:ss.SSS''Z'''),
subscription_event_time_zone
),
'%Y-%m-%d %H:%i:%s.%f'
) AS TIMESTAMP) AS event_time_local
Remarque : Utilisez subscription_event_time_utc pour tous les calculs et tous les filtrages. Convertissez en fuseau horaire local à l’aide de subscription_event_time_zone uniquement à des fins de création de rapports et d’affichage.
Dimensions de la gestion des enregistrements
Ces dimensions vous aident à gérer correctement les données de l’historique des modifications.
Dimension |
Type |
Format |
Description |
subscription_event_id |
chaîne de caractères |
Format UUID |
Identifiant unique pour chaque événement d’abonnement. Il s’agit de la clé primaire pour la déduplication. Plusieurs enregistrements peuvent exister pour le même subscription_event_id si les attributs de l’événement ont été mis à jour. Effectuez toujours la déduplication en conservant l’enregistrement présentant la dernière heure de mise à jour (last_update_time_utc). |
is_deleted |
nombre entier |
0 ou 1 |
Indique si un enregistrement publié précédemment doit être supprimé de votre ensemble de données. 0 = Enregistrement actif (inclure dans l’analyse), 1 = Enregistrement supprimé (exclure de l’analyse - supprimer de vos tableaux s’il a déjà été ingéré). Les enregistrements supprimés sont rares mais peuvent survenir lorsque des corrections de données sont nécessaires. Filtrez toujours is_deleted = 0 dans vos requêtes. |
Remarque : Dédupliquez toujours à l’aide de last_update_time_utc avant d’effectuer une analyse. Filtrez les enregistrements supprimés (is_deleted = 1) au début de votre pipeline ETL pour garantir l’exactitude des données.
Nettoyage des données et logique de consolidation
Cette section explique le processus de déduplication en deux étapes utilisé pour transformer les données d’événements brutes en métriques claires et pertinentes pour l’entreprise. Certains partenaires utilisent une logique de consolidation différente, c’est pourquoi nous fournissons des données brutes sur les événements pour plus de flexibilité. Cette section décrit la logique que nous utilisons chez Prime Video afin que les partenaires puissent réconcilier les statistiques avec le tableau de bord Slate Analytics et voir comment nous modélisons les données.
Pourquoi la consolidation est-elle importante ?
Les données brutes relatives aux événements d’abonnement contiennent du bruit susceptible de gonfler ou de fausser vos métriques :
Problème |
Exemple |
Impact sans consolidation |
Désabonnement le jour même |
Le client crée des événements Start et Cancel en l’espace de quelques heures |
Compté deux fois, à la fois comme un Start et comme un Cancel |
Plusieurs tentatives de paiement |
Événements Cancel multiples dus à des échecs de facturation |
Taux de désabonnement gonflé |
Cancel sans Start |
Événement Cancel sans Start correspondant dans le cycle de vie |
Taux de désabonnement gonflé sans acquisition correspondante |
La logique de consolidation garantit que vos métriques reflètent une activité d’abonnement réelle et non le bruit généré par le système.
Étape 1 : Consolidation de fin de journée
Traitez les paires « Start + Cancel » ayant eu lieu le même jour en conservant uniquement l’état de fin de journée (EOD). Si un client enregistre un événement Start/Renewal et un événement Cancel le même jour, conservez uniquement le dernier événement chronologique pour ce jour. Les annulations le jour même indiquent souvent des échecs d’autorisation de paiement ou des problèmes de flux d’inscription. Ces données ne reflètent pas un engagement significatif des abonnés et leur comptabilisation gonfle à la fois le nombre de Start et de Cancel
Mise en œuvre
-- Step 1: Identify same-day start + cancel pairs
same_day_start_and_cancel AS (
SELECT cid, offer_marketplace, event_date_local
FROM deduped_events
GROUP BY cid, offer_marketplace, event_date_local
HAVING SUM(CASE WHEN subscription_event_type IN ('Start', 'Renewal') THEN 1 ELSE 0 END) > 0
AND SUM(CASE WHEN subscription_event_type = 'Cancel' THEN 1 ELSE 0 END) > 0
),
-- Step 2: Rank events by time within each day
events_with_eod_rank AS (
SELECT e.*,
ROW_NUMBER() OVER (
PARTITION BY e.cid, e.offer_marketplace, e.event_date_local
ORDER BY e.event_time_local DESC
) AS eod_rank
FROM deduped_events e
),
-- Step 3: For same-day pairs, keep only EOD event (rank = 1)
settled_events AS (
SELECT e.*
FROM events_with_eod_rank e
LEFT JOIN same_day_start_and_cancel s
ON e.cid = s.cid
AND e.offer_marketplace = s.offer_marketplace
AND e.event_date_local = s.event_date_local
WHERE s.cid IS NULL -- Not a same-day pair, keep all events
OR e.eod_rank = 1 -- Same-day pair, keep only last event
)
Exemple
Ce tableau illustre comment la logique de consolidation EOD traite les paires d’événements Start et Cancel survenus le même jour, le 15 octobre 2025, en ne conservant que l’état final à la fin de la journée.
Date et heure |
Événement |
Sans consolidation EOD |
Avec consolidation EOD |
2025/08/01 00:00 |
Start |
Compté comme Start |
Compté comme Start |
2025/09/01 00:00 |
Renewal |
- |
- |
2025/10/01 00:00 |
Renewal |
- |
- |
2025/10/15 07:00 |
Cancel |
Compté comme Cancel |
Exclus |
2025/10/15 09:00 |
Start |
Compté comme Start |
Exclus |
2025/10/15 09:15 |
Cancel |
Compté comme Cancel |
Compté comme Cancel |
Remarque : Le client est uniquement comptabilisé comme un Cancel (ou pas du tout, selon le contexte du cycle de vie) et non comme un Start et un Cancel. Le consolidation EOD s’applique uniquement aux métriques consolidées (Start, Cancel). Les métriques instantanées utilisent des périodes d’abonnement établies à partir d’événements dédupliqués dans l’historique des modifications, sans consolidation EOD, afin de conserver la chronologie complète des événements nécessaire aux calculs et conversions ponctuels.
Étape 2 : Déduplication du cycle de vie
Regroupez les événements en « cycles » d’abonnement et ne conservez que le premier Start et le premier Cancel par cycle de vie. Un Cancel valide nécessite un Start correspondant au cours du même cycle de vie.
Mise en œuvre-- Step 1: Identify lifecycle boundaries
-- A new lifecycle starts when there's no previous event OR previous event was Cancel
events_with_lifecycle_boundaries AS (
SELECT e.*,
LAG(subscription_event_type) OVER (
PARTITION BY cid, offer_marketplace
ORDER BY event_time_local
) AS prev_event_type
FROM settled_events e
),
-- Step 2: Flag lifecycle starts
events_with_lifecycle_start_flag AS (
SELECT e.*,
CASE
WHEN prev_event_type IS NULL THEN 1 -- First event ever
WHEN prev_event_type = 'Cancel' THEN 1 -- After a cancel
ELSE 0
END AS is_lifecycle_start
FROM events_with_lifecycle_boundaries e
),
-- Step 3: Assign lifecycle numbers using cumulative sum
events_with_lifecycle_id AS (
SELECT e.*,
SUM(is_lifecycle_start) OVER (
PARTITION BY cid, offer_marketplace
ORDER BY event_time_local
ROWS UNBOUNDED PRECEDING
) AS lifecycle_num
FROM events_with_lifecycle_start_flag e
),
-- Step 4: Keep only first Start and first Cancel per lifecycle
events_with_dedup_rank AS (
SELECT e.*,
ROW_NUMBER() OVER (
PARTITION BY cid, offer_marketplace, lifecycle_num,
CASE WHEN subscription_event_type IN ('Start', 'Renewal') THEN 'Start' END
ORDER BY event_time_local
) AS start_rank,
ROW_NUMBER() OVER (
PARTITION BY cid, offer_marketplace, lifecycle_num,
CASE WHEN subscription_event_type = 'Cancel' THEN 'Cancel' END
ORDER BY event_time_local
) AS cancel_rank
FROM events_with_lifecycle_id e
),
deduped_lifecycle_events AS (
SELECT *
FROM events_with_dedup_rank
WHERE (subscription_event_type IN ('Start', 'Renewal') AND start_rank = 1)
OR (subscription_event_type = 'Cancel' AND cancel_rank = 1 AND lifecycle_has_start = 1)
)
La condition lifecycle_has_start = 1 garantit que les Cancel ne sont comptabilisés que lorsque le cycle de vie comporte un événement Start correspondant.
Exemple
Client |
Événement |
Date et heure |
Cycle de vie |
Conservé ? |
ABC |
Start |
1/1/2025 |
1 |
✓ Premier Start du cycle de vie 1 |
ABC |
Renewal |
2/1/2025 |
1 |
✗ Pas le premier Start du cycle de vie 1 |
ABC |
Cancel |
3/1/2025 |
1 |
✓ Premier Cancel du cycle de vie 1 |
ABC |
Start |
4/15/2025 |
2 |
✓ Premier Start du cycle de vie 2 |
ABC |
Cancel |
5/15/2025 |
2 |
✓ Premier Cancel du cycle de vie 2 |
Important : À l’instar de la consolidation EOD, la déduplication du cycle de vie s’applique uniquement aux métriques consolidées. Les métriques instantanées utilisent les durées d’abonnement brutes, où chaque Start/Renewal crée une durée qui se termine à l’événement suivant, préservant ainsi la chronologie complète nécessaire aux calculs ponctuels.
Métriques
Les métriques sont des mesures calculées dérivées des événements d’abonnement. Contrairement aux dimensions, les métriques ne sont pas stockées directement dans le journal des événements, mais vous les calculez en agrégeant et en transformant les données des événements. Notez que les formules de calcul fournies sont des recommandations ; vous pouvez les ajuster en fonction de vos définitions commerciales.
Métriques de base
Les métriques suivantes sont essentielles à l’analyse des abonnements :
Métrique |
Description |
End of Period Subscribers |
Clients ayant un abonnement actif à la fin de la période |
Active Subscribers |
Clients disposant d’un abonnement actif à tout moment au cours de la période |
Subscriber Acquisition (Starts) |
Nouveaux abonnés gagnés |
Cancellations |
Abonnés ayant annulé |
Free Trial Conversion Rate |
Conversion d’un essai gratuit en abonnement payant |
Net Paid Starts |
Nouveaux abonnés payants représentant des conversions |
Métriques relatives aux abonnés
Ces métriques permettent de suivre les nouvelles acquisitions d’abonnés et les résiliations après application de la consolidation et de la déduplication du cycle de vie.
Métrique |
Définition |
Calcul |
num_starts |
Nombre d’événements Start et Renewal marquant le début d’un nouveau cycle de vie d’abonnement au cours de la période de référence. |
Après application de la logique de consolidation et de la déduplication du cycle de vie, comptabilisez les événements pour lesquels subscription_event_type IN (‘Start’, ‘Renewal’) et dont la date d’événement se situe dans la période considérée. SUM(CASE WHEN subscription_event_type IN (‘Start', ‘Renewal') AND event_time_local >= period_start AND event_time_local < period_end THEN 1 ELSE 0 END) AS num_starts |
num_starts_ft |
Nombre de Start pour lesquels le type de facturation de l’offre est Essai gratuit (FT). |
SUM(CASE WHEN subscription_event_type IN (‘Start', ‘Renewal') AND offer_billing_type = ‘FT’ AND event_time_local >= period_start AND event_time_local < period_end THEN 1 ELSE 0 END) AS num_starts_ft |
num_starts_ho |
Nombre de Start pour lesquels le type de facturation de l’offre est Offre ferme (HO) — abonnements payants. |
SUM(CASE WHEN subscription_event_type IN (‘Start', ‘Renewal') AND offer_billing_type = ‘HO’ AND event_time_local >= period_start AND event_time_local < period_end THEN 1 ELSE 0 END) AS num_starts_ho |
num_net_starts_ho |
Nouveaux abonnés payants nets, calculés comme suit : Starts HO directs + conversions d’essais gratuits. Fournit une image complète des nouveaux abonnés payants, qu’ils aient souscrit directement à un forfait payant ou qu’ils aient effectué une conversion après un essai gratuit. |
num_net_starts_ho = num_starts_ho + num_ft_conversions |
num_cancels |
Nombre d’événements Cancel survenus au cours de la période de référence après application de la consolidation et de la déduplication du cycle de vie. |
SUM(CASE WHEN subscription_event_type = ‘Cancel’ AND event_time_local >= period_start AND event_time_local < period_end THEN 1 ELSE 0 END) AS num_cancels |
num_cancels_ho |
Annulations lorsque l’abonné bénéficiait d’une offre ferme (payante). |
- |
num_cancels_ft |
Annulations lorsque l’abonné était inscrit à un plan d’essai gratuit (la période d’essai s’est terminée sans conversion). |
- |
Métriques de la période
Ces métriques fournissent des instantanés ponctuels et des activités périodiques à l’aide de périodes d’abonnement établies sans consolidation EOD.
Métrique |
Définition |
Calcul |
Variantes |
num_end_period_subs |
Nombre d’abonnés uniques actifs à la fin de la période de référence. Il s’agit d’un instantané ponctuel. |
Depuis subscription_spans (établi sans consolidation EOD) COUNT(DISTINCT CASE WHEN span_start_date < period_end AND (span_end_date IS NULL OR span_end_date >= period_end) THEN cid END) AS num_end_period_subs |
num_end_period_subs_ho — Abonnés à la fin de la période sur les offres fermes (HO), num_end_period_subs_ft — Abonnés en fin de période sur les offres d’essai gratuit (FT) |
num_active_period_subs |
Nombre d’abonnés uniques qui étaient actifs à tout moment au cours de la période de référence. Capture tous les clients dont la période d’abonnement en cours chevauche cette période, quelle que soit la date à laquelle ils ont commencé ou ont annulé leur abonnement. |
Depuis subscription_spans (établi sans consolidation EOD) COUNT(DISTINCT CASE WHEN span_start_date < period_end AND (span_end_date IS NULL OR span_end_date >= period_start) THEN cid END) AS num_active_period_subs |
num_active_period_subs_ho — Abonnés actifs à tout moment au cours de la période sur des offres fermes (payantes) - num_active_period_subs_ft — Abonnés actifs à tout moment au cours de la période sur des offres d’essai gratuit |
Remarque : Les métriques de la période utilisent subscription_spans sans consolidation EOD pour préserver la chronologie complète des événements.
Métriques des essais gratuits
Ces métriques permettent de suivre les conversions et les consolidations des essais gratuits à l’aide de périodes d’abonnement établies sans consolidation EOD.
Métrique |
Définition |
Calcul |
num_ft_conversions |
Nombre d’abonnés à l’essai gratuit qui ont souscrit à un forfait payant (offre ferme) au cours de la période de référence. Une conversion se produit lorsqu’un abonné bénéficiant d’un essai gratuit (offer_billing_type = ‘FT’) a pour événement suivant un Start/Renewal avec offer_billing_type = ‘HO’. |
Depuis subscription_spans (établi sans consolidation EOD) COUNT(CASE WHEN offer_billing_type = ‘FT’ AND span_end_billing_type = ‘HO’ AND span_end_event_type IN (‘Start', ‘Renewal') AND span_end_date >= period_start AND span_end_date < period_end THEN 1 END) AS num_ft_conversions |
num_ft_settled |
Nombre d’abonnements à l’essai gratuit ayant pris fin (arrivés à expiration) au cours de la période de référence. Un essai prend fin lorsque l’abonné passe à un abonnement payant ou résilie son abonnement (le type de facturation suivant n’est pas FT). |
COUNT(CASE WHEN offer_billing_type = ‘FT’ AND span_end_date IS NOT NULL AND span_end_date >= period_start AND span_end_date < period_end THEN 1 END) AS num_ft_settled |
ft_conversion_rate_pct |
Pourcentage d’essais gratuits réglés convertis en abonnements payants. |
CASE WHEN num_ft_settled > 0 THEN ROUND(100.0 * num_ft_conversions / num_ft_settled, 2) ELSE 0 END AS ft_conversion_rate_pct |
Remarque : Les métriques des essais gratuits utilisent subscription_spans sans consolidation EOD pour suivre avec précision les conversions lorsque les clients passent d’un offer_id à un autre.
Comprendre les schémas récurrents liés aux événements
Cette section explique les schémas d’événements courants que vous rencontrerez dans le journal des événements d’abonnement et explique comment les interpréter correctement.
Cycle de vie des abonnements
Un abonnement classique suit ce cycle de vie et passe par quatre étapes clés, de l’inscription initiale aux cycles de renouvellement et à l’annulation éventuelle. Chaque étape génère des types d’événements spécifiques qui vous permettent de suivre le comportement des clients et de calculer les métriques d’abonnement.
Points clés du cycle de vie
Ces étapes clés du cycle de vie représentent les quatre étapes critiques du parcours d’abonnement d’un client, chacune générant des types d’événements distincts qui permettent le suivi des schémas d’acquisition, de fidélisation, d’engagement et de désabonnement.
Étape |
Type d’événement |
Description |
Acquisition |
Start |
Un nouveau client rejoint votre chaîne |
Fidélisation |
Renewal |
Le client existant poursuit son abonnement |
Engagement |
Active - AR ON/OFF |
Le client ajuste ses préférences de renouvellement automatique |
Désabonnement |
Cancel |
L’abonnement du client prend fin |
Schémas d’événements courants
Schéma 1 : Renewal sans Start
L’historique des événements d’un client affiche des événements Renewal, mais aucun événement Start. L’événement Start initial du client s’est produit il y a plus de 2 ans. En raison de la politique de conservation des données, les événements datant de plus de 2 ans ne sont pas disponibles. Les événements Renewal de la fenêtre temporelle restent accessibles.
Schéma 2 : Événements Cancel multiples
Un client enregistre plusieurs événements Cancel en quelques minutes ou quelques heures. Ce schéma indique généralement des échecs de paiement répétés : Le système de facturation tente de débiter le mode de paiement du client. Chaque tentative échouée peut générer un événement Cancel. Le client tente peut-être de se réabonner avec une carte refusée. La déduplication du cycle de vie ne conservera que le premier événement Cancel par cycle de vie.
Schéma 3 : Start et Cancel le même jour
Un client affiche un Start et un Cancel le même jour calendaire. Les causes courantes incluent :
- Le client s’est inscrit et a immédiatement annulé
- L’autorisation de paiement a échoué après l’inscription initiale
- Tentative d’inscription frauduleuse bloquée
La consolidation EOD gère ce schéma automatiquement. Seul l’état final est conservé.
Schéma 4 : Conversion d’un essai gratuit en abonnement payant
Un client présente un Start avec offer_billing_type = ‘FT’, suivi d’un autre Start ou Renewal avec offer_billing_type = ‘HO’. Le client a terminé son essai gratuit et est passé à un abonnement payant. Utilisez les fonctions de la fenêtre LEAD () pour détecter quand offer_billing_type passe de FT à HO. Comptez cela comme une conversion lorsque l’événement de transition survient pendant la période de référence.
Événements Auto Renew
Les événements Auto Renew (AR) permettent de suivre les moments où les clients activent ou désactivent le renouvellement automatique de leur abonnement. Ces événements fournissent des signaux précoces permettant de prévoir le taux de désabonnement futur et d’identifier les abonnés à risque.
Type d’événement |
Description |
Cas d’utilisation |
AR_ON |
Le client a activé le renouvellement automatique. Son abonnement sera automatiquement renouvelé à la fin de la période en cours. |
Suivez les clients qui se sont engagés à poursuivre leur abonnement. |
AR_OFF |
Le client a désactivé le renouvellement automatique. Son abonnement expirera à la fin de la période en cours, à moins qu’il ne réactive le renouvellement automatique. |
Signal d’alerte précoce : Les clients qui désactivent le renouvellement automatique signalent leur intention de partir avant la fin effective de leur abonnement. Prévision du taux de désabonnement : Les abonnés AR OFF abandonneront définitivement leur abonnement à la fin de la période, à moins qu’ils ne réactivent le renouvellement automatique. Cela fait des événements AR OFF l’un des indicateurs les plus fiables du taux de désabonnement futur. |
Remarque : Les événements Auto Renew sont enregistrés chaque fois qu’un client modifie activement ses préférences de renouvellement automatique via l’interface de gestion des abonnements.
Analyse des événements AR
Pour analyser le comportement de renouvellement automatique, consultez les événements AR ON/OFF séparément du pipeline principal des métriques du cycle de vie. Les événements AR suivent les mêmes règles de déduplication de l’historique des modifications, mais ne sont pas inclus dans les calculs du cycle de vie Start/Renewal/Cancel.
-- Example:Filter to AR Off Events
SELECT *
FROM deduped_events
WHERE subscription_event_type = 'AR_OFF'
GROUP BY 1, 2
ORDER BY 1, 2
Pipeline ETL
En vous appuyant sur les définitions des métriques et les transformations de données ci-dessus, utilisez ce pipeline ETL (Extract, Transform, Load) pour transformer les données brutes du journal des événements d’abonnement en métriques propres et pertinentes pour votre activité. Cette requête peut être lancée directement dans Amazon Athena.
Le pipeline met en œuvre une architecture à deux voies pour calculer correctement les différents types de métriques :
- Voie A : Événements consolidés — Applique la consolidation EOD ET la déduplication du cycle de vie. Utilisé pour les métriques consolidées (Start, Cancel). Cela permet de filtrer les informations parasites telles que les paires Start + Cancel le même jour, qui ne représentent pas de véritables acquisitions.
- Voie B : Durée de l’abonnement — Applique la déduplication du journal des modifications UNIQUEMENT. Utilisé pour les métriques instantanées (décomptes de fin de période, conversions FT).
-- ============================================================================
-- SUBSCRIPTION METRICS ETL PIPELINE
-- ============================================================================
-- Transforms raw subscription events into clean metrics using TWO PATHS:
-- PATH A: Settled Events - for settled metrics (starts, cancels)
-- Applies: Changelog dedup → EOD settlement → Lifecycle dedup
-- Filters out noise like same-day start+cancel pairs
-- PATH B: Subscription Spans - for snapshot metrics (end-of-period, conversions)
-- Applies: Changelog dedup ONLY (preserves full timeline)
-- Required for conversions because customer switches offer_id (A → B)
-- ============================================================================
WITH
-- =============================================================================
-- STEP 1: Parse timestamps and convert to local timezone
-- =============================================================================
parsed_events AS (
SELECT
subscription_event_id,
subscription_event_type,
subscription_event_time_utc,
subscription_event_time_zone,
cid,
offer_id,
offer_name,
offer_marketplace,
offer_billing_type,
offer_payment_amount,
is_promo,
channel_label,
channel_tier_label,
benefit_id,
is_deleted,
last_update_time_utc,
-- Parse and convert timestamps
parse_datetime(subscription_event_time_utc, 'yyyy-MM-dd''T''HH:mm:ss.SSS''Z''') AS event_time_utc,
CAST(DATE_FORMAT(
AT_TIMEZONE(
parse_datetime(subscription_event_time_utc, 'yyyy-MM-dd''T''HH:mm:ss.SSS''Z'''),
subscription_event_time_zone
),
'%Y-%m-%d %H:%i:%s.%f'
) AS TIMESTAMP) AS event_time_local,
CAST(DATE_FORMAT(
AT_TIMEZONE(
parse_datetime(subscription_event_time_utc, 'yyyy-MM-dd''T''HH:mm:ss.SSS''Z'''),
subscription_event_time_zone
),
'%Y-%m-%d'
) AS DATE) AS event_date_local
FROM your_subscription_events_table
WHERE is_deleted = 0
AND subscription_event_type IN ('Start', 'Renewal', 'Cancel')
),
-- =============================================================================
-- STEP 2: Deduplicate changelog records (used by BOTH paths)
-- =============================================================================
deduped_events AS (
SELECT * FROM (
SELECT
*,
ROW_NUMBER() OVER (
PARTITION BY subscription_event_id
ORDER BY last_update_time_utc DESC
) AS dedup_rank
FROM parsed_events
)
WHERE dedup_rank = 1
),
-- =============================================================================
-- PATH A: SETTLED EVENTS (for starts, cancels)
-- Applies: Changelog dedup → EOD settlement → Lifecycle dedup
-- =============================================================================
-- STEP A1: EOD Settlement - Identify same-day Start+Cancel pairs
same_day_start_and_cancel AS (
SELECT cid, offer_marketplace, event_date_local
FROM deduped_events
GROUP BY cid, offer_marketplace, event_date_local
HAVING
SUM(CASE WHEN subscription_event_type IN ('Start', 'Renewal') THEN 1 ELSE 0 END) > 0
AND SUM(CASE WHEN subscription_event_type = 'Cancel' THEN 1 ELSE 0 END) > 0
),
-- Rank events by time within each day
events_with_eod_rank AS (
SELECT
e.*,
ROW_NUMBER() OVER (
PARTITION BY e.cid, e.offer_marketplace, e.event_date_local
ORDER BY e.event_time_local DESC
) AS eod_rank
FROM deduped_events e
),
-- Apply EOD settlement: for same-day pairs, keep only the last event
eod_settled_events AS (
SELECT e.*
FROM events_with_eod_rank e
LEFT JOIN same_day_start_and_cancel sd
ON e.cid = sd.cid
AND e.offer_marketplace = sd.offer_marketplace
AND e.event_date_local = sd.event_date_local
WHERE sd.cid IS NULL OR e.eod_rank = 1
),
-- STEP A2: Build customer lifecycles (on EOD settled data)
settled_events_with_prev AS (
SELECT
*,
LAG(subscription_event_type) OVER (
PARTITION BY cid, offer_marketplace
ORDER BY event_time_local
) AS prev_event_type
FROM eod_settled_events
),
settled_events_with_lifecycle_flag AS (
SELECT
*,
CASE
WHEN prev_event_type IS NULL THEN 1
WHEN prev_event_type = 'Cancel' THEN 1
ELSE 0
END AS is_lifecycle_start
FROM settled_events_with_prev
),
settled_events_with_lifecycle AS (
SELECT
*,
SUM(is_lifecycle_start) OVER (
PARTITION BY cid, offer_marketplace
ORDER BY event_time_local
ROWS UNBOUNDED PRECEDING
) AS lifecycle_num,
cid || '|' || offer_marketplace || '|' || CAST(
SUM(is_lifecycle_start) OVER (
PARTITION BY cid, offer_marketplace
ORDER BY event_time_local
ROWS UNBOUNDED PRECEDING
) AS VARCHAR
) AS lifecycle_id
FROM settled_events_with_lifecycle_flag
),
-- STEP A3: Lifecycle deduplication
events_with_type_rank AS (
SELECT
*,
CASE WHEN subscription_event_type IN ('Start', 'Renewal') THEN
ROW_NUMBER() OVER (
PARTITION BY lifecycle_id,
CASE WHEN subscription_event_type IN ('Start', 'Renewal') THEN 'START' END
ORDER BY event_time_local
)
END AS start_rank,
CASE WHEN subscription_event_type = 'Cancel' THEN
ROW_NUMBER() OVER (
PARTITION BY lifecycle_id,
CASE WHEN subscription_event_type = 'Cancel' THEN 'CANCEL' END
ORDER BY event_time_local
)
END AS cancel_rank,
MAX(CASE WHEN subscription_event_type IN ('Start', 'Renewal') THEN 1 ELSE 0 END) OVER (
PARTITION BY lifecycle_id
) AS lifecycle_has_start
FROM settled_events_with_lifecycle
),
settled_events AS (
SELECT *
FROM events_with_type_rank
WHERE
(subscription_event_type IN ('Start', 'Renewal') AND start_rank = 1)
OR (subscription_event_type = 'Cancel' AND cancel_rank = 1 AND lifecycle_has_start = 1)
),
-- =============================================================================
-- PATH B: SUBSCRIPTION SPANS (for conversions, end-of-period)
-- Applies: Changelog dedup ONLY (NO EOD settlement, NO lifecycle dedup)
-- This preserves the full timeline needed for accurate span calculations
-- =============================================================================
-- STEP B1: Calculate LEAD() on ALL deduped events (before any filtering)
events_with_span_boundaries AS (
SELECT
cid,
offer_marketplace,
offer_id,
offer_billing_type,
subscription_event_type,
event_time_local,
event_date_local,
LEAD(event_time_local) OVER (
PARTITION BY cid, offer_marketplace
ORDER BY event_time_local
) AS next_event_time,
LEAD(subscription_event_type) OVER (
PARTITION BY cid, offer_marketplace
ORDER BY event_time_local
) AS next_event_type,
LEAD(offer_billing_type) OVER (
PARTITION BY cid, offer_marketplace
ORDER BY event_time_local
) AS next_billing_type
FROM deduped_events -- Uses deduped_events directly, NOT eod_settled_events
),
-- STEP B2: Create spans from Start/Renewal events
subscription_spans AS (
SELECT
cid,
offer_marketplace,
offer_id,
offer_billing_type,
subscription_event_type,
event_time_local AS span_start,
event_date_local AS span_start_date,
next_event_time AS span_end,
CAST(next_event_time AS DATE) AS span_end_date,
next_event_type AS span_end_event_type,
next_billing_type AS span_end_billing_type
FROM events_with_span_boundaries
WHERE subscription_event_type IN ('Start', 'Renewal')
),
-- =============================================================================
-- STEP 3: Generate reporting periods
-- =============================================================================
reporting_periods AS (
SELECT
period_month,
CAST(period_month AS DATE) AS period_start,
CAST(DATE_ADD('month', 1, period_month) AS DATE) AS period_end
FROM UNNEST(SEQUENCE(DATE '2025-01-01', DATE '2025-12-01', INTERVAL '1' MONTH)) AS t(period_month)
),
-- =============================================================================
-- STEP 4A: SETTLED METRICS (from settled events - with EOD + lifecycle dedup)
-- Use for: starts, cancels
-- =============================================================================
settled_metrics AS (
SELECT
DATE_FORMAT(p.period_start, '%Y-%m') AS report_month,
e.offer_marketplace,
-- Starts (all)
SUM(CASE WHEN e.subscription_event_type IN ('Start', 'Renewal')
AND e.event_date_local >= p.period_start
AND e.event_date_local < p.period_end
THEN 1 ELSE 0 END) AS num_starts,
-- Starts (Free Trial)
SUM(CASE WHEN e.subscription_event_type IN ('Start', 'Renewal')
AND e.offer_billing_type = 'FT'
AND e.event_date_local >= p.period_start
AND e.event_date_local < p.period_end
THEN 1 ELSE 0 END) AS num_starts_ft,
-- Starts (Hard Offer / Paid)
SUM(CASE WHEN e.subscription_event_type IN ('Start', 'Renewal')
AND e.offer_billing_type = 'HO'
AND e.event_date_local >= p.period_start
AND e.event_date_local < p.period_end
THEN 1 ELSE 0 END) AS num_starts_ho,
-- Cancels (all)
SUM(CASE WHEN e.subscription_event_type = 'Cancel'
AND e.event_date_local >= p.period_start
AND e.event_date_local < p.period_end
THEN 1 ELSE 0 END) AS num_cancels,
-- Cancels (Hard Offer)
SUM(CASE WHEN e.subscription_event_type = 'Cancel'
AND e.offer_billing_type = 'HO'
AND e.event_date_local >= p.period_start
AND e.event_date_local < p.period_end
THEN 1 ELSE 0 END) AS num_cancels_ho,
-- Cancels (Free Trial)
SUM(CASE WHEN e.subscription_event_type = 'Cancel'
AND e.offer_billing_type = 'FT'
AND e.event_date_local >= p.period_start
AND e.event_date_local < p.period_end
THEN 1 ELSE 0 END) AS num_cancels_ft
FROM settled_events e
CROSS JOIN reporting_periods p
GROUP BY DATE_FORMAT(p.period_start, '%Y-%m'), e.offer_marketplace
),
-- =============================================================================
-- STEP 4B: SNAPSHOT METRICS (from subscription spans - NO EOD settlement)
-- Use for: end-of-period counts, conversions, settled trials
-- =============================================================================
snapshot_metrics AS (
SELECT
DATE_FORMAT(p.period_start, '%Y-%m') AS report_month,
s.offer_marketplace,
-- End of period counts (who was active at period end?)
COUNT(DISTINCT CASE
WHEN s.span_start_date < p.period_end
AND (s.span_end_date IS NULL OR s.span_end_date >= p.period_end)
THEN s.cid
END) AS num_end_period_subs,
COUNT(DISTINCT CASE
WHEN s.offer_billing_type = 'HO'
AND s.span_start_date < p.period_end
AND (s.span_end_date IS NULL OR s.span_end_date >= p.period_end)
THEN s.cid
END) AS num_end_period_subs_ho,
COUNT(DISTINCT CASE
WHEN s.offer_billing_type = 'FT'
AND s.span_start_date < p.period_end
AND (s.span_end_date IS NULL OR s.span_end_date >= p.period_end)
THEN s.cid
END) AS num_end_period_subs_ft,
-- Active at any point during the period
COUNT(DISTINCT CASE
WHEN s.span_start_date < p.period_end
AND (s.span_end_date IS NULL OR s.span_end_date >= p.period_start)
THEN s.cid
END) AS num_active_period_subs,
COUNT(DISTINCT CASE
WHEN s.offer_billing_type = 'HO'
AND s.span_start_date < p.period_end
AND (s.span_end_date IS NULL OR s.span_end_date >= p.period_start)
THEN s.cid
END) AS num_active_period_subs_ho,
COUNT(DISTINCT CASE
WHEN s.offer_billing_type = 'FT'
AND s.span_start_date < p.period_end
AND (s.span_end_date IS NULL OR s.span_end_date >= p.period_start)
THEN s.cid
END) AS num_active_period_subs_ft,
-- Conversions (FT span ending with HO start in this period)
COUNT(CASE
WHEN s.offer_billing_type = 'FT'
AND s.span_end_billing_type = 'HO'
AND s.span_end_event_type IN ('Start', 'Renewal')
AND s.span_end_date >= p.period_start
AND s.span_end_date < p.period_end
THEN 1
END) AS num_ft_conversions,
-- FT Settled (FT span that ended in this period)
COUNT(CASE
WHEN s.offer_billing_type = 'FT'
AND s.span_end_date IS NOT NULL
AND s.span_end_date >= p.period_start
AND s.span_end_date < p.period_end
THEN 1
END) AS num_ft_settled
FROM subscription_spans s
CROSS JOIN reporting_periods p
GROUP BY DATE_FORMAT(p.period_start, '%Y-%m'), s.offer_marketplace
)
-- =============================================================================
-- FINAL OUTPUT: Combine flow and snapshot metrics
-- =============================================================================
SELECT
sm.report_month,
sm.offer_marketplace,
-- Starts (from settled events)
sm.num_starts,
sm.num_starts_ft,
sm.num_starts_ho,
-- Net Starts (paid starts + conversions)
sm.num_starts_ho + sn.num_ft_conversions AS num_net_starts_ho,
-- Cancels (from settled events)
sm.num_cancels,
sm.num_cancels_ho,
sm.num_cancels_ft,
-- Free Trial Metrics (from spans)
sn.num_ft_conversions,
sn.num_ft_settled,
CASE WHEN sn.num_ft_settled > 0
THEN ROUND(100.0 * sn.num_ft_conversions / sn.num_ft_settled, 2)
ELSE 0
END AS ft_conversion_rate_pct,
-- Active Subscribers (from spans)
sn.num_active_period_subs,
sn.num_active_period_subs_ho,
sn.num_active_period_subs_ft,
-- End of Period Subscribers (from spans)
sn.num_end_period_subs,
sn.num_end_period_subs_ho,
sn.num_end_period_subs_ft
FROM settled_metrics sm
JOIN snapshot_metrics sn
ON sm.report_month = sn.report_month
AND sm.offer_marketplace = sn.offer_marketplace
ORDER BY sm.report_month, sm.offer_marketplace
Remarque : Remplacez your_subscription_events_table par le nom réel de votre tableau. Ajustez la plage de dates reporting_periods en fonction de vos besoins d’analyse.
