Use metrics and timers to understand how performance impacts your business

mPulse captures your custom metrics, timers, dimensions, and performance data elements and objects in an mPulse beacon. Use this beacon to connect your users' experience and your site's key business goals to understand how performance is impacting your business.

Metrics and custom metrics

In mPulse, metrics are non-performance data that are the result of something a visitor did while on your site. For example, a metric might be the percentage of visitors who buy something on your site (conversion rate), or the percentage of visitors who leave your site after viewing only your home page (bounce rate).

Custom metrics are values defined in your web app configuration to track and assess the status of specific business goals that mPulse doesn't automatically capture. Some examples of custom metrics include; conversion rate, revenue, order total, number of items in cart, and number of shares traded. mPulse has built-in system metrics such as bounce rate, session length, and session duration that are automatically captured in your data beacon.

Timers and custom timers

mPulse considers timers to be performance data such as DNS lookup time, SSL connection time, front-end time, back-end time, and page load time. mPulse system timers and custom timers are measured in minutes, seconds, or milliseconds.

For modern browsers, mPulse has built-in system timers to automatically collect performance data for page load time. There are also perceived performance timers that track Time to Interactive, Time to Visually Ready, and LongTasks Time. Timers that are defined by the Navigation Timing API are also collected for browsers that implement it.

Custom timers are values that you define in your web app configuration to identify and track other key performance moments during a page load that mPulse doesn't automatically capture. A few examples of custom timers include time to first image, time to sidebar load, and time to load content served from a specific third-party resource. For older browsers, mPulse estimates front-end and back-end performance timing, and collects custom timers using values from the Resource Timing API and the User Timing API for browsers that implement them.

Dimensions and custom dimensions

Like metrics, dimensions are non-performance data about your visitors' experience that help mPulse categorize page views into useful segments for analysis. mPulse has built-in system dimensions that capture details about the technology used by a visitor including browsers, operating system, device, network, geography, and Internet service provider (ISP).

Custom dimensions are values defined in your web app configuration that mPulse doesn't automatically capture. For example, you can use custom dimensions to identify pages served to visitors that are logged in, visitors that are not logged in or first-time visitors. You might also consider custom dimensions to identify mobile-optimized versus desktop-optimized versions of pages, and capturing the language or regional edition used for the page content.

How your custom definitions are collected in mPulse

Whenever a visitor goes to your site, the mPulse boomerang library looks at the definitions that you set up in your custom metrics, timers, and dimensions. When the library sees a match, it reads and stores the value as part of the boomerang beacon that's sent back to the mPulse collection system, where it's aggregated and displayed on mPulse dashboards.

All mPulse system metrics, timers, and dimensions are calculated at the page view level.

For descriptions of the parameters collected via the boomerang beacon, as well as how they're mapped to other parts of mPulse (for example, S3, Snowflake, and RedShift), see What's in an mPulse beacon?

mPulse system metrics

mPulse provides built-in, system metrics that are automatically captured and stored in the mPulse beacon.

All mPulse system metrics are calculated at the page view level, and are available in the filter bar at the top of the dashboards as shown in this example.

Metrics filter

System metrics

This table lists the mPulse system metrics that are common to most dashboards.

CategoryNameDescriptionRequirements
Resource Timing:
  • All Asset: includes all end-user requests.

  • Page: includes the page itself.

  • CSS: includes the cascading style sheets on the page.

  • Image: includes all images on the page.

  • HTML: includes the page and all HTML iframes.

  • Font: includes all fonts on the page.

  • Beacon: includes responses of 0 bytes, sendBeacon() calls, and pixels.

  • JavaScript: includes all JavaScript on the page.

  • Other: includes any asset that is not applicable to one of the other categories.

Browser Cache Hit RateThe ratio (0-100) of the number of browser cache hits to browser cache misses.The Collect ResourceTiming Data option must be selected in your web app configuration on the Beacons tab.
CDN Cache Hit RateThe ratio (0-100) of the number of requests that were CDN cache hits (that is the request did not go to the origin) to the total number of requests made to the Akamai network.
Request Compression RateThe ratio (0-100) of the number of requests where compression was applied to the total number of requests.
Request CountThe total number of requests.
Byte Compression RateThe percent reduction in total number of bytes as a result of compression.
  • Your visitors' browsers must support Resource Timing Level 2 and Server Timing.

  • The Collect ResourceTiming Data option must be selected in your web app configuration on the Beacons tab.

Decoded Body SizeThe size received from the fetch (HTTP or cache) of the message body, after removing any applied content-codings (decodedBodySize).
Transfer SizeThe size of the fetched resource including the response header fields plus the response payload body (transferSize).
Errors Per PageErrors per Page is calculated by dividing the total number of JavaScript errors by the combined number of page view, SPA soft beacons, and SPA hard beacons.The Collect JavaScript Errors option must be enabled in your web app configuration.
SessionSession DurationThe amount of time the user spent in a single visit.None
Session LengthThe number of pages the user viewed in this session up to and including the current page, but not including any pages viewed after this page in the same session.
StandardBounce RateThe ratio (0-100) of number of sessions consisting of a single page view (bounces) to the total number of sessions.None
User ExperienceRage ClicksHow many times the user repeatedly clicked the same region.
  • Boomerang version 1.720.0

  • The Collect Perceived Performance Metrics checkbox must be selected in your web app configuration on the Beacons tab.

