Menü
Root-cause analysis — identify which dimensions explain a metric spike, drop, or anomaly
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | Investigación de Métricas |
| description | Root-cause analysis — identify which dimensions explain a metric spike, drop, or anomaly |
| keywords | driver, cause, investigate, root cause, breakdown, attribution, por qué, porqué, causa, cayó, bajó, subió, spike, explicar, impacto, dimensión, contribuyó, investigar |
| next | data-storytelling |
Activa cuando el usuario quiere entender POR QUÉ una métrica cambió. Sigue la metodología de drill-down dimensional: descomponer el cambio total en contribuciones por segmento, al estilo Tableau Pulse.
Objetivo: encontrar la combinación de dimensiones (región, producto, canal, etc.) que explica la mayor parte del cambio entre período A y período B.
Razona en hipótesis, no en barrido: antes de medir, lista qué dimensiones podrían explicar el cambio y por qué (¿lanzamiento? ¿estacionalidad? ¿un segmento?). Mide para confirmar o descartar esas hipótesis, empezando por la más probable — no descompongas todas las dimensiones por inercia.
SELECT dimension,
SUM(CASE WHEN periodo = 'actual' THEN metrica ELSE 0 END) AS actual,
SUM(CASE WHEN periodo = 'baseline' THEN metrica ELSE 0 END) AS baseline,
SUM(CASE WHEN periodo = 'actual' THEN metrica ELSE 0 END) -
SUM(CASE WHEN periodo = 'baseline' THEN metrica ELSE 0 END) AS delta,
ROUND((...delta... / NULLIF(...total_delta..., 0)) * 100, 1) AS pct_contribucion
FROM tabla
GROUP BY dimension
ORDER BY ABS(delta) DESC
display_chart tipo bar-horizontal con delta por segmentoCORR() nativo de DuckDB entre dimensiones numéricas y la métrica objetivofinal_answer con: dimensión principal que explica el cambio, % de contribución, hipótesis causal, acciones sugeridasNULLIF en divisiones para evitar division by zeroSequence cleaning steps in a chain — trim/case/replace, null handling, deduplication, and type casting — in the right order. Use when raw ingested data needs cleaning before joins or aggregation.
Place Assert and Schema Validation nodes as gates that halt a chain when data is wrong, so bad data never reaches the output. Use when the pipeline must guarantee correctness before exporting or loading downstream.
Choose the right sink format, compression, and destination for a chain's output, and decide between exporting a file vs creating a table. Use at the end of a pipeline when deciding how to persist results.
Best practices for loading files into a chain — single file, folder globs, type detection, and union of many files. Use when the pipeline starts from CSV/Parquet/JSON/Excel files or a folder of files.
Decide between Merge (stack rows / UNION) and Join (match on a key) when a chain has multiple inputs, and set keys and join type correctly. Use when a pipeline combines two or more upstream tables.
Descompone un objetivo de procesamiento en un flujo de nodos Chains (source → transform → sink). Use when the user wants to build a data pipeline / chain, or describes an end-to-end "load X, clean it, summarize, export" goal.