Why Pay For GUIs Instead Of APIs?

Andrew Ruegger on
  • Categories: Analytics, Analytics & Marketing Column, Channel: Analytics & Conversion
  • If you currently use data to help grow your business, you will inevitably end up in a conversation as a manager or director that begins with, “What’s the difference between an API and a UI agreement, and why are the pricing models so different?”

    GUI, or UI, stands for Graphical User Interface, a software platform that presents the back-end data in a visually coherent way to users. It is managed (via online login) by the company you’re paying for the service. Everything from Facebook to Gmail has a UI; it’s simply how users interact on the page with the servers.

    API stands for Application Program Interface, which has a set of routines and protocols that let your machines talk directly to other machines. In short, APIs are how developers build applications on other platforms and a common method of raw data exchange between two parties.

    There are a variety of reasons why a company would use only UIs as opposed to APIs, or a combination of both. APIs:

    • Require higher technological skills to leverage;
    • Offer different data;
    • Can be unreliable;
    • Often require a library of scripts, proper back-end storage with logical architecture, and continuous management;
    • Have harder pay structures to budget around;
    • Require homegrown or additional purchased applications to provide equivalent insights.

    The costs associated with UIs reflect their quality of data, their uniqueness in the market, and their overall user experience. For example, companies that provide Twitter analytics from the Twitter firehose are very expensive because the firehose is rarely awarded to companies and resource-intensive to process. Whereas if the company is just tracking keyword rankings in Google for you, it tends to be cheap, as the market is oversaturated with comparable offerings.

    APIs, on the other hand, are generally not subscription-based like UIs, but call-based, and you get specifically what you ask for. In other words, you pay only for the raw material as opposed to the finished product.

    The Case For An API

    There are many structural reasons why UIs make sense, one being that sometimes the infrastructure doesn’t exist to support only APIs. However, times are changing, and you don’t need a team of developers anymore to leverage APIs and create great solutions, especially if you’re a smaller company and can’t afford nine UI subscriptions.

    If you’re a knowledgeable Excel user (or have something like Spotfire), you can create and set up a MySQL database (free), and if you understand the basics of calling an API, UIs may be something you want to start strategically moving away from. There are numerous benefits to this if done correctly, including lower costs, better data, and considerably less employee hours needed to pull the same sets of data. Going this route requires a concrete plan consisting of:

    • A clear vision of what you are trying to accomplish;
    • A solid understanding of the call limits in terms of price and throttling;
    • An intelligent storage and architecture;
    • Systems that support mass retrieval and manipulation/visualization (some Hadoop solutions like Arcadia are awesome).

    Having all of your data in one place — a benefit of APIs and centralized data storage — allows for a lot more flexibility in terms of automation, analysis and innovation.

    For example, I recently made this dashboard on Tableau Public using AdGooroo data for the Paid Search Industry in 2015. I had employees pull the data manually from AdGooroo’s UI, which took a long time, maybe two to three hours, as we were unaware that they had an API.

    Me being me, I wanted more data; I wanted a date range of two years, blended by domain with their organic search data. Manually, this would have taken 20 to 30 hours, but now we pull and produce visual dashboards in under in one minute (not including the call time of about 10 minutes) for all of our brands and competitors.

    Not being a developer, I use KNIME to call their API in a workflow like this:

    This workflow calls their API using the C# programming language, recalls if the data is missed, consolidates, cleans, aggregates and writes my desired sheet to a MySQL database on my hard drive. (My company is hesitant to allow me write access to our database.)

    After it writes, it bridges over to Spotfire and produces a dynamic dashboard that can be updated quickly each month. This is then emailed out to all of our execution teams in a secure environment to leverage for execution:

    Or with selectable metrics for more specific comparisons:

    Similar efforts are done, joining many of our data sources, to produce a variety of different visuals from a lot of API feeds. This way, employees don’t need to log into 15 places to get all their information and stay informed.

    UIs are certainly the right solution depending on your current technology stack and business objectives, but APIs are the future to superior business, creating numerous efficiencies and the ability to craft elaborate statistical models that tie your digital investments to sales.

    About The Author

    Andrew Ruegger
    Andrew Ruegger is Senior Partner, Head of Data Science at GroupM Search & Social - Catalyst. He is a digital veteran with over 7 years of experience in advertising. He currently is responsible for running the data and insights practice for search and social marketing.