Building an Ads API Ecosystem: 18 Tips for the Next Company To Do It
Some believe there is room for a new full-stack ads player out there. I am one of them. But I do also believe that having a fully-participating ecosystem of third-party companies working with such a player will be key to their success. And there are many lessons that (should have been) learned by now about how to build a vibrant API (application program interface) program* as a major publisher (like Facebook, Google, Twitter) or exchange (Yahoo/Right Media, Google, who is both). Here are some free (advertiser-oriented) suggestions I hope the next guy might take advantage of:
1. Consider not building your own ad interface at all.
I don’t expect anyone will actually listen to me on this, but I honestly believe that focusing all your internal engineering resources on building APIs and tools for others to send money to you and design/create/build ads on top of your platform is a better investment that recreating the ad buyer user interface (UI) one more time. Ads systems and UIs are like national airlines – as my college econ professor lamented, every country typically has one because of national pride, even if it doesn’t make economic sense to do so. How much unbelievable, often unforeseeable innovation has come from thousands of non-Apple companies and engineers on Apple’s AppStore? You may use the argument that Ads are like the “Phone” application on the iPhone: a core piece of what you’re doing… but today a lot of the ads problems are far better understood than even 3 years ago, and there are tens of thousands of engineers who’ve built systems like these (who are not going to come and work for you, Publisher), but given the chance to “do it right” within their own company and the right incentives by you through an ads ecosystem, would build far more robust systems than you could yourself. That being said, if you do build your own ads product, you need to be even more transparent with all trusted partners around your ad product roadmap and vision: an ongoing dialogue/collaboration between the publisher & partners with respect to what each party should and should not be building, as well as how those capabilities are positioned in market (to minimize customer confusion).
2. Share revenue directly, with tiers and rewards.
The biggest difference between advertising API programs and other types of non-advertising API programs is that advertising generates cash. Sometimes a LOT of cash. Many recent ads API programs funnily enough, don’t create any kind of direct financial relationship between the parties (except when providers are acting as agencies, but that’s a story for another day!). Customers pay the publisher for media directly via their account, and the developer is typically free to charge (with some guidelines set up by the publisher/exchange) a % of spend, a software fee or whatever. It would be far better for everyone if there was a transparent and explicit revenue share (e.g. 5% of spend) and that companies then were free to charge any software or usage fees they like in addition, as long as they are transparent. There should also be a starting tier (e.g. 7.5%) that runs for say 90 days, that every new partner gets upon launch. This would encourage entrants to get going, and also encourage them to build fully-baked systems and not launch before they are actually ready to get some scale from initial customers.
3. Design for real-time, accurate reporting.
For it being something so fundamental, many platforms get this wrong or at the very least, bad. Reporting via the API should be as close to real-time as possible, and inaccuracies should rarely occur – often providers run jobs hours later to correct/summarize data, and it’s difficult or impossible to tell the originally reported data from the final, “billable” numbers. If the early numbers are an estimate, that’s fine – but make sure the fields in the API lets partners know the difference and take the right actions, optimization, reporting or otherwise.
4. Require transparency.
The software or usage fees that customers are charged should be clearly understood and transparent to others in the market, and published on vendors’ websites as well as in a central location administered by the publisher. Does this mean more competition based on price? Probably, but I think it is better to get to this equilibrium quickly than to drag it out painfully. The future of all business is going to be a transparent one, so let’s just hurry the process up so we can focus on the areas where we can uniquely add value.
5. Have a sandbox for developers.
This is a must – you have to be able to test your code in a place where mistakes won’t cost you. A lot of big API programs don’t have this – most notably for a long time Facebook – and so you end up having engineers having to test with live-able-to-spend-money ad campaigns. Usually they make sure to have zero budgets etc, but I have seen some nasty instances of money wasted on “test” ads.
6. Design for high-volume, anticipate partners getting around constraints.
These APIs and systems should be designed for extremely high volumes of ads from a smaller number of large advertisers, and this is often opposite to how they are designed. Many ads systems seem to be designed for large numbers of advertisers running a small human-entered handful of ads and campaigns each. Often, the former breaks a system designed for the latter. Also, constraints like numbers of ads per campaign, campaigns per account and so on are usually designed-around by ad partners in order to achieve what they want. In 2009 my team crashed the servers of the original Doubleclick Ad Exchange 1.0 (they told us) because we had to create large numbers of campaigns targeting one publisher each in order to control spend at a publisher level (because publisher was the largest predictor of performance, not ad creative), and they hadn’t designed for that initially. The effort spent by partners to build around constraints in order to spend money is effort that is often short-term and wasted, when it could be spent collaborating on solving these problems together. Also beware of setting draconian/generic API rate limits as these can stifle innovation.
7. Allow more companies to get access and make auditions longer-term.
A senior exec at one of the big publishers with an API program told me how frustrated he was that so few new companies were getting accepted into the API program. “We’re blocking people from more efficiently shipping us money,” he told me. I think there’s little harm in having fairly open doors – and then punishing/suspending companies if they get out of line (e.g. by posting spammy ads). Part of the reason there are limitations are because ad systems may be fragile and prone to breaking with some of the high-volume tactics employed by API partners, which is why it’s important to design for them from the beginning. Give yourself a proper amount of time to assess potential partners. Set good hurdles to get to the next level, but make it easy to get started.
8. But certify partners PROPERLY for certain competencies.
Don’t let your partners claim to be good at certain kinds of things. Test their knowledge of your products and their application to different situations. Don’t set some opaque ad spend level within a certain vertical or set of companies dictate that they are experts in that vertical. Test their knowledge both of the vertical as well as of the tactics that work in that vertical and publish the actual results, the same way Odesk shows you publicly how a developer scored in a Node.js test, or the English test. This is difficult and takes time, but do it in an online-testing scaleable way, make it transparent and you can also apply it to training and managing your own sales team, just as well as partners (who can be a real extension of your own sales team).
9. Give free ad spend for control groups and (attributed) case studies.
I’ve seen amazing successes that the client wouldn’t let us talk about at all, or we had to put together a case study referring to them as “a major bank” or “one of the largest auto dealer groups”. But worse than that is the great work done whose efficacy vs. control groups representing other tactics is done poorly or not at all. Ad agencies and end customers alike often do not understand why you wouldn’t want to spend 100% of your budget on ( what you think is) the “best” tactic. You need to test and be able to see what lift a new method leads to – so publishers should promise 10-20% of free ad spend to campaigns where (a) a partner who is certified in that vertical or competency, and can actually design valid tests, is involved, (b) the customer promises to allow a case study to be created and distributed by both Partner and Publisher with their name on it, obviously assuming it’s not a complete disaster.
10. Compensate sales teams based on ecosystem success.
There are good and bad examples of publisher efforts in this area ranging from Facebook (mostly good) to Yahoo and AOL (more bad than good): but ultimately, if salespeople at the publisher are compensated based on spend from a customer segment regardless of what “interface” they use to spend that money, it should be better versus salespeople fighting over getting credit for making the customer use an inferior product to spend money. This is not that difficult to solve for someone just starting out – the problem is when you have people used to being managed and paid a certain way (e.g. Yahoo sales teams at various points), a change could be painful.
11. Award innovation with $money$.
Facebook has done a great job of encouraging their partners to compete to solve certain types of problems (Optimal won grand prize in one of these contests last year); prestige provides the major incentive here, but they and others could do more to provide larger monetary awards to the companies and teams that work on these efforts. I like the idea of providing monetary awards that the companies have to give to specific individuals as well as to the company (probably skewed to the latter) in addition to the always-appreciated but less sexy publisher swag or ads credits that have typically been the award. Make the amounts significant as well – why not at least $50,000 for the company and $10,000 for the team, for example, if you want to get something really great.
12. Share core engineering resources and listen to one another.
Partner engineers who work specifically with API partners are a great resource, no doubt – but often there is a disconnect between these folks’ knowledge and what their core ads engineering teams are working on. Partners collaborate with their assigned engineer(s) but are surprised by changes coming from the larger teams they never have any interaction with. There is a LOT for these people to learn from one another — but I’ve seen that some publisher engineers appear to have a disdain for the (perceived) lower quality engineers that work for partners. Beware of this kind of arrogance – because some of the power users and engineers from partners know far more from a practical standpoint than the core publisher engineers, about how their ads system actually works in the field. Engineers get jazzed when they can collaborate on hard problems with others. Share some of this knowledge, and work to build a better ecosystem on both sides. Note that all of the problems with this collaboration would be solved by my first point, of just not trying to build your own publisher ads interface in the first place and instead focusing 100% on partners and APIs!
13. Listen to power users.
Gokul Rajaram who was an early architect of Google’s Adsense/Adwords products told me that he ended up knowing a lot more about the system he’d helped build after he needed to use it to buy large volumes of advertising after he left Google. When at Facebook, he agreed with me that sometimes API partners have some of the most knowledgeable people about those publisher ad systems you could imagine. Often these aren’t the people who go to the partner conferences, unfortunately, because, just like Dan Ackroyd in “Spies Like Us”, they’re too valuable to let out of the basement. Both partners and publishers should let them out sometimes: publishers should give monetary incentives to their partners for these people to share some of that arcane knowledge.
14. Let partners really truly build vertical specialities.
Don’t encourage your partners to specialize in certain verticals or markets and then require them to still support all your functionality and/or features that are not relevant to that segment. If you want them to specialize, then let them – allow them to make the choice how to spend their resources. Certify them properly and transparently for certain verticals and/or horizontal specialities, and show everyone in the market exactly what those criteria are. For example, if you think they need to spend $1mm a quarter with at least 3 of the top 10 companies in a specific vertical as that criteria, then say that, publish that, show that on the website. Let them put up the “Banking Spend” badge or whatever. This is far better than the logo-shuffling powerpoint/website game, or I-can-tell-you-the-customer-name-on-the-phone-but-not-in-email game that many partners play today – set up some criteria based on real spend, and don’t be afraid to move people into and out of categories (probably on a quarterly basis).
15. Version your API, and don’t move the goalposts.
This is more about aligning development between what’s in your own ad interface and what’s in the API, and releasing them simultaneously. There’s few things that are more frustrating than having API engineers at the partner be ready, willing and able to implement a new feature that their customers are asking for, and it’s “coming soon” or “we’re not sure when it will be ready” etc. Innovation of your ads product is awesome, but longer-term planning and collaboration with the partners helping your biggest customers spend more money is awesome too.
16. Be transparent internally about customer introductions.
Communications at the publisher between salespeople sometimes seem broken based on hearing which partners get directly introduced to specific customers. If more specific qualifications and vertical spend figures are public and transparent, then introductions by salespeople should become more even-handed and less subject to who-knows-whom
17. Keep score and show partners where they stand, publicly.
Facebook has probably the most advanced feedback of any API program for its partners and provides a lot of metrics to partners about where they rank based on certain criteria. This is very useful to give those partner companies direction, but they and others could go further. Why not make this kind of data public to everyone, including clients? I’m sure many will disagree, but having tiers and awards can be frustrating when nobody really knows what the criteria are. This doesn’t mean you can’t include subjective factors like “amount of feedback given”, but you can objectively show that as one of the criteria and also indicate what kind of weight it has. Otherwise you open yourself up to criticism for not being even-handed.
18. Architect for stability, and communicate issues immediately to the marketplace with greater specificity.
The lack of stability among platforms that persists with some of them to this day, can make it very difficult for Partners to want to support and sell on behalf of a big Publisher partner. This can make it difficult for Partner customers to scalably use their tools, who may not know what is a Partner problem versus a Publisher API problem, or a Publisher product problem (e.g. not the ad system but the underlying site). Publish current ongoing ads issues somewhere prominent that anyone can see without having to log in, customer, partner and even consumer. Another way to help is (if, as we assume most likely, the Publisher didn’t listen to my advice (1) and also has its own ad interface) to use the same set of APIs to support your own products as your external partners use. Some Ads ecosystems use different sets of APIs for their own products versus their Partners, and make it harder for themselves to support, increases the chances for inconsistencies, and makes collaboration with Partners difficult. We’ve all experienced as both consumers and businesses bizarre and unhelpful software error messages; imagine your frustration though at seeing “Issue 1900: Contact support” when your system is trying to spend $100,000 in an hour for a customer! When there are issues or an endpoint isn’t working, error messages and error handling should be consistent and ideally shared ahead of time with the API’s users.
*My former company Optimal was one of the first members of Facebook’s Ads API program, as well as Twitter’s. Before focusing on social we’d also built on top of the Google Adwords API and heavily participated in Yahoo/Right Media ad exchange’s display ads API program as well. Optimal was acquired by Brand Networks in October 2013. I remain a member of the board of directors of Brand Networks.