hzy24/validate-data

/validate-data - Validar Análisis Antes de Compartir

Si ves marcadores de posición desconocidos o necesitas verificar qué herramientas están conectadas, consulta CONNECTORS.md.

Revisa un análisis para verificar su precisión, metodología y posibles sesgos antes de compartirlo con las partes interesadas. Genera una evaluación de confianza y sugerencias de mejora.

Uso

/validate-data <análisis a revisar>

El análisis puede ser:

• Un documento o informe en la conversación
• Un archivo (markdown, notebook, hoja de cálculo)
• Consultas SQL y sus resultados
• Gráficos y sus datos subyacentes
• Una descripción de la metodología y los hallazgos

Flujo de Trabajo

1. Revisar Metodología y Suposiciones

Examina:

• Formulación de la pregunta: ¿El análisis responde a la pregunta correcta? ¿Podría interpretarse la pregunta de manera diferente?
• Selección de datos: ¿Se están utilizando las tablas/conjuntos de datos correctos? ¿El rango de tiempo es apropiado?
• Definición de población: ¿La población del análisis está definida correctamente? ¿Hay exclusiones no intencionadas?
• Definiciones de métricas: ¿Las métricas están definidas de forma clara y consistente? ¿Coinciden con cómo las entienden las partes interesadas?
• Línea base y comparación: ¿La comparación es justa? ¿Los períodos de tiempo, tamaños de cohorte y contextos son comparables?

2. Ejecutar la Lista de Verificación de QA Previa a la Entrega

Trabaja a través de la lista de verificación a continuación: comprobaciones de calidad de datos, cálculo, razonabilidad y presentación.

3. Buscar Trampas Analíticas Comunes

Revisa sistemáticamente el catálogo detallado de trampas a continuación (explosión de joins, sesgo de supervivencia, comparación de períodos incompleta, cambio de denominador, promedio de promedios, desajustes de zona horaria, sesgo de selección).

4. Verificar Cálculos y Agregaciones

Cuando sea posible, verifica puntualmente:

• Recalcula algunos números clave de forma independiente
• Verifica que los subtotales sumen los totales
• Comprueba que los porcentajes sumen 100% (o cerca) cuando se espera
• Confirma que las comparaciones interanuales/mensuales utilicen los períodos base correctos
• Valida que los filtros se apliquen de manera consistente en todas las métricas

Aplica las técnicas de verificación de cordura de resultados a continuación (comprobaciones de magnitud, validación cruzada, detección de banderas rojas).

5. Evaluar Visualizaciones

Si el análisis incluye gráficos:

• ¿Los ejes comienzan en valores apropiados (cero para gráficos de barras)?
• ¿Las escalas son consistentes en los gráficos de comparación?
• ¿Los títulos de los gráficos describen con precisión lo que se muestra?
• ¿Podría la visualización engañar a un lector rápido?
• ¿Hay ejes truncados, intervalos inconsistentes o efectos 3D que distorsionen la percepción?

6. Evaluar la Narrativa y las Conclusiones

Revisa si:

• Las conclusiones están respaldadas por los datos mostrados
• Se reconocen explicaciones alternativas
• La incertidumbre se comunica adecuadamente
• Las recomendaciones se derivan lógicamente de los hallazgos
• El nivel de confianza coincide con la solidez de la evidencia

7. Sugerir Mejoras

Proporciona sugerencias específicas y accionables:

• Análisis adicionales que fortalecerían las conclusiones
• Salvedades o limitaciones que deberían mencionarse
• Mejores visualizaciones o encuadres para puntos clave
• Contexto faltante que las partes interesadas querrían

8. Generar Evaluación de Confianza

Clasifica el análisis en una escala de 3 niveles:

Listo para compartir -- El análisis es metodológicamente sólido, los cálculos verificados, las salvedades señaladas. Sugerencias menores de mejora pero nada que lo bloquee.

Compartir con salvedades señaladas -- El análisis es en gran medida correcto pero tiene limitaciones o suposiciones específicas que deben comunicarse a las partes interesadas. Enumera las salvedades requeridas.

Necesita revisión -- Se encontraron errores específicos, problemas metodológicos o análisis faltantes que deben abordarse antes de compartir. Enumera los cambios requeridos con orden de prioridad.

