Install the client library

Using our CDN

Add this snippet to your markup, before the closing tag:

<script type="text/javascript">
    h&&h(b,c,d,f,g),g||(g=new Error(b)),a[e].q=a[e].q||[],a[e].q.push({

Or manually

Download the production script (minified), the development script (full source) or see here for installing with Bower, NPM or NuGet.


Add the following lines to your JS site code and paste in your API key (from Raygun), to set up the provider to automatically send session data to your Raygun account:

<script type="text/javascript">
  rg4js('apiKey', 'paste_your_api_key_here');
  rg4js('enablePulse', true);

Add user data

Set up the library to transmit data for the currently logged-in user:

rg4js('setUser', {
  identifier: '',
  isAnonymous: false,
  email: '',
  firstName: 'Firstname',
  fullName: 'Firstname Lastname'

You can then browse to pages on your site, and data will be transmitted and appear in your Real User Monitoring dashboard.

Single Page Applications

Real User Monitoring also supports SPAs built with client-side technologies like Angular, Ember, Backbone etc. You can track SPA view change events through the trackEvent function:

Raygun.trackEvent('pageView', { path: '/' + foo });

When a route or view change is triggered in your SPA, this function should be called with pageView as the first parameter and an object with a path key set to a path representing the new view or route. Real User Monitoring will collect up all timing information that is available and send it to the dashboard. These are then viewable as ‘virtual pages’.

The following are a couple of configuration examples that you can use or adapt for your client-side view library/framework. Naturally, if you are using a more full-featured routing system, you should trigger a pageView inside there when the route changes.


$(window).hashchange(function() {
  Raygun.trackEvent('pageView', {
    path: '/' + location.hash

AngularJS['$rootScope', '$window', '$location', trackPageView]);

function trackPageView($rootScope, $window, $location){
  // watch for successful state transitions
  $rootScope.$on('$locationChangeSuccess', function (event, current) {
    $window.Raygun.trackEvent('pageView', {
      path: $location.url()

Default behavior

Real User Monitoring receives URL paths for each page that your users visit on your site. Due to the common use of REST routes or other schemes, duplicate Pages would be created by default for the same view. Using a common forums web application example, the and otherwise show up as two Pages inside Real User Monitoring, when really they are two instances of the same Thread view.

By default, Real User Monitoring replaces both integer path segments and DateTime strings with the wildcard character *. Thus, the above two page views would be bucketed beneath the single Page*.

You can add new rules on the Real User Monitoring > Settings page:

Screenshot showing the Real User Monitoring Settings item in the Raygun application sidebar menu.

Any new or deleted rules are saved whenever you click ‘Add URL’ or the delete button beside a rule.

Any changes to the two rule lists documented below may take up to 15 minutes to be reflected by new pages in the Real User Monitoring dashboard.

Grouping URLs

Screenshot of the Real User Monitoring settings interface for grouping URLs.

This allows you to add your own path segment wildcards for your routing scheme, if you have non-integer segments that can change for the same view. For instance, if you add a new row to the Grouping URL rule list containing this:*

Page visits for the routes and will show up beneath the same Page in Real User Monitoring.

These can be made more specific. This grouping rule:*/delete

will turn pages visit to /forum/foo/delete and /forum/bar/delete into /forum/*/delete.

Ungrouping URLs

Screenshot of the Real User Monitoring settings interface for ungrouping URLs.

Single URLs

If you want routes containing integer path segments to appear un-wildcarded, you can disable the default integer wildcarding by adding to the Ungrouping rule list on the Real User Monitoring Settings page. For instance:

Visits to the above two routes would show up as two Pages inside Real User Monitoring, while a visit to would show up under /thread/*.

All URLs

If you want to mass-ungroup segments all URLs that match a rule, you can do so by have an ungrouping rule with a wildcard character:*

All pages such as /thread/1, /thread/2 etc. will appear as their own pages in Real User Monitoring.


Subdomains can also be grouped or ungrouped in the same way as the segments above. If you have multiple domains that each serve the same pages, you can set these up to be (un)grouped using rules such as:



The protocol and domain is optional

Don’t care about matching by the protocol/domain that your pages have? You can also add rules with just the path, e.g:


Mixing ungrouping with grouping

You can have ungrouping rules coexist alongside grouping rules. Ungrouping rules take precedence over (AKA override) grouping rules. For instance, this ungrouping rule:


Combined with this grouping rule:


Will cause the following two pages:

To appear in Real User Monitoring as this one page:*