Cumulative Layout Shift (CLS)Measures visual stability; how many times a user tries and fails to interact with an element on the page. For example, how many times the user repeatedly clicked the same region.
  • Boomerang version 1.720.0

  • The Collect Perceived Performance Metrics checkbox must be selected in your web app configuration on the Beacons tab.

  • Your visitors' browser must support the layout Instability API.

LCP Decoded Body SizeDecoded body size of the object that resulted in the Largest Contentful Paint.

None

Set up a custom metric

Custom metrics give you the tools to help you make connections between your users' experience and your site's business goals, or key performance indicators (KPIs). You can measure, track, and assess the status of specific key business goals that are critical to your organization.

Before you begin

You can define up to 10 custom metrics for your web app configuration based on any measurable value in a page, using these methods by browser:

  • JavaScript Variable (all browsers)
  • URL Pattern (all browsers)
  • URL Pattern with CSS Selector or XPath (Chrome, Firefox, Opera, Safari, iOS, Android 4+)

For best practices on setting up custom metrics, visit Community.

How to

  1. In mPulse, click Central.

  2. In the left pane, select Apps.

  3. From the list, double-click your app, then click Metrics.

    In the Metrics dialog, there are preset (default) formats for the way results appear in the dashboards, which you can override.

  4. Click the plus sign to add a custom metric and open the Metrics dialog.

    Metrics page

  5. In the Name field, give the metric a name. Enter a descriptive comment about the metric if you want.

  6. From the Value Source menu, select the method to define the metric.

    šŸ‘

    For details on how to define a conversion metric, a revenue metric, or a mobile app metric, see the links under Learn more.

  7. From the Include on menu, select which beacons you want the metric applied to.

  8. From the Data Type menu, chose a data type for the metric.

  9. To override the preset dashboard formats at the top of the Metrics dialog, select the checkbox and make your changes.

  10. Click OK to save the metric.

Define a conversion metric

Measure and track how long it takes your visitors to convert from casually looking around on your site to completing a purchase.

A conversion metric tells mPulse to track the percentage of sessions (visits) that reach a page view, and confirm that a purchase has been completed. mPulse uses this metric to perform a What-If analysis to help you set goals for better online business results and improve site performance.

There are two ways to set up a conversion metric, either with a JavaScript variable or with a URL pattern to find the page you're interested in. These instructions use a JavaScript variable to define a conversion metric.

šŸš§

If you choose the URL Pattern method to define a conversion metric, ignore the Type of Query options.

How to

  1. If the metric that you want to capture applies only to certain pages on your site, enter the URL pattern to match those pages.

    You can use an asterisk as a wildcard to replace one or more characters (for example, /example/example-abc/). mPulse looks for the first matching query string parameter for the page that has a URL pattern match.

    šŸ“˜

    For best results, avoid using a regular expression in the URL pattern.

  2. In the Variable Name field, enter the variable in your source code that you want to capture. The variable must be encoded globally on the page.

  3. From the Data Type menu, select Percentage to capture the rate that your visitors are viewing this page.

    šŸ“˜

    Percentage is divided by 100, and then multiplied by 100. Decimal places are to the right of a given decimal point. For example: 0 displays 12345%; 1 displays 1234.5%; 2 displays 123.45%; and so on.

  4. Scroll to the bottom of the dialog, and select a calculation method:

    • Once per session. Calculates the conversion rate based on the number of conversions per session. For example, your site has 10 visitors (sessions), and 2 of those visitors purchase a total of 6 items, while the other 8 visitors do not. The conversion rate for your site is 20%.

    • Once per page. Calculates the conversion rate based on the number of conversions per page.

    šŸ“˜

    If you choose this option and a visitor purchases the same item more than once, the conversion rate will be higher than 100%.

  5. To override the preset dashboard formats at the top of the dialog, select the checkbox and make your changes.

  6. Click OK to save the metric.

Define a revenue metric

Track your revenue and the cumulative value of sales over a period of time.

A revenue metric tells mPulse to track the cumulative value of sales over a period of time, and then perform a What-If analysis to help you set goals for better online business results and improve site performance.

There are two ways to set up a revenue metric, either with a JavaScript variable or with a URL pattern and a CSS selector or XPath.

Whether you use the JavaScript variable or URL pattern with the CSS selector or XPath to capture a currency value, mPulse takes the string of text it finds, strips out non-numeric values, and passes on just the numbers in the beacon that's sent when the page load is complete. For example, if the page has $123.45 on it, mPulse sends 12345. When using currency values, make sure that the values presented to mPulse are consistently using the same number of decimal points.

These instructions use the URL Pattern method and a CSS Selector to define a revenue metric.

For additional support when defining custom metrics, visit Community or contact your account team.

How to

  1. In the URL Pattern field, enter the URL that you wan to match.

    You can use an asterisk as a wildcard to replace one or more characters (for example, /example/example-abc/). mPulse looks for the first matching query string parameter for the page that has a URL pattern match.

    šŸ“˜

    For the best results, avoid using a regular expression in the URL pattern.

  2. From the Type of Query menu, select CSS Selector.

  3. From the page, find the currency value that you want applied to the metric, copy the element's selector, and paste it in the CSS Selector field.

    For details, see Capture a CSS Selector or XPath, below.

  4. From the Include on menu, select All non-XHR beacons. This tells mPulse to collect page view beacons for this metric.

  5. From the Data Type menu, select Currency.

    šŸ“˜

    Currency is displayed using a currency symbol. Decimal places are from right to left. For example: 0 displays $12,345; 1 displays $1,234.5; 2 displays $123.45; and so on.

  6. To override the preset dashboard formats at the top of the dialog, select the checkbox and make your changes.

  7. Click OK to save the metric.