Formato de Salida

## Informe de Validación

### Evaluación General: [Listo para compartir | Compartir con salvedades | Necesita revisión]

### Revisión de Metodología
[Hallazgos sobre el enfoque, selección de datos, definiciones]

### Problemas Encontrados
1. [Gravedad: Alta/Media/Baja] [Descripción del problema e impacto]
2. ...

### Verificaciones Puntuales de Cálculos
- [Métrica]: [Verificado / Discrepancia encontrada]
- ...

### Revisión de Visualizaciones
[Cualquier problema con gráficos o presentación visual]

### Mejoras Sugeridas
1. [Mejora y por qué es importante]
2. ...

### Salvedades Requeridas para las Partes Interesadas
- [Salvedad que debe comunicarse]
- ...

---

Lista de Verificación de QA Previa a la Entrega

Ejecuta esta lista de verificación antes de compartir cualquier análisis con las partes interesadas.

Comprobaciones de Calidad de Datos

• Verificación de fuente: Se confirmó qué tablas/fuentes de datos se utilizaron. ¿Son las correctas para esta pregunta?
• Actualidad: Los datos son lo suficientemente actuales para el análisis. Se anotó la fecha "a fecha de".
• Integridad: No hay brechas inesperadas en las series temporales o segmentos faltantes.
• Manejo de nulos: Se verificaron las tasas de nulos en columnas clave. Los nulos se manejan adecuadamente (excluidos, imputados o marcados).
• Desduplicación: Se confirmó que no hay doble conteo debido a joins incorrectos o registros fuente duplicados.
• Verificación de filtros: Todas las cláusulas WHERE y los filtros son correctos. No hay exclusiones no intencionadas.

Comprobaciones de Cálculo

• Lógica de agregación: GROUP BY incluye todas las columnas no agregadas. El nivel de agregación coincide con el grano del análisis.
• Corrección del denominador: Los cálculos de tasas y porcentajes utilizan el denominador correcto. Los denominadores no son cero.
• Alineación de fechas: Las comparaciones utilizan la misma duración de período de tiempo. Los períodos parciales se excluyen o se señalan.
• Corrección de JOIN: Los tipos de JOIN son apropiados (INNER vs LEFT). Los joins muchos a muchos no han inflado los conteos.
• Definiciones de métricas: Las métricas coinciden con cómo las definen las partes interesadas. Cualquier desviación se señala.
• Suma de subtotales: Las partes suman al total donde se espera. Si no lo hacen, explica por qué (por ejemplo, superposición).

Comprobaciones de Razonabilidad

• Magnitud: Los números están en un rango plausible. Los ingresos no son negativos. Los porcentajes están entre 0-100%.
• Continuidad de tendencia: No hay saltos o caídas inexplicables en las series temporales.
• Referencia cruzada: Los números clave coinciden con otras fuentes conocidas (paneles, informes anteriores, datos financieros).
• Orden de magnitud: Los ingresos totales están en el rango correcto. Los recuentos de usuarios coinciden con cifras conocidas.
• Casos límite: ¿Qué sucede en los límites? Segmentos vacíos, períodos de actividad cero, nuevas entidades.

Comprobaciones de Presentación

• Precisión de gráficos: Los gráficos de barras comienzan en cero. Los ejes están etiquetados. Las escalas son consistentes entre paneles.
• Formato de números: Precisión adecuada. Formato de moneda/porcentaje consistente. Separadores de miles donde sea necesario.
• Claridad de títulos: Los títulos indican la información, no solo la métrica. Los rangos de fechas están especificados.
• Transparencia de salvedades: Las limitaciones y suposiciones conocidas se indican explícitamente.
• Reproducibilidad: Alguien más podría recrear este análisis a partir de la documentación proporcionada.

Trampas Comunes en el Análisis de Datos

Explosión de JOIN

El problema: Un join muchos a muchos multiplica silenciosamente las filas, inflando los conteos y las sumas.

Cómo detectarlo:

-- Verificar el conteo de filas antes y después del join
SELECT COUNT(*) FROM tabla_a;  -- 1,000
SELECT COUNT(*) FROM tabla_a a JOIN tabla_b b ON a.id = b.a_id;  -- 3,500 (uh oh)

Cómo prevenirlo:

