How Timehop Saved Itself By Building Its Own Ad Server

So, a little over a year ago, Timehop decided to build an ad server of its own to support unified auctions.

Lucky for Timehop, a small pub-tech company called PubGears was shutting its doors and several of its experienced engineers were looking for work.

In November 2017, after going heads down for a few months, Timehop launched its ad server beta, which they named Nimbus after the chief engineer’s chinchilla.

Nimbus was a significant engineering investment for a company with only 15 employees, but the results were well worth the effort. Daily revenue increased twelvefold during the holiday season, leveling out three months later to around seven times pre-Nimbus revenue.

Timehop kept tweaking its server, implementing VPAID and MRAID formats, adding in a bunch of DSPs and setting up Moat via the open measurement SDK. But the most value by far came from hosting unified auctions.

The problem before Nimbus was that “buyers were just guessing what our inventory was worth,” said Timehop CEO Matt Raoul.

But with its own ad server in place, Timehop could create a header bidding-like solution on fixed line items. Instead of one line item at a fixed price point, it could set, say, 100 different line items at 25-cent intervals. Each line item would then call the same impressions, and Timehop could cherry pick the ones with the highest CPMs. It’s not pure RTB, but it allows Timehop to avoid the waterfall.

“Essentially, we’re checking in on every possible price point available so we don’t get the short end of the stick,” Leviev said. “If something is sold for a certain amount, that’s the amount the buyer is actually willing to pay.”

These days, Timehop is profitable, commanding $28 CPMs. It’s in the process of prettying up the Nimbus UI and its reporting capabilities so that other publishers can take advantage of the tech. It’s also developing an SDK of its own for apps that don’t want to build a video player, which should be ready to go by the first quarter of 2019.

Leviev said Timehop has a queue of publishers in the pipeline looking to cut out the middleman and take Nimbus for a spin. “They’re willing to try this, because they’re tired of the bigger names,” he said. “They’re tired of just DFP.”

But now Timehop faces a new challenge: convincing demand partners that it’s got the supply scale and the technical chops to pull off managing its own server-side solution. “They don’t want to deal with custom implementations, they don’t have trust in publishers to implement to spec and they think we’re small,” Webb said. “But we do have the technical chops.”

In recent months, Nimbus has actually been helping Timehop have better relationships with the buy side.

“We’ve gained enough traction where some demand sources are actually asking us for best practices,” said Marc Santiago, Timehop’s director of programmatic engineering and owner of Nimbus the chinchilla.

Although Timehop acts like a publisher – people consume content within its app and it supports itself with advertising – it’s always really functioned more like a platform company, Webb said.

“Other apps have writers and editors and we have engineers who spend their time updating our connections to public APIs,” Webb said, and that gives Timehop a unique perspective into the in-app world that other content publishers monetizing primarily through desktop and the mobile web don’t have.

“The message we’re trying to convey to the industry is simple,” Webb said. “SDKs shouldn’t be the one and only way to implement multiple demand sources. Server-to-server can be very efficient.”

This post was syndicated from Ad Exchanger.