I was a professional weatherman. Err…well not really; Instead I “forecast” weather for targeted content campaigns in ecommerce. Playing weatherman was one of the most eccentric parts of my time as a Digital Product Manager at Eddie Bauer and was something I never foresaw myself doing professionally to be honest. In the year since our site testing developer had left the company, I was managing the company A/B testing program (without as many technical skills as I have now) and forecasting weather was one of the more unusual roles that came along with that. A/B testing is the process where site traffic is split into groups (group A and group B or as many groups as you need) and the ecommerce results are compared against each other statistically to understand an impact of certain changes. These changes could be the redesign of a site frame or as simple as changing the color of a button.
One of the most often attempted campaigns was identify site traffic from warm and cold areas of the United States and display weather specific content to influence customers to buy more. In the 4 or 5 campaigns we attempted, only once did we see a statistically significant impact on our sales metrics. I lay blame for the lack of success of these campaigns primarily on the inability to accurately predict weather. The only method I was able to make work at the scale of the full United States was to pick the content displayed at the state level with the average temperature of these states. This was terribly inaccurate! However, now that I have explored regular expressions(regex) and ruby implementations a bit more, I have a significantly better idea of I can automate this testing process and deliver more targeted results based on longitude and latitude of each individual user.
Example of inaccurate forecasting states manually:
The basic structure of the automated geotargeting uses ruby to create a relational database to structure data from an openweather.com API for current weather and then use regex to match the user location on the DB tables. The API is called twice a day statically as I thought it unnecessary to call the API for every user interaction which could impact user latency during their customer journey. The result is users are automatically presented with the content that matches their actual weather and significantly reduces the fudge factor by my amateur forecasting skills.
Example of more accurate automated method:
The project itself is almost fully complete and can be connected to any ecommerce testing program fairly easily. I look forward to actually getting a campaign up and running to see if the automated method actually produces statistically significant results faster. In any case, it certainly will cause me less tedious work as a weatherman that I am not qualified for!
Top comments (0)