• Siempre verifica los conteos de filas después de los joins
• Si los conteos aumentan, investiga la relación del join (¿es realmente 1:1 o 1:muchos?)
• Usa COUNT(DISTINCT a.id) en lugar de COUNT(*) al contar entidades a través de joins

Sesgo de Supervivencia

El problema: Analizar solo las entidades que existen hoy, ignorando aquellas que fueron eliminadas, se fueron o fracasaron.

Ejemplos:

• Analizar el comportamiento de "usuarios actuales" omite a los usuarios que se fueron
• Mirar "empresas que usan nuestro producto" ignora a las que evaluaron y se fueron
• Estudiar propiedades de resultados "exitosos" sin los "no exitosos"

Cómo prevenirlo: Pregunta "¿QUIÉN NO está en este conjunto de datos?" antes de sacar conclusiones.

Comparación de Período Incompleta

El problema: Comparar un período parcial con un período completo.

Ejemplos:

• "Los ingresos de enero son $500K frente a los $800K de diciembre" -- pero enero no ha terminado
• "Los registros de esta semana han bajado" -- verificado el miércoles, comparando con una semana completa anterior

Cómo prevenirlo: Siempre filtra a períodos completos, o compara el mismo día del mes / mismo número de días.

Cambio de Denominador

El problema: El denominador cambia entre períodos, haciendo que las tasas no sean comparables.

Ejemplos:

• La tasa de conversión mejora porque cambiaste la forma de contar usuarios "elegibles"
• La tasa de abandono cambia porque se actualizó la definición de "activo"

Cómo prevenirlo: Usa definiciones consistentes en todos los períodos comparados. Señala cualquier cambio de definición.

Promedio de Promedios

El problema: Promediar promedios precalculados da resultados incorrectos cuando los tamaños de grupo difieren.

Ejemplo:

• Grupo A: 100 usuarios, ingreso promedio $50
• Grupo B: 10 usuarios, ingreso promedio $200
• Incorrecto: Promedio de promedios = ($50 + $200) / 2 = $125
• Correcto: Promedio ponderado = (100*$50 + 10*$200) / 110 = $63.64

Cómo prevenirlo: Siempre agrega desde datos sin procesar. Nunca promedies promedios preagregados.

Desajustes de Zona Horaria

El problema: Diferentes fuentes de datos usan diferentes zonas horarias, causando desalineación.

Ejemplos:

• Marcas de tiempo de eventos en UTC frente a fechas orientadas al usuario en hora local
• Resúmenes diarios que usan diferentes horas de corte

Cómo prevenirlo: Estandariza todas las marcas de tiempo a una sola zona horaria (se recomienda UTC) antes del análisis. Documenta la zona horaria utilizada.

Sesgo de Selección en Segmentación

El problema: Los segmentos se definen por el resultado que estás midiendo, creando una lógica circular.

Ejemplos:

• "Los usuarios que completaron la incorporación tienen mayor retención" -- obviamente, se autoseleccionaron
• "Los usuarios avanzados generan más ingresos" -- se convirtieron en usuarios avanzados AL generar ingresos

Cómo prevenirlo: Define los segmentos basándote en características previas al tratamiento, no en los resultados.

Otras Trampas Estadísticas

• Paradoja de Simpson: La tendencia se invierte cuando los datos se agregan frente a cuando se segmentan
• Correlación presentada como causalidad sin evidencia de apoyo
• Tamaños de muestra pequeños que llevan a conclusiones poco fiables
• Valores atípicos que afectan desproporcionadamente los promedios (¿deberían usarse medianas en su lugar?)
• Pruebas múltiples / selección selectiva de resultados significativos
• Sesgo de mirar hacia adelante: Usar información futura para explicar eventos pasados
• Rangos de tiempo seleccionados a conveniencia que favorecen una narrativa particular

Verificación de Cordura de Resultados

Comprobaciones de Magnitud

Para cualquier número clave en tu análisis, verifica que supere la "prueba de olfato":

