> 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 的识别规则（RTI）的特性和功能。你将了解如何制定策略，为你的项目中的新渠道设置识别规则（RTI），或修改现有渠道。
没有一种万能方案能够适用于所有情况。不过，你应该能够得出最适合你独特情况的方案。针对某个特定 RTI 设置的反对意见总是可能存在，但 **RTI 的目的并不是在所有情况下都能发挥作用**. **RTI 的设计初衷是为了被调整为最适合你的具体情况**.
本文将补充设计适合你项目的最佳识别规则所需的基础和功能知识。
{% hint style="info" %}
**保持渠道设置聚焦**：请记住，Optimize 的重点在于呈现渠道层面的洞察；在创建 RTI 时，你必须考虑如何识别来自特定渠道的流量。牢记这一点将有助于让你的 RTI 保持简单、聚焦且有效。
{% endhint %}
**快速提醒**
* 规则目标是指规则将去哪里查找，以应用规则逻辑并找到规则值。
* 规则逻辑是规则尝试识别流量的方式。
* 规则值是你提供给规则用于判断的输入。
#### 精确性与可靠性
在设计 RTI 时，需要牢记的关键概念是精确性和可靠性。规则中的规则目标和规则逻辑选项不应被视为可互换，即使在某个场景下，多个组件组合都能正常工作。请参阅以下部分中的示例。
选择规则目标
可以从精确性和可靠性两个维度来评估规则目标。下图根据各自的精确性和可靠性绘制了不同的规则目标。规则目标距离图表原点越远，就越精确（沿 x 轴）且越可靠（沿 y 轴）。
你应始终尽可能使用最可靠、最精确的规则目标，只有在别无选择时才在图表中向左或向下移动。下面有两个示例，说明如何选择要使用的规则目标。
**示例 1：付费搜索**
在这种情况下，所有付费搜索流量都带有 Google 的 UTM 参数 `utm_medium=search`。因此， **落地页参数** 应该作为规则目标。识别规则将开始如下所示：
| 规则目标 | 规则值 1 | 规则逻辑 | |
|---|
| 落地页 URL | utm_medium | * | * |
查看 *规则逻辑 - 示例 1* 部分，看看这里应填写什么 *规则逻辑* 和 *规则值 2*.
**示例 2：自然搜索**
下一个渠道，自然搜索，不会有任何 UTM 参数，并且落地页不可预测。这些条件排除了所有以参数和查询字符串为目标的规则目标，以及所有落地页规则目标。你可以从上方图表看到，综合所有这些因素后，最佳选择是 **推荐域名**。识别规则将开始如下所示：
| 规则目标 | 规则值 1 | 规则逻辑 | |
| ---- | ----- | ---- | -- |
| 推荐域名 | `--` | \* | \* |
查看 *规则逻辑 - 示例 2* 部分，看看这里应填写什么 *规则逻辑* 和 *规则值 2*.
选择一个规则逻辑选项
规则逻辑只能从精确性角度进行评估。下图根据各个规则逻辑选项的相对精确性进行了绘制。
你应始终尽可能使用最精确的规则逻辑选项，只有在别无选择时才在图表中向下移动。下面有两个示例，说明如何选择要使用的规则逻辑选项。
**示例 1：付费搜索**
由于所有付费搜索都带有 Google 的 UTM 参数 `utm_medium=search`，因此最佳的规则逻辑选项将是 **完全匹配**.
| 规则目标 | 规则值 1 | 规则逻辑 | |
| ------- | ------------ | ---- | -------- |
| 落地页 URL | `utm_medium` | 完全匹配 | `search` |
**完全匹配** 在这里最有效，因为只有参数键值对精确为 `utm_medium=search` 的流量才应被视为此渠道的一部分。
例如，如果使用规则逻辑选项 **包含** ，那么任何 `utm_medium` 值中含有 `search` 的流量都会被视为此渠道的一部分，这可能会导致归因错误、补量，以及更多问题。 **包含** 不过，这并不意味着这里的选择是错误的； **完全匹配** 只是它恰好不是最佳选择。
**示例 2：自然搜索**
既然前面已经将引荐域规则目标确定为最佳选择，那么一个可能的规则逻辑选项可以是：
| 规则目标 | 规则值 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 的所有自然搜索流量都被视为此渠道的一部分。
这些原因也正是为什么不能选择任何更精确的规则逻辑选项，因为那样会排除本应被视为此渠道一部分的引荐域。
**正则表达式规则逻辑选项**
由于实现正则方案的复杂性，impact.com 不会就如何在 Optimize 中实现正则表达式提供通用建议或指导。如果你认为你的情况最适合使用正则规则逻辑选项，请与你的 CSM 联系，了解如何开始实施。
#### 完全匹配 vs. 任意匹配
这两个规则逻辑选项的功能完全相同，但有一个细微区别。 *完全匹配* 只会查找 RTI 中写明的精确规则值 2。 *任意匹配* 将查找规则中按原样写出的所有规则值 2。
如果你发现自己在 **完全匹配** 和 **以及** 运算符下多次使用 **任意匹配**，可以考虑使用 **包含** 和 **包含任意**.
#### 常见点击 ID
点击 ID 在付费媒体中正变得越来越常见。以下是你可以用来识别流量的常见点击 ID 列表。
| 媒体来源 | 点击 ID |
| --------------------- | --------- |
| Google Ads | `GCLID` |
| Bing Ads/Yahoo Search | `MSCLKID` |
| Facebook Ads | `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 设置场景](/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.