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.
- What is Akamai mPulse?
- What is Boomerang?
- What is the Data Science Workbench (DSWB)?
- Will mPulse slow down my site?
- What kinds of web sites are compatible with mPulse?
- What kinds of browsers are compatible with mPulse?
- Does mPulse work with mobile-optimized web sites?
- Does mPulse work with sites built on Single Page Application (SPA) frameworks?
- Does mPulse work with sites that use Content Distribution Networks?
- Can I use my tag management system to deploy mPulse on my site?
- How can I find the version of Boomerang I have deployed?
- How can I test what will happen if mPulse or the third-party tag management system I use to inject t...
- Can I suspend beacons from being collected?
- What is the size of the first-party cookie that Boomerang uses for session ID tracking?
- What is the expiration set to for the session cookie used by mPulse?
- Why are the requests for config.js or config.json being rejected with HTTP 403 Forbidden errors?
- What limitations are there in the use of XPaths for custom metric collection?
- Can I change the maximum number of page elements for which Resource Timing data will be collected?
- How do I get component-level data for Resource Timings for all of the domains on my site?
- Can mPulse be used to monitor a site that is only accessible via IP address (not accessible via a do...
- How do I configure mPulse to collect additional custom parameters?
- When defining a URL Pattern for a custom metric, timer, or dimension, why does my regular expression...
- Is there a way to delay the sending of a beacon until some time after the onload event?
- What happens with the site visitor's IP address information if I turn on the "Strip IP Address From ...
- What percentage of site traffic is captured with mPulse?
- When are beacons of data sent to mPulse?
- How large is the beacon of performance data and metrics sent to Akamai for each page view?
- What kinds of personal user data are collected in beacons, and how can I manage it to remain in comp...
- How do you identify and group key pages on my site for analysis?
- What is a metric? What is a custom metric?
- Can I track conversion rates or order totals with mPulse?
- What is a timer? What is a custom timer?
- What kinds of timers does mPulse collect?
- Does mPulse collect timers for 'first paint' or 'initial render'?
- What is a dimension? What is a custom dimension?
- Why do I see "Your tenant does not allow Dimensions" in my App config?
- What kinds of dimensions does mPulse collect?
- What are the limitations on Custom Dimensions?
- How does mPulse identify the operating systems and browsers used by real users?
- How does mPulse identify and track user sessions?
- How does mPulse calculate the duration (in time) of a session?
- What happens if a user closes their browser before the page load is complete?
- Will mPulse collect data on my synthetic performance monitoring tests?
- Does mPulse have support for A/B testing?
- How can mPulse measure ‘above the fold’ render time?
- Why did my bounce rate change when I turned on 'Auto-XHR' data collection?
Using the Data
- How long does it take for beacon data to be available in the Akamai Dashboards?
- How long is mPulse data stored?
- Can I get breakdowns by regions inside a country?
- When does mPulse use medians and when does mPulse use means?
- What does Akamai mean by "Page Load Time"?
- What does Akamai mean by the terms "Back-End Time" and "Front-End Time"?
- When I add the "Back-End Time" and "Front-End Time" together, the sum does not equal the "Page Load ...
- How is the Margin of Error in mPulse dashboards calculated?
- What range of Page Load Times does mPulse consider valid?
- Can I filter XHR vs. non-XHR traffic in mPulse?
- When I go into the Waterfall Dashboard and choose ‘last 3 days,’ or any pre-selected time filter, wh...
- Why are my conversion numbers really skewed in the What-If Dashboard?
Exporting, Importing, and Sharing Data
- Can I retrieve aggregated data for use in my own analytics engines or tools?
- Can I get the raw beacon data?
- Can I import data to use in Dashboards from an external source like AppDynamics?
- Can I share dashboards with custom links?
- Can I restrict some user accounts on mPulse to be read-only?
- Can I restrict users to be able to view only certain Dashboards?
Single Page Applications (SPA)
- What Single Page Application (SPA) frameworks does mPulse support for measuring?
- If I have a SPA that is not entirely using AngularJS (or some other supported framework), can I meas...
- Does mPulse distinguish between XHR requests that are generated by user actions and other XHR reques...
- How do I configure A/B testing for various versions of my SPA within mPulse?
- How does mPulse collect metrics on site visitor bandwidth?
- Will mPulse bandwidth testing slow down the user experience for my site?
- How large are the files that a bandwidth test will load?
- How often are mPulse bandwidth tests performed for any particular site visitor?
- Can I throttle or limit the bandwidth testing?
- Can I disable bandwidth testing for mobile site visitors?
- Should I host the image files used for bandwidth testing on my origin server or on my CDN?
- Can I perform bandwidth testing on an HTTPS site?
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.
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.
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.
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.
A11: mPulse will work with sites that use CDNs. There is nothing special that you need to do in configuration.
A: 878 bytes.
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/;.*//'
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/
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.
A: Seven (7) days after last use. mPulse can also be configured to not use session-tracking cookies.
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.
A: No. mPulse requires that the site be reachable via a domain name.
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
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.
A:The IP address is acquired via the TCP/IP headers between the browser and our CDN's servers. 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.
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.
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.
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.
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.
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.
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.
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.
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:
Internet Explorer: window.performance.msFirstPaint
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.
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.
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.
A: I addition to the policy limitation of no more than 100 unique values in a Custom Dimension, there is a hard limit of 150 characters for the value captured in a custom dimension. For more information on custom dimensions, and how to configure them, seeCustom Dimensions.
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/
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
EXPORTING, IMPORTING, AND SHARING DATA
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.
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.
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.
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.
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.
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
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.
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.
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.
A: A/B Testing works the same for SPA apps as it does for non-SPA apps.
A: mPulse 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.