Tag Analytics & Control – Usage Guide

Overview

In recent years the use of 3rd-party tags and services has become widespread. For example, Google Analytics has become near-ubiquitous as a way to track website traffic; instrumenting websites to track performance with tools like New Relic is a common practice; and many eCommerce sites rely on third-party services to add sophisticated features such as personalization, user comments and reviews to approach the high bar set by Amazon without needing to reinvent the wheel.

These tags add critical functionality to websites and digital applications. However, with more tags constantly being added and changed, often by different departments, with little or no regard to how they load, execute, and interact in your users' browsers, it becomes difficult for digital operations teams to ensure amazing user experience, protect application reliability and performance, keep customers secure, and debug problems when they occur.

Instart Tag Analytics & Control gives you visibility and control over 3rd-party tags that executes in the user’s web browser, regardless of who added them to your application, enabling you to see and understand the impact and behavior of all tags in one place. It allows you to create policies that manage their impact on performance, reliability, and security. Problematic tags can be deferred or stopped, while simultaneously alerting your team. The key to this capability is Instart's Nanovisor technology, a lightweight JavaScript injected into pages that provides client-side control not possible otherwise.

A rich set of analytics screens provides detailed information about 3rd-party resources on your site.

This document describes using the Instart web portal to view tag analytics and create and manage rules to control loading of resources in the browser, protect cookies from being read and/or written by other scripts, and send email alerts if, for example, a script starts taking longer than a specified, or similar performance issues.

The Tag Analytics & Control screens are accessed from the left navigation panel of the portal:

Quick start example

In this example we will focus on a specific page of the Instart public website – the company page – that we've noticed seems to load somewhat more slowly than we'd like. We use the portal to look at some of the tag analysis screens and see if we can see anything to explain it.

We open the Domain Analysis screen and scroll down to the Domain Level Activity data:

Hmmm.... the fourth line shows something that is taking an inordinate time to load, so nothing aside from some code from instartlogic.com, Blue Triangle, and Google loads until after it's done. We switch to the Object Level Detail - Graph view:

The addthis_widget.js is taking almost 500 msec to load. Maybe if we could load it after Avg Time to DOM Content Loaded (the blue vertical line in the waterfall), which appears to be averaging around 2500 msecs, the page performance would improve.

So we switch to the Rules screen to create a rule to defer the loading of this tag:

First, let's enter a description for the rule (a description is required):

We begin by clicking on the pulldown labeled What do you want to do? The choices are Identify App, which is the first step towards creating a rule to either protect a cookie from access by specific scripts, or delay loading of specific resources, or Set Up Alert, which allows you to specify alert conditions for resources from a specific 3rd-party domain. For our current purpose we choose Identify App. This opens up the Identify App section and moves the What do you want to do? pulldown down in the page:

To create our rule, we next need to set some criteria to specify the app we intend to set up our rule for. We look at the Criteria pulldown to see what our choices are:

We choose Path and then specify the path of the page we noticed the slowness with:

Now we click on the pulldown labeled What do you want to do?

We choose Delay Resource LoadThis opens up the Delay Resource Load section and again moves the What do you want to do? pulldown down in the page:

FIrst, we need to select something to specify the tag we want to defer. We know its name, so we choose Path and enter addthis_widget.js in the Path field:

OK, we've specified the affected app and the script we want to defer… next we need to specify which event to defer the loading of this script until. In this case we're going to have it load after the DOM Content Loaded event:

Then we click Save at the bottom of the rule. A Change Reason dialog box appears, so we add a note about the purpose of this rule:

We fill in a note about why we are creating this rule and click Submit.

Now that our rule has been created, it takes about 5-10 minutes to be validated and deployed. After it's been in play for a while and had a chance to be triggered, information about the rule's action will become visible in the Action Analytics screen. This should happen after about 15-20 minutes have passed. We can then take another look at the company page and see if it appears to load faster.

Inventory 

The Inventory screen shows a list of tags present in the current property. You can present and organize the list in a number of ways – as a list of the Domains the tags are called from, or a list of source Files; these can be grouped by Site, Page, or Environment.

