API Analysis News

These are the news items I've curated in my monitoring of the API space that have some relevance to the API analysis 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.

Labeling Your High Usage APIs and Externalizing API Metrics Within Your API Documentation

I am profiling a number of market data APIs as part of my research with As I work my way through the process of profiling APIs I am always looking for other interesting ideas for stories on API Evangelist. One of the things I noticed while profiling Alpha Vantage, was that they highlighted their high usage APIs with prominent, very colorful labels. One of the things I’m working to determine in this round of profiling is how “real time” APIs are, or aren’t, and the high usage label adds another interesting dimension to this work.

While reviewing API documentation it is nice to have labels that distinguish APIs from each other. Alpha Vantage has a fairly large number of APIs so it is nice to be able to focus on the ones that are used the most, and are more popular. For example, as part of my profiling I focused on the high usage technical indicator APIs, rather than profiling all of them. I need to be able to prioritize my work, and these labels helped me do that. Providing one example of the benefit that these types of labels can bring to the table. I’m guessing that there are many other time saving aspects of labeling popular APIs, beyond just saving me time.

This type of labeling is an interesting way of externalizing API analytics in my opinion. Which is another interesting concept to think about across API operations. How can you take the most meaningful data points across your API management processes, and distill them down, externalize and share them so that your API consumers can benefit from valuable API metrics? In this context, I could see a whole range of labels that could be established, applied to interactive documentation using OpenAPI tags, and made available across API documentation, helping make APIs even more dynamic, and in sync with how they are actually being used, measured, and making an impact on operations.

I’m a big fan of making API documentation even more interactive, alive, and meaningful to API consumers. I’m thinking that tagging and labeling is how we are going to do this in the future. Generating a very visual, but also semantic layer of meaning that we can overlay in our API documentation, making them even more accessible by API consumers. I know that Alpha Advantages’s high usage labels have saved me significant amounts work, and I’m sure there are other approaches that could continue delivering in this way. It is something I’m keeping a close eye in this increasingly event-driven, API landscape, where API integration is becoming more dynamic and real time.

The More We Know About You The More API Access You Get

I’ve been trash talking APIs that identify me as part of some sort of sales funnel, and automate the decision around whether or not I get access to their API. My beef isn’t with API providers profiling me and making decisions about how much access I get, it is about them limiting profiles making it so I do not get access to their APIs at all. Their narrow definitions of the type of API consumers they are seeking does not include me, even though I have thousands of regular readers of my blog who do fit their profile. In the end, it is their loss, not mine, that they do not let me in, but the topic is still something I feel should be discussed out in the open, hopefully expanding the profile definitions for some API providers who may not have considered the bigger picture.

I’ve highlighted the limiting profiling of API consumers that prevent access to APIs, but now I want to talk about how profiling can be sensibly used to limit access to API resources. Healthy API management always has an entry level tier, but what tiers are available after that often depend on a variety of other data points. One thing I see API providers regularly doing is requiring API consumers to provide more detail about who they are and what they are doing with an API. I don’t have any problem with API providers doing this, making educated and informed decisions regarding who an API consumer is or isn’t. As the API Evangelist I am happy to share more data points about me to get more access. I don’t necessarily want to do this to sign up for your entry level access tier, just so I can kick the tires, but if I’m needing deeper access, I am happy to fill our a fuller profile of myself, and what I am working on.

Stay out of my way when it comes to getting started and test driving your APIs. However, it is perfectly acceptable to require me to disclose more information, require me to reach out an connect with your team, and other things that you feel are necessary before giving me wider access to your APIs, and provide me with looser rate limits. I encourage API providers to push on API consumers before you give away the keys to the farm. Developing tiered levels of access is how you do this. Make me round off the CRM entry for my personal profile, as well as my company. Push me to validate who I am, and that my intentions are truly honest. I encourage you to reach out to each one of your API consumers with an honest “hello” email after I sign up. Don’t require me to jump on the phone, or get pushy with sales. However, making sure I provide you with more information about myself, my project and company in exchange for higher levels of API access is a perfectly acceptable way of doing business with APIs.