mPulse system timers

mPulse provides built-in, system timers that are automatically captured and stored in the mPulse beacon.

mPulse system timers are available in the filter bar at the top of the dashboards as shown in this example.

mPulse system timers

System timers

This table lists the mPulse system timers that are common to most dashboards.

CategoryNameDescriptionRequirements
Perceived PerformanceFirst Contentful PaintThe time when the browser displays something that has content for the first time. For example, text, image, canvas, or SVG.
  • Boomerang version 1.571.0

  • The Collect Perceived Performance Metrics checkbox must be selected in your web app configuration on the Beacons tab

  • Your visitors' browser must support Paint Timing

First Contentful Paint (Front End)The time when the browser displays something that has content for the first time, excluding Back-End time.
  • Boomerang version 1.571.0

  • The Collect Perceived Performance Metrics checkbox must be selected in your web app configuration on the Beacons tab

  • Your visitors' browser must support Paint Timing

Interaction to Next Paint (INP)Measures responsiveness by observing the latency of all interactions a user has made with the page, and reports a single value. A low Interaction to Next Paint (INP) value means the page was consistently able to respond quickly to most user interactions.
  • Boomerang version 1.785.0
First Input Delay (FID)Measures responsiveness: the time from when a user first interacts with a page (i.e. when they click a link, tap on a button, or use a custom, JavaScript-powered control) to the time when the browser is able to begin processing event handlers in response to that interaction.---
  • Boomerang version 1.720.0

  • The Collect Perceived Performance Metrics checkbox must be selected in your web app configuration on the Beacons tab.

First PaintThe time when the browser first rendered after navigation.

Currently, mPulse collects this value for the following browsers:

  • Chrome window.chrome.loadTimes().firstPaint

  • Internet Explorer window.performance.msFirstPaint

  • Edge window.performance.msFirstPaint

Largest Contentful Paint (LCP)Measures load time: the time to render the largest image or text block visible within the viewport.
Largest Contentful Paint (Front End)The time to render the largest image or text block visible within the viewport, excluding Back-End time.
Time to InteractiveThe time when the page looks ready to use and is responsive to user input.
Time to Interactive (Front End)The time when the page looks ready to use and is responsive to user input, excluding Back-End time.
Time to First InteractionThe time when the user first tries to interact with the page.
Time to Visually ReadyThe time when the page looks ready to use.
Time to Visually Ready (Front End)The time when the page looks ready to use, excluding Back-End time.
LongTask TimeThe sum of the amount of time of Long Tasks, which are browser tasks that take over 50 ms. For example, JavaScript, layout, and rendering.
  • Boomerang version 1.571.0

  • The Collect Perceived Performance Metrics checkbox must be selected in your web app configuration on the Beacons tab

  • Your visitors' browser must support Long Task

Total Blocking Time (TBT)The sum of time where the main thread was blocked long enough to prevent user input. A measure of how busy the browser was, a good proxy for how interactive the page may feel.
  • Boomerang version 1.720.0

  • The Collect Perceived Performance Metrics checkbox must be selected in your web app configuration on the Beacons tab.

  • Your visitors' browser must support Long Task.

CDN:
  • All Asset: includes all end-user requests.

  • Page: includes the page itself.

  • CSS: includes the cascading style sheets on the page.

  • Image: includes all images on the page.

  • HTML: includes the page and all HTML iframes.

  • Font: includes all fonts on the page.

  • Beacon: includes responses of 0 bytes, sendBeacon() calls, and pixels.

  • JavaScript: includes all JavaScript on the page.

  • Other: includes any asset that is not applicable to one of the other categories.

Client Round-Trip TimeThe round-trip time between the browser and the Akamai edge server (nearest to the end user). This timer can help quantify how well connected your end users are to the nearest Akamai point of presence (PoP).---
CDN Edge TimeThe time between when the first byte of the request is received by the Akamai edge server from the client browser, and just before the first byte of the response is written back. This does not include the time that may or may not have been spent forwarding the request to the origin. It applies to requests delivered by the Akamai network via an mPulse-enabled property configuration. This timer can help quantify the time spent within the Akamai CDN.
Origin TimeThe round-trip time between the Akamai edge server (nearest to the origin), and the origin. This includes the time the origin spends handling the request. Note that this timer is only relevant when content is served from the origin, and not CDN cache. It applies to requests delivered by the Akamai network via an mPulse-enabled property configuration. This timer can help diagnose whether the origin is the source of slow load times.
StandardBack-End Time (TTFB)Time to First Byte (TTFB). The full time it takes from the beginning of the navigation to the first byte of content received. A good indicator of general delivery performance including DNS, TLS, and server response.None
DNS ResolutiondomainLookupEnd - domainLookupStart from NavigationTiming.
DOM LoadingdomLoading - navigationStart from NavigationTiming.
DOM CompletedomComplete - navigationStart from NavigationTiming. Formerly known as DOM Ready.
Front-End TimeTime from first byte to onload (or whenever the page is considered ready).
Page LoadloadEventEnd - navigationStart from NavigationTiming.
SSL HandshakeconnectEnd - secureConnectionStart from NavigationTiming.
TCP ConnectionconnectEnd - connectStart from NavigationTiming.
Service Worker Startup TimeThe time it takes for the Service Worker to initialize. fetchStart - workerStart from Navigation Timing.

If your site is a progressive web app (PWA), there's a Service Worker installed. The additional time taken to initiate the service worker and dispatch the first fetch event is non-zero, so this timer tracks how long it takes.

