Beyond the Dashboard: Using State-Space Models to Track Regime Changes in User Behavior

1. Introduction: Beyond the Dashboard's Rearview Mirror

Most analytics dashboards are, at their core, historical summaries. They show what happened—page views, session durations, conversion rates—but they rarely explain why those metrics shifted, and they almost never anticipate the next turning point. For teams tasked with understanding user behavior, this creates a persistent blind spot: the dashboard confirms a regime change only after it has fully materialized, leaving product and engineering teams reacting to consequences rather than steering through transitions. This guide argues that state-space models (SSMs) offer a more principled path forward, enabling teams to track latent behavioral regimes in near real-time and adapt strategies before a shift becomes a crisis. The framing is deliberately advanced, assuming familiarity with time-series concepts and a willingness to move beyond plug-and-play analytics tools. We focus on practical implementation trade-offs, not idealized textbook solutions, and we avoid inventing faux academic studies to bolster credibility. Instead, we draw on common patterns observed across product analytics contexts, from subscription platforms to marketplace applications. The goal is to give you a decision framework for when and how to deploy SSMs for regime detection, along with concrete steps to avoid the most frequent implementation failures. This overview reflects widely shared professional practices as of May 2026; verify critical details against current official guidance where applicable.

Why Dashboards Fail at Regime Detection

Dashboards excel at monitoring known metrics, but they are inherently backward-looking. A sudden drop in daily active users (DAU) might appear on Monday morning, but the dashboard cannot distinguish between a normal weekly fluctuation and the start of a structural decline until several data points confirm the pattern. By that time, the regime has already shifted. The underlying problem is that dashboards treat each data point as independent, ignoring the latent state that generates observed behavior. Regime changes—such as a permanent shift in user engagement after a feature release or a temporary spike due to a marketing campaign—are not directly observable; they must be inferred from noisy measurements. State-space models address this by explicitly modeling the hidden process (the regime) and the observation process (the metrics), allowing for probabilistic inference about when a change is occurring. This is not a new technique—SSMs have been used in econometrics and control theory for decades—but their application to user behavior analytics is still underutilized in practice. Teams often default to simpler heuristics like moving averages or change-point detection, which can work for clear, abrupt shifts but fail for gradual or subtle transitions. The result is a reactive analytics culture where decisions lag behind reality.

What This Guide Covers and What It Does Not

This guide is not a beginner's tutorial on state-space models. We assume you are familiar with concepts like Kalman filters, hidden Markov models, and likelihood estimation. Instead, we focus on the strategic and practical considerations for applying SSMs to user behavior regime detection: model selection, parameter tuning, handling non-stationarity, and integrating results into decision workflows. We compare three common approaches—linear Gaussian SSMs, Markov-switching models, and dynamic linear models with stochastic volatility—using a structured table for clarity. We then walk through two anonymized scenarios: a subscription platform experiencing an engagement decline and an e-commerce site dealing with disrupted seasonal patterns. Each scenario includes concrete implementation steps, common failure modes, and how to interpret outputs. The guide concludes with an FAQ addressing concerns about model complexity, data requirements, and team adoption. Throughout, we emphasize that SSMs are a tool, not a replacement for domain expertise; they require thoughtful calibration and ongoing validation. The aim is to help experienced practitioners decide whether this approach fits their context and, if so, how to implement it without falling into common traps like overfitting or ignoring model assumptions.

Who Should Read This

This article is written for data scientists, product analysts, and engineering leads who have hit the limits of dashboard-based analytics and want a more rigorous method for detecting behavioral shifts. If you have ever looked at a flat line on a dashboard and wondered whether it signals stability or a brewing problem, this guide is for you. We assume you have working knowledge of time-series analysis and some experience with probabilistic models, but we avoid unnecessary mathematical notation in favor of conceptual explanations and decision heuristics. The scenarios are drawn from common product contexts, but the principles apply broadly to any domain where user behavior is measured over time—from SaaS platforms to content sites to marketplaces. If you are new to state-space models entirely, we recommend starting with a focused tutorial on Kalman filters before diving into this discussion. The value here is in the trade-offs and implementation details that textbooks often gloss over, informed by patterns observed across multiple teams and projects.

2. Core Concepts: What Are Regime Changes and Why SSMs Work

