What is the Key Metric Driver Analysis?

The Key Metric Driver Analysis helps you answer a simple question: what is most likely driving your KPI? It ranks the metrics connected to that outcome by how much they explain changes over time — so you can focus on the few levers that matter most.

This is not a guarantee of causation. It’s decision-support: a transparent, evidence-based view of relative leverage that you can validate with domain knowledge and experiments.

What Value It Gives

• Faster diagnosis – When your KPI moves, quickly see which upstream metrics moved with it and which ones likely mattered most.
• Higher-leverage planning – Target the drivers that actually explain KPI movement, not the metrics that are just easy to improve.
• Clearer alignment – Turn “we think X matters” into a shared, data-backed narrative your team can rally around.
• Better bets – Use drivers to choose initiatives that move the right levers, then validate with experiments and measurement.
• Confidence guardrails – Use fit and significance signals to know when results are strong vs. mostly directional.

Common Use Cases

• Your KPI changed and you need answers – Identify which drivers most strongly explain the movement and whether the direction matches what you expected.
• You’re prioritising initiatives – Choose bets aimed at the tier‑1 drivers, then use contribution + direction to decide where to start.
• A metric “feels important” but you’re not sure – See whether it still matters once other metrics are considered (some drivers disappear when you control for the rest).
• You suspect delays – Check which drivers lead the KPI (e.g., pipeline today affects revenue weeks later) so you set the right expectations on timing.
• You want a KPI tree, not a flat list – Trace impact pathways across intermediate metrics to find bottlenecks between effort and outcome.
• You need to explain performance – Create a clearer narrative for stakeholders: what moved, what likely drove it, and what you’ll do next.

How Drivers Are Ranked

Segflow fits a statistical model that explains your KPI using all candidate drivers at the same time, then turns that model into an easy-to-act-on ranking.

Under the hood (methodology)

1. Prepare and normalise the data Segflow validates that your KPI and driver time series have matching lengths and standardises values so different scales don’t distort results. Note: Series must be pre-aligned before analysis (same dates, same length).

2. (Optional) Test delayed effects
   If lag analysis is enabled, Segflow adds lagged versions of drivers (e.g., signups_lag2) to capture “driver moves first, KPI moves later.”

3. Fit a multivariate model
   Segflow uses regression to estimate each driver’s relationship with the KPI while controlling for the other drivers. This helps separate “true leverage” from “it just moved at the same time” — and explains why a driver can correlate with the KPI but still rank lower once overlap is accounted for.

4. Turn the model into a ranking

   • Contribution (%): Segflow decomposes the model into a percentage contribution per driver based on absolute contributions to predicted values. Percentages are normalised across drivers plus baseline (intercept), so sum(driver %) + baseline % = 100%. This shows each driver’s relative importance in the model’s predictions. Note: Under high collinearity, contributions may be less stable—check the multicollinearity warnings.
   • Direction: The sign (positive/negative) comes from the regression coefficient.

5. Attach evidence and guardrails

   • R-squared: How much of the KPI’s movement is explained by the full driver set.
   • p-values: Whether each driver’s relationship is statistically distinguishable from noise (smaller = higher confidence).
   • Multicollinearity checks: When drivers overlap heavily, the model flags it because rankings can become less stable.

6. Tier the list for focus
   Drivers are sorted by contribution and bucketed into tiers so you can move from analysis to action quickly (tier 1 is the top ~25% by contribution; tier 3 is the bottom ~25%).

Interpreting the driver table

If you’re familiar with experiments, think of each driver row as having two primary attributes: “how big” and “how confident.”

• Contribution = how big the driver is (relative leverage within this model)
• p-value = how confident the signal is. The model provides two p-values:
  • coefficientPValue (recommended) = significance controlling for other drivers in the model
  • correlationPValue = significance of the bivariate correlation (does not control for other drivers)
  • Fallback behavior: The human-readable significance label uses coefficientPValue when available. When coefficientPValue is NaN (e.g., multicollinearity), it falls back to correlationPValue. For precise control, use the raw p-value fields directly.

Then use direction to understand whether raising that driver is expected to raise or lower the KPI.

• directionReliable = false when direction should not be trusted:
  • Model used equal-share fallback (degenerate, degenerate_contributions warning)
  • Model has negative R² (model_worse_than_mean warning)
  • Coefficient p-value is NaN (multicollinearity warning — coefficients are unreliable) When unreliable, treat direction with caution — it may have defaulted to “positive”.

