事件跟踪
事件跟踪
本主题概述了在云眼灰度发布（特性标帜）AB实验中有效跟踪事件的最佳做法。
如果可以安装 SDK 并识别用户，则可以使用 云眼 功能实验来跟踪任何事件，从与网页或移动应用程序的特定元素交互的用户到更复杂的指标，例如在后端系统中计算的生命周期价值。
跟踪和衡量用户行为是了解客户如何使用产品以及他们为什么以这种方式使用它的先决条件。如果没有这些信息，判断新灰度发布（特性标帜）规则（如 A/B 测试）的性能或将任何经验教训应用于未来的规则将变得更加困难。将不知道客户正在与产品的哪些特定组件进行交互，并且将没有为未来开发构建以用户为中心的路线图所需的信息。
若要有效地跟踪事件，必须战略性地规划对组织很重要的指标，并确保实施适当的基础结构。这是一个两步过程：
- 确定在何处跟踪技术栈中的指标。
- 检测 SDK 以主动跟踪事件。
本主题概述了该过程的两个步骤的一些最佳做法。
另请参阅选择指标。
使用客户数据平台
我们建议在云眼灰度发布（特性标帜）AB实验中设置事件跟踪时使用细分等客户数据平台。这样做有助于绕过启动和运行功能实验的常见摩擦点，即在整个堆栈中配置和验证 API 调用。
如果没有客户数据平台，开发者可能会遇到双重标记问题。当堆栈包含具有重叠功能的多种技术（例如跟踪转化）时，可能会发生双重标记。除非您从一开始就勤奋和有条理，否则很容易无意中在多个工具中标记相同的事件。
当您自己站点的灰度发布（特性标帜）和功能像这样双重标记时，工程团队通常会继承一定程度的技术债务，这可能需要大量努力才能解决。
通过从一开始就将像区段这样的产品合并到云眼灰度发布（特性标帜）AB实验实现中，并仔细规划策略来尽早定义和标记事件，从而避免这种情况。具体要考虑以下因素：
- 希望解决的特定用例。
- 解决这些用例的可行性。
- 最能帮助执行此操作的指标。
- 将这些指标嵌入现有基础架构的最高效和最有效的方法。
实现
确定要跟踪的事件后，下一个问题是如何最好地在网站上实施云眼灰度发布（特性标帜）AB实验。这涉及调整功能实验 SDK 以满足组织的需求。
需要调整 SDK 的典型云眼灰度发布（特性标帜）AB实验用例包括：
- 应用程序将处理大量事件。
- 通过代理服务器路由。
- 需要实时结果。
具体的实现方法将有所不同，具体取决于这些条件中有多少适用于应用程序。
一次仪器
在许多情况下，SDK 检测可以而且应该在代码本身中完成，而不是在堆栈中进一步完成。由于所有产品都绑定到多系统或面向服务的体系结构中的一个服务中，因此可以在一个位置进行检测。这简化了初始部署以及更新和维护。
如果需要实时结果，这种方法可以工作，但它并不总是处理它的最佳方式。如果需要实时结果，请考虑将信息封装在 API 中。
例如，考虑一个事件票证应用程序。该应用程序包括一个名为 buy_tickets 的模块，该模块由后端的 Java 驱动。在基于队列的模型中，有关用户交互的所有信息都捕获在队列中的槽中。应用程序将实时处理登录，但不一定会对与该登录相关的所有操作执行相同的操作。队列中的事件处理速度取决于事件量和后端处理流量的能力。因此，在提供 A/B 测试结果时可能会有一些滞后。
现在想象一下有1万人同时使用此应用程序。如果应用尝试在站点上的某个位置记录 A/B 测试的成功或失败，则这些结果可能无法在排队模型下实时提供。但是，如果通过云眼实验 API 跟踪这些事件，则结果将立即可用，没有明显的滞后。
如果实时结果对您很重要，请在事件实际发生的位置检测事件。