| CARVIEW |
Team Comment on the "Customer Experience Digital Data Acquisition 1.0" Submission
W3C is pleased to receive the Customer Experience Digital Data Acquisition 1.0 Submission, Member Submission Request from IBM Corporation.
Summary
Web pages are frequently instrumented with JavaScript code that provides analytics data to third parties. In the language of the submission, "Digital Analytics is the collection and analysis of various metrics from multiple digital touchpoints to provide goal oriented, actionable understanding and response to user behaviors."
The Submission proposes to define a JavaScript object that would hold various metadata about an interaction (including both page metadata and data describing a business process implemented on a Web site), ranging from page name to information about registered users and business-process-related events. A standardized JavaScript object could be shared among several pieces of JavaScript code from different sources, and could help to significantly reduce complexity and load time of analytics solutions.
The specification further defines a mapping of these data elements to
shortcuts that can be used to transfer analytics data to a service
provider through an HTTP GET request, called the "Customer Experience
Digital Data Communication Specification."
Next Steps
This specification comes at a time when analytics and user tracking are at the forefront of interest. We concur with the submitters that it will be useful to further review and refine this specification in, initially, a Community Group. Additionally, the Team is working on a proposal for a series of Digital Marketing workshops as a result of the 2012 headlights process and expects to take up conversations about "customer experience" on that occasion.
Specific issues that we recommend to address in such a discussion include:
- Notation. Contemporary ECMAScript APIs are generally defined using WebIDL. Use of that notation would facilitate broader review of this Submission by the Web community. Additionally, we recommend that the authors review the Web API Design Cookbook Working Draft.
- Security considerations of multi-tenant DOM instances. The basic deployment model for this specification is through an ECMAScript library that would expose a global JavaScript object to other pieces of code running within the same global scope. This model discourages the separation of scripts from different origins into, e.g., separate, sandboxed iframes, and encourages situations in which code and data from different trust domains are mashed up without limitations on mutual control and data flows. It would be useful to investigate design approaches that enable a clear separation of different trust domains. Such approaches should, in particular, take the work of the Web Application Security Working Group into account.
- Privacy considerations. It would be useful to discuss the distribution of concerns between client- and server-side processing in analytics, in particular in light of user privacy preferences, such as Do Not Track, under standardization by the Tracking Protection Working Group. The Submission notes potential user privacy advantages in standardized access to analytics data; the Privacy Interest Group might provide a venue for review and discussion of this approach.
- Other vocabularies. The data elements proposed in this specification overlap in scope with existing vocabularies for page metadata and user metadata, such as Dublin Core, the Open Graph Protocol, and the schema.org vocabulary. It would be worthwhile to investigate and discuss the relationship between this work and existing vocabularies.
- Extensibility. While the Submission proposes a rudimentary extensibility model for the JavaScript object exposed, that extension model is not carried through into the communication protocol that is defined in section 6 of the specification as a set of query parameters for use with HTTP GET requests. A communication protocol based on a JSON serialization of the shared object would address this issue in a natural way.
- Internationalization. The submission should be reviewed for internationalization considerations, as some data items such as the address format used or line items such as "Sales Tax" appear specific to certain locales. Addressing internationalization issues will be made easier by a clearly described extensibility model that carries through into the communication protocol.
Please send comments to the public-new-work@w3.org mailing list (archive).
Robin Berjon <robin@w3.org> and Thomas Roessler <tlr@w3.org>