携程火车票基于因果推断的业务实践

开发 新闻
本文将以携程火车票业务中存在的现实问题为例进行展开,介绍一些携程火车票在因果推断这块的相关工作。

作者简介

Seven,数据分析师,专注用户增长、数据科学等领域。

一、背景

携程作为旅游平台,跟用户需求息息相关,理解和识别各个策略/系统对转化/收益的因果关系尤为重要,在这个过程中需要将影响因变量的其他因素进行控制,但这些因素通常是复杂且难以测量的。在关系识别困难的情况下,如何使用更为科学的方法,对策略进行微观和宏观的建模分析,如何系统性的评估各种策略的长期影响,是要解决的重要问题。

在火车票 BG 我们现阶段已经遇到的需要探究因果的问题有五类:产品功能迭代评估、虚拟产品价值评估、精准营销和运营、无 AB 实验增量效果评估、外部环境变化影响评估。

遇到这些问题我们通常有几种方式来解决: 

  • 在产品设计上构建正确的 AB 实验,合理计算指标,度量产品功能和迭代的影响;
  • 基于观测数据的因果推断,即从已有实验和非实验数据中提炼因果关系;
  • 通过机器学习算法和数据、实验的结合构造反事实推理来回答长期效应问题。 

以上三种方式的核心思想是因果推断。

本文将以携程火车票业务中存在的现实问题为例进行展开,介绍一些携程火车票在因果推断这块的相关工作,主要内容包括:首先,介绍因果推断理论的基本思想和理论框架,让大家从宏观上了解因果推断工具有哪些;其次,讲解我们尝试用因果推断的方法/工具去解决业务核心问题的案例,主要有以下三个较为具体的场景:

  • 用户运营场景中遇到的因果推断问题;
  • 虚拟价值评估场景中的因果推断具体案例;
  • 其他无法做 AB 实验的场景的效果评估。

最后,通过实践我们相应的沉淀了一些工具使用的框架。

二、因果推断的基本思想和理论框架

2.1 基本思想

因果关系首先要区别于我们日常生活中非常常见的相关关系。比如:我们发现医院外面的人比医院里面的人更加健康,这个可以说明“医院与身体健康程度存在相关性”,但可以说“医院是导致身体不健康的原因吗?”,显然是不能的。即只要 A 和 B 经常同时发生,那么说明 A 和 B 存在相关关系,而不能说明 A 和 B 一定存在因果关系。因果性强调的是 A 导致了 B 的发生,因此存在因果性一定存在相关性,反之则不成立(如图 2-1)。

因此,因果推断的核心是在数据中存在关联关系的前提下,考虑数据之间的因果关系。即将因果关系从关联中分割,对因果分析的大小作出正确的估计。

图片图片

图2-1  相关和因果关系

2.2 理论框架

在因果推断中,有以下两种框架:

Rubin 虚拟事实模型(Potential Outcome)的核心是寻找合适的对照组。通常情况下,我们想要度量用户在被实验影响和不被实验影响这两种情况下结果差异是多少,而对于同一个用户,我们只能观测到被影响/不被影响一个状态,因此需要寻找合适的对照组,估计和衡量无法被观测到的影响。我们通常会构造一些识别实验,比如,互联网常使用 AB 实验,或者根据观测数据使用恰当的方法来寻找对照组。针对观测数据,这里分为两种思想:

  • 构造相似群体(Matching):这种思路假设在未被实验策略影响的样本中存在一些样本与被实验策略影响的样本具有同质性。只要我们想办法找到这些相似的样本作为虚拟对照组,就可以控制外生因素。这种思想最经典的方法是倾向得分匹配法(PSM)。
  • 构造虚拟现实(Synthetic Control):这种思路认为策略的影响其实是策略上了之后的指标表现和“假设策略没上”的平行时空中指标表现的差值。因此,只要通过建模方法构建出假设策略没上的虚拟时空的指标水平,即可评估实验策略收益。典型的方法包括合成控制法(SCM)、Causal Impact。