Example: Diagnosing a Subscription Revenue Slowdown (Illustrative)

Scenario: Weekly subscription revenue has flattened over the last two months. The team assumes it’s an acquisition problem — but wants to verify before scaling spend.

How you’d use Key Metric Driver Analysis:

1. Set the KPI to weekly subscription revenue.
2. Add candidate drivers connected to that outcome on your Board (for example: trials started, activation rate, upgrade rate, churn rate).
3. Run the analysis over the same time window.

What you might learn:

• Churn rate shows up as the top tier driver with a negative direction and strong confidence → the biggest lever is reducing leakage, not adding more volume at the top.
• Activation rate is a meaningful positive driver → improving onboarding can lift revenue, often with a delay.
• Trials started correlates with revenue, but looks weak once other drivers are controlled for → scaling acquisition may not fix the underlying constraint.

What you do next:

• Prioritise a retention bet (e.g., fix cancellation reasons, improve early product value, win-back flows), then use Bet Impact Analysis to sequence the highest ROI options.
• Use lag insights to set expectations (e.g., activation improvements may show in revenue a few weeks later).
• Re-run Driver Analysis after shipping to confirm the ranking and contributions changed the way you expected.

What You Provide

Required Inputs

• Primary KPI – The outcome you want to understand or improve.
• Candidate drivers – Metrics you believe influence the KPI (often the metrics connected to the KPI on your Board).
• Historical data – A consistent time series for the KPI and each driver (same cadence and enough history to detect patterns).

Optional Inputs (Advanced)

• Lag analysis – Test delayed effects and identify likely lead times.
  • Note: lagPeriods and metricsToLag must not contain duplicates—the model will throw an error if duplicates are detected.
• Stability analysis – Rolling window analysis to see if drivers are durable or shifting over time.
  • Note: Lag and stability analysis require sufficient history (at least 4-5 data points after any lag trimming). On short series, these features may be unavailable—the analysis will still return core rankings with a warning.
• Value chain mapping – Trace impact pathways across intermediate metrics to find bottlenecks.
• Scenario forecasting – Project how overall model fit (R²) may evolve under optimistic/neutral/pessimistic assumptions, based on KPI trend and seasonality. Note: This forecasts aggregate explanatory power, not per-driver relationship strength.

What You Get Back

Core Outputs

• Driver ranking – A ranked list with tiers (tier 1/2/3) so you can quickly see which metrics are the most likely levers.
  • Lagged variants: When lag analysis is enabled, lagged versions appear as separate drivers (e.g., signups, signups_lag1, signups_lag2). To see one row per base metric, use aggregateRankingsByBaseMetric() which keeps the highest-contributing variant for each base metric.
• Contribution breakdown – How much each driver explains the KPI’s movement relative to the others (useful for deciding where focus will have the biggest payoff).
• Direction of impact – Whether the relationship tends to be positive or negative, so you know if improving the driver should raise or lower the KPI.
• Evidence strength – Model fit (R-squared) plus statistical signals (p-values) and diagnostics (like multicollinearity) to help you judge confidence.

Optional Outputs

• Lag insights – Which drivers lead the KPI and the estimated lag period. Important caveats:
  • optimalLags applies a default significance threshold (p-value ≤ 0.1). Metrics with higher p-values are typically omitted.
  • Fallback behavior: When coefficient p-values are unavailable or NaN (e.g., multicollinearity), the threshold is skipped and lags are selected by correlation only. Check for lag_selection_gating_skipped warnings to identify these cases.
  • When present, use optimalLags[metric].pValue for additional post-filtering (e.g., stricter threshold of 0.05).
  • Check laggedCorrelations for the full set of lag correlations if you need to see all lags regardless of significance.
  • Auto-skip behavior: If you limit lag analysis to specific drivers via metricsToLag, any invalid or missing driver names are automatically skipped. Check lag_metrics_missing or lag_metrics_filtered warnings if expected lags are absent.
