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).
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.
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).
|Zone/placement targeting||Location on page; spot in search results||You’ll want to have different ads in various locations - in order to optimize CTRs, drive more money, and make your platform look versatile to advertisers|
|Contextual targeting||Shoes sub-category||Enable in-market targeting by letting, say, Nike show ads to a user only when they are browsing your shoe subcategory page|
|Frequency capping||Show same ad only once to a user per day||A common request from advertisers, this also provides a better user experience|
|Keyword targeting||Ad appears in the search results for ‘red hat’||Search targeting is extremely valuable to buyers - hence why Google is the #1 ad tech player|
|Day & hour parting||Show ads just on Saturdays, 9am-5pm||Buying patterns change on evenings and weekends, and smart advertisers bid differently during those times|
|Country targeting||USA||Non-starter if don’t have|
|City/DMA targeting||Durham, NC only||Country targeting may cover most use cases, but even tighter targeting can lead to higher eCPMs|
|Radius targeting||30 miles around Durham, NC only||City/DMA targeting isn't perfect because it targets just people in that area, so offering radius targeting can be a real differentiator|
|Language targeting||English||Enables advertisers to target just users who speak English (creating better user experience)|
|Demographic targeting||Gender, age||Advertisers know their target markets and will pay extra to show ads just to these users|
|Behavioral/Interest targeting||Shoe lovers (visitors who have searched for shoes in past)||Even if you don't have demo data, you can still offer user-level targeting by creating interest or behavior categories that advertisers can target, based on users' actions or information they've given you|
|Retargeting||Show an ad to someone who's visited the advertiser's site||Retargeting is lucrative, and you can offer this dynamically through a pixel or manually via a way to upload IDs to target|
|User agent targeting||iPhone X||Advertisers usually break their campaigns down by platform (desktop, mobile, tablet), as well as by device and even OS version|
|Bidding by CPM||Cost Per Mille (1K impressions)||The standard way a beginning ad server charges, but it isn’t the way that performance advertisers prefer buying|
|Bidding by other metrics||Cost Per Click, Cost per Conversion||This takes risk off the advertisers, who can bid by deeper actions|
|Ad pacing by time frame (pacing spend evenly over period of time)||Campaign with a 30MM impression goal over 30 days that wants to average 1MM/day||Ad pacing is complicated - if there’s a spike in a given hour, does the system correct itself and slow down ads? Or, if volume slows down, does it try to be more aggressive? If your system can’t balance requests in real-time, you run the risk of advertisers being unhappy about uneven display (or worse, ending without hitting their campaign goals)|
|Ad pacing by multiple metrics||Pace by clicks, not impressions||Not all customers want to pace by the same metric, so the ad balancer needs to incorporate multiple options|
|Ad capping||Pause a campaign after $500/day is spent||In addition to pacing goals, advertisers will want to set daily and lifetime caps. The ad server must be able to slow down and stop at the required metric|
|Goal optimizations||The advertiser bids via CPC but wants the system to optimize for a $20 cost per conversion||A more advanced functionality, this helps advertisers hit downstream goals|
|Priority waterfalls||Premium sponsorships → standard ads → in-house banners||This helps you sell higher value inventory and manage multiple advertiser buckets. For instance, you could sell full-site takeovers to key advertisers, but if none of these campaigns are active, you “waterfall” down to the next cohort of bidders|
|Lottery display rules||10 ads would each have a 10% chance of being chosen||Which ad wins is a vital aspect of ad serving, especially with 1000s of ads to choose from. Lottery is the simplest: all ads have equal chance to show|
|eCPM auctions||The ad that will deliver the most revenue wins||Lottery rules, however, don’t maximize revenue. Auctions that account for which ad will deliver the most revenue (a combo of bid and interaction rates) will increase your top-line|
|2nd-price auction||Auction where winning ad pays $0.01 more than what the 2nd bidder was bidding||Advertisers love 2nd-price auctions because they help minimize risk of high bids, and it’s what Google and others employ|
|Relevancy score||Ads with a higher relevancy score are more likely to be shown||This feature drives better user experiences by limiting ads that have low click-through-rates|
|Macros||Dynamically inserting a user's location into the ad||Using macros to dynamically insert content into the ad itself (such as the user's location, user agent, page metadata, etc) is valuable in making the ad as tailored as possible|
|Companion ads||Two ads on the same page come from the same advertiser||Advertisers love full-page takeovers, where every ad spot belongs to them. Building this so it includes eCPM optimization and targeting is much more complex than one would think|
|Show no duplicates||All ads on a page are different||The opposite of companion ads, this ensures that users aren't bombarded by the same ads, or ads from the same advertiser, at once|
|Brand exclusions||Nike and Adidas never appear next to each other||This feature pleases advertisers who want to make sure their ads never appear next to a competitor's|
|Pixel tracking||Impressions||Advertisers won't run without it|
|Click tracking||Clicks||Advertisers won't run without it|
|Revenue tracking||How much the advertiser is spending||You'll need to be able to calculate how the advertiser is bidding (CPM, CPC, etc) and at what amount, and then track and report on this||Conversion tracking||Purchases||An important addition for advertisers to measure downstream performance|
|Custom event tracking||Likes, saves||A valuable addition that lets advertisers track unique ways their ad is being interacted with|
|Enabling 3rd-party tags||MOAT tags||Required - advertisers won’t run unless they can track using independent tools|
|Tag management tools||Multiple tags pinged at once||Tag managers help to speed up ad requests by reducing number of calls, improving the user experience|
|Structured campaign hierarchy||Advertiser → Campaign → Ad Group → Ads||Advertisers will want different campaigns/ads with different targeting and bids. You’ll then need to structure reporting around these permutations|
|Multiple ad types||Native, 300x250, etc||Boost your offering by having multiple ad types and different bidding options, as they’ll have varying value|
|Video ads||15s clips||Video ads not only drive higher CPMs, but they are increasingly demanded by advertisers. Make sure you can also report on how far users got through each video (25%, 50%, etc)|
|Campaign scheduling||Start on 9/15 and end on 10/15||Automated campaign start/stop helps ensure no manual mistakes|
|Self-serve campaign management UI||N/A||Advertisers are used to self-serve UIs and only begrudgingly work with partners that require e-mail to stop/stop/etc campaigns (plus it's more work for you to manage these)|
|Self-serve reporting UI||N/A||Ad servers with manual reporting vs a log-in UI are unlikely to see quick customer adoption|
|Reporting by every metric||N/A||Advertisers will expect reporting by all permutations, including campaign, ad, keyword, country, device, etc|
|Forecasting & sales reservation||N/A||For predicting future traffic and selling against that|
|GDPR compliance||Consent prompt and back-end database to store info||Your ad server must be able to ask for, handle, and manage consent for EU residents|
|User management (advertiser logins)||N/A||You’ll want a system for creating user logins, scheduled reporting to them, etc|
|Billing||N/A||Automated tools to help with billing and invoicing cut down on internal time|
|Multiple server locations||Servers in Seattle, Singapore, etc||If you have international traffic, working with multiple servers across different continents is needed to minimize response times|
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.
|What||Avg Yearly Cost for Enterprise Customer||Importance|
|IAB membership||$50K - $100K+||While not a requirement, IAB membership helps to drive advertiser trust by ensuring your platform is transparent, following best practices, and a legitimate ad product. This is something you’ll likely be asked about from advertisers with large budgets|
|IAB's Spiders & Bot list||$4K with membership||In order to provide accurate reporting, you’ll want to remove impressions and clicks from non-human traffic. This helps with fighting refunds that may arise from discrepancies with advertisers who use their own tracking tools. There are also free tools out there to scrape - just depends on how much accuracy and accountability you want|
|SOC Type I audit||$25K||If you’ll be handling financial reporting, SOC I auditing is a must. You're looking at $25K and 300 people-hours to complete it|
|Device targeting databases||$20K||To provide robust and accurate device-level/user agent targeting and reporting, you’ll need integration with a device detection tool in real-time. There are scrapable tools out there, but boils down again to the level of accuracy you want|
|Status and incident communication tool||$5K||For your advertisers to continue to spend with you, they need to trust the platform. Having a live feed of uptime provides your advertisers with transparency into your product, cutting down support costs and increasing customer trust|
|Server monitoring tools||$4K||It’s vital you are tracking and monitoring your uptime, timeouts, and volume of your ad serving and ad creation requests|
|Location targeting databases||$2K||To provide robust and accurate location targeting and reporting, you’ll need integration with a geoIP database in real time|
|Server & database costs||$5 per million requests||This is one of the hardest costs to quantify, as there are so many moving parts: how much scale do you have, can you reserve instances, is there a DMP database involved, how much data are you storing, are the servers hosted or not, etc. However, as a ballpark-figure, we've found that $5 per million requests to cover both server and database costs will be inclusive of most companies, with it going lower with high scale|
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 Klarna, 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!
Chris has worked in ad tech for over fourteen years in a variety of roles - giving him customer support, PM, and marketing perspectives from both the advertiser and publisher sides. He previously worked as the VP of Marketing at Kevel.