API Branding News

These are the news items I've curated in my monitoring of the API space that have some relevance to the API definition conversation and I wanted to include in my research. I'm using all of these links to better understand how the space is testing their APIs, going beyond just monitoring and understand the details of each request and response.

Which Platforms Have Control Over The Conversation Around Their Bots

I spend a lot of time monitoring API platforms, thinking about different ways of identifying which ones are taking control of the conversation around how their platforms operate. One example of this out in the wild can be found when it comes to bots, by doing a quick look at which of the major bot platforms own the conversation around this automation going on via their platforms.

First you take a look at Twitter, by doing a quick Google search for Twitter Bots:

Then you take a look at Facebook, by doing a quick Google search for Facebook Bots:

Finally take a look at Slack, by doing a quick Google search for Slack Bots:

It is pretty clear who owns the conversation when it comes to bots on their platform. While Twitter and Facebook both have information and guidance about doing bots they do not own the conversation like Slack does. Something that is reflected in the search engine placement. It is also something that sets the tone of the conversation that is going on within the community, and defines the types of bots that will emerge on the platform.

As I’ve said before, if you have a web or mobile property online today, you need to be owning the conversation around your API or someone eventually will own it for you. The same comes to automation around your platform, and the introduction of bots, and automated users, traffic, advertising, and other aspects of doing business online today. Honestly, I wouldn’t want to be in the business of running a platform these days. It is why I work so hard to dominate and own my own presence, just so that I can beat back what is said about me, and own the conversation on at least Google, Twitter, LinkedIn, Facebook, and Github.

Seems like to me, if you are going to enable automation on your platform via APIs, it should be something that you own completely, and make sure you provide some pretty strong guidance and direction.

The Twitter Branding Page Provides Minimum Bar For API Providers

API branding is an area that I find to be contradictory in the space, with the loss of brand control being in the top concerns for companies when doing APIs, while simultaneously one of the most deficient areas of API operations, with most API providers have no branding guidance in their developer portal whatsoever. I think it is just one of those telling aspects of how dysfunctional many companies are, and how their concerns are out of alignment with reality, and where they are investing their resources.

Every API should have some sort of branding page or area for their API operations--I even have a branding page. ;-) If you are looking for a healthy example to consider as a baseline of your branding page, take a look at Twitters branding page, which provides the essential building blocks you should be considering:

  • Simple URL - Something easy to find, easily indexed by search engines, even a subdomain like Twitter does.
  • Logos & Assets - Provide us with at least a logo for your company, if not a wealth of assets to put to use.
  • Branding Guidelines - Offer up some structure, helping guide us, and show you've put some thought into branding.
  • Link to Embeddables - If you have any buttons, badges, and widgets, point us to your embeddable resources.
  • Link to Terms of Service - Provide us with a quick link to the terms of service as it applies to branding.
  • Contact Information - Give me an email, or another channel for asking a question if I get confused at any time.

I do not agree with all of Twitter's branding enforcement, but I respect that they have set a bar, and provide the ecosystem with guidance. At the very least, it makes sure all of us are using the latest logo, and when done right it can help encourage consistency across every integration that is putting API resources to work. I find it hard time respecting branding concerns from companies who don't have a dedicated branding resource area for me to consult.

When done right, APIs extend the reach of any brand. Think about Twitter and Facebook sharing, and other embeddables. Most API consumers are more than happy to help extend your brand, but we are going to be lazy, and ALWAYS need guidance and things to copy / paste. At the very least, make sure you have the minimum viable branding assets and guidance like Twitter does, it really is the minimum bar for any API operating out there, and should not be ignored.

Why Do Companies Who Ask Me To Update Their Logo Never Have Branding Page?

When processing the news for API.Report, and the over 150 areas of my API industry research, I spend a good deal of time looking for images to represent my stories, and the companies I'm covering. When looking for an image to best represent a company I always search google for "[company name] logo branding", and look for an official branding and logo guidelines page for a company--secondarily I switch over the image search if there is no official page available.

After a blog post, news piece, or research update goes live, I will sometimes receive a DM or email from a company asking me to update the logo, to a newer option than what I found via a Google search. I'm always happy to update the logo, and since my images are centrally stored on Amazon S3 it is pretty easy to do so. What I find interesting is that every company who actively polices their brand in this way never have an easy to find branding and logo area for their company and API operations.

 I fully understand the need to police your brand and make sure your company's logo is represented in the best light, but what I don't understand is why they don't have a self-service branding area to help empower folks like me to do this on their own. It just seems like a lot of extra work that is unecessary or at least is something that you could minimize by providing a dedicated page where folks like me can find the most recent copy of your logo. 

Every API Provider Should Have A Logo And Branding Page

I spend a lot of time looking for good quality logos to represent the companies I track on and write stories about. I have a certain vision in my head about how I want company listings and detail pages to look across the API Evangelist network—something that takes a lot of work.

To support this vision, I spend a lot of time looking for logos. Sometimes you can find them in the header of a website, but often times they are poor quality, not configured to be standalone, or difficult to get at for any number of other reasons--making my work a lot tougher.

I published a new list of 819 companies who are doing interesting things with APIs that I call The API Stack. After publishing the project, Concur, one of the travel API providers listed, tweeted at me asking if I could replace their logo with a better quality one from their official logo page--I did so very quickly!

I sure love me a good logo and branding page for an API. It makes my life easier, by giving me a single place to go get high quality logos, without having to open up my image editor. I wish that more API platforms would have a well designed logo page like Concur.

