A couple of weeks ago, we explored the Future of Social Networks which we see evolving towards:
- friends over followers
- future over past
- activities over posts
In this post we would like to share a couple of the business models that could support these activity centric social networks. But, before we do that let’s start by looking at the implications of shifting from a knowledge centric point of view (the Web) to an activity centric point of view (the Platform).
Don’t Underestimate SmallData
It does sound a bit trivial to state that we perform a lot of activities with our mobile devices, far more than we ever did with our computers: we purchase our morning coffee, we deposit checks, board a plane, we go places, we take pictures and videos, we learn, we measure our blood pressure, change thermostat settings, select something to watch on TV, open and rent a car … and that list is not even the tip of the iceberg. Our phone is rapidly becoming a universal remote.
And, even though we are nearly 5 years into the “smartphone” revolution, there is one large area of the Platform architecture that has not been explored: Mobile App Integration. As smartphones enhance every task we do and every action we take, we can expect every task and action to produce invaluable “cues” that could be reused to support other activities from the same user (or from other users) using completely different apps. That’s what we call “Small Data”, very small data.
We define small data as the data exchanged between two apps that are either under the control of the same end user or an end user and its direct social network (relatives, friends and acquaintances a.k.a RFAs).Image may be NSFW.
Clik here to view.
The lion share of the Platform’s business model is going to be driven by Small Data. Why? Because apps won’t need to guess what we want, SmallData is made up of the exact events (location, time and activity) of our lives and can provide other apps with a wealth of cues that will make them behave exactly as we wish. Most of what there is to know lives on our devices and the ones of our relatives, friends and acquaintances (the RFAs).
For instance, I may need to replace my old washing machine. I can tell my “To Do” app that I need to accomplish that new task (a well defined task). I could even enter right there a price range, features and rankings of the product. You can easily guess the kind of dialog you would have with Siri or Google Now. That information becomes instant context for all the apps I visit next on any of my device.
I can also connect easily the physical environment of my tasks by scanning QR codes or using picture-based database queries.
BigData and Machine Learning algorithms may provide insight over our very next moves, but there is some big barriers that Small Data can help level. BigData cannot guess the tasks we have to do, the problems we have to solve. BigData can only guess what we may want to do. Precision is another big barrier that BigData can rarely address. How many times do you search for something, end up buying it and continue seeings ads for weeks that are trying to sell a product you already own. Imagine how many opportunities to sell complementary products, or simply to ask feedback are lost? SmallData can inform your apps of the tasks you are trying to accomplish and whether you are done buying this washing machine you needed. How valuable is that?
We are at this fascinating moment in time where, from a business point of view, and for all intent and purposes we live in an “unRelated” world, and there is this massive revolution marching (let’s call it the SoMoLoCo revolution) which is all about surfacing, realizing and enhancing all the relationships that make up our lives as part of the activities we do. When we say relationships, we mean of course the relationships between people, but also between people and tasks, things or places. SmallData is at the core of that revolution.
The Web Architecture is not optimized for a Task Centric World
In a “related” world, the opportunities to share cues abound but we need a new kind of apps which can exchange seamlessly specific data elements on the same device or beyond, with friends for instance, or with a community. Cues could of course be aggregated across a community and be made available as such.
This exchange of contextual “cues” has been going on, at least, for as long as the Web became commercial, but today, the Web is facing a major disruption that directly challenges its business model: architecturally, the Web always mandates a 3rd party server-side integration to mediate the exchange of information between two apps (think double-click), unless there is a direct hop from one application to the next (think Facebook’s referer).
In the washing machine example, the Web architecture would require either a back-end integration between the To Do app and merchants, or it would require that you always enter a merchant app through the To Do app. Neither are really practical. The problem here is that activities relate to each other in a way that is quite different than simple bits of knowledge, propagating the context of a search to an ad is far easier than propagating the context of a trip to a series of activities.
That fundamental shift requires a new application integration model as mobile apps are weaved into every task we perform. One could argue, of course, that Amazon could shift from being a “Catalog” to becoming a mundane “To Do” app, but would they have that kind of insight? BigData is in their DNA, they actually don’t know much about the tasks customers are trying to accomplish. Before they build that kind of knowledge, there would be a lot of room for alternatives to grow. Other retailers will have to quickly come up with an alternative solution and architecture anyways.
Application integration is a very old idea but today mobile platforms are changing the game. They enable the sharing of cues between trusted users, using trusted apps and mediated by a trusted party. This is somewhat new, trust has never really been part of Web application integration. Quite the opposite actually. You cannot underestimate how much disruption can result from trusted integrations.
So, the key success factor here is to enable the apps on your device to securely and privately share information without requiring a complex temporal integration involving a 3rd party service. The information is produced and consumed on the device or the device of a related end-user. What happens on your device can now stay on your device (sort of).
Just to be clear, and to show how disruptive this architecture is, the primary identifier of your private data becomes your phone. Merchants no longer need to identify you. They can’t care less about YOU, they just care to know some information about you. The problem with the Web Architecture was that the only way to do that was by identifying you and tracking your every move.
This can be achieved with a protocol based on the fact that the device OS (and the Platform behind) is a trusted party for the user, friends, commercial partners… and has the ability to both establish the identity of the applications which share the information, enforce consent of the end-user for the sharing to happen, enrich the integration, report on transaction for commercial applications, …
This is why protocols are likely to be a lot more important than “services” moving forward. The Web has trained us to build dumb clients and centralize anything of value on the server, at a huge cost and never enough trust. We can predict that light-weight protocols, mediated by the mobile OS (and its Platform) will directly challenge the Web architecture, precisely because we can leverage the platform trust model. That evolution is extremely profound.
With all that being said, let’s look at a couple of scenarios where we see valuable protocols emerging.
We saw in our last post, with the Starbucks example, that Automated social events, integrated with the tasks consumers are doing are going to be a big part of the future of Social Networks.
There is also an extreme value in decoupling the way cues are captured, stored and shared. On the Web this is done in a monolithic way, and you have to become a Google AdSense to monetize it. There is a real opportunity in enabling developers to focus on capturing and using cues while the Platform manages and mediates the exchange of these cues in a trusted way. Again this paradigm shift is profound because we are no longer dependent on Google dictating the resulting service (ads) and the information being exchange. A platform based architecture can support many more information sharing scenarios. We actually argue that a trust-based neutral Platform supports a more vibrant and diverse ecosystem than a truly open model.
Platform operators (Google, Apple, Microsoft, RIM…) will enable that architecture because they will continuously seek ways to monetize the trust they established. The paradox is that because the Web is open, any integration between services start by establishing a form of trust and most often that leads to identifying a useful use case (such as AdSense) and mining it, at the expense of many more, but slightly less valuable, use cases.
Share information, Share Revenue
As apps align with the tasks end users are trying to accomplish and as these tasks coordinate several actions, we can expect that applications will see value in exchanging larger number of cues.
The Platform can report on the connection between the usage of a cue (produced by App 1) and a sale performed on App2 in the context of the cue provided by App1. That kind of information sharing mechanism can support a healthy affiliate ecosystem, far more diverse and effective than what AdSense could ever do. So what would the protocol look like? Here is a proposal: 1) App 2 developer sets up a commercial campaign to promote the sharing of clues with its application 2) App 1 developer configures his app to provides the clues when end user uses his application.
- Step 2 App 1shares the specified clue.
- Step 3 App 2 queries the clues
- Step 4 End user makes a purchase based on clue
- Step 5 App 2 reports the purchase to the platform (optionally completes the purchase with the platform)
- Step 6 The device communicates the transaction to the platform server (including, campaign identifier provided by App 1 with the clue, identiy of application 1). The platform mediates payouts from developer 2 to developer 1
3) an alternative flow is to provide the cues a 3rd party service for marketing / research perspective
Image may be NSFW.
Clik here to view.
With such protocol the information never travels to a developer server prior to its consumption, the end user is not “tracked”. It is only shared as needed on the end-user device for the benefit of the end-users or with the devices of trusted related end users (RFAs), or completely anonymously, as simple stats.
Social Data integration
We describe here a simple protocol that enables the “social” sharing of cues.
Image may be NSFW.
Clik here to view.
A trusted platform may also share this information with a trusted group of users (for instance friends), either anonymously, or specifically, with the identity of the first user. (steps 5: and 6:).
The key though is that your friends can now use a completely different set of apps and still benefit from the sharing of cues.
For instance if users open the Fandango application, they might be interested in seeing a percentage of friends who saw or speak about any given movie (anonymously) combining the information from social network posts, iTunes purchases,…. For the Fandago app, this information has a lot of value because it does not need to build that integration, on its back-end, track who is friend with who and who consented to share this information. It would be extremely difficult for every user to manage their social network based on sharing actions such as purchasing a movie ticket or replacing a washing machine.
Social Networks will align with end user interests, but not with every tasks they do. The platform may also aggregate some of these cues and offer aggregated / anonymized information to a group of users. For instance, people checking in at a restaurant or purchasing movie tickets may give a good idea of the wait time. It may also give local statistics for popular movies, restaurants, events, transportation, …. Cues could also be augmented with the help of a 3rd party service (Step 8) after being produced at step 2 and before they are consumed by step 3. In other words a series of additional clues could be made available to the device OS that neither app 1 or app 2 could infer on their own, just by the user sharing a clue on app1.
With these kinds of protocols, and unlike the Web, the production and consumption of cues has the highest value when the contexts of the apps are connected. A cue-based affiliate model is no longer about delivering “ads” but by making commerce more effective, nearly frictionless, by sharing the right information between the actors that can really make sense of it as users take specific actions. Of course, all this can only be enabled if the end user is given control over:
- the consent for an application to share a cue with other applications
- the topology of the data integration between applications. For instance a user could be presented with a view of the cues surrounded by apps that would allow to “slide and drop” cues to a particular application.
The very open nature of the Web is driving scale over scope. The Web has successfully nurtured the largest Catalog, the largest Search engine, the largest Auction site, the largest Social Network, but we see this as a drawback because it limits the scope of what people can do. In other words, the scope of what Amazon, Google or Facebook offer is limited by the scale (and hence the revenue) they can achieve.
The Platform architecture, and what appears to be a closed system, turns that model on its head. The Platform which has already achieved scale can now focus on scope and has the potential to create business models and ecosystems that are far more varied and efficient to solve our every days problems while not compromising our privacy. The platform could for instance support sharing all our activities’ context in the privacy of our devices. We strongly believe that the Web as it stands will not be able to resist that kind of disruption. We expect Business Models will align towards:
- activities over knowledge
- small data over big data
- trusted data sharing over “sniffing around”