促销 eVar 和产品查找方法

这份非常详细的文档介绍了促销 eVar 背后的概念，促销 eVar 处理和分配数据的方式与标准 eVar 不同。它还介绍了促销 eVar 与产品查找方法的关系。

概述

借助促销 eVar，您可以将任何成功的活动分配给 eVar 在​ 按产品 级别（而非​ 按访问/按订单 级别）捕获的值。

虽然大多数零售网站都有多种查找产品的方法，但 Adobe 认为每个零售客户都应在 Adobe Analytics 中跟踪的基本产品查找方法如下：

出于本文档的目的，我们将一些 eVar 映射到解决方案，如下所示：

我们可以使用额外的 eVar 来衡量所有产品查找方法相互之间的表现。除了上述查找方法外，eVar 还包括其他查找方法以进行比较，例如从外部网站链接到产品详细信息页面。

不要将这些变量中的任何一个配置为标准 eVar，而要将它们配置为促销 eVar。

为了演示如何设置这些变量，这里举了一个例子：一位访客决定使用内部搜索关键词“凉鞋”在网站上查找产品。在关键词搜索结果页面上，您必须至少捕获两个 eVar 中的数据：

当您将这两个变量设置为等于这些特定值时，便知道该访客正使用“凉鞋”这一内部搜索关键词来查找产品。与此同时，您知道该访客并未使用其他的产品查找方法来查找产品（例如，该访客并未在执行关键词搜索的同时浏览产品类别）。为确保按产品进行适当分配，这些未使用的方法不应该因为查找通过内部关键词搜索找到的产品而获得点数。因此，您必须在代码(例如AppMeasurement、Adobe Experience Platform Web SDK等)中插入逻辑，以自动将与其他这些查找方法关联的eVar设置为等于“非查找方法”值。

例如，当用户使用关键词“凉鞋”搜索产品时，Analytics 代码的逻辑应在内部关键词搜索结果页面上将变量设置为等于以下内容：

促销 eVar 设置

以下是您可以在促销 eVar 中使用的不同设置。以下屏幕快照来自报表包管理器。访问方法是转到 Analytics > 管理员 > 报表包 > 编辑设置 > 转化 > 转化变量 > 添加新项 > 启用促销。

有关这些设置的更多详细信息，请参阅下表各部分。

启用促销

当“启用促销”设置为“已启用”时，下面描述的所有设置都会出现在报表包管理器中。当“启用促销”设置为“已禁用”时，只有标准 eVar 设置可用。

促销

此选项不适用于标准 eVar。通过促销设置，您可以选择转化变量语法或产品语法作为捕获促销 eVar 值的方法。

转化变量语法 ​意味着您在其自身变量中设置 eVar 值。例如，使用转化变量语法， eVar1 “内部关键词搜索”的值在页面代码(或AppMeasurement代码、Adobe Experience Platform Web SDK代码等)中设置如下：

s.eVar1="internal keyword search";

而使用​ 产品语法，eVar 只在 Adobe Analytics 的 products 变量中设置。Analytics 的 products 变量分为六个不同部分（就每个产品而言）：

s.products="[category];[name];[quantity];[revenue];[events];[eVars]"

配置为使用产品语法的促销 eVar 在 products 变量的最后部分中设置。例如，假设访客使用内部关键词搜索来查找产品 ID“12345”。本例中基于产品语法设置 eVar1 的方法如下所示：

s.products=";12345;;;;eVar1=internal keyword search";

请注意，对于 products 变量的数量、收入和事件部分，我们仍然使用分号分隔的占位符。如果没有这些占位符，内部关键词搜索的 eVar1 设置将被完全忽略。

分配

用于促销 eVar 的术语“分配”具有误导性，尤其对于使用转化变量语法的促销 eVar。所有标准 eVar 都可以拥有各自的分配设置。然而，使用转化变量语法的促销 eVar 只使用“最近（最后一个）”分配设置，而不管报表包管理器中显示什么分配设置。

了解此设置的作用也就了解了 eVar 分配与促销 eVar 捆绑之间的区别。对于促销 eVar，“促销 eVar 捆绑”更适合用作这个“分配”设置的名称。

标准 eVar 分配设置

每当从一个图像请求中收集到任何使用标准语法的 eVar 时，Adobe Analytics 处理服务器都会将数据插入另一个数据库列（称为 post_evar 列）。由于 eVar 具有持久性（大多数情况下，它们会在超出当前点击的某个时间点过期），服务器随后会在每个后续图像请求中设置此 post_evar 列。它被设置为等于传递到相应 eVar 中的最后一个值。对于标准 eVar，当成功事件发生时，Adobe Analytics 使用 post_evar 列（而不是常规 eVar 列）来确定因该事件而获得点数的 eVar 值。

