Category: APIs

Apple HealthKit and VRM

Withhealthkit-hero iOS8, Apple is releasing a pile of new capabilities for developers, such as HomeKit, CarPlay, Family Sharing and HealthKit. These don’t just bring new stuff to your iPhone and iPad. Start digging and you see a framework for personal control of one’s interactions in the world: one that moves Apple away from the norms set by Google, Yahoo, Facebook and other companies that make most of their money in the advertising business.  Explains Greg Lloyd,

Google, Yahoo and others gather correlate, analyze and use personal identity metadata including your location, search history, browsing history to monetize for their own purposes or to sell to others. I believe Apple is trying to build a counter story on security using identity and services encapsulated in devices you own. In addition to continuity, examples include OS8 MAC address randomization for WiFi localization privacy and hardware partitioned storage of iOS fingerprint data.

The italics are mine. Our devices — phones in particular — are becoming extensions of our selves: as personal as our chothes, wallets and keys. They bring new ways for us to engage with people, organizations and other things in the world. There is enormous room for growth in personal empowerment with these devices, especially if those devices are fully ours, and not the hands of advertising companies in our pockets.

Apple, one hopes, aims mainly to enhance our agency — our capacity to act with effect in the world — through our mobile devices. And they have an important advantage, beyond their gigantic size and influence: we pay them. We don’t pay Google, Facebook and Yahoo for most of what we get from them. Advertisers do.

Haydn Shaughnessy unpacks the difference in The Revolution Hidden In The Apple Health Kit :

When you do business with Google, as a consumer, you strike a deal. In return for free search you get ads and for those ads you agree to your data being collected, stored and sold on. The way Apple sees business up ahead, when you use an Apple health service, Apple manages data for you, on your terms. That is a revolution.

health_iconSo, as I’ve been digging thorugh the scant literature on Healthkit and Apple’s new Health app, I’ve looked for ways they line up with VRM principles, goals and tool requirements. Here’s what I see (√ is yes, ? is don’t know. x is no — but I don’t see any of those yet):

VRM Principles

√ Customers must enter relationships with vendors as independent actors
√ Customers must be the points of integration for their own data
√ Customers must have control of data they generate and gather. This means they must be able to share data selectively and voluntarily.
? Customers must be able to assert their own terms of engagement.
√* Customers must be free to express their demands and intentions outside of any one company’s control.

VRM Goals

√ Provide tools for individuals to manage relationships with organizations.
√ Make individuals the collection centers for their own data, so that transaction histories, health records, membership details, service contracts, and other forms of personal data are no longer scattered throughout a forest of silos.
√ Give individuals the ability to share data selectively, without disclosing more personal information than the individual allows.
√ Give individuals the ability to control how their data is used by others, and for how long. At the individual’s discretion, this may include agreements requiring others to delete the individual’s data when the relationship ends.
? Give individuals the ability to assert their own terms of service, reducing or eliminating the need for organization-written terms of service that nobody reads and everybody has to “accept” anyway.
? Give individuals means for expressing demand in the open market, outside any organizational silo, without disclosing any unnecessary personal information.
? Make individuals platforms for business by opening the market to many kinds of third party services that serve buyers as well as sellers
? Base relationship-managing tools on open standards and open APIs (application program interfaces).

VRM Tools:

√* VRM tools are personal. As with hammers, wallets, cars and mobile phones, people use them as individuals,. They are social only in secondary ways.
? VRM tools help customers express intent. These include preferences, policies, terms and means of engagement, authorizations, requests and anything else that’s possible in a free market, outside any one vendor’s silo or ranch.
√ VRM tools help customers engage. This can be with each other, or with any organization, including (and especially) its CRM system.
√ VRM tools help customers manage. This includes both their own data and systems and their relationships with other entities, and their systems.
√* VRM tools are substitutable. This means no source of VRM tools can lock users in.

