达达集团技术

到家营销警卫即时降低资损实践

一、背景及业内案例分析
1.背景
2.案例
3.问题总结及分析
二、营销警卫简介和实现方案
1.营销警卫简介
2.实现方案
三、成果及规划
1.成果
2.不足
3.未来规划
一 背景及业内案例
背景
如今的电商平台每天充斥着大量营销活动,营销活动的本质是为了提高平台的日活、商家销量提升、让利C端用户;在运营、商家做让利营销活动的过程中,在操作失误时往往就会导致运营营销事故。
案例
1.2019年某平台百元通用优惠券营销推广,无论新老用户都可以领100元无门槛券,最终导致资损高达上千万。
2.2021年某国外手机厂商由于运营操作失误,原本应该是满4000减200,但是线上生效的优惠券却是满200减4000,造成大量资损,这样的运营事故对于公司来说是致命的。
问题总结及分析
  • 问题总结

    • 系统设计问题
    • 运营操作失误
  • 问题分析

    1.案例1,从需求层面出发,针对平台类的电商在目前电商发展成熟期,各大电商平台都在降低补贴的前提下,用户领券无限制的场景是否真的存在,我们认为答案是否定的;即使没有黑产,上千万人民币无门槛优惠券,也不是任何一家商业公司愿意支付的成本。

    2.案例2,满200减4000的优惠券,无论从哪个维度来看,正常的营销业务是不可能创建力度如此大的优惠券,即使每年618、双11也不会存在这样的大额券;这种问题可能存在的原因是产品的需求不严谨、研发对产品的需求没有做深度思考。

  • 运营操作失误

    针对案例1、2,无论是测试、还是运营发布线上优惠券,要建立规范化流程,增加审批流程,降低资损风险;我们可以在系统维度针对大额券设置用户领取限制规则;重视代码安全,可能一个简单的if...else就会导致资损问题,这种问题在营销业务开发人员身上发生的概率尤为明显;在系统层面建设补贴规则限制机制、精准预算控制等,对于特定的品类、sku不允许设置过多的补贴,这种方式虽然不够精细,但是在很大程度上可以降低资损风险。

二 营销警卫简介和实现方案

营销警卫简介
在到家的发展历史中也发生过资损问题,在营销团队多年迭代的过程中,我们总结了以往自身问题和学习其他平台发生的案例,我们设计了一套到家资损风险预警机制,即到家营销警卫,警:营销风险预警,卫:即保护,降低资损风险。
实现方案

事件驱动
  • 非侵入式

1.在营销警卫规划设计前期调研了业内实现方案,基于营销业务场景并且结合到家营销业务的现状,最终采用的是非侵入方式设计、独立部署;营销警卫通过MQ与各营销业务实现系统级的业务层解耦,各营销业务只负责独立业务逻辑。这样做的优点是降低了各业务系统的复杂度。
2.如果采用侵入式系统设计,由于营销业务的复杂度高、数据量大,预警规则数据整合到各个业务子系统,那么对于业务子系统来说既要承担日常处理数据又要负责风险数据检查,那么后期随着营销业务的发展,各业务子系统的性能压力会逐渐增大,进而影响正常处理业务数据的吞吐量。
  • 双层存储设计

我们采用的是ES+Hbase双层存储架构,营销预警数据对我们来说有很多复杂的查询场景,基于不同的场景,我们构建了多套索引,根据不同的索引为B端提供查询功能,另外利用Hbase做了二级索引,将ES的索引中的RowKey快速定位到Hbase具体数据,这样的设计也缓解ES部分读写压力。

营销警卫系统架构图

营销警卫时序图
  • 事前规避