fetchStart - workerStart from NavigationTiming.

Redirect TimeDuration of redirects before loading the current page. redirectEnd - redirectStart from NavigationTiming.

Good for identifying legacy deep links or server/CDN configuration issues.

Waiting TimeTime spent waiting for the server to respond to the HTTP request. responseStart - requestStart from NavigationTiming.

A good measure of origin and CDN performance.

Download TimeTime spent downloading the HTML. responseEnd - responseStart from NavigationTiming.
Unload TimeTime spent unloading the previous HTML page (if same domain). unloadEnd - unloadStart from NavigationTiming. A high unload time will feel like high latency to a user, because the browser delays subsequent navigations while processing these events.
Time to RequestBack-end time minus Waiting Time (the time spent waiting for the server to respond to the HTTP request). See How to calculate back-end time for details.
Unattributed Navigation Overhead (UNO)Any non-attributed time between Navigation Start and Request Start.
LCP Transfer TimeTransfer time of the object that resulted in a Largest Contentful Paint.
  • Boomerang version 1.720.0

Akamai middle-mile CDN system timers
Time equations visual

Set up a custom timer

You can define timers to identify key performance moments during a page load such as time to first image, time to sidebar load, and time to load content served from a specific third-party resource.

Before you begin

mPulse supports either client-side URL pattern matching defined as part of your app, or as a variable in your source code written as a boomerang plug-in.

You can define up to 10 custom timers for your web app configuration based on any measurable value in a page, using the following methods by browser:

  • JavaScript Variable (all browsers)
  • Navigation Timing (Chrome, Firefox, Internet Explorer 9+, Opera, Android; experimental on Safari & iOS)
  • Resource Timing defined with CSS Selector or XPath (Chrome only)
  • Resource Timing defined with Resource URL pattern (Chrome and Internet Explorer 10+)
  • URL Timing (Chrome and Internet Explorer 10+)
  • Resource Groups (all browsers)

How to

  1. In mPulse, click Central.

  2. In the left pane, select Apps.

  3. From the list, double-click your app, then click Timers.

  4. Click the plus sign to add a custom timer and open the Timers dialog.

    Custom timer set up

  5. In the Name field, give the timer a name. Enter a descriptive comment about the timer if you want.

  6. From the Value Source menu, choose the method that you want to use to define the timer.

    šŸ“˜

    For details on using these methods, see the links under Learn more.

  7. From the Include on menu, select which beacons you want the timer applied to.

  8. In the Indicator Color Ranges section, color ranges and time indicators are set for you. You can change these if you want or use the presets.

  9. Click OK to save your custom timer.

Define a timer with JavaScript Variable

Capture performance data of a specific time in the page load, using simple math between two timing points.

How to

  1. Define a JavaScript timing variable in your source code that captures a specific time in the page load, and assign it a name.

  2. If the timer that you want to capture applies only to certain pages on your site, enter the URL pattern to match those pages.

    You can use an asterisk as a wildcard to replace one or more characters (for example, /example/example-abc/). mPulse looks for the first matching query string parameter for the page that has a URL pattern match.

    šŸ“˜

    For the best results, avoid using a regular expression in the URL pattern.

  3. In the Variable Name field, enter the name of the JavaScript timing variable you defined in your source code.

Define a timer with Navigation Timing

Capture performance data of certain timing points with in the page load based on existing Navigation Timing API methods.

The Navigation Timing API is provided in all modern desktop browsers and most Android mobile browsers.

How to

  1. If the timer that you want to capture applies only to certain pages on your site, enter the URL pattern to match those pages.

    You can use an asterisk as a wildcard to replace one or more characters (for example, /example/example-abc/). mPulse looks for the first matching query string parameter for the page that has a URL pattern match.

    šŸ“˜

    For the best results, avoid using a regular expression in the URL pattern.

  2. From the Start and End menus, select the corresponding timing attributes that you want applied to the timer. You can define a client-side custom timer using a URL pattern with any of these values.

    • Connect Start / Connect End
    • Load Event Start / Load Event End
    • DOM Complete
    • DOM Content Loaded Event Start / DOM Content Loaded Event End
    • DOM Loading
    • DOM Lookup Start / DOM Lookup End
    • DOM Interactive
    • Fetch Start
    • Navigation Start
    • Redirect Start / Redirect End
    • Response Start / Response End
    • Request Start
    • Secure Connect Start
    • Unload Event Start / Unload Event End

Define a timer with Resource Timing

Capture performance data about a specific resource, such as objects, images, and CSS files, based on existing Resource Timing API methods.

How to

  1. If the timer that you want to capture applies only to certain pages on your site, enter the URL pattern to match those pages.

    You can use an asterisk as a wildcard to replace one or more characters (for example, /example/example-abc/). mPulse looks for the first matching query string parameter for the page that has a URL pattern match.

    šŸ“˜

    For the best results, avoid using a regular expression in the URL pattern.

  2. From the Type of Query menu, select a method to locate the resource.

    • To use CSS Selector or XPath, go to the page, copy the selector or XPath and paste it in the corresponding field in the dialog.

      For details, see Capture a CSS Selector or XPath, below.

    • To use Resource URL, enter the absolute URL of the resource in the Resource URL field. To collect the first resource found in the page that matches, use a wildcard.

      For example, to collect a specific resource, the Resource URL might look like this:

      http://www.example.com/images/image4.gif

      If you include a wildcard at the end of the Resource URL, like this:

      http://www.example.com/images/image*

      then mPulse collects the first resource found that matches, such as:

      http://www.example.com/images/image1.gif

  3. From the Start and End menus, select the corresponding timing attributes that tell mPulse when to begin and when to stop collecting performance data for the resource.

    • Connect Start / Connect End
    • DOM Lookup Start / DOM Lookup End
    • Fetch Start
    • Page Start Time
    • Redirect Start / Redirect End
    • Resource Start Time
    • Response Start / Response End
    • Request Start
    • Secure Connect Start

