Los Product Managers trabajan periódicamente con métricas que describen cómo las personas descubren, adoptan y utilizan un producto. La mayoría de estas métricas provienen de datos almacenados en varias tablas: cuentas de usuario, eventos, suscripciones, transacciones y otros registros generados a medida que las personas interactúan con la aplicación. SQL proporciona una manera de recuperar esa información y convertirla en respuestas a preguntas específicas sobre productos.
Un Product Manager que investiga una caída en la activación, por ejemplo, puede querer saber cuántos nuevos usuarios completaron la incorporación, cuánto tiempo les llevó alcanzar su primera acción significativa o si la activación difiere entre los canales de adquisición. Estas preguntas a menudo se pueden responder combinando registros de usuarios con eventos de comportamiento y aplicando los filtros y agregaciones adecuados.
SQL es particularmente útil cuando los paneles disponibles no proporcionan el nivel de detalle necesario para una investigación. Permite ajustar el análisis a medida que surgen nuevas preguntas, siempre que los datos subyacentes sean accesibles y confiables.
Este artículo presenta siete ejemplos prácticos de SQL que cubren escenarios comunes de análisis de productos. Cada ejemplo comienza con una pregunta sobre el producto, explica los datos necesarios y muestra cómo se puede utilizar una consulta para investigarlos.
1. Comprender los datos detrás del análisis de productos
Antes de escribir consultas, es útil comprender cómo se organizan los datos del producto. La mayoría de los productos digitales almacenan información en varias tablas, cada una de las cuales representa un tipo diferente de entidad o actividad.
Una aplicación basada en suscripción, por ejemplo, podría tener una tabla users que contiene información de la cuenta, una tabla events que registra las acciones del usuario y una tabla subscriptions que describe los planes pagos.
Los ejemplos utilizan la siguiente estructura simplificada de base de datos.
Usuarios
| Columna | Descripción |
|---|---|
| user_id | Identificador único para cada usuario |
| signup_date | Fecha en que se creó la cuenta creado |
| canal_adquisición | Canal a través del cual se adquirió el usuario |
| país | País del usuario |
Eventos
| Columna | Descripción |
|---|---|
| event_id | Identificador de evento único |
| user_id | Usuario que realizó la action |
| event_name | Nombre del evento registrado |
| event_timestamp | Fecha y hora del evento |
Suscripciones
| Columna | Descripción |
|---|---|
| subscription_id | Identificador de suscripción único |
| user_id | Asociado usuario |
| nombre_plan | Plan de suscripción |
| started_at | Marca de tiempo de inicio de suscripción |
| ended_at | Marca de tiempo de finalización de suscripción, si corresponde |
El producto hipotético es una aplicación de gestión de proyectos en la que los usuarios crean proyectos, invitan a compañeros y gestionan tareas. Su registro de eventos incluye project_created, task_created, teammate_invited y session_started.
Los ejemplos utilizan la sintaxis de PostgreSQL. Otras bases de datos, incluidas BigQuery, Snowflake y MySQL, admiten operaciones similares, aunque las funciones de fecha y determinadas expresiones SQL pueden diferir. El modelo de datos está intencionalmente simplificado. Las bases de datos de producción suelen contener tablas adicionales, propiedades de eventos, asignaciones de identidad y reglas comerciales que deben tenerse en cuenta antes de calcular las métricas.
2. Ejemplo 1: Medición de la activación del usuario
Pregunta sobre el producto: ¿Qué porcentaje de nuevos usuarios completan su primera acción significativa?
Un registro nos dice que alguien creó una cuenta, pero no establece si experimentó el valor previsto del producto. Para una aplicación de gestión de proyectos, la creación de un primer proyecto podría ser un evento de activación inicial razonable, aunque el equipo debe validar si esa acción está realmente asociada con un uso posterior.
Supongamos que el Product Manager quiere medir el porcentaje de usuarios que crean un proyecto dentro de los siete días posteriores al registro. El cálculo requiere dos grupos: usuarios que se registraron durante el período de análisis y aquellos que completaron el evento de activación dentro de la ventana definida.
WITH new_users AS (
SELECT
user_id,
signup_date
FROM users
WHERE signup_date >= DATE '2026-09-01'
AND signup_date < DATE '2026-10-01'
),
activated_users AS (
SELECT DISTINCT
u.user_id
FROM new_users u
JOIN events e
ON u.user_id = e.user_id
WHERE e.event_name = 'project_created'
AND e.event_timestamp >= u.signup_date
AND e.event_timestamp < u.signup_date
+ INTERVAL '7 days'
)
SELECT
COUNT(DISTINCT u.user_id) AS signups,
COUNT(DISTINCT a.user_id) AS activated_users,
ROUND(
100.0 * COUNT(DISTINCT a.user_id)
/ NULLIF(COUNT(DISTINCT u.user_id), 0),
2
) AS activation_rate
FROM new_users u
LEFT JOIN activated_users a
ON u.user_id = a.user_id;La primera expresión de tabla común (CTE) selecciona a los usuarios que se registraron en septiembre. El segundo identifica a quienes crearon un proyecto durante sus primeros siete días. La consulta final calcula la proporción de nuevos usuarios que cumplieron esa condición.
Si 1000 usuarios se registraron y 420 crearon un proyecto en siete días, la tasa de activación sería del 42%. Este resultado se vuelve más útil cuando se realiza un seguimiento a lo largo del tiempo o se compara entre segmentos. Una tasa de activación decreciente podría indicar problemas en la incorporación, cambios en la calidad de la adquisición o problemas técnicos que afectan el flujo de creación del primer proyecto.
La ventana de siete días también importa. Los usuarios que se registraron a finales de septiembre deben observar su actividad hasta octubre. Sin esos datos adicionales, los registros recientes podrían clasificarse incorrectamente como inactivos.
3. Ejemplo 2: análisis de un embudo de conversión
Pregunta sobre el producto: ¿Dónde dejan los usuarios durante la incorporación?
Un embudo de conversión describe la progresión a través de una secuencia de acciones. En nuestra aplicación de gestión de proyectos, la incorporación puede implicar crear una cuenta, crear un proyecto e invitar a un compañero de equipo. Para analizar este recorrido, necesitamos identificar cuántos usuarios completan cada paso en el orden esperado.
WITH signups AS (
SELECT
user_id,
signup_date::timestamp AS signup_at
FROM users
WHERE signup_date >= DATE '2026-09-01'
AND signup_date < DATE '2026-10-01'
),
first_project AS (
SELECT
s.user_id,
MIN(e.event_timestamp) AS project_at
FROM signups s
JOIN events e
ON s.user_id = e.user_id
AND e.event_name = 'project_created'
AND e.event_timestamp >= s.signup_at
GROUP BY s.user_id
),
first_invite AS (
SELECT
p.user_id,
MIN(e.event_timestamp) AS invite_at
FROM first_project p
JOIN events e
ON p.user_id = e.user_id
AND e.event_name = 'teammate_invited'
AND e.event_timestamp >= p.project_at
GROUP BY p.user_id
)
SELECT
(SELECT COUNT(*) FROM signups) AS signed_up,
(SELECT COUNT(*) FROM first_project) AS created_project,
(SELECT COUNT(*) FROM first_invite) AS invited_teammate;La consulta cuenta los usuarios que se registraron, luego los que crearon un proyecto después de registrarse y, finalmente, los que invitaron a un compañero de equipo después de crear un proyecto. Un resultado ilustrativo podría verse así:
| Paso del embudo | Usuarios | Conversión del paso anterior |
|---|---|---|
| Se registraron | 1000 | — |
| Creó un proyecto | 620 | 62,0% |
| Invitó a un compañero de equipo | 280 | 45,2% |
La mayor caída proporcional se produce entre la creación del proyecto y la invitación a un compañero de equipo. Esto le da al Product Manager un área específica para investigar, aunque los números por sí solos no explican por qué los usuarios dejan de progresar.
Algunos usuarios pueden preferir explorar la aplicación individualmente antes de invitar a colegas. Otros pueden encontrar confuso el flujo de la invitación, carecer de los permisos necesarios o simplemente no tener ningún motivo inmediato para colaborar.
El siguiente paso podría implicar segmentar el embudo por canal de adquisición, dispositivo o tipo de cliente y luego combinar los resultados cuantitativos con la investigación cualitativa.
Antes de actuar sobre una caída de activación
Escenario ilustrativo: un dashboard muestra que la activación baja del 42 % al 35 %. Es un motivo para investigar, pero todavía no demuestra que el nuevo onboarding haya causado la caída. Antes de cambiar el producto, comprueba qué se ha contado.
- Compara ventanas completas. Si activarse significa crear un proyecto en siete días, deja esos siete días completos a ambas cohortes de registro. No compares una cohorte madura con usuarios que llegaron ayer.
- Cuenta usuarios, no filas de eventos. Un usuario que crea cuatro proyectos debe aportar un solo usuario activado. Un JOIN puede multiplicar filas: revisa la unidad de análisis antes de agregar.
- Revisa la mezcla de adquisición. Compara la activación por canal además del total. Una mayor proporción de un canal con menor activación puede reducir el total aunque la tasa de cada canal siga igual.
- Comprueba la instrumentación. Revisa si la definición del evento, la identificación de usuarios o la recogida de datos cambiaron con el release.
Imagina que ambas cohortes tienen 1.000 registros, pero la segunda sigue dentro de su ventana de observación. Sus 350 usuarios activados son un recuento parcial. Esperar al cierre puede cambiar la interpretación; no garantiza que la tasa final se recupere.
Decisión que te llevas: documenta la cohorte, el evento de activación, la ventana de observación y las exclusiones junto a la consulta. Después decide si la evidencia justifica un cambio de producto o si el siguiente paso es comprobar los datos.
Consulta la guía de agregaciones de PostgreSQL para la mecánica del cálculo. Para elegir entre aprender consultas y definir métricas, utiliza nuestra guía de libros técnicos.
Esta consulta también ilustra una limitación importante del análisis de embudo: la definición de cada paso influye en el resultado. Aquí, los usuarios deben completar los eventos en orden, pero no hay un tiempo máximo permitido entre ellos. Agregar una ventana de finalización de siete días produciría una métrica diferente.
4. Ejemplo 3: Medición de la adopción de funciones
Pregunta sobre el producto: ¿Cuántos usuarios activos están adoptando una nueva función?
La adopción de funciones mide qué tan ampliamente se utiliza una capacidad entre una población relevante. El denominador es particularmente importante porque la adopción puede verse muy diferente dependiendo de si se calcula en función de todos los usuarios registrados, los usuarios activos mensuales o los usuarios elegibles para acceder a la función.
Supongamos que la aplicación introdujo recientemente plantillas de tareas, registradas a través de un evento template_used. El Product Manager quiere medir la adopción entre los usuarios que estuvieron activos durante septiembre.
Para este ejemplo, un usuario activo es alguien que generó al menos un evento session_started durante el mes.
WITH active_users AS (
SELECT DISTINCT user_id
FROM events
WHERE event_name = 'session_started'
AND event_timestamp >= TIMESTAMP '2026-09-01'
AND event_timestamp < TIMESTAMP '2026-10-01'
),
feature_users AS (
SELECT DISTINCT user_id
FROM events
WHERE event_name = 'template_used'
AND event_timestamp >= TIMESTAMP '2026-09-01'
AND event_timestamp < TIMESTAMP '2026-10-01'
)
SELECT
COUNT(DISTINCT a.user_id) AS active_users,
COUNT(DISTINCT f.user_id) AS feature_users,
ROUND(
100.0 * COUNT(DISTINCT f.user_id)
/ NULLIF(COUNT(DISTINCT a.user_id), 0),
2
) AS adoption_rate
FROM active_users a
LEFT JOIN feature_users f
ON a.user_id = f.user_id;Si 2000 usuarios estuvieran activos durante septiembre y 350 usaran plantillas de tareas, la tasa de adopción sería del 17,5%. Ese porcentaje describe el alcance, pero no nos dice si la función es útil o si la gente continúa usándola. Un usuario que prueba una plantilla una vez se cuenta de la misma manera que alguien que utiliza plantillas todos los días.
Un análisis más detallado podría examinar el uso repetido, la cantidad de plantillas creadas o si la adopción de plantillas está asociada con una creación de tareas más rápida. Si la función está disponible solo en ciertos planes de suscripción, el denominador también debe excluir a los usuarios que no pueden acceder a ella. De lo contrario, la tasa de adopción subestimaría el uso entre el público objetivo.
5. Ejemplo 4: cálculo de la retención semanal
Pregunta sobre el producto: ¿Cuántos usuarios regresan al producto después de la primera semana?
La retención mide si los usuarios continúan interactuando con un producto después de una interacción inicial o un punto de partida. La definición varía según el producto y el comportamiento que se mide.
Para nuestra aplicación, calcularemos la retención de la primera semana comprobando si los usuarios que se registraron durante una semana determinada generaron un evento session_started entre siete y catorce días después del registro.
WITH signup_cohorts AS (
SELECT
user_id,
signup_date,
DATE_TRUNC('week', signup_date)::date
AS cohort_week
FROM users
WHERE signup_date >= DATE '2026-08-01'
AND signup_date < DATE '2026-10-01'
),
retained_users AS (
SELECT DISTINCT
u.user_id
FROM signup_cohorts u
JOIN events e
ON u.user_id = e.user_id
WHERE e.event_name = 'session_started'
AND e.event_timestamp >= u.signup_date
+ INTERVAL '7 days'
AND e.event_timestamp < u.signup_date
+ INTERVAL '14 days'
)
SELECT
u.cohort_week,
COUNT(DISTINCT u.user_id) AS new_users,
COUNT(DISTINCT r.user_id) AS retained_users,
ROUND(
100.0 * COUNT(DISTINCT r.user_id)
/ NULLIF(COUNT(DISTINCT u.user_id), 0),
2
) AS week_1_retention
FROM signup_cohorts u
LEFT JOIN retained_users r
ON u.user_id = r.user_id
GROUP BY u.cohort_week
ORDER BY u.cohort_week;El resultado agrupa a los usuarios por semana de registro y calcula el porcentaje que regresó durante su segundo período de siete días.
| Cohorte de registro | Nuevos usuarios | Usuarios retenidos | Retención de la semana 1 |
|---|---|---|---|
| Agosto 3 | 400 | 172 | 43,0% |
| 10 de agosto | 460 | 184 | 40,0% |
| agosto 17 | 510 | 224 | 43,9% |
| 24 de agosto | 480 | 230 | 47,9% |
Estos resultados ilustrativos sugieren que la cohorte del 24 de agosto tuvo un mejor desempeño que las cohortes anteriores. Antes de atribuir la diferencia a una mejora del producto, el equipo necesitaría examinar los cambios en los canales de adquisición, la composición de los usuarios, la estacionalidad y otros factores que podrían influir en la retención.
La ventana de medición también debe estar completa. Los usuarios necesitan al menos catorce días de actividad observable después de registrarse para que esta métrica se calcule de manera justa. Las cohortes que no hayan llegado a ese punto deben excluirse de la comparación hasta que haya suficientes datos disponibles.
6. Ejemplo 5: elaboración de un análisis de cohorte
Pregunta sobre el producto: ¿Cómo evoluciona la retención a lo largo de varios meses?
La retención semanal proporciona una visión de la participación temprana, pero muchos productos necesitan comprender cómo cambia el comportamiento durante períodos más largos. El análisis de cohortes permite comparar grupos de usuarios que se unieron en diferentes momentos y observar su actividad a medida que maduran.
Para este ejemplo, agruparemos a los usuarios por mes de registro y calcularemos si estuvieron activos en los meses calendario siguientes.
WITH user_cohorts AS (
SELECT
user_id,
DATE_TRUNC('month', signup_date)::date
AS cohort_month
FROM users
),
monthly_activity AS (
SELECT DISTINCT
user_id,
DATE_TRUNC('month', event_timestamp)::date
AS activity_month
FROM events
WHERE event_name = 'session_started'
),
cohort_activity AS (
SELECT
u.cohort_month,
(
EXTRACT(YEAR FROM AGE(
a.activity_month,
u.cohort_month
)) * 12
+ EXTRACT(MONTH FROM AGE(
a.activity_month,
u.cohort_month
))
)::int AS months_since_signup,
COUNT(DISTINCT u.user_id) AS active_users
FROM user_cohorts u
JOIN monthly_activity a
ON u.user_id = a.user_id
AND a.activity_month >= u.cohort_month
GROUP BY
u.cohort_month,
months_since_signup
),
cohort_sizes AS (
SELECT
cohort_month,
COUNT(*) AS cohort_size
FROM user_cohorts
GROUP BY cohort_month
)
SELECT
a.cohort_month,
a.months_since_signup,
s.cohort_size,
a.active_users,
ROUND(
100.0 * a.active_users
/ NULLIF(s.cohort_size, 0),
2
) AS retention_rate
FROM cohort_activity a
JOIN cohort_sizes s
ON a.cohort_month = s.cohort_month
ORDER BY
a.cohort_month,
a.months_since_signup;La consulta produce una fila por cohorte de registro y mes transcurrido. Estos resultados luego se pueden transformar en una matriz de retención, donde cada fila representa una cohorte y cada columna representa el número de meses desde el registro.
Una matriz ilustrativa podría verse así:
| Cohorte de registro | Mes 0 | Mes 1 | Mes 2 | Mes 3 |
|---|---|---|---|---|
| Mayo 2026 | 88% | 51% | 39% | 33% |
| junio de 2026 | 90% | 54% | 42% | 36% |
| julio 2026 | 89% | 57% | 44% | — |
| Agosto de 2026 | 91% | 59% | — | — |
El mes 0 representa la actividad durante el mes de registro. No es necesariamente 100%, ya que la métrica cuenta a los usuarios que generaron un evento de sesión, en lugar de tratar automáticamente cada registro como activo.
Las celdas vacías indican períodos para los cuales la cohorte aún no ha acumulado suficiente historial. Una matriz de cohorte puede revelar patrones que son difíciles de identificar a partir del recuento total mensual de usuarios activos. Por ejemplo, la actividad total podría aumentar porque la empresa está adquiriendo más usuarios, incluso cuando la proporción de usuarios que regresan después de dos meses está disminuyendo.
El análisis de cohortes ayuda a separar el crecimiento de las adquisiciones de los cambios en el comportamiento de los usuarios existentes. Es particularmente útil al evaluar mejoras de incorporación, cambios en la experiencia del producto o cambios en la estrategia de adquisición.
7. Ejemplo 6: comparación de métricas de productos por canal de adquisición
Pregunta sobre el producto: ¿Qué canales de adquisición atraen usuarios que realmente interactúan?
Los informes de adquisición a menudo enfatizan la cantidad de registros generados por cada canal. Esa información es útil para comprender el volumen, pero proporciona información limitada sobre la calidad de los usuarios adquiridos.
Un canal que genera una gran cantidad de registros puede producir relativamente pocos usuarios activados, mientras que un canal más pequeño puede atraer a personas que tienen más probabilidades de completar la incorporación y continuar usando el producto.
Para investigar esto, calcularemos las tasas de activación por canal de adquisición utilizando la misma definición de activación de siete días presentada anteriormente.
WITH signups AS (
SELECT
user_id,
signup_date,
acquisition_channel
FROM users
WHERE signup_date >= DATE '2026-09-01'
AND signup_date < DATE '2026-10-01'
),
activated AS (
SELECT DISTINCT
u.user_id
FROM signups u
JOIN events e
ON u.user_id = e.user_id
WHERE e.event_name = 'project_created'
AND e.event_timestamp >= u.signup_date
AND e.event_timestamp < u.signup_date
+ INTERVAL '7 days'
)
SELECT
u.acquisition_channel,
COUNT(DISTINCT u.user_id) AS signups,
COUNT(DISTINCT a.user_id) AS activated_users,
ROUND(
100.0 * COUNT(DISTINCT a.user_id)
/ NULLIF(COUNT(DISTINCT u.user_id), 0),
2
) AS activation_rate
FROM signups u
LEFT JOIN activated a
ON u.user_id = a.user_id
GROUP BY u.acquisition_channel
ORDER BY activation_rate DESC;Un resultado ilustrativo podría ser:
| Canal | Registros | Usuarios activados | Tasa de activación |
|---|---|---|---|
| Orgánico búsqueda | 350 | 189 | 54,0% |
| Referencia | 180 | 90 | 50,0% |
| Pago búsqueda | 500 | 175 | 35,0% |
| Redes sociales | 420 | 105 | 25,0% |
La búsqueda orgánica tiene la tasa de activación más alta en este ejemplo, mientras que la búsqueda paga genera más registros pero una menor proporción de usuarios activados. Los resultados podrían informar las discusiones sobre adquisiciones, aunque la activación por sí sola no es suficiente para determinar la rentabilidad del canal. Los costos de marketing, la retención, la conversión de suscripciones y el valor de vida del cliente pueden llevar a conclusiones diferentes.
Las diferencias en la intención del usuario también importan. Alguien que busque una solución de gestión de proyectos específica puede llegar con una necesidad más clara que alguien que descubre el producto a través de una campaña general en las redes sociales.
Segmentar las métricas de productos por fuente de adquisición ayuda a revelar estas diferencias y respalda conversaciones más informadas entre los equipos de Producto, Marketing y Crecimiento.
8. Ejemplo 7: Medición de la conversión de gratuito a pago
Pregunta sobre el producto: ¿Qué porcentaje de usuarios se convierten en clientes de pago?
Para un producto basado en suscripción, convertir usuarios gratuitos en clientes de pago suele ser una métrica comercial central. El cálculo requiere una definición clara del evento de conversión y de la población que se mide.
En este ejemplo, mediremos el porcentaje de usuarios que inician una suscripción paga dentro de los treinta días posteriores al registro.
La tabla subscriptions contiene registros de suscripción y asumiremos que plan_name identifica el tipo de plan. Un usuario se considera convertido cuando inicia una suscripción cuyo plan no es free.
WITH new_users AS (
SELECT
user_id,
signup_date
FROM users
WHERE signup_date >= DATE '2026-08-01'
AND signup_date < DATE '2026-09-01'
),
paid_users AS (
SELECT DISTINCT
u.user_id
FROM new_users u
JOIN subscriptions s
ON u.user_id = s.user_id
WHERE s.plan_name <> 'free'
AND s.started_at >= u.signup_date
AND s.started_at < u.signup_date
+ INTERVAL '30 days'
)
SELECT
COUNT(DISTINCT u.user_id) AS signups,
COUNT(DISTINCT p.user_id) AS paid_users,
ROUND(
100.0 * COUNT(DISTINCT p.user_id)
/ NULLIF(COUNT(DISTINCT u.user_id), 0),
2
) AS free_to_paid_conversion
FROM new_users u
LEFT JOIN paid_users p
ON u.user_id = p.user_id;Si 1200 usuarios se registraron durante agosto y 144 iniciaron una suscripción paga dentro de los treinta días, la tasa de conversión sería del 12%. El resultado debe interpretarse de acuerdo con el precio y el modelo de prueba del producto. En un producto con una prueba gratuita de catorce días, el comportamiento de conversión puede concentrarse hacia el final del período de prueba. En un producto freemium sin prueba por tiempo limitado, los usuarios pueden tardar varios meses antes de decidirse a actualizar.
La consulta también supone que cada suscripción no gratuita representa una conversión paga. Es posible que una implementación de producción deba excluir planes complementarios, cuentas internas, pagos fallidos o suscripciones que nunca fueron facturables.
Un siguiente paso útil sería comparar las tasas de conversión entre canales de adquisición, planes de suscripción o estados de activación. Esto puede ayudar a identificar si ciertos comportamientos de incorporación están asociados con una mayor probabilidad de convertirse en un cliente de pago.
9. Errores comunes de SQL en análisis de productos
Escribir una consulta que se ejecute correctamente no garantiza que la métrica resultante sea correcta. El análisis de productos depende de la relación entre la lógica SQL, los datos subyacentes y la definición de negocio que se mide.
Una fuente común de errores es contar eventos en lugar de usuarios. Si un usuario crea diez tareas, una consulta que cuente task_created eventos devolverá diez registros. Esto puede ser apropiado al medir el volumen de creación de tareas, pero exageraría la adopción si el objetivo fuera contar cuántos usuarios crearon al menos una tarea. El uso de COUNT(DISTINCT user_id) puede solucionar esta diferencia cuando la métrica requiere usuarios únicos.
Las JOINs pueden presentar problemas similares. Cuando una tabla de usuarios se une a una tabla de eventos, un solo usuario puede aparecer en varias filas porque generó varios eventos. Las agregaciones realizadas después de el JOIN deben tener en cuenta esa relación.
Los periodos de tiempo también requieren un tratamiento cuidadoso. Comparar una cohorte mensual completamente observada con una que ha existido solo durante unos días puede producir resultados engañosos de retención o conversión. El análisis debe excluir cohortes incompletas o indicar claramente que sus períodos de observación son más cortos.
Otra consideración es la calidad del seguimiento de eventos. SQL puede recuperar sólo la información que se ha registrado. Si un evento falta, está duplicado, tiene un nombre incorrecto o se activa en el punto equivocado del recorrido del usuario, el análisis resultante puede no ser confiable incluso cuando la consulta sea técnicamente correcta.
Finalmente, las definiciones de métricas deben permanecer consistentes en todos los equipos e informes. Si Producto define un usuario activo como alguien que inicia una sesión mientras Marketing utiliza cualquier evento registrado, sus paneles pueden informar diferentes recuentos de usuarios activos para el mismo período. La implementación de SQL debe reflejar una definición acordada, idealmente documentada junto con la métrica.
10. De las consultas SQL a las decisiones de producto
SQL resulta útil en la gestión de productos cuando respalda una investigación específica. El punto de partida suele ser una pregunta sobre el comportamiento del usuario o el rendimiento empresarial, seguida de un examen de qué datos pueden responderla.
Una consulta de activación puede revelar que menos usuarios están creando su primer proyecto. Un análisis de embudo puede mostrar dónde se produce esa disminución, mientras que la segmentación por canal de adquisición puede indicar si el cambio se concentra en un grupo en particular. Esos hallazgos pueden luego guiar análisis adicionales, investigaciones de usabilidad o investigaciones técnicas.
Los ejemplos de este artículo cubren varias necesidades analíticas comunes:
- Activación y comportamiento temprano del usuario.
- Embudos de conversión e incorporación.
- Adopción de funciones.
- Retención semanal.
- Análisis de cohorte mensual.
- Rendimiento del canal de adquisición.
- Conversión de gratuito a pago.
Cada consulta proporciona una vista particular del producto. La interpretación depende de cómo se define la métrica, si los datos son confiables y qué otra evidencia está disponible.
Los Product Managers que quieran desarrollar aún más estas habilidades pueden explorar SQL para Product Managers, parte de la colección The Product Shelf. El libro cubre los conceptos de SQL utilizados en el análisis de productos, incluidos filtrado, agregaciones, JOINs, operaciones de fechas, embudos, cohortes y traducción de preguntas comerciales en consultas.
Para referencia adicional, la documentación de PostgreSQL proporciona una introducción a la sintaxis SQL y las consultas de bases de datos.
Antes de utilizar una consulta en un informe periódico hay que validar su población, periodo de observación y tratamiento de registros duplicados o ausentes. Guardar esas definiciones junto a la consulta permite mantener el cálculo en las comparaciones posteriores.
