09-03-2014 12:20 PM - last edited on 01-13-2017 02:40 PM by dmurphy
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.
Using the Data
Exporting, Importing, and Sharing Data
Single Page Applications (SPA)
A1: mPulse is SOASTA’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: http://cdn.soasta.com/wp/wp-content/uploads/2012/1
A3: The SOASTA 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 SOASTA into a SOASTA designed schema in Amazon Redshift. 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. For more information, see: http://www.soasta.com/wp-content/uploads/2015/05/d
A5: mPulse Lite gives you a chance to try mPulse on your own site for free, but has some limitations in scope and functionality. With mPulse Lite, you are limited to a smaller number of beacons (page views) per day and you cannot define custom metrics or custom timers. You also have a limited number of Page Groups available, and you cannot create custom Dashboards. Upgrading to mPulse Pro from mPulse Lite is easy and you can use your already created App configurations from mPulse Lite without having to start over. mPulse Pro increases the number of logins you can have for users, allows access to the Waterfall Analysis Dashboard, custom dashboards, bandwidth testing, more page groups, and allows up to 1 million beacons/month. mPulse Enterprise is the right solution for sites with more than 1 million page views per month, and offers even more features including the What-If Analysis Dashboard, unlimited page groups and users, more custom metrics and timers, and access to aggregated and raw data. You can sign up for mPulse Lite here: http://www.soasta.com/free/ and you can watch our Getting Started with mPulse Lite video here: http://www.soasta.com/getting-started-mpulse/
A6: Please be sure to check your spam filters and whitelist firstname.lastname@example.org. If you are still having issues, please contact SOASTA via the Contact Support page.
See http://caniuse.com/#search=TLS%201.2 for a list of browsers with TLS 1.2 support.
See http://caniuse.com/#search=Resource%20Timing for a list of browsers that support Resource Timing.
A9: 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 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.
A13: 878 bytes.
A15: 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/;.*//'
A16: 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, SOASTA 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/
A18: 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.
A19: Seven (7) days after last use. mPulse can also be configured to not use session-tracking cookies.
A22: 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. SOASTA 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.
A25: No. mPulse requires that the site be reachable via a domain name.
A27: 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:
A28:In certain cases, you may want to delay the mPulse beacon from firing on the load event. SOASTA 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 http://cloudlink.soasta.com/t5/mPulse/Delay-the-mP
A29: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 SOASTA collector server. This is the first point at which it enters SOASTA'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.
A29: 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. Note: mPulse Lite and mPulse Pro both have limitations regarding the total number of samples per month, and sites that begin to exceed those limits will see throttling on the data collection.
A30: 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 two minutes to be available.
A31: 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.
A32: 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 SOASTA 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.
A34: 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. Custom metrics are only available to mPulse Pro and mPulse Enterprise customers.
A36: 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. Custom timers are only available to mPulse Pro and mPulse Enterprise customers.
A37: 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: http://cloudlink.soasta.com/t5/Knowledge-Base/mPul
A38: 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
A39: 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.
A40: 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.
A41: By default, mPulse collects Beacon Type (page view or XHR), 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: http://cloudlink.soasta.com/t5/mPulse-Resources/Cu
A42: 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/
A43: 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.
A44: 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.
A45: 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.
A46: 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 filter out the robot traffic using the same mechanism as when you Suspend Beacons manually in the mPulse domain configuration dialog. For more information: http://cloudlink.soasta.com/t5/mPulse-Technical-Ar
A49: SOASTA 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
A50: 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: http://cloudlink.soasta.com/t5/Knowledge-Base/mPul
A51: Data is stored at minute-level granularity for different lengths of time for the three different mPulse product tiers. mPulse Lite customers get 30 days of data retention, mPulse Pro customers have 90 days of data retention, and mPulse Enterprise customers enjoy 18 months of data retention. For even longer-term data storage options, mPulse Enterprise customers can use the Aggregate API or raw beacon access features of the product to collect and store the data in their own data warehouses.
A52: mPulse Pro and mPulse Enterprise customers receive regional breakdowns 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. mPulse Lite customers are limited to country-level breakdowns.
A53: 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.
A54: 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: http://cloudlink.soasta.com/t5/mPulse/Tag-Manager-
A56: 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).
A57: 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.
A58: The mPulse UI will only use beacon data when the beacon has a page load time between 1 and 600,000 ms (10 minutes). If you are analyzing your own raw beacon data, SOASTA recommends that you incorporate a similar restriction in your computations as a best practice.
A59: 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 not automatically added to the filter bar of existing custom dashboards, but you can add it just as you would any other filtering option.
A60: The Waterfall Dashboard will only display beacons for a 60 minute (or shorter) time frame in the most recent 18 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
A62: The Aggregate API for mPulse is a unified REST API that allows mPulse Enterprise customers to fetch aggregate data and receive a JSON response with 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. The Aggregate API is not available for mPulse Lite or mPulse Pro customers. For more details on the mPulse Aggregate API, see: http://cloudlink.soasta.com/t5/Knowledge-Base/mPul
A63: The raw data that SOASTA collects can be very large in size and requires a more efficient transfer mechanism than REST API. mPulse Enterprise customers can have the raw data uploaded directly to their own bucket in the Amazon Web Services (AWS) Simple Storage Service (S3). Raw data access is not available for mPulse Lite or mPulse Pro customers. For more information, see the "Amazon S3 Upload Setup for Domain-Specific Beacon Logs" section on this page:
A64: With SOASTA 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 http://cloudlink.soasta.com/t5/Knowledge-Base/Inte
A65: 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.) For more information on sharing dashboards in mPulse, see http://cloudlink.soasta.com/t5/mPulse-Resources/Sh
A66: 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: http://cloudlink.soasta.com/t5/CloudTest-Technical
A67: 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: http://cloudlink.soasta.com/t5/CloudTest-Technical
SINGLE PAGE APPLICATIONS
A68: SOASTA mPulse has native support for the following Single Page Application Frameworks:
A69: 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 http://cloudlink.soasta.com/t5/mPulse-Resources/mP
A70: 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:
A71: A/B Testing works the same for SPA apps as it does for non-SPA apps.
A72: 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://www.lognormal.com/boomerang/doc/methodology
A73: 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.
A74: 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.
A75: 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.
A76: 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.
A77: 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.
A78: 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. SOASTA 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.
A79: 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.
A80: Yes. Packaged services, including Quick Starts (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 SOASTA Professional Services.
A81: mPulse customers with a professional services contract with SOASTA should first reach out to their Web Performance Consultant for help and advice. For others, the first stop for support questions after this FAQ is searching for your question in SOASTA CloudLink (http://cloudlink.soasta.com/). mPulse customers should register for the Premier section of CloudLink to gain access to an extensive Knowledge Base, over 100 training videos, an active community of users, tutorials, and other references. On CloudLink Premier, you can also find detailed information on how mPulse Pro and mPulse Enterprise customers can submit bug reports, feature requests, and get email support from SOASTA. mPulse Enterprise customers also get access to 24x7 phone support options.
© 2015 SOASTA. All Rights Reserved. Privacy & Legal