IBM, Google, Best Buy May Have Cracked E-Commerce Pain Point

Written by Frank Hayes
July 11th, 2013

A group of dozens of tech firms—and two major retailers—are working on a standardized way of storing E-Commerce data for websites as JavaScript objects. IBM, Google, Adobe, Accenture and other IT software and services suppliers are backing the proposed Customer Experience Digital Data Acquisition standard, and they went public with it last week after submitting it to the World Wide Web Consortium (W3C) in May. But only two large retailers have people working on the standard: Best Buy (NYSE:BBY) and HSN (NASDAQ:HSNI).

That’s too bad, because the problem of all the incompatible, vendor-specific data formats for shopping carts, product identifiers, transactions and customer information is costing retailers money to integrate and maintain E-Commerce sites. It also locks chains into specific vendors’ formats—and vendor lock-in is very much a dollars-and-cents issue in retail IT. Any retailer’s E-Commerce group that doesn’t start tracking this effort now may soon either be paying or playing catch-up.

The issue is painfully familiar to application developers: Every vendor seems to use different data formats for things like user information, product data and transactions. The data involved may be the same—a Zip code, say—but one vendor might store it as an ASCII string, another as an integer, a third as part of a complex address object.

Inside each vendor’s component, that’s not a problem. The trouble comes when the piece IBM did needs to pass information to the piece Accenture did (or the bolted-on Oracle product, or the never-designed-for-this In those cases, every piece of data has to be translated from one format to another—and since no two vendors necessarily use the same format, and even the same vendor might not use the same format as last year, there’s a lot of custom software plumbing being done.

That requires a lot of testing. And fixing. And plenty of retesting every time there’s a change. And because there’s so much one-off code, it’s much more brittle than you really want a business-critical system to be.

The Customer Experience group’s approach—creating a standard for those connections—means IBM and Accenture and Oracle can just build one extra interface layer. If they get it right, their components will be able to exchange data with anyone else’s that has that standard interface. (Think Ethernet or TCP/IP—you plug it in, it works.) And if Salesforce doesn’t support that standard interface, it still takes just one layer of standard-to-Salesforce glue to make it work.

Better still, this JavaScript approach is wonderfully elegant, in part because it’s probably the cheapest way to fix the problem. The one thing every web browser has is JavaScript, so storing the data as JavaScript objects, with a base object called digitalData and specifications for how common pieces of E-Commerce data are to be stored, solves several political problems along with the technical issues.

First, no vendor gets an expertise advantage, because they all already know how to use JavaScript. Second, JavaScript is already embedded in web browsers, so nobody’s making any money by selling add-on software to implement the standard. And third, once it’s a standard, it will be possible to test compliance by plugging components together and seeing if they successfully communicate—a sort of E-Commerce Data Connectathon.

Needless to say, it’s not a cure-all. The draft spec includes formats for page identifiers, product IDs, shopping-cart IDs, transactions and event, with details drilling down to product category, price, currency, coupon discounts, payment and shipping information and user details. That’s the common stuff, but it’s almost certainly not all the data that a complex E-Commerce site may need components to exchange.

But even an ad-hoc JavaScript object to move that less-than-common data around is better than what developers have now, which is typically two competing vendors, each happy to blame the other for a connection that doesn’t work perfectly.

Making them both use the cheapest approach possible to fix the problem? Yeah, that fits almost any E-Commerce project’s budget.


Leave a Reply

Readers, specifically those who want to comment on a story:
Our Comment SPAM system is getting very aggressive these days and has been blocking legitimate comments. If you post a comment and don't see it appear within 2 hours or so, can you please send a heads-up to Ideally, please include the time you posted the comment. That will allow us to try and hunt for it. Thanks! P.S. We're working on fixing the system, but we don't want to lose any valuable comments in the meantime.


StorefrontBacktalk delivers the latest retail technology news & analysis. Join more than 17,000 retail IT leaders who subscribe to our free weekly email. Sign up today!

Most Recent Comments

Why Did Gonzales Hackers Like European Cards So Much Better?

I am still unclear about the core point here-- why higher value of European cards. Supply and demand, yes, makes sense. But the fact that the cards were chip and pin (EMV) should make them less valuable because that demonstrably reduces the ability to use them fraudulently. Did the author mean that the chip and pin cards could be used in a country where EMV is not implemented--the US--and this mis-match make it easier to us them since the issuing banks may not have as robust anti-fraud controls as non-EMV banks because they assumed EMV would do the fraud prevention for them Read more...
Two possible reasons that I can think of and have seen in the past - 1) Cards issued by European banks when used online cross border don't usually support AVS checks. So, when a European card is used with a billing address that's in the US, an ecom merchant wouldn't necessarily know that the shipping zip code doesn't match the billing code. 2) Also, in offline chip countries the card determines whether or not a transaction is approved, not the issuer. In my experience, European issuers haven't developed the same checks on authorization requests as US issuers. So, these cards might be more valuable because they are more likely to get approved. Read more...
A smart card slot in terminals doesn't mean there is a reader or that the reader is activated. Then, activated reader or not, the U.S. processors don't have apps certified or ready to load into those terminals to accept and process smart card transactions just yet. Don't get your card(t) before the terminal (horse). Read more...
The marketplace does speak. More fraud capacity translates to higher value for the stolen data. Because nearly 100% of all US transactions are authorized online in real time, we have less fraud regardless of whether the card is Magstripe only or chip and PIn. Hence, $10 prices for US cards vs $25 for the European counterparts. Read more...
@David True. The European cards have both an EMV chip AND a mag stripe. Europeans may generally use the chip for their transactions, but the insecure stripe remains vulnerable to skimming, whether it be from a false front on an ATM or a dishonest waiter with a handheld skimmer. If their stripe is skimmed, the track data can still be cloned and used fraudulently in the United States. If European banks only detect fraud from 9-5 GMT, that might explain why American criminals prefer them over American bank issued cards, who have fraud detection in place 24x7. Read more...

Our apologies. Due to legal and security copyright issues, we can't facilitate the printing of Premium Content. If you absolutely need a hard copy, please contact customer service.