At its simplest, a regime change is a structural shift in the underlying process that generates observed user behavior. Consider a subscription service that has maintained a steady 5% month-over-month churn rate for two years. Suddenly, churn rises to 8% and stays there. That is a regime change. But regime changes are rarely so clean: they can be gradual, temporary, or mixed with noise. A feature rollout might improve retention for power users while decreasing it for casual users, creating a heterogeneous shift that a single metric cannot capture. The key insight is that regime changes happen at a latent level—the unobserved state of user engagement, satisfaction, or intent—and manifest only indirectly through observable metrics like logins, purchases, or support tickets. Traditional dashboards conflate the latent state with the noise, leading to false alarms or missed signals. State-space models solve this by explicitly separating the latent process (the state equation) from the measurement process (the observation equation). The state evolves over time according to a transition model, and observations are generated from the state plus random noise. By applying filtering algorithms—most famously the Kalman filter for linear Gaussian systems—practitioners can estimate the current state and detect when it deviates from expected patterns. This is not a theoretical curiosity; it is a practical framework that has been validated across industries, from finance to robotics, and is now increasingly relevant for user behavior analytics.

The Latent State: Why You Cannot See Regime Changes Directly

User behavior is inherently noisy. A single day's drop in engagement could be due to a holiday, a server outage, or a genuine shift in user preferences. Without a model of the underlying state, you cannot distinguish between these causes. The latent state represents the "true" level of user engagement, free from transient fluctuations. In a state-space model, you define how this state evolves—for example, as a random walk with drift, or as a mean-reverting process—and how it relates to the observations. The filtering step recursively updates your belief about the state as new data arrives, producing a probability distribution over possible states at each time point. This distribution is the key to regime detection: when the estimated state moves outside a confidence interval, or when the model's prediction errors grow systematically, you have evidence of a regime change. The advantage over simpler methods is that you are not just looking at the raw metric; you are isolating the signal from the noise. For example, if you model daily active users as a noisy observation of a latent "engagement state," a Kalman filter will smooth out random daily fluctuations and only signal a regime change when the underlying state shifts persistently. This reduces false positives and allows earlier detection of gradual trends. The trade-off is that you must specify the model structure—the form of the state transition and observation equations—which requires domain knowledge and careful validation.

Why Traditional Methods Fall Short

Common alternatives to SSMs include moving averages, exponential smoothing, change-point detection algorithms (like PELT or binary segmentation), and anomaly detection based on static thresholds. Each has its place, but each also has limitations for regime detection. Moving averages and exponential smoothing are easy to implement but lag behind the true state, especially for abrupt changes. They also assume a constant underlying process, which is exactly what you are trying to question. Change-point detection algorithms are designed to find points where the statistical properties of a sequence change, but they typically operate retrospectively, requiring a window of data to confirm a shift. This makes them unsuitable for real-time monitoring, which is often critical for product decisions. Static threshold methods are the simplest but also the most brittle: they generate alerts for any spike or drop, regardless of context, leading to high false-positive rates. SSMs address these shortcomings by providing a real-time, probabilistic estimate of the latent state, along with a measure of uncertainty. They can handle missing data, irregular time intervals, and multiple observation streams simultaneously. They also allow for forecasting: once you have estimated the current state, you can project it forward to anticipate where metrics are heading, giving you lead time to intervene. The cost is increased complexity—in model specification, parameter estimation, and computational overhead—but for teams dealing with high-stakes user behavior shifts, the investment often pays off.

When to Use SSMs vs. Simpler Approaches

Not every analytics problem requires a state-space model. If your user behavior is stable and you only need to detect large, abrupt changes, a simple threshold-based alert system may suffice. SSMs are most valuable when behavior exhibits gradual trends, seasonal patterns, or multiple interacting factors—what economists call "structural breaks" and what product teams call "the new normal." They are also useful when you have multiple correlated metrics and want to infer a single latent driver (e.g., "overall user sentiment" from clicks, time on site, and support interactions). In the scenarios that follow, we apply SSMs to two common but distinct regime-change problems: a sudden engagement drop in a subscription platform and a seasonal pattern disruption in an e-commerce site. In both cases, simpler methods would either miss the shift or generate too many false alarms. The SSMs, by contrast, provide a clear signal with quantified uncertainty, enabling more confident decision-making. However, we also acknowledge the limitations: SSMs require careful tuning, can be sensitive to model misspecification, and demand more computational resources than simple heuristics. We provide decision criteria in the next section to help you evaluate whether SSMs are the right fit for your context.

