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.
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.
Making them both use the cheapest approach possible to fix the problem? Yeah, that fits almost any E-Commerce project's budget.