HomeDev GuideAPI Reference
Dev GuideAPI ReferenceUser GuideGitHubNuGetDev CommunityDoc feedbackLog In
GitHubNuGetDev CommunityDoc feedback

Consumption metrics

Describes the consumption metrics service, definitions, and usage parameters for solutions running in Optimizely Digital Experience Platform (DXP).

Setting the usage parameters correctly, especially for single page applications, ensures that the website traffic volume monitoring is correct.

You define the consumption levels when setting service tiers, based on the estimated amount of generated traffic. The usage parameters measure the service consumption.

An example of a usage parameter is the view of a page on a customer website provided by a service instance under an Optimizely DXP subscription. A visitor clicking reload after reaching the page counts as an additional page view. A visitor going to a different page and returning to the original page records an additional page view.

You can see the consumption metrics and traffic volumes in Application Insight (requires access).

Usage parameter definitions

  • Page view  – Tracks page impressions. Every occurrence where a page is displayed to a visitor counts as a page view. For websites, page views usually correlate with events where the browser location changes, such as when a visitor clicks a link, navigates browser history and reloads the current page or types in a new address.
  • Page  – Compiles content that is not a static file but has a URL and can be loaded in a browser. Depending on implementation, a page may map to an instance of a page type in Optimizely Content Management System (CMS) or to a product in Optimizely Customized Commerce but may also include blocks, external data or aggregates of external data or other pages.
  • Static file  – Contains an uploaded or deployed file, such as a PDF, image or CSS with an URL, and can be downloaded as-is by visitors.

These parameters are the base of the usage metrics. Application Insight monitoring is configured automatically for all sites running in DXP, but you may need further configuration to fully use its features depending on the site architecture.

Single page applications

By default, page views are tracked when a new page loads into the browser. Websites based on the Single Page Application (SPA) concept are different, since these interact with visitors by dynamically rewriting the current page and do not need page reloading. You need to configure the page view tracking for these websites.

Application Insights is already loaded when the page loads with the following code to track a custom page view:

if (typeof appInsights !== 'undefined') 

External Frontend Applications

If you are hosting your frontend application outside of DXP Cloud Services, you can instrument and send client telemetry to Application Insights in DXP Cloud Services.

Fetch the Instrumentation Key from the landing page in Application Insights in the Azure Portal.

Follow the steps here from Microsoft Azure to enable Application Insights.

Client telemetry

Application Insights tracks server telemetry through a JavaScript agent installed on the server but can also track client telemetry such as page views, session information and general information about users. This is done through a JavaScript beacon injected on the site. This injection happens automatically on App Services for CMS 11 through the app setting APPINSIGHTS_JAVASCRIPT_ENABLED or through the NuGet package EPiServer.CloudPlatform.Cms on CMS 12. This sends the client telemetry to Application Insights and is retained for 90 days. Optimizely collects the page view data from each application insight instance in DXP and presents it through https://dxc.episerver.net/.



In CMS 12, make sure you have the @Html.RequiredClientResources("Header") snippet in your site template, otherwise the necessary scripts for Application Insights might not be injected and the tracking will not work.

You can see this JavaScript in dev tools as ai.0.js. You also see a POST request called Track that actually sends the data to application insights.


To contextualize the user, it also injects two cookies called ai_session and ai_user and passes these values to application insights in the POST request.

You can interact with this data in a few ways once the client telemetry has been sent to Application Insight.

1. Performance Overview

The Performance Overview in Application Insight defaults to server telemetry and operations, but you can switch it to client telemetry for an overview of browser performance by selecting Browser rather than Server.

2. Usage statistics

The Usage section in Application insights gives you an overview of aggregated data such as users, sessions, page views and custom events over a period of time.

3. Workbooks

Workbooks are customizable reports to make analytics easier and more understandable. Workbooks can be based on any data in Application Insights with pre-built ones on client telemetry and usage.

4. Log analytics

Most of the data visible in Application Insight is available as tables through the Logs section. This is the most flexible, and complex, way of interacting with the client telemetry. Most of the client telemetry is available in the table called pageViews and browserTimings.

Example queries

  1. View page views for the last 30 days.

    | where timestamp > ago(30d)
    | summarize count() by bin(timestamp, 1d)
    | render timechart
  2. Count of unique users.

    | where timestamp > ago(30d)
    | summarize dcount(user_Id)
  3. Page views by site.

    | where timestamp > ago(30d)
    | extend site = split(url, "/")[2]
    | summarize count() by tostring(site)

See also Microsoft Documentation.