Tous les produits
Search
Centre de documentation

AnalyticDB:Funnel and retention functions

Dernière mise à jour :Oct 10, 2026

AnalyticDB for MySQL propose quatre fonctions intégrées pour l'analyse des tunnels de conversion et de la rétention : window_funnel, retention, retention_range_count et retention_range_sum. Utilisez ces fonctions pour mesurer les taux de conversion à chaque étape du parcours utilisateur et suivre le nombre d'utilisateurs qui reviennent au fil du temps.

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants :

  • Un cluster AnalyticDB for MySQL exécutant la version mineure 3.1.6.0 ou ultérieure

Remarque

Pour afficher et mettre à jour la version mineure, accédez à la section Configuration Information de la page Cluster Information dans la console AnalyticDB for MySQL.

Contexte

L'analyse de tunnel mesure la progression des utilisateurs à travers une séquence d'étapes définies, par exemple, de la consultation d'un produit à la finalisation de l'achat. À chaque étape, certains utilisateurs abandonnent ; le taux de conversion indique la proportion de ceux qui poursuivent le processus. Cette technique est largement utilisée dans l'analyse du trafic et l'analyse de la conversion vers les objectifs produits.

AnalyticDB for MySQL prend en charge les fonctions suivantes :

Fonction

Objectif

window_funnel

Compte jusqu'où un utilisateur a progressé dans une séquence d'événements définie au sein d'une fenêtre temporelle glissante

retention

Vérifie si chaque utilisateur satisfait à un ensemble de conditions basées sur la date, en renvoyant un tableau binaire

retention_range_count

Enregistre l'état de rétention par utilisateur sur des intervalles spécifiés, en renvoyant un tableau à deux dimensions

retention_range_sum

Agrège la sortie de retention_range_count pour tous les utilisateurs afin de calculer les taux de rétention quotidiens

Jeu de données de test

Les exemples de cette rubrique utilisent les Données de comportement des utilisateurs de Taobao pour la recommandation du laboratoire Tianchi. Le jeu de données contient quatre types de comportements :

Comportement

Description

pv

Affichage de la page produit (compté comme un clic)

buy

Achat

cart

Ajout au panier

fav

Ajout aux favoris

Pour charger le jeu de données dans AnalyticDB for MySQL, téléchargez-le sur Object Storage Service (OSS), puis importez-le à l'aide d'une table externe OSS.

  1. Téléchargez le jeu de données sur OSS. Pour plus d'informations, consultez Télécharger des objets.

  2. Créez une table externe OSS.

    CREATE TABLE `user_behavior_oss` (
      `user_id` string,
      `item_id` string,
      `cate_id` string,
      `event` string,
      `ts` bigint
    ) ENGINE = 'oss'
    TABLE_PROPERTIES = '{
      "endpoint":"oss-cn-zhangjiakou.aliyuncs.com",
      "accessid":"******",
      "accesskey":"*******",
      "url":"oss://<bucket-name>/user_behavior/",
      "delimiter":","
    }'

    Pour plus d'informations, consultez Syntaxe des tables externes OSS.

  3. Créez une table de test dans AnalyticDB for MySQL.

    CREATE TABLE user_behavior(
      uid string,
      event string,
      ts string
    )
  4. Importez les données depuis la table externe OSS.

    SUBMIT JOB INSERT OVERWRITE user_behavior SELECT user_id, event, ts FROM user_behavior_oss;

window_funnel

window_funnel recherche une séquence d'événements spécifiée dans l'historique des événements d'un utilisateur, au sein d'une fenêtre temporelle glissante. Elle renvoie la longueur du plus long préfixe correspondant de cette séquence.

Fonctionnement

La fonction traite les événements de chaque utilisateur par ordre chronologique :

  1. Elle parcourt les événements pour trouver la première occurrence de la condition initiale de votre séquence. Lorsqu'elle est trouvée, la fenêtre glissante démarre.

  2. Elle recherche ensuite chaque condition suivante dans l'ordre, au sein de la fenêtre. Chaque correspondance incrémente le compteur d'une unité.

  3. Si la séquence est interrompue ou si la fenêtre expire avant que toutes les conditions ne soient satisfaites, le compteur s'arrête. La fonction renvoie la valeur maximale atteinte par le compteur.