Big Data Is Not About Access Using Web APIs

I’m neck deep in research around data and APIs right now, and after looking at 37 of the Apache data projects it is pretty clear that web APIs are not a priority in this world. There are some of the projects that have web APIs, and there a couple projects that look to bridge several of the projects with an aggregate or gateway API, but you can tell that the engineers behind the majority of these open source projects are not concerned with access at this level. Many engineers will counter this point by saying that web APIs can’t handle the volume, and it shows that the concept isn’t applicable in all scenarios. I’m not saying web APIs should be used for the core functionality at scale, I’m saying that web APIs should be present to provide access to the result state of the core features for each of these platform, whatever that is, which something that web APIs excel at.

From my vantage point the lack of web APIs isn’t a technical one, it is a business and political motivation. When it comes to big data the objectives are always about access, and it definitely isn’t about the wide audience access that comes when you use HTTP, and the web for API access. The objective is to aggregate, move around, and work with as much data as you possibly can amongst a core group of knowledgable developers. Then you distribute awareness, access, and usage to designated parties via distilled analysis, visualizations, or in some cases to other systems where the result can be accessed and put to use. Wide access to this data is not the primary objective, paying forward much of the power and control we currently see around database to API efforts. Big data isn’t about democratization. Big Data is about aggregating as much as you can and selling the distilled down wisdom from analysis, or derived as part of machine learning efforts.

I am not saying there is some grand conspiracy here. It just isn’t the objective of big data folks. They have their marching orders, and the technology they develop reflect these marching orders. It reflects the influence money and investment has on the technology. The ideology that drives how the tech is engineered, and the algorithms handle specific inputs, and provide intended outputs. Big data is often sold as data liberation, democratization, and access to your data, building on much of what APIs have done in recent years. However, in the last couple of years the investment model has shifted, the clients who are purchasing and implementing big data have evolved, and they aren’t your API access type of people. They don’t see wide access to data as a priority. You are either in the club, and know how to use the Apache X technology, or you are sanctioned one of the dashboard analysis visualization machine learning wisdom drips from the big data. Reaching a wide audience is not necessary.

For me, this isn’t some amazing revelation. It is just watching power do what power does in the technology space. Us engineers like to think we have control over where technology goes, yet we are just cogs in the larger business wheel. We program the technology to do exactly what we are paid to do. We don’t craft liberating technology, or the best performing technology. We assume engineer roles, with paychecks, and bosses who tell us what we should be building. This is how web APIs will fail. This is how web APIs will be rendered yesterdays technology. Not because they fail technically, it is because the ideology of the hedge funds, enterprise groups, and surveillance capitalism organizations that are selling to law enforcement and the government will stop funding data systems that require wide access. The engineers will go along with it because it will be real time, evented, complex, and satisfying to engineer in our isolated development environments (IDE). I’ve been doing data since the 1980s, and in my experience this is how data works. Data is widely seen as power, and all the technical elements, and many of the human elements involved often magically align themselves in service of this power, whether they realize they are doing it or not.

The Concept Of API Management Has Expanded So Much the Concept Should Be Retired

API management was the first area of my research I started tracking on in 2010, and has been the seed for the 85+ areas of the API lifecycle I’m tracking on in 2017. It was a necessary vehicle for the API sector to move more mainstream, but in 2017 I’m feeling the concept is just too large, and the business of APIs has evolved enough that we should be focusing in on each aspect of API management on its own, and retire the concept entirely. I feel like at this point it will continue to confuse, and be abused, and that we can get more precise in what we are trying to accomplish, and better serve our customers along the way.

The main concepts of API management at play have historically been about authentication, service composition, logging, analytics, and billing. There are plenty of other elements that have often been lumped in there like portal, documentation, support, and other aspects, but securing, tracking, and generating revenue from a variety of APIs, and consumers has been center stage. I’d say that some of the positive aspects of the maturing and evolution of API manage include more of a focus on authentication, as well as the awareness introduced by logging and analytics. I’d say some areas that worry me is that security discussions often stop with API management, and we don’t seem to be having evolved conversations around service conversation, billing, and monetization of our API resources. You rarely see these things discussed when we talk about GraphQL, gRPC, evented architecture, data streaming, and other hot topics in the API sector.

