Asignación y métricas de pruebas A/B
Unir la asignación del experimento con los resultados y calcular métricas por variante.
Asignación y métricas de pruebas A/B es una lección gratuita de SQL Interview Prep en CoddyKit. Esta es la lección 3 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de SQL Interview Prep, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de SQL Interview Prep incluye 4 lecciones en total.
Qué evalúa una pregunta sobre pruebas A/B
Las preguntas sobre pruebas A/B comprueban si puede unir correctamente la asignación del experimento con los resultados y calcular una métrica limpia por variante.
El error suele estar en la unión: contar resultados de usuarios que nunca fueron incluidos en el experimento o contar dos veces a usuarios asignados en dos ocasiones. Si realiza correctamente la unión con la asignación, las métricas son una cuestión sencilla de aritmética.
Las dos tablas que recibirá
Espere una tabla de asignaciones y una tabla de resultados:
assignments(user_id, variant, assigned_at), donde variant es 'control' o 'treatment'.orders(user_id, order_id, amount, created_at)o una tabla de eventos genérica.
La asignación es la fuente de verdad para determinar quién participa en el experimento. Los resultados solo se cuentan si el usuario aparece en la asignación.
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
);Parta de la asignación y use LEFT JOIN con los resultados
La regla fundamental es partir de la tabla de asignaciones y hacer LEFT JOIN con los resultados. Así conserva a los usuarios incluidos en el experimento que nunca convirtieron, algo necesario para obtener un denominador fiable.
Un INNER JOIN eliminaría silenciosamente a quienes no convirtieron y aumentaría artificialmente la tasa de conversión.
SELECT
a.user_id,
a.variant,
o.order_id
FROM assignments a
LEFT JOIN orders o
ON o.user_id = a.user_id;Contar la conversión por variante
La tasa de conversión es igual a usuarios que convirtieron / usuarios asignados, por variante. Cuente los usuarios distintos que convirtieron en el numerador y todos los usuarios asignados en el denominador.
Use COUNT(DISTINCT ...) sobre el usuario del pedido para que un usuario con tres pedidos siga contando como un solo conversor.
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;La trampa de la doble asignación
¿Qué ocurre si un usuario aparece dos veces en las asignaciones, una vez en cada variante? La unión lo contará en ambos grupos y el experimento quedará contaminado.
Los entrevistadores suelen incluir este caso intencionadamente. Evítelo: deduplique la asignación para dejar una sola variante por usuario, normalmente la de la primera asignación, antes de hacer la unión.
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;Cuente solo los resultados posteriores a la asignación
Un pedido realizado antes de que se asignara el usuario no puede haber sido causado por el experimento. Añada una condición temporal: el resultado debe producirse en assigned_at o después.
Coloque esta condición en la cláusula ON del LEFT JOIN para conservar también a los usuarios que no convirtieron.
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 frente a WHERE en la unión con resultados
Esta es una pregunta de seguimiento casi segura. Si mueve o.created_at >= a.assigned_at a WHERE, convierte el LEFT JOIN en una unión interna: las filas de usuarios que nunca hicieron un pedido tienen o.created_at = NULL, el predicado es UNKNOWN y esas filas desaparecen.
Mantenga las condiciones de filtrado de resultados en ON para conservar a quienes no convirtieron en el denominador.
Métricas de ingresos por variante
Además de la conversión, los entrevistadores pueden pedirle los ingresos por usuario (ARPU) y los ingresos por conversor. Sume el importe y divida después entre el denominador adecuado.
El ARPU se divide entre todos los usuarios asignados; los ingresos por conversor se dividen solo entre los usuarios que hicieron un pedido. Especifique claramente cuál de las dos métricas necesita el negocio.
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;El patrón de agregación en dos niveles
Cuando una métrica es «promedio de pedidos por usuario», no la calcule en una sola pasada: mezclaría el nivel de usuario con el nivel de pedido. Primero agregue al nivel de usuario y después calcule el promedio entre usuarios.
Este patrón, primero por usuario y después por variante, utiliza el nivel de detalle correcto y es un criterio habitual para distinguir respuestas en entrevistas.
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;Una consulta completa y defendible
Combine todos los elementos: deduplique para conservar la primera asignación, parta de la asignación, aplique la condición temporal a los resultados en ON e informe la conversión y el ARPU por variante. Explique cada condición mientras escribe la consulta.
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;Comprobaciones de coherencia que esperan los entrevistadores
Antes de comunicar los resultados, valide la configuración del experimento:
- ¿Los tamaños de las variantes están aproximadamente equilibrados? Una división 90/10 cuando se esperaba 50/50 indica un error.
- ¿Algún usuario terminó en ambas variantes? Cuente los usuarios con más de una variante distinta.
- ¿Hay asignaciones sin una ventana de resultados posible porque se realizaron después del cierre de los datos?
Ofrecer estas comprobaciones sin que se las pidan demuestra madurez analítica.
SELECT user_id, COUNT(DISTINCT variant) AS variant_count
FROM assignments
GROUP BY user_id
HAVING COUNT(DISTINCT variant) > 1;Comprobación rápida
Calcula la conversión por variante haciendo LEFT JOIN de los pedidos con las asignaciones, pero coloca o.created_at >= a.assigned_at en la cláusula WHERE. ¿Qué ocurre?
Repaso: asignación y métricas de pruebas A/B
Ahora dispone de un método defendible para analizar experimentos:
- Trate la asignación como la fuente de verdad y haga LEFT JOIN con los resultados.
- Deduplique para dejar una variante por usuario (la primera asignación).
- Aplique la condición temporal a los resultados en la cláusula ON, nunca en WHERE, para conservar a quienes no convirtieron.
- Elija el denominador adecuado para la conversión, el ARPU y los ingresos por conversor.
- Agregue primero al nivel de usuario para calcular promedios por usuario.
- Realice comprobaciones de coherencia sobre el equilibrio de la división y las asignaciones cruzadas.
Siguiente: convertir estas métricas por variante en incremento, significación y métricas de protección.
Preguntas frecuentes
¿La lección «Asignación y métricas de pruebas A/B» es gratis?
Sí — el texto completo de «Asignación y métricas de pruebas A/B» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de SQL Interview Prep, actualiza a CoddyKit PRO. El curso de SQL Interview Prep incluye 4 lecciones en total.
¿Qué aprenderé en «Asignación y métricas de pruebas A/B»?
Unir la asignación del experimento con los resultados y calcular métricas por variante. Practicas SQL Interview Prep con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.
¿Necesito experiencia previa para empezar SQL Interview Prep?
No se requiere experiencia previa. SQL Interview Prep en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 3 de 4.
¿Cuánto tiempo toma la lección «Asignación y métricas de pruebas A/B»?
La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.
¿Puedo escribir y ejecutar código en esta lección de SQL Interview Prep?
Sí. Cada lección de SQL Interview Prep incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.
Todas las lecciones de este curso
- Crear un embudo de varios pasos
- Eventos ordenados y ventanas temporales
- Asignación y métricas de pruebas A/B
- Incremento, significancia y controles en SQL