Our Itility September hackathon was based on creating a sales prediction model for beer. A real customer case – with the goal to predict the effect of promotional activities on the number of crates sold. The goal was to predict the sales for week 34 of 2019 in the provided data set. A combination of clustering, regression and some common sense did the trick for the winning team.

The teams started with a cleaned and prepared data set - since data cleaning is very labor intensive and we want the teams to focus on optimizing the prediction model instead of tidying up incomplete, incorrect and/or irrelevant data entries. The (anonymized) data contained fields about sales of the past 80 weeks, sales activations (if there were any), and some information on locations.

A higher score is not always better

The teams used different methods for their prediction models. Most popular method, which performed not bad with an RMSE of 5.19, was using week 33 to predict the sales of crates for week 34. The reasoning behind it was: if you don’t know what the weather is going to be like tomorrow, you do not look at the weather of the past 4 months but at today’s weather.

All submitted results were assessed by the hackathon-jury and had to contain the predicted (integer) number of crates sold per outlet. Luckily, the jury was in a good mood and even condoned results with non-integer numbers by rounding off the numbers themselves. The score of the teams was based on the RMSE of the predicted and actual sales, thus the lower the score the better. Unfortunately, one team thought that a higher score was better. They were surprised and disappointed that they didn’t win, and in fact ended last.

The winning team used the most popular method with the previous week as a good predictor. In addition, they included the weeks before to prevent outliers. They decided to use the past six weeks and include a linear decay in the weight of inclusion, because not every week was equally important in the prediction. To also include the effect of sales activations, they added a crate of beer to the prediction if there was an activation in the week before (which made the prediction slightly better). This resulted in an RMSE of 4.76.

Other methods used include XGBoost and linear regression, but unfortunately their score on RMSE was not low enough to beat the winning team and earn lifelong fame and a dinner at La Fontana.

Time is always a limiting factor (at hackathons)

It is the case for every hackathon: you would like to do more in the provided time frame than possible. Therefore, it is always good to start with something simple and basic and have a baseline for your team to build upon further. This is usually not what happens: teams start with something complex, which means they stress nearing the finish and end up with a solution that does not meet the requirements set at the beginning, or even can’t come up with a presentable solution at all. Starting with something basic and build further from this means that at the end of the hackathon you have at least a substantial result (value) to show. And that is what counts: bringing value to the table in the time frame that you have.

Got excited for the next hackathon? Sign up for the Meetup group to get your invite