Machine learningPersonal project
River level forecasting
A hydrological forecasting project based on historical observations, lagged variables, baseline models and rigorous evaluation.
- Python
- Time series
- Predictive modelling
Advanced analytics and predictive models
Forecasts and classifications built from your historical data, evaluated against simple alternatives and explained so you can decide with them, knowing what they can and cannot tell you.
Updated:
Without a reasoned forecast you buy too much or too little, or size the team badly.
Each platform attributes sales to itself. A joint view of the effect of spend is missing.
Reports describe the past, but nobody has quantified which factors explain the results.
A model with a good metric in a notebook is useless if nobody builds it into a decision or maintains it.
A prediction without an error margin is an opinion. In every project I report, next to the expected value, a reasonable range and the model’s performance against a simple baseline (for example, repeating last week’s value). If the model does not consistently beat that baseline in a validation that respects time order, I will tell you and we will not put it into production.
I use temporal validation (train on the past, test on the future) to avoid information leakage, which artificially inflates metrics. I choose metrics according to the cost of being wrong: under-predicting is not the same as over-predicting. I also analyse where the model fails — certain products, months or customers — because that is usually where the most useful improvements are.
A model is useful when someone acts on it. That is why from the start I settle how results will be consumed and how often they are refreshed. Once the model is in use, I monitor the gap between forecast and outcome and retrain at an agreed frequency.
Under projects you can see a river-level forecast using time series and lagged variables, and a marketing mix modelling project using Bayesian inference — both personal, with their methodology and limitations described.
What data exists, its quality, the patterns it shows and what can and cannot be concluded from it.
Forecast, classification or response model, always compared with a simple baseline (such as repeating the previous value).
Temporal or cross validation, business-relevant metrics, uncertainty intervals and error analysis.
A periodic report, results table or connection to your BI tool, with retraining and quality monitoring.
What the model assumes, when it stops being reliable and how to interpret its results.
Which decision will be made with the result, over what horizon and what error is acceptable.
Historical coverage, gaps, definition changes and the variables available at the time of prediction.
I start with simple methods; I only add complexity if it improves consistently in validation.
Temporal split between training and test, so the evaluation resembles real use.
Measure in production whether the model keeps working and retrain when the data changes.
Estimate sales or orders by product or period with seasonality, trend and variables such as promotions or calendar.
Rank leads, tickets or customers by the probability of an outcome to decide where to act first.
Quantify which factors explain changes in revenue, margin or conversion.
Estimate each channel's contribution and simulate budget allocation scenarios, with model uncertainty in view.
Anticipate failures from sensor data or logs, provided there is enough failure history.
Short-term forecasting of physical variables with lags and comparison baselines.
It depends on the problem. For time-series forecasting you want several full cycles (for example, at least a couple of years if there is yearly seasonality); for classification, enough examples of each class. We assess this in the initial analysis and, if it is not enough, I propose simpler alternatives.
I cannot give a figure before seeing the data. I can commit to measuring it honestly, with temporal validation and against a simple baseline, and to telling you if the result does not justify using the model.
Whatever fits the problem. Often a statistical model or a simple method with good features beats a complex one, and it is easier to explain and maintain.
Yes. Results can be written to your data warehouse or delivered in a format consumed by Power BI, Looker or spreadsheets.
Only if sensor data or logs with enough failure history exist. If not, it is better to start by recording data properly and, meanwhile, use simple rules and alerts.
Machine learningPersonal project
A hydrological forecasting project based on historical observations, lagged variables, baseline models and rigorous evaluation.
AnalyticsPersonal project
An analytical project exploring marketing attribution, budget allocation and response modelling with Bayesian statistics in PyMC.
Find where AI adds value in your operations and take it to production with human oversight.
View serviceTurn manual, repetitive tasks into scheduled, traceable and maintainable workflows.
View serviceAn assistant that answers from your documents, cites its sources and respects permissions.
View serviceReliable pipelines, clear models and quality tests so you can decide with data you trust.
View serviceA first conversation is enough to know whether it makes sense and where to start.