Source Data’s True Worth

In my discussion of the Internet of Things (IoT) a few weeks back, I mentioned that there was a big push underway to put sensors in farm fields to collect and monitor soil conditions as a way to optimize fertilizer application, planting dates, etc. But who would be the owner of this information, which everyone in agriculture believes to be exceedingly valuable? Apparently, this is far from decided. An association of farmers, The Farm Bureau, recently testified in Congress that it believes that farmers should have control over this data, and indeed should be paid for providing access to it.

We’ve heard this notion advanced in many different contexts over the past few years. Many consumer advocates maintain that consumers should be compensated by third parties who are accessing their data and generating revenue from it.

Generally, this push for compensation centers on the notion of fairness, but others have suggested it could have motivational value as well: if you offer to pay consumers to voluntarily supply data, more consumers will supply data.

The notion of paying for data certainly makes logical sense, but does it work in practice? Usually not.

The first problem with paying to collect data on any scale is that it is expensive. More times than not, it’s just not an economical approach for the data publisher. And while the aggregate cost is large, the amount an individual typically receives is somewhere between small and tiny which really removes its motivational value.

The other issue (and I’ve seen this first-hand) is the perception of value. Offer someone $1 for their data, and they immediately assume it is worth $10. True, the data is valuable, but only once aggregated. Individual data points in fact aren’t worth very much at all. But try arguing this nuance to the marketplace. It’s hard.

I still get postal mail surveys with the famous “guilt dollar” enclosed. This is a form of paying for data, but it drives, as noted, off guilt, which means undependable results. Further, these payments are made to assure an adequate aggregate response: whether or not you in particular respond to the survey really doesn’t matter. It’s a different situation for, say, a data publisher trying to collect retail store sales data. Not having data from Wal-Mart really does matter.

Outside of the research world, I just haven’t seen many successful examples of data publishers paying to collect primary source data. When a data publisher does feel a need to provide an incentive, it’s almost always in the form of some limited access to the aggregated data. That makes sense because that’s when the data becomes most valuable: once aggregated. And supplying users with a taste of your valuable data often results in them purchasing more of it from you.

Read More

Edmunds.com Yields Multi-Million Dollar Revenue Opportunity from its Free API

APIs, which stand for Application Programming Interfaces, are all the rage these days. APIs, which can be described as online back doors into your database, allow programmers to seamlessly integrate your data into their products, particularly, but not necessarily, mobile apps. Increasingly, customers are asking companies selling subscription data products for “API access” to their data. The reason for this is that these companies want to integrate commercial datasets into their own internal software applications. So you’ve got application developers looking for API access to your data in order to build it into software products for resale. You’ve also got companies that want API access to your data to power their own internal software. If you are charging a high enough price for your data that reflects the convenience and power of API access, as well as the expanded audiences your data will reach, APIs are nothing but great news for data publishers. But can you also make money giving away API access to your data for free? A growing number of companies think so. We recently spoke with Ismail Elshareef, Senior Director, Open Platform Initiatives for Edmunds.com. Edmunds makes its data available via API for free, and can directly attribute millions of dollars in recurring revenue to this initiative.

According to Ismail, Edmunds.com launched its API about two years ago, primarily as a way to get more exposure for the Edmunds.com brand. The second objective was one we often hear from those with open APIs: a desire to encourage innovation. As Ismail puts it, “We can’t hire all the smart people out there.” The goal is to put Edmunds data in the hands of a broad array of talented developers and see what they can do with it – whether it’s new applications software to leverage the data, or even entirely new and unintuitive uses for the data itself.

The additional brand exposure for Edmunds worked exactly as planned, according to Ismail, who said it has become “a huge differentiator.” Edmunds displaced a number of competitors who were charging money for equivalent data, and with the “powered by Edmunds” attribution on so many different products, Edmunds saw immediate brand benefit, not the least of which was more advertisers specifically acknowledging the reach of Edmunds in sales meetings.

Overall, Edmunds has found a number of partner deals came together more quickly as well, “because using the API, they can get comfortable with our data first.” A great example of this is a major deal Edmunds put together with eBay. Ismail emphasized the growing popularity of this “try before you buy” approach to data content, and that publishers need to respond to this growing preference among data buyers.

Ismail is careful to note that Edmunds wasn’t seeking to actively disrupt paid data providers in its vertical; the free data it offers simply reflects lower barriers to entry, and to an extent, the increasing commoditization of much of data it offers for free.

