# Channel Setup Strategy

{% hint style="warning" %}
**Important**: Familiarize yourself with the following resources before moving on to this article:

* [Optimize Startup Guide](https://help.impact.com/brand/platform-features/cross-channel-performance-insights/optimize-startup-guide)
* [What is a Rule To Identify?](https://help.impact.com/brand/platform-features/cross-channel-performance-insights/set-up-rules-to-identify-channel-traffic)
* [What is a Credit Group?](https://help.impact.com/brand/platform-features/actions-and-payouts/credit-groups-explained)
  {% endhint %}

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.

{% hint style="info" %}
**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.
{% endhint %}

**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.

#### Precision & Reliability

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.

<details>

<summary>Choose a Rule Target</summary>

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.

<div data-with-frame="true"><figure><img src="https://4048883401-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FwMLlMoFBtKJa8ptd3zaw%2Fuploads%2Fgit-blob-489f6f57993cbcf93749f93b54b796fd3f2f0095%2Fc19fe1a665f9b3e512fe5afb73ca76dfe2ae37fcda9f0873ae316bebaf1fb02c.png?alt=media" alt=""><figcaption></figcaption></figure></div>

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.

**Example 1: Paid Search**

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:

<table><thead><tr><th width="128">Rule Target</th><th>Rule Value 1</th><th>Rule Logic</th><th></th></tr></thead><tbody><tr><td>Landing Page URL</td><td><code>utm_medium</code></td><td>*</td><td>*</td></tr></tbody></table>

View the *Rule Logic - Example 1* section to see what to fill in for the *Rule Logic* and *Rule Value 2*.

**Example 2: Organic Search**

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 |    |
| ---------------- | ------------ | ---------- | -- |
| Referring Domain | `--`         | \*         | \* |

View the *Rule Logic - Example 2* section to see what to fill in for the *Rule Logic* and *Rule Value 2*.

</details>

<details>

<summary>Choose a Rule Logic option</summary>

Rule Logic can only be evaluated for precision. The following chart plots the various Rule Logic options in terms of their relative precision.

<div data-with-frame="true"><figure><img src="https://4048883401-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FwMLlMoFBtKJa8ptd3zaw%2Fuploads%2Fgit-blob-c917a70e8cfa00de3db2c1855ae9276f687da113%2F5a7fdeb96314eec55916b1fb0357483ee17dd3aec317357e20bbf514232c2ab0.png?alt=media" alt=""><figcaption></figcaption></figure></div>

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.

**Example 1: Paid Search**

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      |          |
| ---------------- | ------------ | --------------- | -------- |
| Landing Page URL | `utm_medium` | Exactly Matches | `search` |

**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.

**Example 2: Organic Search**

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 |        |
| ---------------- | ------------ | ---------- | ------ |
| 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.com`
* `https://www4.bing.com/search`
* `https://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.

</details>

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.

**Regex Rule Logic options**

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.

#### Exactly Matches vs. Matches Any

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**.

#### Common click IDs

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`  |
| Pinterest             | `EPIK`    |

#### Disqualifying traffic

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.

{% tabs %}
{% tab title="Example 1: Paid Search" %}
Here is the example that was created above:

|                  |                  |                 |                  |
| ---------------- | ---------------- | --------------- | ---------------- |
| **Rule Target**  | **Rule Value 1** | **Rule Logic**  | **Rule Value 2** |
| Landing Page URL | `utm_medium`     | Exactly Matches | `search`         |

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       | `utm_medium`     | Exactly Matches | `search`         |
| **OR**                 |                  |                 |                  |
| Landing Page Parameter | `GCLID`          | Is Present      | --               |

Now, if either Rule is true, the traffic will be identified as part of this channel.
{% endtab %}

{% tab title="Example 2: Organic Search" %}
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 | `MSCLIKID`   | Is Not Present | --           |
| {% endtab %}           |              |                |              |
| {% endtabs %}          |              |                |              |

Now, both Rules must be true for traffic to be identified as part of this channel.

#### Case sensitivity

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 | `utm_medium` | Exactly Matches | `search`     |

#### What's next?

Review some [Optimize setup scenarios](https://help.impact.com/brand/platform-features/cross-channel-performance-insights/optimize-channels/optimize-channel-setup-scenario-examples). Here, you will find recommendations for common Optimize scenarios.