Define a timer with User Timing

Capture performance data with a timing mark or a timing range in a page based on existing User Timing API methods.

The User Timing API is only available in a few browsers, such as modern versions of Internet Explorer and Chrome. It allows you to capture performance data between the value of performance marks and the value of performance measures. It's similar in concept to using JavaScript timing points, but a much simpler way to add points without having to expose or add substantial amounts of additional JavaScript to your site.

How to

  1. Define either a timing mark (performance.mark) to capture a specific timing point in a page or a timing measure (performance.measure) to capture a range of time in a page. For an example of how a performance.markis defined in a script, see User Timing.

  2. If the timer that you want to capture applies only to certain pages on your site, enter the URL pattern to match those pages.

    You can use an asterisk as a wildcard to replace one or more characters (for example, /example/example- abc/). mPulse looks for the first matching query string parameter for the page that has a URL pattern match.

    šŸ“˜

    For the best results, avoid using a regular expression in the URL pattern.

  3. In the User Time Name field, enter the name of the timing mark or the timing measure that you defined in your source code. mPulse automatically detects the difference between performance marks and measures. It assumes that you want to know the time from the beginning of the page load until the timer itself is found on the page.

Define a timer with Resource Groups

Capture performance data of critical resources on your site by group.

Like Resource Timing, this method is based on existing Resource Timing API methods that specifically target the time it takes for a resource on a page to load such as objects, images, and CSS files. For each resource in the group, you can define the time by capturing the resource in the page with either a CSS selector, an XPath, or a specific name or name pattern (Resource URL).