对于标准 eVar，“分配”设置确定是将某段时间内收集的第一个还是最后一个 eVar 值插入 post_evar 列。如果标准 eVar 的“分配”设置等于“原始值（第一个）”，则对于所有后续图像请求，从访客处收集的第一个 eVar 值将插入 post_evar 列。对于从该访客的浏览器发送的所有未来请求，都会继续执行这一操作，直到 eVar 按照其“过期时间”设置过期。

如果标准 eVar 的“分配”设置等于“最近（最后一个）”，则对于所有后续图像请求，从访客处收集的最近的 eVar 值将填入 post_evar 列。“最近（最后一个）”分配意味着在任何图像请求中，每次将相应的 eVar 设置为新值时，post_evar 值都会更改。“原始值（第一个）”分配意味着在未来某个图像请求中，即使相应的 eVar 可能设置为不同的值，post_evar 列也不会因点击而更改。

促销 eVar 分配（捆绑）设置

如前所述，所有使用转化变量语法的促销 eVar 都只有“最近（最后一个）”分配。因此，促销 eVar 的“分配”设置并不确定在访客继续使用网站时将哪些值插入 post_evar 列中；而是确定哪个 eVar 值捆绑到产品，以及这些产品如何将其成功事件分配回它们所捆绑的 eVar 值。

当促销 eVar 的“分配”（即捆绑）设置设为等于“原始值（第一个）”时，会发生以下情况：任何与 post_evar 列一起设置且之前尚未捆绑到 post_evar 列的相应“预处理”eVar 的产品都将捆绑到 post_evar 列中包含的值。eVar 值与产品之间的这种捆绑在 eVar 按照报表包设置中的“过期时间”设置过期之前永不改变。

每当图像请求满足将已捆绑产品捆绑到最近设置的 eVar 值的条件时，“原始值（第一个）”设置就会强制 Adobe Analytics 数据收集服务器忽略任何此类进一步的尝试。当“分配”（捆绑）设置等于“最近（最后一个）”时，促销 eVar 会出现相反的情况。每当图像请求满足将产品捆绑到销售 eVar 的条件时，该产品就会将自身捆绑（以及重新捆绑）到传递给 eVar 的最近值，或（始终）包含在 post_evar 列中的值。

如前所述，借助促销 eVar，您可以按产品（而不是按访问/按订单）将成功事件分配给 eVar 值。所以，每当捆绑的产品具有与之关联的成功事件（例如购物车添加或购买）时，成功事件就会将其点数提供给该产品和该产品当时捆绑的促销 eVar 值。

过期时间

通过促销 eVar 的过期设置，您可以选择

当记录了成功事件或经过一段特定时间后，eVar 可能会过期。Adobe Analytics 每次仅允许每个 eVar 有一个“过期”设置。

对于产品查找方法，设置促销 eVar 过期时间的最佳实践应是将其设置为等于

无论采用哪种设置，访客购买的任何产品都会将订单/件数/收入点数分配给当时产品捆绑的促销 eVar 值。

类型

eVar 类型设置确定插入 eVar 中的数据的类型。大多数情况下，该值应等于“文本”。将“计数器”用于促销 eVar 的情况很少见。但是，“计数器”可用于按产品将成功事件分配给“计数器”eVar 值。“计数器”类型解决方案的讨论超出了本文档的范围。

促销捆绑事件

通过“促销捆绑事件”设置，您可以指定将产品捆绑到促销 eVar 值的条件。这些条件仅限于特定成功事件或 eVar 的触发。触发流量变量（例如 prop）对促销捆绑没有影响。

请注意，“促销捆绑事件”设置可以通过多个事件将产品捆绑到 eVar 值。示例：

默认情况下，只要与产品相同的图像请求中包含任何其他事件/eVar（促销或标准），该设置就会将产品捆绑到促销 eVar 值。

重置

通过“重置”设置，您可以立即让当前在 Adobe Analytics 后端数据库中具有 post_evar 值的所有访客的所有 eVar 值“过期”。它还可消除所有当前的产品/eVar 捆绑。

应使用哪些设置？

在众多可用的设置组合中，您可能想知道：哪些设置是最佳实践？