3. Comparing Approaches: Three State-Space Model Families for Regime Detection

Choosing the right state-space model family depends on the nature of the regime changes you expect, the data available, and the operational constraints of your team. We compare three common families: linear Gaussian state-space models (LGM), Markov-switching models (MSM), and dynamic linear models with stochastic volatility (DLM-SV). Each has distinct strengths and weaknesses. LGMs are the simplest and most computationally efficient, assuming that both the state transition and observation equations are linear with Gaussian noise. They work well for gradual trends and seasonal patterns but struggle with abrupt regime changes or non-Gaussian noise. MSMs explicitly model regime changes as discrete shifts between a finite number of states, each with its own dynamics. They are ideal for detecting abrupt, categorical transitions—like a product going from "growth" to "maturity" phase—but require specifying the number of regimes in advance and can be computationally intensive. DLMs with SV extend the basic DLM framework to allow the observation noise variance to change over time, capturing periods of increased volatility that may precede a regime change. This is useful for early warning systems, where you want to detect uncertainty before a shift occurs. In practice, many teams start with an LGM and layer on complexity as needed, but the right choice depends on your specific signal structure. The table below summarizes the trade-offs.

Decision Criteria for Model Selection

When deciding among these families, start by asking: What does a regime change look like in your domain? If you expect gradual shifts—like slowly declining engagement after a competitor launch—an LGM with a random walk state transition is often sufficient. If you expect discrete, abrupt changes—like a sudden drop after a pricing change—an MSM with two or three regimes may be more appropriate. If you are unsure and want to detect both gradual and abrupt changes, consider a DLM with time-varying parameters that can adapt to different regimes without assuming a fixed number. Another important factor is data volume and frequency. LGMs scale easily to high-frequency data (e.g., hourly metrics for millions of users), while MSMs and DLMs with stochastic volatility can become computationally prohibitive for large datasets without careful optimization. Finally, consider interpretability needs. If your team will act on the model outputs directly, simpler models with clear state estimates (like LGMs) are easier to explain and trust. More complex models like DLMs with SV may produce better forecasts but at the cost of transparency. We recommend starting with the simplest model that captures the essential dynamics and adding complexity only when validation shows that simpler models miss important shifts. This iterative approach reduces the risk of overfitting and makes it easier to diagnose failures.

Common Pitfalls in Model Selection

One frequent mistake is assuming that a more complex model is always better. In practice, simpler models often outperform on out-of-sample prediction because they avoid overfitting to noise. Another pitfall is ignoring model diagnostics: after fitting an SSM, you must check whether the residuals (prediction errors) are white noise and whether the estimated state evolves as expected. If residuals show autocorrelation or heteroscedasticity, the model is misspecified and regime detections will be unreliable. A third pitfall is failing to account for non-stationarity in the observation process. User behavior metrics often have trends, seasonality, and day-of-week effects that must be modeled explicitly; otherwise, the state estimate will conflate these known patterns with genuine regime changes. For example, if you model raw daily active users without removing weekly seasonality, the model will detect a "regime change" every Monday. The solution is to include seasonal components in the state vector or to pre-process the data with deseasonalization. We cover specific implementation steps in the next section.

4. Step-by-Step Guide: Implementing a State-Space Model for Regime Detection

Implementing an SSM for user behavior regime detection involves five major steps: problem framing, model specification, parameter estimation, filtering and smoothing, and regime identification. Each step requires careful judgment; skipping or rushing any of them leads to unreliable results. We outline the process here using a generic workflow, then illustrate with specific scenarios in the following section. The workflow assumes you have a time series of user behavior metrics (e.g., daily active users, session duration, conversion rate) and a clear question: Is the underlying behavior regime stable, or is it shifting? The output is a probabilistic estimate of the current regime and a forecast of where it is heading. We focus on the Kalman filter for linear Gaussian models, but the principles extend to other families with appropriate modifications. We also emphasize the importance of validation and iteration: your first model will almost certainly be wrong, and the goal is to refine it based on diagnostic checks and domain feedback.

Step 1: Problem Framing and Metric Selection

