> For the complete documentation index, see [llms.txt](https://help.impact.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.impact.com/brand/zh/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/optimize-channels/channel-setup-strategy.md).
# 渠道设置策略
{% hint style="warning" %}
**重要**：在继续阅读本文之前，请先熟悉以下资源：
* [Optimize 入门指南](/brand/zh/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/optimize-startup-guide.md)
* [什么是识别规则？](/brand/zh/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/set-up-rules-to-identify-channel-traffic.md)
* [什么是 Credit Group？](/brand/zh/what-would-you-like-to-learn-about/platform-features/actions-and-payouts/credit-groups-explained.md)
{% endhint %}
本文介绍 Optimize 的 Rules To Identify（RTI）的功能和特性。你将了解如何制定策略，为新的渠道设置 Rules To Identify（RTI），或修改程序中现有渠道。
没有一种万能解决方案能够适用于所有情况。不过，你应该能够找到最适合你独特情况的解决方案。针对某个 RTI 设置的反对意见总是可能存在，但 **RTI 的目的并不是在所有情况下都适用**. **RTI 的设计目的是经过调整，以最适合你的具体情况**.
本文档将进一步提供设计适合你程序的最佳 Rules To Identify 所需的基础和功能知识。
{% hint style="info" %}
**保持渠道设置聚焦**：请记住，Optimize 的重点是呈现渠道层级的洞察；在创建 RTI 时，你必须考虑如何识别来自特定渠道的流量。牢记这一点有助于让你的 RTI 保持简洁、聚焦且有效。
{% endhint %}
**快速提示**
* 规则目标是规则应用规则逻辑并查找规则值的“位置”。
* 规则逻辑是规则尝试识别流量的“方式”。
* 规则值是你提供给规则用于辅助判断的输入。
#### 精确性与可靠性
在设计 RTI 时，需要牢记的关键概念是精确性和可靠性。规则中的 Rule Target 和 Rule Logic 选项不应被视为可互换，即使在某个场景下有不止一组组件可用。以下章节提供了相关示例。
选择 Rule Target
Rule Target 可从精确性和可靠性两个维度进行评估。下图按各个 Rule Target 的精确性和可靠性进行了绘制。Rule Target 离图表原点越远，就越精确（沿 x 轴）且越可靠（沿 y 轴）。
你应始终尽可能使用最可靠、最精确的 Rule Target，只有在别无选择时才向图表左侧或下方移动。下面是两个关于如何选择 Rule Target 的示例。
**示例 1：付费搜索**
在此场景中，所有付费搜索流量都标记了 Google 的 UTM 参数 `utm_medium=search`。因此， **落地页参数** 应当作为 Rule Target。Rule To Identify 将会类似如下：
| 规则目标 | 规则值 1 | 规则逻辑 | |
|---|
| 落地页 URL | utm_medium | * | * |
查看 *规则逻辑 - 示例 1* 部分，查看应在 *规则逻辑* 和 *规则值 2*.
**示例 2：自然搜索**
下一个渠道，自然搜索，不会有 UTM 参数，且着陆页不可预测。这些条件排除了所有以参数和查询字符串为目标的 Rule Target，以及所有着陆页 Rule Target。你可以从上方图表看出，综合考虑这些因素后，最佳选择是 **推荐域名**。Rule To Identify 将会类似如下：
| 规则目标 | 规则值 1 | 规则逻辑 | |
| ---- | ----- | ---- | -- |
| 推荐域名 | `--` | \* | \* |
查看 *规则逻辑 - 示例 2* 部分，查看应在 *规则逻辑* 和 *规则值 2*.
选择 Rule Logic 选项
Rule Logic 只能从精确性角度进行评估。下图按各个 Rule Logic 选项的相对精确性进行了绘制。
你应始终尽可能使用最精确的 Rule Logic 选项，只有在别无选择时才向图表下方移动。下面是两个关于如何选择 Rule Logic 选项的示例。
**示例 1：付费搜索**
由于所有付费搜索都标记了 Google 的 UTM 参数 `utm_medium=search`，因此最佳的 Rule Logic 选项将是 **完全匹配**.
| 规则目标 | 规则值 1 | 规则逻辑 | |
| ------- | ------------ | ---- | -------- |
| 落地页 URL | `utm_medium` | 完全匹配 | `search` |
**完全匹配** 在这里最合适，因为只有参数键值对完全为 `utm_medium=search` 的流量才应被视为该渠道的一部分。
例如，如果使用 Rule Logic 选项 **包含** ，那么任何 `utm_medium` 的值 `search` 中包含该内容的流量都会被视为该渠道的一部分，这可能导致归因错误、补偿处理，以及更多问题。 **包含** 不过，这里并不是错误选择； **完全匹配** 只是它恰好是更好的选择。
**示例 2：自然搜索**
既然前面已经确定 Referring Domain Rule Target 是最佳选择，那么一个可行的 Rule Logic 选项可以是：
| 规则目标 | 规则值 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 的所有自然搜索流量都被视为该渠道的一部分。
这些原因也是为什么不能选择更精确的 Rule Logic 选项，因为那样会排除本应归为该渠道一部分的引荐域名。
**Regex Rule Logic 选项**
由于实现正则表达式方案较为复杂，impact.com 不会就如何在 Optimize 中实现正则表达式提供通用建议或指导。如果你认为你的情况最适合使用 regex Rule Logic 选项，请与你的 CSM 讨论如何开始实施。
#### 完全匹配 vs. 匹配任一
这两个 Rule Logic 选项的功能完全相同，但有一个小区别。 *完全匹配* 将只搜索 RTI 中按原样写出的确切 Rule Value 2。 *匹配任一* 将搜索规则中按原样写出的所有 Rule Value 2。
如果你发现自己在 **完全匹配** 和 **AND** 运算符一起多次使用 **匹配任一**，不妨考虑使用 **包含** 和 **包含任一**.
#### 常见点击 ID
点击 ID 在付费媒体中正变得越来越常见。以下是你可用于识别流量的常见点击 ID 列表。
| 媒体来源 | 点击 ID |
| --------------------- | --------- |
| Google Ads | `GCLID` |
| Bing Ads/Yahoo Search | `MSCLKID` |
| Facebook Ads | `FBCLID` |
| Pinterest | `EPIK` |
#### 排除流量
有时，创建会 *排除* 流量的 Rules To Identify，与将流量识别为渠道的一部分同样有帮助。请查看下面的子部分，了解如何将上面创建的示例设置为排除流量。
{% tabs %}
{% tab title="示例 1：付费搜索" %}
以下是上面创建的示例：
| | | | |
| -------- | ------------ | -------- | --------- |
| **规则目标** | **规则值 1** | **规则逻辑** | **规则值 2** |
| 落地页 URL | `utm_medium` | 完全匹配 | `search` |
此规则已经排除了大量流量。通过再添加一个 Rule To Identify 并使用 **或者** 运算符，规则可以扩展以识别更多流量：
| | | | |
| -------- | ------------ | -------- | --------- |
| **规则目标** | **规则值 1** | **规则逻辑** | **规则值 2** |
| 落地页 URL | `utm_medium` | 完全匹配 | `search` |
| **或者** | | | |
| 落地页参数 | `GCLID` | 存在 | -- |
现在，只要任一规则为真，流量就会被识别为该渠道的一部分。
{% endtab %}
{% tab title="示例 2：自然搜索" %}
以下是上面创建的示例：
| 规则目标 | 规则值 1 | 规则逻辑 | 规则值 2 |
| ---- | ----- | ---- | ------ |
| 推荐域名 | `--` | 包含 | .bing. |
此规则将识别所有由 Bing 引荐的流量。通过再添加一个规则并使用 **AND** 运算符，规则就可以开始排除由 Bing 引荐的流量：
| 规则目标 | 规则值 1 | 规则逻辑 | 规则值 2 |
| ------------- | ---------- | ---- | ------ |
| 推荐域名 | `--` | 包含 | .bing. |
| **AND** | | | |
| 落地页参数 | `MSCLIKID` | 不存在 | -- |
| {% endtab %} | | | |
| {% endtabs %} | | | |
现在，必须两个规则都为真，流量才会被识别为该渠道的一部分。
#### 大小写敏感性
Rules To Identify 不区分大小写。例如，如果你有一个参数，其中 `utm_medium=SEARCH`，你仍然可以将规则设置为：
| 规则目标 | 规则值 1 | 规则逻辑 | 规则值 2 |
| ------- | ------------ | ---- | -------- |
| 落地页 URL | `utm_medium` | 完全匹配 | `search` |
#### 接下来是什么？
查看一些 [Optimize 设置场景](/brand/zh/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/optimize-channels/optimize-channel-setup-scenario-examples.md)。在这里，你将找到常见 Optimize 场景的建议。
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://help.impact.com/brand/zh/what-would-you-like-to-learn-about/platform-features/cross-channel-performance-insights/optimize-channels/channel-setup-strategy.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
