当前位置: 首页 > news >正文

Motif技术团队:利用行为序列预测模型进行因果推断的案例(二)

译| 路径分析方法论:motifanalytics技术团队的事件序列建模(GLEAM)(一)
Motif技术团队:如何利用路径分析进行因果推断论证的案例(二)


文章目录

  • 0 笔者擅自总结
    • 0.1 亮点一 因果象限图
    • 0.2 motifanalytics的因果发现方法论
    • 0.3 因果效应论证的方法
      • 0.3.1 步骤 1:计算倾向得分
      • 0.3.2 步骤 2:PSM 构建“更公平”的对照组
    • 0.4 局限性
  • 1. 因果图谱象限的分析意义
    • 1.1. 象限 1:确定的因果关系 + 确定的检验结果
    • 1.2. 象限 2:确定的因果关系 + 意外的检验结果
    • 1.3. 象限 3:不确定的因果关系 + 确定的检验结果
  • 2. 发现新原因可促进产品改进
    • 2.1. 阶段 1:发现新的潜在原因
    • 2.2. 阶段 2:生成更多的影响变量
    • 2.3. 阶段 3:运行实验并验证假设
  • 3. 我们如何可靠地发现新原因?
    • 3.1. 方法 #1:EDA比较:分组、聚合
    • 3.2. 方法 #2:行为相关性比较
    • 3.3. 方法 #3:根据先前行为调整的相关性
  • 4. 自动调整事件前行为
  • 5. 自动因果推断的世界
    • 5.1. 实证示例:电子商务活动
  • 6. 扩展到更复杂的假设
  • 7. 验证新的因果发现方法


0 笔者擅自总结

本文来源于文章:Causal discovery for product analytics,笔者觉得吧,他是真能写,但是第一遍看,我硬是看不太懂。。 有点啰啰嗦嗦,裹脚布一样。

笔者简单自己整理一下

0.1 亮点一 因果象限图

是一个比较好的因果技术应用的方法论,适合讲故事用

DAGs

  • 第一类(最简单):原因和结果都清楚。比如,我们改了一个按钮颜色(原因),想看它对点击率(结果)有没有影响。这种用 A/B 测试就能搞定,很简单。
  • 第二类(有点难):原因清楚,但结果不清楚。比如,我们上线了一个新功能(原因),但发现效果不好,想知道“为什么不好?”或者“还影响了哪些我们没想到的地方?”。这时候光看预设的指标就不够了。
  • 第三类(最难,也是文章重点):结果清楚,但原因不清楚。比如,销售额突然下降了(结果),我们想知道“是什么导致了销售额下降?”。作者把这叫做“反向因果问题”。这就像侦探破案,得从结果倒推原因。

大家普遍觉得第一类和第二类问题好解决,但第三类“找原因”的问题,目前还没有特别好的科学方法,很多时候只能靠经验和直觉。

0.2 motifanalytics的因果发现方法论

Hero Story
提出一个理想的“找原因”流程,分三步:

  1. 发现潜在原因:比如,我们发现那些自己上传数据的用户留存率更高,这可能是一个潜在原因。
  2. 根据原因想办法:既然自己上传数据有好处,那我们怎么才能鼓励更多用户上传数据呢?可以优化上传流程,或者在新手引导里强调。
  3. 实验验证:把想到的办法付诸实践,看看是不是真的能让用户更多地上传数据,并且最终提升留存率。

他们提出的GLEAM序列模型,可以基于行为进行下一个行为动作的预测。所以可以预测下一个用户行为可能会有哪些。

0.3 因果效应论证的方法

目前大家常用的方法有:

  • 按用户属性分组:比如,看看哪个国家的用户留存率高。但这能分的维度有限,而且很难说“这个国家的用户留存率高”就是因为“是这个国家的人”这个原因,可能还有其他因素。
  • 看行为相关性:比如,发现使用了某个小功能的用户留存率很高。但问题是,这个相关性是因果关系吗?是不是那些本来就更活跃、更忠诚的用户才去用了那个小功能?
  • 基于GLEAM路径预测:Motif 公司(作者所在的公司)提出了一种更智能的方法,他们用了一个叫 GLEAM 的“基础模型”来分析用户的行为序列数据。这个模型的厉害之处在于:

详细来看一下他们的计量步骤,这里也可以回到:译| 路径分析方法论:motifanalytics技术团队的事件序列建模(GLEAM)(一)
GLEAM 模型本身不直接进行因果论证,它产出的倾向得分是后续进行更可靠因果推断(如匹配、加权等)的关键输入。建模步骤分为三个步骤:

  • 计算倾向得分(Propensity Score Calculation)
  • 构建“更公平”的对照组(Constructing Fairer Control Groups)
  • 实验组与对照组对比得到整体处理效应

开始举例子:

场景:你负责一款新社交 App 的用户增长和体验。App 有一个新用户引导流程,其中包含一个“跳过引导”的按钮。产品经理想知道:用户点击“跳过引导”按钮,是否真的会影响他们在 App 中的长期活跃度(例如,7天留存率)?

0.3.1 步骤 1:计算倾向得分

目标:
对于每个用户,计算他们在看到“跳过引导”按钮时,根据他们之前的行为,有多大可能性会点击这个按钮。

GLEAM 会根据这个用户之前的所有行为序列(这些就是协变量,但 GLEAM 自动处理了它们的复杂性),预测他们点击“跳过”按钮的概率。
这个预测出的概率就是该用户的倾向得分P(点击跳过∣之前行为)P(\text{点击跳过} | \text{之前行为})P(点击跳过之前行为)

每个用户都会有一个倾向得分:

  • 得分高的用户(比如0.8),意味着根据他们之前的行为,他们有很大概率会点击“跳过”。
  • 得分低的用户(比如0.2),意味着他们之前的行为表明他们更倾向于完成引导。

0.3.2 步骤 2:PSM 构建“更公平”的对照组

目标:消除混淆因素的影响,使得“点击跳过”组和“未点击跳过”组在“点击跳过倾向”上是可比的。
这里会有以下的匹配 (Matching)过程:
对于处理组中的每个用户(比如用户 A,倾向得分0.7),我们从对照组中找到一个或多个倾向得分非常相似的用户(比如用户 B,倾向得分0.69),但用户 B 实际没有点击“跳过”。
这样,用户 A 和用户 B 在“点击跳过”的倾向性上是相似的,但一个点击了,一个没点击。我们就认为他们是“可比的”。
通过这种方式,我们为处理组的每个用户找到一个“克隆人”(在倾向性上),从而构建一个“平衡”的对照组。

我们得到了两个在“点击跳过倾向”上大致平衡的用户群体。两个组跳过率的相减就是一种总体效应的估计。
这意味着,如果他们之间还存在7天留存率的差异,那么这个差异更有可能是由“是否点击跳过”这个行为本身造成的,而不是由用户固有的“耐心”或“兴趣”差异造成的。

0.4 局限性

笔者认为这个模型的局限性也非常大。包括:

  • 无法处理未观测到的混淆因素,例如,用户的个人情绪、外部生活事件、竞争对手的突然促销活动、用户在产品之外的社交互动等,如果没有在建模特征中,那么路径预测就存在缺陷。
  • **对行为模式稳定性的假设:**GLEAM 模型是在历史数据上训练的,它学习的是过去的用户行为模式。如果用户行为模式随时间发生显著变化(例如,产品进行了重大改版、市场环境发生了巨大变化、出现了新的竞争对手等),那么模型可能无法准确地预测当前或未来的用户倾向。
  • 对数据质量和完整性要求高,其效果严重依赖于输入的用户行为事件数据的质量、粒度和完整性。如果事件数据稀疏、存在大量缺失值、记录不准确、或者存在严重的噪音,那么模型学习到的用户行为模式将是扭曲的,从而导致倾向得分的计算不准确。
  • 模型的复杂性和可解释性挑战,模型越大计算资源消耗大

当然,不同方法的都有其自己的适用场景,由上述方法展开,看上去是一种仿真的过程,感觉也可以使用【SHAP的升级版:可解释性框架Alibi的相关介绍(一)】反事实手段来分析;或者直接使用SHAP也是可以实现这一效果的。


1. 因果图谱象限的分析意义

两年前,我的观察是,产品分析充满了因果问题,但因果建模和因果推断方法却并不特别流行。自那时起,我们与数百名数据科学家和分析师就他们面临的挑战进行了交流,这些对话进一步使我确信,我们可以在提出和回答分析问题的方式上带来巨大的变革。

