营销活动业务研发模式的升级

快手电商无线团队
11,153 阅读7分钟

你是否经常被营销需求所困扰呢？

产品：大促马上来了，得赶紧做营销活动规划啊

运营：好勒，给主链路、活动页面上挂件、弹窗

产品：最好挂件、弹窗可以复用，除了给大促用之外，平时活动也能用到。另外配置的时效性也得考虑下。

运营：那不就是要求挂件、弹窗做到动态化吗。

产品：对啊对啊。短时间内可配置生效，才方便我们根据活动需要灵活调整啊。

运营：你说的对。如果能做到那就真的太好了。但好像现在每次搞个新的营销资源位，开发就说得提需求、排期开发、测试，入下个版本。真的太麻烦了。

产品：基建能力不行啊。正常这些都应该具备的。而且理想化的产品形态应该做到任意页面任意投放，可以配置一些常用的规则，后续还可以根据用户行为智能推荐。

运营：你说的太对了，现在技术基建能力太薄弱了，每次搞个营销活动都是困难重重。我们赶紧让开发把这些基础能力补上吧。

开发：

背景

在电商的各种大促活动中，运营经常会通过各种方式来进行流量控制，比如挂件、弹窗、悬浮条等。快手电商早期营销基建比较薄弱，为了快速满足需求，通常以Native为主，部分RN、H5为辅。

然后传统做法往往需要和当前页面做强绑定，效率低，难以复用（Native开发的内容往往只能使用一次，不存在复用价值），上线周期长；另外基于电商的特性活动多、调整快、时效性要求高，这两者的特性无法调和。那么，是否有一种手段可以最大程度的解决问题呢？

业务思考

资源位后台作为配置物料入口，指定页面，配置规则，圈定人群；营销SDK作为端侧引擎，精准匹配页面，解析规则，二次校验，渲染展示；

方案设计

方案调研

阿里PopLayer

投放能力：页面事件拦截+本地筛选排序+接口二次判定

容器能力：H5渲染

对于大多数常规场景来说，Poplayer可以满足日常所需。但是对于直播间这种更复杂、更偏重于交互的链路来说，就有点捉襟见肘了。

技术挑战

基于Poplayer的设计思路，结合自身业务特性，我们需要构建一套更强逻辑&分层渲染能力的方案。

端规则引擎

支持任意页面任意投放：配置资源位运营只会关注投放的页面、内容及规则，因此需要有端规则引擎来支持任意页面及事件的触发和规则的匹配解析。

定义一套通用的规则，满足前置的逻辑处理能力，如延迟、定时、关键词、生效版本、生效时间等

用户交互事件拦截

...

多引擎容器

渲染引擎支持视图无侵入注入

URL驱动渲染，灵活投放各种容器

跨容器间的通信

用户交互处理

...

整体架构

经过上述业务需求拆解及技术难点的剖析，方案的整体架构图就比较清晰的显露出来了。

其中投放平台作为运营配置中心，可以根据规则、圈选人群下发。另外运营之间的投放是相对独立的，可以不受之前配置限制。

端侧引擎负责协议的管理和规则的处理，在端侧做数据的清洗。假如当前投放的物料无需服务端二次校验，端侧校验无误后，则直接渲染展示，减少服务端的消耗；

渲染层负责动态化协议的渲染及容器管理，事件的统一调度和处理。

通过数据埋点，完成数据链路的建设，监控大盘性能指标及业务指标

关键点

触发器

为了支持任意页面任意投放，我们得感知各页面的页面名及生命周期事件（常规触发），比如pageEnter，pageResume，PagePause，PageLeave

如何感知呢？如果继承于同一个业务基类或者平台有统一的事件上报处理中心，那么获取页面生命周期及公共参数就相对简单；同时针对特殊case，提供显示api，让业务注册对应的页面上下文信息。肯定有同学跳出来hook是否可行呢？hook最大的影响因素就是存在风险性，另外获取到的信息需要过滤不然非常驳杂。

有些大促活动需要定时开启，我们还得对活动时间进行倒计时监听，另外结合信令、长链接事件来保证时效性

"triggerTimings": [
  {
    "triggerType": "pageEnter",
    "triggerName": "页面进入",
    "triggerParam": {
      "delay": 5
    }
  },
  {
    "triggerType": "signaling",
    "triggerName": "信令"
  }
  ...
],
 "pageBaseInfo": {
    "pageCode": "BUYER_HOME_PAGE",
     ...
  }

匹配器

端侧需要根据投放协议携带的规则进行校验，比如关键词、生效时间、生效版本等。

该层是投放规则能力的解析器，支持前置的逻辑处理。只有匹配通过并且需要server二次校验的，才会后续调用api，最大程度降低服务端的QPS。

"ruleMatcherInfo": {
  "conditionList": [
    {
      "tagName": "version",
      "conditionOperator": "BETWEEN",
      "values": [
        "1.0.0.0",
        "9.9.9.0"
      ]
    },
    {
      "tagName": "time",
      "conditionOperator": "BETWEEN",
      "values": [
        "1631604684000",
        "1632692070000"
      ]
    }
  ],
    "logicalOperator": "AND"
}

用户交互处理

弹窗大小和位置多样，为了支持所有弹窗类型展示，容器默认用全屏的view展示。全屏的view会挡住宿主页面，拦截宿主页面的用户交互事件，而在挂件、底部提示条场景下，用户需要和页面交互，所以有一套机制来处理用户交互事件，可以根据当前点击区域的不透明度判断。默认不捕获任何交互行为。

假设设置的阈值为0.5，点击某个区域的alpha值是1，大于所设的阈值，就可以捕获了该用户的事件操作，然后交与容器处理；当用户点击的位置不透明度小于设置的阈值，用户行为将会透传。

产品形态

最后

业务数据

目前已接入业务场景60+\color{red}{60+}个，展现形式如弹窗、挂件等，覆盖电商主链路及各活动页面；电商资源位营销首选方案，

提效数据

经过多场大促和日常活动的试炼，目前该方案已覆盖到快手电商主链路。从研发层面来看，大幅度提升了研发人员的效率，缩减了开发时间；从业务角度来看，营销活动不再受限于某个页面，内容形式动态化，解决版本覆盖慢等问题；

后续，我们将会继续完善相关建设。一方面提升现有触发、匹配能力，支持更多维度的能力，如AB、人群等；另一方面支持用户行为集的输入，使触发形式更加多元化，从粗放式演变成精细化运营；最后引入端智能，支持端计算能力。

hi, 我是快手电商的zhl

快手电商无线技术团队正在招贤纳士🎉🎉🎉! 我们是公司的核心业务线, 这里云集了各路高手, 也充满了机会与挑战. 伴随着业务的高速发展, 团队也在快速扩张. 欢迎各位高手加入我们, 一起创造世界级的电商产品~

热招岗位: Android/iOS 高级开发, Android/iOS 专家, Java 架构师, 产品经理(电商背景), 测试开发... 大量 HC 等你来呦~

内部推荐请发简历至 >>>我的邮箱: hr.ec@kuaishou.com <<<, 备注成功率更高哦~ 😘

avatar
文章
阅读
粉丝