Before writing any code, define what constitutes a regime change in your context. Is it a shift in the mean level of a metric? A change in the trend (slope)? A change in variability? Different regime types require different model structures. For example, a shift in mean is captured by a random walk state, while a shift in trend requires a local linear trend model with two states (level and slope). Also, decide whether you want to model a single metric or multiple metrics jointly. Joint modeling can be more powerful—e.g., using both login frequency and purchase rate to infer a latent "engagement state"—but it increases complexity and requires specifying how the metrics relate to the latent state. A good starting point is to model one key metric that is most sensitive to behavior changes, then expand to multivariate models if needed. Document your assumptions explicitly: what is the latent state, how does it evolve, and what noise sources affect observations? This documentation will guide model specification and help communicate results to stakeholders.

Step 2: Model Specification and State Vector Design

The state vector contains all the latent variables that evolve over time. For a simple local level model, the state is just the true mean of the metric, which follows a random walk. For a local linear trend model, the state includes both the level and the growth rate, with the growth rate itself following a random walk. For seasonal patterns, add seasonal components (e.g., 7 dummies for day-of-week effects). The observation equation maps the state to the observed metric, typically as a linear combination plus Gaussian noise. The transition equation describes how the state evolves, usually as a linear transformation plus process noise. Specify the covariance matrices for both the process noise (how much the state can change each time step) and the observation noise (how noisy the measurements are). These covariance parameters are often unknown and must be estimated from data. A common approach is to treat them as hyperparameters and estimate them via maximum likelihood or Bayesian methods. In practice, the process noise variance is the most critical parameter: too large, and the model will overreact to noise; too small, and it will miss genuine regime changes. Start with reasonable initial guesses based on historical variance and iterate.

Step 3: Parameter Estimation and Validation

With the model structure defined, estimate the unknown parameters (covariance matrices, initial state, and any additional coefficients) using a training period of historical data. For linear Gaussian models, maximum likelihood via the Kalman filter is efficient and widely implemented in Python (statsmodels, pykalman) and R (dlm, KFAS). For Markov-switching models, the EM algorithm or MCMC is typically required. After fitting, validate the model on a holdout period to check that the residuals are white noise (no autocorrelation, constant variance) and that the state estimates are sensible. If residuals show patterns, revisit the model structure: add missing components (e.g., seasonality, day-of-week effects) or transform the data (e.g., log-transform metrics that are strictly positive). Also, check whether the estimated state aligns with known events: for example, if you know a major feature launch occurred in the training period, the state should show a corresponding shift. If it does not, the model may be too rigid or the process noise too small. This validation step is iterative; expect to go through several cycles before the model is reliable enough for production use.

Step 4: Filtering, Smoothing, and Regime Identification

Once the model is fitted, apply the Kalman filter to the entire time series (or to new data in real time) to obtain filtered state estimates—the current belief about the state given all observations up to that time. For retrospective analysis, apply the Kalman smoother, which uses all observations (past and future) to estimate the state at each time point. The filtered estimates are used for real-time regime detection, while the smoothed estimates are better for identifying when a regime change started historically. To identify regime changes, define a decision rule based on the state estimate and its uncertainty. A common rule is to flag a regime change when the state estimate moves outside a confidence interval (e.g., 95% credible interval) for a sustained period (e.g., three consecutive time points). Alternatively, monitor the prediction errors: if the model consistently under- or over-predicts the observed metric, that is evidence of a regime change. Some practitioners use a cumulative sum (CUSUM) of the standardized prediction errors, which is sensitive to small persistent shifts. The choice of rule depends on your tolerance for false positives versus false negatives. We recommend testing multiple rules on historical data with known regime changes to calibrate sensitivity.

Step 5: Integration into Decision Workflows

The final step is to integrate the regime detection output into your team's decision process. This is often the hardest part, as it requires translating probabilistic signals into actionable alerts. Design a dashboard (ironically) that shows the estimated state and its uncertainty, along with the regime status (stable, shifting, or uncertain). When a regime change is detected, trigger a predefined response: e.g., notify the product team, run an A/B test to diagnose the cause, or adjust forecasting models. It is crucial to set expectations that the model will have false positives and false negatives—no model is perfect—and to build in feedback loops where teams can flag incorrect detections for model refinement. Also, plan for periodic model retraining: user behavior patterns evolve over years, and a model that works today may need recalibration after a major product change. We recommend retraining the model monthly or quarterly, or whenever a confirmed regime change occurs, to keep the parameters aligned with the current dynamics.

5. Real-World Scenario 1: Subscription Platform Engagement Decline

