Abstract

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document is the Customer Experience Digital Data Acquisition 1.0 Submission.

By publishing this document, W3C acknowledges that the Submitting Members have made a formal Submission request to W3C for discussion. Publication of this document by W3C indicates no endorsement of its content by W3C, nor that W3C has, is, or will be allocating any resources to the issues addressed by it. This document is not the product of a chartered W3C group, but is published as potential input to the W3C Process. A W3C Team Comment has been published in conjunction with this Member Submission. Publication of acknowledged Member Submissions at the W3C site is one of the benefits of W3C Membership. Please consult the requirements associated with Member Submissions of section 3.3 of the W3C Patent Policy. Please consult the complete list of acknowledged W3C Member Submissions.

Table of Contents

1. Introduction

Collection and analysis of visitor behavioral and demographic data has become an integral part of web design and website success. This data is central to site performance analysis, dynamically tailoring site content to visitor activity and interest and retargeting visitors based on behaviors.

Increasingly, multiple vendors are involved in the data collection process on a given digital property, and each has a solution that needs to be implemented on the web page. As a result, page design has become more complex and development cycles lengthen as different requirements for data surfacing and formatting are added to the design process. Furthermore, changing or adding vendors typically requires that the client development team change the page design to accommodate vendor requirements. The common data items must be continually surfaced in different ways for different vendors and each design requirement is a custom effort, contributing to the lengthening development cycles. Clients are searching for a simpler, flexible and standard method to surface this common data on the web page and across their digital properties.

2. Terminology

3. Rationale for this Standard

Customer Experience digital data items that are tracked and captured by different vendors are commonly understood elements used in digital analytics, but vendor specific format requirements and code assignments create design complexity and vendor dependency in site design.

As a simple instance, vendorA may capture some digital data for page details as a concatenation of ‘PageID + PAGENAME + PAGECATEGORY' while vendor B may capture the same through distinct variables vendorB.page.pageId, vendorB.page.pageName, vendorB.page.pageCategory. Further, the names of the variables, the data structure name & types and methods of extensibility all vary on a per-vendor basis. Frequently, custom code must be written to capture data to meet a given vendor's requirements.

Cumulatively, differences of this type between vendors permeate across all relevant customer experience digital data objects including Order, Shopping Cart, Registrant and more, increasing the complexity of customer experience digital data management at the site.

To this end, a Standard data object that represents the common data elements in a standard way will allow development teams to implement standard design structures that populate the Standard data object. Vendor code placed on the page would reference that standard structure, simplifying the process of on-boarding or changing vendors, and shaving off expensive development cycles.

The proposed Standard data object is a JavaScript object because of ubiquitous support for JavaScript in web browsers and web based applications, as well as in other forms of digital properties like mobile & kiosks and so forth.

The use of a JavaScript object means that the data is not embedded in the html markup and would not affect page registration or performance. Developers would only need to populate the data fields in the object that are applicable to the page, keeping the size and complexity of the object to a minimum. That coding would never change regardless of page requirements vis-a-vis vendor additions or deletions unless new data elements were required. Because the data is a standard object, vendors who recognize the object would provide code that references that object, requiring no modification of the page other than to drop the vendor code container onto the page.

This standard will thus yield a shorter development cycle using fewer resources and there will be a savings to the client in time and money. The addition or deletion of vendors will be independent of considerations of page redesign, allowing decisions to be made based on vendor efficacy rather than cost of migration.

4. Conformance

5. Customer Experience Digital Data Object

This section details the JavaScript Object structure to be used whenever the corresponding data value needs to be surfaced.

5.1 The Root JavaScript Object

This section is normative

The root JavaScript Object (JSO) MUST be digitaldata, and all data elements used in web analytics MUST derive off of this JavaScript Object either directly or indirectly.

5.2 Page Identifier Object

This section is normative

Page Identifier is among the most widely used web analytic data element, and is among the top level web analytic objects. A Page Identifier MUST have the following Object Name & Type.

5.3 Page Details Object

This section is normative

Page Details Object carries significant details about the page, and the most commonly used data elements are captured by the specification below. Page Details MUST have the following Object Name & Type.

5.4 Product Object

This section is normative

Product Object carries details about a particular product with frequently used attributes listed below. Product Object MUST have the following Object Name & Type.

5.5 Cart Object

This section is normative

Cart Object carries details about items in cart. ‘Items' is an array under Cart Object. Cart Object MUST have the following Object Name & Type.

5.6 Order Object

This section is normative

Order Object consists of Order Object and the Products and Address sub Objects. Order Object and the sub objects of Products and Address MUST have the following Name& Type.

5.7 Registrant Object

This section is normative

A registrant is a visitor who logs in or registers at the site, sharing additional information during the process. Analytic data details related to a Registrant MUST be captured in the following Object Name & Type.