That’s a wishful reading, and conditional in many ways. The *, for example, means “within Apple’s walled garden,” which may not be substitutable. Greg thinks this isn’t a problem:

…many people value a safer, more consistent, curated, and delightfully designed user experience to a toolkit… I want my personal information and keys to access heath, home, car, family information stored in a walled garden in a device I own, with gated access looking in for Apps I authorize, and freedom to search, link and use anything looking out. Apple appears to be develop its stack top down, starting from a vision of a seamless user experience that just works, giving developers the extensions they need to innovate and prosper.

As a guy who favors free software and open source, I agree to the extent that I think the best we can get at this stage is a company with the heft of an Apple stepping and doing some Right Things. If we’re lucky, we’ll get what Brian Behlendorf calls “minimum viable centralization.” And maximum personal empowerment. Eventually.

I am also made hopeful by some of the other stuff I’m seeing. For example, Haydn quotes this from @PaulMadsen of Ping Identity (both of which are old friends of VRM):

Apple is positioning its Health app as the point of aggregation for all the user’s different health data, and Health Kit the development platform to enable that integration.

In this I hear echoed (or at least validated) Joe Andrieu‘s landmark post, VRM — The User as a Point of Integration.

I also think Apple is the only company today that in a position to lead in that direction. Microsoft might have been able to do it when they dominated the desktop world, but those days are long gone. Our main devices are now mobile ones, where Apple has a huge share and great influence.

Apple is also working with Epic Systems (the largest B2B tech provider to the health care business) and the Mayo Clinic (the “first and largest integrated nonprofit medical group practice in the world”). Out of the gate this has enormous promise for bringing health care systems into alignment with the individual, and for providing foundations for real VRM+CRM connections.

Of course we’ll know a lot more once iOS 8 gets here.

Meanwhile, some questions.

  • Can data gathered in the Health app easily flowed out into one’s non-Apple personal cloud or data store, and then flowed into the health care system of the individual’s choice?
  • In more concrete terms, would a UK citizen with integrated data in her Health app be able to flow that data into her Mydex personal data store, and from there into the National Health Service?  I don’t know, but I hope Mydex, Paoga, Ctrl-Shift and other players in the UK can find out soon, if they don’t know already.
  • Likewise, for the U.S., I would like to know if data can flow, at the individual’s control, back and forth from one’s Personal data vault or one’s Bosonweb or Emmett personal cloud and one’s Apple-hosted health data cloud (or a self-hosted one connected to one’s Apple cloud. And if data can easily flow from those to doctors and other health care providers. In Personal’s case, I’d like to know if data can flow through the Fill It app, which would be a handy thing.
  • For Australia and New Zealand, I’d like to know if the same thing can be done for individuals from their MyWave, Welcomer, Geddup or Onexus personal clouds. I’d also like to know if data in the Health app can be viewed and used through, for example, Meeco‘s app. And what are the opportunities for any of those companies, plus 4th Party, Flamingo and other players, to participate in an ecosystem that has any and all of the companies just mentioned, plus Medicare (the Australian national health service, not to be confused with the American one just for persons 65+)?
  • Same questions go for Qiy in the Netherlands, CozyCloud in France, and many other VRooMy developers in other places. And what’s the play for the Respect Network, which brings consistencies to what many of the developers listed above bring to the market?

In all cases the unanswered question is whether or not your health data is locked inside Apple’s Health app. Apple says no: “With HealthKit, developers can make their apps even more useful by allowing them to access your health data, too. And you choose what you want shared. For example, you can allow the data from your blood pressure app to be automatically shared with your doctor. Or allow your nutrition app to tell your fitness apps how many calories you consume each day. When your health and fitness apps work together, they become more powerful. And you might, too.”

Sounds VRooMy to me. But we’ll see.

 

Turning the customer journey into a virtuous cycle

Traditional CRM typically looks at customers this way:CRM cycleIt’s a cycle. One of the reasons we started ProjectVRM is that actual customers are hard to find in the CRM business. We are “leads” for Sales, “cases” in Support, “leads” again in Marketing. At the Orders stage we are destinations to which products and invoices are delivered. That’s it.

Oracle CRM, however, has a nice twist on this (and thanks to @nitinbadjatia of Oracle for sharing it*):

Oracle Twist

Here we see the “customer journey” as a path that loops between buying and owning. The blue part — OWN, on the right — is literally the customer’s own-space. As the text on the OWN loop shows, the company’s job in that space is to support and serve. As we see here…

… the place where that happens is typically the call center.

Now let’s pause to consider the curb weight of “solutions” in the world of interactivity between company and customer today. In the BUY loop of the customer journey, we have:

  1. All of advertising, which Magna Global expects to pass $.5 trillion this year
  2. All of CRM, which Gartner pegs at $18b)
  3. All the rest of marketing, which has too many segments for me to bother looking up