今天的文章将介绍我们在实现最初愿景方面所取得的进展:我们如何利用因果推断技术从数据中获取更多信息并做出更好的业务决策? 在 Motif,我们有一些令人兴奋的进展要分享,这些进展利用了 GLEAM,即基于事件序列数据的基础模型。在我们深入探讨解决方案之前,让我先回顾一下我们一直试图解决的问题。

在我之前的文章中,我提出了_因果分析_任务可以根据原因和结果是否已定义(当时我称之为“已知”或“未知”)进行分类。我提出了一个 2x2 框架,现在以有向无环图(DAG)的形式展示:

DAGs

三个“未定义”象限的主要挑战在于,它们需要更新我们的因果 DAG,而不是估计我们已经指定的 DAG 的参数。每个数据团队都应努力提供更完整的产生价值(和负面结果)的过程视图,这意味着随着时间的推移逐渐改进因果模型。

在我们与数据科学家和分析师的讨论中,这个框架在对他们的工作进行分类方面表现良好。我可以在这里粗略地总结我们的发现(跳过象限 4,我认为通过解决象限 2 和 3 来启用):

1.1. 象限 1:确定的因果关系 + 确定的检验结果

分析师的舒适区是左下象限,即原因和结果都被定义的情况。当运行实验时,该任务尤其例行公事,他们可以使用 Eppo 和 Statsig 等 A/B 测试工具。当无法运行实验时,一些数据科学家会求助于较弱的证据或尝试使用因果推断策略,例如综合控制方法。

1.2. 象限 2:确定的因果关系 + 意外的检验结果

我们与之交谈过的许多团队都认为象限 2 是一个痛点。组织经常会遇到测试或发布未能按预期进行的情况,这导致需要进行探索性分析来理解背后的原因。这可能成为一个耗时的项目,因为实验平台通常依赖于一组有限的预配置指标,可能无法涵盖所有可能的感兴趣结果。

Motif 已经在帮助团队进行这类分析。序列比较允许用户以比实验工具更灵活和更广泛的方式调查发布和实验的效果,这通常能产生重要的见解,并加快后续实验的周转时间。

1.3. 象限 3:不确定的因果关系 + 确定的检验结果

笔者:分析师在这个象限可以做的是,多做一些因果关系假设,让因果模型进行真实性判定,哪些因果链是显著的。该象限实操性强

什么驱动了我的关键产品成果?

我们发现解决象限 3 的需求非常强烈。分析师通常将这些任务定义为_寻找改进注册、留存或收入的机会_。他们经常希望产生想法并帮助优先安排产品和工程工作;有时他们则在寻找可以作为成功里程碑的中间指标。无论哪种情况,都没有标准的工具或方法可用。

大多数因果推断方法旨在衡量已假设原因的效果,而不是发现新的原因。2013 年,两位因果推断巨擘 Andrew Gelman 和 Guido Imbens 将这个问题称为“反向因果问题”。在那篇论文中,他们分享了 Kaiser Fung 总结情况的一段精彩引述:

许多现实世界的问题都是反向因果类型,我们对此视而不见令人尴尬……大多数业务问题都是反向因果的……如果销售额突然下降,那么高管们会想知道是什么导致了下降。通过排除法,可以缩小到一小组合理的原因。这都是复杂的工作,只能给出近似的答案。

Kaiser 的例子引入了一个额外的微妙之处——一些反向因果问题是关于什么倾向于导致感兴趣的结果(例如销售额),而另一些则是关于什么导致了该结果中已观察到的特定变化(例如销售额下降)。它们显然是相关的,并且回答任何一个问题都需要一种发现和优先排序因果 DAG 中新原因的方法。

2. 发现新原因可促进产品改进

希望我已经说服你,因果发现是一个有很大改进空间的任务。以下是学习新原因如何带来有影响力的产品变革的英雄故事。它主要分为三个阶段:

Hero Story

2.1. 阶段 1:发现新的潜在原因

在此阶段,我们为我们感兴趣的结果的原因生成并选择一个新的假设。从图形上看,这个原因在 DAG 中是一个新节点,它可能有一个指向我们结果节点的有向边。

