mPulse is designed to capture 100% of user traffic, providing full visibility into the end-user experience. Unlike other RUM solutions that sample traffic, mPulse allows you to see events like micro-outages that would likely be impossible to detect with sampling. With that said, there could be instances where sampling of mPulse traffic is needed. For example, a user has budgetary constraints and wants to keep their beacon count low, but still wants to track errors on the site or receive alerts of certain SLA violations – things that you can’t do with the free version of mPulse – mPulse Lite.
There are four methods that you can use to sample mPulse traffic if mPulse is being injected through the Akamai property manager. Let’s review them here:
1 – Basic Sampling
The simplest way to enable sampling is using the Sample Percentage criteria in Property Manager. This allows you to select the percentage of requests that you want to the mPulse behavior injected into, as shown below:
There are a few things to note with this approach. First, it’s important that you remove the mPulse behavior from your Default Rule, or anywhere else you may have it. Secondly, you must include the API Key of your mPulse app in the Optional Overrides section of the behavior. If you don’t include the API Key, mPulse will be injected in 100% of requests, as if the Sample Percentage criteria didn’t exist.
You can find your API Key in mPulse my going to Central -> Apps -> Right Click on your app and Open
Your API Key will be exposed on the General Tab.
2 – User Variable
The second method is to use a custom property variable in conjunction with match criteria.
In this example, we’ve created a property variable called PMUSER_MPLUSE, with a default value of ‘false’.
Next we apply whatever criteria we want for the mPulse injection. In this example we’re looking for one of two host names. We could also look for a certain path if we only want mPulse included on specific pages.
Then we include a behavior that sets our PMUSER_MPULSE variable to ‘true’.
Finally, we create a new mPulse rule that checks for value of the property variable and uses the Sample Percentage criteria:
In this example we are injecting the mPulse behavior for 10% of the requests. NOTE: You must include the mPulse API Key whenever you use the Sample Percentage criteria.
3 – Use MPULSE_SNIPPET Variable
Similar to the previous method, this method uses a variable, however, it uses the built-in variable mPULSE_SNIPPET that can be turned on and off to determine if the mPulse snippet gets injected.
We first set the value of the variable to ‘false’ in the Property Variables section.
Next we create a Sample rule that uses the Sample Percentage criteria with a behavior that sets the variable to ‘true’.
Finally, we create an mPulse injection rule that simply enable mPulse.
Note that no criteria is required for this behavior because the injection will only happen if the variable is set to ‘true’. Also note that no API Key is required when using the approach. The default API Key for the property will apply.
4 – Cookie Based for Session Tracking
The previous methods of mPulse sampling are quick and easy to implement. However, they work on a per request/page basis. So depending on your sample percentage, the first page of the session may get mPulse and the second page may not. This approach breaks mPulse’s ability to track session data, such as the number of pages in a session or session duration.
If you want to maintain session tracking data, you need a way to sample on a session by session basis rather than page by page. The final approach sets a cookie that is valid for the session and ensures that mPulse gets injected on every page of the session.
First we define a user variable. (See methods 1 & 2).
Next we check to see if our cookie exists and has a value of ‘true’. This will be the case for subsequent pages in the session.
Next, in our sampling rule, we check to see if the cookie exists. If not, we do our sampling (50% in this case) on requests missing file extensions to avoid static assets affecting the desired sample rate. We then set our variable to ‘ON’.
Next we set the cookie to ‘true’ if the variable is ‘ON’ and the content type is HTML.
Next we have a rule to set the cookie ‘OFF’ if the user wasn’t selected in the sample. The user will get another opportunity to be sampled in an hour.
Finally, we inject mPulse if the variable is ‘ON’:
Summary
mPulse is best used when it gets injected into every page for every user. However, there are instances where the Enterprise features of mPulse are needed but not for every user/page. The four methods mentioned above can be used to enable sampling of the mPulse behavior when full visibility is not required.