In the OWN loop we have a $0trillion greenfield. This is where VRM started, with personal data lockers, stores, vaults, services and (just in the last few months) clouds.

Now look around your home. What you see is mostly stuff you own. Meaning you’ve bought it already. How about basing your relationships with companies on those things, rather than over on the BUY side of the loop, where you are forced to stand under a Niagara of advertising and sales-pitching, by companies and agencies trying to “target” and “acquire” you. From marketing’s traditional point of view (the headwaters of that Niagara), the OWN loop is where they can “manage” you, “control” you, “own” you and “lock” you in. To see one way this works, check your wallets, purses, glove compartments and kitchen junk drawers for “loyalty” cards that have little if anything to do with genuine loyalty.

But what if the OWN loop actually belonged to the customer, and not to the CRM system? What if you had VRM going there, working together with CRM, at any number of touch points, including the call center?

This is more than a simple dream. One of the coolest things to happen in the VRM development world is this insight, based on actual technology: everything you own can have its own cloud, and each can live inside your personal cloud. Your stuff doesn’t need to have embedded smarts. You can put your things’ smarts inside clouds of their own. Manufacturers can also include clouds along with everything they sell. Inside that cloud can go all the touchpoint contact data required for a genuine relationship, plus useful extras such as service manuals and shortcuts to product updates.

This means the product itself becomes the platform for relationship between the customer and everybody on the sell side, from manufacturer to distributor to retailer to service company. As I explained in this HBR post, that platform — the product’s cloud — is the level table where all those parties sit, at the grace of the customer. Because it’s the customer’s space.

One tablecloth for that platform is the TalkTag. It’s a simple QR code, like the one on the right. The pioneering company here is Kynetx, through its SquareTag service. It’s a simple way to give anything you have a cloud of its own. Scanning a TalkTag is one way to visit a thing’s cloud, which is also a programmable space. If your thing is lost, you can program it to provide contact information through somebody’s smartphone when they scan it. (Which I have done, and it works.)

You can also program it to, say, notify the call center when you scan it. For example, I want the TalkTag I just put on my cable modem to notify Time Warner Cable when I scan it. If Time Warner Cable’s CRM system is listening (which should be easy enough to make happen), it can send back a message to my phone, telling me there is an outage in my neighborhood. Or, in the event that there isn’t an outage, the “I’ve been scanned” message from me to Time Warner Cable can jump past stages in the company’s IVR (Interactive Voice Response) system and get me straight to the right person or automated response. That might be, “You need to download new firmware,” or “We have three new service tiers you might want to know about,” or “We see you haven’t paid your bill.”

I have shared this kind of scenario with two call center companies recently, and they liked it a lot. In fact they like the whole idea of VRM systems on the customers’ side that can lighten the burdens of relationship (and open opportunities) for both sides.

The customer journey — his or her experiences of owning and buying — will include more than just interacting with call centers. We use the things we own in countless ways that might be useful to share with others, including the companies that make and sell stuff — and not just through “social” systems like Facebook and Twitter, over which we have little or no control.

