Text archives Help


[projectvrm] VRM Monetization


Chronological Thread 
  • From: Peter Cranstone < >
  • To: ProjectVRM list < >
  • Cc: " " < >, Gary Rowe < >, Katherine Warman Kern < >, Kevin Cox < >
  • Subject: [projectvrm] VRM Monetization
  • Date: Fri, 5 Jul 2013 17:57:41 +0000
  • Accept-language: en-US

All,

This is an 'opinion'.  It represents my idea of how to monetize VRM so that it scales across everything in the Web ecosystem. I make the following assumptions:
  1. The Identity problem (consumer & vendor) is solved, along with good enough security (multi-factor authentication) After v. 1.0 this will get better
  2. Developers can build either 1) Mobile Apps, 2) Mobile Web Apps and or 3) Use Browser contextual menus to support the solution
  3. A new protocol is added as a layer to HTTP – I'm normally against this but in this case in my opinion (IMO) it's necessary
  4. The solution scales across the consumer and enterprise workspace & reduces the friction in the sale allowing for profits
  5. There's a 'Network' effect to drive revenue and sustainable growth
  6. Integration is simple for VAR's, SI's Developers etc.

Summary:

The goal of this proposed VRM solution is to showcase a potential value proposition that disrupts the current ambiguous privacy business model by providing a method for signaling intent (intent casting), and allowing the use of real time private data to more closely align consumers and vendors. Everything showcased in the image below (with one exception) has already been discussed and at a high level validated. What's been missing up until now (IMO) is the presence of a 'Trusted Web Service Manager'. Think of this as the clearing house for vendors and consumers alike to share their private data to close a sale. 

For monetization to work, VRM needs a 'Network Effect' model very similar to the model that Google has successfully employed. The elegance of the Google model shows that it's self sustaining until there are no more users coming online. It's almost like a perpetual money printing machine. However it relies on one key item – access to your data. If you remove access to your data, or significantly downgrade the accuracy of that data, then the value of the 'printing press' is diminished. So for VRM to disrupt and at the same time monetize, you must provide A) more accurate data in real time and B) Shift it to another space where it can be better rewarded. 

Enter the Trusted Web Service Manager. They coordinate the exchange of your intent and private data with trusted vendors and in doing so extract a tiny sliver of the financial value exchanged. As VRM is a transaction based economy there is the ability to reduce the friction in the sale, lower the cost of the sale slightly, and reward all the players in the ecosystem. The elegance of this solution is that it follows the Google model to perfection – except in this case, the crucial difference is that the precision and accuracy of your data and intentions are kept inside this new ecosystem. The way it's kept in this new ecosystem is via the 'Respect Connect' protocol. This is a layer added on top of the existing HTTP protocol and establishes a respected connection between consumer and vendor. 
  • As a consumer I would be willing to pay $30 a year to belong to the Trusted Web Service Network
  • As a vendor I would be willing to pay $30 a year to belong to the Trusted Web Service Network
  • As an Ad Tech vendor I would be willing to pay to have access to this network
Why – because when operating in this environment the accuracy of the data changes my ability to market to the consumer. Everybody who joins the network does so because it offers value. The network becomes self policing because if vendors and advertisers misuse the data, the social network effect removes them from effectively competing for the business. (The Trusted Web Service Manager steps in to remove them from approved vendors/advertisers).

Disruptions start small and then grow rapidly. Right now there is no trusted service on the web, so we're stuck with the status quo. Binary solutions are inadequate, mobile apps and mobile web apps are not sufficiently easy enough to deploy across the ecosystem to solve this problem, and don't have an easy path to monetization. Google has validated the 'Network Effect' business model – so it would be prudent from a financiers viewpoint to leverage that as a starting point.  So what are the dependancies around building the solution below?

Well surprisingly few…
  • I'd start in one of three places to validate the idea (they're huge networks within themselves, with current revenue models which has NOT been optimized)
    • Financial services network OR Healthcare provider network OR Affiliate shopping network
  • I'd build a trusted web service network manager and constrain it to one of the three places above
  • I'd add the Respect Connect protocol to a mobile browser (Mobile is bigger than anything else) and build the corresponding server side solution (Apache/IIS Mod_VRM module)
  • I'd start signing consumers and vendors up via a really good marcom package
You could easily build the entire solution for less than a couple of million dollars (assuming you stay focused and reign in the feature creep). At the end you'd have a 'network' inside the existing network (internet) that supports trusted data exchanges. You'd have consumers and vendors aligned, you'd have a monthly revenue stream, and it would also support a very small transaction fee that grows as the number of vendors and consumers grow. Essentially it's the Google Printing Press except this time you control the collection, flow and use of your private data. And because it's all browser based it's easy to opt out back to the 'old way of doing business'. 

Doing the same old thing is clearly not working – VRM is still academic and will remain so until it becomes financially viable & sustainable. The only way to do that IMO is to create a VRM network that mirrors the existing Internet. Except in this environment it allows for increased clarity around the transfer of my private data.




Thoughts.







Archive powered by MHonArc 2.6.19.