示例:在 Motif 的免费版本中,我们提供了示例数据集,但也允许用户在本地(在他们的浏览器中)使用数据,而无需将数据传输给我们。我们观察到,加载自己数据的用户在接下来的一周内更有可能再次使用该产品。这是一个合理的原因,因为直接体验熟悉的数据可能有助于用户更快地了解该工具的价值。然而,也存在一个明显的混淆故事,因为意图更高的用户更有可能克服收集和加载数据的障碍。

2.2. 阶段 2:生成更多的影响变量

在第二阶段,我们发挥想象力,提出可以针对我们已发现的原因进行干预的假设性措施。这是一项创造性工作,因为 DAG 中的节点在当前数据中并不存在;它是我们将构建或重新配置以作用于假设机制的东西。在因果推断术语中,我们可以将这种干预视为一种工具,它作用于我们已识别的原因。

示例:我们集思广益,探讨了如何减少数据加载的摩擦并鼓励用户这样做。出现了各种想法,包括重新设计我们的数据加载表单,以及更改我们的引导对话框以促使用户导入他们自己的数据。我们甚至考虑移除演示数据集作为一种非常强烈的鼓励。

2.3. 阶段 3:运行实验并验证假设

最后阶段是验证我们生成的假设。结果的改进取决于两件事的真实性:

  • 第一阶段:我们开发的产品变更增加了假设原因发生的概率。
  • 第二阶段:假设原因对感兴趣的结果具有实际显著的影响。

这两个阶段反映了估计工具变量模型的步骤,因为这正是我们所处的情境:我们引入了一个外生工具,它通过我们发现的因果变量影响感兴趣的结果。希望该工具足够强大,并且我们在阶段 1 中识别的因果关系也足够强大,能够带来益处。

示例:我们在 Motif 中推出了简化的数据加载功能。数据加载率上升了约 100%,留存率也因此得到改善。(这有点像创造性叙事,我们实际上并没有运行实验,因为我们行动非常迅速!)

Experiment and Validate

3. 我们如何可靠地发现新原因?

如果你同意我在上一节中提出的过程,你可能会想我们如何才能更快、更可靠地实现这个故事。

  • 阶段 2 通常是产品经理、设计师和工程师的职责范围,他们非常擅长开发和实施有用的产品改进。
  • 阶段 3 通过实验得到了很好的解决。有一种可靠的技术可以测试因果假设。在整个行业中,成千上万的数据科学家、分析师、设计师和产品经理已经达成共识,使用实验来评估产品变更并以原则性的方式做出决策。我们对这种方法有着全行业的信念,因为它旨在产生业务价值并解决了团队面临的持续决策问题。

这就给我们留下了阶段 1利用数据改进产品的最大机会是发现并优先排序那些极有可能导致成功产品变更的假设。对于那些投入了大量精力进行丰富埋点和数据质量建设的分析团队来说,将这些数据转化为对其跨职能合作伙伴的价值却缺乏标准方法,这可能令人沮丧。

在实践中,最常见的方法是(模糊的)探索性数据分析(EDA),旨在帮助产生新的见解。事实上,“可操作的见解”被描述为 BI 软件超越其报告功能的特定价值主张,仿佛通过相同的切片、切块和聚合就能完成所需的一切。

实践者需要一个可靠的程序来从数据中生成有用的假设,但在这项任务上没有严谨的科学方法。这导致对因果发现工作的系统性投入不足。探索性项目可能会拖延很长时间,并且在没有强有力结论的情况下结束,因此它们没有获得多少资源。

我们如何才能创建一个生成假设的过程,使其像测试假设的实验一样可靠?

3.1. 方法 #1:EDA比较:分组、聚合

假设生成(以及一般的产品分析)最常见的方法是比较用户在通常易于定义和衡量的属性上的群体。

  • 国家
  • 设备或应用程序
  • 基于注册日期的群组
  • 推荐来源(如搜索、自然流量、广告等)

在大多数 BI 工具中,按(变化缓慢或永不变化的)用户级别属性进行细分很容易创建,并且可以解释感兴趣结果的显著变化。我们可以将这种细分视为估计一个结构模型:

Group by, aggregate

这种方法固有地存在局限性:

  1. 可用于细分的变量数量有限。它们可能不特别丰富,因为它们是不变的用户级别事实。这种类型的模型天花板较低。
  2. 该模型不预测任何有用的反事实。即使我们观察到特定群组的用户更有可能注册高级计划,这也不能直接推断出行动方案。
  3. 估计的关系没有明确的因果关系。例如,我们可以尝试从高绩效国家招募更多用户,但这样做如何扩展以及差异是否会持续下去尚不清楚。

添加时间维度可以增加结构模型的丰富性:

Time dimension

我们有时可以在特定子群体的时间序列数据中发现变化,这表明在特定时间引入了一个原因,这可能是发现原因的合理线索。然而,这种方法可能产生的问题多于答案——我们随后必须调查当时还有什么发生了变化,并形成关于为什么它可能只影响了一组用户的理论。

3.2. 方法 #2:行为相关性比较

类似A/B Test的方法进行比较

通过行为相关性获得洞察的一个很好的例子来自 Amplitude 关于 Calm 应用有价值洞察的案例研究。他们写道:

Calm 构建了一个每日提醒功能,允许用户为其每日冥想课程设置提醒,但该提醒功能深藏在应用设置页面中。很少有用户(不到 1%)发现并使用了提醒。令他们惊讶的是,他们发现设置了每日提醒的用户留存率几乎增加了 3 倍。由于用户样本量如此之小,他们无法确定这是否是因果关系。可能是他们的应用的高级用户(无论如何都会保持高留存率)才是那些深入设置页面并找到提醒功能的人。

这个案例研究非常符合我们的因果发现故事,他们后来解释说他们进行了实验来证实生成的假设。这个故事对于如何发现行为相关性有点模糊,但我们可以想象方法是将用户分为使用某个功能的用户和不使用该功能的用户,并根据一些关键结果(例如留存率)进行比较。结构模型大致如下:

Behavioral correlations

该模型解决了方法 1 中的一个关键限制:假设的原因是事件日志捕获的行为,而不是更持久的用户属性。然而,它也伴随着自身的一系列潜在限制:

  1. 他们是如何决定查看此特定功能的相关性的?许多应用程序都具有相当丰富的功能集,他们是凭直觉行事,还是 Amplitude 从大量假设中主动发现了这一点?
  2. 他们估计的相关性真的是因果效应吗?几乎每个功能的使用都将与留存率相关,那么是什么让这个特定的功能变得特别呢?(巧合的是,在这个案例研究中,相关性结果是无偏的 😉)

在下一节中,我将解释我们如何解决这些限制。

3.3. 方法 #3:根据先前行为调整的相关性

在产品数据中发现行为与结果之间的相关性几乎是必然的,因为以下图表通常是因果结构的良好表示:

Correlations adjusted for prior behaviors

这里未观察到的混杂因素通常会使特征使用与结果之间的估计相关性产生偏差。我们有机会根据用户的早期行为进行调整,这可以减轻偏差。在理想世界中,特征使用前的行为是潜在意图变量的完美度量,在这种情况下,对其进行调整将阻断后门路径并消除偏差。经验丰富的因果推断学生会知道这里还有其他可能的 DAG,包括一个这种调整会_增加_偏差的 DAG,尽管在我们运行的合理模拟中,偏差减少通常远大于放大。

4. 自动调整事件前行为

自动调整相关性并最小化偏差的关键在于译| 路径分析方法论:motifanalytics技术团队的事件序列建模(GLEAM)(一)。
回想一下,这些模型使用与文本生成式 AI 模型相同的自监督目标进行训练。因此,对于我们视为原因的任何事件(或事件模式),模型都可以估计该事件在事件序列中任何位置发生的概率。

Adjusting for pre-event behaviors automatically 1

我们可以使用这个估计来获取“处理”组中的事件,并为其分配处理概率(倾向得分),以及构建一个对照组——在事件序列中处理可能发生但未发生的位置:

Adjusting for pre-event behaviors automatically 2

在一个没有 GLEAM 估计的世界中,我们将有一个处理组,但我们必须使用一组不具代表性的用户作为对照组——那些系统性地不太可能表现出我们感兴趣的原因的用户。
通过平衡倾向得分分布,我们可以显著减少偏差,尽可能地模拟我们干预以阻止某些用户发生原因的思想实验。

通过此过程实现的偏差减少直观地体现在以下图表中:

Adjusting for pre-event behaviors automatically 3

请注意,处理组的估计值不会因此过程而改变。我们正在构建一个更真实的对照组,这将倾向于使他们的估计值更接近处理组。在这种设置中,我们正在针对 ATT(对处理组的平均处理效应)。对于某些处理,我们无法找到足够多的与处理组具有相似倾向得分的用户,在这种情况下,效应估计值方差较大,自然会忽略它们。

5. 自动因果推断的世界

正如我们所见,我们可以使用从 Transformer 架构估计的倾向得分来减少混杂带来的偏差,并且这可以自动完成。假设并非总是现实的,但我们有一个强大的工具,可以非常灵活地(无需特征工程甚至训练新模型)根据先前的事件调整数据。让我们看看在实践中如何利用此功能来生成假设。

5.1. 实证示例:电子商务活动

由于我们无法分享客户数据的结果,我们一直在尝试使用一个简单的电子商务数据集,该数据集作为 2021 SIGIR eCom 数据挑战赛(感谢 Jacopo)共享,这是我们能找到的用于评估这种方法的最佳公共数据集之一。你可以想象一个简单的网店,用户可以搜索或浏览商品,运行搜索,并将他们想购买的商品添加到购物车。

有趣的是,SIGIR 竞赛中包含了一项意图预测任务:模型会显示一个包含添加到购物车事件的会话,并被要求预测该商品是否会在会话结束前被购买。我们可以将我们的因果发现任务视为将此从预测任务转向可解释性任务——我们可以将购买结果归因于哪些事件?
数据科学家习惯于使用类似部分依赖图来展示一个特征如何影响预测,而我们的方法将此概念应用于序列设置。

此图显示了 GLEAM 对每个主要事件的概率得分分布,分为我所说的“事实”和“反事实”情况。

E-commerce activity 1

这些分布之间的差异是混杂因子的来源——事件发生的序列在各个方面都存在差异,我们需要纠正这些差异。我们可以丢弃不重叠的区域,然后通过对控制案例应用权重来平衡这两个分布,使灰色分布与绿色分布匹配。

下面我们看到事件对用户购买概率影响的估计。

E-commerce activity 2

观察以下几点:

  • 在所有情况下,调整都会使效应估计值更加保守。未调整的相关性在幅度上都大于调整后的相关性。pageviewresult_click 事件的效应在调整后接近于零。
  • purchase 效应是固定的,因为如果发生购买,结果被定义为 1。然而,这个估计值有一个有趣的解释——在用户即将购买的时刻,由于对照组有大约 [1 - 0.63 = 0.37] 的购买概率。可以将相关性估计值视为使用大约 10% 的购买概率作为基线。
  • 调整后的估计值往往具有更大的误差(参见更宽的置信区间)。我们进行了偏差-方差权衡,通过调整减少了偏差。如果我们认为调整后的估计值具有严格更小的偏差,因为方差没有那么大,那么结果似乎是有利的。
  • remove 处理的符号在调整后反转——从购物车中移除商品具有很强的正向未调整关联,但在调整后具有负向效应。正向效应有一个明显的混杂故事,如果用户从购物车中移除商品,他们很可能非常接近购买。在这种情况下,负向估计似乎更合理。

总的来说,这些估计似乎具有一定的表面有效性,在某种我们能够促使用户更频繁地发生这些事件(例如通过改变商店设计)的世界中。当然,它们比依赖相关性更有意义且更保守。

6. 扩展到更复杂的假设

下一步是扩展我们考虑的假设数量——撒下一张大网以寻找潜在有用的原因。有多种方法可以增加假设空间的复杂性:

  • 事件序列:我们可以将事件模式(例如,在 SOL 中可以匹配的)定义为处理。例如,“在一小时内使用此功能两次的效果是什么?”
  • 考虑事件的属性:事件通常有许多属性,这些属性可能合理地修改其效果。
  • 上下文效应:处于某些状态(之前使用过其他功能)的用户具有更小/更大的效应。
  • 效应的时间变化:某些事件的效应可能随时间变化,揭示产品变化驱动的潜在变化。
  • 剂量-反应效应:事件的效应可以累积,我们可以估计这些曲线。

无论我们如何定义原因及其上下文,估计其处理效应的机制都是相同的,完全自动化且相对快速。我们可以估计数百或数千个效应并查看它们的分布。

Scaling up

引人注目的是,调整过程倾向于使效应集中在零附近,并且估计值相对较小,这符合我们的先验,即我们大多数假设的处理不会影响结果。还存在一种合理的非对称性——对于像购买这样罕见的结果,不太可能找到能大幅降低概率的处理,但某些处理可以产生强大的积极效应。

应用错误发现率控制程序有助于我们选择可能有趣的效应进行调查。通过将 Benjamini-Yekutieli 应用于估计值的 p 值,我们可以设置一个我们感到满意的错误发现率阈值。在这里,有超过 300 个处理定义,我们将错误发现率设置为 0.1%,并找到 27 个有趣的效应进行后续跟踪。

具有产品及其埋点知识的人工分析师和产品经理形成了人机协作过程,以理解这些估计值。我们发现,通常有少数可以立即被舍弃,因为它们要么显而易见,要么不适合干预。它们可以被逐步过滤掉,留下更多可操作的假设进行后续跟踪。

7. 验证新的因果发现方法

在我两年前的文章中,我写道:

如果你正在阅读这篇文章,并且你和我一样,警钟正在敲响:这一切的“因果关系”何在?

在这篇文章中,我可能已经为那些担心多重比较问题的人敲响了更多的警钟。所以现在有两个重要原因,我们应该预期这种方法会导致偶尔的错误发现:来自我们无法通过调整消除的偏差,以及来自纯粹偶然发现有趣事物的噪声。

我发现强调估计效应以指导决策或政策,与估计效应以生成关于因果关系的新假设之间的区别很重要:

  • 假设检验:我们经历的估计误差表现为在发布什么方面做出错误决策,导致产品变差和用户不满意。
  • 假设生成:我们经历的估计误差表现为不知道如何在我们的产品中关注什么或关注什么,导致产品优先级低下和“猜测与检查”的开发周期。

我的论点是,我们应该将损失函数中的权重从主要关注假阳性转移到关注因果关系的假阴性。换句话说:如果现状是使用人类直觉和相关性来决定什么有助于我们产品的成功,那么我们可能会犯什么样的错误?通过这种方法,我们是否错过了什么,难道不值得看看吗?

Validating a new causal discovery method

对我们的产品持健康科学态度意味着我们在测试想法和产生新想法方面都面临瓶颈。我们在实验常态化方面取得的进展尚未伴随着发现方面的相应创新。但截至今天,Motif 的新因果发现引擎已准备好与我们的客户进行测试,我们很高兴能从您的事件序列数据中学习到什么。

http://www.lryc.cn/news/606453.html

相关文章:

  • 嵌入式第十六课!!!结构体与共用体
  • 【Python修仙编程】(二) Python3灵源初探(9)
  • 7.31IO进程线程——标准IO函数
  • 在window中安装swow体验php协程
  • 【07】大恒相机SDK C#开发 —— 相机IO触发采集与信号输出
  • 2025年IntelliJ IDEA最新下载、安装教程,附详细图文
  • 最新PS 2025安装包下载与安装教程(Adobe Photoshop 2025 )
  • Linux731 shell工具;[]字符
  • imx6ull-驱动开发篇5——新字符设备驱动实验
  • 【MATLAB】(三)数据类型与运算符
  • 在MySQL中DECIMAL 类型的小数位数(Scale)如何影响分组查询?
  • 如何提前识别项目风险?主要方法分享
  • 【MATLAB】(二)基础知识
  • SAML、OpenID、OAuth、LDAP:解码 SSO 协议
  • Table-Render:基于 JSON Schema 的高性能 React 动态表格渲染器
  • 一万字讲解Java中的IO流——包含底层原理
  • 开启云服务器mysql本地连接(is not allowed to connect to this mysql server)
  • java关键字2—this和super
  • 前端ESLint扩展的用法详解
  • 468. 验证IP地址
  • 图论-最短路 Bellman-Ford算法
  • sqli-labs:Less-12关卡详细解析
  • C++(模板,智能指针)
  • 力扣-102. 二叉树的层序遍历
  • 数据治理:数字化时代的 “治” 与 “理” 之道 —— 破解企业数据资产困局
  • 脚手架搭建React项目
  • 解决Python ModuleNotFoundError:使用python -m的妙招
  • Spring MVC体系结构和处理请求控制器
  • 【硬件-笔试面试题】硬件/电子工程师,笔试面试题-52,(知识点:简单一阶低通滤波器的设计,RC滤波电路,截止频率)
  • 【Kubernetes 指南】基础入门——Kubernetes 201(三)