Pearl 因果图模型(Causal Graph Model)使用有向图描述变量之间的因果关系。通过计算因果图中的条件分布,获得变量之间的因果关系。有向图指导我们使用这些条件分布来消除估计偏差,其核心也是估计检验分布、消除其他变量带来的偏差。

以上两种因果框架是两种互补的推测虚拟事实的方法,目的都是为了计算存在混淆变量时,干预变量时对结果的影响,都需要对因果关系作假设,以及控制带来偏差的变量,不同点在于 Rubin 框架估计的因果效应主要是干预前后的期望差值,而 Pearl 框架下,我们估计的是干预前后的分布差异,Rubin 框架解决的问题是因果效应的估计和统计推断,Pearl 框架更偏向于因果关系的识别。图 2-2 展示了两种框架的一些常见的主要使用方法。

图片

图2-2  因果推断工具箱

三、实践案例

随着业务的发展,对因果关系的探究和准确评估愈发受到重视,越来越多的业务场景和评估问题需要通过因果推断理论去优化和解决,比如如何降低营销成本,如何科学评估会员价值等等。基于这些问题,我们对因果推断理论进行了探索研究,并最终在多个关键的业务问题上落地实践,成功解决了现存的问题。

3.1 用户运营场景 — UPLIFT 模型

  • 模型介绍:寻找策略敏感人群,寻找策略敏感人群,策略敏感人群是指能够针对某个干预做出反应的人群,即图 3-1 右上角这类用户。

图片

图3-1  UPLIFT模型示意图

  • 业务背景:现阶段用户运营体量较大,短信是需要成本的,利用 UPLIFT 模型寻找短信敏感人群,在精细化策略运营的基础上帮助运营人员节省成本,进一步提高运营 ROI。
  • 模型应用

建模方式:S-Learner、T-Learner、X-Learner 等等。

评估方法:QINI 曲线等。

  • 应用结果:已在多个策略下进行了测试并上线了运营平台,取模型分前 10%,带来增量:人数 *10%*0.011,如图 3-2。

图片

图3-2  UPLIFT模型结果展示

3.2 虚拟价值评估场景 — 倾向性得分匹配

  • 模型介绍:通过计算倾向性得分从观测数据中找到相似的人群,即在未干预人群中找到与干预人群相似的人,如图 3-3。

图片图片

图3-3  PSM思想示意图 

  • 业务背景用户增长业务存在一些业务板块是虚拟形态,比如企业微信、公众号、会员等,业务方希望评估下这些虚拟形态带来的增量价值,从而指导成本投入。
  • 口径迭代

A. 口径1.0

实验组:企业微信环境下用户。

对照组:大盘且不在企业微信环境下的用户。

结论:在企业微信环境的用户比不在企业微信环境用户价值高 xx%。

事实上,这个结论肯定是错误的。因为在企业微信环境和不在企业微信环境这两组用户本身就不平衡,因为一般来说,能够主动/被引导愿意进入企业微信环境的用户都是相对更加忠实/活跃的用户。即存在很严重的样本自选择问题,得到的结论是带有混淆偏差的。

B. 口径2.0:严格逻辑控制,控制首单时间、用户类型和关注时间等相同,如图 3-4。

实验组:首单时间在 2020.1-2020.7 活跃用户 & 在 2020.7-2020.12 关注公众号。

对照组:首单时间在 2020.1-2020.7 活跃用户,至今未关注公众号。

图片

图3-4  口径2.0展示

相比于原始口径相对准确,但是在严格逻辑控制下,用户量大幅缩小,无法准确测量所有公众号环境内用户的增量价值。

C. 口径3.0:PSM 模型寻找相似人群,如图 3-5。

实验组:加入企业微信环境且留存达到 180 天的用户。