如果要将“内部关键词搜索”捆绑到产品 ID 12345，则按如下方式设置 products 变量：

s.products=";12345;;;;eVar1=internal keyword search";

与产品 ID 12345 同时捕获的任何成功事件（购物车添加、购买）都将其点数提供给产品 ID 12345 和“内部关键词搜索”的 eVar1 值。对于与产品 ID 12345 关联的成功事件，不同的 eVar1 值获得点数的唯一方式是稍后将 eVar1 设置为 products 变量中的不同值（与产品 ID 12345 一起）。

例如：

s.products=";12345;;;;eVar1=internal campaign";

此变量设置将产品 ID 12345 的捆绑从“内部关键词搜索”的 eVar1 值更改为“内部营销活动”的 eVar1 值。此外，将 eVar 配置为使用产品语法和“最近（最后一个）”的“分配”（捆绑）设置时，也会发生这种重新捆绑更改。如果“分配”（捆绑）设置设为“原始值（第一个）”，则将 eVar1 与产品 ID 12345 一起设置为等于“内部营销活动”并不会将产品 ID 12345 重新捆绑到“内部营销活动”的 eVar1 值。相反，捆绑将保留最初捆绑的值 –“内部关键词搜索”。

使用产品语法时面临的挑战

若不仔细规划，使用产品语法可能会产生一些问题。我们以使用多个 eVar 跟踪网站上的产品查找方法为例。此处，必须同时设置每个单独产品的查找方法 eVar，以便为特定查找方法 eVar 提供点数（而其他查找方法 eVar 没有点数）。可以在此类场景中使用产品语法，但最终要部署的代码更加复杂。

如果我们使用最初的“凉鞋”示例，并将其调整为使用产品语法（假设访客使用关键词“凉鞋”找到了 ID 为“sandal123”的产品），则生成的 products 变量必须设置如下：

s.products=";sandal123;;;;eVar2=sandals|eVar1=internal search|eVar3=non-internal campaign|eVar4=non-browse|eVar5=non-cross-sell";

虽然本例中 products 变量的语法较长，但它会将看到的每个 eVar 值都捆绑到 ID 为“sandal123”的产品。从那时起，与“sandal123”产品同时捕获的任何成功事件（例如购物车添加、购买）都将其点数提供给最后捆绑到产品的 eVar 值。此代码示例显示，如果将上述 eVar 捆绑到“sandal123”产品后购买了 1 件“sandal123”产品（价格为 79.95 美元）：

s.products=";sandal123;1;79.95";
s.events="purchase";

以下值都将有 1 个订单、1 件产品和 79.95 美元的收入归因于它们：

这是正确的归因，并不是问题。这种方法的主要困境是确定如何以及何时设置产品查找方法 eVar。

在大多数使用产品语法的情况下，必须在产品详细信息页面上设置产品查找方法 eVar，而不是在实际使用查找方法的页面上进行设置（例如，关键词搜索结果页面、浏览页面、内部营销活动登陆页面等）。可以合理地假设，在访客与产品进行某种程度的交互之前，尚未真正“找到”产品。因此，不应在查找方法页面上设置这些 eVar（使用产品语法），因为这些页面上（通常）会显示多个产品。我们希望仅将查找方法值捆绑到访客与之交互的那些产品。

此外，在查看查找方法页面时，访客也许能够单击将他们带到单个产品详细信息页面的链接，或者直接从查找方法页面将单个产品添加到购物车。以我们的“凉鞋”搜索关键词为例，如果访客直接从关键词搜索结果页面将“sandal123”产品添加到购物车，那么用于捕获购物车添加（通过“添加到购物车”按钮的 onClick 事件等）的代码必须要么在购物车添加发生时动态生成，要么直接通过页面代码或标记管理系统进行“硬编码”。无论如何，在这种情况下触发的代码如下所示：

s.linkTrackVars="products,events";
s.linkTrackEvents=s.events="scAdd";
s.products=";sandal123;;;;eVar2=sandals|eVar1=internal keyword search|eVar3=non-internal campaign|eVar4=non-browse|eVar5=non-cross-sell";
s.tl(true,"o","Cart Add")

此代码将上面所示的 eVar 值正确捆绑到“sandal123”产品。但是，为了在发生点击事件时适当地设置这些值，开发人员必须：

另外，如果访客决定通过单击指向产品详细信息页面的链接来“查找”产品，则开发人员必须：

产品语法适用的情况

当具有相同产品 ID 的

