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.