The following information describes how the system processes and aggregates data for CX Overstat reports.

1. In the SDK, when a page load occurs, a type 2 (screenview load) event fires. The type 2 event has the following properties:

   url

   The path of the URL, for example:

   http://www.test.com/a/b/c

   becomes /a/b/c

   name

   The screenview name. The screenview name can be set in various ways. For example:

   • You can set it explicitly by customization in the SDK.
   • It can be set from fragment changes

     For example, going from http://www.test.com/a/b/c/#cart to http://www.test.com/a/b/c/#checkout would cause the screenview name to be #checkout.

   • History changes

     Websites can change the url without causing a page load. For example, the URL for a page can go from http://www.test.com/products/shirts to http://www.test.com/products/shoes. This change causes the url property of the type 2 event to be /product/shirts, as that's what existed for the page load, and the name (screenview) property would be what changed, i.e., /shirts.

2. When the snapshot extension creates a snapshot of the page, it captures the URL and the screenview name.

   If no screenview exists, it uses "root" for the screenview.

   The extension is notified of updates by the SDK (when capturing a page containing the SDK), so in the fragment change example shown above, it saves #checkout for the snapshot's screenview.

   On the server, when CX Overstat retrieves the visualization / usability data, it first checks if a screenview was specified, if not (i.e. it is "root"), then the URL is used as the screenview value.

3. When the SDK posts data for CX Overstat, the events record and associate the screenview with the data. Thus, when visualization / usability data is retrieved, the screenview is specified and that becomes part of the criteria for retrieving the data.