How processing rules work

Processing rules let you make changes to data based on defined conditions. When attributes or values match defined conditions, values can be set and deleted, and events can be set.

Processing rules are applied to data as it is collected, and rules are applied to all data that comes through the AppMeasurement libraries and through the Data Insertion API. Processing rules also apply to the full and log data sources. These sources contain data that represents a hit or an action that a user takes. Processing rules do not apply to other data sources.

Important Concepts

The following table contains key concepts you need to understand when using processing rules:

Concept	Details
Rules apply to a single report suite.	Copy processing rules to another report suite
Processing rules are applied in the order listed.	If an action changes a value, subsequent conditions use the new value.
Processing rules are applied immediately to the report suite after they are saved.	Changes from processing rules should be visible in your report suite within minutes of saving. When testing processing rules, we recommend configuring real-time reports in your test report suite so you can quickly see the results of a processing rule.
Processing rules are the only way to access to context data variables.	Copy a Context Data Variable to an eVar
Processing rules are applied before VISTA rules and Marketing Channel rules.	Processing Order
Hits cannot be excluded.	You can use VISTA rules to exclude hits.
The product string, referrer, and user agent cannot be changed.	Referrer and user agent are read-only. The product string is not available.
Mobile device attributes and classifications are not available.	The mobile device lookup occurs before processing rules, but attributes are not available in processing rules.
Query string parameters cannot be read beyond the first 255 characters of a URL if you are running JavaScript AppMeasurement H.25.2 or earlier. JavaScript AppMeasurement H.25.3 and later provide the full URL including all query string parameters to processing rules.	Upgrade to H.25.3 or later, or read query string parameters from long URLs client-side and store values in Context Data variables.
Query string values must be encoded in Unicode or UTF-8 to be read by processing rules.	This might affect multibyte characters that are passed using query strings.
You are limited to 150 rules with 30 conditions each for each report suite.	Processing rule limits are per report suite, not per company.
Processing rules must be set up to retrieve context data variables before data is sent.	Processing rules are applied as server calls are sent. Values stored in context data variables are discarded if they are not copied using processing rules.
Value comparisons in the UI are case insensitive.	Cleaning up Values in a Report .
Context data variable names can contain only alphanumeric characters, underscores and dots. Any additional characters are stripped out.	For example, The context data variable `login_page-home` automatically becomes `login_pagehome`. All data sent to the `login_page-home` variable is allocated under `login_pagehome`. Context data variables that contain unsupported characters cannot be added in the Processing Rules interface.
Caret (^) is a special character in the processing rules system.	To match a single caret character, use two caret characters (^^).

Processing Rule Conditions

Conditions check page variables for a matching value or if a value is present. Multiple conditions can be added and you can select if all conditions must be matched.

You can create a rule with no conditions to always execute defined actions.

Variables are not automatically checked for values before actions occur. For example, Prop1 contains a value of “something”, and eVar1 is empty. If you set Prop1 to equal eVar1 both values will be empty. If you need to avoid this add a condition to check for the presence of a value.