1.营销警卫各接入营销系统生产消息,产品和业务侧总结了关于此业务可能出现的潜在风险,例如是否存在平台大额补贴的优惠券、优惠券领取规则等。
2.在需求评审阶段必须关注数据的逆向流程,在发生资损的情况时,逆向流程往往是保护平台、商家的关键手段。
3.DDD驱动技术方案设计,针对营销业务的复杂场景,要做到高度抽象,各业务场景避免业务逻辑交叉,严格遵守Service层单一职责原则。
4.存储设计,到家每天会产生大量的营销业务数据,对于开发人员来说要时刻关注存储的情况其中包括DB和Cache等,避免写操作性能降低导致数据不一致问题的发生。
5.锁设计,当使用分布式锁时不仅要考虑锁的获取、释放,还需要关注重入性的问题,避免因为分布式锁使用不当导致系统的吞吐量降低。
6.代码评审时关注代码规范,代码中避免取反逻辑的判断,提高代码的可读性、存储层的表结构、索引、大key、热key等问题。
7.业务灰度,上线后进行多维度灰度上线,例如按节奏慢慢开放灰度商家、门店、运营人员等,当业务稳定运行一段时间后逐步开放给大KA商家、门店、运营人员等,尽可能规避资损事故。
8.问题扼杀在摇篮,在运营人员前期创建数据时,营销警卫订阅各营销服务消息,结合预制预警规则及时发现风险数据,并实时反馈到运营。
9.当业务需求上线前期,研发、产品、业务侧建立良好且有效的沟通机制,对灰度数据做好重点数据指标监控和报警,如果产品功能存在设计不合理的场景尽可能在灰度阶段暴露出来。
  • 事中发现

    1.营销警卫接入提单消息,基于预先制定好的预警规则,例如促销的每天限购限售、营销数据叠加等,实时处理营销业务的数据指标,包括促销、优惠券、实时价、补贴规则、预算等数据;在C端用户提单那一刻就检查此类数据是否存在资损风险; 当“事前规避”未发现数据问题的前提下,“事 中 发现”阶段又对营销数据进行了二次检查预警 ,这样做的优点是基于业务数据流做了一次Double Check。
    2.分析营销数据指标,结合Flink的能力实时计算营销业务重点指标数据,例如券接口的领取、使用量、核销量、TOP地域、商家、门店、品类、SKU等维度数据;将营销活动的实时数据和离线数据结合,进而发现刷单、黑产用户利用平台或商家营销漏洞从中牟利。
    3.营销警卫将标记的风险数据实时反馈到运营侧,运营人员对该营销数据做二次检查是否存在资损风险,如果存在风险及时取消线上促销数据,进而降低由于运营人为失误所导致的资损问题进一步扩大。
  • 事后恢复

    多渠道实时追平营销数据,在“事中发现”阶段的问题数据实时反馈到研发、产品、运营,运营人员收到业务报警消息后发起逆向操作,例如将促销、优惠券取消,往往B端系统在后台可能存在大量的处理数据任务,从而可能导致逆向任务未及时执行;此时营销警卫在消费提单消息后,针对营销类(如促销、优惠券)数据不一致的问题主动发起促销、优惠券的逆向流程,进而降低资损问题进一步扩大的风险。通过发现的线上问题和对事故经验总结,反哺事前,从而形成飞轮效应。

三 成果及规划

成果
  • 避免资损

    自营销警卫上线以来在到家平台发现了多起线上问题,例如促销数据状态不一致、运营误操作创建大额优惠券、商家错误创建促销,将原价近万元的手机设置促销价为1元等。
  • 赋能研发和运营

    1.营销线的研发在业内属于“高危”工种;在现实场景中,即便按照严格的项目流程推进需求落地,但往往在需求迭代中也会存在很多变量例如人员变更迭代、需求变更等;以上这些问题如果未及时发现和反馈,就会导致一些隐形的问题很难被发现;那么此时营销警卫沉淀下来的数据就非常有价值。
    2.对营销线研发、产品的价值,营销警卫的业务报警数据,研发、产品对生产环境系统运行情况有一定程度的了解。
    3.对运营人员的价值,营销警卫的多维度的实时数据指标为营销活动的提效提供数据参考依据,帮助运营及时调整营销活动的运营策略。
不足
营销警卫上线后也存在一些不足,如预警机制中将价格作为一个监控的维度,商家的价格数据差异性非常大,价格问题报警准确率很难提升。
未来规划
1.继续迭代完善预警机制和业务规则,不断提高预警数据的准确率,降低误报率。
2.营销警卫沉淀的数据目前只在研发内部使用,后续将一些业务数据指标反哺运营,根据历史营销数据、历年营销日历,当运营创建营销活动时给出营销价格建议,降低运营误操作风险。
3.后续将和履约团队打通,支持逆向操作订单,最终将平台、商家资损风险控制到最低。
4.现阶段预警机制基于人为设置规则和人工标记风险数据,后续将警卫沉淀下来的特征数据结合深度学习模型,自动识别营销、价格的风险数据,进而减少人为干预。