mPulse FAQ

Document created by Dave Murphy Employee on Jul 12, 2017Last modified by Sheril Joseph on Aug 8, 2017
Version 13Show Document
  • View in full screen mode

This Frequently Asked Questions (FAQ) documentation will be updated on a regular basis to help as a first stop for answering your questions about the configuration, deployment, and use of mPulse on your web site.  Another great resource is the mPulse Setup guide.  

 

General

Deployment

Configuration

Data Collection

Using the Data

Exporting, Importing, and Sharing Data

Single Page Applications (SPA)

Bandwidth Testing

Support

 

GENERAL

 

Q: What is Akamai mPulse? 

A: mPulse is Akamai’s Real User Measurement (RUM) solution.  mPulse collects detailed data directly from a user’s browser or mobile application, including performance timers such as bandwidth and page load times as well as business metrics like bounce rate, conversion rates, or order totals.  mPulse also gathers mobile user metrics like user location, device type, carrier speed and application usage.  You get actionable views of this data via stunning dashboards that are populated instantly via the industry’s first in-memory analytics engine. You are provided real time views of real user activity broken down by such segments as page groups, browser type, bandwidth distribution, and geography.  The mPulse product data sheet is here.

 

Q: What is Boomerang?

A: boomerang.js is open source Javascript code (BSD license) that was developed in 2010 to implement Real User Measurement (RUM).  mPulse is built using boomerang.js.  Boomerang was created by Philip Tellis, who founded LogNormal, Inc., the first company to offer a RUM product.  LogNormal was acquired by SOASTA in 2012, and SOASTA was in turn acquired by Akamai in 2017. Akamai maintains the open source version of Boomerang, which can be found here: https://github.com/SOASTA/boomerang/

 

Q: What is the Data Science Workbench (DSWB)?

A: The Akamai Data Science Workbench is an analytics platform that allows data scientists, engineers, business analysts, and decision makers to quickly and easily acquire actionable business intelligence from their data. This includes analysis of 100% of their customer experience data collected via mPulse as well as any other data sets available. Users can easily access this information, then slice, dice and analyze the data in a variety of different visual formats.  Every customer experience beacon is unpacked, transformed and loaded nightly by Akamai into a Akamai designed schema in a cloud-based database.  Interact with your data using an online, interactive Explore & Discover user interface based on the Julia scientific programming language developed at MIT.  Pre-developed functions and statistical models are available to quickly get you started. 

 

Q: Will mPulse slow down my site?

A: The mPulse Team has ensured that your client's performance comes first, and that performance is not adversely affected by the measurement tool in use.  Our Boomerang implementation is designed with the smallest possible footprint, whether Boomerang is loaded into a mobile browser or into some other browser type.  mPulse conserves the limited parallel connections available to the web browser or mobile app and has a far–future header that spreads out its necessary requests over time. Akamai's Javascript calls will not block your critical client requests.  For more information, see mPulse Boomerang Overhead and Why it is ok for our JavaScript snippet to be at the top of the page.

   

Q: What kinds of web sites are compatible with mPulse?

A: mPulse can function effectively in both traditional and Single Page Application (SPA) sites.  By default, mPulse measures the time it takes to load a full page. This works well if you have a standard multi-page site. If your application runs as a single page that loads content from the back end using things like XHR or JSON-P, mPulse can handle that as well, recoding timers for XHR actions.  For more details on setting up the Javascript tag to capture AJAX calls or for more details on the first-class support for the most popular SPA frameworks, see the mPulse Setup Guide.  For details on the mPulse Boomerang AngularJS Plugin in this post.

 

Q: What kinds of browsers are compatible with mPulse?

A: Any browser that supports Javascript will work with mPulse.  mPulse can collect more detailed performance timers from browsers that support the World Wide Web Consortium (W3C) Navigation Timing API.  For legacy browser versions, mPulse still collects page-level timer information, and can estimate front-end versus back-end time, even though it is not measured directly in these older browsers.  Element-level performance details used in the Waterfall Analysis Dashboard are collected from browsers that support the W3C Resource Timing API.  For connections to the mPulse UI and API, we require that the browser or client support a minimum of TLS 1.2. 

See http://caniuse.com/#search=TLS%201.2 for a list of browsers with TLS 1.2 support.

See http://caniuse.com/#search=Navigation%20Timing%20API for a list of browsers that support the Navigation Timing API.  

See http://caniuse.com/#search=Resource%20Timing for a list of browsers that support the Resource Timing API.

 

Q: Does mPulse work with mobile-optimized web sites?

A: mPulse is compatible with desktop-optimized, mobile-optimized, and Responsive Web Design (RWD) sites.  There is nothing special that you need to do in configuration for mobile or tablet that is different from desktop.

 

Q: Does mPulse work with sites built on Single Page Application (SPA) frameworks?

A: mPulse has first-class support for sites built on the AngularJS, Backbone.js, Ember.js, React.js, and other SPA frameworks.  

 