5.8 Elements Object

This section is normative

Element identifies specific objects on a Page such as flash movies, videos, portlets and similar content. Typically used for tracking dynamic elements of page content. The Analytic data object MUST have the following Object Name & Type to surface this information.

5.9 Events Object

This section is normative

This object populates event tags on a page and is used to track an event that has a start and stop - for example, an application, a submission or an event that should be tracked separately from content. This object tracks non-mercantile transactions; mercantile transactions are tracked usd the differential between the cart and order object. Event objects MUST follow the name & type indicated below.

5.10 Extending the Customer Experience Digital Data Surfacing Objects

This section is normative

Extensions or custom analytic data locations may sometimes be needed to collect unique, vendor or client-specific data that is not part of the standard.

It is RECOMMENDED that all extensions or custom digital data locations be derived from the root digitaldata object, with a custom.companyid added at the level of the hierarchy where the extension or custom field is being added.

For instance, to add some custom digital data fields, the object would look like:

The fields after custom.companyid are completely unique to the vendor/client requirements.

5.11 Usage Sample for Customer Experience Digital Data Object

This section is informative

Product Detail Page

To surface data for a typical product detail page using the JavaScript object we would instantiate the standard page related 
digital data values as well as data for the individual product displayed:

  digitaldata = 
  { page:
        {pageid:'PRODUCT:PRODUCTNAME(PRODUCTID)',
         categoryid:'categoryid',
         searchterm:'', searchresults:''},
    

    product:
        {productid:'productid',
         productname:'productname',
         categoryid:'categoryid'}
  }

Shopping Cart

This example creates the data object for a typical web cart. Analytics page information is created as well as entries for each of the products carted.

  digitaldata= 
  {cart:
    {items: new Array()},
    page:
        {pageid:'CART',
         categoryid:'CART',
         searchterm:'',
         searchresults:''}
  };

  var counter=0;

  for (counter=0; counter<=1;counter++ )
  {digitaldata.cart.items[counter] =
    {productid:'productid'+counter, productname:'productname'+counter, quantity:'1',
     baseprice:'99.99', categoryid:'categoryid'}
   };
	 

Order Page

  A typical order thank you page is very similar to a cart page but will typically collect information about the customer. In this example, page information,
    order information, customer information and individual information on purchased items are collected.

   digitaldata=
   { order:
          {orderid:'123456',
           ordersubtotal:'199.98',
           shippingcharges:'10',
           registrationid:'registrationid',
           address:{city:'austin',state_province:'tx',postalcode:'78759'},
           {items: new Array()},
     page:{pageid:'ORDER CONFIRMATION',
           categoryid:'ORDERCONFIRMATION',
           searchterm:'',
           searchresults:''},
     registrant:{registrationid:'registrationid',
                 email:'email@address.com',
                 address:{city:'austin',state_province:'tx',postalcode:'78759',country:'us'}
                }
   };

  var counter=0;
  for (counter=0;counter<=1;counter++ )
  {digitaldata.order.items[counter] =
                     {productid:'productid'+counter,
                      productname:'productname'+counter,
                      quantity:'1',
                      baseprice:'99.99',
                      categoryid:'categoryid', 
                     }
  }
  
	 

6. Customer Experience Digital Data Communication Specification

This section is normative

This section details the parameter list used for communicating Customer Experience Digital Data to the analytic servers. Data is typically communicated as parameters on an Http GET request, and so the parameter list would show up as:

http://datadomain.com?pi=pageID&cg=categoryID

In the table below, the first column carries the standard names of the parameters; these names are terse to accommodate length limitations on HTTP requests, though newer browsers are supporting longer lengths. The second column identifies the parameter, and the third column ties it back to the JavaScript object which surfaced the data. Between the surfacing of the data and its actual communication through the Http request, additional processing may be done on a per-vendor basis.

The parameter names MUST be defined as shown below for carrying the identified data.

Page Identifier

Page Details

Product

Cart

Order

Registrant

Element

Event

7. Data Privacy Considerations

This section is informative

A standard specification for customer experience data acquisition, as the one laid out in this document, serves to simplify the space, and by offering a method to precisely define and reference the data being collected, holds the promise of addressing some of the data privacy concerns related to commercial use of consumer data. We intend to encourage participants in the W3C standardization effort to consider how the specification laid out in this submission can be evolved to help address privacy concerns, including, but not limited to, accommodating privacy categorizations that may emerge from W3C's "Do Not Track" efforts. Such extensions could help deliver standardized solutions, contributing to simplified and meaningful consumer choice and greater transparency regarding use of consumer data.

8. References

8.1 Normative References

8.2 Informative References

9. Acknowledgements