Shading in the Page views indicate when the domain or file was loaded relative to a few key DOM events:

  • shaded pink: loaded before Time to DOM Interactive
  • shaded gray: loaded between Time to DOM Interactive and Time to DOM Content Loaded
  • shaded blue: loaded between Time to DOM Content Loaded and Onload
  • no shading: loaded after Onload

Here's the Domains by Site view of the Inventory screen:

Here's the Domains by Page view:

Here's the Files by Site view:

Here's the Files by Page view (scrolled to show shading):

By default the list appears in ascending order of start time. You can sort it to appear in ascending or descending order of any of the three columns by clicking the corresponding up/down arrow icon.

You can narrow down the list by typing in the search boxes above each column. For example, typing "ab" atop the Domain column reduces the list to only those domains that have that substring present in their names; typing "< 100" atop the Avg. Duration column reduces the list to only items that loaded in less that 100 ms. These searches can be used together – for example, the following reduces the list from 147 results to just one:

0

By default the lists are set up to display 50 lines per page, and left and right pagination buttons are provided to move around in the full list. This is configurable; you can click in the number/page selector and choose to display 5, 10, 25, 50, or 100 lines per page, or All to show the entire list on a single page:


You can apply filters to each screen to limit the amount of data displayed. Filters can be set by clicking the filter icon on the right above the list. Some of these are required, such as Data type and Page Name. The available filters also differ depending on whether Data Type is set to Synthetic or Real User.

A complete list of available filters can be found in the Appendix.

Domain Analysis

The Domain Analysis screen collects a number of detailed metrics about the property. It shows 7 days of data back from a date you select in the Filters pane.

You can apply filters to each screen to limit the amount of data displayed. Filters can be set by clicking the filter icon on the right above the list. Some of these are required, such as Data type and Page Name. The available filters also differ depending on whether Data Type is set to Synthetic or Real User.

A complete list of available filters can be found in the Appendix.

Performance Details

Starting at the top is the Performance Details graph. This can be viewed either with all measurements or with only resource timings collected by clicking the tab along the top of the graph.

The graph plots the following metrics, indicated by different colors and line types:

Graph traceDescription
Page ViewsA page view is an instance of a page being loaded or reloaded in a browser. Page views is a metric defined as the total number of pages viewed.
OnloadThe average time until an object has been loaded (the Onload event)
1stByteThe average time between when the user or client made an HTTP request and the first byte of the page being received by the requesting browser.
DNSThe average time it took to receive the results from a DNS lookup, from the Resource Timing API in the users' browsers.
TCPConThe average time to establish the TCP connection to the server, from the Resource Timing API in the users' browsers.
DOM DurationThe average time for the browser to download a page's HTML and finish constructing the document object model (DOM) after the page is requested so that the domComplete event is triggered. Visually, this event occurs when the loading spinner stops spinning, which affects user perception of page speed. DOM Duration is measured as the time elapsed between the DOM Loading and DOM Complete events (DOM Duration = domComplete - domLoading). It occurs during the processing of the page. See W3C Navigation Timing for further information.
SSLWhen TLS or SSL are in use, the average time between when the handshake begins for securing the connection and when the connection to the server is complete, from the Resource Timing API in the users' browsers.
RedirectThe average time it took to redirect, if the page was redirected; from the Resource Timing API in the users' browsers.
Base PageThe average time the page takes to fetch the HTML file. This is calculated in the browser as the time elapsed between Response Start and Response End (Base Page = responseEnd - responseStart). See W3C Navigation Timing for more information.
Time to DOM InteractiveThe average time until the DOM could be interacted with by user. Specifically this is defined as the point where the page has displayed useful content, event handlers are registered for most visible page elements, and the page responds to user interactions within 50 milliseconds.
Time to DOM Content LoadedThe average time until the DOMContentLoaded event was fired, which is when the initial HTML document has been completely loaded and parsed, without waiting for stylesheets, images, and subframes to finish loading.
30 Day Avg OnloadThe 30-day average of the time until the Onload event occured
30 Day Avg DOM DurationThe 30-day average of the time until the DOM is constructed
30 Day Avg Time To DOM InteractiveThe 30-day average of the time until the DOM could be interacted with by users

