The monetization of API datastreams has been discussed at length. Figuring out a methodology to create passive income streams from API users can help an API be more successful, allowing for further developer-supported iterations, better customer service, and longer-term longevity.

When considering how to monetize a web service there are a bevy of options. A common method is to integrate with third-party advertising APIs. Today, we’re going to discuss the fundamental differences between advertising APIs, the security concerns of their implementation, and the benefits of integrating targeted, specific advertising models driven by third-party APIs.

Differences Between Monetization and Marketing APIs

There is a fundamental difference between monetization and marketing APIs that sits at the core of this discussion. Strictly speaking, both monetization and marketing APIs do one thing directly by design – create a potential client and revenue stream. The fundamental difference is in how each goes about doing this.

A monetization API is strictly concerned with its namesake — monetization. APIs such as Google adSense, Amazon Mobile Ads, and even third party advertising agency-specific APIs are concerned with generating ads for networks to then show to a client.

We can see this basic concept in YouTube video monetization — a content producer creates a video, and elects to monetize. This choice then enables an API that draws from a database of advertising partners who have bid for specified advertisement sizes and positions, creating advertisements in general categories such as “sports” or “gaming”. The API then pairs these ads from a separate streaming server to integrate into the video, splitting revenue partly between the partner system with Google and the YouTube content producer.

A marketing API, however, does this in a much more targeted and often more effective way. Marketing APIs, such as the Instagram Ad API, Twitter API, and Facebook Ad API, utilize customer data to create a profile of potential interest in products and services. This may be done in a opaque way, such as delivering a partner’s product at the top of search results when a user searches for an item such as “coffee mug”; likewise, it can be done in a transparent way, such as a “relevant products” lightbox that links to partner products similar to recently viewed products on a storefront.

Benefits of Programmatic and Sponsored Advertising

There is a great benefit to using programmatic and sponsored advertising through advertisement APIs. These benefits can be broadly separated into two distinct groups — user benefits and developer benefits.

No one really likes ads, but there’s no doubt that targeted ads eliminate much of the frustration with older advertising methods amongst the user base. For instance, a mid–20’s American male would find an advertisement for a teen gossip website completely off-base — he’s simply not the target demographic. Seeing an advertisement so unrelated often drives away content viewers, readers, and users; targeted content, however, has a lower incidence of driving away users.

Targeted advertising could even be seen as a service to the user — for example, if a video-game enthusiast is searching for advice on how to upgrade a graphics card, delivering a targeted advertisement for a low-cost high-value graphics card from a partner might be the terminal point of their search. By targeting a specific demographic based on personal information and buying habits, you can reduce your advertising budget but increase actual physical return.

For developers, a great benefit is the reduction of negative perception. Users tend to dislike advertisements that pop under content, play loud audio, or represent political or economic groups they disagree with. Additionally, for developers who use these APIs as advertisements for their services rather than for creating a revenue source within an application, these APIs result in a lower advertising cost overall.

Advertising API Security

Advertising APIs may create a litany of caveats in the realm of security. When implementing an advertising API, you can consider the system within three broad categories — control, security, and opportunity cost.

Firstly, an ad API must grant a good amount of control for it to be worthwhile. Advertising is a very fickle beast — what may be seen as a feature to others can easily become a bother, and even a reason to cease using the API for some. Obtrusive advertisements, inappropriate ad content, and resource-intense advertisement systems can deter current and future clients, even if your product is excellent.

Having a modicum of control, or at the very least knowledge, concerning the practices, approach, and implementation standards of an advertisement API is an absolute requirement. Knowing that your customers won’t be tracked (or that they will be only when they opt in), that content will be relevant to their interests, and that advertisements will complement rather than take away from your API is of prime importance. This lack of control can also result in zero day exploits or vulnerabilities which make our second consideration that much more important.

An API must have high security. Security is at its very base definition a consideration of vulnerabilities and the resultant methodology by which they are controlled or limited. Attacks are becoming more and more common as the average web user becomes more savvy — according to a report from The Hill, cyber-attacks increased by 48% in 2014, and most estimates see that trend continuing, which can place the imbalance between your advertisement API security level and your API or webservice security level in a very dangerous spot.

This imbalance would typically not be an issue with first party advertisement APIs, as security at the API level would apply to both the API and the advertisement engine. With third party solutions, however, advertisements are delivered using external servers, adding an additional layer of complexity, and thus an additional node by which man-in-the-middle, injection, or even session replay attacks can be carried out.

Finally, the opportunity cost must be considered. Integrating an advertising API will be costly regardless of how it is done, what languages are used, and what architecture type the API can be categorized under. Whether this cost is limited, as in the case of Google Adsense utilizing simple Javascript snippets to employ advertisements on a web service, or comparatively more costly, such as with complicated RPC (remote call procedure) based server-driven advertisement engines, there is an inherent cost to implementing an advertisement API.

