Insights to Ignite Your Mind
Dan Cristo

Director of SEO Innovation

A Marketers Guide To APIs

A Marketer’s Guide to APIs

This post is a short guide for marketers who want to understand what APIs are, and the role that they will play in the future of search marketing.

But before we jump into APIs, I’d like to start off with a prediction that the search engines of the future will primarily gather data using APIs not by crawling a website.

I believe this will happen because we’re quickly moving toward a world dominated by mobile, not desktop usage. In the mobile world, the best experience is delivered within a native app, not a mobile browser.

With this in mind, we can safely assume that brands and developers will focus their energy on creating apps and content for mobile devices as opposed to websites for desktop users. And, that’s not much of an assumption, as it’s already happening.

The difference between creating content for the web, and creating content for a native app is that search engines can’t crawl the content inside native apps. They need to access that content if they are to send mobile searchers your way. The solution is an API, and this guide will help explain what it is and how it works.

What is an API and how does it work?

API stands for Application Programming Interface. It’s fancy talk for, “A way for computers to talk to each other.”

Computers talk to each other all the time. Look at Siri and Google’s relationship when you ask Siri to perform a web search on your iPhone. Siri can answer our questions because Google has an API that allows external applications, to query its search results in the same way a user would enter a keyword in Google.com.

Why should we should we bother to understand how an API works? Because, in doing so, we’ll know how to create one for our mobile apps to ensure search engines can crawl our content.

Now of course we don’t want to get into the technical details in this guide, we simply want to get a feel for how things work at a high level so we can tell our developers what we need built.

A typical website

If your site sells products, has user-generated content, collects any consumer information, or has an admin panel where you can edit site content, it most likely has a database to store all that info.

When a visitor lands on your homepage, your website requests information from its database to display the right product details. How does that work?

Programmers write code on the homepage called a query. The query connects to your database and gives it specific instructions to extract the product details it needs.

The query might say, “Give me the top 10 most popular products in the database. Then give me the names, prices and images for those 10 products.” The database will provide a list of results that’s formatted and displayed on the homepage as the Top 10 Hottest Product list.

To write a query like the one above, a website will need two critical pieces of information, the database/username or password (since the database will only run queries from authorized users) and the exact names of the database tables (where you store the information).

Now your website shouldn’t have any problems retrieving this information, but external applications, like Siri or Google, may. After all, they don’t know your database username/password and they don’t know the names of your database tables.  This is where an API comes in handy.

An API allows an external application to say, “Give me a list of all your products, and their associated information.” The API translates that into a query that contains instructions for the database to retrieve the right information. The beauty here is that Google doesn’t need to know your database username/password nor the location of the information in the database. The API takes care of that for them.

Now what about security? You might be okay with sharing product information with external apps like Google, but you probably don’t want them asking about member or credit card information. APIs manage that well too. They have the ability to, block unauthorized apps from accessing confidential data, and allow approved apps to access that information.

Your Mobile App and Your API

Twitter is a fantastic example of how an external API helped a company become successful.

When Twitter first launched, it was simply a very basic web interface that let members text an update, and allowed their followers to see this update online. Even when smartphones started to become popular, Twitter didn’t create an iPhone app. Instead they asked developers to build mobile apps for their service using their API.

Soon there were dozens of mobile applications that brought the Twitter experience to the iPhone using APIs to request tweets, view member information, and send updates to Twitter’s database.

What’s even more amazing is a few years ago, Twitter started to gain widespread recognition as a platform that allowed information to be discovered and shared quickly.

And it was only a matter of time that Google saw Twitter as a way to add real-time updates to their search results. They worked with Twitter to gain unrestricted access to their “tweets” via a special API called the “Fire hose feed”. This let Google display breaking news in their search in near real time… all powered by Twitter’s API.

Without the API, Google wouldn’t have been able to crawl Twitter’s site fast enough to keep up with all of its updates.

Search engines crawl websites to get information. This can be a slow process and can use a lot of bandwidth because they have to load an entire webpage to retrieve its results. APIs, on the other hand, are fast and efficient, because they provide only the requested information in a streamlined format.

Deciding whether to use traditional website crawl methods or an API is similar to the decisions you make when renting a movie. You can either stream a movie from Netflix, or go to the store to rent one. Which one did you choose? That’s the difference between a search engines using an API (streaming video) vs. crawling a site (going to a store to rent).

Long story short, search engines want websites to build APIs. With them, search results can be updated in near real time, site content that was previously inaccessible can now be accessed, and data that was once unorganized is now structured, which makes it easier to evaluate.

Now IS THE TIME

With mobile projected to overtake desktop usage in 2014, now is the time for brands to focus on building their mobile applications.

When your team starts building mobile apps, make sure they do so using API calls, like Twitter’s apps, as opposed to hard coding queries like today’s websites. Queries don’t allow external apps like search engines to access data, which will be critical in the future.

Remember, consumers who prefer mobile also conduct searches through their mobile devices. Today, search engines deliver desktop pages to mobile searches. In the future, I see search engines delivering app results instead.

Conclusion

When you start building your mobile apps, build them on an API. Doing so will help ensure your organic traffic doesn’t drop because mobile searches are rising and you’re not ready to let search engines access your content.

Get ahead of the curve and lay the right search marketing foundation now.

Crafting Innovation

Catalyst crafts innovative search strategies for the world’s largest brands.

Would you like to talk to Catalyst about your search campaign?

Your Name (required)

Your Email (required)

Share this:

  • http://www.catalystsearchmarketing.com/author/adavis Angela D

    Love this post! Great insights.

    • http://dancristo.com Dan Cristo

      Well thank you very much, Angela.

  • http://completelyfreesalesadvice.wordpress.com Tony Dowling

    Dan, you must be terribly clever to make that all sound so straight forward. I would like to genuinely thank you for that post, excellent explanation for us non techies

    • http://dancristo.com Dan Cristo

      Hey Tony,
      Thanks so much for taking the time to leave that comment. I really appreciate it.

  • http://www.clayburngriffin.com Clayburn

    APIs are a lot of fun.

    • http://dancristo.com Dan Cristo

      They are.

  • http://twitter.com/jeypandian Jey Pandian (@jeypandian)

    How do you let Search Engines access the information within a web application through an API? As I understand it, Google worked with Twitter to get the ‘firehose API’ but what about web apps that do not have a Google “relationship?”

    • http://dancristo.com Dan Cristo

      Hey Jey,
      This all is based on my prediction that Google will roll out a set of standards for working with APIs in the same way they’ve rolled out schema.org.

)