Hovering over the plot will cause a summary data box to appear at the time points along the graph. For example:

For RUM data (DNS, TCPCon, , some browsers don't support the JavaScript resource timing API, so the second tab allows you to view the data allows you to filter out those that don't have that data reported.

You can click on the metric labels below the graph to gray them out, removing its trace in the display. For example, here's a graph showing only the average time until the Onload event:

Clicking on them returns them to the display.

Average Load Time By Domain

Next is the Average Load Time By Domain table:

This displays a list of third-party domains and the average daily load time for each over the selected seven-day period, plus the average load time over the last month, a 30-day average of the percentage of elements, and a 30-day average of elements per page.

By default the table is set up to display 25 lines per "page," and left and right pagination buttons are provided to move around in the full list. This is configurable; you can click on the number/page selector and choose to display 5, 10, 25, 50, or 100 lines per page, or All to show the entire list on a single page.


By default the list appears in ascending order of the 30-day average percentage of elements. You can sort it to appear in ascending or descending order of any of the other columns by clicking the corresponding up/down arrow icon.

You can narrow down the list by typing in the search boxes above each column. For example, typing "ad" atop the Domain column reduces the list to only those domains that have that substring present in their names; typing "< .09" atop the 30-Day Average column reduces the list to only items that loaded in less that 90 ms. These searches can be used together – for example, the following reduces the list from 28 results to just 3:

You can export the data in this table to CSV, TSV, JSON format, or as an array. Click Export on the upper left side of the table and select the desired format from the menu.

Domain Level Activity

Next comes Domain Level Activity. There are four possible views:

Domain Level Detail as a graph

This displays a waterfall for all the third-party domains in the selected page.

Hovering the mouse cursor over any portion of the waterfall will display details:

Domain Level Detail as a table

This displays the same data but in tabular form.

If you click on a small image icon in the first column, a graph of domain timings over the last seven days is generated:

You can click on the metric labels below the graph to gray them out, removing its trace in the display. For example, here's a graph showing only the average page load time:

Clicking on them returns them to the display.

By default the table is set up to display 25 lines per "page," and left and right pagination buttons are provided to move around in the full list. This is configurable; you can click on the number/page selector and choose to display 5, 10, 25, 50, or 100 lines per page, or All to show the entire list on a single page.


By default the list appears in ascending order of the count in the leftmost column. You can sort it to appear in ascending or descending order of any of the other columns by clicking the corresponding up/down arrow icon.

You can narrow down the list by typing in the search boxes above each column. For example, typing ".add" atop the Domain column reduces the list to only those domains that have that substring present in their names; typing "> .5" atop the Domain Activity column reduces the list to only items that loaded in more than 500 ms. These searches can be used together – for example, the following reduces the list from 47 results to just 2:

You can export the data in this table to CSV, TSV, JSON format, or as an array. Click Export on the upper left side of the table and select the desired format from the menu.

Object Level Detail as a graph

This displays a waterfall for all the third-party objects in the selected page.

Hovering the mouse cursor over any portion of the waterfall will display details:

Object Level Detail as a table

This displays the same data but in tabular form.

If you click on a small image icon in the first column, a graph of domain timings over the last seven days is generated:

You can click on the metric labels below the graph to gray them out, removing its trace in the display. For example, here's a graph showing only the Total Duration time:

Clicking on them returns them to the display.

By default the table is set up to display 25 lines per "page," and left and right pagination buttons are provided to move around in the full list. This is configurable; you can click on the number/page selector and choose to display 5, 10, 25, 50, or 100 lines per page, or All to show the entire list on a single page.

By default the list appears in ascending order of the count in the leftmost column. You can sort it to appear in ascending or descending order of any of the other columns by clicking the corresponding up/down arrow icon.

By default the list appears in ascending order of the 30-day average percentage of elements. You can sort it to appear in ascending or descending order of any of the other columns by clicking the corresponding up/down arrow icon.

You can narrow down the list by typing in the search boxes above each column. For example, typing ".css" atop the Files column reduces the list to only those domains that have that substring present in their names; typing "< .09" atop the Duration column reduces the list to only items that loaded in less that 90 ms. These searches can be used together – for example, the following reduces the list from 112 results to just 2:

You can export the data in this table to CSV, TSV, JSON format, or as an array. Click Export on the upper left side of the table and select the desired format from the menu.

Resource Timings By File

Finally there is Resource Timings By File:

The information provided is described below:

ColumnDescription
DomainRepresents an IP resource, usually understood as the name and address of a website.
FileThe name of the file loaded by a domain on the site.
Element CountThe number of times an element was loaded within the filter parameters and the selected time period.
DurationThe average time all objects in a domain or individual objects spend loading. Within a domain, this does not include time between files firing. See W3C Resource Timing for more information.
Redirect(s)The time elapsed between Redirect Start and Redirect End in the browser timings. This elapsed time is is added into the calculation for First Byte time in the event of a redirect.
App Cache(s)The amount of time it takes for a page to retrieve information from the application cache. Caching allows local storage and retrieval of information for loading a page. In the browser, the App Cache time is defined as the time elapsed between Fetch Start and Domain Lookup Start (App Cache = domainLookupStart - fetchStart). If there is no caching, Fetch Start and Domain Lookup Start occur simultaneously.
DNS(s)The Time Required to look up the domain name in the DNS system. (Domain Lookup End - Domain Lookup Start)
Request(s)The time spent issuing the network request for a page load or a page resource load. In the browser, this is the time elapsed between Request Start and Response Start (Request = responseStart - requestStart). Also see First Byte for a page load.

By default the table is set up to display 25 lines per "page," and left and right pagination buttons are provided to move around in the full list. This is configurable; you can click on the number/page selector and choose to display 5, 10, 25, 50, or 100 lines per page, or All to show the entire list on a single page.

Domain Details

This screen displays some summary details about domains.

At the top appears a Resource timing over time graph; by default it is populated with the aggregate timings for the currently selected domain.

As with the graphs in the Domain Analysis screens, you can click on the metric labels below the graph to gray them out, removing their trace in the display. Clicking on them returns them to the display.

You can view resource timings for individual resources by selecting a specific resource in the table below:

You can apply filters to each screen to limit the amount of data displayed. Filters can be set by clicking the filter icon on the right above the list. Some of these are required, such as Data type and Page Name. The available filters also differ depending on whether Data Type is set to Synthetic or Real User.

A complete list of available filters can be found in the Appendix.

Rules

The Rules screen is where you can build rules to deal with tag issues. You can

  • protect cookies from being accessed by other third-party tags
  • point to specific tags and defer their load sequence to a later time, or block them from being loaded at all.
  • set up alerts to notify you if a tag is exceeding a time threshold

Note

This first version of Tag Analytics & Control only allows control over dynamic tags – that is, tags that are launched by other JavaScript. For example, tag managers insert JavaScript that will launch many of the tags on the page in runtime in the browser. Static tags, which are defined directly in the HTML code (either with references to source files or actual lines of code) are not supported..

To build a rule, the basic process is:

  1. Identify the web app/page that you want the rule to be in place on, and optionally some client-end filters such as browser type.
  2. Specify what action you intend to take when a request matches the app criteria:
    • control access to one or more cookies
    • delay loading of a resource until after a browser event (such as Page Load)
    • set up an alert
  3. Selecting the action sets what choices you have for specifying the resource the rule will act on; for example, choosing to control access to a cookie allows you to specify the cookie by name, or choosing to delay the loading of a resource allows you to specify the domain or path of the resource.
  4. Optionally add additional actions for the rule to take (for example, you may want to protect a cookie and defer the loading of a resource in the same rule).

Adding rules

To build a rule, begin by clicking on the pulldown labeled What do you want to do?

The choices are

  • Identify App, which is the first step towards creating a rule to either protect a cookie from access by specific scripts, or delay loading of specific resources
  • Set Up Alert, which allows you to specify alert conditions for resources from a specific 3rd-party domain.

Once you have made your selection, the steps differ slightly depending on your choice.

To create a rule for your web app to control cookie access or delay loading a resource:

  1. From the Rules page, click Add a new rule to open the rule builder.
  2. Enter a Description (required) and one or more optional Labels if desired.
  3. Click the pulldown labeled What do you want to do? and choose Identify App. This opens up the Identify App section and moves the What do you want to do? pulldown down in the page:
  4. Match specification is set to Use criteria, match conditions by default, and a Criteria field is shown.
    You could also set Match specification to No criteria - always match, which means the rule will be applied to any request; in this case the Criteria selector below it disappears.
  5. If you are specifying criteria to match, the Criteria pulldown provides the following choices:

    These are in two groups, those that pertain to the App (the server side) and those that pertain to the Client (the browser).
    Selecting any of these criteria opens up a Match condition field and a field to specify one or more values. Depending on the criteria, some of these are text fields that accept strings, and some are pulldowns that allow you to select from a specific list of values.
    If Domain or Path is selected, the match condition can be equals any of, does not equal any of, matches any of, or does not match any of. The former two specify an exact match for the value or values you enter, while the latter two can be a regular expression. (See below for more on regular expressions, also called regexes.)
    For example:


    If Query String is selected, the match condition can be matches any of or does not match any of. Standard ECMAScript-flavor regexes are supported. For example, the following Query String criterion will match if a request's query string contains a specific combination of letters followed by an arbitrary six-digit number:


    A good reference on ECMAScript-flavor regexes can be found on the Mozilla Developer Network site. Regularexpressions101.com is a useful tool that can be used to test expressions and provides a quick syntax reference.
    Conditions that depend on the requesting client can be:
    - Browser name (Chrome, Internet Explorer, Edge, Safari or Firefox)
    - Device (Mobile, Tablet, or Desktop)
    - Country (from pulldown list)
    The match condition for these three criteria can be equals any of or does not equal any of, and therefore specify an exact match for the value or values you enter.
  6. Once you have selected a criterion, you can add additional ones by clicking the plus sign icon to the right of the value field. Note that the selections available no longer include the one you already specified:

    You can also remove criterion by clicking on the x icon to the right.
  7. Next you select which type of control rule you want. Click the pulldown labeled What do you want to do?

    The choices available are
    - Control Cookie Access
    - Delay Resource Load
    If you select Control Cookie Access:
    a form section appears, allowing you to specify the appropriate criteria, which are predefined in this case:

    Specify the cookie by name, specify the URL pattern, and choose to control read access, write access, or both.
    For Cookie Name, the match conditions can be equals any of or does not equal any of, and therefore specifies an exact match for the value or values you enter.
    For URL pattern, the match condition can be matches any of or does not match any of, and therefore specifies a regular expression.
    For example, consider that you have a cookie named session that you wish to protect from anything other than your own scripts. The following rule specification will do this:

    If you have additional cookies you want to create rules for, click the What do you want to do? pulldown and select Control Cookie Access to open another group of form fields.
    If you select Delay Resource Load, a form section appears, allowing you to specify the appropriate criteria:

    The choices available are
    - Domain
    - Path
    - Query String

    Note

    Note that these fields here specify the resource that you want to delay, whereas the fields with the same name you selected under Identify App specify the location in your web application of the request and/or the properties of the requesting browser.

    If Domain or Path is selected, the match condition can be equals any of, does not equal any of, matches any of, or does not match any of. These specify an exact match for the value or values you enter, while the latter two can be a regular expression.
    If Query String is selected, the match condition can be matches any of or does not match any of. Standard ECMAScript-flavor regexes are supported.
    As noted earlier, you are able to add additional criteria by clicking the plus sign icon to the right of the value field. Note that the selections available no longer include the one you already specified.
    Next, select the Event that you want to have the specified resource load after. The choices are
    - Page Loaded – when the webpage and its dependent resources have finished loading.
    - DOM Content Loaded – when the initial HTML document has been completely loaded and parsed, without waiting for stylesheets, images, and subframes to finish loading.
    - Never Load – do not load the script at all.

  8. When you have finished defining your rule, click Save at the bottom of the rule. A Change Reason box appears:

    Fill in a note about why you are creating this rule and click
    Submit.
    The rule is saved and will appear in the list of rules on the Tag Control Rules page.

To create a rule for your web app to perform multiple actions:

After you have selected either to either Control Cookie Access or Delay Resource Load, you can add additional actions before saving the rule, or by editing the rule after you have saved it. Simply click the What do you want to do? pulldown at the bottom again to open another block of either type and define it as described above.

To create a rule to send alerts:

  1. From the Rules page, click Add a new rule to open the rule builder.
  2. Enter a Description (required) and one or more optional Labels if desired.
  3. Click the pulldown labeled What do you want to do? and choose Set Up Alert. This opens up the Set Up Alert section and moves the What do you want to do? pulldown down in the page:
  4. Specify
    - the Root domain of the tag(s) you want to alert on; currently this is the only way to specify the scope of what you want to set up the alert for.
    - a Threshold in milliseconds – the number of milliseconds above which you consider the resource is taking too long to load.
    - an Aggregate percentile – what percentage of requests this threshold is exceeded for, from a pulldown offering values 50th, 90th, 95th, and 99th.
    - a Duration window – how long you want the system to wait while the threshold and percentile remain in this state before an alert is sent, from a pulldown offering values 10m, 15m, 30m, 60m, 90m, or 120m).
    - the Alert notification email list: enter one of more email addresses to which the alert is to be sent when triggered.
    (The What do you want to do? pulldown moves to the bottom of the form field section but there is nothing you can select from it.)
  5. When you have finished defining your alerting rule, click Save at the bottom of the rule. A Change Reason box appears:

    Fill in a note about why you are creating this rule and click
    Submit.
    The rule is saved and will appear in the list of rules on the Tag Control Rules page.

