Modeling Bitcoin volatility with a Markov-switching model

Aethan Lee — Mon, 14 Sep 2026 17:22:37 +0000

A Bitcoin price chart shows the path prices took. For this report, I wanted to estimate how the volatility of daily returns changed along that path.

I used a Markov-switching model and built the visual report in OWL Compose. The report includes state probabilities, a transition matrix and a comparison between two-state and three-state specifications.

Explore the full report.

Start with returns and a fixed cutoff

The input is Binance Spot BTCUSDT daily OHLCV data, using completed UTC candles through September 13, 2026. Daily returns are calculated as:

100 * ln(close_today / close_yesterday)

I kept weekends and excluded the incomplete daily candle. The training period runs from January 2, 2022 through June 30, 2026: 1,641 daily returns. The holdout contains 75 days, from July 1 through September 13.

That split matters. Parameters fitted over the entire history would let later observations influence the apparent success of an earlier classification.

Fit states with different variances

The analysis uses statsmodels MarkovRegression with switching means and variances. Both the two-state and three-state models were fitted using multiple starting values and three random seeds. I retained the converged fit with the highest likelihood for each specification.

In the two-state model, the fitted daily return standard deviations are about 1.53% and 4.30%. Both means are close to zero, so I label the states by volatility. Large positive and negative returns can both fit the high-volatility state.

Keep the probability path visible

For the holdout period, training parameters stay fixed. Filtered probabilities update using returns observed up to each day.

The report places the most likely state on the price timeline, then shows the full probability series below it. A hard label can change when the probabilities cross 50%; the probability chart shows whether that change was decisive or marginal.

The January–June portion is explicitly marked as a retrospective training view.

Check the model choice

The three-state model has a slightly lower training BIC. The two-state model has a slightly better mean predictive log score over this holdout. That is useful evidence of sensitivity, rather than proof of a universal winner.

The score evaluates the probability density assigned to observed returns. It does not measure directional trading accuracy.

Make the assumptions inspectable

The report includes fitted distributions, model parameters, transition probabilities and reproducibility notes. Constant transition probabilities and Gaussian returns remain simplifying assumptions.

I built OWL Compose, and used it to present this analysis alongside its charts and data. If you work on time-series analysis, the English report shows the complete result.

What would you test next: rolling refits, a different training window, or a heavier-tailed return distribution?

Keeping an AI-assisted conversion report numerically consistent

Aethan Lee — Sun, 13 Sep 2026 18:52:40 +0000

I'm a software engineer, and data analysis is part of my work. Cleaning data, agreeing on metric definitions, and checking a report against its source numbers are familiar parts of the job.

I built OWL Compose to help with this workflow. This post walks through the checks behind a user conversion report I made with it. The dataset is simulated and describes a fictional team collaboration product; it contains no customer performance results.

Define the population and observation window

The example covers January–June 2026 signup cohorts, observed through August 1. Each user is assigned to their first acquisition channel. The onboarding funnel follows signup, completed import, and first useful output, in that order, within seven days of signup.

Week 4 retention counts users active on days 22–28 after signup, divided by the original signup cohort. All six cohorts have completed that window. This makes the comparison meaningful across signup months.

Calculate the total from counts

The six months contain 29,080 signups and 7,486 week 4 active users. The combined retention rate is:

7,486 / 29,080 × 100 = 25.7% (rounded)

This calculation weights each cohort by its size. An unweighted average of monthly percentages would give each month equal influence even though the signup counts differ.

For each month and channel, the report uses the same definitions:

activation = first useful output within 7 days / signups
week 4 retention = active users in days 22–28 / signups
spend per week 4 active user = direct acquisition spend / week 4 active users

The spend measure is in CNY. It includes direct acquisition expenses and excludes staffing, product delivery, and service costs. It cannot establish profitability without revenue and the missing costs.

Check the aggregate against its segments

January has 3,000 signups and 781 week 4 active users: 26.0% retention. June has 7,180 signups and 1,833 week 4 active users: 25.5%.

Within each channel, June retention is higher than January retention. Paid ads, the lowest-retention channel in this example, account for a larger share of June signups. Both the channel rates and their weights contribute to the aggregate.

This is a useful report review: a change in the total can reflect a change in the population mix. The channel breakdown helps explain the arithmetic. It does not establish why users behaved differently.

Keep the presentation tied to the calculations

In the report, the metric cards, charts, and appendix draw from the same simulated aggregate data. Derived values are calculated from those inputs. The written analysis names the cohort, denominator, and limits of each comparison.

OWL Compose helps me put those pieces into a readable report with AI. Input quality and metric definitions still need review. A polished chart does not validate either one.

Explore the complete simulated report. The public example includes the funnel, channel comparison, retention matrix, and data appendix.

If you review analytics reports, which consistency check do you run first?

DEV Community: Aethan Lee