A rule helps you validate your data by looking for tags, variables, values (such as an individual page name) or by confirming a variable matches a pattern (like a campaign code format). If a rule fails to meet its criteria, it will show up as a failed rule in the Rule Summary report for Audits or on the action where it failed in a Journey. It can also be configured to send an email alert each time it fails. Rules were previously called "compliance rules."

You can find all of the rules in your account by selecting Tag & Variable Rules under Standards in the left-hand navigation.

In the Tag & Variable Rules menu, you will see a list of all of the rules that have been created in your account. You can also see which Audits and Journeys have each rule applied, who created the rule, when it was created, and when it was last modified. On this page, you can filter the entire report by labels or by typing in the Journey name.

Organize your rules with names and labels. While the name of the rule should be descriptive, you can also add labels to help further organize the rules. Labels can have one or more terms separated by spaces. The auto-fill list will show the current labels as soon as you begin typing. Arrow down and press Enter to select from the list. Or, if the label is not already in the list, press Enter or click Create New Label to add it. All labels are forced to be lowercase.

After the rule is saved, you can search by either name or label in the rule list. When searching by multiple labels in the list of rules, the list will filter to only those rules that contain all the labels.

The rule can also be set to validate multiple times on a page or action. This is helpful in such cases where a video event would be expected to fire three times, for example, during a 10 second pause on a page where a video plays. The rule fails if it doesn't meet the rule criteria the exact number of times configured.

A final configuration option on the General tab lets you specify one or more emails to send alerts to whenever the rule fails. This is not commonly used because it is not usually specific enough because it notifies all the recipients regardless of whether they have any interest in the specific Audit or Journey the rule may be applied to. Use this if it is critical that a specific person always knows about the rule failure. Otherwise set up the notification in the specific Audit or Journey and leave this field blank.

Rules contains two similar but very specific parameters, filters and conditions. A filter specifies when a condition should be validated. A condition describes how a tag or variable should be configured on the page.

Rules use IF/THEN logic to determine when a rule should run and the criteria for success. The IF condition controls when the rule should be executed while the THEN condition defines the expected results of the rule. The logic goes like this:

Before the rule can execute you must tell it when to execute. The IF filter may have one or more criteria defined or it can be empty. If empty, the rule will execute on every page of an Audit to which it is applied.

You may choose to have multiple IF filters. Choose All or Any from the dropdown to determine if each or any one of them must pass to activate the rule.

The filter can look for a URL, status code, or tag.

Setting the If condition to fire only when the URL matches a specific criteria restricts the execution of that rule to pages where either an exact URL, a portion of the URL, or a Regular Expression that matches the URL is found. Use the Operator selector to determine if the URL should equal, contain, or match a regular expression in the Value field. For example, to configure the rule to fire only when in the forum directory, set the condition to URL contains /forum/. If the current page URL contains the value, the rule will execute the Then statement. URLs that do not fulfill the condition will ignore the Then statement. This can be applied to Initial and Final URLs. A URL If condition can only be used in Audits.

The If condition can also be configured to recognize a status code that the page returns. Status codes reveal if a page was served (200), wasn't found (404), was redirected (302) or some other state. Most pages that the server returns have a 200 code, meaning the page was served. Capturing a status code would be useful for running the rule only on pages with 400 level codes, for example, to validate that they have the analytics tag on them. This can be applied to Initial and Final URLs. You can use regular expressions to match on multiple status codes. For example, the regular expression 302|404|500 would match on any of the three codes listed.

Setting the If condition to Tag, allows you to select from the hundreds of tags that ObservePoint detects. If that tag is found, then the rule executes. Begin typing the tag name in the Value field to search the list. Let's suppose, for example, the AppNexus tag is implemented on only a subset of your site's pages. A rule set up with an AppNexus tag condition won't execute on each page, only on those pages where it finds AppNexus firing.

Setting the If condition to Tag Status Code, allows you to select from the hundreds of tags that ObservePoint detects and its status code. If that tag is found, then the rule executes. Begin typing the tag name in the Value field to search the list. Let's suppose, for example, the AppNexus tag is implemented on only a subset of your site's pages. A rule set up with an AppNexus tag condition won't execute on each page, only on those pages where it finds AppNexus firing.

The Operator field is context sensitive, depending on the Filter:

Other operators throughout the rule builder include the following:

The Value field can consist of any text or regular expression. Use regex.observepoint.com for reference and to test out regular expressions.

If you choose to filter by tag, you can be more specific by adding an account condition. The option to add Account or Variable conditions will not appear until you choose to filter by a tag. This allows you to execute the rule on any page where a specific tag is collecting data into a specific account or report suite. See "Add Account for the THEN Condition" below for setup instructions.

