How processing rules work
Last update: Fri Jan 12 2024 00:00:00 GMT+0000 (Coordinated Universal Time)
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 section_EB138775E7C64C74B0D1D3213F7A823C
The following table contains key concepts you need to understand when using processing rules:
Rules apply to a single 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.
Processing rules are applied before VISTA rules and Marketing Channel rules.
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.
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 section_387390EEE9BA4DA98698522A84326DB4
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.
Processing Rule Actions section_E2285C9D008442C7BF136E52A9A4CC06
Actions set page variables, delete page variables, or trigger events. Actions can also concatenate values to display in a report.
For example, you might want to display category:product by concatenating two variables.