Exemples :

  • Liste d'événements [c1, c2, c3], données utilisateur [c1, c2, c3, c4] → renvoie 3 (séquence complète correspondante)

  • Liste d'événements [c1, c2, c3], données utilisateur [c4, c3, c2, c1] → renvoie 1 (seule la condition c1 correspond depuis le début)

  • Liste d'événements [c1, c2, c3], données utilisateur [c4, c3] → renvoie 0 (la première condition n'a jamais été satisfaite)

Syntaxe

window_funnel(window, mode, timestamp, cond1, cond2, ..., condN)

Paramètres

Paramètre

Type

Description

window

Integer

Taille de la fenêtre temporelle glissante, dans la même unité que la colonne timestamp

mode

String

Mode de fonctionnement. Définissez la valeur sur "default"

timestamp

BIGINT

Colonne d'horodatage. Doit être de type de données BIGINT. Si votre colonne d'horodatage n'est pas de type BIGINT, utilisez TIMESTAMPDIFF pour la convertir. Par exemple : TIMESTAMPDIFF('second', '2017-11-25 00:00:00.000', ts)

cond1, ..., condN

Boolean

Conditions d'événement qui définissent les étapes du funnel, évaluées dans l'ordre

Exemple

L'exemple suivant analyse le parcours de conversion — consultation → ajout aux favoris → ajout au panier → achat — entre le 25 novembre 2017 à 00:00:00 et le 26 novembre 2017 à 00:00:00. La fenêtre temporelle glissante est de 30 minutes (1 800 secondes) et les horodatages sont au format Unix (de 1511539200 à 1511625600).

La requête s'exécute en deux étapes : la requête interne calcule la profondeur du funnel par utilisateur, tandis que la requête externe compte le nombre d'utilisateurs ayant atteint chaque niveau de profondeur.

SELECT
  funnel,
  count(1)
FROM (
  SELECT
    uid,
    window_funnel(
      cast(1800 as integer),  -- 30-minute sliding window
      "default",
      ts,
      event = 'pv',           -- Step 1: Browse
      event = 'fav',          -- Step 2: Add to favorites
      event = 'cart',         -- Step 3: Add to cart
      event = 'buy'           -- Step 4: Purchase
    ) AS funnel
  FROM user_behavior
  WHERE ts > 1511539200
    AND ts < 1511625600
  GROUP BY uid
)
GROUP BY funnel;

Résultat exemple :

+--------+----------+
| funnel | count(1) |
+--------+----------+
|      0 |    19687 |
|      1 |   596104 |
|      2 |    78458 |
|      3 |    11640 |
|      4 |      746 |
+--------+----------+
5 rows in set (0.64 sec)

Une valeur de 4 signifie que l'utilisateur a effectué les quatre étapes. Une valeur de 1 indique que seule la première étape (consultation) a été satisfaite.

retention

retention vérifie si un utilisateur satisfait un ensemble de conditions — généralement une condition par jour — et renvoie un tableau UINT8 où chaque élément vaut 1 (condition satisfaite) ou 0 (condition non satisfaite).

Syntaxe

retention(cond1, cond2, ..., cond32)

Paramètres

Paramètre

Type

Description

cond1, ..., cond32

UINT8

Conditions à évaluer, jusqu'à 32. Renvoie 1 si la condition est satisfaite, 0 sinon

Exemple

L'exemple suivant mesure la rétention sur 7 jours à partir du 25 novembre 2017. sum(r[1]) compte les utilisateurs actifs le jour 1 ; sum(r[2]) à sum(r[7]) comptent combien d'entre eux sont revenus chaque jour suivant.

Étape 1 — calcul des tableaux de rétention par utilisateur :

