Unique first-party data and innovative targeting options are your path to more ad dollars and better user experiences. One such novel feature is weather targeting - where you individualize content based on the weather conditions of where the user is located.
Weather targeting involves identifying, in real time, the weather conditions of a user’s city/zip and showing specific content to them based on that data. For instance, if it’s raining around them, you could show them ads for raincoats.
It’s not a common targeting feature - in fact, no major self-serve ad platform offers it - so it is far from expected by advertisers. And - depending on your product - it may not even make sense to build, especially when features like behavioral targeting and frequency capping are more pressing.
That said, such a targeting feature could:
One use case is for digital-out-of-home - such as digital billboards. Given most are outside, they naturally pair well with current weather conditions. For instance, Lamar has done a great job tying together ad copy with the weather:
Weather targeting is not limited to DOOH, though. Any website or app could incorporate weather targeting and offer it as a value-add to advertisers. If you work with Patagonia, for example, you could have them display parka ads only to people in locations where it’s currently snowing.
You also don’t need advertisers to make weather targeting valuable.
Such optimization helps to increase click-through-rates and improve the user experience.
This type of targeting is possible if you’ve built your own ad server and are not reliant on JavaScript tags or code from third-party ad tech vendors. This article will assume you’ve built your own ad server from scratch or are using a JSON API solution like Kevel.
For a starting point, you’d need to:
Definitely. Here’s a more thorough process for getting there:
No matter what Weather API you use, the response will contain lots of atmospheric data. For instance, here’s the response from Open Weather Map when I pinged it for the current conditions in zip code ‘27701’ (our headquarters):
"""curl "weather":[{"main":"Clear","description":"clear sky"}], "main":{"temp":49.42}, "wind":{"speed":8.05,"deg":80}, "sunrise":1578572790 """
The nerd in you may get giddy about all the possible targeting opportunities, but let's focus on this bit:
"""curl "description":"clear sky" """
Indeed - an MVP could incorporate just the nine pre-set response options for the "description" parameter:
How you approach this is up to you, but you could offer a targeting category called “Weather” with a simple dropdown like:
Advertisers (or your internal team) could then create campaigns with relevant ad copy that target just users in cities/zips currently experiencing that selected weather condition.
First off, for DOOH like billboard advertising, where speed is not imperative and the location is always set, you could just ping the Weather API every hour for each billboard location and store the responses for targeting.
For everyone else, you have two main options for when to ping the API.
Please note - given the mercurial nature of weather, we recommend thinking about incorporating a TTL (time to live) value.
In the ‘at time of ad request’ scenario, you would:
With Open Weather Map, their stated average response time is 89ms. For brands looking to have ad load times of <100ms, this would be a non-starter.
In the second scenario, you would ping the Weather API when they first interact with you, like a page load or app open. In this case, you’d:
Let’s assume you are able to append the weather data to the ad request. What do you do with this data?
This is where we recommend your system have feature we call Keyword Targeting - a way to create rules for targeting keywords attached to each ad request.
Using Kevel's targeting tools as an example, if you pass Open Weather Map's "description" response as a keyword in each ad request, you could set up campaigns targeting it, like:
If the "keywords" parameter in the ad request contains "rain", then this campaign would be eligible to be shown.
Yup - and it’s really not that complicated. Your MVP could be as basic as above, but you could also incorporate more sophisticated weather rules like:
Fortunately, this type of targeting is likely GDPR/CCPA compliant (please note: we are not a law firm - please consult a lawyer for this).
As long as you aren’t sending a user’s actual PII like lat/long to the Weather API - and relying instead on something broader like zip code or city - then you aren’t sharing PII with a third-party. Additionally, since you need to know only a user’s general area for weather data (such as city), there’s no need to pull exact IP Address - and a truncated IP Address (such as the last octet removed) is considered anonymized.
This will depend on your traffic, and we recommend using RapidAPI to discover different plans for different Weather APIs. For instance, Open Weather Map’s top tier costs $2K/month for up to 200K calls a minute. If you have that volume, you’d have to determine if $24K/year is justified by more relevant content and/or CPM premiums.