We should also be able to integrate data from products that don’t relate but should. In the Quantified Self world, for example, there is a standing need to synthesize data from many devices and databases. This need  cannot be solved by asking Nike, Fitbit, Withings, RunKeeper and the rest of them to all make their data un-silo’d and combine-able. And doing it in “social media,” whose only business is advertising at us, won’t work either. We need means of our own.

In the VRM world we’ve been saying the user needs to be the point of integration for his or her own data since Joe Andrieu first expressed that insight in 2007. Now, with personal clouds, in 2013, it’s starting to look possible. In fact the personal cloud, and the whole OWN loop, can also be a platform for intentcasting toward the BUY side.

The OWN side is also where all the privacy technology also sits, chiefly because it is distributed. It is here also that we hold the terms, preferences and policies we express when dealing with companies sitting across the tables set between us.

An interesting case that lies between buying and owning is relationships with service organizations, such as utilities. What we own here is own side of an ongoing relationship. Equipment of our own may be in there, or may not be. Either way, the use of a service — in our homes, cars and pockets — is what we at least control, even if we don’t own it.

So clearly we need a common platform for personal clouds, and for the things we put in them. That platform needs to be small, lightweight, distributed and open source. Right now I see one candidate for that: CloudOS, which is the brainbaby of Phil Windley. (Here’s a search for CloudOS and Windley. Lots of stuff there.) If you’ve got some other hacks, point them out in the comments below.

If we look at the customer experience from the company’s side again, this graphic from Joe Pine and Jim Gilmore does a nice job of framing the possibilities:

Across the table set in a personal cloud, customers can feed back good intelligence to every one of the loops in that graphic. And, because that data arrives directly and voluntarily, it has far higher quality than inferential data gathered by marketing’s many surveillance methods.

It also re-frames relationship and loyalty, as real things rather than as words marketing recites inside its own echo chambers. It will reduce marketing’s urge to manipulate, and advertising’s urge to personalize in the absence of conscious and voluntary signals welcoming it. The customer journey will thus turn into a virtuous cycle rather than the arduous one it is today.

It can also create a demand chain that can work in tandem with the supply chain, providing far better feedback at every stage. I could go on, but I want to get this up before the latest in the series of Important Calls that punctuate my life. (And they are all Good Things, trust me.)

Bonus link.

* In the comments below the post that follows this one, Ray Wang points to Esteban Kolsky as the original author of this graphic. As I say in my comment below Ray’s, I did hear that from Nitin Badjatia (of Oracle and formerly of Right Now), but I didn’t remember it when I wrote both posts in a hurry. Again, it is the verbs — BUY and OWN — that make the image especially useful for VRM, because they are the customer’s. I don’t yet know if those verbs are Esteban’s or Right Now/Oracle’s. Let me know and I’ll give credit where due.

When consumers become media for themselves

I was talking recently with Edi Immonen of Glome about the idea behind it: turning users into publishers. He used the word “media,” but I’m going with “publishers” for now, because that’s the word used in this graphic (one of many like it — all amazing and excellent) from LUMA partners:

That’s the marketer’s view. But how about yours, as the consumer over there on the right. In fact it’s actually more like this:

Because all you do is consume. You have no direct influence on all that intermediary stuff; so it just presses down on you.

But what if you become the publisher — a form of producer, and not just of consumer? Then the system, simplified, would look like this:

This is in alignment with what Tim Berners-Lee designed the Web to look like in the first place, but in in a commercial setting. (Remember that Sir Tim was then working in high energy physics at CERN, looking for ways to share and edit documents across the Internet as it existed at the turn of the ’90s.) It is also what blogging, as originally conceived, also did. If this blog were commercial (which it is not, on purpose), that would be me (or us) on the right.

Now, if we, as publishers, look at our data, or of our personal space — our state as a medium — as a platform for selling and buying stuff, including services, a whole new horizon opens up.

