随着我国银行信用卡业务进入存量经营时代,银行面临着如何在做好传统信贷业务的同时,提升客户获客和留存率的挑战。
O2O优惠券正是银行应对这一挑战的重要手段之一。
本系列文章将从一个亲历者的视角，讲述银行APP上O2O消费代金券应用个性化推荐系统的建设与运营过程。
通过讲述个性化推荐系统的设计思路、技术实现、产品迭代和效果评估等内容，读者可以了解银行如何利用大数据和人工智能技术，根据客户的消费需求、偏好和行为数据，实现精准的个性化营销，提升客户体验和满意度。
本系列旨在分享银行数字化转型过程中的实践经验，以供读者借鉴和参考。
本文是该系列的第一篇，讲述了一个具体场景应用推荐系统的探索历程。
背景与目标O2O消费代金券，对于银行信用卡的客户经营是非常重要的一个内容，通过与线下消费商户进行合作，在线上发放代金券，把线上客户引流至线下商户消费，是增加客户黏性的好方法，对标互联网厂商最典型的例子就是美团、大众点评APP上的券。
从信用卡客户全生命周期的视角来看，在发卡环节，通过发卡奖励提供的消费代金券，可以吸引潜在客户进行办卡。
面对成长期的客户，通过在首页、专题页的栏位推荐客户感兴趣的O2O代金券，可以以此培养客户在我行APP进行消费的习惯。
面对成熟期与潜在脱落客户，通过数据分析与机器学习模型，通过APP内推荐栏位或者app push的方式，提前进行客户挽留。
因此，通过向客户推荐O2O优惠券商户的场景目标是显然的，但是，如何才能推荐更吸引用户的优惠券，促使用户购买并核销优惠券，就成了需要机器学习模型团队与上下游合作解决的问题了。
场景分析从产品形态来看，银行APP的O2O优惠券和美团、点评的优惠券并没有太大的差别，整体转化链路是用户访问APP-商户曝光-用户点击-选券购买-进入支付页面-支付-核销。
机器学习团队需要做的是，通过搭建个性化推荐系统，在列表页曝光位推荐客户感兴趣的O2O优惠券商户。
某银行的O2O优惠券商户推荐列表页面目标的制定与对齐前文定义了业务场景和目标，但是如何量化目标，把业务目标转化为技术可实现的目标,仍需进一步讨论。
与互联网企业习惯按产品建立团队不同，在银行复杂的组织架构下,本文涉及的场景需要银行各职能部门密切配合，包括业务主管部门、机器学习团队、开发中心的工程化开发团队以及数据中心的应用运维团队。
不同业务主管部门对场景效益诉求各异：市场部希望提升用户获客留存量和客户活跃率；商户部希望为合作商户带来流量和成单量提升，加强后续合作；APP运营部门希望提高APP的DAU和次日留存。
因此，团队需要明确核心优化目标，兼顾各方需求，统一归集多个部门的诉求，转化为可量化的技术指标，以指导算法模型和系统设计。
从技术目标角度来看，因为模型是对O2O优惠券商户进行排序推荐，影响的是类似上图中的商户曝光位置的相对排序，从链路来看，用户对于推荐结果好坏的反馈的最直接反馈就是是否点击进入了某一商户的详情页。
对于这个最直接的指标的衡量就是推荐列表页的点击率CTR。
那么，机器学习团队的最初一版的建模目标，就锁定在提升点击率上。
点击率，毕竟只是整个转化链路的一环，距离真正的业务目标还比较遥远。
机器学习团队需要把这个指标融入整个转化链路，反向对齐业务目标。
在第一版时，笔者与业务主管部门就这个问题进行过探讨。
鉴于当时，机器学习方法在银行的应用还处于较为原始的阶段，不像现在已经相当普及。
因此，在指标讨论过程中，业务部门普遍采取了较为宽容且合作的态度。
最后，我们得出的结论是，假设客户进入APP查看优惠券商户列表的曝光量不变，客户点击进入商户详情页后的转化率也不变，即除点击率以外的项都固定，这样机器学习团队可以集中精力优化点击率。
这个指标的设定，是一个权宜之举。
在上线运营的过程中还真出现了一些戏剧性的问题，在本系列文章后面会详细阐述。
在指标的数值目标制定上，因为对比的基线相对较弱，所以设定了模型实验组相比于基线对照组的点击率提升20%的目标。
这里的基线排序规则是根据客户实时定位计算客户与商户间的距离，按由近到远排序。
前期探索与分析前文提到，模型的目标是提升客户的点击率，依照点击率建模的思路，这将转化为一个机器学习里的二分类问题，即是在给定的距离范围内（context）对于给定的客户（user）和商户（item），提取特征并训练一个机器学习模型，判断该客户是否点击进入该商户的详情页。
对于一个具体客户，需要一一计算客户与范围内的商户的打分，并按照点击可能性从高到低呈现给客户。
这个打分即是模型目标Y，打分归一化为0~1的区间，越靠近1表明客户越有可能点击，越靠近0表示越不可能点击。
在这个场景中，需要特别说明为何需要给定距离范围内推荐商户。
对于O2O优惠券，用户必须线下到店消费，不能像点外卖或网购商品那样跨越很远的距离，因此用户对于远距离尤其是跨城的O2O优惠券兴趣不大。
再结合数据分析用户购券和核销的时间差，发现很大一部分都是同日购券和核销，表明用户往往是临时起意，寻找附近优惠券并很快消费。
这种行为表明，无论是策略还是模型，都应推荐离用户较近的商户。
例如，如果用户周末饭点时在深圳后海，就不应大量推送福田、宝安区乃至其他城市的餐饮商户，因为用户不太可能在短时间内去远处商户消费。
综上，模型的推荐位应仅推荐指定范围内的商户。
需要注意的是，这个距离限制仅针对推荐，不适用于搜索。
搜索有其独立逻辑，后续文章会专门讨论搜索场景。
埋点插曲确定了点击率建模的目标，也确定了机器学习二分类训练的模型框架，现在的问题到了数据。
我行的APP前期已经建立了一套稀疏埋点系统，客户在APP上的操作会通过客户端埋点上报至行内服务端，并同步至行内大数据平台供数据分析使用。
由于埋点是稀疏埋点，因此埋点记录的信息是由产品经理制定，并由APP客户端开发工程师通过类似一个onEvent(params)的函数里把相应的信息通过埋点SDK上报的。
但相关页面在上线之初，埋点主要是为了通过在数仓里计算各页面的PV、UV，可以画出O2O优惠券的转化漏斗，进行数据分析。
但是，原有的埋点信息难以关联出一个具体的用户对于一个具体的商户的曝光与点击之间的前后关系。
而机器学习模型，恰恰需要这个用户与商户点击之间的关系，才能开始建模。
看到这种数据现状，当时不得不感叹，万事开头难呐。
好不容易和上下游各方谈好了业务目标，模型可行性，结果准备开干的时候发现数据基本是没有的。
于是，当时只能和APP产品经理与开发团队协调排期，提供了一版机器学习建模所需数据的埋点需求，把埋点部署到APP上，收集一波数据再开始进行建模。
如果在银行或者其他金融行业信息科技条线工作的读者应该很有经验并且深有体会，这种情况起码要两三个月才能搞好，而事实也恰恰如此。
当然，在这个时间内，机器学习团队也不是完全就是被动的等待，关于客户属性画像、行为画像的数据采集与分析工作也在同步进行。
特征数据采集与加工特征工程是建模工程中非常重要的一环。
特征，并不是无水之源、无土之木。
进入模型的特征，都有其来源上游。
在客户的画像数据中，相比于互联网APP往往只要一个手机号和验证码就能很轻量级地注册导致客户画像不好收集，银行APP的用户大部分是银行的客户，客户在申卡过程中会填写一些信息。
对于机器学习团队来说，这些基础数据，可以比较方便地构建出客户的属性类画像。
这些信息缺失率较低，且经过风险审核，真实性较高，可以很好地作为入模的特征。
在工程化开发上，由于这些数据基本上已经存在于行内大数据平台上，因此，机器学习团队可以比较方便地获取到这些信息，并进行简单地加工即可。
解决了基础属性类的画像数据，还有一类数据是行为数据，在这一类数据上，银行APP相对于互联网就存在于巨大的劣势。
银行业务大部分是金融业务，相对于互联网APP里面的浏览与消费而言，金融业务大部分是低频业务，其行为数据较难积累。
一个用户打开银行APP，可能最多的就是使用查账转账还款等功能，对于O2O优惠券来说，这些客户其实和“新户”无异，也就是说，从建模角度来看这是一个巨大的冷启动问题。
我们分析的结论是，冷启动还是由策略来解决，模型还是专注于有过在我行APP上的O2O优惠券浏览和购买的客户上。
针对已有历史行为的客户，特征的设计主要还是基于行为事件的滑窗。
首先，对于行为事件分出了曝光（浏览）、点击、下单、核销等几大类。
对于每一类行为事件，又根据商户类型的不同，分为餐饮等几类，其中餐饮又细分为川菜、湘菜、粤菜，火锅、烤肉、西餐，甜点、咖啡、奶茶等几小类，并统计客户在1、3、7、14、30、90天等时间周期内的各个行为事件的计数，以及占比等。
此外，客户使用我行卡的消费行为（不一定是O2O优惠券促成的消费）也被加工成为入模特征。
对于合作商户侧，以类似的思路，同样加工出相应的特征。
基本属性方面，例如商户是大型连锁商户（例如KFC、屈臣氏、瑞幸、奈雪的茶等等）还是本地商户，商户的注册资本，门店规模等。
行为数据主要是商户对应的优惠券购买和核销使用的记录。
如果该商户还是我行的收单商户的话，还能得到一些相关的数据作为特征输入。
在交叉类特征上，我们基于客户在指定商户类型的行为数据的基础上，轻度加工一些交叉类特征，以便上线推理时可以实时计算这些特征。
这些特征主要有，针对一个具体客户和一个具体商户，计算该客户在该商户所在的商户大类、小类上的浏览次数、消费金额等等。
本篇结尾与后续在场景确定、目标对齐、调研分析、埋点优化、特征采集进行完后，下一步就是到了真正模型训练、验证以及推理上线的过程了。
下一篇，我们将从更偏工程化的角度来阐述这一过程。
敬请期待。