Q: Does mPulse work with sites that use Content Distribution Networks?

A11: mPulse will work with sites that use CDNs.  There is nothing special that you need to do in configuration.

  

 

DEPLOYMENT

 

Q: Where do I need to deploy the mPulse Javascript tag on my web site?

A: Akamai strongly recommends that the mPulse Javascript tag load as early as possible in the page load to ensure that the code is executed and ready when the first onload events (indicating the complete page load) occur.  Our best practice recommendation is to load the tag in the <HEAD> of the base page HTML of each page on the site.  If the tag cannot be loaded in the <HEAD> of the document (perhaps because it needs to be loaded through a tag management system by corporate policy, for example), it should be loaded as soon as possible in the <BODY>.  The earlier in the page load that the Javascript is executed, the more accurate will be the metrics from legacy browsers that do not support the W3C Navigation Timing API.  For more information on this, see Tag Manager Improvements.

 

Q: How large is the Javascript tag that I need to deploy?

A: 878 bytes.

  

Q: Can I use my tag management system to deploy mPulse on my site?

A: Ideally, the mPulse Javascript tag should load as early as possible in the page load.  It is best if the tag completely loads before the page’s onload event fires, especially for legacy browsers that do not support the Navigation Timing API.  If the Boomerang library loads after the onload event, Page Load Time on browsers that do not support Navigation Timing will include the time between the onload event and when the Boomerang library actually loaded.  For more details on this, seeTag Manager Improvements.  Some tag management services support the ability to load tags early, but others always or almost always load mPulse after the onload event, and would not be as desirable for use with mPulse. Some specific details about deploying mPulse using Tealium can be found here.

 

Q: How can I find the version of Boomerang I have deployed?

A: The version of Boomerang used for any beacon is displayed in the Beacon Details widget of the Waterfall Dashboard in the Page Construction tab.  Alternatively, in your browser, load the URL http://c.go-mpulse.net/boomerang/<API-KEY> replacing the API-KEY with the value of the API Key assigned to your App.  When you have received the response to this request, search for the substring "BOOMR.version=".  The version of Boomerang being sent to users with your API Key will be in the double-quoted string that follows, e.g.: BOOMR.version="0.9.1422498372".  On UNIX or MacOS systems, you can also run the following from the command line to get the Boomerang version number:

 

curl -A 'Mozilla/5.0' http://c.go-mpulse.net/boomerang/<API-KEY> 2>/dev/null | grep 'BOOMR.version=' | sed -e 's/.*BOOMR.version=/BOOMR.version=/;s/;.*//'

 

Q: How can I test what will happen if mPulse or the third-party tag management system I use to inject the mPulse Javascript snippet go down?

A: One potential problem you'll face with any third-party call on your site is when the browser makes the request but no response comes back because servers are down, or if the response takes very long, like if they were under a DDoS attack.  To test for this possibility, Akamai recommends using the "SPOF" or "Single Point of Failure" feature of WebPageTest.  In the configuration of the WebPageTest run, enter the domain name of the third-party call whose failure you want to simulate.  To simulate a failure of the mPulse calls, use c.go-mpulse.net.  For more information on this tool, see: http://www.webpagetest.org/

 

Q: Can I suspend beacons from being collected?

