Before we built Nimbus, we spent some time experimenting with ads on Timehop. This experimentation gave us insight into how the ad tech industry works — both on the business and tech side — and eventually led us to the path of building our own ad exchange.

The experimentation we went through as a publisher was vital to informing how we designed and built Nimbus as a publisher-first ad tech exchange. Instead of approaching the challenge as “how can we make a better ad tech exchange,” we approached it as “how can we better serve ads on Timehop.” This difference is subtle, but important. For us, it meant taking an engineering approach to ad tech, rather than a business approach, which ultimately benefits the publisher. In this post, I’ll share some of the fundamental issues we encountered during our experimentation phase, and how we addressed them in Nimbus.





A Return to the Basics of Ad Tech

First and foremost, we knew we needed to implement IAB’s OpenRTB standards. As an engineer, if you ignore rules and standards for how frameworks are meant to be used, you invite possible trouble in the future. Ad tech is no different. While the RTB standards are meant to be followed across the industry, we quickly learned that was not the case, and it was causing fragmentation across the entire ecosystem.

The RTB framework is a collaborative collection of ideas and specifications for how advertising systems should communicate with each other. It’s designed to normalize the data being sent to and from the system, to ensure proper security principles are applied to protect that data, and to define effective protocols to reduce latency and redundancy between communicating systems.

When it’s not followed, it can lead to increased demand side integration time and cause confusion around how to properly communicate and monetize with third-party demand side technologies — this is exactly what happened to us at Timehop.

At Nimbus, abiding by the RTB standards is non-negotiable. If demand partners aren’t following RTB standards, we do not spend the tech resources to integrate them into Nimbus, and they lose access to publishers working with Nimbus. As a result, publishers who work with us inherit better technical performance from demand. With Nimbus, publishers don’t have to worry or even consider the demand side integration or how well it will work, because Nimbus normalizes the format of the request and tailors it for each demand partner’s specific requirements.





Prioritizing Latency

When users are swiping through their memories on Timehop, or scrolling on any mobile app, you only have a brief moment to show them an ad they may be interested in. A very brief moment. If the ad takes too long to load, the user is gone and both publishers and advertisers miss out on revenue.

This is one of the issues we observed when experimenting with various ad tech partners.

The root of this issue largely comes from companies taking their ad tech built for desktop, and transitioning it to mobile. Initially, this might sound like an efficient and logical solution for advertising on mobile. However, it makes the incorrect assumption user’s on mobile phones have the same internet speed and processing power as they would on a computer.

When we built Nimbus, we knew latency had to be a top priority. This meant getting rid of advertising SDKs that utilize the client’s resourcing for retrieving and displaying advertisements. This is an important line to draw, as it forced us to think about alternative ways to retrieve an ad. Luckily, we didn’t have to look hard for a proper solution. DSPs have been doing this with advertisers and other SSPs for a long time using a server to server network calls. Nimbus allowed Timehop to run concurrent auctions in parallel efficiently, simply by moving where the network calls were originating from. As we onboarded more and more demand partners, it became apparent that mobile advertising SDKs could never achieve the same level of control and performance that Nimbus brought to the table.

Because Nimbus had become our power house for efficiency, it allowed us to take the next logical step in optimizing a desktop world for mobile. That is, Nimbus exposes the real-time bidding (RTB) spec to publishers. This gives publishers the ability to micro optimize and specify how they’d like their auctions run in Nimbus without slowing down their applications — increasing auction speed and decreasing latency. Lastly, because all the network calls are now offloaded to Nimbus and because Nimbus exposes RTB directly to publishers, the need for line items and highly latent waterfalls goes away.



