My reasoning about the data

I began with Black Hut Coffee's synthetic history, then moved to Spotify's publicly reported quarterly data to test my approach against a real business. I bring the shareholder reports into a consistent workbook and record the source filename in each populated cell's notes. I also check later reports for revisions to earlier quarters, so changes in the published figures remain traceable.

I keep Premium subscribers and Ad-supported monthly active users (MAU) separate because they measure different things. Premium subscribers represent paying subscriptions, including subscribers who may not have listened recently. Ad-supported MAU measures active users of the free service. Their sum provides a combined measure for this project, but it cannot be treated as Spotify's official MAU or a count of unique active users. The published data does not give me enough detail to reconcile the difference reliably.

For the monthly forecasting experiment, I use linear interpolation between reported quarter-end counts. This creates a consistent monthly series, but the intervening values are estimates. It does not create additional observed data or reveal what actually happened within each quarter. I retain the reported quarter-end markers and distinguish user counts, measured at a point in time, from revenue earned over a period.

To investigate seasonality, I examine quarterly net additions and each quarter's contribution to annual additions across complete years. This helps me assess whether Q4 consistently accounts for a larger share of growth. I base that assessment on the reported quarterly figures, recognising that a recurring pattern does not, by itself, explain what causes it.

How I test and judge the results

I use chronological training and test periods, with the most recent 15%, 20%, 25%, 30% or 35% held back. Each frozen forecast is compared with the same test dates across all six methods. I review both monthly scores and scores at reported quarter ends, using WAPE for the size of the error and bias for its direction. A near-zero bias can hide errors that cancel each other out.

The final July–December 2026 outlook uses a separate refit through June 2026. Changing the test slider changes the historical evaluation; it does not change that saved full-history outlook. I consider performance across the test windows, the shape of the forecast and how clearly I can explain it to management. The dashboard's suggested reference remains provisional.

The holdouts overlap, so they are sensitivity checks rather than independent tests. Monthly interpolation was also completed before the split: at a cut-off between quarters, a training estimate can depend on a quarter-end observation inside the test period. Checking only reported dates does not remove this issue. A direct quarterly backtest is the next validation step.

How I structured the assignment

I use AI as a coding assistant, specifying the dataset, Google Colab environment and outputs I need. I run the code, inspect the results and refine the instructions as issues arise. The dashboard follows the logical sections of the notebook so that the inputs, workings and decisions can be explained without scrolling through every line of Python.

1. Collecting Data: assemble the reported history, check definitions and reconciliation, and retain the source record.
2. Data Frequency Experiment: create the monthly estimates, inspect the charts and distinguish estimated months from reported quarter ends.
3. Forecasting: run the six methods on consistent inputs and retain forecasts, settings and diagnostics.
4. Comparing forecasts: review historical errors, bias and sensitivity to the test window.
5. Management Advice: assess the year-end landing, compare planning choices and explain the risks and next decisions.

The Assumptions page records the modelling choices and limits. The final dashboard cell assembles saved results without fitting the models again. The downloadable files retain the forecast values and supporting checks.

This structure responds to the assignment's requirement to show workflow and thought process, and Marianne's coaching advice to document data choices, model reasoning and assumptions in plain English.

What this approach can support

This approach gives management a starting point for planning future subscriber growth, with separate forecasts for Premium subscribers and Ad-supported users. Comparing the models helps assess how sensitive the outlook is to the forecasting method. Testing forecasts against historical results also helps judge which methods deserve more confidence.

For FP&A, the output can inform discussions about growth expectations, targets and where further investigation is needed. A wide difference between forecasts is a reason to examine the assumptions more closely before committing to a plan.

The subscriber forecasts can also provide a foundation for revenue scenarios by adding assumptions about average subscribers, Premium ARPU and advertising monetisation. That would connect the growth outlook to its financial implications.