Empowering The Atlantic to Build Fast, High-Quality Ads at Scale
In the fast-paced and ever-changing world of online advertising, speed of ad production, speed of ad loading, flexibility, and scalability is key. It’s ideal to produce ads quickly, with a diverse array of styling and functionality options, but also to be able to maintain them easily over time.
Our custom ads are a suite of bespoke templates designed to be visually compelling and respectful of the reader experience. They’re an order of magnitude faster than average ads on the web and adhere to strict performance rules.
We started making custom ads in 2017, with a process that was highly flexible but required developer work, and it didn’t scale well in terms of maintainability. To remedy this, we created a better system for easily creating and maintaining our custom ads that is used by Re:think, our in-house branded content studio.
Custom Ads 1.0
In 2017, when we decided to try out producing custom ads on TheAtlantic.com, we built Custom Ads 1.0 as an MVP. We wanted to get something off the ground that would allow us to experiment with custom ad creation without building too much infrastructure until we better understood the problem space.
Custom Ads 1.0 had a boilerplate template (HTML, CSS, and Javascript) for each of our 15 custom ad units. When you wanted to create a new custom ad for Advertiser X, you’d use an automated scaffolding task (with a tool called Yeoman) to create a new ad from the template, and then you would change out the code that it used with text, media, and styles. You’d add the code from those files to the ad server, which would then serve your custom ad on the site.
This worked pretty well for a while. But there were two main problems:
- Maintainability/Scalability. Let’s say you wanted to add a script to start tracking swipe events in analytics for the first time. You can add it to the template, so it will be included in future ads, but what about the hundreds of ads you’ve already produced from that template? Since they were copied over from the original template and are no longer tied to it, you would need to open up each ad’s code and manually add in the script. Simply put, given the lack of greater infrastructure, this doesn’t scale.
- Required skillset and speed to production. Because this process required working with frontend code, only developers could create custom ads, which put a bottleneck in the production process.
Custom Ads 2.0: Powered by Hattie
To solve this problem, we created a new repo containing a Custom Ads app. In the app, there are templates for each custom ad, similar to 1.0. However, the difference is that there is no need to interact with the template code directly when producing a new ad. Rather, each template plugs into a Django-based platform we built (and affectionately named Hattie, after Harriet Beecher Stowe, a co-founder of The Atlantic). Django is excellent for building staff admins, allowing us to get new systems and features up and running quickly.
Each custom ad template requires content (such as images, text, and links) be supplied to it via Hattie in order to produce the final ad.
Having a platform like this allows us to make other improvements like integrate Thumbor, an image processing service, that lets us automatically serve images at the best file and file format for reader’s device, letting us cut down the file sizes and speed up our ads even more.
Once all of the settings for a given ad are submitted in the form, Hattie attaches them to a unique ID tied to that ad and serializes them, sending them into an API.
Hattie then uses a Node app to create a unique URL for that ad that pulls in and serves both the Javascript code from the app’s template as well as the settings from the Hattie API — which together produce the custom ad. The Hattie admin provides a script tag containing that URL that we can drop into the ad server (GAM360), which will serve the ad to readers visiting our site.
Combining the template code and the API-provided ad settings into one HTTP request provides a nice performance optimization. Additionally, any changes made to the template or Hattie settings are immediately integrated into the code that the URL serves and thus passed directly to the ads being served, making this process highly scalable.
Living in a Post-Custom Ads 2.0 World
The result has been tremendous. We are producing custom ads at a rapid pace, as each simply involves completing a form in the Hattie platform in just a few minutes, rather than 10–20 minutes of code development and review. Since this doesn’t require code at all, it empowers a broader set of people to create these custom units.
We have focused on using ad templates that are easily extensible and have flexible features. We are also able to add new features to the template as needed to respond to market needs. This makes our ads scalable as well as quick to produce. Whereas creating some custom ads used to take several hours, some of those variations are now reduced to just toggling a checkbox.
For example, you may have noticed in one of the screenshots above that there is an option for a button to display on the left or right side of the screen. In Custom Ads 1.0, a developer would achieve that with a few lines of CSS. Now it is a template setting, and can be quickly selected in a form that is serialized and pulled in by the template.
This system has opened the door to doing more complex, ambitious units. We recently shipped a new custom ad template called “Storyscroll,” which keeps track of its state across impressions so it can tell a running story through the reader’s experience. This would not not have been feasible on the MVP infrastructure.
The ability to extend and scale our ads by being able to deploy template changes immediately and obtain feedback in real time also means that in the future, if we want to integrate exciting new features into our custom ads, such as A/B testing, it’s entirely possible.
And with that, we get everything on our bucket list: speed of ad production, speed of ad loading, flexibility, and scalability. Magical!