例如，许多服装产品都有“子 SKU”，用于指定尺寸、颜色、款式和任何其他属性。这些属性将单个子产品与属于同一父产品的其他产品区分开来。比如说，您决定购买一件中号蓝色 T 恤和一件大号红色 T 恤。假设两件 T 恤的父产品 ID 均为“tshirt123”，并且 eVar10 已配置为捕获子 SKU。在购买确认页面上设置的变量将按如下方式设置：

s.events="purchase";
s.products=";tshirt123;1;20;;eVar10=tshirt123-m-blue,;tshirt123;1;20;;eVar10=tshirt123-l-red";

在本例中，“tshirt123-m-blue”和“tshirt123-l-red”的 eVar10（childSKU）值都因购买了各自的产品 ID“tshirt123”实例而获得点数。

“最近”分配的挑战

使用“最近（最后一个）”的“分配”（捆绑）设置可能会遇到其他问题。在许多网络浏览体验中，访客会“重新找到”他们已经查看和/或添加到购物车中的产品。这通常通过后续访问或就在他们决定完成购买之前发生。假设访客在访问网站时，通过关键词搜索“凉鞋”找到了“sandal123”产品。他们立即将其从关键词搜索结果页面添加到购物车。捕获购物车添加的代码将设置如下：

s.linkTrackVars="products,events";
s.linkTrackEvents=s.events="scAdd";
s.products=";sandal123;;;;eVar2=sandals|eVar1=internal keyword search|eVar3=non-internal campaign|eVar4=non-browse|eVar5=non-cross";

因此，此图像请求中所示的每个 eVar 值都捆绑到“sandal123”产品。

现在，假设访客在这次访问期间没有购买该产品，但三天后返回网站时，“sandals123”产品仍在购物车中。访客希望在购买之前了解有关该产品的更多信息。但是，访客不是使用关键词搜索来查找产品，而是浏览网站。就在“重新找到”该产品之前，他们最终会进入“女式”>“鞋子”>“凉鞋”的促销浏览区。当他们最终“重新查找”“sandal123”产品的产品详细信息页面时，变量将设置如下（加载页面时）：

s.events="prodView";
s.products=";sandal123;;;;eVar4=womens > shoes > sandals|eVar1=browse|eVar3=non-internal campaign|eVar2=non-search|eVar5=non-cross-sell";

当“分配”（捆绑）设置设为“最近（最后一个）”时，“sandal123”产品会重新捆绑到与最初捆绑的 eVar 值完全不同的 eVar 值。此外，如果访客随后完成了“sandal123”的购买，则所有购买点数都将分配给这些新捆绑的 eVar 值，而不是最初捆绑的值！

这里的问题是：哪些 eVar 值应获得购买点数？请记住，访客最初是通过内部关键词搜索找到“sandal123”产品的。然后，他们直接从搜索结果页面将其添加到购物车。因此，“内部关键词搜索”的 eVar1 值（以及“凉鞋”的 eVar2 值）应获得购买点数。但是，“分配”（捆绑）设置设为“最近（最后一个）”。因此，“浏览”的 eVar1 值（以及“女式 > 鞋子 > 凉鞋”的 eVar4 值）将获得购买点数。原因是，在访客完成购买之前，它们是绑定到“sandal123”的最后值。

此问题的解决方案是将促销 eVar 的“分配”（捆绑）设置从“最近（最后一个）”更改为“原始值（第一个）”。这样一来，捆绑到“sandal123”产品的原始 eVar 值就会在购买发生时获得点数，而不管访客“重新找到”该产品多少次。

如果访客将某个产品添加到购物车，但从未购买该产品，则 eVar 过期设置允许将新的查找方法值捆绑到该产品。eVar 过期时间应等于网站在自动删除产品之前让产品留在购物车中的时间。

使用转化变量语法

我们回到“产品语法”与“转化变量语法”的问题上来。Adobe 发现了一种更简单的方法，既可以收集促销 eVar 的产品查找方法，又可以将其值捆绑到访客找到的产品：使用转化变量语法可减少客户开发人员负责的实施工作。它仍然提供与产品语法方法相同甚至更有用的信息。开发人员只需按照给出的部署说明进行操作，其余代码可以放入Adobe AppMeasurement/Adobe Experience Platform Web SDK文件中。

例如，我们来看看推荐的用于跟踪内部关键词搜索性能的解决方案。它说的是，在关键词搜索结果页面上，代码捕获通过一个 prop（如 prop4）和另一个 prop（如 prop5）搜索的关键词。这些 prop 跟踪搜索结果的数量。每当在搜索结果页面上生成 Adobe Analytics 图像请求时，它都会使用开发人员部署的数据层对象（或页面代码）来填充上述变量 (prop)。