Editing and deleting rules

Rules can be edited at any time.

To edit an existing rule:

  1. From the rule list page, click the rule you want to change. This opens the Edit Tag Control Rule screen:
  2. You can
    -modify existing criteria and actions
    -add additional criteria and/or actions
    -delete criteria and/or actions
  3. When finished, click Save.

To delete an existing rule:

To delete an existing rule, open it for editing from the rule list page and click Delete at the bottom.

Reordering rules

The order of rules matters – any rule that defines criteria that trigger a rule set higher up in the list takes precedence will be the one whose action is taken.

You can reorder the rules by clicking Reorder Rules and then dragging and dropping rules up or down in the list:


Action Analytics

The Action Analytics screen displays information about requests that matched rule conditions and had the rule actions applied.

At the top below the time filter is a graph showing the number of times rule actions were triggered.

You can select how to list the action events by selecting from the Group by pulldown. The choices are:

  • App
    • Page Domain
    • Resource Domain
    • Page Event
  • Client
    • Country
    • Browser
    • Device

You can select which of two types of events to show from the Action type pulldown:

  • Control Cookie Access
  • Delay Resource Load

You can further narrow down the list of events by applying Additional filters and specifying criteria and values for them. For example, you could filter on Domain set equal to images.acme.net and click Apply, and only those events that were applied to images.acme.net would be displayed.

