App Admins can define dimensions to track on each beacon. Beacon-level dimensions can be defined using one of six supported pattern-matching techniques, or value types found in the Configure Apps box, Advanced view, Dimensions tab.
SOASTA recommends defining dimensions on value types that have relatively few possible values. With that in mind, a good example is a dimension used to track free and paid users on a domain.
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.
Identity-tracking dimensions, however, are riskier for performance because they can return millions of unique values. Displaying a list of 1 million values in a dashboard will take longer to load and analyze than a list of 100 values. Examples include: user ID, session ID, and username.
Tenants are each limited to 10 custom dimensions.
Within individual dimensions, an alias map can be used to create user-friendly values for display in dashboards.
The App Administrator can use any of the following Value Source techniques to define a dimension:
No matter which type you choose, the value is extracted on the client side (inside the browser).
Some custom dimensions only apply to a portion of your website. In those cases, you can limit the set of URLs for which the dimension value will be extracted, using the "URL Pattern" input. For example, if a custom dimension only applies to the online store portion of your site, the URL pattern might be
Note that URL patterns are not regular expressions. Their syntax is limited to asterisk wildcards.
Dimensions may be of three (user facing) types:
In some cases, the actual value extracted at runtime is not the value that you want to display in dashboards. For example, let’s say you’re setting up an "Account Type" dimension, whose values are "Free", "Pro", or "Enterprise". The value will be extracted from a cookie, but it turns out that the cookie uses internal codes, like "f", "p"and "e".
You can define an Alias Maps to translate the internal values collected in the browser to "user-friendly" values that will be shown in the mPulse dashboard and alert UIs.
For example, a simple Alias Map for user authentication status plus user type might be defined using the following user-defined values and aliases (with the numeric dimension type):
For the map defined above, mPulse will get the numeric value and place it on the beacon, save that value to the database, and then display the user-friendly alias in dashboards (e.g. as Logged Out, Logged In Lite User, etc.).
XPath matching works similarly to the matching presented in mPulse via the Metrics tab and can also be filtered by URL pattern. When this value source is selected, define an Xpath from which to match.
For example, a news site might create a custom dimension called "Market Vertical," which uses XPath to pull the type of news content that the user is currently viewing.
URL matching works similarly to the matching presented in mPulse via the Page Groups tab and can also be filtered by pattern.
For example, an ecommerce site might create a custom dimension called "Product Type" that uses a Regex capture group to pull the product type from a URL, and a replacement value to capture the specific product value, such as hammer.
Query Parameter matching works similarly to the matching presented in mPulse via the Page Groups tab. When this value source is selected, define a query string parameter from which to match. The URL used here must have a query string (e.g., a "?" that precedes the non-hierarchical data that follows).
For example, the Query Parameter value source can be used to pull the value of the common query parameter, referrer.
Cookie matching works similarly to the matching presented in mPulse via the Page Groups tab.
For example, many e-tailers store the marketing campaign value(s) that resulted in a web site hit. Using the Cookie value source to define a custom dimension, we can extract that information from a cookie named details, and then get the campaign name using a replacement value.
User Agent matching works similarly to the matching presented in mPulse via the Page Groups tab.
For example, a physical retailer may have specialty in-store kiosks whose user agents (e.g. browsers) are identified by a kiosk-code such as "kiosk-code:5869:". In such a case, mPulse can capture this user-agent string from their internal site's instrumentation.
© 2015 SOASTA. All Rights Reserved. Privacy & Legal