AppMeasurement/Adobe Experience Platform Web SDK文件中包含的其他逻辑可以填充需要同时设置的其余变量（促销eVar/维度）。
例如，如果新访客要对“凉鞋”进行关键词搜索（搜索结果页面上返回了 25 个结果），则要触发的代码（通过页面代码或数据层捕获）将如下所示：

s.prop4="sandals";
s.prop5="25";

AppMeasurement/Analytics SDK 文件中的逻辑随后可以自动将此代码片段转换为以下内容：

s.prop4="sandals";
s.prop5="25";
s.eVar2="sandals";
s.eVar1="internal keyword search";
s.eVar3="non-internal campaign";
s.eVar4="non-browse";
s.eVar5="non-cross sell";

无需担心将数据从一个页面传递到另一个页面，也无需担心尝试创建一个相当大而且笨拙的字符串以插入 products 变量中。开发人员可以实施他们的跟踪解决方案部分（哪些内容插入 prop 中），而将其余的实施留给 Adobe Consulting 提供的自定义代码。

如前所述，所有使用转化变量语法的促销 eVar 都具有“最近（最后一个）”的“分配”设置。一旦将 eVar 设置为等于任意值，该值将在所有后续点击中持续存在（通过 post_eVar 列）。它将一直存在，直到被设置为不同的值或直到 eVar 过期。因此，对于设置 eVar 后任何人交互的任何产品，如果尚未绑定到这些 eVar，则将其绑定到传递至 eVar 的“最近（最后一个）”值。

使用我们前面举的例子，“凉鞋”的 eVar2 值和“内部关键词搜索”的 eVar1 值等在关键词搜索发生之后所示的所有页面上持续存在。它们会一直存在，直到 eVar 被其他值覆盖。假设一位访客在关键词搜索结果页面上单击指向“sandal123”产品 ID 的产品详细信息页面的链接。那么，“sandal123”产品 ID（如果尚未捆绑）将捆绑到 post_evar 列中包含的每个值，或者捆绑到从上一（搜索结果）页面收集的 eVar 值。

对于转化变量语法，还有一点需要重新考虑。必须设置捆绑事件，以将 eVar 值捆绑到产品。在 Adobe Analytics 图像请求中，只是将促销 eVar（在其自己的变量中）与某个产品（在 products 变量中）一起设置并不一定会将 eVar 值捆绑到该产品。相反，在报表包管理器中设置的“促销捆绑事件”设置确定将 eVar 值捆绑到产品的条件。

由于我们希望每当发生产品交互（表明已“找到”产品）时就将产品查找方法 eVar 值捆绑到产品，因此可以放心地假设可能发生的最常见的“找到产品”交互是产品查看（当访客转到产品详细页面时）或购物车添加（当访客直接从产品查找方法页面将产品添加到购物车时）。

因此，我们可以选择这两个事件（prodView 和 scAdd）作为“基本”促销捆绑事件。
当这些捆绑事件中的任一事件包含在图像请求中时，会发生以下情况。包含在同一请求中（在 products 变量内）且尚未捆绑到促销 eVar 的任何产品 ID 都将捆绑到传递至促销 eVar（post_evar 列）的最近值。当“分配”（捆绑）设置设为等于“原始值（第一个）”时，在此原始捆绑发生后重新捆绑这些产品的任何尝试都将被忽略。

最佳实践设置

以下是最佳实践设置。它们可以轻松实施产品查找方法，并获得理想结果。Adobe 建议客户按如下方式配置其促销 eVar 的每种产品查找方法（一般而言）：

捆绑事件实际上做什么？

当捆绑事件包含在与 products 变量相同的服务器调用中时，其后处理列中的促销 eVar（使用转化变量语法）值将捆绑到 products 变量。基于前面的示例，假设一台服务器调用包含以下促销 eVar 值：

s.eVar2="sandals";
s.eVar1="internal keyword search";
s.eVar3="non-internal campaign";
s.eVar4="non-browse";
s.eVar5="non-cross sell";

如前所述，上述 eVar 通过其各自的 post_evar 列在当前点击之后持续存在。因此，Adobe 的服务器将上述 eVar 转换为以下内容：

post_eVar2="sandals";
post_eVar1="internal keyword search";
post_eVar3="non-internal campaign";
post_eVar4="non-browse";
post_eVar5="non-cross sell";