Consider a subscription-based SaaS platform that provides project management tools. The team tracks daily active users (DAU) as a key health metric. For two years, DAU has followed a stable pattern: steady growth during weekdays, dips on weekends, and a slight upward trend overall. In March, DAU starts declining. The dashboard shows the drop, but the team cannot tell if it is a temporary blip due to a holiday or a structural shift. They decide to implement an LGM with a local linear trend and day-of-week seasonal components. The state vector includes the true DAU level, the growth rate, and seven seasonal factors. They fit the model on two years of historical data using maximum likelihood, then run the Kalman filter on new data in real time. Within two weeks, the model's state estimate shows a clear downward shift in the level component, and the growth rate turns negative for the first time. The 95% confidence interval for the level does not overlap with the pre-March range. The team flags a regime change and initiates an investigation. They discover that a competitor launched a similar product with a lower price point, causing a slow but steady exodus of price-sensitive users. The SSM detected the shift three weeks before the competitor's impact became visible in revenue metrics, giving the team time to launch a retention campaign and adjust pricing.

Implementation Details and Diagnostic Checks

In this scenario, the team used the Python library statsmodels' UnobservedComponents class, which implements LGMs with trend and seasonal components. They set the trend to "local linear trend" and the seasonal to 7 periods. The initial parameters were estimated using maximum likelihood with the L-BFGS-B optimizer. After fitting, they checked the residuals for autocorrelation using the Ljung-Box test; the p-value was 0.23, indicating no significant autocorrelation. They also computed the one-step-ahead prediction errors and confirmed they were approximately normally distributed with constant variance. The state estimate for the level component showed a clear inflection point around March 10, which aligned with the competitor's launch date (confirmed later through external data). The team also tested a simpler model with only a random walk level (no trend), but the residuals showed a systematic pattern, indicating that the trend component was necessary. This diagnostic process is typical: start simple, check residuals, add complexity only when needed. The team also validated the model on a holdout period from the previous year to ensure that the detected regime change was not a false positive caused by model misspecification.

Lessons Learned and Common Mistakes

One mistake the team avoided was overreacting to short-term fluctuations. The filtered state estimate initially dipped in the first week of March, then recovered slightly, which could have triggered a false alarm if they had used a naive threshold on the raw DAU. The SSM's uncertainty quantification helped them wait for a sustained shift before acting. Another lesson was the importance of seasonal components: without them, the model would have flagged every Monday as a potential regime change. The team also learned that the model's growth rate component was a leading indicator: it turned negative a full week before the level component crossed the confidence boundary. They now monitor both the level and growth rate for early warnings. A common mistake they avoided was setting the process noise variance too high, which would have made the model react to every random fluctuation. They used cross-validation to tune this parameter, selecting the value that minimized one-step-ahead prediction error on a validation set. Finally, they set up an automated retraining pipeline that re-estimates parameters every month, ensuring the model stays calibrated as user behavior evolves.

6. Real-World Scenario 2: E-Commerce Seasonal Pattern Disruption

An e-commerce platform specializing in outdoor gear experiences strong seasonal patterns: sales peak in summer and winter holiday periods, with troughs in spring and fall. The analytics team uses a DLM with stochastic volatility to monitor daily conversion rates, because they have observed that periods of high volatility often precede shifts in the baseline conversion rate. In October, the model detects a sudden increase in the estimated observation noise variance—the stochastic volatility component spikes. At the same time, the filtered state estimate for the conversion rate shows a slight upward trend, but within the historical range. The team is alerted to increased uncertainty, not a regime change in the mean. They investigate and find that a new feature—a personalized recommendation engine—was rolled out gradually, causing heterogeneous effects: some user segments saw higher conversion, while others were confused and converted less. The net effect on the mean was small, but the variance increased significantly. The team uses the volatility signal to decide to bucket users by treatment and run a deeper analysis, ultimately discovering that the feature improves conversion for logged-in users but decreases it for anonymous users. They adjust the rollout strategy accordingly. Without the stochastic volatility component, they would have missed this early warning and discovered the negative impact only after a full rollout.

Why Stochastic Volatility Matters for Regime Detection

