Text archives Help


Re: [projectvrm] Very interesting VRM play from UK


Chronological Thread 
  • From: Peter Cranstone < >
  • To: Nathan Schor < >, 'ProjectVRM list' < >
  • Cc: 'Don Marti' < >
  • Subject: Re: [projectvrm] Very interesting VRM play from UK
  • Date: Tue, 3 Sep 2013 02:48:52 +0000
  • Accept-language: en-US

Title: RE: [projectvrm] Very interesting VRM play from UK
Nathan,

The key is how to value that intent data. Price Patrol doesn't put a value on it all, it's simply a convenient way to be notified of a price for a good which is available locally. In this case I would say that the consumer is a prospect or maybe just a lead. In fact there's probably an argument to be said for that he/she isn't an anything until a certain price is reached.

So now how do we put a value on what, which, when and where? When it looks and feels somewhat like Price Patrol. It will come down to marketing, a market segment that has appeal to a certain demographic, and that has a repeat business model which generates measurable, sustainable, profitable revenue from volume.

Again I come back to the empty iPhone sketch - until we can sketch in reality all that exists is fog.

From: Nathan Schor < "> >
Date: Monday, September 2, 2013 7:22 PM
To: 'ProjectVRM list' < "> >
Cc: 'Don Marti' < "> >, "Peter J. Cranstone" < "> >
Subject: RE: [projectvrm] Very interesting VRM play from UK

Peter,

That app, as appealing as it may be, is addressing a different problem from the specific aspect of VRM that Handshake is tackling, which is (as I understand it) customers possess a cognitive asset – their purchasing intent data – that, like any other asset, has marketable value. So it seems reasonable that vendors would eagerly bid to know the what, which, when and where self-declared customers aspire to acquire. Handshake’s challenge is to ignite the exchange of data-for-dollars in a way that both parties find compelling, so each side obtains the benefit they respectively value the most – noticeable cash for customers and improved transaction efficiency for sellers.

 

 

From: Peter Cranstone [ ">mailto: ]
Sent: Monday, September 2, 2013 3:24 PM
To: Nathan Schor; ProjectVRM list
Cc: 'Don Marti'
Subject: Re: [projectvrm] Very interesting VRM play from UK

 

Nathan,

 

http://pricepatrolapp.com/ will solve the problem and doesn't require any behavior changes on the part of the user OR infrastructure changes on the part of the vendor. In fact it's really about a smart filter that looks for things that I specify. But then again I can easily do what with Amazon or Google. 

 

 

 

 

Peter

_________________________
Peter J. Cranstone
CEO.  3PMobile

Boulder, CO  USA



Improving the Mobile Web Experience



Cell: 720.663.1752

Web site: www.3pmobile.com

 

CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain information that is confidential or legally privileged. Any unauthorized review, use, disclosure or distribution of such information is prohibited. If you are not the intended recipient, please notify the sender by telephone or return e-mail and delete the original transmission and its attachments and destroy any copies thereof. Thank you.

 

 

From: Nathan Schor < "> >
Date: Monday, September 2, 2013 4:15 PM
To: ProjectVRM list < "> >
Cc: 'Don Marti' < "> >
Subject: RE: [projectvrm] Very interesting VRM play from UK

 

Don,

In the real-time case you describe, there may not be much incentive. But, here is a scenario where trading data-for-dollars benefits both customer and vendor.

A customer is planning purchase of a stoveand several days prior to purchase they know which brands are in their consideration set, as well as when and where they are likely to complete sale. Surely that quartet of data -what (item),which (brands),when, andwhere – is valuable to sellers.The commercial success of VRMdepends on vendors believing thatbuyingsuch anintentcast from an in-market customeris much more efficient than broadcast a message to the very many in the hopes of enticing the very few.

To prevent buyer’s from gaming the exchange or not following through, they are only paid if the sale takes place. So there is no risk for either party to participate. 

Another motivator for buyers to intentcast is that their intent details are perishable, in the sense of having value onlyprior to sale. So if buyers keep their data confidential prior to negotiating the sale then neither party benefits, but if they exchange it, then both benefit.

Of course, whether the operational details that Handshake proposeswill workfor examples like the one aboveis to be determined, but I don’t see any showstoppers to their approach.

Nathan Schor 305.632.1368 ">

-----Original Message-----
From: Don Marti [ ">mailto: ]
Sent: Monday, September 2, 2013 2:05 PM
To: Nathan Schor
Cc: ProjectVRM list
Subject: Re: [projectvrm] Very interesting VRM play from UK

begin Nathan Schor quotation of Mon, Sep 02, 2013 at 12:36:22PM -0700:

> Handshake Is A Personal Data Marketplace Where Users Get Paid To Sell

> Their Own Data

>

>http://techcrunch.com/2013/09/02/handshake/

I completely don't get this.

Any intent information that is valuable to a vendor is more valuable to me.

Here's an example.  It's a summer weekend, and I'm walking through an anchor store at the mall, looking at khaki pants.

Here are two pieces of intent information.

  "I'm cutting through the store on the way to pick up

  my car at Sears.  I wonder if there are any decent

  khaki pants on sale, since I could probably use

  another pair."

  "I ripped my last pair of khaki pants and I have a

  meeting in Palo Alto on Monday morning.  I have a

  lot of stuff to get done and I'm not leaving this

  store without a new pair."

What's my incentive to reveal which intent is the true one?

Can anyone come up with a scenario in which selling my intent information is more valuable to me than keeping it confidential when I go to negotiate a purchase?

--

Don Marti                      +1-510-332-1587 (mobile)

http://zgp.org/~dmarti/        Alameda, California, USA

">




Archive powered by MHonArc 2.6.19.