And while additional market exposure is clearly beneficial, as Edmunds saw it, the big upside opportunity was to see what dozens or even hundreds of talented, motivated independent developers would do with the data. And that’s exactly where Edmunds found gold. Acknowledging that of the apps developed around its data, “only 1 in a 100 is really interesting,” Ismail noted that one really interesting application emerged after only seven months of offering the free API. An independent software provider in the Northeast built a cutting-edge application for automobile dealerships. But while they had a great solution, they didn’t have a sales force to market it to dealers. Edmunds contacted the CEO of the software company, struck a partnership deal, and already the product generates millions of dollar in annual revenues.

One of the keys to Edmunds’ success is that while its data is free, it isn’t free for the taking. Every developer who wants to use Edmunds data has to adhere to a terms of service agreement, which specifies the attribution that Edmunds is to receive, as well as reserving the right for Edmunds to cut off data delivery to anyone who acts irresponsibly, though Ismail notes that most developers are very responsible and “know what’s cool and what’s not.” Also important to the Edmund’s model is that it initially only provides enough free data to developers for testing purposes. Before raising a developer’s API quota, Edmunds looks at each application to make sure attribution and back-links are correct, and that the application overall is using the data correctly (not incorrectly labeling data elements or incorrect calculations) and that the application is a quality product that Edmunds is comfortable being associated with.

As guidance to other data publishers interested in pursuing an open API, Ismail feels it is essential to use a service that provides an API management layer. After extensive research, Edmunds went with Mashery, which stood out to Ismail in particular because “Mashery already works with major publishers like the New York Times and USA Today, so they know the issues that are specific to publishers. They also have a huge developer outreach program, now over 100,000+ developers, which made it easy for us to get the word out in the developer community.”

Internally, Ismail notes that the Edmunds API was initially a tough sell. Not everyone believed in the concept, so executive support was a huge factor. It was only because the company’s chairman was such a believer that the API became a reality. As Ismail notes, “ultimately a free API is a leap of faith.” Ismail also noted the difficulties in getting the concept cleared by the company’s lawyers, who simply weren't initially comfortable with exposing our data to everyone." Executive sponsorship was key to ultimately clearing these legal impediments as well.

Launching the API involved “a lot of small steps in the beginning.” Initially, Ismail worked by himself on the API program. Now, his team consists of four engineers and a designer. And just yesterday, the Edmunds API has been certified for “Best Developer Experience” by Mashery – more evidence of how far Edmunds has come so quickly.

Don’t Be Embarrassed

“If you’re not at least a little embarrassed by something you just launched, you probably waited too long to start it.” So says Alexis Ohanian, founder of Reddit and a number of other high profile web media products. This statement, provocative as it is, actually is little more than a smart synthesis of the current state of play in the world of online product development. You no doubt hear variants of this theme regularly, sometimes expressed as “minimum viable product,” “rapid iteration,” and even “fast fail.” They all embody the philosophy that it’s more important to launch a new product quickly than launch a really good new product. I credit Google for raising this practice to high art by teaching users that the word “beta” appended to any product name excused the product from delivering much value, or even working properly, for an often extended period of time.

I certainly agree that there is an imperative for speed in the world of online content. We’re surrounded by hordes of competitive start-ups, many of them explicitly attempting to disrupt market incumbents. But before we decide to emulate these companies, it’s important to note their typically distinctive business models.

First, most of these not-ready-for-primetime products are thrown onto the market for free. The companies behind them are betting that if they can build an audience and usage, everything will work out fine in the end, even if they don’t generate any revenue in the short-run. Further, most of these products come from start-ups, so there’s not much in the way of reputation risk. Thirdly, these companies are staffed and funded to iterate rapidly – some actually push out updates and fixes on an almost daily basis. If you’re going to play in this world, you can’t just talk a good line about evolving the product – you have to deliver, and often at a blistering pace.

That’s why I would argue that for most established data publishers with subscription businesses, applying this approach of pushing out half-baked new releases can be very dangerous. When working with an existing customer base, be clear that your subscribers don’t value speed for its own sake – they want clear product improvement. And frankly, this shouldn’t be that hard. You’ve got the advantage of a successful existing product you want to evolve, so you’re not starting from scratch. You’ve got loyal customers who will test with you and offer input. You have a deep understanding of the market you serve, so there’s no need to guess about what might be useful or compelling. Perhaps most importantly, your subscribers often need your data and your tools to conduct business. That’s a world away from a nifty new pizza delivery app. You have an implicit obligation to move prudently and get it “as right as possible” right out of the gate.

So yes, constant evolution of your product is essential. Speed is important. It’s also important to understand that nothing will be perfect the first time around, and that’s okay if you fix problems as quickly as they are identified.

What about new products from established publishers? First off, if you plan to charge for the product from the start, this comes with a much higher level of subscriber expectations. If it’s free (at least initially), expectations are lower, but be aware that those who go away unimpressed probably won’t come back. Finally, being embarrassed may well be an issue for an established publisher known for quality data and solid applications.

