Here’s an example of a local alert one would see on a page with Smart Layers that’s opted-in to receive AMBER alerts.

Though AddThis has had many Hackathons that have resulted in products being released, this project is the first to see a release so quickly. Kudos to the team for making it happen, while fitting in some late-night foosball as well!

How Does it Work?

ValueClick uses the Common Alerting Protocol to retrieve up to date alerts. This drives logic in their ad-serving technology to display alert messages instead of ads when the conditions warrant (i.e. the user is located in the geographical region of an active alert).

ValueClick has extended this tech to work as a gateway for partners like AddThis. They deliver both the alert parameters and pre-assembled graphical assets, and AddThis decides when to show these warnings to users when they are browsing publisher sites that have opted in.

Right now, we’re only implementing AMBER alerts, but as we move forward, we’ll look at adding severe weather alerts as well. We’ll also continue to improve the balance between immediacy of warnings, and how often we display them for a given user on a given website. We see around fifteen AMBER alerts per month and are tightly geo-targeted. So if you do the math, the display of these alerts will be a rare occurrence.

Since this is a Labs feature, we are releasing it as opt-in right now. Based on feedback and testing, we’ll see if it makes sense to move it to opt-out.

Design Considerations

In the weeks leading up to the hackathon, there was increasing press around mobile implementations of these warnings. Specifically, some late-night (or for some, early-morning) mobile phone alerts waking New Yorkers and Californians caused a bit of a stir. We didn’t want to add to that, so we spent a lot of time discussing user and publisher impact.

The first thing that we decided was that we’d never obscure publisher content to display a warning. So… no lightboxes allowed! We settled on an implementation that pushed the publisher content down slightly, displaying the warning in a slide-out from the top––similar to our Welcome Bar.

Next, we decided to cap the frequency of these warnings at one every four hours to reduce the total exposure to individual users. This is quite conservative, but we wanted to be careful while we were just starting out. In addition, if the user doesn’t have third-party cookies enabled, we won’t display the warning at all, since we can’t save a cross-site way to save state to frequency cap the warnings for them. (We do not use HTML5 LocalStorage as a rule.)

Third-Parties & the Open Web

The Emergency Warning Layer project encapsulates what third-party tools and services like AddThis do for publishers on the open web. By creating shared technology and experiences across websites and apps, users get more unified and ubiquitous functionality, and publishers get the power of networks focused on solving hard problems.

As a result, publishers can focus on making their product great, while third-parties take care of things like monetizing pageviews, driving traffic and engagement, and optimizing social channels. We believe that this forwards the spirit of the open web, letting anyone put their product or message out there, and potentially making a living from it.

This model also lets us create a potentially life-saving service together. Win, win, win.

What’s Next?

First of all, we want your feedback! As more of our publishers opt-in and get comfortable with the way we display the messaging, we would love to move it to an opt-out model. This would help fully use the AddThis publisher footprint to get warnings to the right people at the right time.

And the internal team, who won the popular Hackathon vote, produced the main Smart Layer product, landing page, backend integration, and some cool browser plugins to help us test: Sol Chea, Foo, Ben Knear, Jim Lane, Ted Pearson, Andy Tomasello, Yuesong Wang, and Emily Wilson.