> 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 %}

**简要提醒**

* Rule Target 是规则将在哪里查找以应用 Rule Logic 并找到 Rule Value(s)。
* Rule Logic 是规则将如何尝试识别流量。
* Rule Values 是你为规则提供的输入，用于辅助判断。

#### 精确性与可靠性

在设计 RTI 时，需要牢记的关键概念是精确性和可靠性。Rule 中的 Rule Target 和 Rule Logic 选项不应被视为可互换，即使在某个场景下，多个组件组合都能正常工作。下面各部分将提供示例说明。

<details>

<summary>选择一个 Rule Target</summary>

可以从精确性和可靠性两个方面评估 Rule Target。下图按各个 Rule target 的相对精确性和可靠性进行展示。Rule Target 距离图表原点越远，就越精确（沿 x 轴）且越可靠（沿 y 轴）。

<div data-with-frame="true"><figure><img src="/files/967e3148c40bb2169ebf5f8e4fc5778caff58fc5" alt=""><figcaption></figcaption></figure></div>

你应始终尽量使用你能获得的最可靠、最精确的 Rule Target；只有在别无选择时，才向图表左侧或下方移动。下面有两个示例，说明如何选择要使用的 Rule Target。

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

在这种情况下，所有付费搜索流量都带有 Google 的 UTM 参数 `utm_medium=search`。因此， **落地页参数** 应该作为 Rule Target。识别规则将开始呈现如下：

<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>

查看 *Rule Logic - 示例 1* 部分，看看这里应填写什么 *规则逻辑* 和 *规则值 2*.

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

下一个渠道，自然搜索，不会带有任何 UTM 参数，而且落地页也不可预测。这些条件排除了所有以参数和查询字符串为目标的 Rule Target，以及所有落地页 Rule Target。你可以从上方图表看出，在综合考虑这些因素后，最佳选项是 **引荐域名**。识别规则将开始呈现如下：

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

查看 *Rule Logic - 示例 2* 部分，看看这里应填写什么 *规则逻辑* 和 *规则值 2*.

</details>

<details>

<summary>选择一个 Rule Logic 选项</summary>

Rule Logic 只能从精确性方面进行评估。下图按各个 Rule Logic 选项的相对精确性进行展示。

<div data-with-frame="true"><figure><img src="/files/d5f4b4d3e1cc755b45fad8a4e5e0981b8b47b057" alt=""><figcaption></figcaption></figure></div>

你应始终尽量使用你能获得的最精确的 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 的所有自然搜索流量视为该渠道的一部分。

</details>

正因如此，也不能选择任何更精确的 Rule Logic 选项，因为那样会排除掉本应被视为该渠道一部分的引荐域名。

**Regex Rule Logic 选项**

由于实现正则表达式解决方案较为复杂，impact.com 不会就如何在 Optimize 中实现正则表达式提供通用建议或指导。如果你认为你的情况最适合使用 regex Rule Logic 选项，请与你的 CSM 咨询如何开始实施。

#### Exactly Matches 与 Matches Any

这两个 Rule Logic 选项的功能完全相同，但有一个小区别。 *完全匹配* 将只搜索 RTI 中按原样写出的精确 Rule Value 2。 *匹配任意* 将搜索所有在 Rule 中按原样写出的 Rule Value 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`  |

该规则已经取消了大量流量的资格。通过添加另一个识别规则并使用 **OR** 运算符，可以放宽规则以使更多流量符合条件：

|          |              |          |           |
| -------- | ------------ | -------- | --------- |
| **规则目标** | **规则值 1**    | **规则逻辑** | **规则值 2** |
| 着陆页 URL  | `utm_medium` | 完全匹配     | `search`  |
| **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` | 完全匹配 | `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=<question>&goal=<endgoal>
```

`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.