文章主要是从前端接口和后端运营管理两个方面来详细讲述了贷超项目系统架构，一起来看看~
随着国家各个金融政策尘埃落地，自2019年7月28日出台非法借贷涉及刑事责任，市场上的现金贷公司犹如洪潮般尽数清退，当然，贷超(全名叫贷款超市，为现金贷提供多样、个性化推荐的引流平台)就自然受到影响，瞬间市场上90%以上贷超都关闭了。笔者之前负责过两个贷超项目，所以借此来复盘此项目来理清下自己思维。
一、前端
1. H5贷超
基于我们有内部的信贷平台，则可以作为导流入口，但考虑到跳转至APP流失率较高，也考虑到MVP模式，先快速的做了个H5贷超和简单版数据系统，保证一套系统能运转起来。
可以理解为将信贷系统的尾流量利用起来，入口在不同借款状态位置，毕竟也是用钱在第三方买来的。
当时用了这两种A/B页面来测试哪个下载率高，大家也可以猜下结果。
2. APP
APP我们实际做了两个版本，第一版就是搭建简单的功能，第二版就运用了一些商业模式，就玩法更多样。
涉及到商业模式这块就不放原型图了哈。
二、后端运营管理系统
后端系统包含了有，后台运营管理、POW BI(数据系统)、财务对账系统、渠道管理(分为买量、跑量。买量表示从第三方买量,我们需要配置H5链接给到他们，跑量表示商家需要我们这边提供他们产品跑的数据量)
1. 运营管理
这个就和电商后台都差不多，提供一些供前端展示及条件筛选的字段，运营人员将甲方提供的文档填入进去。
但唯一一点不同的贷超有分CPA、UV，这个就和数据系统和结算系统相关联，留到后面说。
这个从零做的，因为一个表的逻辑关系比较复杂，数据表也多大概有十多个表吧，基本拆成一版1-2个表来做的，包括但不仅限于总数据、产品总数据、产品详细数据、页面数据、数据对账等等。举一两个数据表的栗子；
（1）数据对账
可让商务人员可核对不同甲方的每日数据及收入情况，财务也可通过资金收款与对账情况进行核对。
（2）总数据
此表可显示每日贷超的总收入情况，及提供运营参考的数据，如点击人数、点击价值、转化率、客单价等等，每个字段都有一定的公式，例如人均点击产品数=产品点击人数除以UV等，总计则通过筛选条件，如筛选条件为一个月，则总计计算出一个月的总流水，当然某些字段是算出平均值的。以平均值和其他数据来作为数据参考。
这只是举其中一些小例子，一个实际从零做的数据系统复杂度可比我写的这些要复杂很多。
3. 结算系统
结算分为预付和日结，当然有些平台或者其他行业还有分周结、月结，但目前还没遇到这种场景所以就不做举例了。
预付可以理解为充值，表示商家提前付给平台方款项，直到消耗完，在消耗完之前我们会发邮件或者电话联系。
日结表示从0-24时间点之间该商家消耗的金额，当天或次日打款结算。
这里又分为CPA（按注册用户算）、CPC（即按当天产品点击UV），如果按CPA结算，表示注册用户数是在商家那里，这里就需要通过我们这边的点击UV数据去查看，大概估计他们扣量的比例，这种就需要次日上午结算出来催打款。
如果按CPC则系统可以做智能算法，通过产品单价*当天的点击UV数，当然结算也是人工去结，因为会考虑到当天涨价，涨价情况就得看商务强不强势，商家的用户进件数据是否优良。
这里会有一个场景会比较复杂，就是日结商家会转成预付商家，若商家先是日结，在转做预付，我这里的解决方案是把日结和预付分开，商户重新新建预付合作，因为预付会有充值、消费和清算操作，而日结则只有消费，也就是结算，同时只能操作一种。
缺点就是只能分开看预付和日结消费记录，各位有什么好的解决方案也可以讨论讨论。
因为在数据系统能看到流水和收入的，所以结算系统是与数据系统有关联性的，通过用户的行为，例如曝光、点击UV、产品点击数等，来分析收入的增长和降低，在设计的时候都要考虑好各种场景。
4. 商品管理
商品管理是因为我们接了电商的API，他们只提供货源，商品订单管理要做在我们后台。基于对我们用户群体特征的分析，主要提供的是一些线上的商品，如视频会员、游戏充值、快餐电子优惠券等。
主要模式有直充和卡密，也考虑到减少物流成本和人力成本，用户充值填写账号即可到账。
结尾
至此搭建完整的贷超系统需要这些就足以能够支撑起来，因为贷超也算是一个流量平台，所以玩法很多，例如我们还有会员模式，对应后台的会员管理，都是能提高我们的商业变现和多样的运营玩法。
此篇文章主要讲搭建，所以每个系统维度都只是讲了个大概，举一两个例子，但表面越简单地实际逻辑则越复杂。
由于今年的金融严重受挫，相信不少金融从业者都有些迷茫，若仍想在金融行业深耕，个人做了一些小研究，推荐可以往供应链金融、证券、区块链(非交易所)、金融支付、持牌信贷机构等发展，而未来3-5年基本面向TO B的稍微多些，也可以向这边靠。
第一次写文章，若有对你有帮助可以留个言，让我有些自豪感，也可以互相学习。