Building More Metrics Into Your API Branding Strategy To Quantify Your Reach

I use both Bitly and Google shortened URLs to track activity across my networks. I don’t just track click throughs, I also track image impressions for many of my projects and partners. This usage of shortened URLs lets me quantity the scope of my network, and understand interest across the network in the form of impression and click-throughs.

After talking with about their embed strategy for API driven data visualizations, the topic of a sensible API branding has floated to the top of my story list again. I consider an APIs branding strategy to be an important building block that contributes to the politics of an API and its ecosystem (both internal and external). If an API branding strategy is too strict, it can turn developers off from using your API, but a well planned branding strategy that includes a healthy suite of embeddable tools can be a serious asset, and go a long way in satisfying internal concerns about brand integrity--which is major concern for companies when it comes to API deployment.

What is a branding strategy? At its simplest it is about providing your API developers with a set of simple links and / or images that they should publish on their site, providing attribution for API resources consumed. A complete branding strategy provides the links, images and possibly JavaScript tools, as well as guidance on how they should be published on websites and within apps, providing proper attribution.

In the context of a basic API branding strategy, URL shorteners can provide a wealth of data about the scope of your API ecosystem, as well has help measure specific activity across deployments by your developers. You should be able to quantity the impressions and click throughs everywhere your API resources are put to use. Of course, a healthy API partner structure also allows for developers to opt out of tracking and possibly deploy white label solutions.

What does your branding strategy look like, and how to you measure the reach and activity across your API ecosystem?

Protecting Your Brand With API Branding Guidelines

One of the top five concerns I hear from companies considering APIs is regarding losing control of their brand. With APIs being about access to raw data and resources, companies immediately think that developers will extract the value, without any attribution or reference to the companies brand.

Even with this being a major concern, I see many APIs implement very poor branding guidelines, giving developers zero direction regarding how to properly provide attribution.  This is a missed opportunity to not just protect the API providers brand, but actually extend it and increase its value.

With this in mind, I'm always on the lookout for good examples of API branding guidelines.  One recent example I came across while monitoring my API Stack, is from the Active Network which provides activity and outdoor content via their APIs.

Active Network starts with a great explanation of why they provide branding guidelines:

At ACTIVE Network, we want you to be able to create fantastic applications with the ACTIVE Network APIs. At the same time, we don't want users to get confused about who is responsible for the data they are accessing, so we have some brand guidelines.

Next Active Network explains to developers why branding guidelines are important to their own users:

  • The ACTIVE brand holds credibility in the mind of the customer. It serves as a seal of approval giving customers the confidence to transact through a trusted source
  • As a consumer utility,® captures and records registration activity providing people with a record of their personal registration history if they need it at a future date
  • Transacting for an ACTIVE powered activity, tells your customer who they need to call if they need help. ACTIVE’s standard of excellence provides customers with 24/7 support 365 days a year

Active Network also provides details on how to properly use their companies name (which I followed in my story), what attribution is required, and a complete branding kit for download as a zip file--containing the following key assets:

  • Branding Guidelines in PDF Format
  • Icon Image
  • Powered by Logos
  • Register Now Buttons

The Active Network Branding Guidelines is one of the better implementations I've come across. It provides a nice overview, with all of the details and assets needed to execute properly.

Even if you aren't concerned about your brand when it comes to your API, requiring some attribution from your developers will at least help you market and advertise your API, and potentially bring in new API consumers.

Managing API Terms of Service, Privacy, and Branding with Github

Managing API Terms of Service, Privacy, and Branding with Github

The legal building blocks of an API can be just as critical as the technical and business building blocks. It makes sense to version and communicate your API terms of use (TOS) , privacy policy and branding guidelines alongside your code.

Since Github will allow document types other than code, such as markdown and PDF, it can make sense to use Github for managing the legal side of your API.

Using Github for the legal aspects of API operation will provide a level of transparency developers will appreciate, allowing them to download and store for their own records while being able to see the difference between each version, in a format that makes sense to them.

Just as with all other areas of an API, Github will allow you to completely manage the evolution of your API terms, privacy and branding in a way that is in sync with all the other technical and business building blocks of your API.

Google Deploys a Single, Centralized Terms of Use for APIs

Google has made another step towards a more common API infrastructure in line with their API Discovery Service, API Explorer, and API Console by launching a single terms of service for all Google APIs.

Google has rewritten their terms from the ground up with the goal of making them easier to understand for application developers.

At the moment it seems as though most of the APIs that use the central terms of service are content and data related APIs, like Google Tasks, Google ModeratorGoogle Charts and Blogger.

While more complex APIs like Youtube, Google Analytics, Google Adwords and Google Latitude still use their own terms of service. Over time, more APIs will be migrated to the new, centralized terms of service format. 

With almost 100 APIs now, it makes sense for Google to reduce the complexity of terms of use across APIs, increasing the chances a developer will “legally” build an application or business around one or multiple Google APIs. 

Google provides tools for developers to easily discover, explore their APIs, while also providing centralized management of billing, usage reporting and terms of use.  I predict we will see other API service providers offering tools for managing terms of use, branding and other legal aspects of API management in 2012.

If you think there is a link I should have listed here feel free to tweet it at me, or submit as a Github issue. Even though I do this full time, I'm still a one person show, and I miss quite a bit, and depend on my network to help me know what is going on.