It's also worth noting that Wells Fargo now offers several forms of
ditial receipts for ATM transactions, including sending it to your
email of record.
I think the real trick is to be able to streamline the secondary uses
of receipts for the authorizing vendor, e.g., returns, rebates,
warranties, recalls and various customer service issues. It's all fine
that a vendor pushes out data in a friendly format, but it will take
the game to a whole new level when they accept that data back into
their system as a proof of purchase.
-j
Joe Andrieu
">
+1 (805) 705-8651
On 5/27/2011 2:24 PM, Iain Henderson wrote:
"
type="cite">
Sure, there are issues to be addressed, but none un-resolvable over time.
I'm a believer in going after the easy bits first, and using the momentum that generates to build out. For example, in UK a huge proportion of £'s spent on groceries is with one company (Tesco), who already digitise receipts for the vast majority of their customers (who have Clubcards). I should have an option to opt out of paper receipts at the till, have that preference tagged in my Clubcard account, and have the receipts and data at item level fired off into my personal data service.
There's nothing difficult about that. Come to think of it, we'll raise that with them, and the others in the UK.gov mydata project.
Iain
On 27 May 2011, at 17:35, Mark Lizar wrote:
Very Good Points Charles,
Iain, Luk do your backends cover some/all of these issues?
Alternatively, a work around to alot of these problems can be achieved with an install program that enables the vendor to map the fields of the receipts to the Online Data Store upon installing the vendor side application.
There are other tricks as well.
MOOOOOO!
On 27 May 2011, at 15:40, Charles Andres wrote:
A few of the obstacles -- and the ultimate standard -- English language*, Arabic numbers , unambiguous context - a place where lawyers can agree that the receipt is intelligible to both parties.
*(Mandarin is perhaps less efficient as context requires tonal parsing and much larger character sets)
Receipt issuers have little interest in conforming to a data interchange standard.
The receipt is considered a record of a private contract between two parties; not an information source to be used for other purposes.
Further, the information on digital receipts is wildly variable. The only common datum are the date (with finite format variances) and the total amount charged, lumping together individual items, tax, etc which appear differently from every distributor/state-province. There are services like shoeboxed.com that can perform this elementary level of parsing even for paper receipts. To go to the next level, parsing needs to be done on a case by case basis. You could create rules for Amazon, Apple, EBay, etc. and maintain updates as their formats change from time to time but doing this needs to be pooled for efficiency -- infrastructure services could do this, but they need to sell this to someone.
At least the digital receipt can be converted to ASCII if it is not already in that fundamental form. Paper receipts have the additional character to ASCII parsing problem. Then you need to interpret the meaning of the ASCII strings and normalize it into defined data fields that can be used for other purposes. Data cleansing may require manual intervention.
Suppose a standard is proposed. It then needs to be adopted by a significant number of retailers to be considered a useful standard for any data gathering system. This is difficult to make happen without either a federal mandate or a significant business advantage that continues after the leveling effect of universal adoption. Ahead of that, the advantage has to be sold to each distributor so they budget the funds to adopt and support the standard.
While we wait, parsing algorithms get smarter, but this is a tough problem to solve.
So there you have it -- the cowboys (sellers) herding cattle (buyers) are not interested in the divinity of bovines (re: Craig Burton) or cow equality. They like the system the way it is. But as the herd acquires smarter affordable gadgets, they will cause defacto open standards to emerge that can free the data to be used in multiple ways to benefit the cows (buyers).
Viva la Vaca!
- The Mad Cow
P.S. As dairy farmers well know, the fence holding the cows in is puny, but the herd respects it most of the time (zap). Now and then, one of the herd tramples down the fence and the cows escape for a while, usually in the spring. The cost-benefit ratio of flimsy fence / number of break-outs is within acceptable bounds. Warning: more break-outs inevitably leads to stronger more expensive fences and higher milk prices. YMMV ;-)
On May 27, 2011, at 3:15 AM, Iain Henderson wrote:
Yes, and let's not forget the offline world. A colleague of mine covered digitising receipts in her MSc thesis and came up with fascinating numbers, like the miles of paper that supermarkets churn out each week that go straight in the bin. Much of this is just a legacy way of doing things crying out for a standardised fix.
Count me in for this project work if we get it going.
Iain
On 27 May 2011, at 00:58, Doc Searls
"><
> wrote:
On May 26, 2011, at 5:32 PM, Brian Behlendorf wrote:
Why not a standard for emailed purchase receipts?
Great idea!
Could it be there's already one we don't know?
For no good reason, today I get email messages confirming purchases in all sorts of different formats. One could pretty easily imagine a standard that preserved the ability to view the message in an HTML-ish mail client, but which also embedded enough metadata (microformats-style, or as a small attachment a la VCF) to allow a message to be fed to a client-side application that did interesting things with the data - like helped me keep track of purchasing habits, a personal-property inventory system for insurance purposes, a warranty tracking system so that when X breaks I know quickly what number to call and if it's still in service, etc. It could also thus feed a VRM system entirely client side, or on a personal cloud of one's choice, in a manner much more semantically meaningful than free text association.
Then, let a thousand All My Purchases apps bloom.
Brian
Yay! Let's do it.
Doc
e-mail:
">
blog: www.iainhenderson.info
twitter: @iainh1
This email and any attachment contains information which is private and confidential and is intended for the addressee only. If you are not an addressee, you are not authorised to read, copy or use the e-mail or any attachment. If you have received this e-mail in error, please notify the sender by return e-mail and then destroy it.
|