This cost is necessarily increased for first party development, of course — and thus the argument becomes one of appropriate levels of development. If your API or webservice has a low usage level, a third party solution may be the best solution, whereas a high usage system might validate first party development, as the opportunity cost is balanced by the lack of royalty and licensing fees. This opportunity cost can best be measured using appropriate and effective methodologies of metric analysis, which should be a core feature of any good API.

Examples of Advertising APIs

Now that we understand the benefits of advertisement APIs, let’s examine a few party options within the field. This is not an exhaustive comparison at all — there are hundreds of advertising API providers.

One of the largest APIs in terms of brand recognition is the Amazon Mobile Ads API, specifically designed for application-level integration into apps. The API is designed to serve ads directed from a third party server onto a native client API utilizing unique Application Keys for both security and identification.

Ads can be customized using the adSize attribute within the AdLayout configuration, using the following bit of code in the API packaging stage:

Unfortunately, with ease of use comes lack of control. While Amazon Mobile Ads has a great eCPM and offers cross-platform support across the Android, iOS, and Fire ecosystems, the ads are decided upon by the brand advertisers and Amazon’s proprietary ad system. This means that ads are served on what a third party thinks your clientele wants to see, which may not always be on track with reality.

Thankfully, however, this comes with an exchange in analytics. Amazon is well-known throughout the web world as having some of the best analytics systems, and having this analytic functionality tied directly into an advertisement platform makes it powerful enough to vindicate the loss of control.

Alternately, another great large-brand API is the Twitter Ads API. Though it lacks significantly proven analytics systems that other APIs such as Amazon’s can provide, Twitter Ads API provides far more control over the actual advertising campaign utilizing custom campaigns targeting keywords and concepts. For instance, a campaign can be carefully crafted to deliver target keywords at a set price. The following call:

$ twurl -H ads-api-sandbox.twitter.com -X PUT "/0/accounts/xxxxxx/line_items/yyyy/?paused=false" | json

Will generate the following Twitter Ad campaign:

{
  "data_type": "line_item",
  "data": {
    "placement_type": "PROMOTED_TWEETS",
    "bid_type": "MAX",
    "name": "grumpy cat",
    "placements": [],
    "bid_amount_local_micro": 1500000,
    "automatically_select_bid": false,
    "advertiser_domain": null,
    "primary_web_event_tag": null,
    "charge_by": "ENGAGEMENT",
    "product_type": "PROMOTED_TWEETS",
    "bid_unit": "ENGAGEMENT",
    "total_budget_amount_local_micro": null,
    "objective": "CUSTOM",
    "id": "yyyy",
    "paused": false,
    "account_id": "xxxxxx",
    "optimization": "DEFAULT",
    "categories": [],
    "currency": "USD",
    "created_at": "2015-02-09T00:00:20Z",
    "updated_at": "2015-02-09T00:00:20Z",
    "include_sentiment": "POSITIVE_ONLY",
    "campaign_id": "dy1f",
    "deleted": false
  },
  "request": {
    "params": {
      "line_item_id": "yyyy",
      "paused": false,
      "account_id": "xxxxxx"
    }
  }
}

This campaign will target the San Francisco/Oakland/San Jose geographic area with promoted tweets related to the keyword “grumpcat”, with a maximum bid price of $1.50. This kind of linear, granular control makes an API such as Twitter Ads extremely powerful.

The difference is stark, and represents in many ways the dichotomy between feature sets and control — a choice that is mirrored perfectly in the first and fundamental choice between first and third party APIs.

Conclusion

The fact of the matter is that integrating with an advertising API isn’t as complex an issue as it’s often made out to be.

Consider the security of your service — treat it like a stronghold, with the relevant precautions, security measures, and principles of vulnerability rectification. If you desire greater security, develop your API in house, as the granular control will result in greater security management and a more powerful internal culture of security.

Consider the cost of implementation — would implementation of an API fit with your development strategy and resource allocation? If your API is being developed in a fast-track with an eye for lean resource cost, choose third party solutions, as their cost, implementation effort, and overall benefit will match your approach more closely.

Consider the type of application you have — is it cloud-based with an entire ecosystem of tools and services? Pairing your service with an appropriate type of service (i.e., cloud-based app with a third-party cloud-based advertisement API, and vice versa) can make your API more functional, and ultimately, more useful.

Fundamentally, implementing a well-developed and appropriate advertising API can result in dramatically increased revenue, better user retention, and an improved user experience. This is a rare thing to see in the API space, but it’s delightfully true — when implemented properly, advertising APIs can be a win/win for everybody involved.