What Edi and his colleagues at Glome envision is a way for you, as a medium, to sell your space (however you chose to define that word) to:

  1. brands with which you already have a relationship;
  2. brands in which you have an interest; or
  3. brands in which you might have an interest.

From the traditional marketing perspective, #3 makes you “qualified lead,” for which the brand should be willing to pay. But that’s a far too reduced view of what you really are, or might be, to that brand.

Think of this marketplace frame from a CRM+VRM perspective. Between those two rectangles, inside the black two-pointed arrow, are cycles of buying and owning, of use and re-use, of live interactions and of long periods of idle time where neither is paying much attention to the other. Lots of stuff can go on within the boundaries of that two-way arrow.

What Glome proposes here is not zero-basing the marketplace, but instead to re-start our thinking, and our work, atop three well-understood existing roles: brand, publisher (or medium) and marketplace. The main re-characterization is of the individual, who is now a publisher or a medium, and not just a consumer.

Obviously much can get disintermediated here, including all the stuff between the marketer and the publisher in the graphic up top.

But much new intermediation is now possible, especially if the individual has a personal cloud through which one (or one’s fourth party) can program interactions, for the individual, among API-based services (in the manner of IFTTT, or using KRL) and the “Internet of things”. (For developers, I believe Singly fits in here too.)

So we are looking here at a whole new market for information and relationships, within the larger marketplace of everything else. This isn’t complicated, really. It’s actually what markets looked like in the first place:

This is the context we meant by “Markets are conversations” in The Cluetrain Manifesto.

LUMAscapes (such as the top one above) brilliantly depict the ecosystems of marketing as they have evolved so far, down different branches of discipline. The tree from which they branch, however, is the old advertising and direct marketing one, now operating inside the Internet . (“Big data” and analytics in marketing are hardly new. They were what direct mail was all about long before it evolved into direct marketing and then spread into online advertising.)

So this is a shout-to —

— as well as all the VRM developers in the world (and it seems there are more every day).

The last graphic above is our new frame. It helps that it’s also the oldest frame.

I also look forward to the day when Terence Kawaja and his colleagues at LUMA partners draw up VRM+CRM and other new ecosystems that are bound to evolve, once enough of us get our heads out of the old marketing frame and into the oldest marketplace one. So this is a shout-out to them too. :-)

Toward a matrix of APIs

At  the 2006 O’Reilly Emerging Technology conference, Cal Henderson, then of Flickr, gave a long session called “Launching and scaling new Web services.” As I recall, among the many things he explained well were some principles behind the Flickr API. One of those principles was user access to data. The API should be one that allowed the user to haul all of her data out of the system, even if it was to federate that data into a competing system. That’s because Flickr believed that user data is the user’s first, and not just the company’s. Another principle was keeping the API stable, so as not to disrupt users and other services that depended on the API.

Cal left Flickr a couple years after that, but Flickr’s API remains a model of stability and utility — so much so that Dave Winer this morning suggested it be declared a national treasure.

Many of us depend in large ways to the APIs of companies great and small — and more get added to that collection every day. For a good picture of what’s going on with APIs, check out ProgrammableWeb.com. Between Dave’s respect for durable APIs like Flickr’s, and ProgrammableWeb’s roster of current and future dependencies, we start to see a matrix of APIs that Craig Burton compares to a city filled with buildings and relationships. Each API provider, like each building, exposes the provider’s core competencies in ways that can be engaged.

But what happens when we each have our own APIs — when our own core competencies become exposed in ways that can be engaged? And when we start managing our lives through relationships between our APIs and those in the rest of the world — especially in ways that are live and full-duplex (two ways at the same time, like a phone call)? And where each of us, or a trusted agent, can do the required IF, THEN, OR and other programming logic, between our own personal clouds and the clouds of others? What will we have then?