So before speeding up, slow down and think it through. The people advocating speed often are in a very different place from you.

TripAdvisor and the Ignorance of Crowds?

We all know the many benefits of user-generated data, including ratings and recommendations. Underlying all of it is a general belief in “truth in numbers” - if enough people say it is so, then it must be so. But what happens when the crowd returns a result that is obviously and intuitively wrong? A small but perfect example of this occurred recently when TripAdvisor published its list of “Americas Top Cities for Pizza.”

I’ll spare you the suspense: the top-rated city for pizza in the United States is (drumroll, please) ... San Diego, California. Are you already checking flights to San Diego or are you shaking your head in disbelief? I am guessing the latter, and that’s exactly my point.

Something went wrong in this tally by TripAdvisor. Most likely the underlying methodology wasn’t sound. TripAdvisor merely rolled up ratings for individual pizzerias and restaurants around the country and ranked them by city. There’s a little problem with that: context. What TripAdvisor converted to a national ranking were individual ratings made in the context of specific geographies. That’s why you see comments for top-rated San Diego along the lines of “it’s just as good as New York.” These people clearly didn’t see themselves voting in a national poll.

Also odd is that TripAdvisor decided to go ahead and publicize the results of this analysis. Clearly, TripAdvisor saw the potential for buzz with its surprising findings. Yet the flip side of this is the creation of a credibility issue: if TripAdvisor thinks the nation’s best pizza is in San Diego, how can I trust the rest of its information?

A few lessons for the rest of us can be found here. First Big Data is only valuable if properly analyzed. Second, evaluating data supplied by a large and disparate crowd can be tricky. Third, always balance the potential for buzz in the marketplace against reputation risk. Say enough dumb things online and you will hurt your credibility.

TripAdvisor will no doubt say in its defense that it is simply reporting what its users are saying. But if your user base is saying something dumb, it’s probably not in your interest to amplify it. And in fact, the TripAdvisor user base isn’t dumb; their individually smart comments were aggregated in such a way that they yielded a dumb result. But most people aren’t going to dig that deep. They’ll simply say that’s one less reason to rely on TripAdvisor.

A New Push to End Passwords

I hate passwords. But I don’t hate passwords as a concept. Certainly I understand the need, but password protection implemented poorly creates friction and often frustration, and that’s not good for business or for my own personal protection.

Now there’s a new initiative out of Silicon Valley called the “Petition Against Passwords.” It’s not proposing a specific alternative, but the basic premise is that we can do better. And the initiative seems to be getting some early traction. But I think that before we try to improve, we also need to address our failings.

In my view, because online security has become such a high profile concern, many companies have given their programmers carte blanche to “beef up security.” And beef they have, adding all sorts of onerous restrictions, cool new programming and faddish techniques that satisfy their intellectual curiosity, but put a big dent in the overall user experience.

Several years ago, I bought one of the most popular password management programs called Roboform. It actually will provide long, randomly generated passwords for every site where I have an account. Once set-up, I could access any site with a single click. Nirvana! I was fully protected, and friction was eliminated. This was a win for everyone. And it worked. For a while.

But I’ve watched as RoboForm has become less effective, as more sites institute cool new login processes that force you to do more, remember more, and defeat the popular password managers.

I have one site that insists I manually input my password into a virtual keypad on the screen. Way cool, but essentially pointless. I have another site with no fewer than ten challenge questions that it presents randomly, with responses that have to be entered perfectly, or you are locked out and forced to spend 20 minutes with their call center to get back in. Still another site wants a ten character password that includes both a capital letter and two non-alphanumeric characters. And the latest cool approach is “two-factor authentication,” which sends a separate code to your cellphone every single time you want to login. Honestly, can you picture yourself doing this several times (or more) a day? We want more user engagement, not less.

Where I come out is with this simple, three-point proposition:

1. Login security should be proportionate to what you are protecting, a point of particular relevance to online content providers. Let’s be honest with ourselves: we’re not protecting nuclear launch codes.
2. Don’t leave login protocols completely in the hands of your programmers. Logins are a critical component of the overall user experience and need to be assessed accordingly. If users aren’t logging in, they’re also not renewing.
3. For most of us, time would be better spent improving our back-end system security, to reduce the chance of wholesale theft of user logins, credit card data and personal information. That’s where the big business risk resides, although the necessary programming is admittedly less glamorous than virtual keypads.

So sure, let’s start talking about eliminating passwords. But first, let’s acknowledge that a lot of the problem is self-inflicted by the way in which we have implemented passwords.