> 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` | 完全匹配 | `搜索` |
**完全匹配** 在这里最适合，因为只有参数键值对完全为 `utm_medium=search` 的流量才应被视为该渠道的一部分。
例如，如果使用规则逻辑选项 **包含** ，则任何 `utm_medium` 带有 `搜索` 其中内容的值都会被视为该渠道的一部分，这可能导致错误归因的操作、补偿投放，甚至更多问题。 **包含** 不过，在这里也并不算错误的选择； **完全匹配** 只是恰好是更好的选择。
**示例 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 搜索 | `MSCLKID` |
| Facebook Ads | `FBCLID` |
| Pinterest | `EPIK` |
#### 排除流量
有时，创建能够 *排除* 流量与将其识别为某个渠道的一部分同样有帮助。请查看下面的小节，了解如何将上面创建的示例设置为排除流量。
{% tabs %}
{% tab title="示例 1：付费搜索" %}
以下是上面创建的示例：
| | | | |
| -------- | ------------ | -------- | --------- |
| **规则目标** | **规则值 1** | **规则逻辑** | **规则值 2** |
| 落地页 URL | `utm_medium` | 完全匹配 | `搜索` |
这条规则已经排除了大量流量。通过再添加一条识别规则并使用 **OR** 运算符，可以将该规则扩展为识别更多流量：
| | | | |
| -------- | ------------ | -------- | --------- |
| **规则目标** | **规则值 1** | **规则逻辑** | **规则值 2** |
| 落地页 URL | `utm_medium` | 完全匹配 | `搜索` |
| **OR** | | | |
| 落地页参数 | `GCLID` | 已存在 | -- |
现在，只要任一规则为真，流量就会被识别为该渠道的一部分。
{% endtab %}
{% tab title="示例 2：自然搜索" %}
以下是上面创建的示例：
| 规则目标 | 规则值 1 | 规则逻辑 | 规则值 2 |
| ---- | ----- | ---- | ------ |
| 来源域名 | `--` | 包含 | .bing. |
这条规则会识别所有由 Bing 引荐的流量。通过再添加一条规则并使用 **且** 运算符，规则就可以开始排除由 Bing 引荐的流量：
| 规则目标 | 规则值 1 | 规则逻辑 | 规则值 2 |
| ------------- | ---------- | ---- | ------ |
| 来源域名 | `--` | 包含 | .bing. |
| **且** | | | |
| 落地页参数 | `MSCLIKID` | 不存在 | -- |
| {% endtab %} | | | |
| {% endtabs %} | | | |
现在，两个规则都必须为真，流量才会被识别为该渠道的一部分。
#### 大小写敏感性
识别规则不区分大小写。例如，如果你有一个参数，其中 `utm_medium=SEARCH`，你仍然可以将规则设置为：
| 规则目标 | 规则值 1 | 规则逻辑 | 规则值 2 |
| ------- | ------------ | ---- | ----- |
| 落地页 URL | `utm_medium` | 完全匹配 | `搜索` |
#### 下一步是什么？
查看一些 [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.