Appendix 

Inventory screen filters 

FilterRequired?DescriptionValid values
Data TypeYesData Type allows you to choose either Synthetic or RUM data. RUM data will give insights into real experience on your site. Synthetic measurements yield more consistent measurement values, making this data particularly useful in scatter plots to reduce noise. Bullet list Choose from pulldown: Synthetic or Real User
Time PeriodYes

The span of time to show data from.

Choose from list:
  • Last 3 Hours
  • Last 6 Hours
  • Last 24 Hours
  • Last 3 Days
  • Last 7 Days
  • Last 14 Days
  • Last 30 Days
  • Yesterday
  • Today
  • This Month
  • Last Month
  • Custom Range

If you choose Custom Range, you can select from the calendar widget to the right.

TimezoneYesThe timezone for the selected time spanSelect from pulldown

Datacenter location

NoWhere a user's site experience was served from. Contact your Blue Triangle representative to set up a datacenter location.
Page nameYesThe name of a specific page of a website.Select from pulldown
CountryNoSpecifies where site traffic from real users originates by country. Changing the country does not change the timezone used for reporting.Select from pulldown
Number of objectsYesResources on a page. As a filter, this limits the number of objects displayed in graphs and tables.

Select from pulldown:

  • 150
  • 200
  • 250
  • 300
  • 350
  • 400
  • 500
  • 600\
  • 700
  • 800
  • 900
  • 1000