这些后处理列存储在 Adobe 的数据库中，并在它们最初设置的当前点击之后持续存在。这假设没有发生过期或变量重置。当 Adobe 的服务器处理包含捆绑事件和 products 变量的任何未来服务器调用时，这些 post_evar 值将“可用”。

捆绑仅在这些 post_evar 值与 products 变量的内容之间发生。捆绑事件不一定“捆绑”到 eVar 或 products 变量。它是“催化剂”，告诉 Adobe 服务器将 post_evar 值捆绑到产品。

假设在未来点击时，设置了以下变量：

s.products=";sandals123"
s.events="prodView";

在 post_evar 列中，Adobe 处理服务器按如下方式显示此点击：

s.products=";sandals123";
s.events="prodView";
post_eVar2="sandals";
post_eVar1="internal keyword search";
post_eVar3="non-internal campaign";
post_eVar4="non-browse";
post_eVar5="non-cross sell";

假设 eVar1、eVar2、eVar3、eVar4 和 eVar5 已配置为使用 prodView 作为捆绑事件。如果这些 eVar 中的任何一个未配置为使用 prodView 作为捆绑事件，则该（错误配置的）eVar 与 products 变量之间的捆绑将不会发生。

捆绑会产生一些非常有趣的结果，可以在 post_products 列的值中看到这些结果。捆绑对上面的代码进行了转换，并设置了更多的后处理列，如下所示：

post_events="prodView";
post_products=";sandals123;;;;eVar2=sandals|eVar1=internal keyword search|eVar3=non-internal campaign|eVar4=non-browse|eVar5=non-cross-sell";

您可能对 post_products 列中包含的值感到熟悉。在本文档中向上滚动并比较此 post_products 值和 s.products 值，如下所示。请注意，post_products 列是使用产品变量语法设置的！

这意味着捆绑通过产品语法将转化变量语法 eVar 值“复制”到 products 变量。仅当 products 变量和捆绑事件（通过 eVar 配置进行设置）包含在同一请求中时，才会发生此复制操作。此时，post_eVar 列中包含的值将捆绑到产品。此捆绑通过存储在 post_products 列中的产品语法表示。

促销eVar、实例量度和归因

在 Analytics 服务器调用中发送标准 eVar 时，其 post_evar 列中的值始终会获得一个归因于它的实例。实例表示在图像请求中将 eVar 设置为等于特定值的次数。

例如，假设 eVar10 是具有最后接触归因的标准 eVar。如果您在任何页面上设置 s.eVar10="hello world"，那么当 Adobe 处理点击时，“hello world”的值将传递到 post_evar10 列。对于 hello world 的每个 eVar10 设置，实例量度等于“1”。请记住，当 post_evar 列具有值时，并不总会记录实例。post_evar 列确定在记录一个实例时哪个值会获取该实例。

促销 eVar 的实例将归因于 eVar 收集的值。但是，只有在与促销 eVar 值捆绑的产品同时“交互”时才会发生这种情况。

例如，单独设置 s.eVar1="Internal Keyword Search" 不会为“内部关键词搜索”的 eVar1 值提供任何实例量度点数。此时将记录一个实例。但是，除非在设置 eVar1 的同时将产品捆绑到该“内部关键词搜索”值，否则该实例将归因于“未指定”存储桶。换句话说，“内部关键词搜索”的 eVar1 值可以获得一个实例。但只有当同一图像请求的 products 变量中出现捆绑到“内部关键词搜索”值的产品时，才会发生这种情况。

总之，如果不进行额外的配置，促销 eVar 的现成实例量度就没有多大用处。幸运的是，Adobe被释放了 归因. 您可以借助它，为 Adobe Analytics 收集的任何自定义量度应用多个归因模型。应用这些归因模型的量度不使用 post_evar 列中包含的值或捆绑到任一种特定产品的值。这些量度仅使用通过图像请求本身传递的值（或通过 Adobe Analytics 处理规则捕获的值）。您可以使用“归因”中的功能，为所有使用转化变量语法的促销eVar获取准确归因的实例量度。

将促销eVar的实例量度添加到报表时，正确的归因模型应该是“最近联系”模型。 在这种情况下，模型的“回顾窗口”设置并不重要。原因是，“强制”最后接触归因模型始终将实例点数分配给通过请求传入的每个单独值。这与 eVar 的实际属性/捆绑设置是设置为等于“最近（最后一个）”还是设置为“原始值（第一个）”无关。