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

Tools

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 Salesforce.com). 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.