SELECT
  uid,
  retention(
    ds = '2017-11-25' AND event = 'pv',  -- Day 1: active (baseline)
    ds = '2017-11-25',                   -- Day 1 retention check
    ds = '2017-11-26',                   -- Day 2
    ds = '2017-11-27',                   -- Day 3
    ds = '2017-11-28',                   -- Day 4
    ds = '2017-11-29',                   -- Day 5
    ds = '2017-11-30'                    -- Day 6
  ) AS r
FROM user_behavior_date
GROUP BY uid

Étape 2 — agrégation sur l'ensemble des utilisateurs :

SELECT
  sum(r[1]),   -- Active users on day 1
  sum(r[2]),   -- Retained on day 1
  sum(r[3]),   -- Retained on day 2
  sum(r[4]),   -- Retained on day 3
  sum(r[5]),   -- Retained on day 4
  sum(r[6]),   -- Retained on day 5
  sum(r[7])    -- Retained on day 6
FROM (
  SELECT
    retention(
      ds = '2017-11-25' AND event = 'pv',
      ds = '2017-11-25',
      ds = '2017-11-26',
      ds = '2017-11-27',
      ds = '2017-11-28',
      ds = '2017-11-29',
      ds = '2017-11-30'
    ) AS r
  FROM user_behavior_date
  GROUP BY uid
);

Résultat exemple :

+-----------+-----------+-----------+-----------+-----------+-----------+-----------+
| sum(r[1]) | sum(r[2]) | sum(r[3]) | sum(r[4]) | sum(r[5]) | sum(r[6]) | sum(r[7]) |
+-----------+-----------+-----------+-----------+-----------+-----------+-----------+
|    686953 |    686953 |    544367 |    529979 |    523516 |    524530 |    528105 |
+-----------+-----------+-----------+-----------+-----------+-----------+-----------+
1 row in set (2.96 sec)

retention_range_count et retention_range_sum

retention_range_count et retention_range_sum sont conçues pour l'analyse de la croissance des utilisateurs. Elles prennent en charge des intervalles de rétention flexibles et génèrent une sortie adaptée à la visualisation.

  • retention_range_count calcule le statut de rétention par utilisateur sur des intervalles de jours spécifiés, en renvoyant un tableau à deux dimensions.

  • retention_range_sum prend la sortie de retention_range_count et l'agrège pour tous les utilisateurs afin de produire des taux de rétention quotidiens.

Syntaxe

-- Per-user retention
retention_range_count(is_first, is_active, dt, intervals)
retention_range_count(is_first, is_active, dt, intervals, retentionGranularity, outputFormat)

-- Aggregate across users
retention_range_sum(retention_range_count_result)

Paramètres

retention_range_count :

Paramètre

Type

Description

is_first

Boolean

Indique si cette ligne correspond à l'événement d'activation. true = il s'agit du comportement initial

is_active

Boolean

Indique si cette ligne correspond à l'événement de rétention. true = cela compte comme un comportement de rétention

dt

Date

Date de l'événement, au format date (par exemple, 2022-05-01)

intervals[]

Array

Intervalles de rétention à suivre (par exemple, array(1, 2) pour la rétention à J+1 et J+2). Jusqu'à 15 intervalles sont pris en charge

retentionGranularity

String

L'unité de temps pour les statistiques de rétention. Seule la valeur DAYS (jours) est actuellement prise en charge. Les valeurs WEEKS (semaines) et MONTH (mois) ne sont pas prises en charge.

outputFormat

String

Le format de sortie. Valeurs valides : normal (par défaut) ou expand.

Valeurs de outputFormat :

Valeur

Format de sortie

normal (par défaut)

[[d1(date de début), 1, 0, ...], [d2(date de début), 1, 0, ...], ...] — chaque ligne est [date de début, indicateur_intervalle_1, indicateur_intervalle_2, ...], où 1 = retenu et 0 = non retenu

expand

[[d1(date de début), d1+1(date de rétention)], [d1, d1+2], [d2, d2+1], [d2, d2+3]]

