渠道设置策略

重要：在继续阅读本文之前，请先熟悉以下资源：

• Optimize 启动指南

• 什么是 Rule To Identify？

• 什么是 Credit Group？

本文介绍 Optimize 的 Rules To Identify（RTI）的功能与作用。您将学习如何制定策略，为新渠道设置 Rules To Identify（RTI），或修改程序中现有渠道的 RTI。

没有一种万能解决方案可以适用于所有情况。不过，您应该能够得出最适合您独特情况的解决方案。针对某个 RTI 设置的反对意见总是可能存在，但是 RTI 的目的并不是在所有情况下都能工作. RTI 的设计应当根据您的具体情况进行调整，以达到最佳适配.

本文将进一步提升设计适用于您程序的最佳 Rules To Identify 所需的基础与功能知识。

保持渠道设置聚焦：请记住，Optimize 的重点是呈现渠道级洞察；在创建 RTI 时，您必须考虑如何识别来自特定渠道的流量。牢记这一点将有助于让您的 RTI 保持简洁、聚焦且有效。

快速提醒

• Rule Target 是规则将通过“何处”来应用 Rule Logic 并查找 Rule Value(s)。

• Rule Logic 是规则将以“何种方式”尝试识别流量。

• Rule Values 是您提供给规则用于辅助判断的输入。

精确性与可靠性

在设计 RTI 时，需要牢记的关键概念是精确性和可靠性。规则中的 Rule Target 和 Rule Logic 选项不应被视为可互换，即使在某些场景下，多个组件组合都能工作。以下章节将提供相关示例。

选择 Rule Target

Rule Targets 可从精确性和可靠性两个方面进行评估。下图根据各个 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	*	*

查看下方的 Rule Logic - 示例 1 章节，查看此处应填写什么内容 规则逻辑 和 规则值 2.

示例 2：自然搜索

下一个渠道，自然搜索，不会有 UTM 参数，且落地页也无法预测。这些条件排除了所有以参数和查询字符串为目标的 Rule Targets，以及所有以落地页为目标的 Rule Targets。您可以从上方图表看到，在考虑这些因素后，最优选项是 推荐域名。Rule To Identify 将开始呈现如下：

规则目标	规则值 1	规则逻辑
推荐域名	--	*	*

查看下方的 Rule Logic - 示例 2 章节，查看此处应填写什么内容 规则逻辑 和 规则值 2.

选择一个 Rule Logic 选项

Rule Logic 只能从精确性角度进行评估。下图根据各个 Rule Logic 选项的相对精确性进行了展示。

您应始终尽量使用最精确的 Rule Logic 选项，只有在别无选择时才向图表下方移动。以下是两个用于说明如何选择 Rule Logic 选项的示例。

示例 1：付费搜索

由于所有付费搜索都带有 Google 的 UTM 参数 utm_medium=search，因此最佳的 Rule Logic 选项应为 完全匹配.

规则目标	规则值 1	规则逻辑
落地页 URL	utm_medium	完全匹配	搜索

完全匹配 在这里最适合，因为只有具有精确参数键值对 utm_medium=search 的流量才应被视为该渠道的一部分。

例如，如果改用 Rule Logic 选项 包含 ，那么任何 utm_medium 值中包含 搜索 的内容都将被视为该渠道的一部分，这可能导致归因错误、补偿流量，以及更多问题。 包含 不过，在这里这也不是错误的选择； 完全匹配 只是它恰好不是更优选择。

示例 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 路径可能存在很大差异，因此只要确保 referring domain 包含二级域 .bing. 即可让所有来自 Bing 的自然搜索流量被视为该渠道的一部分。

这些原因也解释了为何不能选择任何更精确的 Rule Logic 选项，因为那样会排除本应被视为该渠道一部分的 referring domains。

Regex Rule Logic 选项

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

Exactly Matches 与 Matches Any

这两个 Rule Logic 选项的功能完全相同，但有一个小区别。 完全匹配 只会搜索 RTI 中按原样写出的精确 Rule Value 2。 匹配任意一个 会搜索所有在 Rule 中按原样写出的 Rule Value 2。

如果您发现自己在使用 完全匹配 与 AND 运算符一起多次出现，建议考虑使用 匹配任意一个。对于 包含 和 包含任意一个.

常见点击 ID

点击 ID 在付费媒体中正变得越来越常见。以下是一些可用于识别流量的常见点击 ID 列表。

媒体来源	点击 ID
Google Ads	GCLID
Bing Ads/Yahoo Search	MSCLKID
Facebook Ads	FBCLID
Pinterest	EPIK

排除流量

有时，创建能够 排除 流量的 Rules To Identify，与将流量识别为某个渠道的一部分同样有帮助。请参阅下面的小节，了解如何将上面创建的示例设置为排除流量。

示例 1：付费搜索

下面是上面创建的示例：

规则目标	规则值 1	规则逻辑	规则值 2
落地页 URL	utm_medium	完全匹配	搜索

该规则已经排除了大量流量。通过再添加一个 Rule To Identify 并使用 或者 运算符，可以将该规则扩展为识别更多流量：

规则目标	规则值 1	规则逻辑	规则值 2
落地页 URL	utm_medium	完全匹配	搜索
或者
落地页参数	GCLID	存在	--

现在，只要任一规则为真，流量就会被识别为该渠道的一部分。

示例 2：自然搜索

现在，必须两个规则都为真，流量才会被识别为该渠道的一部分。

大小写敏感性

Rules To Identify 不区分大小写。例如，如果您有一个参数，其中 utm_medium=SEARCH，您仍然可以将规则设置为：

规则目标	规则值 1	规则逻辑	规则值 2
落地页 URL	utm_medium	完全匹配	搜索

接下来做什么？

查看一些 Optimize 设置场景。在这里，您将找到针对常见 Optimize 场景的建议。