I feel like the technology of APIs conversations have outpaced the business of APIs conversations as API management matured and moved forward. Advancements in logging, analytics, and reporting have definitely advanced, but understanding the value generated by providing different services to different consumers, seeing the cost associated with operations, and the value generated, then charging or even paying consumers involved in that value generation in real-time, seems to be being lost. We are getting better and the tech of making our digital bits more accessible, and moving them around, but we seemed to be losing the thread about quantifying the value, and associating revenue with it in real-time. I see this aspect of API management still occurring, I’m just not seeing the conversations around it move forward as fast as the other areas of API management.

API monetization and plans are two separate area of my research, and are something I’ll keep talking about. Alongside authentication, logging, analysis, and security. I think the reason we don’t hear more stories about API service composition and monetization is that a) companies see this as their secret sauce, and b) there aren’t service providers delivering in these areas exclusively, adding to the conversation. How to rate limit, craft API plans, set pricing at the service and tier levels are some of the most common questions I get. Partly because there isn’t enough conversation and resources to help people navigate, but also because there is insecurity, and skewed views of intellectual property and secret sauce. People in the API sector suck at sharing anything they view is their secret sauce, and with no service providers dedicated to API monetization, nobody is pumping the story machine (beyond me).

I’m feeling like I might be winding down my focus on API management, and focus in on the specific aspects of API management. I’ve been working on my API management guide over the summer, but I’m thinking I’ll abandon it. I might just focus on the specific aspects of conducting API management. IDK. Maybe I’ll still provide a 100K view for people, while introducing separate, much deeper looks at the elements that make up API management. I still have to worry about onboarding the folks who haven’t been around in the sector for the last ten years, and help them learn everything we all have learned along the way. I’m just feeling like the concept is a little dated, and is something that can start working against us in some of the conversations we are having about our API operations, where some important elements like security, and monetization can fall through the cracks.

Image Logging With Amazon S3 API

I have been slowly evolving my network of websites in 2017, overhauling the look of them, as well as how they function. I am investing cycles into pushing as much of my infrastructure towards being as static as possible, minimizing my usage of JavaScript wherever I can. I am still using a significant amount of JavaScript libraries across my sites for a variety of use cases, but whenever I can, I am looking to kill my JavaScript or backend dependencies, and reduce the opportunity for any tracking and surveillance.

While I still keep Google Analytics on my primary API Evangelist sites, as my revenue depends on it, whenever possible I keep personal projects without any JavaScript tracking mechanisms. Instead of JavaScript I am defaulting to image logging using Amazon S3. Most of my sites tend to have some sort of header image, which I store in a common public bucket on Amazon S3, all I have to do is turn on logging, and then get at logging details via the Amazon S3 API. Of course, images get cached within a user’s browser, but the GET for my images still gives me a pretty good set of numbers to work with. I’m not concerned with too much detail, I just generally want to understand the scope of traffic a project is getting, and whether it is 5, 50, 500, 5,000, or 50,000 visitors.

My two primary CDNs are Amazon S3 and Github. I’m trying to pull together a base strategy for monitoring activity across my digital footprint. My business presence is very different than my personal presence, but with some of my personal writing, photography, and other creations I still like to keep a finger on the pulse of what is happening. I am just looking to minimize the data gathering and surveillance I am participating in these days. Keeping my personal and business websites static, and with a minimum footprint is increasingly important to me. I find that a minimum viable static digital footprint protects my interests, maximize my control over my work, and minimizes the impact to my readers and customers.

An API Change Log And Road Map Visualization

