Implementing Weather Targeting with APIs

Chris Shuptrine
cardimage

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.

This article will explore how to add weather targeting to your ad server using APIs and possible use cases for it.

What exactly is weather targeting?

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:

  1. Increase ad revenue, as you can charge a premium for the extra targeting
  2. Make your ad product stand out to potential advertisers
  3. Provide better (aka more relevant) ad experiences for your users
  4. If you are using an ad server for internal promotions, allow you to put the right content in front of the right person at the right time

What are examples of weather targeting?

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:

dooh weather ad
lamar weather ad
dooh weather ad
lamar weather ad

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.

A service like Ticketmaster could incorporate weather data for targeted internal promotions - such as only promoting indoor events to a user if it’s currently raining.

Such optimization helps to increase click-through-rates and improve the user experience.

How do I start with weather targeting?

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 Adzerk.

For a starting point, you’d need to:

  1. Collect location data on your users
    -For DOOH, this is the location of the billboard/device/etc
    -For web users, this will be their IP Address or zip code they registered with
    -For mobile native app users, this will be their GPS data
  2. Use a location lookup tool to tie IP or lat/long to a city/zip
  3. Integrate with a Weather API. RapidAPI lists a bunch, with a top one being Open Weather Map. We’ll use them for this example (please note - we have no affiliation with Open Weather Map).
  4. Incorporate this weather data into your ad decision engine for targeting (for example, in Adzerk you could pass it as a keyword in the ad request and target against that).
open weather map
open weather map

Can you describe the implementation more thoroughly?

Definitely. Here’s a more thorough process for getting there:

Decide what targeting options you want to offer

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):

  "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:

"description":"clear sky"

Indeed - an MVP could incorporate just the nine pre-set response options for the description parameter:

open weather map
open weather map
Build weather targeting options into your front-end ad product

How you approach this is up to you, but you could offer a targeting category called “Weather” with a simple dropdown like:

  1. Sunny
  2. Cloudy
  3. Rainy
  4. Snowy

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.

open weather map
open weather map
Decide when to ping the Weather API and how to store the data

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.

When Pros Cons
At time of ad request Most up-to-date; adds weather data to all ad calls Can greatly slow down ad response times
After the user first logs in, opens an app, or visits the site. Data is then stored locally and referenced at time of ad request The ad's load time is not contingent on the response time of the Weather API This data would likely not be included in the very first ad request
  1. At Time of Ad Request

    This is most up-to-date and adds weather data to all ad calls. However, it can slow down ad response times because it requires waiting for the Weather API's response before sending it to the ad engine.
  2. First Interaction

    You ping the API after the user first logs in, opens an app, or visits the site. Data is then stored locally and referenced at time of ad request. Here the ad's load time is not contingent on the response time of the Weather API. On the other hand, this data would likely not be included in the very first ad request.

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:

  1. Use a lookup tool to match IP or lat/long with a specific city/zip
  2. Ping the Weather API with that city/zip
  3. Take data from the response, insert it into the ad request, and send it to your ad decision engine to be used in targeting

The obvious issue here is load time. In order for this to work, you’d need to delay the ad request until the Weather API data has returned (and you’ve parsed it).

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:

  1. Use a lookup tool to match IP or lat/long with a specific city/zip
  2. Ping the Weather API with that city/zip
  3. Store the information using local storage, such as Window.localStorage. The data doesn’t leave the browser, is persistent across sessions, and acts roughly like a database. This would be advised over using cookies (which you could employ but aren't great for this type of caching). It’s also possible to layer in TTL with the browser localStorage object.
  4. Then, when it’s time to show an ad, check local storage first. If the weather is available, grab it and append it to the ad request; otherwise, make an ad request without it and spawn a thread that will refresh the weather for the next time.

By pinging the Weather API asynchronously and before the ad request, you are minimizing any impact this targeting will have on ad load times.

Make this data actionable

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 Adzerk'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:

open weather map
open weather map

If the keywords parameter in the ad request contains rain, then this campaign would be eligible to be shown.

That’s pretty cool!

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:

  1. Temperature < 32 degrees Fahrenheit
  2. Rain > 0.5 inch
  3. Within 5 minutes of the sun setting/rising
  4. If there’s volcanic ash in the air (actually, please do not offer this)

Is weather targeting GDPR/CCPA compliant?

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.

Finally, by storing the weather data locally with a set TTL, it's a form of contextual, user-level targeting that doesn't involve persistent IDs or the need for a data management platform.

How much does this cost?

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.

Then there would be the cost of designing the feature. This is where integrating your ad product with Adzerk can expedite the process, as Adzerk provides turnkey access to a JSON ad serving API and Keyword Targeting logic.


Thinking of adding Weather Targeting to your ad product - or have already? We’d love to hear from you! Click the link below to join the discussion.

Join the Ad.Product community

Sign up for our monthly newsletter and to be notified of member-exclusive events and opportunities.

Ad.Product is the first community for product managers, engineers, and others to discover and discuss how to build innovative, user-first ad platforms.

Chris Shuptrine

Recommended Articles