Configuring Tag Control Rules in the Portal

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

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

  • protect cookies and form fields 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
  • set up a performance budget to automatically defer specific tags if a specified time is reached

From this screen you can toggle the status of one or more rules between Enabled and Disabled by clicking one or more checkboxes at the left side of each rule and clicking Disable Selected or Enable Selected. You can also click Select All at the top to quickly select all rules to disable or enable.

The current version of Instart Tag 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.

Adding rules

To build a rule, begin by clicking on the pulldown labeled Select a rule type:

The choices are

  • Create custom rule, which allows you to create a rule to protect one or more cookies and/or form fields from being accessed by specific scripts, or delay the loading of specific scripts.
  • Set up alert, which allows you to specify alert conditions for scripts from a specific third-party domain.
  • Create performance budget rule, which allows you to specify a time span that, if exceeded, will cause the service to automatically defer one or more specified tags until after the OnLoad event.
  • Create form field protection rulewhich allows you to create a rule to protect form fields from access by specific scripts.

Once you have made this selection, the steps to build a rule differ slightly depending on the type.

To create a custom rule to control cookie access, protect a form field, 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 Select a rule type and choose Custom rule. This opens up the Identify App section:

    The 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.
  4. 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.
  5. 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 their right.
  6. Next you select which type of control rule you want. Click the pulldown labeled Create a sub-rule:

    The choices available are
    - Control Cookie Access
    - Protect Form Field
    Delay Resource Load

How you continue from here depends on the type of sub-rule that you want.

If you select Control Cookie Access:

  1. A form section appears, allowing you to specify the appropriate criteria, which are predefined in this case:

  2. Specify the cookie by name, specify the URL pattern to match against script paths, 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 specify 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 specify 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 Create a sub-rule pulldown and select Control Cookie Access to open another group of form fields.

If you select Delay Resource Load:

  1. A form section appears, allowing you to specify the appropriate criteria:

    The choices available are
    - Domain
    - Path
    - Query String

    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.


  2. 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.
  3. 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.
    The following example shows Path set to addthis_widget.js and delays its loading until after the DOM Content Loaded event:

    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.

If you select Protect Form Field:

  1. A sub-rule block appears, allowing you to specify the appropriate criteria, which are predefined in this case:
  2. Specify the Resource URL pattern, the Element selector, and choose to control read access, write access, or both.
    The Element selector is the DOM selector that specifies which form field you want to protect. This is typically the ID attribute of the element, but any valid selector that specifies the element will work.
    The simplest way to get add this to the rule is to click the Scan Form Fields button. This will open a modal dialog that lists all the available form fields and their DOM selectors:

    Click the ones you want and click Add, and a corresponding number of Element selector fields will be added to the block.
    Alternatively, you can manually find a form field's selector as follows:

    To determine a form field's selector:
    You can use your browser's developer tools to find the DOM selector that specifies which form field you want to protect. For example, in Chrome, right-click on the field of of interest and select Inspect to quickly open the Developer Tools console with the element selected:

    Then, right click on the element and select Copy > Copy selector from the popup menu:

    Caution

    Note that if your selector is not specific enough, this will cause the Nanovisor to examine all elements that match the selector, which can affect performance. The id attribute is ideal because it is unique.

    The URL pattern specifies the script or scripts you want to prevent from being able to read and/or write the value of this form field.
    For URL pattern, the match condition can be matches any of or does not match any of, and therefore specifies a regular expression.
    For the Element selector, the match conditions can be equals any of or does not equal any of, and therefore specify an exact match for the value or values you enter.
    For this example, the following rule specification will allow only the script processtransaction to read or write the value of the form element with an ID of ccnum:

To complete the rule:

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, Delay Resource Load, or Protect Form Field, you can add additional actions before saving the rule, or by editing the rule after you have saved it. Simply click the Create a sub-rule 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 Select a rule type and choose Set Up Alert. This opens up a Set Up Alert block:

  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.
    (A Create a sub-rule pulldown appears to the bottom of the form field protection block, 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 alert and click Save.

The rule is saved and will appear in the list of rules on the Tag Control Rules page.

To create a form protection rule:

A form field protection rule allows you to protect form fields from access by specific scripts.

Note

You can also protect form fields along with other sub-rules in a custom rule; see above.

  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 Select a rule type and choose Create Form Protection RuleThis opens up an Identify App block and a Protect Form Field sub-ruleblock:

    The match specification in the Identify App block is set to Use criteria, match conditions by default, and a Select Criteria field is shown.
    You could also set the 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.If you are specifying criteria to match, the Criteria pulldown provides the following choices:


    These are the same as described above for defining a Custom rule. 
    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.
  4. In the Protect Form Field block, specify the Resource URL pattern, the Element selector, and choose to control read access, write access, or both:


    The Element selector is the DOM selector that specifies which form field you want to protect. This is typically the ID attribute of the element, but any valid selector that specifies the element will work.
    The simplest way to get add this to the rule is to click the Scan Form Fields button. This will open a modal dialog that lists all the available form fields and their DOM selectors:

    Click the ones you want and click Add, and a corresponding number of Element selector fields will be added to the block.
    Alternatively, you can manually find a form field's selector as follows:

    To determine a form field's selector:
    You can use your browser's developer tools to find the DOM selector that specifies which form field you want to protect. For example, in Chrome, right-click on the field of of interest and select Inspect to quickly open the Developer Tools console with the element selected:

    Then, right click on the element and select Copy > Copy selector from the popup menu:

    Caution

    Note that if your selector is not specific enough, this will cause the Nanovisor to examine all elements that match the selector, which can affect performance. The id attribute is ideal because it is unique.

    The URL pattern specifies the script or scripts you want to prevent from being able to read and/or write the value of this form field.
    For URL pattern, the match condition can be matches any of or does not match any of, and therefore specifies a regular expression.
    For the Element selector, the match conditions can be equals any of or does not equal any of, and therefore specify an exact match for the value or values you enter.
    For this example, the following rule specification will allow only the script processtransaction to read or write the value of the form element with an ID of ccnum:

  5. You can enter additional form field protection rules for other form fields by clicking the Create a sub-rule pulldown and selecting Protect Form Field to add an additional block:
  6. 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 alert and click Save.

The rule is saved and will appear in the list of rules on the Tag Control Rules page.

To create a performance budget rule:

A performance budget rule allows you to specify a time span that, if exceeded, will cause the service to automatically defer one or more specified tags until after the OnLoad event.

  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 Select a rule type and choose Create Performance Budget RuleThis opens up a Identify App block and a Set Performance Budget sub-rule block:

    The match specification in the Identify App block is set to Use criteria, match conditions by default, and a Select Criteria field is shown.
    You could also set the 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.
  4. If you are specifying criteria to match, the Criteria pulldown provides the following choices:

    These are the same as described above for defining a Custom rule, with two additional criteria that apply to performance budget rules only – Percentage of Users and Network Speed.
    Percentage of Users will apply the performance budget rule to a specified percentage of users visiting the page:

    Network Speed will apply the performance budget rule based on the user's detected network speed in kbps: 

    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.
  5. In the Set Performance Budget block, enter a time in milliseconds in the field.
  6. Click the Scan Tags button. This will open a modal dialog that lists all the available tags:

    Click the ones you want and click Add, and a corresponding number of tag fields will be added to the block:

    Alternatively, you can manually enter tag paths.
  7. You can enter additional performance budgets for other tags with different time thresholds by clicking the Create a sub-rule pulldown and selecting Set Performance Budget to add an additional block:
     
  8. 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 alert and click Save.

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: