mcpField
C
configuring-experiment-rollout

configuring-experiment-rollout

github.com/posthog数据与数据库95377 次安装今天更新
代码仓库

关于 configuring-experiment-rollout

这是一个用于配置 PostHog 实验发布范围和变体分配的技能。它说明变体比例与整体发布范围的区别,并介绍影响分析偏差和用户分配的设置。

主要功能

  1. 01配置变体比例与整体发布范围
  2. 02说明两种发布控制如何相互作用
  3. 03处理不均等分配带来的偏差
  4. 04澄清含糊的发布比例请求
  5. 05选择用户 ID 或设备 ID 分桶
  6. 06配置跨登录持久性

适用场景

  1. 01限制进入实验的用户比例
  2. 02设置均等或不均等的变体分配
  3. 03规划运行中实验的发布变更
  4. 04创建标记前选择分桶方式

MCP 相关

它介绍 PostHog 实验和功能标记工作流,包括 create-feature-flag 与 experiment-create。

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/posthog/ai-plugin --skill configuring-experiment-rollout

安装后在 Claude Code 中输入/configuring-experiment-rollout确认已加载。

附带文件references/changing-distribution-after-launch.md

详细介绍

配置实验的发布比例

此技能回答的问题是:谁会看到哪个变体?

推荐做法:均匀分流 + 调整发布比例

在大多数情况下,实验采用均匀分流效果最佳。如果想限制测试变体的曝光,请改为调整发布比例。

均匀分流更好的原因:

  • 均匀分流可最大限度地提高统计功效——每个变体的样本量相同
  • 均匀分流可平衡流量,从而更快达到显著性
  • 在实验过程中逐步提高发布比例,以增加用户曝光,是一种稳妥的做法(在实验中途更改分流可能导致用户切换变体,从而影响用户体验和数据质量)

除非用户明确提出其他要求,否则始终默认采用均匀分流。

何时需要不均匀分流

不均匀分流结合默认的“从分析中排除”处理方式,可能会引入偏差。 如果实验观察到多变体用户(接触过多个变体的用户),这些用户就会被不对称地剔除——较小变体会损失更大比例的分配。如果这些用户的行为与其他用户不同,较小变体的指标就会产生偏差。

合适的缓解措施取决于实验状态:

  1. 发布前,或实验已运行但目前曝光量较少——采用均匀分流并降低整体发布比例。 这样既能达到相同的测试变体曝光量,又不会产生偏差,并且能保留统计功效。请参阅下方的消歧问题。
  2. 已运行且曝光量较大的实验——将多变体处理方式切换为“首次看到的变体”。 在运行过程中更改分流会将用户重新分配到不同变体(反模式;请参阅下方的“更改运行中实验的发布比例”)。改为切换处理方式则能让每个人保留在原始变体中,并避免不对称排除。如何设置,请参阅 configuring-experiment-analytics。请注意,“首次看到”处理方式可能会引入其他偏差,但优于在运行过程中重新分配。

两种发布比例控制项

有两个独立的控制项决定谁会看到什么。 它们都位于关联的功能标志中,通过功能标志自身格式的 feature_flag 对象传递(而非已弃用的 parameters 键)。

1. 变体分流(feature_flag.filters.multivariate.variants)

实验内部的用户如何分配到各个变体。

  • 由 {key, name, rollout_percentage} 组成的数组,其中 rollout_percentage 的值之和必须为 100
  • 至少 2 个变体,最多 20 个
  • 不要求特定的变体键——如果存在键为 "control" 的变体,分析基线默认为该变体;否则默认为第一个变体
  • 默认值:control 50% / test 50%

如果用户说“A/B/C 测试”但未指定键,则将基线的键设为 "control"(惯例),并为其他变体创建额外的键;如果用户指定了具体的键,则按原样使用,并将基线放在最前面。

2. 整体发布比例(feature_flag.filters.groups[0].rollout_percentage)

所有用户中有多少比例会进入实验,通过单个发布组传递:groups: [{ "properties": [], "rollout_percentage": N }]。 默认值:100%。

未被纳入的用户会被完全排除:他们看不到任何变体,也不属于分析范围。

这些参数的传递位置

这两个控制项都位于 feature_flag.filters 中:

{
  "feature_flag": {
    "filters": {
      "multivariate": {
        "variants": [
          { "key": "control", "name": "Control", "rollout_percentage": 50 },
          { "key": "test", "name": "Test", "rollout_percentage": 50 }
        ]
      },
      "groups": [{ "properties": [], "rollout_percentage": 100 }]
    }
  }
}

filters 还可以包含 aggregation_group_type_index(用于在某种群组类型而非单个用户上运行实验)和 payloads(以变体键为键的 JSON 编码字符串)。 对于运行中的实验,任何功能标志配置更改都必须同时传递 update_feature_flag_params: true,否则 API 会在更新到达功能标志之前拒绝该请求(请参阅“更改运行中实验的发布比例”)。

它们如何相互作用

这两个控件会相乘:

总体投放比例变体分流比例看到测试变体的比例纳入分析的比例
100%50/5050%100%
100%75/25 对照组/测试组25%100%
50%50/5025%50%
25%50/5012.5%25%

消除歧义的问题

重要:如果用户要求不均衡的变体分流比例(例如“60/40”“70/20/10”),或提到一个可能指变体分流比例也可能指投放比例的具体百分比(例如“投放给 25% 的用户”),你必须先进行澄清再继续。以下两种情况均适用:

情况 1:单个百分比(“25%”“投放给 40% 的用户”)

百分比含义模糊——它可能指变体分流比例,也可能指投放比例的变化。请询问:

有两种方法可以让 25% 的用户看到测试变体:

  1. 降低投放比例并均等分流(推荐):降低总体投放比例,并对变体进行均等分流。只有部分用户会进入实验,而其中每个变体获得相同的份额。 均等分流可最大限度地提高统计功效并避免偏差。
  2. 不对称分流:保持 100% 的投放比例,但只让 25% 的用户进入测试变体。 所有用户都会进入实验,但不均衡的分流会降低较小变体的统计功效,并带来偏差风险。

你更倾向于哪种方法?

根据用户要求的百分比调整数字。

情况 2:不均衡比例(“60/40”“70/30”“80/20”等)

该比例看起来是明确的变体分流比例,但几乎总是更推荐降低投放比例并进行均等分流。请说明其中的权衡,并推荐替代方案:

不均衡的变体分流可行,但建议采用均等分流并降低投放比例:

  1. 均等分流 + 降低投放比例(推荐):降低总体投放比例,让相同比例的用户看到测试变体,同时在实验中对变体进行均等分流。 均等分流可最大限度地提高统计功效,并避免不对称的多变量排除所造成的偏差。
  2. 不均衡分流。 可实现相同的用户侧效果,但会降低较小变体的统计功效,并带来偏差风险。

你想采用均等分流方案,还是有特定原因需要使用不均衡分流?

根据该比例调整数字。对于包含两个以上变体的实验,“均等”是指每个变体获得相同份额(例如,三个变体时为 34/33/33)。如果用户在了解权衡后确认仍要使用不均衡分流,请继续操作——但不得跳过下一节。

用户选择不均衡分流后

如果用户选择不均衡分流(以上任一情况中的选项 2),在创建或更新实验之前,你必须说明其对多变量处理方式的影响。用户选择了风险更高的投放方案,因此需要在了解情况后做出如何降低风险的选择。

请询问:

还有一点——使用不均衡分流时,默认的“从分析中排除”处理方式会不对称地排除接触过多个变体的用户。较小的变体会有更大比例的分配被排除;如果这些用户的行为与其他用户不同,其指标可能会出现偏差。

有两种选择:

  1. 将多变量处理方式切换为“使用首次看到的变体”(对于不均衡分流推荐)——将所有用户保留在分析中,并避免不对称排除。此方式也有自身的注意事项(可能会出现其他偏差),但对于不均衡分流而言,优于默认方式。
  2. 保留默认的“排除”处理方式,并接受偏差风险。

你想选择哪一种?

有关如何设置多变量处理方式,请参阅 configuring-experiment-analytics。在同一次操作(创建或更新)中应用该选择——在未获得用户明确知情后的决定前,不要让实验在默认处理方式下采用不均衡分流。

登录前后的分桶和持久化

默认情况下,用户的变体由其 distinct ID 决定。同一用户在识别前后(通常是在登录时)看到标志时,其 distinct ID 会发生变化,变体也可能随之变化。 请在创建标志或实验之前做出选择;切勿更改正在生效的标志的分桶或持久化设置。

页面上匿名访客的占比不能说明问题。这反映的是页面上的构成,而不是同一个人是否会在此处完成身份识别;这是两个不同的问题:即使占比均衡,也可能是两个互不相遇的群体;即使页面上的访客几乎都已识别,也仍可能每个人都先经过一个匿名的首次页面浏览。 因此,请说明以下三个选项及各自的要求,并让用户选择:

  • 按用户 ID 分桶(默认):不传入 ensure_experience_continuity,这样会应用团队的持久化默认设置,但以下两种情况除外。
  • 按设备 ID 分桶(配方见下文):每次调用标志时都需要设备 ID,因为没有设备 ID 的调用不会获得变体。服务端 SDK 必须转发浏览器的设备 ID,这样本地评估才能正常工作。web SDK 从 posthog-js 1.307.1 开始会在标志请求中发送设备 ID;请检查版本,因为旧版本会在事件中携带设备 ID,但不会在标志请求中携带。标志服务会使用任何发送设备 ID 的 SDK 提供的设备 ID,因此请检查设备 ID 占比,而不是平台。这些占比统计的是事件,而不是标志请求,因此占比接近 0 时,应视为尚未确认此选项可用,而不是判定不可用。
  • 持久化(ensure_experience_continuity: true):如果 SDK 在本地评估标志,则无法使用,因为本地评估不会查询覆盖存储。此外,还需要为匿名用户创建用户档案、不使用引导数据,并在服务端标志调用中传入 $anon_distinct_id。了解详情:https://posthog.com/docs/feature-flags/creating-feature-flags#persisting-feature-flags-across-authentication-steps

省略 ensure_experience_continuity 时,experiment-create 会应用团队的持久化默认设置。设备 ID 配方无需此步骤:除非设置持久化,否则 create-feature-flag 会将其关闭;而 experiment-create 会拒绝已存在标志对应的 feature_flag 对象。按设备 ID 分桶与持久化不能同时使用,API 会拒绝这两个设置的组合。

有两种情况需要设置此字段,而不是省略:

  • 将 experiment-create 已创建的标志改为按设备 ID 分桶。该标志会沿用团队的持久化默认设置,因此必须在同一次调用中传入 ensure_experience_continuity: false,否则会被上述限制拒绝。
  • 团队的持久化默认设置为开启,且 SDK 在本地评估标志。此时标志会继承一个在该环境下无法生效的持久化设置。请告知用户;只有用户提出要求时才将此字段设为 false,因为这是团队选择的默认设置。
按设备 ID 分桶的配方

experiment-create 无法设置分桶,因此请先创建标志,再将其关联:

  1. 使用实验的 key 调用 create-feature-flag,设置 bucketing_identifier: "device_id" 和 active: false,这样在发布前不会有人获得变体(新标志默认处于启用状态):

    {
      "key": "kebab-case-key",
      "name": "Experiment name",
      "active": false,
      "bucketing_identifier": "device_id",
      "filters": {
        "groups": [{ "properties": [], "rollout_percentage": 100 }],
        "multivariate": {
          "variants": [
            { "key": "control", "rollout_percentage": 50 },
            { "key": "test", "rollout_percentage": 50 }
          ]
        }
      }
    }
    

    必须设置 filters.groups:没有分组的标志会被拒绝。

  2. 使用该标志的 feature_flag_key 调用 experiment-create,且不传入 feature_flag 对象。实验会按原样关联该标志,发布实验时会启用该标志。

experiment-setup-context 会报告这些规则所需的信息(页面上未识别访客的占比,以及各 SDK 的设备 ID 占比和本地评估占比)。creating-experiments(references/setup-decisions.md)会据此执行规则。

定位实验

更改发布比例需要实验 ID。如果用户通过名称或描述提及某个实验(例如“更改我的注册测试的发布比例”),请加载 finding-experiments 技能,在继续操作前将其解析为具体 ID。

更改运行中实验的流量分配

更改运行中实验的流量分配或变体比例会同时影响用户体验和统计有效性。 在进行更改之前,必须警告用户并获得明确确认。

不要静默应用更改——即使用户直接提出了要求。

请从以下两个角度说明警告:

  1. 哪些用户会看到哪个变体?——用户会切换变体或失去某项功能吗?
  2. 哪些用户会纳入分析?——这会如何影响数据质量?

例外:提高流量分配(不更改变体比例)通常是安全的——不会有用户切换变体,只会干净地纳入更多用户。

如果目标是“阻止新用户加入”,而不是更改百分比:降低流量分配并非正确做法——这也会让已加入实验的用户退出实验。 冻结曝光(experiment-freeze-exposure)会关闭用户加入入口,同时让已加入的用户保留其变体,并继续收集指标;其前提条件和限制请参阅 managing-experiment-lifecycle。

实验中途修复比例不均导致的偏差:对于已启动的实验,建议将多变量处理方式从“排除”切换为“首次看到的变体”——不会有用户切换变体,且所有已收集的数据都会保留在分析中。实验运行中途更改比例使其均等是一种反模式(通常需要重置或结束实验),仅当实验尚未覆盖太多用户时才是更好的选择。如何更改处理方式,请参阅 configuring-experiment-analytics。

有关详细警告、如何告知用户以及何时建议替代方案,请参阅 references/changing-distribution-after-launch.md。

相关技能

  • configuring-experiment-analytics——分析相关内容:曝光标准、指标和多变量处理方式
  • diagnosing-experiment-health——实验中途更改比例已导致结果偏斜时使用
  • managing-experiment-lifecycle——更改比例需要重置或结束并重新启动时,了解相关操作

评论

支持 Markdown