retention_range_sum :

Paramètre

Description

retention_range_count_result

La sortie sous forme de tableau à deux dimensions de retention_range_count

Exemple

L'exemple suivant calcule la rétention à J+1 et J+2 pour les utilisateurs qui se sont connectés les 1er et 2 mai 2022, en se basant sur l'activité du 1er au 4 mai 2022. L'événement d'activation est login et l'événement de rétention est pay.

Étape 1. Créez une table de test et insérez des données.

CREATE TABLE event(uid string, event string, ds date);
INSERT INTO event VALUES
  ("user1", "pay",   "2022-05-01"),
  ("user1", "login", "2022-05-01"),
  ("user1", "pay",   "2022-05-02"),
  ("user1", "login", "2022-05-02"),
  ("user2", "login", "2022-05-01"),
  ("user3", "login", "2022-05-02"),
  ("user3", "pay",   "2022-05-03"),
  ("user3", "pay",   "2022-05-04");

Exemple de données :

+-------+-------+------------+
| uid   | event | ds         |
+-------+-------+------------+
| user1 | login | 2022-05-01 |
| user1 | pay   | 2022-05-01 |
| user1 | login | 2022-05-02 |
| user1 | pay   | 2022-05-02 |
| user2 | login | 2022-05-01 |
| user3 | login | 2022-05-02 |
| user3 | pay   | 2022-05-03 |
| user3 | pay   | 2022-05-04 |
+-------+-------+------------+

Étape 2. Calculez le statut de rétention par utilisateur.

SELECT
  uid,
  r
FROM (
  SELECT
    uid,
    retention_range_count(
      event = 'login',   -- Activation event
      event = 'pay',     -- Retention event
      ds,
      array(1, 2)        -- Track day-1 and day-2 retention
    ) AS r
  FROM event
  GROUP BY uid
) AS t
ORDER BY uid;

Exemple de résultat :

+-------+-----------------------------+
| uid   | r                           |
+-------+-----------------------------+
| user1 | [[738642,0,0],[738641,1,0]] |
| user2 | [[738641,0,0]]              |
| user3 | [[738642,1,1]]              |
+-------+-----------------------------+

Chaque tableau interne contient [date_de_début_en_jours, retention_j1, retention_j2]. Par exemple, user3 s'est connecté le 2 mai (numéro de jour 738642) et a effectué un paiement à la fois le 3 mai (jour 1) et le 4 mai (jour 2).

Étape 3. Agrégez les données pour obtenir les taux de rétention quotidiens pour tous les utilisateurs.

SELECT
  from_days(u[1]) AS ds,
  u[3] / u[2] AS retention_d1,
  u[4] / u[2] AS retention_d2
FROM (
  SELECT retention_range_sum(r) AS r
  FROM (
    SELECT
      uid,
      retention_range_count(
        event = 'login',
        event = 'pay',
        ds,
        array(1, 2)
      ) AS r
    FROM event
    GROUP BY uid
  ) AS t
  ORDER BY uid
) AS r,
unnest(r.r) AS t(u);

Exemple de résultat :

+------------+--------------+--------------+
| ds         | retention_d1 | retention_d2 |
+------------+--------------+--------------+
| 2022-05-02 |          0.5 |          0.5 |
| 2022-05-01 |          0.5 |          0.0 |
+------------+--------------+--------------+

Le 1er mai, deux utilisateurs se sont connectés (user1 et user2). Seul user1 a effectué un paiement le 2 mai (jour 1 après l'activation), donc la rétention à J+1 pour le 1er mai est de 0,5. Aucun utilisateur n'a effectué de paiement le 3 mai (jour 2 après l'activation), donc la rétention à J+2 pour le 1er mai est de 0,0. Le 2 mai, deux utilisateurs se sont connectés (user1 et user3). Tous deux ont effectué un paiement dans les deux jours suivants, donc les rétentions à J+1 et J+2 sont de 0,5 pour les utilisateurs activés le 2 mai.

Étapes suivantes