重定向选件 - A4T 常见问题解答

您的实施必须满足以下最低要求：

• Experience Cloud 访客 ID 服务：visitorAPI.js 版本 2.3.0 或更高版本。
• Adobe Analytics：appMeasurement.js 版本 2.1。
• Adobe Target：at.js 版本 1.6.2 或更高版本。

具有重定向选件的页面和访客被重定向到的页面都必须包含这三个库。

在配置了Analytics for Target (A4T)的活动中使用重定向选件时，有限数量的客户报告流量分布的差异程度较高。

请考虑以下事项：

• Target和Analytics调用顺序不正确可能导致差异程度较高。

  Target调用必须位于源页面（其中发生重定向）和目标页面（其中重定向结束）上的Analytics调用之前。

• 确保在A4T重定向活动中使用重定向选件。

• 如果源页面上有多个Target位置请求（发生重定向），Adobe建议您在第一个Target位置请求上运行重定向活动。

  对前Target个位置请求运行重定向活动可减少其他Target个位置请求中发生任何活动资格并被计入报表中的可能性。 被重定向的访客无需计入其他活动的报表中，因为他们看不到这些体验。

使用at.js版本1.6.3或更高版本时，不计算两个页面上的页面查看次数。 这种争用情况仅影响使用早期版本的客户。Target 团队维护两个版本的 at.js：当前版本和当前版本的上一个版本。根据需要升级at.js，以确保您运行的是支持的版本。

如果您使用的是不受支持的早期 at.js 版本，则可能会发生某种争用情况，这种情况可能导致先触发 Analytics 调用，然后再在第一个页面上执行重定向。这种情况可能会导致同时计入原始页面和重定向页面上的页面查看次数。 在这种情况下，第一个页面上的页面查看次数便是多余的，因为当时访客实际上从未“查看过”该页面。

鉴于代码在页面上的执行位置，建议使用基于表单的编辑器构建重定向活动，以提高页面重定向的速度。 此外，还建议为每个体验各创建一个重定向选件，甚至对默认体验（在默认体验中重定向会返回原始页面）也是如此。为每个体验创建重定向选件可确保在发生计数错误时，所有体验都会发生该错误。 报告和分析对于测试仍然有效。

您希望对活动中包括默认（控制）体验在内的所有体验都使用重定向选件，因这样可以为所有体验施加相同的条件。例如，如果默认体验没有重定向选件，但其他体验具有重定向选件，则没有重定向选件的体验速度将具有一种内在优势。建议仅对临时方案（例如测试）使用重定向选件。不建议对永久性方案（例如个性化）使用重定向选件。确定“入选者”后，应删除重定向以提高页面加载性能。

是，只要您使用内置的重定向选件，这两种编辑器便均受支持。

如果您使用自己的自定义重定向代码，则必须确保填充两个与重定向 URL 关联的新参数（即下面介绍的 adobe_mc_sdid 和 adobe_mc_ref）。

以下查询字符串参数与重定向选件关联：

在 VEC 和基于表单的体验编辑器中使用内置的重定向选件时，如果已在页面上实施访客 ID 服务，则这两个参数会自动添加到重定向 URL 中。如果您在 VEC 或基于表单的编辑器中使用自己的自定义重定向代码，则必须确保使用自定义代码传递这两个参数。

在下列情况下使用自定义编码重定向：

• 您的重定向活动未使用A4T
• 您已实施访客ID服务
• 您不希望将这些参数自动添加到URL

但是，作为最佳实践，您可能想要在 URL 中保留 adobe_mc_ref 参数，以便能够向 Analytics 正确报告引荐信息。

如果您使用A4T和重定向选件，则Target会将adobe_mc_ref和adobe_mc_sdid参数附加到URL。 这两个值已进行 URL 编码。在大多数情况下，一切都会按预期运行；但是，有些客户使用的负载平衡器或 Web 服务器可能会尝试对查询字符串参数再次进行编码。

由于此双重编码过程，访客 API 在尝试对 adobe_mc_sdid 值进行解码时，将无法提取 SDID 值，故而会生成一个新的 SDID。此过程会导致发送到Target和Analytics的SDID值不正确，并且您会在Analytics报表中看到重定向拆分不均匀。

Adobe列入允许列表建议您与IT团队联系，以确保adobe_mc_ref和adobe_mc_sdid，以便这两个值不会发生任何形式的转换。

假设一位访客单击了www.google.com上的链接并由此进入您的主页(www.mysite.com/index.html)，而您的主页上有一个重定向活动处于活跃状态，该访客随后又被重定向到一个新页面(www.mysite.com/index2.html)。

以前，新页面上的Analytics请求报告的引荐URL是www.mysite.com/index.html，而不是www.google.com。 这会导致 Analytics 中与引荐 URL 有关的报表（例如营销渠道报表）不准确。这些报表忽略了您是从www.google.com访问网站的事实。

使用at.js版本0.9.6（或更高版本）和AppMeasurement.js 2.1（或更高版本）时，新页面上的Analytics请求报告的引荐URL为www.google.com。