# 渠道设置策略

{% hint style="warning" %}
**重要**：在继续阅读本文之前，请熟悉以下资源：

* [Optimize 启动指南](https://help.impact.com/brand/zh/platform-features/cross-channel-performance-insights/optimize-startup-guide)
* [什么是识别规则（Rule To Identify）？](https://help.impact.com/brand/zh/platform-features/cross-channel-performance-insights/set-up-rules-to-identify-channel-traffic)
* [什么是信用组（Credit Group）？](https://help.impact.com/brand/zh/platform-features/actions-and-payouts/credit-groups-explained)
  {% endhint %}

本文介绍 Optimize 中的识别规则（RTI）的功能与用途。您将学习如何制定策略来为新渠道设置识别规则（RTI），或修改您计划中现有渠道的规则。

没有一种万能的解决方案适用于所有情况。但您应该能够找到最适合您特定情况的方案。针对某种 RTI 设置的反对意见总是可能存在，但是 **RTI 的目的并不是在所有情况下都能适用**. **RTI 应根据您的具体情况进行调整以达到最佳效果**.

本文将推进设计最优识别规则（Rules To Identify）所需的基础和功能性知识。

{% hint style="info" %}
**保持渠道设置的聚焦**：请记住，Optimize 的目的是呈现渠道级别的洞察；在创建 RTI 时，您必须考虑如何识别来自特定渠道的流量。牢记这一点将有助于使您的 RTI 简单、明确且有效。
{% endhint %}

**简要提醒**

* 规则目标（Rule Target）是规则将查找以应用规则逻辑并寻找规则值的位置（“在哪里”）。
* 规则逻辑（Rule Logic）是规则尝试识别流量的方式（“如何”）。
* 规则值（Rule Values）是您为规则提供以供利用的输入。

#### 精确性与可靠性

在设计 RTI 时，需要牢记的关键概念是精确性和可靠性。规则中的规则目标与规则逻辑选项不应被视为可互换，即使在某些情况下不止一组组件可行。有关示例，请参阅下文各节。

<details>

<summary>选择规则目标</summary>

规则目标可以根据精确性和可靠性进行评估。下图将各种规则目标按其各自的精确性和可靠性绘制。规则目标离图表原点越远，其精确性（沿 x 轴）和可靠性（沿 y 轴）越高。

<div data-with-frame="true"><figure><img src="https://1186853034-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>

您应始终尽量使用尽可能可靠且精确的规则目标，只有在别无选择时才向图表的左侧或下方移动。以下是两个关于如何选择使用哪个规则目标的示例案例。

**示例 1：付费搜索**

在此场景中，所有付费搜索流量均带有 Google 的 UTM 参数 `utm_medium=search`。因此， **落地页参数** 应为规则目标。识别规则将开始类似如下：

<table><thead><tr><th width="128">规则目标</th><th>规则值 1</th><th>规则逻辑</th><th></th></tr></thead><tbody><tr><td>着陆页 URL</td><td><code>utm_medium</code></td><td>*</td><td>*</td></tr></tbody></table>

查看 *规则逻辑 - 示例 1* 部分以查看应为 *规则逻辑* 和 *规则值 2*.

**示例 2：自然搜索**

下一个渠道，自然搜索，将没有 UTM 参数且登录页面不可预测。这些条件排除了所有定位参数和查询字符串的规则目标以及所有登录页面规则目标。根据上图，考虑到所有这些因素，最佳选项是 **推荐域名**。识别规则将开始类似如下：

| 规则目标 | 规则值 1 | 规则逻辑 |    |
| ---- | ----- | ---- | -- |
| 推荐域名 | `--`  | \*   | \* |

查看 *规则逻辑 - 示例 2* 部分以查看应为 *规则逻辑* 和 *规则值 2*.

</details>

<details>

<summary>选择规则逻辑选项</summary>

规则逻辑只能根据精确性进行评估。下图按相对精确性绘制了各种规则逻辑选项。

<div data-with-frame="true"><figure><img src="https://1186853034-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>

您应始终尽量使用尽可能精确的规则逻辑选项，只有在别无选择时才向图表下方移动。以下是两个关于如何选择规则逻辑选项的示例案例。

**示例 1：付费搜索**

既然所有付费搜索都带有 Google 的 UTM 参数 `utm_medium=search`，则最佳的规则逻辑选项是 **完全匹配**.

| 规则目标    | 规则值 1        | 规则逻辑 |          |
| ------- | ------------ | ---- | -------- |
| 着陆页 URL | `utm_medium` | 完全匹配 | `search` |

**完全匹配** 在此处最适合，因为只有具有精确参数键值对 `utm_medium=search` 的流量才应被视为该渠道的一部分。

例如，如果改用规则逻辑选项 **包含** ，任何包含 `utm_medium` 的值都会被视为该渠道的一部分，这可能导致错误归因、补偿（make-goods）以及其他问题。 `search` 然而， **包含** 并不是错误的选择； **完全匹配** 只是更好的选择。

**示例 2：自然搜索**

在早先将引用域（Referring Domain）规则目标确定为最佳选择后，一个可能的规则逻辑选项可以是如下：

| 规则目标 | 规则值 1 | 规则逻辑 |        |
| ---- | ----- | ---- | ------ |
| 推荐域名 | `--`  | 包含   | .bing. |

**包含** 在这里是一个不错的选择，因为 Bing 的自然搜索可能来自多个不同的引用 URL，例如：

* `https://cn.bing.com`
* `https://www4.bing.com/search`
* `https://www2.bing.com/search`

由于不同的三级域（例如， *www，cn*）、顶级域（例如， *com，net*）和 URL 路径可能存在差异，仅确保引用域包含二级域 **.bing.** 将允许来自 Bing 的所有自然搜索流量被视为该渠道的一部分。

</details>

这些原因也是为什么不能选择任何更精确的规则逻辑选项，因为它们会排除应被视为该渠道一部分的引用域。

**正则表达式（Regex）规则逻辑选项**

由于实施正则表达式解决方案的复杂性，impact.com 不会就如何在 Optimize 中实现正则表达式提供通用建议或指导。如果您认为您的情况最适合使用正则表达式规则逻辑选项，请与您的客户成功经理（CSM）咨询如何开始实施。

#### 完全匹配（Exactly Matches）与任意匹配（Matches Any）

这两种规则逻辑选项的功能完全相同，但有一个小区别。 *完全匹配* 将只按照 RTI 中所写的精确规则值 2 进行搜索。 *匹配任何* 将按照规则中所写的精确规则值 2 进行全部搜索。

如果您发现自己使用 **完全匹配** 和 **和** 运算符多次，考虑使用 **匹配任何**。同样适用于 **包含** 和 **包含任一项**.

#### 常见点击 ID

点击 ID 在付费媒体中变得越来越常见。以下是可用于识别流量的一些常见点击 ID 列表。

| 媒体来源        | 点击 ID     |
| ----------- | --------- |
| Google 广告   | `GCLID`   |
| 必应广告/雅虎搜索   | `MSCLKID` |
| Facebook 广告 | `FBCLID`  |
| Pinterest   | `EPIK`    |

#### 排除流量

有时，创建能够 *排除* 流量的识别规则，对识别某个渠道的流量同样有帮助。请参阅下面的小节，了解如何将上面创建的示例设置为排除流量。

{% tabs %}
{% tab title="示例 1：付费搜索" %}
这是上面创建的示例：

|          |              |          |           |
| -------- | ------------ | -------- | --------- |
| **规则目标** | **规则值 1**    | **规则逻辑** | **规则值 2** |
| 着陆页 URL  | `utm_medium` | 完全匹配     | `search`  |

该规则已经排除了很多流量。通过添加另一个识别规则并使用 **或** 运算符，可以打开规则以使其涵盖更多流量：

|          |              |          |           |
| -------- | ------------ | -------- | --------- |
| **规则目标** | **规则值 1**    | **规则逻辑** | **规则值 2** |
| 着陆页 URL  | `utm_medium` | 完全匹配     | `search`  |
| **或**    |              |          |           |
| 落地页参数    | `GCLID`      | 如果       | --        |

现在，只要任一规则为真，该流量就会被识别为该渠道的一部分。
{% endtab %}

{% tab title="示例 2：自然搜索" %}
这是上面创建的示例：

| 规则目标 | 规则值 1 | 规则逻辑 | 规则值 2  |
| ---- | ----- | ---- | ------ |
| 推荐域名 | `--`  | 包含   | .bing. |

此规则将识别所有由 Bing 引荐的流量。通过添加另一个规则并使用 **和** 运算符，该规则可以开始排除由 Bing 引荐的流量：

| 规则目标          | 规则值 1      | 规则逻辑 | 规则值 2  |
| ------------- | ---------- | ---- | ------ |
| 推荐域名          | `--`       | 包含   | .bing. |
| **和**         |            |      |        |
| 落地页参数         | `MSCLIKID` | 存在   | --     |
| {% endtab %}  |            |      |        |
| {% endtabs %} |            |      |        |

现在，必须同时满足两个规则，流量才会被识别为该渠道的一部分。

#### 大小写敏感性

识别规则不区分大小写。例如，如果您有一个参数为 `utm_medium=SEARCH`，您仍然可以将规则设置为：

| 规则目标    | 规则值 1        | 规则逻辑 | 规则值 2    |
| ------- | ------------ | ---- | -------- |
| 着陆页 URL | `utm_medium` | 完全匹配 | `search` |

#### 接下来是什么？

查看一些 [Optimize 设置场景](https://help.impact.com/brand/zh/platform-features/cross-channel-performance-insights/optimize-channels/optimize-channel-setup-scenario-examples)。在这里，您将找到针对常见 Optimize 场景的建议。
