通过机器学习优化支付

举报
xcc-2022 发表于 2022/06/07 09:17:54 2022/06/07
【摘要】 它可能在某个时候发生在你身上:你去使用一项你认为你已经付费订阅的服务,却发现它因未付款而被取消。这不仅对你这个客户不利:它会导致对品牌的负面情绪,它会破坏业务的稳定收入流,而发现自己被拒之门外的客户可能会决定不回来。在 Dropbox,我们发现将机器学习应用于我们处理客户付款,使我们更好地让订阅者愉快地哼唱。在 Dropbox付款 Dropbox 支付平台可管理数百万客户的支付处理。当客户访...

它可能在某个时候发生在你身上:你去使用一项你认为你已经付费订阅的服务,却发现它因未付款而被取消。这不仅对你这个客户不利:它会导致对品牌的负面情绪,它会破坏业务的稳定收入流,而发现自己被拒之门外的客户可能会决定不回来。

在 Dropbox,我们发现将机器学习应用于我们处理客户付款,使我们更好地让订阅者愉快地哼唱。

在 Dropbox
付款 
Dropbox 支付平台可管理数百万客户的支付处理。当客户访问 Dropbox 网站并选择购买我们的产品时,我们会要求客户在购买表单上输入其付款信息。客户提交表单后,系统会收集他们的付款信息,并将此信息以及我们想要向他们收取的金额安全地发送给处理此类付款信息的外部合作伙伴之一。

当客户开始订阅 Dropbox 时,这一切都会在幕后立即发生。一旦他们完成付款并成为付费客户,他们就会进入我们的付款生命周期。从头到尾,所有这些都由我们的支付平台处理。

订阅续订和失败

拥有 Dropbox 订阅的客户可以定期付费,通常按月或按年付费。在定期付款时,将自动从客户的信用卡中扣款(如果客户已授权我们收取费用)。如果收费成功,则续订订阅,客户无需执行任何操作。

但是,如果尝试失败,客户将输入我们所说的续订失败。发生这种情况时,我们会有恢复过程,这些过程会尝试防止客户的订阅中断。

图 1.非自愿流失是指信用卡过期或被取消,或没有资金等。

从历史上看,我们的支付平台使用了一组大约十种不同的静态方法来确定何时向订阅续订失败的客户收费。例如,我们可能会每四天向客户收取一次费用,直到付款成功为止,最长可达 28 天。如果客户的付款在此时段结束时仍然失败,则其 Dropbox 帐户将降级为免费的基本帐户。

当然,降级对于活跃用户和团队来说是一种糟糕的客户体验。非自愿流失可能会让 Dropbox 失去机会。

图 2.续订尝试

付款失败可能由于多种原因而发生。其中:

  • 资金不足
  • 过期的信用卡
  • 信用卡已停用 - 可能报告丢失或被盗
  • 暂时性处理故障

其中一些故障可以自行解决,而另一些则需要客户操作才能恢复。

为什么使用机器学习进行支付?

在过去的几年中,Dropbox进行了A / B测试,以了解我们向客户收费时的转变是否会对这些费用的成功率产生影响。这些A / B测试在很大程度上依赖于人类的直觉和领域知识,以提出一套何时向客户收费的规则。

支付团队必须根据用户的功能(订阅类型、地理位置等)手动将用户细分为人群,然后A / B测试我们十个左右不同的硬编码规则集,以确定哪些功能最适合这些功能。然后,付款团队会将最佳结算政策选项存储为该总体的默认结算政策选项。他们会定期重新测试,看看不同用户的最佳解决方案是否发生了变化。

从好的方面来说,这种方法证明了充电时间对充电成功率有影响,这使得Dropbox能够让更多的订阅者不间断地嗡嗡作响。但随着时间的推移,这些规则中的大量规则已经衰败并达到了性能上限。此外,手动更新这些规则既复杂又耗时。

为了减少非自愿流失和维护它所需的工作量,Payments团队与应用机器学习团队合作,尝试使用机器学习(ML)来优化计费。

作为ML团队的一员,我知道这个挑战类似于机器学习专家所说的“终极强盗问题”——一个人有一套固定且有限的资源,可以在竞争的替代方案之间分配。对于付款,我们必须确定何时重试,重试次数,以及是否应该尝试重试。

随着时间的推移,我们应用机器学习,发现了多项改进,即使是顶级支付专家团队也无法计算:

  • 消除手动干预和基于规则的复杂逻辑
  • 例如,“每 X 天重试一次”或“避免周末”
  • 针对特定客户群的多个参数进行全局优化
  • 对客户和市场变化的稳健性
  • 支付费用成功率的整体提高和收款时间的缩短

简而言之,将ML应用于支付使客户我们都更快乐。

我们是如何做到的

我们首先专注于预测何时尝试收费,即确定在续订时向客户收费的最佳时间,并在续订失败期间重试向其帐户收费。

我们尝试了不同的客户群,特别是从北美的个人客户和团队开始。我们构建了一个梯度提升排名模型,该模型经过训练,具有支付失败类型、Dropbox 帐户使用模式和支付类型特征等功能。该模型按每个充电时段的预测成功可能性对充电尝试进行排名。

例如,我们采用 8 天的窗口,并将其划分为一小时的区块,总共产生 192 个时间区块。我们使用模型来查找排名最高的时间区块来尝试续订。我们还尝试了6天和4天的窗口期。

起初,我们尝试独立优化每次充电尝试。我们有一个模型,该模型优化了在第一次付款失败后何时向客户收费。如果模型的建议尝试也失败,则在续订时段的其余部分,我们默认返回到基于规则的逻辑。我们对这种组合进行了A / B测试,使用美国各个用户群的随机抽样。对于定位,我们使用了内部功能门控服务 Stormcrow。该模型提高了成功率,我们发布了它。

我们的目标始终是对续订失败尝试进行端到端优化。从单个模型开始有助于验证ML是否可以用于解决此类问题。但是,我们很快意识到,这种每次支付尝试都有单独模型的设计模式只会创建一个更复杂的系统。例如,如果我们在付款成功之前重试5次,使用此设计,我们最终会得到5个模型。这违背了我们使用ML来降低计费系统复杂性的次要目标。

因此,我们改变了方法,使用一个模型来预测何时向客户收取多次费用,直到客户能够成功续订,或者在最大续订窗口期过后降级,如图 2 所示。如果第一次付款失败,我们会要求模型下一个最佳充电时间。如果失败了,我们会再次向模型询问下一个最佳时间,依此类推,最多次数。此时,如果所有付款均未成功,则客户将被降级。但是,如果任何付款成功,则无论进行了多少次付款尝试,相关发票都会获得批准。

这个特定的模型目前正在生产中进行A / B测试,使用我们的Stormcrow系统随机定位Dropbox团队进行测试。到目前为止,结果是积极的。

投放预测
一旦我们训练了模型,我们的下一步就是在支付处理期间使这些模型可用。我们需要一种方法来提供从机器学习模型到支付平台的最佳时间,以确保它们将用作计费策略的一部分。

当我们第一次开始实验时,我们使用支付平台来加载和运行模型。这种设计导致支付平台由于增加了依赖关系而显着膨胀。预测延迟平均持续约两分钟。

为了简化流程,我们利用了由 ML Platform 团队构建和管理的 Predict 服务,该团队负责管理基础架构,以帮助在 Dropbox 快速构建、部署和扩展机器学习流程。使用预测服务有助于将生成模型预测的延迟从几分钟减少到 99% 的 300 毫秒以下。迁移到预测服务还提供了两个系统之间的明确分离,以及轻松扩展的能力。

通过这种即插即用的机器学习系统,支付平台可以获取与客户相关的所有信号,并向模型发出请求(通过Predict Service提供),以获得向客户收费的最佳时间,从而消除了我们经过14年A / B测试开发的所有旧的硬编码次优计费策略。

此系统的工作流设计如下。白色表示支付平台的组件。紫色表示机器学习系统的组件。

  1. 获取下次充电的预测 — 当客户的付款尝试失败时,支付平台会向预测模块发出请求,以获得向客户收费的下一个最佳时间。请求是使用客户 ID 和类型发出的
  2. 检索客户信号。预测模块为客户收集最新的使用和付款信号,以及有关以前故障的信息。此数据使用每日计划的气流作业存储在 Edgestore(Dropbox 的主元数据存储系统)中。
  3. 请求预测 — 收集的信号通过 GRPC 调用发送到预测服务GRPC 调用将信号编码为特征数据帧,然后将其发送到模型。
  4. 生成预测 — 该模型返回何时向客户收费的最佳排名时间。此预测将发送回预测模块,该模块将结果返回到计费策略。
  5. 日志预测结果  预测模块还记录模型的预测,以及可用于故障排除和分析的其他相关信息。
  6. 计划下一次收费 — 一旦付款服务收到最佳收费时间,它就会使用它来计划下一次付款尝试,并将其存储在 Edgestore 中。