对照组:用户加入企业微信环境当日,无放回的用 PSM 在大盘人群中匹配与之相似的用户放入对照组。

图片

图3-5  解决问题思路图

  • 结果展示:如图 3-6 所示,左上角图中展示的是实验组和对照组原始的倾向性得分,右下角图为实验组和对照组匹配之后的人群得分,可以看出,从两组中挑选出来的人群倾向性得分匹配程度较高,即我们认为两组人群同质性较强。从左下角的图中也可以看出来在匹配之前和匹配之后,匹配前人群差异非常大,匹配人群间的方差都控制在一个合理的范围内。

图片

图3-6  PSM模型结果图

3.3 实验设计场景 — 合成控制法(SCM)

  • 模型介绍:例如我们在 A 城市施加干预/政策,且无法找到 A 城市的最佳对照地区,就可以使用合成控制法对若干大城市进行适当的线性组合,以构造一个与 A 市非常相似的“合成 A 市”,并将“真实 A 市”与“合成 A 市”进行对比。
  • 业务背景:酒店产品想通过AB实验探索用户价格弹性,即调整定价时,看转化率变化情况,为了在不进行违规操作的前提下能够得到相对科学的结论来支持决策,我们使用合成控制(SCM)的方法寻找合理的对照组:通过寻找可对比的省份作为调价前后对比评估的控制组,从而合成与实验组省份数据特征相似的虚拟控制组。
  • 方案详情

实验组:A市。

对照组:A虚拟组(B *0.584+ C *0.223+ D *0.183+ E *0.01)。

(拟合情况如图 3-7 可以看出来实验组和对照组拟合情况较好)。

  • 数据指标:总转化 cr(提交酒店 uv/ 列表页 uv)。

图片图片

图3-7  SCM 模型结果图

3.4 政策干预场景 — 断点回归(RDD)

  • 模型介绍:用干预临界点前后很近的观测数据构造实验组和对照组。
  • 业务背景:公众号每周四会发推文,推文提醒方式从强提醒改为了弱提醒,评估其对公众号触达转化率的影响。
  • 数据处理

中心化:对关注时间进行了中心化,使得临界点为 0,并以距离临界点的小时数作为相对关注时间。

数据分组:用户根据关注时间排序并分组,每组约 100 人,取平均相对关注时间。

关键指标:

a, 干预变量 D:提醒方式(0:强提醒,1:弱提醒)。

b. 结果变量 Y:3 日支付转化率、7 天支付转化率。

c. 配置变量 X :每组平均相对关注时间。

  • 方案设计

取助力来的关注公众号用户,如图 3-8 所示。

实验组:改版前最后一个周四,前三天新关公众号用户。

对照组:改版后第一个周四,前三天新关公众号用户。

图片

图3-8  断点回归思路图

  • 数据拟合

强提醒变为弱提醒使触达 3 天转化率和 7 天转化率都有显著降低(P 值小于 0.01),如图 3-9。

图片

图3-9  断点回归结果图

四、因果推断使用总结

4.1 因果推断使用

因果推断分为两个部分:因果识别(发现)和因果效应估计。

  • WHEN:当无法设计完美随机实验的时候,从观察性的数据中去(拟合随机试验)测算因果效应。
  • WHAT:本质是剥离我们所不关心的外部变量对结果的影响,从而精准估计到我们所关心的策略因素对结果的单一影响。
  • HOW:评估方法的选择本质上可以总结为:使用场景识别选择合适的因果推断方法,并使用合适的方法结合业务真实数据来解决问题。

4.2 使用场景识别

通过实践总结,因果推断方法常见的使用场景有以下四种(如图4-1):

1)场景一:非实验场景策略效果评估

  • 问题判别:评估计算的是群体效应(ATE)、无法进行 AB 实验。
  • 核心思想:人为创造一个虚拟对照组与策略上线数据做比较估计策略真实效果。
  • 使用方法:PSM\SCM\Casual Impact\DID。
  • 常见场景:

a. 北京市新建立了一个机场,对我们的订单的影响。

b. 微信公众号突然更改提醒方式,对我们用户触达转化率的影响。

c. 研究政策影响方面:例如某地区通过法律将最低工资每小时 4.25 美元提高到 5.05 美元,相邻的某地区保持不变,是否会提高就业人数。

2)场景二:实验场景下的正向用户下探

  • 问题判别:探究干预(策略)对于不同用户的异质效应(又叫 HTE),指的是哪些细分用户对策略更敏感更容易被影响以及影响有多少,更好的归因和理解不同的用户群,传统做法是多维分析,效率低,容易犯错。
  • 核心思想:对某个干预敏感度最大的一批人。
  • 使用方法:因果树/因果森林。
  • 常见场景:通常情况下,是结合实验来做分析的。

a. 实验中挑选出来那些实验效果显著的用户,去分析他们的特征,找到敏感用户,帮助我们做下一步的迭代。

b. 某业务做了产品优化实验,但实验各项消费数据表现较差,以 APP 平均使用时长为例,我们想找到一些群体的消费者,拥有正向的实验收益。

3)场景三:策略敏感人群探究

  • 问题判别:找到真正的干预(策略)敏感人群,将预算/资源投入到这批人群。
  • 核心思想:对期望结果(如下单转化等)进行归因,寻找由于某个干预而引发期望结果的人群。
  • 使用方法:Uplift Model。
  • 常见场景:用户营销场景,节省成本、提升 ROI。

a. 现在公司有一批预算,可以给用户发送优惠券提升用户购买率,应该发给平台的哪些用户。

4)场景四:因果影响指标分析

  • 问题判别:分析某个或者多个指标对结果的影响程度或者寻找对结果有因果影响的因素以及评估影响程度。
  • 核心思想:基于历史观测数据进行因果建模,解决多重共线性问题和自变量和因变量的非线性问题。因果推断经常会遇到混淆变量的问题,比如我们想要去分析直播推荐多样性(指标 D)对用户活跃度(指标Y)的影响,但此时存在很多变量 X 既与 D 相关又与 Y 相关。解决这类问题传统的方法是用 X 对 Y 做线性回归,X 的参数就是影响效应,或者是上 XGboost 看 Shap 值等。但传统的方法会依赖很多强假设例如不能多重共线性等,强假设下得到的估计不一定合理。所以这种场景下传统的指标影响分析方法将不满足业务需求,双重机器学习(Double Machine Learning)可以提供思路。
  • 常见场景:

a. 估计冰淇淋价格与其销量之间的因果效应。

b. 安装抖音对快手使用时长的影响。

c. 探索哪些潜在的用户行为或者哪些内容对用户活跃度有正向因果影响,且衡量因果效应都是多少。

图片

图4-1  因果推断通用框架

责任编辑:张燕妮 来源: 携程技术
相关推荐

2023-07-07 14:18:57

携程实践

2022-09-09 15:49:03

携程火车票组件化管理优化

2023-09-15 09:34:54

2023-10-20 09:17:08

携程实践

2023-06-28 10:10:31

携程技术

2023-05-12 09:58:05

编译优化

2023-06-09 09:54:36

携程工具

2011-01-24 15:37:32

火车票

2024-01-30 08:55:24

2012-01-05 13:14:42

火车票

2016-08-31 13:26:24

PythonPython3工具

2011-01-28 15:48:11

Chrome插件Page Monito火车票

2018-01-10 22:19:44

2018-12-29 16:24:58

Python12306火车票

2012-11-15 09:40:18

2015-03-18 15:05:12

12306验证码

2022-04-27 13:36:18

12306铁路12306

2018-01-02 09:56:04

Python12306火车票

2013-01-07 17:34:47

火车票抢票浏览器

2019-01-23 16:20:30

Python火车票程序员
点赞
收藏

51CTO技术栈公众号