I saw a blog post come across my feeds from the analysis and visualizaiton API provider Qlik, about their Qlik Sense API Insights. It is a pretty interesting approach to trying visualize the change log and road map for an API. I like it because it is an analysis and visualization API provider who has used their own platform to help visualize the evolution of their API.

I find the visualization for Qlik Sense API Insights to be a little busy, and not as interactive as I’d like to see it be, but I like where they are headed. It tries to capture a ton of data, showing the road map and changes across multiple versions of sixteen APIs, something that can’t be easy to wrap your head around, let alone capture in a single visualization. I really like the direction they are going with this, even though it doesn’t fully bring it home for me.

Qlik Sense API Insights is the first approach I’ve seen like this to attempt to try and quantify the API road map and change log–it makes sense that it is something being done by a visualization platform provider. With a little usage and user experience (UX) love I think the concept of analysis, visualizaitons, and hopefully insights around the road map, change log, and even open issues and status could be significantly improved upon. I could see something like this expand and begin to provide an interesting view into the forever changing world of APIs, and keep consumers better informed, and in sync with what is going on.

In a world where many API providers still do not even share a road map or change log I’m always looking for examples of providers going the extra mile to provide more details, especially if they are innovating thike Qlik is with visualizations. I see a lot of conversations about how to version an API, but very few conversations about how to communicate each version of your API. It is something I’d like to keep evangelizing, helping API providers understand they should at least be offering the essentials like a roadmap, issues, change log, and status page, but the possibility for innovation and pushing the conversation forward is within reach too!

Keen IO Pushing Forward The Data Schema Conversation

I wrote earlier this year that I would like us all to focus more on our schema and definitions of our data we use across API operations. Since then I’ve been keeping an eye out for any other interesting signs in this area like Postman with their data editor, and now I’ve come across the Streams Manager for inspecting the data schema of your event collections in Keen IO..

With Streams Manager you can:

  • Inspect and review the data schema for each of your event collections
  • Review the last 10 events for each of your event collections
  • Delete event collections that are no longer needed
  • Inspect the trends across your combined data streams over the last 30-day period

Keen IO provides us with an interesting approach to getting in tune with the schema across your event collections. I’d like to see more of this across the API lifecycle. I understand that companies like Runscope, Stoplight, Postman, and others already let us peek inside of each API call, which includes a look at the schema in play. This is good, but I’d like to see more schema management solutions at this layer helping API providers from design to deprecation.

In 2017 we all have an insane amount of bits and bytes flowing around us in our daily business operations. APIs are only enabling this to grow, opening up access to our bits to our partners and on the open web. We need more solutions like Keen’s Stream Manager, but for every layer of the API stack, allowing us to get our schema house in order, and make sense of the growing data bits we are producing, managing, and sharing.

Focusing On What You Do Best While Leveraging APIs To Not Reinvent The Wheel

There are some pretty proven API solutions out there these days. I had to explain to someone a call the other day that in 2017 you shouldn’t ever roll your own API signup, registration, rate limiting, reporting, logging, and other API management features–there are too many proven API management solutions on the market these days (cough, 3Scale, Restlet, DreamFactory, or Tyk)

As a penny-pinching small business owner who is also a programmer, I am always struggling with the question of whether I should be buying or building. However, when it comes to some of the more proven, well-laid API sectors–I know better. One of these areas I will never develop my own tooling is when it comes to analytics. There are just too many quality analytics solutions available out there who are API-driven.

One of these is, who describe themselves as “APIs for capturing, analyzing, and embedding event data in everything you build”, provided an example of this in action, in their unstoppable API era post:

One of Keen’s largest customers stealthily uses Keen’s APIs to white label an in-app analytics suite for their Fortune 500 customers. Their delivery manager probably made the point most succinctly: “It would have taken our team two years to deliver what we’ve done with Keen in nine weeks.”

As a developer, we like to think we can doing anything on our own, and we often also underestimate the time it will take to accomplish something. I think I’m going to go through the high grade, well-established resources available in my API Stack research, and see which areas I feel contain solid API providers, and I would think twice about reinventing the wheel in.

