用于对代扣服务的用户进行维护的方法和系统与流程

1.本公开涉及对服务用户进行维护，尤其是自动代扣服务的用户的维护。


背景技术：

2.随着数字技术、网络技术、人工智能技术等蓬勃发展，各种服务层出不穷。例如，已经存在各种自动代扣型服务，诸如手机话费代扣、水电煤代扣、会员费代扣、信用卡自动还款、保险产品的自动续期续保，等等。
3.目前，用户可能偶尔因为某些原因没有完成特定操作或满足特定要求而被相应的服务清退。例如，对于自动代扣服务，如果用户在某一期代扣失败(例如，由于账户余额不足等，经过连续多次代扣调度后仍然代扣失败)，则会被清退；清退后的用户将无法继续享受该服务。这样，如果用户在不知情前提下被清退，则会对用户造成不便(例如，用户可能需要重新申请服务)或伤害用户利益(例如，失去与代扣服务相关联的各种服务，诸如手机停机等等)。
4.本公开针对但不限于上述诸多因素进行了改进。


技术实现要素：

5.根据本公开的第一方面，提供了一种用于对代扣服务的用户进行维护的方法，所述方法包括：确定在代扣周期内为所述用户执行的代扣操作因用户账户金额不足而失败；使用留存率模型来为所述用户打分，其中所述留存率模型是用户在下一代扣周期内代扣成功的概率的模型；在所述打分高于预定阈值的情况下，向所述用户提供补助以使代扣成功；以及在所述打分低于预定阈值的情况下，清退所述用户而不再为其执行所述代扣服务。
6.根据一实施例，所述留存率模型是通过如下步骤来获得的：确定在代扣周期内所述代扣服务因账户余额不足而未能代扣成功的所有用户；向这些用户提供补助以使代扣成功；在下一代扣周期内确定这些用户是否代扣成功；针对这些用户中的在该下一代扣周期内代扣成功的用户来收集其用户特征；以及基于所收集的用户特征来训练所述留存率模型。
7.根据另一实施例，所述方法还包括选择这些用户的第一用户子集并仅向该第一用户子集中的用户提供补助以使代扣成功。
8.根据又一实施例，所述第一用户子集是从这些用户中随机地选择的。
9.根据又一实施例，所述方法还包括收集这些用户中的在该下一代扣周期内代扣失败的用户的用户特征。
10.根据又一实施例，所述留存率模型是采用监督学习算法来基于所收集的用户特征训练的。
11.根据又一实施例，向所述用户提供补助包括：确定补助额度和在所述代扣周期内的代扣频次；将所述补助额度分布在所述代扣频次内，使得所述代扣频次内的每一次代扣被分配相应的额度；以及根据所述代扣频次依次执行代扣和补助操作，直至代扣成功。
12.根据又一实施例，所述预定阈值是基于每一代扣周期的补助的额度而变化的。
13.根据又一实施例，所述确定是基于代扣操作的返回消息中的失败类型字段的值的。
14.根据又一实施例，所述方法还包括确定代扣操作因用户账户注销而失败，以及清退所述用户；或者确定代扣操作因网络波动而失败，以及不清退所述用户。
15.如果代扣失败是由于用户账户注销，则清退所述用户；或者如果代扣失败是用于网络波动，则不清退所述用户。
16.根据本公开的第二方面，提供了一种用于对代扣服务的用户进行维护的系统，所述系统包括：代扣服务器，用于在代扣周期内为所述用户执行代扣服务；以及用户账户服务器，用于对来自所述代扣服务器的代扣请求作出响应，所述代扣服务器还被用于：根据来自所述用户账户服务器的响应来确定在代扣周期内所述代扣服务因所述用户的账户余额不足而未能成功；使用留存率模型对所述用户打分，其中所述留存率模型是用户在下一代扣周期内代扣成功的概率的模型；在所述打分高于预定阈值的情况下，向所述用户提供补助以使代扣成功；以及在所述打分低于预定阈值的情况下，清退所述用户而不再为其执行所述代扣服务。
17.根据本公开的第三方面，提供了一种用于对代扣服务的用户进行维护的系统，所述系统包括：处理器；以及被安排成存储计算机可执行指令的存储器，所述可执行指令在被所述处理器执行时使所述处理器执行根据本公开的第一方面所述的方法。
18.各方面一般包括如基本上在本文参照附图所描述并且如通过附图所解说的方法、装备、系统、计算机程序产品和处理系统。
19.前述内容已较宽泛地勾勒出根据本公开的示例的特征和技术优势以使下面的详细描述可以被更好地理解。附加的特征和优势将在此后描述。所公开的概念和具体示例可容易地被用作修改或设计用于实施与本公开相同的目的的其他结构的基础。此类等效训练并不背离所附权利要求书的范围。本文所公开的概念的特性在其组织和操作方法两方面以及相关联的优势将因结合附图来考虑以下描述而被更好地理解。每一附图是出于解说和描述目的来提供的，且并不定义对权利要求的限定。
附图说明
20.为了能详细理解本公开的以上陈述的特征所用的方式，可参照各方面来对以上简要概述的内容进行更具体的描述，其中一些方面在附图中解说。然而应该注意，附图仅解说了本公开的某些典型方面，故不应被认为限定其范围，因为本描述可允许有其他等同有效的方面。不同附图中的相同附图标记可标识相同或相似的元素。
21.图1示出了用于对代扣服务的用户进行维护的示例方法的流程图；
22.图2示出了用于对代扣服务的用户进行维护的示例系统的示意图；以及
23.图3示出了用于对代扣服务的用户进行维护的另一示例系统的示意图。
具体实施方式
24.以下结合附图1-3阐述的详细描述旨在作为各种配置的描述，而无意表示可实践本文中所描述的概念的仅有的配置。本详细描述包括具体细节以提供对各种概念的透彻理
解。然而，对于本领域技术人员将显而易见的是，没有这些具体细节也可实践这些概念。
25.术语解释
26.自动代扣：每次缴费时，由系统自动发起，不需要用户做二次核对的一种代扣方式，一般同时具有周期性特征。常用于手机话费缴纳、会员费缴纳、信用卡自动还款、保险续期续保等场景。
27.代扣频次：为了防止系统异常等原因导致代扣失败无法重试，针对一个代扣周期一般要执行多次代扣调度，单个周期的代扣调度次数叫做代扣频次。
28.清退：用户在某一代扣周期内因账户余额不足、账户冻结或注销等因素消耗掉所有代扣频次都代扣失败，被系统自动解约的一个过程。
29.宽限期：用户在某一自动代扣周期从开始欠费，直到被清退的时间。
30.留存率：用户在第一个代扣周期因余额不足或账户冻结等原因代扣失败的前提下，下一个代扣周期能够代扣成功的概率。
31.如背景技术部分所述，当前存在各种期缴自动代扣型服务，诸如手机话费代扣、水电煤费用代扣、各种会员费代扣、信用卡自动还款、保险产品的续期续保等等。一旦代扣失败，在宽限期结束之后，用户将被清退。然而，有些用户只是由于联系方式变更、遗忘等原因而未能代扣成功。因此，将这些用户清退将使得用户权益受损。为此，本技术可通过各种方式(例如，提供补助等)来暂时维持用户的代扣服务资格，并且还可通知用户及时作出补正。
32.下面参考图1，其示出了用于对代扣服务的用户进行维护的示例方法100的流程图。
33.如图所示，方法100可包括在框110，确定在代扣周期内为所述用户执行的代扣操作因用户账户金额不足而失败。在一实施例中，这一确定是基于代扣操作的返回消息中的失败类型字段的值来作出的。。可能存在各种原因导致代扣失败，诸如网络波动、用户账户注销、用户账户余额不足，等等。在一实施例中，可以通过在代扣失败返回消息中的失败类型字段，以指示代扣失败的原因，诸如该字段的值0可表示网络波动或中断、值1可表示用户账户注销、值2可表示用户账户余额不足，等等。由此，为了确定因账户余额不足而导致代扣失败，方法100可基于代扣操作失败的返回消息中的失败类型字段的值来确定代扣失败是否是由于余额不足。本领域技术人员可以明白，还可根据任何其他合适的方式来确定代扣失败的原因，诸如在接收到代扣失败的消息后，方法100可以咨询用户账户的管理方、检验网络状态等等，以确定代扣操作失败的原因。
34.在确定代扣失败之前，方法100还可针对一个代扣周期执行多次代扣调度，即代扣频次。如果在代扣周期内执行完代扣频次之后仍然代扣失败，则方法100可确定代扣失败，并根据代扣频次最后一次代扣操作的返回结果来确定代扣失败的原因。在一替换实施例中，方法100可根据代扣频次内代扣失败标识符出现最多的那一者来确定代扣失败的原因。例如，假定代扣频次为10次，前两次代扣失败是由于网络波动，而后八次是由于用户账户的余额不足，则方法100可以确定代扣失败的原因是用户账户的余额不足。在又一实施例中，用户账户的状况(余额不足、注销，等等)具有高于网络波动等因素的优先级，使得即使用户账户状况在代扣频次内发生较少，也足以确定代扣失败的原因是由于余额不足。在进一步的实施例中，代扣频次中诸次代扣失败可具有不同的权重，例如代扣频次中从第一次代扣失败到最后一次代扣失败可具有从低到高的权重。在又一实施例中，方法100还可以仅根据
代扣频次中最后一次代扣失败来确定失败原因。在这一实施例中，如果代扣失败的原因并非是用户账户的状况造成的，则方法100可进一步根据代扣频次中前几次代扣失败的原因来做出确定。例如，假定代扣频次为10次，最后一次代扣失败是由于网络波动，而前九次是由于用户账户的余额不足，则方法100可以确定代扣失败的原因是用户账户的余额不足。
35.在一实施例中，如果确定当前代扣失败是由于网络波动等系统异常原因造成的，则方法100可维持用户的代扣服务资格而不清退用户。可任选地，方法100还可通知代扣服务的提供方、用户账户的管理方等，以作出相应的修复操作来修复这一系统异常。
36.在另一实施例中，如果确定当前代扣是因用户的账户注销而未能成功，则方法100可任选地包括清退用户和/或通知用户已被清退。
37.继续参考图1，如果代扣失败是由于用户账户金额不足，则方法100可包括在框120使用留存率模型对用户打分，其中该留存率模型是用户在下一代扣周期内代扣成功的概率的模型。如上所述，留存率是用户在代扣周期因余额不足或账户冻结等原因代扣失败的前提下，下一个代扣周期能够代扣成功的概率。留存率模型即是对该概率进行估计的模型。在一实施例中，打分越高，所述用户在下一代扣周期内代扣成功的概率越高。
38.在一实施例中，留存率模型可通过如下步骤来获得：确定在代扣周期内代扣服务因账户余额不足而未能成功的所有用户；向这些用户提供补助以使代扣成功；在下一代扣周期内确定这些用户是否代扣成功；针对这些用户中的在该下一代扣周期内代扣成功的用户来收集其用户特征；以及基于所收集的用户特征来训练留存率模型。在进一步的实施例中，留存率模型可以在每一代扣周期之后都按上述步骤被更新。在该实施例中，用户特征可以是任何合适的特征，诸如用户的年龄、性别、收入、职业，等等。
39.在进一步的实施例中，并非向所有失败用户提供补助，方法100可任选地改为选择这些用户的第一用户子集并仅向该第一用户子集中的用户提供补助以使代扣成功。在该实施例中，第一用户子集可以是通过任何合适的方式来选择的，例如是从这些代扣失败的用户中随机地选择的。在另一实施例中，可以按预定比例来选择第一用户子集。例如，可以选择代扣失败的用户的10％、20％、30％等来作为第一用户子集。可任选地，对于未被选择提供补助的那些用户，方法100可对其进行清退。
40.在进一步的实施例中，方法100还可包括收集这些用户中的在该下一代扣周期内代扣失败的用户的用户特征，并进一步基于这些用户特征来训练留存率模型。由此，可以通过正样例(代扣成功的用户)和负样例(代扣失败)的用户来对留存率模型进行训练，得到更稳健的模型。
41.在又一优选实施例中，留存率模型是采用监督学习算法来基于所收集的用户特征训练的，例如线性回归、随机森林、xgboost等等。本领域技术人员可以明白，还可使用任何其他合适的监督、半监督和非监督学习算法来训练留存率模型。
42.继续参考图1，在框130，方法100可包括在确定用户的打分高于预定阈值的情况下，向用户提供补助以使代扣成功，否则在确定用户的打分低于预定阈值的情况下，方法100可包括在框140，清退用户而不再为其执行代扣服务。
43.在一实施例中，预定阈值可基于每一代扣周期的补助的额度而变化。例如，可根据需要来调整补助总额，从而在补助总额高的时候降低预定阈值，来为更多用户提供补助。
44.作为补充，方法100还可任选地向被清退的用户发送通知，例如通过短消息、社交
媒体消息等等。
45.可任选地，向用户提供补助可包括梯度投放策略。例如，并非一次性提供足额补助，而是可在代扣频次内逐步提供补助。在一实施例中，向用户提供补助可包括确定补助额度和在代扣周期内的代扣频次；将补助额度分布在代扣频次内，使得代扣频次内的每一次代扣都被分配相应的额度；以及根据代扣频次依次执行代扣和补助操作，直至代扣成功。可以明白，每一用户的补助额度可等于其代扣额度，并且补助额度在代扣频次内的分布可以是任一合适的分布，例如补助额度尽可能地分布在代扣频次的靠后代扣中。
46.下面给出本技术的一个示例业务场景来更详细地描述本技术的方法的操作流程：
47.假定代扣业务背景是首次代扣日是每月1号，每天代扣2次，连续代扣7天后仍然失败则将清退用户。代扣额为5元。本技术的方法可如下进行：
48.1)补助总额为5元，分布在总共14次代扣中。这一分布可以使得前10次代扣的分配额度为0，后4次代扣的额度分别是1元、1元、1元、2元。当然，本领域技术人员可以明白，可以采取任何其他合适的补助分布。
49.2)当月6号的第一次代扣为倒数第四次代扣，在此次代扣前确定的所有失败用户，使用留存率模型对用户打分，对打分较高的用户(即高于预定阈值)：
50.为其提供1元的补助；
51.在6号第一次代扣完成后，对仍然代扣失败的用户再投放1元的补助(注意：这1元补助要和之前投放补助可叠加使用)；
52.7号第一次代扣前，向6号第二次代扣完成仍然失败的用户进行第三次补助，仍然是1元，且可叠加使用；
53.7号第二次代扣前，对失败用户进行2元补助，此时单个失败用户已经拥有了1+1+1+2共5元，可全额抵扣代扣金额。
54.接下来参考图2，其示出了用于对代扣服务的用户进行维护的示例系统200的示意图。
55.如图所示，系统200可包括代扣服务器201和用户账户服务器203，其中代扣服务器201用于在代扣周期内为用户执行代扣服务，而用户账户服务器203用于对来自代扣服务器201的代扣请求作出响应。本领域技术人员可以明白，尽管出于说明的目的，图2中的代扣服务器201和用户账户服务器203被示为服务器的形式，它们的相应功能可以通过虚拟机或者在云上实现。
56.参考图2，在代扣周期内，代扣服务器201可以向用户账户服务器203发出代扣请求，如箭头210所示。在接收到代扣请求之后，用户账户服务器203可处理该代扣请求并将处理结果作为响应返回到代扣服务器201，如箭头215所示。
57.在接收到来自用户账户服务器203的响应之后，代扣服务器201可根据该响应来确定在代扣周期内代扣服务因用户的账户余额不足而未能成功；使用留存率模型对用户打分；在打分高于预定阈值的情况下，向用户提供补助以使代扣成功；以及在打分低于预定阈值的情况下，清退用户而不再为其执行代扣服务。
58.图3示出了用于对代扣服务的用户进行维护的另一示例系统300的示意图。系统300可包括处理器305以及被安排成存储计算机可执行指令315的存储器310，计算机可执行指令315在被处理器305执行时可使处理器305执行根据本公开的图1所描述的方法100。
59.以上具体实施方式包括对附图的引用，附图形成具体实施方式的部分。附图通过说明来示出可实践的特定实施例。这些实施例在本文中也称为“示例”。此类示例可以包括除所示或所述的那些元件以外的元件。然而，还构想了包括所示或所述元件的示例。此外，还构想出的是使用所示或所述的那些元件的任何组合或排列的示例，或参照本文中示出或描述的特定示例(或其一个或多个方面)，或参照本文中示出或描述的其他示例(或其一个或多个方面)。
60.在所附权利要求书中，术语“包括”和“包含”是开放式的，也就是说，在权利要求中除此类术语之后列举的那些元件之外的元件的系统、设备、制品或过程仍被视为落在那项权利要求的范围内。此外，在所附权利要求书中，术语“第一”、“第二”和“第三”等仅被用作标记，并且不旨在表明对它们的对象的数字顺序。
61.另外，本说明书中所解说的各操作的次序是示例性的。在替换实施例中，各操作可以按与附图所示的不同次序执行，且各操作可以合并成单个操作或拆分成更多操作。
62.以上描述旨在是说明性的，而非限制性的。例如，可结合其他实施例来使用以上描述的示例(或者其一个或多个方面)。可诸如由本领域普通技术人员在审阅以上描述之后来使用其他实施例。摘要允许读者快速地确定本技术公开的性质。提交该摘要，并且理解该摘要将不用于解释或限制权利要求的范围或含义。此外，在以上具体实施方式中，各种特征可以共同成组以使本公开流畅。然而，权利要求可以不陈述本文中公开的每一特征，因为实施例可以表征所述特征的子集。此外，实施例可以包括比特定示例中公开的特征更少的特征。因此，所附权利要求书由此被结合到具体实施方式中，一项权利要求作为单独的实施例而独立存在。本文中公开的实施例的范围应当参照所附权利要求书以及此类权利要求所赋予权利的等价方案的完整范围来确定。