Attribution des tests A/B et indicateurs
Associer l’attribution de l’expérience aux résultats et calculer les indicateurs par variante
Attribution des tests A/B et indicateurs est une leçon SQL Interview Prep gratuite sur CoddyKit. Ceci est la leçon 3 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage SQL Interview Prep, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours SQL Interview Prep comprend 4 leçons au total.
Ce qu'évalue une question d'expérience A/B
Les questions sur les expériences A/B vérifient que vous savez correctement faire la jointure entre l'affectation à l'expérience et les résultats et calculer un indicateur fiable par variante.
Le piège se trouve presque toujours dans la jointure : compter les résultats d'utilisateurs qui n'ont jamais été inscrits, ou compter deux fois des utilisateurs affectés deux fois. Réalisez correctement la jointure avec les affectations et les indicateurs se réduisent à une simple arithmétique.
Les deux tables que vous recevez
Prévoyez une table d'affectations et une table de résultats :
assignments(user_id, variant, assigned_at), où la variante est « contrôle » ou « traitement ».orders(user_id, order_id, amount, created_at)ou une table d'événements générique.
La table des affectations est la source de vérité pour déterminer qui participe à l'expérience. Les résultats ne sont comptabilisés que si l'utilisateur apparaît dans les affectations.
CREATE TABLE assignments (
user_id INT,
variant VARCHAR(20),
assigned_at TIMESTAMP
);
CREATE TABLE orders (
user_id INT,
order_id INT,
amount NUMERIC,
created_at TIMESTAMP
);Partir de l'affectation et utiliser LEFT JOIN pour les résultats
La règle fondamentale : partez de la table des affectations et utilisez LEFT JOIN pour les résultats. Vous conservez ainsi les utilisateurs inscrits mais qui n'ont jamais converti, ce qui est nécessaire pour obtenir un dénominateur honnête.
INNER JOIN supprimerait silencieusement les utilisateurs non convertis et gonflerait votre taux de conversion.
SELECT
a.user_id,
a.variant,
o.order_id
FROM assignments a
LEFT JOIN orders o
ON o.user_id = a.user_id;Compter les conversions par variante
Le taux de conversion = utilisateurs convertis / utilisateurs affectés, pour chaque variante. Comptez les utilisateurs convertis distincts au numérateur et tous les utilisateurs affectés au dénominateur.
Utilisez COUNT(DISTINCT ...) sur l'utilisateur de la commande afin qu'un utilisateur ayant passé trois commandes ne compte que comme un seul utilisateur converti.
SELECT
a.variant,
COUNT(DISTINCT a.user_id) AS assigned,
COUNT(DISTINCT o.user_id) AS converters,
ROUND(100.0 * COUNT(DISTINCT o.user_id)
/ COUNT(DISTINCT a.user_id), 2) AS conv_rate_pct
FROM assignments a
LEFT JOIN orders o ON o.user_id = a.user_id
GROUP BY a.variant;Le piège de la double affectation
Que se passe-t-il si un utilisateur apparaît deux fois dans les affectations, une fois dans chaque variante ? Votre jointure le compte alors des deux côtés et l'expérience est faussée.
Les recruteurs introduisent souvent ce cas. Préparez-vous à le gérer : dédupliquez les affectations pour ne conserver qu'une variante par utilisateur, généralement la première affectation, avant d'effectuer la jointure.
WITH dedup AS (
SELECT user_id, variant,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY assigned_at) AS rn
FROM assignments
)
SELECT user_id, variant
FROM dedup
WHERE rn = 1;Ne compter les résultats qu'après l'affectation
Une commande passée avant l'affectation de l'utilisateur ne peut pas être due à l'expérience. Ajoutez une contrainte temporelle : le résultat doit se produire à la date de assigned_at ou après.
Placez cette condition dans la clause ON de la LEFT JOIN afin de continuer à conserver les utilisateurs non convertis.
SELECT
a.variant,
COUNT(DISTINCT a.user_id) AS assigned,
COUNT(DISTINCT o.user_id) AS converters
FROM assignments a
LEFT JOIN orders o
ON o.user_id = a.user_id
AND o.created_at >= a.assigned_at
GROUP BY a.variant;ON et WHERE dans la jointure des résultats
C'est une question de suivi presque garantie. Si vous déplacez o.created_at >= a.assigned_at dans WHERE, vous transformez la LEFT JOIN en jointure interne : pour les lignes où l'utilisateur n'a jamais commandé, o.created_at = NULL, le prédicat vaut UNKNOWN et ces lignes disparaissent.
Conservez les conditions de filtrage des résultats dans ON afin de préserver les utilisateurs non convertis au dénominateur.
Indicateurs de revenus par variante
Au-delà de la conversion, les recruteurs demandent le revenu par utilisateur (ARPU) et le revenu par utilisateur converti. Faites la somme des montants, puis divisez-la par le dénominateur approprié.
L'ARPU se calcule en divisant par tous les utilisateurs affectés ; le revenu par utilisateur converti se calcule uniquement avec les utilisateurs ayant passé une commande. Précisez clairement lequel l'entreprise souhaite obtenir.
SELECT
a.variant,
COUNT(DISTINCT a.user_id) AS assigned,
COALESCE(SUM(o.amount), 0) AS revenue,
ROUND(COALESCE(SUM(o.amount), 0)
/ COUNT(DISTINCT a.user_id), 2) AS arpu
FROM assignments a
LEFT JOIN orders o
ON o.user_id = a.user_id
AND o.created_at >= a.assigned_at
GROUP BY a.variant;Le schéma d'agrégation à deux niveaux
Lorsqu'un indicateur correspond à la « moyenne de commandes par utilisateur », ne le calculez pas en une seule passe : vous mélangeriez les niveaux utilisateur et commande. Agrégez d'abord au niveau utilisateur, puis calculez la moyenne sur l'ensemble des utilisateurs.
Ce schéma, qui consiste à passer de l'utilisateur à la variante, utilise la bonne granularité et permet souvent de distinguer les candidats lors d'un entretien.
WITH per_user AS (
SELECT a.variant, a.user_id,
COUNT(o.order_id) AS orders_cnt
FROM assignments a
LEFT JOIN orders o
ON o.user_id = a.user_id
AND o.created_at >= a.assigned_at
GROUP BY a.variant, a.user_id
)
SELECT variant, ROUND(AVG(orders_cnt), 3) AS avg_orders_per_user
FROM per_user
GROUP BY variant;Une requête complète et défendable
Combinez tous les éléments : dédupliquez pour conserver la première affectation, partez des affectations, imposez la contrainte temporelle sur les résultats dans ON, puis présentez la conversion et l'ARPU par variante. Expliquez chaque contrainte au fur et à mesure que vous l'écrivez.
WITH enrolled AS (
SELECT user_id, variant, assigned_at
FROM (
SELECT user_id, variant, assigned_at,
ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY assigned_at) AS rn
FROM assignments
) x WHERE rn = 1
)
SELECT
e.variant,
COUNT(DISTINCT e.user_id) AS assigned,
COUNT(DISTINCT o.user_id) AS converters,
ROUND(100.0 * COUNT(DISTINCT o.user_id)
/ COUNT(DISTINCT e.user_id), 2) AS conv_pct,
ROUND(COALESCE(SUM(o.amount),0)
/ COUNT(DISTINCT e.user_id), 2) AS arpu
FROM enrolled e
LEFT JOIN orders o
ON o.user_id = e.user_id
AND o.created_at >= e.assigned_at
GROUP BY e.variant;Vérifications de cohérence attendues par les recruteurs
Avant d'annoncer les résultats, validez la configuration de l'expérience :
- Les tailles des variantes sont-elles à peu près équilibrées ? Une répartition 90/10 alors qu'une répartition 50/50 était prévue indique un problème.
- Un utilisateur s'est-il retrouvé dans les deux variantes ? Comptez les utilisateurs associés à plusieurs variantes distinctes.
- Existe-t-il des affectations sans fenêtre de résultats possible (affectation postérieure à la date de coupure des données) ?
Proposer ces vérifications sans qu'on vous le demande montre votre maturité analytique.
SELECT user_id, COUNT(DISTINCT variant) AS variant_count
FROM assignments
GROUP BY user_id
HAVING COUNT(DISTINCT variant) > 1;Vérification rapide
Vous calculez la conversion par variante en reliant les commandes aux affectations avec LEFT JOIN, mais vous placez o.created_at >= a.assigned_at dans la clause WHERE. Que se passe-t-il ?
Récapitulatif : affectation à une expérience A/B et indicateurs
Vous disposez maintenant d'une méthode défendable pour analyser une expérience :
- Considérez l'affectation comme la source de vérité et utilisez LEFT JOIN pour les résultats.
- Dédupliquez afin de ne conserver qu'une variante par utilisateur (première affectation).
- Imposez la contrainte temporelle sur les résultats dans la clause ON, jamais dans WHERE, pour conserver les utilisateurs non convertis.
- Choisissez le bon dénominateur pour la conversion, l'ARPU et le revenu par utilisateur converti.
- Agrégez d'abord au niveau utilisateur pour calculer les moyennes par utilisateur.
- Effectuez des vérifications de cohérence sur l'équilibre de la répartition et les affectations multiples.
Ensuite : transformer ces indicateurs par variante en gain, significativité et garde-fous.
Questions Fréquemment Posées
La leçon « Attribution des tests A/B et indicateurs » est-elle gratuite ?
Oui — le texte complet de « Attribution des tests A/B et indicateurs » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours SQL Interview Prep, passe à CoddyKit PRO. Le cours SQL Interview Prep comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Attribution des tests A/B et indicateurs » ?
Associer l’attribution de l’expérience aux résultats et calculer les indicateurs par variante Tu pratiques SQL Interview Prep avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer SQL Interview Prep ?
Aucune expérience préalable n'est requise. SQL Interview Prep sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 3 sur 4.
Combien de temps prend la leçon « Attribution des tests A/B et indicateurs » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon SQL Interview Prep ?
Oui. Chaque leçon SQL Interview Prep inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- Construire un entonnoir en plusieurs étapes
- Événements ordonnés et fenêtres temporelles
- Attribution des tests A/B et indicateurs
- Gain, significativité et garde-fous en SQL