• Stability metrics – Rolling-window statistics showing how consistently a driver stays important over time:
  • Raw metrics (on stabilityMetrics): meanContribution, stdContribution, coefficientOfVariation (std/mean, lower = more stable; may be NaN if mean ≤ 0), and rankVariance. These are raw statistical values useful for detailed analysis.
  • Normalized score (on driverRankings[].stability): A 0–1 score where higher = more stable. Uses log-scale transformation: 1 - log1p(CV) / log1p(10). A CV of 1 maps to ~0.71 stability; CV of 10 maps to ~0.
  • Top drivers per window: Rolling window analysis reports the top 3 drivers per window (fixed limit).
  • Partial results: If some rolling windows fail (e.g., insufficient variance), stability is computed from successful windows only. Check for stability_partial warnings when stability scores seem unexpected.
• Value chain view – Critical paths, bottlenecks, and recommendations across connected metrics. When multivariate impact mode is enabled, confidence values use correlation magnitude (bounded 0–1) while impact prioritization uses coefficient magnitude.
  • Default filtering: Edges are filtered by minConfidence=0.8 (minimum absolute correlation). Edges below this threshold are pruned, so missing chains may indicate “below threshold” rather than “no relationship”. Tune minConfidence, significanceThreshold, or minCoefficientMagnitude options to adjust sensitivity.
  • Note: directImpact and totalImpact are clamped to [0, 1] for UI consistency. Use the rawImpact field (unclamped) when you need to sort/order chains by true coefficient magnitude, especially when coefficients exceed 1.
  • Note: expectedImpact in recommendations uses rawImpact (unclamped) for consistency with priority ordering. Values may exceed 1 when coefficients are large. If you need bounded values for UI display, clamp to [0, 1].
• Forecast + confidence bands – Projects overall model fit (R²) evolution with uncertainty intervals.
  • Note: This forecasts explanatory power of the driver set, not individual driver contributions. For per-driver evolution, use stability metrics from rolling window analysis.
  • Clamping: currentImpact and forecastedImpact are clamped to [0, 1]. A value of 0 may mean either “no effect” or “model worse than mean” (negative R²). Check for model_worse_than_mean or forecast_clamped warnings to distinguish these cases.
  • Flat forecasts: KPIs that hover around zero (e.g., net-change or delta metrics) may produce flat-looking forecasts due to trend slope being forced to zero. Check for zero_mean_trend_suppression warnings—consider using absolute values or domain-specific normalization for delta metrics.
  • Note: The trend.confidence field is currently a fixed placeholder (0.95) and does not reflect actual trend reliability.

How to Interpret Results

• Start with tiers, then zoom in – Use tier 1 to pick focus areas, then use contribution, direction, and evidence to choose the lever.
• Treat it as a map, not a mandate – The top driver is a strong candidate for attention, not automatic causation.
• Read direction with intent – A “top driver” can be negative (e.g., churn rising explains revenue falling).
• Contribution is relative – Use it to choose focus areas within the same KPI and time window.
• Watch for overlap – Highly correlated drivers can share contribution; avoid double-counting.
• Use lag to set expectations – If a driver leads the KPI by weeks, don’t expect immediate movement.
• Use R-squared as coverage – A higher value means this driver set explains more of the KPI’s movement; a low value often means you’re missing a key driver or the relationship changed.
• Stability tells you “durable vs. situational” – Stable drivers are good long-term bets; unstable drivers often reflect campaigns, seasonality, or temporary dynamics.
• Beware of trending metrics – The model does not detrend or adjust for seasonality before regression. Metrics that trend together may show inflated correlations even without a causal link. Cross-check with domain knowledge and consider whether a common trend (e.g., growth, seasonality) explains the relationship.
• R² may be optimistic with many lags – Adding lag features increases model complexity. The model does not currently provide holdout/cross-validated R², so high R² with many lags may reflect overfitting rather than true explanatory power.

Best Practices

• Start with drivers that have a real causal story, then let the model test the data.
• Keep the candidate set tight (5–10) and avoid near-duplicate metrics.
• Use a clean time window; exclude periods with major tracking breaks.
• Re-run periodically — drivers shift as products, markets, and tactics change.
• Pair with Bet Impact Analysis: identify levers here, then prioritise the bets that move them efficiently.

Summary

The Key Metric Driver Analysis turns a messy metric set into a clearer hierarchy of leverage. Use it to diagnose KPI movement, focus on the right levers, and align the team around what most likely drives outcomes. Then convert those insights into action: pick a tier‑1 lever, design a bet or experiment, and re-run the analysis to learn what actually changed.