Sort byYesChanges which objects are displayed in a waterfall chart based on the number of files an object contains or by the amount of time the object takes to load.

Select from pulldown:

  • File count
  • Slowest load time
Minimum sample sizeYesLimits the results in Object Level Detail to objects with a file count above this number. This filter is most useful when sorting the waterfall in Object Level Detail by slowest load time rather than by file count to filter out objects with a low number of hits.

Enter any integer; defaults to 100

Domain Analysis screen filters

FilterRequired?DescriptionValid values
Data TypeYesData Type allows you to choose either Synthetic or RUM data. RUM data will give insights into real experience on your site. Synthetic measurements yield more consistent measurement values, making this data particularly useful in scatter plots to reduce noise. Bullet list Choose from pulldown: Synthetic or Real User
Lookback 7 Days FromYesThe date from which to count back the last 7 days of data.Select from calendar widget
Baseline Period for ComparisonYes

Select from pulldown:

  • 7
  • 14
  • 21
  • 28
  • 30
  • 60
  • 90
TimezoneYesThe time zone for the selected time spanSelect from pulldown
Traffic Source/ReferrerNoSelecting a referrer only allows measurements from users that came from a particular source, such as a search engine, other website, or a direct navigation.
Datacenter LocationNo

Where a user's site experience was served from. Contact your Blue Triangle representative to set up a datacenter location.


