> 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)
* [什么是信用组？](/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 Search | `MSCLKID` |
| Facebook Ads | `FBCLID` |
| Pinterest | `EPIK` |
#### 排除流量
有时，创建能够 *排除* 流量的识别规则，与将流量识别为某个渠道的一部分同样有帮助。请参见下面的小节，了解如何将上面创建的示例设置为排除流量。
{% tabs %}
{% tab title="示例 1：付费搜索" %}
以下是上面创建的示例：
| | | | |
| -------- | ------------ | -------- | --------- |
| **规则目标** | **规则值 1** | **规则逻辑** | **规则值 2** |
| 落地页 URL | `utm_medium` | 完全匹配 | `搜索` |
此规则已经排除了大量流量。通过再添加一个识别规则并使用 **或** 运算符，可以放宽该规则，以识别更多流量：
| | | | |
| -------- | ------------ | -------- | --------- |
| **规则目标** | **规则值 1** | **规则逻辑** | **规则值 2** |
| 落地页 URL | `utm_medium` | 完全匹配 | `搜索` |
| **或** | | | |
| 落地页参数 | `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 by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
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 what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.
