花名:大飞

部门:广告技术

入职时间:2016

主要从事广告系统相关研发工作,CPS系统方面比较深入

背景：    

      CPS(Cost Per Sale)是一种按成交扣费的广告模式，即每成交一笔，商家支付相应的佣金给站长。通过CPS，可以激励站长来推广蘑菇街的商品，从而达到引流、拉新的效果。来目前很火的蘑客联盟，就是基于CPS来运作的，业界类似的还有淘宝联盟、京东联盟等。接下来为大家简单介绍一下CPS的体系。

      在CPS体系中，有三个重要的角色：商家、站长、购买用户。商家给商品设置佣金比例，站长挑选高佣商品，用户购买，站长获得佣金。

       CPS对于商家而言，是风险最低的广告投放方式。商家针对目标商品，设置好固定比例的佣金，这个商品每卖出一笔，就会扣相应比例的佣金，所以只要佣金比例设置合理，商家就绝对不会亏钱。 通过合理的佣金设置，可以吸引站长来推广商品，从而提高店铺销量及知名度。

    站长利用自己的推广渠道(微信群、博客等)推广CPS商品，可以赚取到丰厚的商品佣金，推广的越多，佣金收入就越多。

    站长考虑到购买转化率，通常会推广一些高性价比的商品，所以对于用户而言，可以花相对低的价格来进行购买。

    所以CPS对于商家、站长、购买用户三方都是有利的。

    接下来为大家介绍CPS的具体实现细节。

一.CPS跳转

1.什么是CPS跳转？

     CPS是通过浏览器cookie来跟踪站长信息的(站长userId等)，站长推广的页面有很多种(商品详情页、店铺首页、活动集合页等)，为了使各个落地页不需要关心种cookie这个行为，所以需要把种cookie功能单独解耦出来。

这样CPS的流程就变为：用户点击推广链接，然后种cookie，再跳转到详情页。

    这就是CPS跳转，目的只有一个，就是把站长信息种到cookie里面。

2.CPS怎么种上cookie？

下面是一条最简单的cps推广链接：

    uid参数是站长id，target参数是落地页(一个商品详情页)。

    当站长想要推广某个商品时，只需要把他的站长id和商品链接填写到对应的参数后面就可以了。这是最简单的方式了，对于一些大站长而言，他们还可以向链接中拼接渠道信息、自定义信息等参数。

当用户点击了站长的推广链接后，请求首先会打到统一的跳转服务，服务端在进行一系列的业务验证之后，会给http请求的response headers中写入cps的相关cookie，然后再将请求302条转到商品详情页。

下面就是条转过程中种上的cookie。

     在成功种上cookie并跳转到商品详情页之后，用户在mogujie.com的域名下的所有http请求，都会带上站长的相关信息，其中最主要的一个行为就是下单。一旦用户有下单行为，交易的同学就会读取到下单请求所带的相关cookie，并写入订单消息报中。

    这样站长的信息与订单的信息就绑定到了一起，后续的佣金结算就是基于此进行的。同时我们也可以在站长后台中看到这个订单。

    在种cookie的过程中，很可能遇到作弊的问题：1.站长通过Cookie Stuffing的行为，恶意大范围的种上CPS的cookie，从而非法赚取佣金。2.通过http劫持的方式，篡改用户http请求的信息，从而非法获利。

    针对以上作弊行为，通过多样化跳转、密钥机制、https等手段可以有效防止作弊，因为涉及到反作弊策略，在此就不详细展开了。 

    上图绿色的线是未经反作弊过滤的CPS跳转请求量，底下的黄色线是经过反作弊过滤后有效的CPS跳转请求量，可以看到反作弊策略有效地过滤了很多非法请求。

