有赞多平台推广接入与测试
点击关注“有赞coder”
获取更多技术干货哦～
部门：业务技术/社交电商
一、基本概念
二、整体业务模式
2.1 自营模式
2.2 CPS模式
2.3 两者区别
自营模式只有三方渠道收取佣金，具体佣金率不同渠道设定都不一样。CPS模式会存在二方分佣、三方分佣金以及n方分佣。通常参与分佣对象有：推广者(有赞客佣金)、有赞(有赞技术服务费)、渠道(渠道技术服务费)。
自营模式的接入需要外部渠道申请有赞云应用，完成店铺和渠道应用的绑定关系，作为自营订单归因的判断条件之一。CPS模式需要商家去入驻分佣推广作为CPS订单归因判断条件之一。
自营模式商品池其实就是当前店铺所有商品满足风控基础审核。CPS模式对应的商品池更大，所有入驻过分佣推广的店铺对应商品都流入该池子，禁售规则也更多。
两种模式都会生成推广链接以及写入点击记录，订单归因的时候CPS模式是按照点击归因。自营模式主要按照下单环境fanstype进行归因。
自营模式渠道佣金按照类目设定佣金率或者渠道通用的佣金率来计算。CPS模式佣金分为店铺佣金率(或者设置的类目佣金率)、通用佣金率、定向基础佣金率、定向单品佣金率、团长佣金率，佣金率规则较丰富。
三、技术实现
3.1 实现概览
主要分为几大模块：推广管理、点击跟踪系统、订单归因、佣金计费分润、订单中心；推广管理系统主要负责生成商品对应渠道推广链接、提供佣金率查询能力供计费系统使用以及分佣金推广平台活动计划设置等。用户访问生成的推广链接的过程中的关键节点会被点击跟踪系统记录下来，从而为订单归因系统提供归因依据。然后，计费系统根据拿到的归因结果(归属渠道、归属有赞客、归因类型等信息)去匹配对应的计费策略，通过调用推广管理系统获取订单中每个商品当前享受的佣金率从而进行商品维度佣金计算。得出计费结果后到了结算时间时调用结算中心分润接口将佣金分给各个参与分佣对象。最后，归因结果、计费结果、订单状态变更、物流状态变更、商品信息变更等都会以消息的形式汇聚到cps-order订单中心，提供订单搜索等能力并将相关状态变更推送给三方渠道。
3.2 归因实现
3.2.1 常见归因模型
单点触控归因模型
将功劳归功于转化路径上的一个触摸点，没有复杂的计算，易于实现且投资最少。然而，这大大简化了全渠道客户旅程，并可能导致严重的误解。主要有以下两种归因模型：最终点击归因模型(又称为最终交互或最终接触归因模型)，将100%的转化效果归因给最后一次点击或流量来源; 首次点击（又名首次交互或首次接触）归因模型类似于前两个模型，只是它把用户旅程中的100%的转换效果分配给了用户旅程中的首次点击或引荐(referrer)
多点触控归因模型
单点触控的简单性使数据分析产生了空白，而多点触控通过在客户旅程中增加更多步骤来弥补这一差距。主要有以下三种归因模型：线性归因模型会平等地对待把用户旅程中转化路径上的所有接触点，对所有接触点分配相等的权重和比例；时间衰减归因模型是线性模型的变形，该模型在时间上最接近转化的接触点，获得的权重更高；而接触点与转化的距离越远，其权重“衰减”就越大；数据驱动归因模型，通过预测算法来分析数据，以确定哪些渠道、活动和关键字对转换的影响最大。通过识别整个用户旅程中经历的步骤，增加客户转换的可能性，并给予发挥作用的接触点相应的转换功劳，该模型通常需要高质量的历史数据；
有赞CPS归因系统选择是单点触控归因模型中的最终点击归因模型，有以下两点考虑。第一，多点触控归因模型，需要在用户旅程中存在多个触控点且要综合考虑每个触控点的权重，系统复杂度高。有赞CPS业务主要是针对直播推广场景用户旅程相对较短，只需要找准关键的触控点即可。第二，对比最终点击归因模型和首次点击归因模型，认为购买前的最后接触点是导致用户进行购买的关键转折点。
归因规则
自营模式和CPS模式都是按店铺维度进行归因，归因结果需要几个关键信息：归属渠道、归属有赞客、归因类型(自营或CPS)、归因结果等。具体规则如下：
自营模式：
CPS模式：
注：CPS模式归因优先级高于自营模式。
上述规则是最基础的归因规则，当然在不同归因场景会依据基础规则衍生出其他归因规则。例如，按照订单atrps归因、自购省归因规则、全站归因等。
点击跟踪归因流程
归因依赖于点击归因系统，整体流程如下流程图所示：
1）用户访问推广链接，点击系统解析链接后校验签名(通过算法加密)、生成用户点击信息并写入cookie、发送点击kafka消息，再重定向到商品详情页在页面并将必要信息拼接到url后面
2）点击持久化服务消费点击kafka消息并将点击写入Hbase并提供查询接口，点击记录包含用户、商品、推广与店铺等信息。除此之外，点击持久化服务也会消费埋点点击消息并写入Hbase。埋点消息会存在少量丢失以及消息延迟并不适用于性能要求高可靠性要求高的业务，因此消费埋点消息是作为辅助(例如，302点击系统对应kakfka集群宕机，这时候还可以用埋点归因)
3）归因系统消费下单消息，根据归因指定字段去查询买家最新一次点击记录，优先做CPS归因处理。CPS归因会按照指定指定字段优先级陆续查询点击记录进行归因。埋点消息标识用户的字段是段是yzUid和uuid，用户未登录时埋点消息yzUid字段为空，当埋点服务异常时会出现埋点kafka消息uuid字段为空。点击系统使用atruuid(同个用户可以有多个atrUuid)来标识用户对某个推广链接的点击。
根据具体业务CPS归因还衍生出三种归因方式：自购省归因、按照atrps归因、全站归因。前两种不需要查询点击记录：按atrps归因是直接归因为订单消息里的atrps，当流量超出系统承载能力的时候系统归因速度变慢时将大主播直播间里商品加上到白名单去走这种归因方式(目前基本没用到)。全站归因是跨店铺归因(只针对热卖小程序)，用户访问店铺A商品然后再访问店铺B商品，会将店铺A商品的atrps会携带到店铺B。
当执行完CPS归因的所有归因策略，还未归因成功的话最后执行自营归因策略，通过订单消息里fansType、platform等字段值进行归因同时判断店铺是否授权。
3.3 计费与分润实现
归因是为了得出分佣对象有哪些，计费则是根据业务计费公式分别计算每个分佣对象该分得多少佣金，分润是根据计费得出的结果将佣金转到对应分佣对象的账号里。接下来分别介绍下有赞CPS的计费规则、计费流程以及佣金分润的逻辑。
3.3.1计费规则
计费有几个要素：商品佣金率、分佣对象间计费优先级、佣金池维度划分。商家可以在分佣推广平台设置各种推广活动从而设定商品佣金率，各种推广活动有优先级顺序，商品命中优先级最高活动对应佣金率(定向单品>定向基础>招商团长>通用单品>店铺类目>店铺通用)。佣金池维度指的是总佣金被划分成几个小区域佣金池，每个小区域佣金池都有n个分佣对象，分佣对象指参与瓜分佣金池的角色有唯一的商户号(收款账号)。
推广活动不仅要确定商品的佣金率还决定了有哪些分佣对象，团长有赞客参与分佣的前提是商品推广命中招商团长活动佣金率，有赞客分享赚活动会有粉丝参与分佣。CPS模式当前有两个佣金维度：商品佣金和团长佣金。商品佣金池最多可包含有赞客、渠道平台、有赞平台、粉丝几个分佣对象，最少可包含有赞客和有赞平台两个分佣对象；团长佣金域只包含了有赞平台和团长有赞客。
计费的业务规则是多变的，这三个要素都有可能会进行业务扩展。如增加一个佣金维度或增加一种推广活动类型等。
3.3.2 计费流程
计费流程需要保证消息幂等、消息乱序时也能正确处理、归因慢了计费重试、支付或退款消息丢失能在订单完成时触发走一遍计费流程。
整体计算规则分为几步：
计费需要归因结果取到有哪些分佣对象和归因类型(自营模式和CPS模式)，根据归因类型选择不同处理策略去查询商品佣金率(商品当前享受佣金率以支付时间为准)。
根据归因类型查询每个佣金域内对应划分比例，例如：团长佣金(团长技术服务费占10%，团长有赞客占90%)
针对不同佣金域计算订单上每个商品初始佣金，接着算出不同佣金域各自订单维度总佣金。最后根据每个佣金域分佣对象计费优先级，计算分佣对象应得佣金，优先级较低的分佣对象可能佣金为0。
若发生退款，同样按照第三步计算，应该退回的佣金用初始佣金减去当前佣金。
3.3.3 佣金分润
CPS业务的最后一部就是将佣金转到正确的账号，需要将计费结果告诉结算中心，让结算去调账。CPS业务分润规则如下：
订单完成后T+15天进行分润，若T+15天内有退款一直未完成则分润任务会按天往后延迟。
针对快手渠道，有赞客佣金在订单完成T+7天就进行提前分润，其他分佣对象的佣金分润时间还是T+15天
佣金分润流程主要分为两个阶段：
订单归因成功后交易会给订单打标；
订单完成后资产会将CPS佣金冻结到中间账号，若冻结不成功一直重试；
订单完成T+15之间发生维权会重新计费，结算中心调用计费提供的接口将应退回佣金从中间账号解冻退回给商家；
T+15天订单维权都处理完且订单未关闭则进入第二阶段，依据计费最终结果数据执行分润TSP任务将佣金打到对应分佣账户。
四、质量保障中的挑战
4.2 测试提效与稳定性保障
在CPS测试中，从商家侧店铺入驻，到创建商品，添加多平台卖货商品审核，生成推广链接，到推广者第三发平台上架售卖，再到用户侧点击购买下单，整个链路非常冗长。
CPS从最初只有埋点到后面的302方案也经历了大版本重构。业务迭代较快，测试资源紧张，同时还要兼顾CPS整体重构。在测试过程中为了节约重复成本，提升人效，也做了非常多的数据准备工具。
4.2.1 数据工厂
测试工具主要目的是节约人力，辅助测试提效，增长技术测试团队通过分析测试阶段重复工作与耗时，从数据准备、测试链路推进、问题快速定位三个角度，做了多种测试工具。
4.2.2 QA接口自动化回归与线上监控
有赞当前的QA接口自动化主要是testNG，多平台卖货从最初只有ad-cps整体承接到CPS重构拆分为多个应用，相关的自动化case从一百多case到现在的上千case，全量覆盖了核心场景与接口。同时推进开发单测，增加代码合并maser卡点，在提测前即可通过单测与接口自动化回归原有功能不受影响。
线上监控通过Robot自动化调度，帮助线上问题提前内部发现。同时通过消息积压告警，归因延迟告警灯多个方式监控线上稳定性。在直播大流量场景时可以快速发现问题，及时跟进解决。
4.2.3 监控告警与资损防控
分佣业务与资金密切相关，为了保障商家、消费者、推广者、三方平台与有赞平台等各项服务稳定，对于多平台的资损场景，增长技术团队拟定了全方位的防控策略。
从技术方案设计，考虑了消息延迟、乱序、重复等各种业务场景的可能，设计了实时归因，延迟归因支持动态延迟，定时延迟等。同时又通过离线归因比对全量，保障归因的准确性，在BCP对账中也增加了与交易、资产等订单比对，资金对账，保障资损问题及时发现并自动告警。
五、未来工作
招募优秀的你加入👇