The first problem with analyzing weather data was its size we had a year’s worth of daily weather history with over 40 attributes (such as average temperature, precipitation level, relative humidity, air pressure, etc.). However, we still wanted to ensure that location and weather data provided significant value. We expected them to be more predictive of purchasing behavior generally than the weather or location-based recommendations. In general, we were happy to see customer-based recommendations have higher weightings. The customer processor then cleaned this list of association rules, dropping off low lift rules and attaching them to existing customer data to produce actual item recommendations.įor our weather and location processors, we wanted to produce similar ratios for weighting recommendations to the lift value from the customer processor so that we could prioritize the comprehensive list of recommendations. The lift value is also what we used as a weighting metric to prioritize the recommendations later.

The consequent is a likely future purchase, with the confidence, lift, and support providing various metrics of the strength of that association rule.įor example, the third record there represents a rule that if customers have purchased items 527632, a good recommendation would be item 321500 or 269822, given that there is high confidence and lift value for those two rules. In the below snippet, the antecedent represents item IDs that have been purchased in the past. Still, FP-Growth is efficient at eliminating weaker associations to prevent unnecessary data processing. We chose FP-Growth over other association algorithms due to its speed, as some other a priori methods can become extremely slow with large volumes of data. This algorithm uses prior purchase patterns to create rules around past purchase history. Our customer recommendations used the previously mentioned market basket analysis with FP Growth as our algorithm of choice to produce rules. We divided our project into three parts: a customer processor that produced rules for customer purchase history-based recommendations, a weather processor that produced location and weather-based recommendations, and a recommendation engine that prioritized those recommendations for a given set of customers and locations. It is simple to share work and for others to contribute with minimal hassle. It has the extra benefit of requiring no local setup. We used theĭatabricks is an excellent tool as it is easy to set up a cloud instance with no prior experience or knowledge and pull in a variety of great tools and libraries for machine learning and data analytics. We chose to rely on Databricks as our platform to do data analysis and produce recommendations using PySpark and Scala. By not relying on domain knowledge of weather’s impact on the sales, which our team did not have, we were able to make much better use of what was available to us. For weather data, we were given a substantial number of attributes.

While for that customer data, we only had the IDs of the items clicked, added, or purchased by a specific customer at a location and date. This was especially appropriate because the customer history data provided was scrubbed of all semantic context.

Our team wanted to use an a priori approach that did not rely on making assumptions about what data would and would not be valuable and instead tried to make use of all the data provided. Problem and Approachīelow is the problem that our team was working to solve. Earlier this year, the UDig Nashville office fielded a team to participate in Tractor Supply Company’s “Life out Here” AI/ML Hackathon and won the Product Recommendations competition! Hackathons are always a terrific way to try out modern technologies and build new skills, and it was a great experience for the whole team.

Udig sposnorship