Successful API solutions like Twilio and Stripe rely on the idea that while engineers love building their own solutions, some problems - such as communications and payment processing - have too much complexity to build in-house. Indeed, why spend months/years building a communication infrastructure when you can hook into Twilio’s APIs in hours.
This perceived value of API tools hasn’t migrated to ad serving tech, though, and the most common pushback we hear from companies is that they don't see any reason why they can't just build it in-house from scratch.
If you look at the top ad platforms - like those offered by Google, Facebook, Pinterest, Amazon, etc - they have entire departments dedicated to their ad products (and have for years/decades). And, yet, companies not in ad tech often believe it’s possible to build an ad platform in just a couple months using their current engineering team.
Maybe it’s because placing ads on a site/app seems, well, easy. Just design a basic interface for uploading a 300x250 banner, include some Boolean logic on when to display it, and there you go. Of course, as we’ll touch upon below, such a barebones ad server would be unsellable and see little adoption.
Or, maybe it’s because ads, when they aren’t the sole source of revenue, are viewed negatively, and employees are fine repeatedly punting the project under the guise of, “We’ll get to it when we have the engineering resources” (which ultimately leads to it never getting done).
This may partly be why 95% of the Top 500 e-Commerce sites don’t use native ads, even though they are wildly successful for the largest brands (Amazon, Walmart, Etsy, etc all have high-value sponsored listing ad products).
This is unfortunate, as integrating server-side, user-friendly native ads and/or sponsored listings can drive new revenue without impacting the customer experience.
Kevel's customer Chairish, for example, saw a 10% increase in total revenue after spending just four weeks to integrate sponsored listings into its search results, and Ticketmaster saw 600% more revenue where they implemented native advertising units. There are few other silver bullets that can move the revenue needle like a new, innovative ad product.
It may also be that there are just few educational resources on the subject. To that end, we wanted to highlight exactly what building an ad server from scratch means.
This eBook looks into when it makes sense to build from scratch, and when you should instead look into launching faster with ad APIs.
https://f.hubspotusercontent00.net/hubfs/5897358/PDFs/build_buy.pdf
If you're on mobile, please click here for a mobile-optimized version.
We’ll admit that if your ideal ad server involves banners that rotate evenly, with minimal targeting and manual campaign creation/reporting, then you can build your own without much work.
That said, this is like designing a car that gets someone from point A to B but lacks windows, AC, side mirrors, etc. In other words, you aren’t creating anything that’ll sell.
Ultimately, ad products are only successful if advertisers are willing to pay for them, meaning you’re now competing with Facebook, Google, and others for a limited ad budget (and new budget won’t just appear because you release an ad platform).
As you look to sell your inventory, advertisers will ask questions like:
Building an ad server doesn’t mean the advertisers will come. A subpar ad product may drive some revenue, but it’ll have trouble retaining advertisers, and, at worst, it could make the brand as a whole appear behind-the-curve.
It’s important, therefore, to design an ad server with all the functionality needed to make it successful. Below looks at the features that most of the major ad platforms already offer (and against whom you're competing for ad budget).
Even with a team of 5-10 engineers dedicated to the project, building an ad platform from scratch with all these features would take years (at least, it did for Google, Facebook, and others, who had much larger teams than that).
Of course, one could build an ad server without many of these capabilities, but doing so doesn’t set the product up for success, and now months have been wasted building a product nobody uses.
Additionally, offering an ad product comes with the need for new software tools, certifications, and audits. These costs add up and are easy to overlook when making the decision to build in-house.
These necessary services add up. For instance, a publisher with 500M monthly ad requests may be looking at an additional $100K+/year on top of salary costs.
Another hidden cost is the work needed to scale and maintain the product. An ad server that begins with 1 million monthly impressions will crumble if it tries to grow to 100 million without a team focused on optimizing costs down and preventing ad serving issues.
Advertisers expect 99.99%+ uptime, so without a team focused on maintaining it, it’s likely there will be massive issues and headaches for sales/ad operations.
Additionally, the ad tech space is constantly shifting. For instance, to comply with GDPR, Kevel spent 6+ months making our system compliant. Owning the tech entirely means you must keep up with ad tech trends (which also include, over the years, viewability, fraud, header bidding, video, retargeting, and more).
Our recommendation would be that for every 100 million monthly requests, you have one dedicated ad engineer to help with scalability, reliability, maintenance, growth, and new features.
This means a site with 500 million monthly requests would need five, which at an average engineering salary of $125K is over $600K in salary costs.
Let’s take the scenario of a publisher with 500 million monthly impressions who wants to build an ad server with all the table stakes features of a 2019 ad platform, such as user-level targeting, frequency capping, eCPM optimizations, and more.
Estimated timetable and costs to build are:
And this is with no delays. We have yet to see a company who decided to build from scratch then release their ad platform on time, and most end up never actually launching one.
Hooking into an ads API solution like Kevel means you’d get instant access to tools for building a bespoke ad server with all the functionality of the large ad tech players. Indeed, the above company could launch at a fraction of the time (1-2 months versus 12-24) and cost using APIs.
Plus, the “hidden costs” like server costs, certifications, audits, IAB spider lists, and engineering salaries are built into that price.
This isn’t to say there aren’t reasons to build an ad server from scratch. Some brands want full ownership of the data; for others, if ad revenue is the only way they monetize, it may seem daunting to hand that responsibility to a third-party.
But if the justification is that building from scratch is cheaper or faster, it’s rare that it makes sense not to build on top of APIs, in the same way devs no longer build their own communication infrastructures but just rely on Twilio instead.
Kevel is the market leader in ad APIs. Customers like Ticketmaster, Yelp, OfferUp, Slickdeals, and many more have used Kevel’s APIs to build high-margin, high-scale ad platforms in a fraction of the time and cost as doing it from scratch.
Interested in learning how Kevel can help you build or scale your homegrown ad server? Let us know!