机器学习操作

我们的任务在推出时没有完成。我们将 DevOps 最佳实践应用于数据收集和预测系统:我们自动执行数据收集作业以每天运行,并实施监控以通知我们作业运行中的任何故障或延迟。

对于我们的模型和模型服务基础架构,我们定义了一组特定于业务和模型的指标,并设置了警报,以防任何指标低于可接受的阈值。以下是我们用于确保一切按预期运行的主要指标和度量:

业务指标

  • 发票审批率:这是我们想要改进的主要指标。每次用户的 Dropbox 订阅续订时,该特定续订的所有付款都会作为单张发票的一部分进行跟踪。此指标告诉我们用户的续订是否成功。
  • 尝试成功率:此指标可帮助我们跟踪代表用户进行的每次单独付款尝试的成功率。可能进行了一次付款尝试,或者进行了两次、四次或更多次付款尝试。此指标以及发票审批率可帮助我们跟踪续订客户的速度。

模型内部监控
这是培训过程和正在使用的工具内部的一组度量。这有助于我们根据输入数据确定模型的优化情况,并帮助识别模型在生产环境中运行时的任何问题。我们测量以下在线模型指标以帮助进行诊断:

  • 覆盖率:与固定的 4 天间隔相比,从模型中获得建议的客户所占的百分比。
  • 模型所做的预测数:模型成功做出且没有任何错误的建议数
  • 预测延迟:模型提出每个建议所花费的时间

基础设施监控
除了支付平台和预测服务的所有监控和警报外,我们还跟踪以下内容以跟踪我们的基础架构的性能:

  • 要素数据管道的新鲜度和延迟
  • 预测服务的可用性和延迟
  • 边缘存储的可用性

我们使用Grafana仪表板和Vortex来监控我们的模型和基础设施指标。对于业务指标,我们使用超集。所有这些实时指标和仪表板都有助于我们主动跟踪模型的预期行为,使我们能够在模型偏离时采取适当的措施。

监控这些指标的责任由支付工程团队和应用机器学习团队分担。我们有故障排除指南,可帮助随叫随到的工程师通过清晰的升级路径调试任何问题。由于ML是支付工程团队的新手,我们花时间解释系统是如何工作的,以及如何解释模型的结果。这有助于两个团队在项目上成功协作,并确保一切顺利进行。

四. 今后的步骤

我们的实验已经证明,基于 ML 的系统优于我们基于规则的方法。此外,如果没有手动和广泛的投资,基于规则的系统的性能将随着时间的推移而衰减,而ML系统通过重新训练保持敏锐。我们可以通过添加更多相关功能并尝试不同的模型架构来进一步改进模型。

我们针对单个客户的模型目前已部署在生产中。我们用于优化整个续订周期的模型目前正在A / B测试中运行。我们希望将我们的模型优化从北美扩展到全球所有客户。我们还可以试验更复杂的模型类型,包括强化学习,现在我们已经构建了数据和生产管道。随着我们改进模型,我们将专注于进一步提高续订成功率,这也将使客户满意。

我们正在招聘!
Dropbox 的应用机器学习团队和 ML 平台团队使用机器学习 (ML) 通过利用对用户、内容和上下文的高保真理解来推动超大型业务和用户价值。我们与其他产品和工程团队密切合作,提供创新的解决方案和功能。很高兴在 Dropbox 中寻找机会,通过将 ML 应用于新领域来改善我们的流程和客户体验。我们计划继续利用该项目的经验教训,并将其应用于其他领域。

Dropbox 的支付团队通过灵活的支付和收款系统以及流畅的用户体验,实现新产品和现有产品的货币化。我们利用机器学习 (ML) 来优化我们的计费和路由系统。我们还在积极试验基于 ML 的策略,以实现有针对性的支付和计费通信。除了直接影响收入外,这些基于 ML 的方法还可以提高团队的生产力和系统的可维护性。

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。