Something like analytics always seems like it is easy to do at first, but then once you are down the rabbit hole trying to do at scale, and things begin to change. I prefer to not get distracted by the nuts and bolts of things like analytics, and be allowed to focus on what I’m good at. The best part of APIs is that you get to look good doing what you do, but it is something that can also be enhanced and augmented by other experts like who are rocking what they do.

Increased Analytics At The API Client And SDK Level

I am seeing more examples of analytics at the API client and SDK level, providing more access to what is going on at this layer of the API stack. I'm seeing API providers build them into the analytics they provider for API consumers, and more analytic services from providers for the web, mobile, and device endpoints. Many companies are selling these features in the name of awareness, but in most cases, I'm guessing it is about adding another point of data generation which can then be monetized (IoT is a gold rush!).

As I do, I wanted to step back from this movement and look at it from many different dimensions, broken down into two distinct buckets:

  • Positive(s)
    • More information - More data than can be analyzed
    • More awareness - We will have visibility across integrations.
    • Real-time insights - Data can be gathered on real time basis.
    • More revenue - There will be more revenue opportunities here.
    • More personalization - We can personalize the experience for each client.
    • Fault Tolerance - There are opportunities for building in API fault tolerance.
  • Negative(s)
    • More information - If it isn't used it can become a liability.
    • More latency - This layer slows down the primary objective.
    • More code complexity - Introduces added complexity for devs.
    • More security consideration - We just created a new exploit opportunity.
    • More privacy concerns - There are new privacy concerns facing end-users.
    • More regulatory concerns - In some industries, it will be under scrutiny.

I can understand why we want to increase the analysis and awareness at this level of the API stack. I'm a big fan of building in resiliency in our clients & SDKs, but I think we have to weigh the positive and negatives before jumping in. Sometimes I think we are too willing to introduce unnecessary code, data gathering, and potentially opening up security and privacy holes chasing new ways we can make money.

I'm guessing it will come down to each SDK, and the API resources that are being put to work. I'll be aggregating the different approaches I am seeing as part of my API SDK research and try to provide a more coherent glimpse at what providers are up to. By doing this, I'm hoping I can better understand some of the motivations behind this increased level of analytics being injected at the client and SDK level.

Splitting My Blog API Into Two Separate APIs For News And Analysis

When I started API Evangelist, I knew I didn't want to use WordPress or other common CMS, so I developed my own API, and page and blogging CMS. During the latest migration of my internal API infrastructure, I'm rebuilding everything as a single stack of APIs that I  can use to operate API Evangelist. Part of this process is breaking down legacy systems, into the small possible unit of value, something I consider deeply as I rebuild each API.

It started with my link system, which I broke up into link, curation, keyword, and linkrot APIs. Now I'm eyeballing my legacy blog API, which historically I also use to publish news pieces to API.Report, and sections that I syndicate to white papers I have published. My goal with my blogging API is to get it down to its simplest possible functionality--publishing posts to my blogs.

With this in mind I forked my newer blog API, and labeled it my news API. Right now, my news API behaves very similar to my blog, but it already has new features like automated pulling of press releases, extraction of proper nouns, and a few other bells and whistles that make my news management workflow as painless as possible. Over time I may share some of the features with the blogging API, I think my news and analysis worlds will remain separate beasts, from here forward.

A Glimpse At What I Am Imagining For API Driven Analysis, Visualization, And Beyond

I came across an interesting piece of technology today while doing new curation for API.Report. RASON, an interesting approach to API driven analytics and potential UI and visualization, that kind of resembles what I have been envisioning for one possible future. The analytics tool is created by a company called Frontline Systems, and I’ll let them articulate what it is:

RASON™ software is designed to make it much easier to create, test and deploy analytic models that use optimization, simulation, and data mining. RASON stands for Restful Analytic Solver™ Object Notation.

RASON targets analytical professionals, excel power users, and web app developers, but here is where it gets over my head, "Problems you can solve with the RASON service include linear programming and mixed-integer programming problems, quadratic programming and second-order cone problems, nonlinear and global optimization problems, problems requiring genetic algorithm and tabu search methods -- from small to very large." — sounds impressive to me!

