This article covers the features and functions of Optimize's Rules To Identify (RTI). You will learn how to develop a strategy to set up the Rules To Identify (RTI) for new channels or modify existing channels in your program.
There is no one catch-all solution that can fit all circumstances. However, you should be able to arrive at a solution that best fits your unique circumstances. Arguments against a certain RTI's setup can always exist, but the purpose of an RTI isn't to work in all circumstances. An RTI is meant to be molded to best fit your specific circumstances.
This document will advance the foundational and functional knowledge needed to design the optimal Rules To Identify for your program.
Keep channel setups focused: Remember that Optimize is about surfacing channel-level insights; when creating your RTI, you must consider how to identify the traffic coming from a particular channel. Keeping this in mind will help keep your RTI simple, focused, and effective.
A quick reminder
A Rule Target is "where" the rule will look to apply Rule Logic and find Rule Value(s).
Rule Logic is "how" the Rule will attempt to identify traffic.
Rule Values are input you provide to the rule for leverage.
When designing your RTI, key concepts to keep in mind are precision and reliability. Choices for the Rule Target and Rule Logic option in a Rule should not be viewed as interchangeable, even if more than one set of components will work for a given scenario. See the following sections for examples of this.
Rule Targets can be evaluated for precision and reliability. The following chart plots the various Rule targets in terms of their respective precision and reliability. The farther away from the graph's origin a Rule Target is, the more precise (along the x-axis) and more reliable (along the y-axis) a Rule Target is.
You should always try to use the most reliable and precise Rule Target you can, and only move left or down the graph if you have no other option. Below are two example cases for how to pick which Rule Target to use.
In this scenario, all paid search traffic is tagged with Google's UTM parameter utm_medium=search. Because of this, the Landing Page Parameter should be the Rule Target. The Rule To Identify will begin to look like this:
Rule Target | Rule Value 1 | Rule Logic | Rule Value 2 |
Landing Page URL |
| * | * |
View the Rule Logic - Example 1 section to see what to fill in for the Rule Logic and Rule Value 2.
The next channel, Organic Search, will have no UTM parameters and the landing page is unpredictable. These conditions rule out all Rule Targets that target Parameters and Query Strings as well as all Landing Page Rule Targets. You can see be the graph above that the best option considering all of these factors then is the Referring Domain. The Rule To Identify will begin to look like this:
Rule Target | Rule Value 1 | Rule Logic | Rule Value 2 |
Referring Domain |
| * | * |
View the Rule Logic - Example 2 section to see what to fill in for the Rule Logic and Rule Value 2.
Rule Logic can only be evaluated for precision. The following chart plots the various Rule Logic options in terms of their relative precision.
You should always try to use the most precise Rule Logic option you can, and only move down the graph if you have no other option. Below are two example cases for how to pick which Rule Logic option to use.
Since all paid search is tagged with Google's UTM parameter utm_medium=search, the best possible Rule Logic option would be Exactly Matches.
Rule Target | Rule Value 1 | Rule Logic | Rule Value 2 |
Landing Page URL |
| Exactly Matches |
|
Exactly Matches works best here because only traffic with the exact parameter key-value pair of utm_medium=search should considered part of this channel.
If, for example, the Rule Logic option Contains were used instead, any utm_medium value with search in it would be considered part of this channel, which can lead to mis-attributed actions, make-goods, and potentially more. Contains would not, however, be a wrong choice here; Exactly Matches just happens to be the better choice.
With the Referring Domain Rule Target being established as the best choice earlier, a potential Rule Logic option could be the following:
Rule Target | Rule Value 1 | Rule Logic | Rule Value 2 |
Referring Domain |
| Contains | .bing. |
Contains is a good choice here because Bing's organic search can stem from multiple different referring URLs, such as:
https://cn.bing.comhttps://www4.bing.com/searchhttps://www2.bing.com/search
Because of how different the third-level domains (e.g., www, cn), top-level domains (e.g., com, net), and URL paths can be, simply ensuring that the referring domain contains the second-level domain of .bing. will allow all organic search traffic coming from Bing to be considered part of this channel.
These reasons are also why any more precise Rule Logic options cannot be chosen, as they would exclude referring domains that should be considered part of this channel.
Due to the complexity in implementing regex solutions, impact.com does not provide general advice or direction on how to implement regular expressions in Optimize. If you think your circumstances are best handled with a regex Rule Logic option, consult with your CSM on how to begin implementing that.
These two Rule Logic options function exactly the same, but with a small distinction. Exactly Matches will only search for the exact Rule Value 2 as it is written in the RTI. Matches Any will search for all Rule Value 2 as they are exactly written in the Rule.
If you find yourself using Exactly Matches more than once with the AND operator, consider using Matches Any. The same is true for Contains and Contains Any.
Click IDs are becoming increasingly common for paid media. The following is a list of common click IDs that you can use to identify traffic.
| Media Source | Click ID |
| Google Ads | GCLID |
| Bing Ads/Yahoo Search | MSCLKID |
| Facebook Ads | FBCLID |
EPIK |
Sometimes, creating Rules To Identify that disqualify traffic can be just as helpful to identifying traffic as part of a channel. See the subsections below to see how the examples created above can be set up to disqualify traffic.
Here is the example that was created above:
Rule Target | Rule Value 1 | Rule Logic | Rule Value 2 |
Landing Page URL |
| Exactly Matches |
|
This rule already disqualifies a lot of traffic. By adding another Rule To Identify and using the OR operator, the Rule can be opened up to qualify more traffic:
Rule Target | Rule Value 1 | Rule Logic | Rule Value 2 |
Landing Page URL |
| Exactly Matches |
|
OR | |||
Landing Page Parameter |
| Is Present | -- |
Now, if either Rule is true, the traffic will be identified as part of this channel.
Here is the example that was created above:
Rule Target | Rule Value 1 | Rule Logic | Rule Value 2 |
Referring Domain |
| Contains | .bing. |
This rule will identify all traffic that was referred by Bing. By adding another Rule and using the AND operator, the Rule can start disqualifying traffic referred by Bing:
Rule Target | Rule Value 1 | Rule Logic | Rule Value 2 |
Referring Domain |
| Contains | .bing. |
AND | |||
Landing Page Parameter |
| Is Not Present | -- |
Now, both Rules must be true for traffic to be identified as part of this channel.
Rules To Identify are not case sensitive. For example, if you have a parameter where utm_medium=SEARCH, you can still set your rule up as:
Rule Target | Rule Value 1 | Rule Logic | Rule Value 2 |
Landing Page URL |
| Exactly Matches |
|
Review some Optimize setup scenarios. Here, you will find recommendations for common Optimize scenarios.