Page NameYesThe name of a specific page of the website.Select from pulldown
Common Devices,
Common Operating Systems, and
Common Browsers
NoFilters to show specific devices, operating systems, and browsers.

Click on an icon to select it.

You can also click Select All Common to choose all common client attributes, and Deselect All to clear all selections.

Browser/OS/
Browser Version
NoAllows you to further refine the data displayed to specific OS and browser versionsSelect from pulldown; available selections depend on versions that actually appear in the last 7 days' data.
Bot TrafficNoAllows you to toggle Blue Triangle's bot filtering.

Select the desired radio button:

  • Include Bots will include data Blue Triangle has flagged as bot traffic.
  • Exclude Bots is the default setting, and keeps bot traffic from skewing real-user metrics.
  • Bots Only shows only bot traffic, which can be useful as a diagnostic tool.
CountryNoSpecifies where site traffic from real users originates by country. Changing the country does not change the timezone used for reporting.Select from pulldown; available selections depend on versions that actually appear in the last 7 days' data.
Number of objectsYesResources on a page. As a filter, this limits the number of objects displayed in graphs and tables.

Select from pulldown:

  • 150
  • 200
  • 250
  • 300
  • 350
  • 400
  • 500
  • 600
  • 700
  • 800
  • 900
  • 1000
Sort byYesChanges which objects are displayed in a waterfall chart based on the number of files an object contains or by the amount of time the object takes to load.

Select from pulldown:

  • File count
  • Slowest load time
Minimum sample sizeYesLimits the results in Object Level Detail to objects with a file count above this number. This filter is most useful when sorting the waterfall in Object Level Detail by slowest load time rather than by file count to filter out objects with a low number of hits.Enter any integer; defaults to 100

Domain Details filters

FilterRequired?DescriptionValid values
Data TypeYesData Type allows you to choose either Synthetic or RUM data. RUM data will give insights into real experience on your site. Synthetic measurements yield more consistent measurement values, making this data particularly useful in scatter plots to reduce noise.

Choose from pulldown:

  • Synthetic
  • Real User
  • API/Base Page & SSL
Time PeriodYesThe span of time to show data from.

Choose from list:

  • Last 3 Hours
  • Last 6 Hours
  • Last 24 Hours
  • Last 3 Days
  • Last 7 Days
  • Last 14 Days
  • Last 30 Days
  • Yesterday
  • Today
  • This Month
  • Last Month
  • Custom Range

If you choose Custom Range, you can select from the calendar widget to the right.

TimezoneYesThe timezone for the selected time spanSelect from pulldown