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.
Nimbus ad tech compare to a traditional header bidding
Nimbus is bridging the gap between what technology in the advertising industry should be, what publishers need, and ultimately what advertisers need.
Optimizing Render Rate
As an ad tech driven company, we define ‘quality’ of an ad as an asset that renders successfully within a mobile environment. However, when experimenting with ads on Timehop, we encountered far too many instances where ads were not rendering.
In programmatic meetings, you’ll hear lots of talk about developing creative ads to increase user engagement, conversions and CPIs. While the creative design of the asset is important, the technology that facilitates the rendering of the ad is an often neglected component of the conversation. All the creativity in the world won’t result in a high-performing ad if it doesn’t render.
In an effort to solve for low render rates, some companies might hire or use third party companies to ‘optimize’ the HTML/JS associated with the asset. They may compress the image itself or minify the markup. Another measure is to use a CDN. While these solutions aren’t bad, companies may spend tons of money on them only to have the same sub-par render rate.
To address this issue when building Nimbus, we incorporated a new part of the funnel where we ‘validate the creative.’
How we validate creative in Nimbus
For example, Android browsers don't like javascript’s document.write method if it attempts to load another script. In this case, and for some demand partners, Nimbus will attempt to execute the document.write on the server using a virtual javascript stack that requires zero network connectivity, which ensures trackers and other network related calls do not get fired. This extra process means that when the HTML creative is sent to the client to render it will have a higher likelihood of rendering and therefore converting into a monetizable impression. We also do this for video ads, which typically have lower render rates than other ad formats because they are larger and therefore take longer to load.
For video, our process is a bit different. Video assets are sent to Nimbus via the VAST spec. VAST is a highly structured XML document. Being structured means it can be inspected in a reproducible way. Nimbus takes the VAST response and checks to see if the VAST document wraps another VAST document, something supported by the spec. If the document has been wrapped Nimbus will proceed to unwrap the document until the document is inline, similar to following a series of redirects. Once the document is inline Nimbus performs various checks to ensure that the video asset and document structure is valid. Doing this on the server increases the likelihood the video will render on the client-side device sooner, therefore increasing one’s render rate and ultimately increasing revenue.
Final thoughts
The ad tech ecosystem is massively fragmented, and is largely controlled by advertiser’s preferences instead of maximizing existing technology to benefit publishers. As a result, advertisers often overlook technological requirements of efficient advertising — hurting themselves and their partners in the process.
At Nimbus, we’re prioritizing technology in order to simplify the advertising funnel and deliver a more smooth and efficient ad experience to publisher’s and their users. Advertising is a system, and systems are not designed by advertisers or product teams — they are designed by engineers.
We’ve taken this technological approach not to appease the advertiser, but to allow the whole funnel to flourish. In doing so, all involved parties benefit, while adding back some cohesion into the advertising landscape.