Tipo de Métrica	Comprobación de Cordura
Conteos de usuarios	¿Esto coincide con las cifras conocidas de MAU/DAU?
Ingresos	¿Están en el orden de magnitud correcto en comparación con el ARR conocido?
Tasas de conversión	¿Está entre 0% y 100%? ¿Coincide con las cifras del panel?
Tasas de crecimiento	¿Es realista un crecimiento intermensual del 50%+, o hay un problema de datos?
Promedios	¿El promedio es razonable dado lo que sabes sobre la distribución?
Porcentajes	¿Los porcentajes de los segmentos suman ~100%?

Técnicas de Validación Cruzada

1. Calcula la misma métrica de dos maneras diferentes y verifica que coincidan
2. Verifica puntualmente registros individuales -- elige algunas entidades específicas y rastrea sus datos manualmente
3. Compara con puntos de referencia conocidos -- coteja con paneles publicados, informes financieros o análisis anteriores
4. Ingeniería inversa -- si los ingresos totales son X, ¿el ingreso por usuario multiplicado por el número de usuarios es aproximadamente igual a X?
5. Comprobaciones de límites -- ¿qué sucede cuando filtras a un solo día, un solo usuario o una sola categoría? ¿Esos microresultados tienen sentido?

Banderas Rojas que Justifican Investigación

• Cualquier métrica que haya cambiado más del 50% período tras período sin una causa obvia
• Conteos o sumas que son números redondos exactos (sugiere un problema de filtro o valor predeterminado)
• Tasas exactamente en 0% o 100% (puede indicar datos incompletos)
• Resultados que confirman perfectamente la hipótesis (la realidad suele ser más desordenada)
• Valores idénticos en períodos de tiempo o segmentos (sugiere que la consulta está ignorando una dimensión)

Estándares de Documentación para la Reproducibilidad

Plantilla de Documentación de Análisis

Cada análisis no trivial debe incluir:

## Análisis: [Título]

### Pregunta
[La pregunta específica que se responde]

### Fuentes de Datos
- Tabla: [esquema.nombre_tabla] (a fecha de [fecha])
- Tabla: [esquema.otra_tabla] (a fecha de [fecha])
- Archivo: [nombre_archivo] (fuente: [de dónde vino])

### Definiciones
- [Métrica A]: [Exactamente cómo se calcula]
- [Segmento X]: [Exactamente cómo se determina la pertenencia]
- [Período de tiempo]: [Fecha de inicio] a [fecha de fin], [zona horaria]

### Metodología
1. [Paso 1 del enfoque de análisis]
2. [Paso 2]
3. [Paso 3]

### Suposiciones y Limitaciones
- [Suposición 1 y por qué es razonable]
- [Limitación 1 y su impacto potencial en las conclusiones]

### Hallazgos Clave
1. [Hallazgo 1 con evidencia de apoyo]
2. [Hallazgo 2 con evidencia de apoyo]

### Consultas SQL
[Todas las consultas utilizadas, con comentarios]

### Salvedades
- [Cosas que el lector debe saber antes de actuar sobre esto]

Documentación de Código

Para cualquier código (SQL, Python) que pueda reutilizarse:

"""
Análisis: Cohortes de Retención Mensual
Autor: [Nombre]
Fecha: [Fecha]
Fuente de Datos: tabla de eventos, tabla de usuarios
Última Validación: [Fecha] -- los resultados coincidieron con el panel dentro del 2%

Propósito:
    Calcular cohortes de retención mensual de usuarios basadas en la primera fecha de actividad.

Suposiciones:
    - "Activo" significa al menos un evento en el mes
    - Excluye cuentas de prueba/internas (tipo_usuario != 'interno')
    - Utiliza fechas UTC en todo el análisis

Salida:
    Matriz de retención de cohortes con filas de cohorte_mes y columnas de meses_desde_registro.
    Los valores son tasas de retención (0-100%).
"""

Control de Versiones para Análisis

• Guarda consultas y código en control de versiones (git) o un sistema de documentos compartido
• Anota la fecha de la instantánea de datos utilizada
• Si un análisis se vuelve a ejecutar con datos actualizados, documenta qué cambió y por qué
• Enlaza a versiones anteriores de análisis recurrentes para la comparación de tendencias

Ejemplos

/validate-data Revisa este análisis trimestral de ingresos antes de enviarlo al equipo directivo: [análisis]

/validate-data Revisa esta consulta SQL y sus resultados para asegurarte de que el recuento de usuarios del último mes sea correcto: [consulta SQL y resultados]