There is lots of blogging out loud about this, about both the downsides of dependency (as both Phil Windley and I have, toward Flickr in particular). But I think the upside deserves more than equal consideration, especially as companies begin to realize the importance of direct and engaged relationships with customers and users, which is what we’ll have when VRM and CRM (along with allied functions on both sides) fully engage. The result, I believe, will be a matrix of useful dependencies, based on APIs everywhere, thick with accountability and responsibility. The result will be far more opportunity, and boundless positive economic and social externalities based on the Net’s and the Web’s founding virtues. What will end, or at least be obsoleted, are Matrix-like worlds where users and customers are held captive.

Thus our goal for VRM: to prove that free customers are more valuable than captive ones — both to themselves and to everyone and everything else with which they engage.

 

 

Driving VRM with car data and APIs

Go read OnStar gives Volt owners what they want: their data, in the cloud, by Sean Gallagher, in Ars Technica. It’s a VRM story. The vendor is Chevrolet, the vended product is the Volt, and the relationship management is a DIY hack by one customer. The story begins,

You probably don’t think of your car as a developer platform, but Mike Rosack did. A few days after buying his Chevy Volt, Rosack started slowly mining his driving data. But he eventually revved up his efforts and created a community platform for drivers to track their own efficiency. Today more than 1,800 Volt owners compare stats with each other, jockeying for position on Rosack’s Volt Stats leader board.

volt dash with r-buttonThe Volt uses OnStar, a GM subsidiary known through its advertising for providing a way for drivers to call for roadside assistance; but which is actually a sophisticated cell-based data system through which cars communicate constantly with the mother ship’s cloud. While OnStar generously shares data back to customers through an app called RemoteLink, much more can be done with it, since it’s data and comes out through an API. Now here is where the story gets VRooMy:

Rosack initially wanted to do more with his own driving data than just view it on his phone. So he built what eventually became Volt Stats to capture this data, then started sharing it with other Volt owners. There was just one small problem: Volt Stats relied on Rosack’s reverse engineering of an interface for OnStar’s RemoteLink mobile application (iOS and Android). When OnStar moved to shut down the Web services interface Rosack had plugged into in mid-October, Volt Stats arrived at a screeching halt.

Rather than leaving Volt Stats stalled on the roadside, GM and OnStar accelerated efforts to give developers a new public Web API to create services on top of OnStar data. The companies even worked with Rosack to get him onboard and get Volt Stats re-launched. Now, Volt Stats is back online and other would-be car data hackers will soon be able to connect their Web applications to GM owners’ vehicle data (provided, of course, that they have privacy policies that meet with the approval of GM and OnStar lawyers).

OnStar had already developed an API for GM partners such as the car-sharing service RelayRides, who need to get access to some of the remote control and telematics elements of the service. But this new interface takes advantage of technologies such as OAuth and JAX-RS and it’s a step toward turning OnStar into a broader platform for the “Internet of things.” It’s also a way to give car enthusiasts a new kind of access to something they’ve always thought of as their own—their cars’ data.

Now come the VRM questions:

  • Where and how might customers store that data? Are current PDS (personal data stores) compatible and ready for it?
  • How might customers use that data — especially outside and between multiple vendors’ apps, APIs and relationship silos?
  • Might we see an  ⊂ (r-button) on the dashboards of car? How might that work? And if it does, how do we make it standard?
  • What usage and new market-driving scenarios might we start to imagine here?
  • How might customers assert their own privacy policies and terms as demand begins to drive supply?
  • What other interfaces do cars have that might be brought into the picture?
  • How can what happens here model what we do with the rest of the “Internet of things?”
  • What are the meshy wireless things we can do among ourselves and our cars, outside any vendor’s box? (Would love Robin Chase‘s thinking here.)

These are questions especially for VRM developers. Look for answers (and more questions) here and on various blogs.

© 2014 ProjectVRM

Theme by Anders NorenUp ↑