A variable condition gives you further control by letting you test the value of a variable in the tag before firing the rule. See "Add a Tag Variable" below for setup instructions.

The expected results define which tags, variables and values need to be present to pass the test. Whenever the If filter is met, the Then condition will be executed. The Expectation condition is sometimes also referred to the THEN condition.

The Tag filter defines which tag must be found in order to execute the rule. It can be used by itself to look only for the presence of that tag on the page no matter what account it collects to or what variables it contains. But it can also it can be further narrowed to look for a specific account or report suite or variable value.

If the rule is set up to only look for a specific tag and the tag is missing on a page the rule will fail. In addition, the Tag Type could be configured to look for multiple tags (click the Add Expected Results button), which, if any of the tags were missing, would result in a failure. The Missing Tags report could serve a similar function, except it will not send an alert when pages are found with missing tags.

This lets you define which account or report suite should be collecting the data. Configure this so that one or more accounts are defined. Choose the appropriate operator and enter a value that represents a valid account. The Validation Description lets you type in a note for future reference; it does not affect the rule itself. You can only define the Account Condition if you have already set the Tag Condition.

If the Tag Filter is a Data Layer, you should set the Account as well, especially if you have more than one Data Layer across your Audits or Journeys. The Account name should be the same as the Data Layer name.

The expected result can look for specific variables and values set within the defined tag. This is the most common reason for setting up a rule in the first place. For example the campaign variable ( v0) is available only for Adobe Analytics; likewise, utmdt is specific to Google Analytics. You can set up a Variable Condition to test if the variable has any value at all (is set) or look for a specific value or pattern.

When you add a Variable Condition, enter the variable's name as it is sent in the tag's image request. To discover what that is, open the Variable Summary report, choose the tag and account, and use the variable name that is in parenthesis next to the friendly label. For example, ch is the name for Adobe Analytics Channel variable, el is the name for Google Analytics Event Label variable.

The Variable Summary report shows all the variables for each tag. The term in parentheses is the variable name. If there is no term in parenthesis, use the friendly variable name that is displayed.

A variable name can also be represented with a regular expression when you check the Match as RegEx box under the variable name. This can be useful when trying to create rules to test an array of elements or a single element that is not the first element in an array.

Example #1: A variable name such as ^v[0-9] would allow us to test variables with letter v followed by any number e.g. v1, v3, v9, etc.

Example #2: A variable name of dl.events.[[0-9]].type would allow us to create a rule for any item in a data layer array.

Variable results require an operator such as equals, contains, is set, or regex. If you use is set or is not set , the rule will look to see if the variable has a value of something other than null or empty. If you use >= or <= (greater/less than or equal to), the value must be a number.

The Selector drop-down defines the kind of value the rule should look for. It can look for a string, number, query string parameter, data layer element, or tag variable. A simple configuration might look like the following:

The selectors may be set as follows:

String

A string is any text. Enter the text in the Value field. If you choose >= or <=, the String selector turns into Number.

URL Query String Parameter

The rule will look for whatever you enter in the Value field in the query string of the page. If the parameter is found, the rule will compare its value to the value of the variable.For example, suppose you want to validate the landing pages that populate the Adobe Campaign variable (v0). Assuming the following Initial or Final URL, setting the Value field to cid will look for aff_1234 as the value of the campaign variable:

http://www.mysite.com/landingpage.html?cid=aff_1234

Data Layer

Choosing Data Layer will look for the value of a data layer element and compare it to the value of the item defined in the Variable field. For example, configure a rule to check if a product display page sets the style number of the item in the pv_a10 variable with the following settings:

Tags

It is not uncommon for web page variables to get their values from another variable on the page. To validate in this scenario, choose a tag and set the Value field to the name of a variable that belongs to that tag. For example, use the following settings to confirm that Adobe Analytics eVar1 is the same as the value of prop1:

Multiple Expected Results (optional)

If you add more than one expected result in the same rule, each result must be met for the rule to pass (implicit Boolean AND). If any result is not met, the entire rule fails and the report shows which one failed.

See Applying Rules to Audits and Journeys in Help to learn more about adding rules in Audits and Journeys.

Example 1: You want to validate that the Adobe variable v12 (content group) is set to forum on only the discussion pages. The IF condition tells the rule to look for /forum/ in the URL. The expected result specifies that v12 must be set to forum:

Example 2: Several filters and conditions can be configured within one rule. In this example, eVar8 can be set to either article or post, while prop8 must be set to article only.

Both conditions and results support several match type parameters including regular expressions. RegEx can be used to specify an OR condition, as in the example above ( article|post). But RegEx need not be limited to OR statements, it could be configured to match many types of data. To test regular expressions, use the ObservePoint Regular Expression tester at regex.observepoint.com.