I signed up and played with RASON a little bit, but it wasn't as intuitive as I hoped. I think I have a little more to learn about RASON. The RASON models are very cool, I like the airport hub, I just don’t have enough knowledge to make it work right now, however I’m digging the idea, and it reflects what I’ve been seeing in my head when it comes to defining API driven analysis--when you connecting that with API generated visualizations, hypermedia, spreadsheets, APIs.son, and more—I start to get a little too excited.

Anyhoo. Just sharing a new technology that I found. Once I learn more about RASON, hopefully I will be able to see where RASON fits into the bigger API life-cycle, and share a little more.

Low Hanging Fruit For API Discovery In The Federal Government

I looked through 77 of the developer areas for federal agencies, resulting in reviewing approximately 190 APIs. While the presentation of 95% of the federal government developer portals are crap, it makes me happy that about 120 of the 190 APIs (over 60%) are actually consumable web APIs, that didn't make me hold my nose and run out of the API area. 

Of the 190, only 13 actually made me happy for one reason or another:

Don't get me wrong, there are other nice implementations in there. I like the simplicity and consistency in APIs coming out of GSA, SBA, but overall federal APIs reflect what I see a lot in the private sector, some developer making a decent API, but their follow-through and launch severeley lacks what it takes to make the API successful. People wonder why nobody uses their APIs? hmmmmm....

A little minimalist simplicity in a developer portal, simple explanation of what an API does, interactive documentation w/ Swagger, code libraries, terms of service (TOS), wouild go a looooooooooooong way in making sure these government resources were found, and put to use. 

Ok, so where the hell do I start? Let's look through theses 123 APIs and see where the real low hanging fruit for demonstrating the potential of APIs.json, when it comes to API discovery in the federal government.

Let's start again with the White House (

Only one API made it out of the USDA:

Department of Commerce (

  • Census Bureau API - - Yes, a real developer area with supporting building blocks. (Update, News,( App Gallery, Forum, Mailing List). Really could use interactive document though. There are urls, but not active calls. Would be way easier if you could play with data, before committing. (B)
  • Severe Weather Data Inventory - - Fairly basic interface, wouldn’t take much to turn into modern web API. Right now its just a text file, with a spec style documentation explaining what to do. Looks high value. (B)
  • National Climatic Data Center Climate Data Online Web Services - yeah, now we are talking. That is an API. No interactive docs, but nice clean ones, and would be some work, but could be done. (A)
  • Environmental Research Division's Data Access Program - - Looks like a decent web API. Wouldn’t be too much to generate a machine readable definition and make into a better API area. (B)
  • Space Physics Interactive Data Resource Web Services - - Well its a PDF, but looks like a decent web API. It would be some work but could turn into a decide API with Swagger specs. (B)
  • Center for Operational Oceanographic Products and Services - - Fairly straightforward API, Simple. Wouldn’t be hard to generate interactive docs for it. Spec needed. (B)

Arlington Cemetary:

Department of Education:

  • Department of Education - - Lots of high value datasets. Says API, but is JSON file. Wouldn’t be hard to generate APIs for it all and make machine readable definitions. (B)


  • Energy Information Administration - - Nice web API, simple clean presentation. Needs interactive docs. (B)
  • National Renewable Energy Laboratory - - Close to a modern Developer area with web APIs. Uses standardized access (umbrella). Some of them have Swagger specs, the rest would be easy to create. (A)
  • Office of Scientific and Technical Information - - Interfaces are pretty well designed, and Swagger specs would be straightforward. But docs are all PDF currently. (B)

Department of Health and Human Services (

Food and Drug Administration (

Department of Homeland Security (

Two losse cannons:

 Department of Interior (

Department of Justice (


  • Department of Labor - - I love their developer area. They have a great API, easy to generate API definitions. (A)
  • Bureau of Labor Statistics - - Web APIs in there. Complex, and lots of work, but can be done. API Definitions Needed. (B)

Department of State (

Department of Transportation (

Department of the Treasury (

Veterans Affairs (

Consumer Finance Protectection Bureau:

Federal Communications Commission (

Lone bank:

  • Federal Reserve Bank of St. Louis - - Good API and area, would be easy to generate API definitions. (B)

General Services Administration (

National Aeronautics and Space Administration

Couple more loose cannons:

Recovery Accountability and Transparency Board (

Small Business Administration (

Last but not least.

That is a lot of potentially valuable API resource to consume. From my perspective, I think that what has come out of GSA, SBA, and White House Petition API, represent probably the simplest, most consistent, and high value targets for me. Next maybe the wealth of APis out of Interior and FDA. AFter that I'll cherry pick from the list, and see which are easiest. 

I'm lookig to create a Swagger definition for each these APIs, and publish as a Github repository, allowing people to play with the API. If I have to, I'll create a proxy for each one, because CORS is not common across the federal government. I'm hoping to not spend to much time on proxies, because once I get in there I always want to improve the interface, and evolve a facade for each API, and I don't have that much time on my hands.

API Evangelism Strategy: Landscape Analysis

I’m working with the Cashtie API to pull together an API evangelism strategy for the payments API. As I pull together, it seems like a great opportunity to share with you. Who knows, maybe you can use some of the elements in your own API strategy.

Next up is what I call "landscape analysis", which is about monitoring the blogs, and other social network activity of the sector(s) you are evangelizing your API within:

  • Competition Monitoring - Evaluation of regular the activity of competitors, visiting their sites, and getting to know their customers.
  • Industry Monitoring - Evaluation of relevant topics and trends of overall industry, industries that you are evangelizing within.
  • Keywords - Established a list of keywords to use when searching for topics at search engines, QA, forums, social bookmarking and social networks—this should dovetail nicely into any SEO work your doing. You are doing SEO work?
  • City and Country Targeting - Target specific markets with your evangelism. Get to know where your existing developers and target developers reside, and get local--be on the ground.
  • Social Media Monitoring - Have a solid strategy and platform for pulling relevant data from Twitter accounts, #hashtag conversations, Github profiles, and other relevant platforms to use in your landscape analysis.

The "landscape", is the space you are looking at each and every day out your virtual window, as well as what your existing and target developers will see each day. It is your job as an evangelist or advocate to know this space well, understand all the elements of the landscape, key players, relationships, and be a contributing member to this landscape.

Lanscape analysis should be something you do every day, weaving it into your regular social media, and other online activities. Remember you aren’t targeting this landscape of companies and users, you are looking to participate in the conversation, while also bring your API resources to the table.

NSA Protest Analysis And Targeting Using Angry Bird Data

The public recently found out that the NSA uses leaky applications such as Angry Birds to track on and find out more about every day citizens around the world. There is a wealth of data available regarding the potential of Angry Bird users, where they travel to, how they spend their leisure time, and potentially their understanding of physics.

One very important application for this type of surveillance of citizens is in the area of crowd control, and protest analysis. By tracking users ability to successfully target birds, and fling pings in Angry Birds, you can quickly assess which users will potentially be the most successful in throwing of rocks and other objects during a protest.

When you couple this profile data, with the ability to target these individuals using their cell phone signal in a crowd, you can quickly identify the individuals in a crowd who will potential cause the most damage , as well as injury to law enforcement if things get ugly. However in this scenario, rather than throwing of virtual pigs at birds, protesters will be hurling other objects at angry pigs.

Using big data analysis, law enforcement can easily target these threatening individuals in a crowd, conduct an initial sweep of the crowd and eliminate the threat to law enforcement. This will ensure that large crowds and protests, when they turn violent will minimize the threat to officers and potentially reduce property destruction.

API Stack - Text Analysis with Saplo API

Saplo provides an RESTful API for text analysis, using oath for authentication.

Using the Saplo API you can perform text analysis such as entity tagging, related articles, contextual recognition and sentiment anlysis.

Saplo provides a free account for non-commercial use with a limit of 240 calls per hour, and also a premium plan with pricing based upon the amount of text processed.

Saplo API for text analysisis a perfect tool for the API Stack.

AlchemyAPI Adds Sentiment Analysis to Text Mining Platform

AlchemyAPI, a natural language processing service announced a new sentiment analysis layer to its existing text-mining Software as a Service (SaaS).

The service can be used by online publishers, news aggregators, and contextualadvertising firms to understand and monetize online content.

The cloud-based text mining platform provides document-level, entity-level, and keyword level sentiment ming, in addition to support for negation handling, sentiment amplifiers or diminishers, slang and typos.

These features make the text mining API usable for analyzing and understanding user-generated social media content as well as editorialized text.

Sentiment analysis is available immediately to all AlchemyAPI users, more information is available at the AlchemyAPI web site.

Tech Blogger Analysis

A project I'm moving off the back-burner and into the public domain is a project I called Tech Blogger Analysis. My GF is Audrey Watters @ ReadWriteWeb, so I get exposed to an authors daily perspective in the tech blogging world.

I started harvesting all the RSS feeds from ReadWriteWeb, Techcrunch, O'Reilly, Mashable, VentureBeat, and GigaOm.

Upon harvest I would organize the post and curate author details, tags, etc. I had a whole bunch of scripts I'd run to clean up, organize and centralize meta data.

I would then pull the tweets for each post daily using BackType.

I would then build profiles for each twitter user with their # of followers, tweets well as their Trustrnk using InfoChimps.

When I started I was profile the individual blogs, and quickly saw the true value is in the tech blogger and their brand. I think there is an important story here:
  • What topics to they cover most? Specialize in?
  • Who has the strong brand? Number of Followers? Importance in certain topics.
  • Who are their influential followers? Loyalty? Trustrnk?
  • What do their followers pay attention to?
There is a lot of information here. I had the data harvesting for last 6 months, it was being refined and had a crude web interface setup. I wanted to provide a directory of Tech Bloggers and their brands with real-time stats on what they are writing on their personal and professional blogs. Think Postrank, BackType, Crunchbase for Bloggers.

I think the future of tech journalism is about the individual writers and their brands. I think writers would find this information valuable. I also think industry leaders would find this information valuable also. I see a lot of corporations investing in tech writers and their brand. I see writer brands becoming just as, or more important than the domain based brands we see today.

I would like to restart this project, but just can't afford the EC2, RDS and bandwidth charges if I'm not moving forward. If you are interested, you can contact me.

Amazon Launchs new S3 Analysis Tool

Amazon just launched a new analysis tool for Amazon S3 called, S3Stat. This tool uses the log files generated by S3, analyzes them using Webalizer, and generates a variety of reports. Take a look at the sample reports to learn more. There's a one-month free trial and usage after that costs just $2 per month. Take a look at the pricing plan to learn more. While you are on the site you may want to take a look at their list of S3 resources as well.

2d Code - QR code and two dimensional bar codes, news, views and analysis.

After posting about cellular and mobile barcodes yesterday I received a comment from a guy who started an online magazine on the subject. 2d-code @

From their home page about the magazine:

In Japan QR codes are found on everything from business cards to fresh lettuce. Now they are coming to the West and advertising and promotion will never be the same again. 2d Code will keep you informed as it happens, with news, views and analysis.

If you are interested in the QR code phenomena you can participate with us in several ways.

  • Mention or write about this website on your blog
  • Send us your sightings of QR or 2d barcodes
  • At the bottom of each individual news item there is an opportunity for you to comment or leave a message
  • At the top of each individual news item you can email the item to a friend or colleague.
Great resource to introduce and follow the subject of mobile two dimensional bar codes. I highly recommend you check it out and subscribe to their RSS Feed.

I really think this is an under-realized technology and topic in this country, and if we learn from the Japanese on how they use we can solve that problem off our online / offline lives and how that relates to social media and online marketing campaigns.

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.