多个 SDK 实现
多个 SDK 实现
本主题介绍使用多个云眼灰度发布(特性标帜)AB实验 SDK 的最佳实践。
在更复杂的代码库中,单个客户交互通常涉及多种服务和语言。例如,也许您想要:
- 使用服务器端 SDK 在后端运行实验,但使用一个或多个客户端 SDK(JavaScript、iOS 或 Android)跟踪转化事件的结果。
- 运行跨以不同语言编写的多个服务的实验,例如,使用微服务架构或从旧堆栈迁移到新堆栈时。
优化为大多数主要语言提供功能实验 SDK。本指南介绍了多种语言的常见用例,演示了如何开始使用多种语言,并解决了一些常见的实现问题。
下载必要的开发工具包变体
如果计划使用多个 SDK,我们强烈建议使用 2018 年 2 月之后发布的 SDK 版本(大多数功能实验 SDK 为 0.4 或更高版本)。这些变体生成具有完整功能管理支持的 v2 数据文件,该文件适用于所有变体 0.<> SDK。
如需帮助为特定实现选择正确的一个或多个 SDK 版本,请联系优化支持。
2.0 之前的项目
📘 注意
Flutter、Swift、React 和 Go SDK 在不同的时间发布,因此它们的变体控制与其他 云眼灰度发布(特性标帜) SDK 不同。
如果现有项目使用的是 2 年 0 月之前发布的 v2018.<> 之前的 SDK 版本,仍然可以跨多种语言使用它们。但是,有一些重要的限制:
- 不能跨全栈和移动项目进行实验。2.0 之前的全栈和移动项目会生成不兼容的数据文件(分别为 v2 和 v3)。
- 不能对现有移动项目使用功能管理。若要将功能管理与 Mobile 配合使用,请安装 2.x 或 3.x SDK,并确定是否需要创建新的云眼灰度发布(特性标帜)AB实验项目。
一致的分桶及其重要性
所有云眼灰度发布(特性标帜)AB实验 SDK 都使用 MurmurHash3 来确定用户是否被分桶到实验中,如果是,他们会收到哪些变体。这基于用户 ID 和实验密钥。分桶代码在所有云眼灰度发布(特性标帜)AB实验 SDK 之间共享。
这意味着分桶是确定性的。将给定用户 ID 入分桶到给定实验中时,将始终获得相同的结果),并且在 SDK 之间保持一致(给定一个通用数据文件,将使用 Python SDK 将用户 ID “abc”分桶到实验“123”中获得与任何其他 SDK 相同的结果)。
此行为是云眼灰度发布(特性标帜)AB实验对多种语言的支持的核心。但是,它依赖于三个假设:
- 必须跨 SDK 使用相同的数据文件。 详细了解如何管理数据文件。
- 跨开发工具包对用户进行分桶时,必须使用相同的用户 ID 和属性。如果所有开发工具包都使用相同的确定性方法来生成用户 ID,则一切就绪。但是,如果使用随机用户 ID,则需要将这些 ID 从服务器传递到任何客户端 SDK。请参阅下面的与客户端 SDK 共享用户 ID 和属性。
- 如果将用户配置文件服务与一个 SDK 一起使用,则必须在所有 SDK 中一致地实现该服务。例如,如果用户配置文件服务是在 iOS 客户端上实现的(这是默认行为),但未在 Ruby 后端实现,并且您更改了正在运行的实验的流量分配,则某些用户在客户端和服务器之间的存储将不一致。为了避免这种情况,您还必须在 Ruby 后端中实现相同的用户配置文件服务。
服务器端实验的“源头”分桶
由于分桶的确定性和一致性,跨开发工具包多次分桶用户可以接受。但是,在跨服务器端和客户端开发工具包进行实验时,开发者可能会发现在服务器端对分桶用户进行分桶以确保一致的体验很有帮助:
- 如果客户端无权访问分桶所需的用户 ID 和/或属性,可以在服务器上分桶用户,然后将所需的决策和数据传递给客户端
- 如果在其他平台上维护许多不同的客户端开发工具包,则可能会减轻整合分桶的实施工作量
与客户端 SDK 共享用户 ID 和属性
同时使用客户端和服务器 SDK 时,可能需要将用户 ID 从服务器传递到客户端,以确保正确跟踪转化事件。开发者可能还希望传递仅在服务器上可用的用户属性,以便用于跟踪转化事件。
虽然没有一刀切的方法,但我们建议使用仅限 HTTPS 的 Cookie(即设置了安全标帜的 Cookie)。处理来自新用户的请求时,服务器会分配用户 ID、分桶用户并运行变体代码(如有必要)。然后,它会在响应中设置一个安全 Cookie,其中包含用户 ID 和任何必要的属性数据。然后,客户端 SDK 读取此 Cookie 以创建在跟踪事件时使用的 云眼UserContext 对象。这种方法可以与JavaScript和iOS / Android SDK一起使用。
与客户端 SDK 共享数据文件
大多数客户发现,只要每个 SDK 实现的缓存过期时间相对较短,数据文件之间偶尔出现短暂的差异就可以了。但是,如果需要确保严格的一致性,则可以在客户端和服务器之间同步数据文件。这允许两者从完全相同的数据文件中实例化 云眼 客户端。这消除了客户端和服务器在不同时间分别从 云眼 CDN 获取数据文件时可能引入的任何不一致风险(例如,如果 CDN 正在从 云眼 应用程序传播更新,就像客户端和服务器分别获取数据文件一样)。
在这种方法中:
- 服务器使用从云眼 cdn 获取的数据文件进行实例化。
- 服务器使用对象的方法检索其数据文件的 JSON 表示形式。例如:
云眼Config``getDatafile
JavaScript
var datafile = eyeofcloudClientInstance.get云眼Config().getDatafile();
- 服务器将数据文件传递给客户端,例如作为呈现的 HTML 页面的一部分。
- 客户端从传递的数据文件实例化。
亲
缺点
- 缓解闪烁情况:如果数据文件内容以内联方式存在于页面源代码中,则客户端实例化不必等到 XHR 提取完成。
- 更好的性能:页面加载期间的请求更少,页面呈现速度更快(第一次有意义的绘制)。
* 必须构建一个服务器端解决方案,用于捕获新的数据文件并将其持久化到客户端。
示例:包含客户端转化跟踪的服务器端变体代码
多种语言最常见的用例是在服务器上执行变体代码并测量这些更改对客户端的影响。让我们通过此用例的基本示例。
🚧 重要
此服务器/客户端用例与安全环境不兼容。有关详细信息,请参阅安全环境。
在我们的示例中,我们有一个 JavaScript 单页应用程序电子商务站点,我们正在 Python 服务器代码中对产品列表的排序算法进行实验。我们想看看这个实验是否会影响用户在我们网站上将商品添加到购物车的频率。我们将使用 Python SDK 来运行实验,并使用 JavaScript SDK 来跟踪转化事件。
以下是入门方法:
- 设置新的云眼灰度发布(特性标帜)AB实验项目。我们将使用我们的 Python 后端将用户分配到变体,因此项目的主要语言应该是 Python。
- 在我们的服务器和客户端上安装和设置必要SDK的最新版本,然后将它们指向我们项目的数据文件。我们将在我们的服务器上安装 Python SDK,并使用 npm 在我们的单页应用程序中安装 JavaScript SDK。
- 创建新实验并创建新的转化事件。我们将基于一个带有两个变体的标帜创建一个实验,并且 .我们还将创建一个事件来跟踪实验的目标。
product_sort``popular_first``featured_first``user_added_to_cart
- 确定我们是否需要从服务器传递用户 ID 和属性。
- 用户 ID:如果服务器和客户端都可以访问实验中每个人的稳定、一致的用户 ID,我们可以将其用作用户 ID。例如,如果我们的实验只影响登录用户,并且客户端和服务器都知道用户在数据库中的唯一 ID,我们可以将其用作在服务器上激活调用和跟踪客户端调用的用户 ID。在任何其他情况下,我们需要从服务器传递用户 ID。
- 用户属性:我们是否要使用转化事件跟踪任何用户属性,以及其中是否有任何属性在客户端上不可用?如果是这样,我们将需要从服务器传递它们。
- 如有必要,将用户标识和/或属性从服务器传递到客户机。请参阅上面的与客户端 SDK 共享用户 ID 和属性。
- 使用传递的用户 ID 和属性创建用户上下文。调用 确定服务器上的该用户以分桶用户并执行变体代码。在此示例中,我们在 Python 服务器上做出决策,并根据返回的变体对产品列表进行排序。
product_sort
- 在客户端上使用跟踪事件来跟踪转化事件。接下来,我们将设置我们的 JavaScript 客户端应用程序,以便在用户每次将商品添加到购物车时跟踪事件。
user_added_to_cart