二.订单同步

      经过CPS跳转，站长信息已经与订单牢牢绑定到了一起，为了CPS后面的一系列业务，我们需要把这部分订单数据接管过来，保存在我们自己的数据库中，同时还需要维护订单的最新状态(支付、退款等)，这就是订单同步，大致流程如下：

      1.当用户下单时，交易系统会以订单id为key，把订单消息报push到kafka队列中，这样可以保证同一个订单的不同状态(支付、退款等)会被塞入相同的partition中，从而保证单个订单的消息报会按照真实状态变化被顺序地消费。

        订单同步过程在设计上是允许一定量延迟的，如果由于订单量太大，导致延迟增高，在kafka的消费端，可以增加订单消息报的消费线程，从而平行扩展对消息报的消费能力。

       2.订单的交易状态有以下几种：未支付、已支付、交易完成(已收货)、最终完成(超过无理由退货期)、订单取消(未及时付款)、已退货(付款后退货)。每种状态都会有相应的订单消息报，订单同步程序会根据消息报内容实时更新订单状态。相应的订单状态会展示在站长后台。

      有些有开发能力的站长，他们需要更加实时的订单状态变更信息。对于这些站长，我们采用主动“推”的方式向站长推送订单信息。即站长在后台设置一个可调用的接口地址，每当有订单信息时，我们就调用对应站长的接口，把订单数据实时推给他们。

       3.由于CPS订单是需要扣取商家佣金的，因此还需要一个计费状态。当订单付款后，订单同步程序会发送一个扣费通知给到资金端，由于资金扣费是异步的，所以还需要消费一个计费消息的kafka队列，当有扣费成功的消息时，则修改对应的订单计费状态为成功。

      4.到达最终完成且计费完成的订单，就是可以结算的订单了，我们会在固定的时间点对这些订单进行结算。

三.CPS结算

1.资金来源

     站长CPS的佣金是由佣金结算系统每月定时向站长结算的，由于跟钱打交道，所以这一步非常重要。

      在订单同步过程中，会把佣金从用户的支付款中打入CPS中转账户，CPS结算的资金来源就是这个中转账户。

2.结算流程

      目前是每月1号，对到达可结算状态的订单进行结算。结算流程如下：

      为保证资金安全：1.在结算中确保每条结算纪录幂等，不会重复结算。2.多维度资金对账，转账前和转账后都有相应的对账，有问题立即报警。3.订单结算完成后需要修改对应的状态，由于订单量很大，为防止大批量修改数据产生过多binlog，从而造成数据库主从延迟，在此需要充分保证修改数据的平缓性。

下面是CPS系统的整体架构

四.总结

     在蘑菇街工作了大概一年半的时间，感觉自己的成长还是很大的。技术上：不再只满足于完成功能，更多地考虑系统的性能、稳定性等因素。业务上：更加主动地去思考，发现并改进产品上可以优化的部分。下面是我的一些粗略总结：

1.快速理解自己的业务。

      对于刚开始工作的学生来说，接手的任务多是一些业务功能的实现或bug修复，此时并没有什么技术难点，更重要的是快速理解业务，了解上下游的数据流以及底层的数据存储关系。最好能够自己把功能使用一遍，这样有助于更快地理解业务。在理解业务之后，这些新需求、小功能就不是什么问题了。

2.深入了解自己使用的技术。

     对于自己使用到的技术框架，不能只停留在会用的层次上，要了解其底层架构、甚至深入到源码的级别上。因为技术框架是个双刃剑，用的好了会使自己的系统更加高效，用不好无疑会给自己埋一个大坑，等哪天线上出了问题，就只能欲哭无泪了。

3.一定要多问问题。

      作为职场新人，无论是技术上或是业务上的，多多少少肯定会有不明白的地方，这并没有什么丢人的，有问题一定要及时地问出来，自己的问题解决了，对公司的业务以及自己的成长，都是有好处的。

    最后，由衷地感谢那些在我成长道路上给过我指导的前辈们。

更多流量、广告、搜索、算法相关内容, 敬请关注“美丽联合数据技术”公众号