How to

  1. If the timer that you want to capture applies only to certain pages on your site, enter the URL pattern to match those pages.

    You can use an asterisk as a wildcard to replace one or more characters (for example, /example/example-abc/). mPulse looks for the first matching query string parameter for the page that has a URL pattern match.

    šŸ“˜

    For the best results, avoid using a regular expression in the URL pattern.

  2. At the mid section of the dialog, in the URL Pattern field, enter the absolute URL of the resource. To collect the first resource found in the page that matches, use an asterisk as a wildcard.

    For example, to collect a specific resource, the Resource URL might look like this:

    http://www.example.com/images/image4.gif

    If you include a wildcard at the end of the Resource URL, like this:

    http://www.example.com/images/image*

    then, mPulse collects the first resource found that matches, such as:

    http://www.example.com/images/image1.gif

  3. From the Measure from menu, choose the starting point for the measurement:

    • Navigation Start captures the time just before a new page is requested. It's initiated when a visitor clicks a link on your site or presses Enter after entering a URL in the browser bar.
    • First Resource captures the time when the first resource on the page is encountered (for example, http://www.example.com/images/image1.gif).
  4. From the Include on menu, choose the navigation that you want the resource collected on.

    • SPA Soft: All of the interactions on the page that occur after the initial page load such as an address bar change.
    • SPA Hard: The first page load, which includes; all static HTML, JavaScript, CSS, and the SPA framework itself (for example angular.js).
    • Onload (for non-SPA sites): The browser downloads all of the resources on the page.
    • XHR: An XMLHttpRequest that indicates network activity. For example, the page's view is being updated or it could be a periodic poll like a scoreboard update.
  5. From the Selection type menu, choose a method to locate the resource.

    • To use a CSS Selector or XPath, go to the page, copy the selector or XPath, and paste it in the Selection value field.

      For details, see Capture a CSS Selector or XPath, below.

    • To use Resource URL, enter the absolute URL of the resource in the Selection value field, or use a wildcard to collect the first resource found in the page that matches.

      For example, to collect a specific resource, the Resource URL might look like this:

      http://www.example.com/images/image4.gif

      If you include a wildcard at the end of the Resource URL, like this:

      http://www.example.com/images/image*

      then, mPulse collects the first resource found that matches, such as:

      http://www.example.com/images/image1.gif

  6. Click the plus sign to capture more resources in the page for this group.

šŸ“˜

mPulse only captures the resource in the first URL pattern that matches the current page.

mPulse CORS and Resource Timing

Akamai mPulse can capture element-level performance details during each page load. When viewed in the waterfall analysis dashboard, you can see exactly when every HTML, image, style sheet, and JavaScript asset is being requested and how long they take to load. This is very useful information when diagnosing performance problems on a page. As you use waterfalls, however, you may notice that some elements on a page give you details on component timings such as DNS lookup time, TCP connect time, SSL connect time, request time, and response time, whereas other elements just have a single "total time" value.

The Resource Timing API

The values collected by mPulse come from the W3C Resource Timing API, a standard JavaScript API that is implemented in modern web browsers. Because the information is exposed through JavaScript, the Resource Timing API is subject to the cross-origin security limitations that browsers enforce on scripts. This limitation means that if your site uses multiple domains (such as 'www' and 'images') or has content served from both secure and non-secure servers, you will only be able to get component-level details for requests from the same server/domain that served the base document request, unless you change some settings. To get component-level details for elements on a different origin server than the base page HTML server, you'll need to have headers configured to allow Cross Origin Resource Sharing (CORS). Specifically, you should add the following HTTP header to all requests:

Timing-Allow-Origin = "Timing-Allow-Origin" ":" origin-list-or-null | "*"

If you have third-party tags/elements on your pages, you will need to have those service providers add this header to their elements responses in order to get component-level details in the mPulse waterfalls for those page assets as well.

Security Consideration

Using a wildcard "" header for Timing-Allow-Origin is relatively safe. It does not expose the same security concerns as using the Access-Control-Allow-Origin: header, for example. The only thing that using Timing-Allow-Origin: * allows is for is JavaScript from another site to get a breakdown of DNS, TCP, Request and Response times for content on third-party domains.

That being said, if you want to use a more restricted Timing-Allow-Origin, you can have your site respond with the same value of the Origin HTTP request header. The Origin HTTP request header is added to any request for third-party domains. So if a browser requests content from a server with:

Origin: http://www.example.net

You can include this HTTP header:

Timing-Allow-Origin: http://example.net/

If however, someone requests content from:

Origin: http://community.akamai.com/

You can skip responding with the Timing-Allow-Origin header.

mPulse system dimensions

mPulse provides built-in, system dimensions that are automatically captured and stored in the mPulse beacon.

mPulse system dimensions are available in the filter bar at the top of the dashboards. Dimensions are categorized in a variety of ways such OS families as shown in this example.

Dimensions categorization example

System dimensions

This table lists the mPulse system dimensions that are common to most dashboards.

NameDescription
A/B TestIf A/B testing is used, this variable specifies the test bucket the visitor was in when they sent the beacon.
ActionIndicates the name of the action, as defined by the mobile app owner using the SDK.
Akamai Adaptive AccelerationDenotes whether Adaptive Acceleration was applied to the requested page. Adaptive Acceleration uses real user monitoring (RUM) navigation and timing data to intelligently cache content that viewers will likely need ahead of when it's actually needed. This approach shortens delivery times, reduces the load on the network, and renders web pages faster. Requires Akamai CDN.
AlertThe name of the alert that was triggered.
Alert SeverityThe severity of the alert that was triggered.
App Error CodeThe error response status code.
App Error MessageThe error response message.
App Error SourceThe component that generated the error. For example, Global, Handler, Network or Manual.
App Error TypeThe error type that is parsed from the error message. For example ReferenceError or SyntaxError.
Bandwidth BlockThe bandwidth of the requesting browser's connection.
Beacon TypeBeacon types include; page view, SPA hard or soft navigation, XHR, and error.
BFCache navigationIndicates if the navigation was a result of the Back-Forward Cache (BFCache) optimization.
BFCache Not Restored ReasonLists the reason why the page was not eligible for Back-Forward Cache navigation.
Boomerang VersionThe version number of the Boomerang that fired the beacon.
BrowserThe browser name and browser version that are requesting the object.
Browser FamilyThe name of the browser requesting the object.
Connection TypeThe mobile connection type.
CountryThe country from which the request originated.
DeviceThe full device name and model. For example, Samsung Galaxy S8.
Device MemoryThe device memory reported by the browser per the navigator.deviceMemory property in gigabytes.
Device ManufacturerThe mobile device manufacturer. For example, Apple, Samsung and LG.
Device TypeThe form factor of the device on which the requesting browser is running. For example, mobile desktop, tablet, and console.
Full URLThe entire raw URL of the page that sent the beacon.
HTTP ProtocolThe HTTP protocol used to deliver the page (1.1/2/2+QUIC/.../etc).
IP AddressIdentifies the IP address of the visitor or the proxy they're connected through.
IP VersionThe IP version used to deliver the page. Requires Akamai CDN.
ISPIf the page was requested over a mobile data connection, this is the mobile service provider.
Network Errors4xx client errors. Note: This dimension is present only when XHR instrumentation is enabled (see Use page groups to isolate performance issues).
OSThe OS and OS version of the platform on which the requesting browser is running.
OS FamilyThe platform on which the requesting browser is running.
Page CDN Cache StatusThe Akamai CDN cache status for the navigation URL: either HIT, MISS or REVALIDATION.
Page DomainThe domain name of the navigation URL.
Page GroupsThe groups that are either auto-defined by mPulse or user defined in the web app configuration, on the URLs tab.
RegionThe area of a country from which the request was sent.
Site VersionFor mobile applications, this is the version of the application installed on the visitor's device. For web applications, site owners may use this to specify a release number for their site.
TLS versionThe version of the transport layer security (TLS) protocol that the visitor uses to connect to the Akamai network (edge).
URLFor web apps, this is often the domain of the page that sent the beacon. For mobile apps, if URL patterns are configured, it is the URL pattern of the network request that sent the beacon.
Landing PageWhether or not this was the first page of the session. The first page is likely to be one of the slowest pages views because it may not have cached data and may require a full DNS/TCP/TLS connection. This data gives you insight into where the optimize for first-time visitors and landing pages.
Early BeaconWhether or not this beacon's data was from an Early Beacon (and the full beacon data did not arrive). Early Beacons allow you to capture as much data as is available when mPulse first loads on the page, which is superseded by the full beacon page load. This dimension allows you to filter to just the Early Beacons that never reached a full beacon.
Visibility StateThe visibility state of the page: Always Visible, Partially Hidden, or Always Hidden.

If the page was loaded in the background tab, you might want to exclude the performance metrics from the page view, because browsers can throttle non-visible tabs, which has potential to skew results.

Navigation TypeThe type of the navigation: Navigate, Reload, or Back-Forward. Indicates if the user navigated to the page, refreshed the page, or navigated back through their history to find the page. Excluding refreshed pages and back/forward navigations could give a more realistic performance distribution for your pages.
Akamai Property VersionAvailable when using mPulse Edge Injection. This allows you to compare performance and roll out speed between versions of your CDN configuration, automatically collected from Akamai with every page view. This only works if mPulse is enabled via your property configuration.

Set up a custom dimension

Filter your data on criteria that you define, such as user characteristics. For instance you can differentiate premium customers from casual visitors to make sure that your paying customers are having a good experience on your site. With custom dimensions, you can identify the data center or server that served up the page so you can easily troubleshoot performance issues if they begin to appear.

Before you begin

When setting up a custom dimension, consider these best practices:

  • Unlike metrics, dimensions are not limited to numeric and Boolean values. You can use text strings as well.

  • For performance and manageability, use a small number of values per each dimension (for example, under 100 values). All values appear in the filter list on the dashboards, and it might be difficult to see a large number of values.

  • Before implementing custom dimensions, contact your account team to confirm that the number of values you define will give you a satisfactory experience.

You can define up to 10 custom dimensions for your web app configuration based on any measurable value in a page, with these methods:

  • XPath or CSS Selector
  • URL
  • Query Parameter
  • Cookie
  • User Agent
  • JavaScript Variable

How to

  1. In mPulse, click Central.

  2. In the left pane, select Apps.

  3. From the list, double-click your app and then click Dimensions.

  4. Click the plus sign to add a custom dimension and open the Dimensions dialog.

    Dimensions page

  5. In the Name field, give the dimension a name. It's a good idea to add a descriptive comment that explains what the information is that you're capturing and how you're capturing it, or what you expect the pattern to look like.

  6. In the Type section, select a data type.

    • Text: Some text on a page; can be any alphanumeric value.
    • Numeric: A count on a page such as the number of advertisements.
    • Boolean: A 0 or 1 for Boolean (captured as a Numeric).

šŸš§

Javascript variable names can be used to configure Page Group definitions, custom timers, custom metrics, and for the A/B Testing variable. The only allowed characters in a JS variable name are [a-zA-Z0-9_.$] and the variable must start with [a-zA-Z_$] and cannot end with the "." character. More complex Javascript variables such as dataLayer[0]['pageName'] will not work.

  1. From the Value Source menu, select the method that you want to use to define your custom dimension.

    šŸ“˜

    For details on using these methods, see the links under Learn more.

  2. From the Include on menu, select which beacons you want the dimension applied to.

  3. To set up an alias map that translates values collected in the browser to user-friendly names that appear in the dashboards and alerts:

  4. Under Alias Map, click the plus sign to add an entry.

  5. In the Value field, enter a value collected in the browser.

  6. In the Alias field, enter the user-friendly name for the value.

  7. Click the plus sign to add another entry to the map.

  8. To remove an entry, click the X.

  9. Click OK to save your custom dimension.

Define a dimension with XPath or CSS Selector

Capture the value of a DOM node element in a page.

How to

  1. If the dimension that you want to capture applies only to certain pages on your site, enter the URL pattern to match those pages.

    You can use an asterisk as a wildcard to replace one or more characters (for example, /example/example-abc/). mPulse looks for the first matching query string parameter for the page that has a URL pattern match.

    šŸ“˜

    For the best results, avoid using a regular expression in the URL pattern.

  2. Go to the page, copy the selector or XPath and paste it in the corresponding field in the dialog.

    For details, see Capture a CSS Selector or XPath below.

Define a dimension with URL

Capture a value from a portion of the URL, using a regular expression.

How to

  1. If the dimension that you want to capture applies only to certain pages on your site, enter the URL pattern to match those pages.

    You can use an asterisk as a wildcard to replace one or more characters (for example, /example/example- abc/). mPulse looks for the first matching query string parameter for the page that has a URL pattern match.

    šŸ“˜

    For the best results, avoid using a regular expression in the URL pattern.

  2. In the Regular Expression field, enter the portion of the URL that you want to capture.

    For instance, to capture the portion of the URL that identifies the product "hammer " in "product/hammer/ball-peen " the regular expression might look like this: /product/(.+)/.

  3. In the Replacement field, enter the parameter (for example, $1) to represent the value captured in the regular expression.

Define a dimension with Query Parameter

Capture the value of a query string parameter.

How to

  1. If the dimension that you want to capture applies only to certain pages on your site, enter the URL pattern to match those pages.

    You can use an asterisk as a wildcard to replace one or more characters (for example, /example/example-abc/). mPulse looks for the first matching query string parameter for the page that has a URL pattern match.

    šŸ“˜

    For the best results, avoid using a regular expression in the URL pattern.

  2. In the Parameter field, enter the name of the query parameter that contains the value that you want to capture.

  3. In the Replacement field, enter the parameter (for example, $1) to represent the value captured in the regular expression.

Define a dimension with Cookie

Capture a portion of a cookie value, using a regular expression.

How to

  1. If the dimension that you want to capture applies only to certain pages on your site, enter the URL pattern to match those pages.

    You can use an asterisk as a wildcard to replace one or more characters (for example, /example/example-abc/). mPulse looks for the first matching query string parameter for the page that has a URL pattern match.

    šŸ“˜

    For the best results, avoid using a regular expression in the URL pattern.

  2. In the Cookie Name field, enter the cookie's name (for example, "details").

  3. In the Regular Expression field, enter the regular expression that captures the cookie's name value.

    For instance, to capture the name from a cookie where the cookie's name is "details " and the cookie's format is: "campaign:; " the regular expression might look like this: campaign:(.+);.

  4. In the Replacement field, enter the parameter (for example, $1) to represent the value captured in the regular expression.

Define a dimension with User Agent

Capture a portion of the user agent (for example, a browser) using a regular expression.

How to

  1. If the dimension that you want to capture applies only to certain pages on your site, enter the URL pattern to match those pages.

    You can use an asterisk as a wildcard to replace one or more characters (for example, /example/example-abc/). mPulse looks for the first matching query string parameter for the page that has a URL pattern match.

    šŸ“˜

    For the best results, avoid using a regular expression in the URL pattern.

  2. In the Regular Expression field, enter the portion of the user agent that you want to capture.

    For instance, to capture a retailers specialty kiosk ("1234 ") in this format: "kiosk-code:1234 " the regular expression might look like this: kiosk-code:(.+):.

  3. In the Replacement field, enter the parameter (for example, $1) to represent the value captured in the regular expression.

Define a dimension with JavaScript Variable

Capture the value of a JavaScript variable in a page's source code.

How to

  1. If the dimension that you want to capture applies only to certain pages on your site, enter the URL pattern to match those pages.

    šŸ“˜

    Acceptable characters of the JavaScript value are: upper and lower case alphanumeric characters (a-z, A-Z), space, underscore (_), dash (-), and period (.).

    šŸ“˜

    You can use an asterisk as a wildcard to replace one or more characters (for example, /example/example-abc/). mPulse looks for the first matching query string parameter for the page that has a URL pattern match. For the best results, avoid using a regular expression in the URL pattern.

  2. In the Variable Name field, enter the variable that you want to capture. The variable must be encoded globally on the page.

Capture a CSS Selector or XPath

Use CSS Selector or XPath to locate an element or resource that you want to collect performance data on in a web page.

Before you begin

mPulse does not perform currency conversion. If you allow purchases in multiple currencies, and those numerical values are not kept in separate variables or accessible by separate CSS Selectors or XPath, mPulse may report incorrect values. For these situations, create a JavaScript variable on the page with the order value that represents the appropriate currency (for example, converted to USD, EUR, JPY or whatever makes sense for your business.) instead of using a CSS Selector or XPath.

The value applied is the value of the element within the DOM node after stripping out everything except number characters.

How to

  1. Open the page in a browser (for example, Chrome), right-click the element that you want to capture, and select Inspect to open the developers tools.

    Inspect tool location

  2. From the Elements tab, right-click the element and select either Copy > Copy selector or Copy XPath.

    Copy and copy selector location

  3. To view the value of the element, click Console. After the prompt, type $, select the element in the pop up, and press Enter.

    View element value

  4. Expand the element, until you see the innerHTML value.

    Inner HTML value

How to calculate back-end and front-end times

A key component of the user's page load experience includes how fast the server can dynamically generate or fetch the base document after a new page request. In mPulse, that timer value is called back-end time.

If the median value for back-end time is high, then you definitely know that you have a problem that impacts the customer experience. However, if the back-end time is good, there could still be other issues on the page, including server-side performance issues that are happening at other parts in the page load. The portion of the page load time that follows the back-end time is what mPulse calls front-end time. That timer includes all the remaining time to load the page, including fetching both static and dynamic assets on the page, delays processing Javascript or CSS, time to initialize plug-ins like Flash, and other browser-side delays until the onLoad event has fired.

Calculating back-end time

The value assigned to back-end time for a given beacon (page view) depends on whether the browser being used supports the W3C Navigation Timing standard. For browsers that support Navigation Timing, the value reported for back-end time is the time from navigationStart to responseStart. For legacy browsers that do not support the navigation timing standard, the value is the time from the onBeforeUnload event or the onClick event (whichever is later) to the OnUnload to OnPageHide event (whichever fires). If the page view is the first page in a session, and there are no onBeforeUnload or onUnload events to base a timing from, mPulse calculates an estimated value based on a statistical sample of all back-end times observed so far and the time it takes boomerang to load on the page. For more information on the browsers that support navigation timing, see the Navigation Timing API.

Calculating Front-End Time

Front-end time for a beacon is the time from the calculated back-end time to the end of the page load (when the onLoad event fires on the page.)

Have you ever looked at your front-end, back-end, and total page load time medians, and wondered why they do not add up?

The explanation is basic statistics. Medians cannot be compared across different data sets. In this case, the Total, FE, and BE timers are separate data sets, and the median for each is the middle point in each set independent of the other sets.

Example 1

  • Total = 1.17s
  • Back-End (BE) = 625ms
  • Front-End (FE) = 1.74s.

As a result, the FE + BE > Total.

Example 2

Assume a case with 5 beacons with the following times:

Beacons

BEFETotal
1300ms900ms1200ms
2250ms*1000ms1250ms
3*275ms800ms1075ms
4150ms1050ms*1200ms
5350ms1100ms1450ms
Median275ms1000ms1000ms(BE + FE = 1275ms)
85pctl300ms1050ms1250ms(BE + FE = 1350ms)

You have the following result:

  • For each beacon, the sum of BE and FE always add up to total.
  • For each timer, the middle element (median) across all beacons ends up being on a different beacon for each one of them.
  • For each timer, the 85th percentile (pctl) across all beacons ends up being on a different beacon for each one of them.