This scenario illustrates a key insight: regime changes are not always about shifts in the mean. Sometimes the first sign of a structural change is increased dispersion—users reacting differently to a change, or external factors creating noise. Traditional SSMs that assume constant observation variance will attribute increased volatility to state changes, leading to spurious regime detections. By modeling the volatility as a separate latent process, the DLM-SV framework can distinguish between a shift in the underlying state and a temporary increase in uncertainty. In this case, the volatility spike was the early warning, and the team used it to investigate before a mean shift occurred. The trade-off is increased complexity: estimating both the state and the volatility jointly requires more data and computational resources. For high-frequency metrics (e.g., hourly data), particle filters or approximate Bayesian computation may be necessary. However, for daily or weekly data, MCMC methods (e.g., Stan or PyMC) are feasible and well-documented. The team in this scenario used a DLM with a stochastic volatility component implemented in PyMC, fitting the model on 18 months of daily data. They used a Student-t observation distribution to handle outliers, which improved robustness.

Operationalizing the Volatility Signal

One challenge the team faced was interpreting the volatility signal: when does increased variance warrant action? They set a threshold based on the 95th percentile of the historical volatility distribution; any spike above that threshold triggers a review. They also required that the spike persist for at least three consecutive days to reduce false positives from one-day anomalies. This rule caught the recommendation engine rollout but ignored a Black Friday surge that was expected and had no impact on subsequent behavior. The team also built a simple dashboard that showed the state estimate, the volatility estimate, and a "volatility status" indicator (normal, elevated, high). Product managers were trained to interpret the indicator not as a crisis signal but as a prompt to investigate potential heterogeneity. This approach de-risked the model's complexity by keeping the output simple and actionable. Over time, the team found that volatility spikes often preceded mean shifts by one to three weeks, giving them a valuable early warning system. They now use the volatility signal as a trigger for deeper analysis, rather than as a direct action signal.

7. Common Questions and Practical Concerns (FAQ)

Teams considering state-space models for regime detection often raise similar concerns. We address the most common ones here, based on patterns observed across multiple implementations. These answers are not exhaustive, but they provide a starting point for evaluating whether SSMs fit your context. The key theme is that SSMs are powerful but require thoughtful implementation; they are not a magic bullet for every analytics problem. If you find yourself struggling with model complexity, consider starting with a simpler approach and layering on SSM components only where simpler methods fail. The FAQ is organized by theme: model complexity, data requirements, interpretability, and operational concerns.

Q1: How much data do I need to fit a state-space model reliably?

The amount of data depends on the model complexity and the signal-to-noise ratio. For a simple local level model with one latent state, a few hundred time points (e.g., one year of daily data) is usually sufficient to estimate the variance parameters reliably. For models with multiple components (trend, seasonality, volatility), more data is needed—typically two to three years of daily observations. The key is that you need enough data to estimate the covariance matrices and to validate the model on a holdout period. If you have fewer than 100 time points, simpler methods like exponential smoothing may be more appropriate. Also, the frequency matters: hourly data requires more points but also contains more noise; daily data is often a good balance for user behavior metrics. A common heuristic is to have at least 10 times as many time points as the number of unknown parameters in the model. For a local linear trend with seasonal dummies (say 10 parameters), aim for at least 100 observations.

Q2: How do I handle missing data or irregular time intervals?

State-space models naturally handle missing data: the Kalman filter simply skips the update step when an observation is missing, using the state prediction as the new estimate. This is a major advantage over methods that require complete time series. For irregular time intervals, you need to adjust the state transition matrix to account for the time gap. In a continuous-time formulation, this is straightforward: the state evolves according to a differential equation, and the transition matrix depends on the time step. In practice, many implementations (like statsmodels' UnobservedComponents) assume evenly spaced data, so you may need to resample to a regular frequency (e.g., daily) and treat missing values as missing. If the gaps are large (e.g., multiple weeks), consider a continuous-time model or a Bayesian approach in Stan or PyMC that explicitly models the irregular intervals.

Q3: How do I interpret the state estimate to stakeholders who are not data scientists?

This is a common challenge. The state estimate itself is a latent variable with no natural units, so presenting it directly can be confusing. A better approach is to transform the state estimate back into the metric space: for example, show the "smoothed DAU" (the observation predicted by the state) alongside the raw DAU, and highlight when the smoothed estimate deviates from historical ranges. Another approach is to present a regime indicator (e.g., green/yellow/red) based on the state estimate's distance from its historical mean, with a clear explanation of what each color means. Avoid showing confidence intervals directly to non-technical stakeholders; instead, use language like "we are 95% confident that the true engagement level has dropped below the normal range." Provide a one-page summary of how the model works