A: Yes.  You can log into the mPulse site (http://mpulse.soasta.com/) and suspend the delivery of beacons from any app on which you have mPulse deployed.  This will not remove the mPulse Javascript tag from the site or prevent the loading of the Boomerang library in the browser, but no beacons will be sent to mPulse until suspend beacons is unchecked.

 

Q: What is the size of the first-party cookies that Boomerang uses for session ID tracking?

A: The cookies can be up to 5400 bytes in size.  Boomerang has code that will stop using the cookie if it starts to get larger than 5400 bytes to minimize overhead of mPulse on any application.  In practice, most cookies are 100 to 400 bytes.

 

Q: What is the expiration set to for the session cookie used by mPulse?

A: Seven (7) days after last use.  mPulse can also be configured to not use session-tracking cookies.

 

Q: Why are the requests for config.js or config.json being rejected with HTTP 403 Forbidden errors?

A: An HTTP 403 Forbidden response almost always means that the mPulse Javascript file is being requested with an API key that does not match the top level domain of the page being loaded in the browser.  This is a part of the security mechanism Akamai uses to prevent third parties from copying the tag from your site and using it on their own site.  If you need to deploy the exact same Javascript snippet (including the same API key) on development/QA servers in a pre-production environment that will be used on the production site, you can use the Development Server List feature in the App configuration to specify development servers whose traffic should be excluded from the mPulse Dashboards.  For more information, see Why Does the mPulse JavaScript Get a 403 Error on a Non-Registered Domain? 

 

 

CONFIGURATION

 

Q: What limitations are there in the use of Javascript variables in the mPulse App configuration?

A: 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.

 

Q: What limitations are there in the use of XPaths for custom metric collection?

A: Most modern browsers fully support parsing XPaths to identify specific page elements in the Document Object Model (DOM) of the page.  However, some browsers do not, with Internet Explorer and BlackBerry Browser being the most commonly encountered exceptions.  mPulse has two options for XPaths that can work with both IE and other modern browsers.  If the XPath specified for the custom metric is directly to an element with an ID (for example //*[@id="checkoutOrderTotalValue"]), then mPulse will use a document.getElementById call to directly get the value in that element.  There is also a very limited-functionality XPath parser built into Boomerang that can be used for IE and other browsers that do not have parsers built in.  This limited parser works for XPaths that only include exact tag names using @id or are rooted at the document root (for example /html/body/div/div/a/span).  This latter approach is riskier, as changes to the page structure could change the absolute XPath to the element you want to collect. Akamai recommends updating your page's HTML to include an ID for any element whose value you wish to capture in a custom metric as the most reliable approach to data collection.

 

Q: Can I change the maximum number of page elements for which Resource Timing data will be collected?

A: By default, most browsers will limit their reporting of Resource Timing to the first 150 requests on the page.  You can, however, place Javascript on your pages to increase the buffer size that the browser will use for those pages with more than 150 individual page elements.  See Increasing the default number of resources to report on in Resource Timing for more details.

 

Q: How do I get component-level data for Resource Timings for all of the domains on my site?

A: The timing 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.  In order to get component-level timing details for elements served from a different origin server than the origin server that delivers the base page HTML, you will need to have HTTP response headers configured to allow Cross Origin Resource Sharing (CORS).  See CORS and Resource Timing in mPulse  for more details.

 

Q: Can mPulse be used to monitor a site that is only accessible via IP address (not accessible via a domain name)?

A: No.  mPulse requires that the site be reachable via a domain name.

 

Q: How do I configure mPulse to collect additional custom parameters?

A: There are times that you might want to include custom parameters on the beacon that is sent to mPulse, generally for types of data that are not suitable for collection with Custom Dimensions. For example, collecting a unique customer ID or session ID might be useful for in-depth analysis of issues, but cannot be effectively accessed in the real-time mPulse dashboards because there are too many unique values. With some simple Javascript on the page, custom parameter data can be sent along with the mPulse beacon. This custom parameter data will not show up inside the mPulse dashboards, except for the Waterfall Dashboard where you can see it in the raw beacons details section.  You can use custom parameters in the DSWB. See Adding custom parameters to an mPulse beacon for details on the Javascript that needs to be inserted on the site to add these custom parameters to the beacon of data that is sent back to Akamai.

 

Q: When defining a URL Pattern for a custom metric, timer, or dimension, why does my regular expression not work?

A: When configuring custom timers, metrics, or dimensions, mPulse uses URL Patterns as part of the configuration.  URL Patterns are not the same as regular expressions.  A URL pattern only supports the following parameters:

  • A wildcard on the URL, e.g.: *orderconfirmation.jsp*
  • A strict URL that explicitly defines the target URL to be measured

 

Q: Is there a way to delay the sending of a beacon until some time after the onload event?

A:In certain cases, you may want to delay the mPulse beacon from firing on the load event. Akamai recommends some JS code that can be appended to the main beacon code that you copy out of the mPulse UI to accomplish this. See Delay the mPulse beacon from firing for X seconds for more details.

 

Q: What happens with the site visitor's IP address information if I turn on the "Strip IP Address From Raw Beacon Logs" feature in the App configuration?

A:The IP address is acquired via the TCP/IP headers between the browser and our CDN's servers. The CDN uses this IP to do IP-based rate limiting and if the request passes the rate limiting step, it forwards the request to the Akamai collector server. This is the first point at which it enters Akamai's system. From this point, we use the IP address to do geolocation, identify the ISP the user is on, and determine the network connection type (cable/DSL, cellular, corporate, dialup) using third-party databases that contain mappings based on IP address. After these dimensions have been determined, the next step for the IP address is to write it to the raw beacon log in Amazon S3. At this point, if the "Strip IP Address From Raw Beacon Logs" flag is set, then the IP address value is replaced with a string value "redacted" and the IP address is no longer present in the system.

 

 

DATA COLLECTION

 

Q: What percentage of site traffic is captured with mPulse?

A: mPulse will send beacon data for 100% of all page loads on a web site.  Because mPulse does not sample the data collection of metrics and timers, the margin of error can be kept as small as possible, resulting in a more complete and accurate portrayal of site health.  

 

Q: When are beacons of data sent to mPulse?

A: Beacons are fired immediately upon page load or when specifically called by AJAX or SPA navigation actions on a page. You should see the collected beacons in your mPulse dashboards within seconds, except for the Waterfall Dashboard, where beacons may take up to five minutes to be available.  Viewing historical data (collected more than 24 hours in the past) in the Waterfall dashboard may also take several minutes to load.

 

Q: How large is the beacon of performance data and metrics sent to Akamai for each page view?

A: The size of the beacon can vary depending on the number of custom metrics, timers, and dimensions collected on the page, whether or not the beacon includes Resource Timing data, and how many resources the page uses.  Beacons without Resource Timing data will typically be 2K to 3K in size.  Beacons with Resource Timing data can be twice as large or larger.

 

Q: What kinds of personal user data are collected in beacons, and how can I manage it to remain in compliance with privacy regulations?

A: By default, mPulse does not collect Personally Identifiable Information (PII) data as defined in United States privacy law.  All data stored in raw or aggregate format is only available outside of the customer’s tenant to key Akamai personnel. Domain specific data is NOT shared between tenants.  mPulse offers domain administrators the ability to disable cookies for session tracking, the ability to exclude IP addresses of site visitors from the raw data storage, as well as the ability to exclude query string parameter details from stored URLs.  More information on this topic is available on request.

 

Q: How do you identify and group key pages on my site for analysis?

A: In mPulse, Page Groups identify and segment the web app into logical page groupings (e.g. Home page, Search Results, Login, Add to Cart, etc.).  You have multiple options to identify Page Groups in mPulse.  You can identify types of pages based on Javascript variables on the page, using query string parameter values in the base document URL, substrings of the base document URL, or by applying a regular expression to the base document URL.  For advanced situations, you can also add custom Javascript to identify a page as well.

 

Q: What is a metric?  What is a custom metric?

A: mPulse considers metrics to be non-performance data resulting from user actions during a customer visit.  These can include bounce rate, conversion rate, order totals, number of items in cart, number of shares traded, etc.  Bounce rate, session length, and session duration are metrics built into mPulse.  Most other metrics (including conversion and order total) will need to be defined as custom metrics.  

 

Q: Can I track conversion rates or order totals with mPulse?

A: Most of the metrics that you will be interested in (such as conversions, order totals, number of items in cart, number of shares traded, etc.) will need to be defined as custom metrics.  You can define custom metrics using Javascript variables, URL patterns, or using XPaths on the page.  mPulse can track percentages (such as for computing conversion rate) or numbers (such as for computing order totals or number of items purchased).  

 

Q: What is a timer?  What is a custom timer?

A: Timers are performance data, such as DNS lookup time, SSL connection time, front-end time, back-end time, and page load time.  Timers are always measured in minutes, seconds, or milliseconds.  For modern browsers, mPulse will collect all of the timers defined in the W3C Navigation Timing API.  Custom timers can be defined to identify other key performance moments during a page load.  Some examples include time to first image, time to sidebar load, time to load content served from a specific third-party resource, etc.  

 

Q: What kinds of timers does mPulse collect?

A: By default, mPulse collects performance data for page load time and will collect all the timers defined by the W3C Navigation Timing API for those browsers that implement it.  For older browsers, mPulse estimates front-end and back-end performance timing.  mPulse can also collect custom timers using values from the W3C Resource Timing API and the User Timing API for those browsers that implement them. For a full list of all the parameters delivered in an mPulse beacon, see What's in a beacon.  For an up-to-date list of browser support for the Navigation Timing and Resource Timing APIs, see: http://caniuse.com/#search=Navigation%20Timing%20API and http://caniuse.com/#search=Resource%20Timing.

 

Q: Does mPulse collect timers for 'first paint' or 'initial render'?

A: Unfortunately, there is no standard defined by the World Wide Web Consortium (W3C) for browsers to report a standard timer value for when the user first sees visual changes in the browser viewport. Some browsers have developed their own reporting numbers and mPulse will collect those where they are available. You can view or filter on those values in the Waterfall Dashboard and use them in custom queries in the Data Science Workbench (DSWB). However, because different browsers calculate their numbers differently, making them not directly comparable with each other, those timers are not available for use in the other mPulse real-time dashboards. Currently, we collect this value for the following browsers:
     Chrome: window.chrome.loadTimes().firstPaint
     Internet Explorer: window.performance.msFirstPaint
     Edge: window.performance.msFirstPaint

 

Q: What is a dimension?  What is a custom dimension?

A:  In mPulse, dimensions are non-performance data about the user visit that help us categorize page views into useful segments for analysis.  Some dimensions capture details about the technology used by the visitor, including browsers, operating system, device details, and network details.  mPulse also collects geography and ISP details.  Most other dimensions will need to be defined as custom dimensions.  Popular custom dimensions include identifying pages served to logged-in or return users versus those served to not-logged-in or first-time visitors, identifying mobile-optimized versus desktop-optimized versions of pages, capturing the language or regional edition used for the page content, identifying a product family (kitchen, bath, outdoors, etc.) separately from the Page Group, tracking which application server or hosting server was used to generate the page, tracking pages with embedded videos or other features versus those without, and hooking into the JS variables used with complex multi-level A/B testing.  Custom dimensions are only available to mPulse Pro and mPulse Enterprise customers.

 

Q: Why do I see "Your tenant does not allow Dimensions" in my App config?

A: Dashboard performance may decrease if a custom dimension returns more than 100 unique values.  So, categorical dimensions work well because they can only return a limited number of possible values, whereas user-identifying parameters like usernames, user IDs, or session IDs are not compatible with mPulse custom dimensions.  mPulse customers new to the feature will be guided through configuration in an approval process to ensure success.  You will see the 'Your tenant does not allow Dimensions' message in the App configuration dialog until you have gone through the Custom Dimension approval process for the first time.

 

Q: What kinds of dimensions does mPulse collect?

A: By default, mPulse collects Beacon Type (page view, SPA hard, SPA soft, XHR, error), Country, Region (for select countries), Browser Family, Browser Version, Operating System, OS Version, Device Type (Desktop, Tablet, Mobile, Other), Device Manufacturer (for mobile devices), Device Model (for mobile devices), Connection Type (Cable/DSL, Corporate, Cellular, Dialup), and ISP (for select countries). mPulse has an A/B Test Variable feature for simple A/B test dimensions, and all other dimensions can be collected with Custom Dimensions.  For more information on custom dimensions, and how to configure them, see Custom Dimensions.

 

Q: How does mPulse identify the operating systems and browsers used by real users?

A: mPulse relies upon the industry standard UA-Parser project to parse the User-Agent string of the HTTP request and pull out browser family and version, operating system family and version and a few other fields. For more details on the UA-Parser project, see: https://github.com/ua-parser/

 

Q: How does mPulse identify and track user sessions?

A: mPulse sets a session cookie on the primary domain that allows us to track that user session.  Boomerang does not track users beyond a session.  mPulse has a default session timeout of 30 minutes, but can be configured to any number of minutes between 1 and 60.  mPulse will consider a user session open until 30 minutes (or the customized number of minutes) after the last beacon was sent. Session-based percentages (bounce rate, conversion rate, etc.) are recorded at the end of the session.  mPulse can be configured not to use session-tracking cookies, which would disable the ability to track session-based metrics.

 

Q: How does mPulse calculate the duration (in time) of a session?

A: mPulse calculates the session start time as the minimum value timestamp of page navigation start (if the browser supports Navigation Timing API) or boomerang start (for legacy browsers). The session end time is the last event time seen on the session (either the load event of the final page or the final unload event). Capturing the dwell time for the final page in a session is the most challenging. If an unload beacon arrives after the final page view in a session (about 70% of the time it will not arrive), we change the session end time to the timestamp of that final unload beacon. Unfortunately, about 70% of the time we are never get a final beacon for an unload event. Mobile browsers almost never send it because the page is only unloaded when the browser is force killed. In the case of desktop browsers, there is also a high probability that the network connection gets garbage collected by the browser before the request goes out if the browser/tab is closed. In those cases, the session end time will be the time when the final page in the session completely loaded and will not include any dwell time after the page load.

 

Q: What happens if a user closes their browser before the page load is complete?

A: If the user closes their browser before the page load is complete, mPulse will often still receive a beacon from that page load, as the browser will fire an "unload" event, which triggers beacon delivery in the Boomerang code. If the beacon is fired before the onload event, one of the parameters in the beacon data (rt.abrt) will indicate that the user aborted the page load before it was complete. Data from those beacons is used for session calculations such as session length and session duration, but the timers in those beacons are considered untrusted and not used. There is also a 50-60% chance that we will not receive the beacon if the user closed the browser during a page load.

 

Q: Will mPulse collect data on my synthetic performance monitoring tests?

A: If you are using a synthetic performance monitoring system on your site (such as those offered by Keynote, Compuware Gomez, AlertSite, etc.) you probably do not want to be beaconing back performance information for these non-human page views.   All of the most popular synthetic performance monitoring services intentionally modify the User-Agent string (by appending specific sub-strings like “KTXN”, “GomezAgent” or “AlertSite” to the end of the string) that they send when making connection to your web site, so that they can be uniquely identified.  mPulse uses these identifiers to optionally filter out the robot traffic using the same mechanism as when you Suspend Beacons manually in the mPulse domain configuration dialog.  For more information 204 Response for config.js from Synthetic Monitoring Tools.

 

Q: Does mPulse have support for A/B testing?

A: mPulse can use a Javascript variable set on the page to identify different versions of pages during A/B testing.  Despite being called A/B testing, the variable is actually not limited to just two potential values, so multiple versions of a site can be separately analyzed.  This feature in mPulse can also be used for other purposes, such as tracking logged-in versus not-logged-in versions of pages.  

 

Q: How can mPulse measure ‘above the fold’ render time?

A: With the mPulse Custom Timers feature, you can use a JavaScript variable or User Timing mark instrument a timer that fires close to the bottom of the fold. 

 

Q: Why did my bounce rate change when I turned on 'Auto-XHR' data collection?

A: Akamai mPulse calculated Bounce Rate as the percentage of user sessions with a single beacon.  If your site uses AJAX and there are XHR requests made after onload on a visitor's landing page view, you can expect to have more than one beacon for that session, even if the user does not visit a second page.   mPulse does not automatically filter out XHR beacons from bounce rate calculations because you might have a site (such as a Single Page Application, or SPA, design site) where those XHR beacons represent user actions or navigations that you want to treat in the same way as new page requests for session-based metrics like bounce rate.  If you prefer to exclude those XHR requests from the Bounce Rate calculation, you should create Page Group rules that match the URLs for the XHR requests using regular expressions, and in those rule definitions, check the "subresource" checkbox.   mPulse will not use beacons assigned to "subresource" Page Groups in calculating Bounce Rate or other session-based metrics.

 

USING THE DATA

 

Q: How long does it take for beacon data to be available in the Akamai Dashboards?

A: Beacons are fired immediately upon page load or when specifically called-for AJAX actions happen on a page, and (with the exception on the Waterfall dashboard) you should see the data in your mPulse dashboards within seconds. The Waterfall Dashboard uses a separate database to handle and process the individual beacon data.  This secondary database is loaded in a batch process from the raw JSON beacon logs.  The batch processing means that beacons may not be available in the Waterfall dashboard for up to two minutes after the page view.  This CloudLink article is a good start for new users learning the features available in the mPulse Dashboards here mPulse Dashboard Widgets

 

Q: How long is mPulse data stored?

A: The most recent 13 months of data is stored at minute-level granularity for visualization in the real time dashboards.  For even longer-term data storage options, mPulse Enterprise customers can use the raw beacon access features of the product to collect and store the raw data in their own data warehouses.

 

Q: Can I get breakdowns by regions inside a country? 

A: mPulse offers regional breakdowns in the real time dashboards for the US, Canada, and the UK by default.  Breakdowns by region for a limited number of other countries are available as a configurable option with approval.  Regional details are stored for every beacon in the raw beacon data and in the Waterfall dashboard.

 

Q: When does mPulse use medians and when does mPulse use means?

A: By default, mPulse reports on median (50th percentile) for any timer or other measurement that uses data across multiple users of the site or application.  You can adjust this to any arbitrary percentile value between 1 and 100.  For timers and measurements within a single user session, however, mPulse reporting uses the arithmetic mean.  For sessions, each data point is based on the arithmetic mean of the load times of all pages of a single user across a single session.

 

Q: What does Akamai mean by "Page Load Time"?

A: Page Load Time, as reported in mPulse, is the time from the page request to the "onload" or "load" event in the browser. In the event that the Boomerang library was not already in the browser cache and was not loaded in the browser before the onload event, and the browser does not support the Navigation Timing API, then Page Load Time can also include the time between onload and when the Boomerang library was first loaded.  For more details on this, see Tag Manager Improvements

 

Q: What does Akamai mean by the terms "Back-End Time" and "Front-End Time"?

A: In Akamai mPulse, "Back-End Time" is the time it takes the server to dynamically generate or fetch the base document after a new page request.  The portion of the page load time that follows the "Back-End Time" is what Akamai 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.  For more details on these two timers, see Back-End Time and Front-End Time.

 

Q: When I add the "Back-End Time" and "Front-End Time" together, the sum does not equal the "Page Load Time" in the dashboard.  Why not?

A: By default, mPulse reports on median (50th percentile) for each of these timers.  You cannot compare the sum of medians to the median of sums.  For example, if you had three beacons with the following timers:

 

Front End: 3100ms, Back End: 100ms, Page Load: 3200ms Front End: 3000ms, Back End: 200ms, Page Load: 3200ms Front End: 3200ms, Back End: 200ms: Page Load: 3400ms

The resulting medians would be 3100 ms for Front-End Time, 200 ms for Back-End Time, and 3200 ms for page load time.  As you can see, the sum of the median Front-End Time and the median Back-End Time does not equal the median page load time.  This is true for all percentiles, not just the 50th percentile (median).

 

Q: How is the Margin of Error in mPulse dashboards calculated?

A: The Margin of Error is a statistical computation on the sample based on a confidence interval at 95% confidence level.  The smaller the margin of error, the higher confidence that the value being presented is an accurate representation of the result.

 

Q: What range of Page Load Times does mPulse consider valid?

A: The mPulse UI will only use beacon data when the beacon has a page load time between 1 and 600,000 ms (10 minutes).  Additionally, the real time dashboards will exclude beacons that were collected while the browser was in the process of shutting down (abort beacons) as those timers may not be reliable.  If you are analyzing your own raw beacon data, Akamai recommends that you incorporate a similar restriction in your computations as a best practice.

  

Q: Can I filter XHR vs. non-XHR traffic in mPulse?

A: Yes, mPulse dashboards can use a “Beacon Type” filter that lets you filter traffic to use only Page View beacons, use only XHR beacons, or use all beacons.  The "Beacon Type" filter is availble on all of the system dashboards.  If you enable XHR beacons, the "Beacon Type" filter option is notautomatically added to the filter bar of existing custom dashboards, but you can add it just as you would any other filtering option.

 

Q: When I go into the Waterfall Dashboard and choose ‘last 3 days,’ or any pre-selected time filter, why don’t I see any beacons?

A: The Waterfall Dashboard will only display beacons for a 60 minute (or shorter) time frame in the most recent 13 months.  The beacons that you see in the list in the Beacons widget of the dashboard will be from the first 60 minutes starting from the beginning of the date/time in the filter you select. If you chose 'Last 30 days', for example, it will be the first 60 minutes from 30 days ago.  It’s highly recommended that you use the ‘between’ option in the Date/Time filter to choose a specific hour in which you know beacons exist.

 

Q: Why are my conversion numbers really skewed in the What-If Dashboard?

A: The What-If Dashboard calculates the conversion percentage rate based on the sum of the conversion metric values from beacons in completed user sessions divided by the number of completed sessions.  This works perfectly if the value used for the Conversion custom metric is a boolean value of either ‘0’ or ‘1’.  If you are using a Javascript variable for the custom metric and it is not returning either of these numeric values, the number will not accurately represent a conversion percentage. If you use a URL Pattern to define the Conversion custom metric, Boomerang automatically assigns a 0 or 1 to the metric value for each beacon.

 

 

EXPORTING, IMPORTING, AND SHARING DATA

 

Q: Can I retrieve aggregated data for use in my own analytics engines or tools?

A: The mPulse Query API is a unified REST API that allows mPulse customers to send a query and receive a JSON response with aggregated mPulse data.  Data for a given date is aggregated per minute for the given 24-hour period. Data returned will always be limited to one calendar day in the timezone. If the date is 'today', it is still aggregated per minute, only from midnight to the current time (e.g. the time of the query).  Data sets, navigation timing, custom timers and metrics are supported.  For more details on the mPulse Query API, see Query API.

 

Q: Can I get the raw beacon data?

A: The raw data that Akamai collects can be very large in size and requires a more efficient transfer mechanism than a REST API.  mPulse customers can have the raw data uploaded directly to their own bucket in the Amazon Web Services (AWS) Simple Storage Service (S3).  For more information, see the "Amazon S3 Upload Setup for Domain-Specific Beacon Logs" section on the mPulse Administration: Beacon Settings page. 

 

Q: Can I import data to use in Dashboards from an external source like AppDynamics?

A: With Akamai mPulse, you can include data from External Sources in your custom dashboards to give you a richer, more meaningful view into the user experience.  Once configured, AppDynamics widgets can be added to dashboards alongside other mPulse widgets. mPulse presents aggregate data at any capacity supported by the user’s AppDynamics credentials.  For more information on AppDynamics integration in mPulse, see Integrating AppDynamics as an External Data Source

 

Q: Can I share Dashboards with custom links?

A: Yes.  When sharing a dashboard with a link, you can choose to have the link be either Private (authentication with an mPulse login is required) or Public (login is not required, but the dashboard will be read-only, allowing others to view the dashboard but not make any changes to its configuration.)  Note that shared dashboard links currently have no expiration, so use public links with caution.  For more information on sharing dashboards in mPulse, see Share Dashboard.

  

Q: Can I restrict some user accounts on mPulse to be read-only?

A: With mPulse, you can create User accounts with different levels of data access and privilege.  Users can be Administrators allowed to create new apps and new users, while other users can be restricted from making any changes to the system.  For more information on using the Permissions features in mPulse, see Permissions.

 

Q: Can I restrict users to be able to view only certain custom Dashboards?

A: Yes, users can be restricted from viewing certain custom dashboards.  This could be very useful for allowing certain Users access to technical performance data without revealing potentially sensitive business metrics like conversion rate or order totals.  For more information on using Permissions in mPulse, see Permissions.

 

 

SINGLE PAGE APPLICATIONS

 

Q: What Single Page Application (SPA) frameworks does mPulse support for measuring?

A: Akamai mPulse has native support for the following Single Page Application Frameworks:

  • AngularJS: Both the default AngularJS router and UI router are supported.
  • Backbone.js: The standard Backbone.js router is supported. 
  • Ember.js: The standard Ember.js router is supported. 
  • React.js: The standard React.js router is supported. .
  • Others: We support other SPA frameworks as long as they use the HTML5 History API or change the location hash state. 

 

Q: If I have a SPA that is not entirely using AngularJS (or some other supported framework), can I measure and track my application?

A: mPulse will measure and track every part of the SPA that is using one of the above frameworks (and common implementations). If there are some pages that have the SPA framework and some that don’t have a SPA framework, there are configuration options that should be put on the page to tell Boomerang this. (See Boomerang for the example code for AngularJS). For any part of the SPA that is not using one of the supported frameworks, we may need to do custom engineering to instrument mPulse with the app.

 

Q: Does mPulse distinguish between XHR requests that are generated by user actions and other XHR requests?

A: How mPulse processes XHR requests for Single Page Applications depends upon whether or not the “Automatically Instrument XHR Requests” checkbox is selected in the App configuration:

  • If just a “Framework” is selected, one beacon will be sent for each SPA navigation (hard or soft.)  mPulse considers all soft navigations that are part of the same application request initiated by the user to be a single page view. 
  • If a “Framework” and “Automatically Instrument XHR” are both selected, then one beacon will be sent for each SPA navigation (hard or soft), plus any XHRs that happen outside of a SPA navigation will get their own separate beacons as well.
  • If you want to track all XHRs that happen during an SPA navigation in addition to the SPA navigation beacon, there are configuration options available to have Boomerang send beacons for both.

 

Q: How do I configure A/B testing for various versions of my SPA within mPulse?

A: A/B Testing works the same for SPA apps as it does for non-SPA apps.

 

 

BANDWIDTH TESTING

 

Q: How does mPulse collect metrics on site visitor bandwidth?

A: mPulse Pro and mPulse Enterprise customers can perform bandwidth tests on real site visitors, but the feature is not turned on by default.  Bandwidth testing is done by having the site visitor browser make multiple requests for progressively larger and larger files from your web server or your CDN provider's servers. These files are in a non-compressible image format, to ensure that a known number of bytes are sent and received during the test. The specific files to use for the bandwidth test can be downloaded from the mPulse user interface, and you will need to provide the URL for their hosting location in the mPulse App configuration.  For more technical details about the way that Boomerang implements bandwidth testing, see: http://soasta.github.io/boomerang/doc/methodology.html   For more detailed information on bandwidth testing configuration in mPulse, see Configuring mPulse to measure user Bandwidth.

 

Q: Will mPulse bandwidth testing slow down the user experience for my site?

A: Image files for the bandwidth test are downloaded between complete page loads and the bandwidth testing is abandoned whenever new real user interaction begins.  If the testing is interrupted, then it will be restarted after the next page.  Site visitors should experience no degradation in site experience.

 

Q: How large are the files that a bandwidth test will load?

A: The set of images files that you will need to host range from about 11K to 9MB.  Boomerang will download images in ascending order of size until an image takes more than 1.2 seconds on average to load.  It will stop at that image and not go on to the larger images.  This means that users on very slow connections will only load the smallest images. 

 

Q: How often are mPulse bandwidth tests performed for any particular site visitor?

A: Bandwidth testing is only performed once every 7 days for each user.  This is managed by a cookie that is tied to the user’s subnet.  If either seven days have elapsed, or the user’s subnet has changed, mPulse may run a new bandwidth test from that user.  

 

Q: Can I throttle or limit bandwidth testing?

A: You can define a sampling percentage to limit bandwidth testing to a percentage of the real user population.  This can help control costs and resource consumption on your systems or the CDN you are using.

 

Q: Can I disable bandwidth testing for mobile site visitors?

A: Yes.  You can disable bandwidth testing for users on mobile network connections with a setting in the mPulse domain configuration dialog.  Mobile browsers or devices that can be identified as connected via WiFi or cable/DSL network connections may still run bandwidth tests.

 

Q: Should I host the image files used for bandwidth testing on my origin server or on my CDN?

A: The decision where to place bandwidth images depends on what you want to measure, and how your CDN provider charges you. Do you want to measure bandwidth to your origin server or to your CDN?  The images are not cached on the client, and we use cache-busting query string parameters to force an image reload. This is necessary to make sure we're testing the bandwidth to your server and not the bandwidth to a local browser cache. If you put the images on your CDN, your CDN will make a call back to your origin server every time a user gets tested unless you can configure your CDN provider to ignore query string parameters for these images.  Placing the bandwidth testing images on a CDN service will likely result in additional charges from the CDN provider. Akamai recommends that, if you wish to use a CDN, set the sampling percentage to a very low value at first to see what the cost impact will be.

 

Q: Can I perform bandwidth testing on an HTTPS site?

A: No.  Bandwidth testing is disabled over HTTPS.  The TLS handshake and encryption adds overhead to the bandwidth test and results in invalid measurements.  The bandwidth calculation algorithm is tuned for use on non-secure HTTP connections.

 

 

SUPPORT

 

Q: Does mPulse have a professional services offering?

A: Yes.  Packaged services, including Basic Implementation (to help get your site up and running and your key stakeholders trained as quickly as possible), training, custom reporting, and business analysis consulting are available through Akamai Professional Services.

 

Q: Where do I go to get more help?

A: mPulse customers with a professional services contract with Akamai should first reach out to their Enterprise Architect for help and advice.  For others, the first stop for support questions after this FAQ is searching for your question here in the Akamai Community.   For more information on Support go here.

2 people found this helpful

Attachments

    Outcomes