手淘双11最新实践:PopLayer弹层领域业务研发模式升级-阿里云开发者社区

开发者社区> 开发与运维> 正文
登录阅读全文

手淘双11最新实践:PopLayer弹层领域业务研发模式升级

简介: 背景 近年来,各大APP内的弹层需求逐渐增多,以手机淘宝为例,日常的弹层上线频率为单端每月50次左右,而在大促期间可以达到240次以上。在手淘内,各类弹层业务都会通过PopLayer中间件的能力进行管理。但业务往往会遇到开发弹层难、慢、稳定性差的种种困难。对比于往年业务研发成本较高的现状,PopLayer在今年提出了【低研发搭建模式】来解决这类问题,形成一套快速搭建+可视化+多端多场景通用的解决

背景

近年来,各大APP内的弹层需求逐渐增多,以手机淘宝为例,日常的弹层上线频率为单端每月50次左右,而在大促期间可以达到240次以上。在手淘内,各类弹层业务都会通过PopLayer中间件的能力进行管理。但业务往往会遇到开发弹层难、慢、稳定性差的种种困难。对比于往年业务研发成本较高的现状,PopLayer在今年提出了【低研发搭建模式】来解决这类问题,形成一套快速搭建+可视化+多端多场景通用的解决方案,在日常与大促期间得到了广泛应用:

  • 研发效率升级:弹层业务的上线成本从3天+,降低到2小时左右
  • 业务覆盖率高:双11大促期间的业务覆盖率达到75%
  • 稳定性极佳:大促期间线上0故障

 

在各类APP都逐渐走向存量时代,精细化流量运营的今天,弹层作为一个可以随时随地产生内容并带来高流量的强运营手段,已经从低频需求,变成了面向各类人群触达的高频需求。作为业务支撑方向的中间件,如何为业务提效,将业务的关注重点从开发转向内容运营,助力其完成触达矩阵,成为了一件非常值得探索的事情。

 

PopLayer

弹层,是一种强触达用户的交互形态。PopLayer的定义,则是一个可以在任何APP页面上,在指定时间内,对页面无侵入地弹出任何内容的弹层中间件。其业务定位,则为触达各领域用户的重要流量场。

为了便于理解,下面以手淘首页近期Pop为例,将手淘内的Pop业务分类举例介绍(本文中Pop即指弹层):

  1. 大促氛围打造

大促全屏揭幕动画

全屏红包雨

开售倒计时提醒

 

  1. 增强用户体验


  

死亡恢复浏览飘条

 

  1. 红包发放&提醒

星秀猫开奖

 

红包催用提醒飘条

 

  1. 用户指引

会员码模块入口迁移提醒

 

可以看到,弹层业务的交互形态是灵活多变的,业务目标诉求也各有不同。其背后有着各自业务层面的复杂诉求和增长目标。PopLayer为此提供了一套端侧弹层管理SDK+任务管理系统的整体解决方案。

PopLayer常规任务管理流程

注:PopLayer是以端侧中间件为核心进行建设的,其中每个环节都有比较复杂的链路可以展开,本文不展开讨论端侧细节,主要讨论研发效率方面。

 

在这套流程中,对业务方负担最重的,也是研发耗时最重的,便是前端页面的研发以及服务端接口的研发。且各个业务的曝光预判接口不断累积,也带来了非常大的资源浪费与QPS压力。随着弹层业务逐年增多,这套模式的弊端越来越凸显:

  • 研发效率低下以日常期间观察,研发一个图文类型弹层,至少需要一个前端人员投入三天以上时间+一个后端人员投入三天以上时间+测试人员投入一天以上。
  • 运营效率低下。运营策略往往受限于研发成本、资源调控、以及上线时间等等问题,而无法灵活展开与快速迭代。尤其在大促期间,很多快速决策的运营玩法无法及时且稳定地落地,丧失了关键时刻获取流量的机会。
  • 研发质量难以保证。不同于整页研发,弹层存在一些特殊需要注意的问题。而研发人员接入PopLayer的流程熟悉程度往往有限,很容易因缺乏经验而产生线上异常,比如只有背景黑色遮罩弹出而内容加载失败(可以想一想会是什么状况)
  • 业务数据指标没有统一标准,无法形成客观统一的业务指标,无法通过数据快速定位问题,无法形成有效的数据沉淀与对比。
  • 整体方案难以沉淀复用。

这样的研发成本,对于Pop这类往往需要快速响应的业务需求,是远远不能满足的。尤其在大促期间,对时效性要求很高,一个Pop从决策到上线,可能仅仅只有1-2个小时的响应时间,一旦错过时机对业务的流量损失是巨大的。

 

经过建设搭建模式,这套陈旧野生的研发流程终于得到了改变。如今,通过新模式,一个常规的单图Pop几分钟就可以完成搭建。业务方可以彻底解放双手,集中精力在更加优质的内容编排与制作上。

PopLayer搭建模式对研发流程的影响

PopLayer搭建模式

Pop业务背景分析

经过长期与业务深入合作,我们发现弹层的需求往往有一定的规律可循。PopLayer领域下的业务特征大体如下:

  • UI结构轻量:主要为底图+内部图文混合的UI结构,视觉复杂度有限
  • 点击交互可枚举:跳转页面、关闭Pop、发送后端接口、切换内部子页面等
  • 组件复用性低、整体复用性高:每个Pop内部可复用的组件几乎不存在,更应该以一个完整的Pop作为一个模板进行维护和复用
  • Pop特有逻辑较多,比如疲劳度规则、各类数据来源变量解析等

 

那么实现一套统一标准的搭建方案,从前后端等各个方面逐个击破,来承载业务的大部分高频需求,支持其快速、低研发迭代上线,便成了解决这类问题的首选方案。

得益于这套标准化的前端协议规则,我们可以将PopLayer的触发范围,从APP站内触达,向其他流量场横向扩展,比如Android桌面、H5环境等,这部分后文将会展开讨论。

 

搭建模式架构

搭建模式方案框架图

 

我们通过锁定 低研发搭建+多端多领域统一触达 的解决方案,支持运营与业务快速完成各类弹层小时级上线。其链路主要包括如下几个部分:

  • 搭建
    • 设计一套Pop业务域内的统一业务描述DSL,来描述Pop的全部UI架构、数据提取规则、交互逻辑等等内容。以其为核心,完成搭建与各端各领域的解耦
    • 搭建IDE,提供友好的编辑界面、实时动态预览、真机预览等业务服务,最终产生标准DSL内容
  • 解析
    • 探索除APP站内之外的更多触达领域,包括Android桌面环境、H5环境
    • 研发DSL运行时解析引擎,并完成统一体验的Pop渲染及交互
  • 任务管理服务
    • 提供一体化人群预判服务
    • 提供权益、AB与模板搭建的打包配置能力,无需业务方自建实验、自研权益对接
    • 将单场景多Pop情况下的预判QPS压力,降低为单场景组合预判模式,有效降低服务端压力

 

搭建

搭建与DSL

DSL,即领域特定描述语言,是为了解决特定领域问题而形成的编程语言或规范语言。在Pop业务域下,我们无需形成编程语言,甚至追求尽可能低研发,所以这里的DSL即为一种Pop业务域范围内的规范描述语言。

Pop的DSL格式为常用的JSON格式。其整体结构为pages-UI动线、props-变量解析、requests-请求接口、env-环境全局配置。

 

下面我们从交互动线结构、变量解析、事件结构、疲劳度几个方面分别介绍DSL描述的主要内容。

 

  1. 交互动线与UI结构

 

交互动线

以如上的测试Demo为例,我们可以看到其基本动线为:展示开奖图文,点击后,进入第二页红包获取图文。但实际针对部分不同策略的用户,会如第二个视频,直接展示其红包获取图文。

对应到DSL,我们提供了多子页面+多版本的描述方案,即通过创建多个子页面+每个子页面的多个版本来完成动线素材,并通过设置事件动作,完成动线串联。对应到DSL的结构,即通过pages+vers以树形结构分别描述各个子页面版本。其整体示例如下:

 

布局版型

Pop的布局版型是多种多样的,但基本可归类为如下几种:居中、四角挂角、四边贴边。DSL设计中,每一个子页面都可以单独设置其布局版型。不同的版型,会以不同的布局逻辑计算其大小位置。

 

 

UI组件

Pop形态下的UI组件,基于围绕着如下几个类型展开:图片、文本、视频、容器、倒计时、点击热区等。即通过提供大图或视频为背景,并通过容器+内部组件形成内部复杂的界面布局。我们针对各个组件提供了统一的布局配置+各自不同的素材配置。以一个倒计时组件为例:

 

  1. 变量数据提取与绑定

 

变量数据提取

Pop的内容与服务端数据做绑定时,需要提供一套提取数据的描述方案。而数据来源因Pop的整体链路设计,存在多个可能来源。我们通过 指定数据来源+提供插入式Mtop接口配置+接口数据提取Function 完成数据提取的设置,形成一个变量。仍以上述Demo为例,其中红包金额的变量为服务端Mtop接口返回数据。其提取流程示例:

即通过预判MTOP接口数据源,通过JSONPath,并指定其数据位置完成提取。在某些较为复杂的情况下,有时数据来源需要多层解析(JSONPath+URLDecode+URLParse),那么也支持其设置串行多层解析。

 

变量绑定

解析结束的变量,即视为一种全局资源,其可以绑定到各种内容与其他数据上,哪里需要哪里搬。比如图片地址、文本内容、toast内容、跳转地址、MTOP请求参数等等。其实现方案为常用的字符串模板表达式${prop_name},进行运行时替换。

 

  1. 事件结构

大多情况下,Pop内的事件,即为用户点击事件,但随着业务复杂度的提升,例如视频播放结束、视频加载失败、倒计时结束等时机也需要响应事件,我们便提供了统一的事件描述,方便挂载到各个组件事件配置上。而事件的类型。即为跳转场景、切换子页面、发送MTOP接口、关闭Pop等,我们分别对这些事件提供了对应的封装描述。此处细节较多暂不展开。

 

  1. 疲劳度

疲劳度是Pop的重要组成部分之一。疲劳度的设计分为疲劳度规则+疲劳度消耗规则。例如Pop需要用户每天曝光不设限,但点击后当天不再弹出。那么其疲劳度规则为一天一次,而消耗规则即为点击时消耗。通过这样的实现方式,则可以非常灵活的实现各类疲劳度需求,做到想怎么弹就怎么弹。

在DSL的曝光、关闭、以及每个事件结构中,均有疲劳度消耗规则,而疲劳度整体规则,则通过不同的疲劳度表达式完成配置。

 

搭建IDE

IDE的核心功能,即为业务用户提供一个实时可视化、随时可真机预览的一站式搭建编辑器。其产出,则是产生一份描述业务完整需求的DSL内容。目前已为业务提供包括页面搭建、数据管理、曝光判定、疲劳度规则、降级策略、埋点配置等方面的搭建服务。

搭建IDE

解析

如方案框架图所示,搭建模式的目标不仅仅是在APP站内完成Pop触达,还需要在Android桌面、站外H5这样的环境里完成一站式多端触达。我们可以把目前涉及的几个流量域,称为触达领域。

APP站内的触发流程,即PopLayer端侧中间件,功能上有非常丰富的积累,可支撑几乎所有Pop业务的各方面诉求,此处不进行展开,本文将从弹出Pop后的解析引擎、Android桌面的触达领域支持方面进行介绍。

 

运行时解析引擎

针对不同的触达环境,需要形成各自的运行时解析引擎,目前我们完成了APP站内引擎:负责站内+Android桌面的解析渲染,以及H5站外引擎:负责H5环境下的解析渲染。这里我们主要针对站内引擎进行介绍。

 

PreDisplay + Running

解析引擎的主体工作流程,分为PreDisplay阶段:获取DSL、获取各环境数据、解析变量、完成UI渲染并曝光,以及Running阶段:在曝光后的事件交互处理。

解析引擎工作流

在执行display之前,Pop为隐形状态,用户无感知。经过如上图的DSL解析、同步各类环境数据、变量解析、曝光判定、素材加载等流程后,通过display接口,完成最终曝光。

为了达到双端统一的渲染效果、高适配性、以及高性能渲染的要求,站内引擎的底层载体目前为Rax方案。基于Rax完善的工程化支持,我们得以完成一系列上层方案,无需过度关注动态性、适配性等问题。

 

Android桌面弹层

对于手淘这样日活流量足够大的APP,其Android桌面的触达流量价值同样是巨大的。相比APP站内的Pop触达,其更加拥有包括加强唤端、二方流量交换这样的独特价值。在有规则规范的前提下,我们可以通过端侧中间件建设,把Pop搭建的能力无差别的输出到桌面环境,使其成为Pop触达生态的一环。其具体的触达形态,则可以是顶部消息、挂角提醒等。其底层实现方案为Android悬浮窗。

 

桌面Pop的效果Demo如下:

桌面Pop方案框架

 

首先,我们将桌面与站内进行了搭建能力对齐,使一个搭建产生的页面,即可以在手淘里弹出,也可以在桌面上弹出。为此我们抹平了底层方案不同带来的差异,包括:

  • 搭建模式与站内一致,同样采用标准DSL+解析引擎完成渲染
  • 通过控制Window添加次序来对齐层级管理
  • 通过控制视窗大小位置,控制其可绘图区域;通过搭建输出可视区域位移量,对视窗内容进行位移还原窗口内容

 

另外,我们提供了桌面环境的特殊处理:

  • 增加了切换桌面触发时机(计划触发,适合计划常驻),并打通了ACCS消息触发时机(即时触发,适合消息类型)
  • 增加了自由拖拽、边侧自动吸附功能

 

由于桌面环境的特殊性,应避免对用户形成严重的干扰。那么桌面触达的规则管理则十分重要。目前我们设计了如下避免过度干扰的规则:

  • 桌面环境的Pop必须有明确明显的关闭按钮
  • 切换其他APP时,需要将Pop内容进行隐藏,对于Android高版本则进行倒计时后自动关闭设置
  • 桌面的弹出管理底层与站内一致,采用分层分优先级管理,并对一次桌面切换的曝光次数进行上限设置

 

任务管理服务

从上述任务管理流程图可以看到,业务对于曝光预判、业务数据方面都是需要服务端的人力投入的。即除前端的研发成本问题,服务端同样面临类似的问题。我们梳理业务目前痛点如下:

  • 人力消耗大,大促响应时效性差
  • 机器资源消耗大
    • 全量配置下发+全量接口预判的模式,导致单活动机器资源消耗大
    • 单场景(比如手淘首页)下的Pop往往存在多个,活动之间筛选独立进行,导致机器消耗总量增长快(QPS总量随活动数线性增加且无上限)
  • 稳定性风险高
    • 临时开发的模式,加上人员开发质量层次不齐,稳定性很难保障。
    • 业务需要自己投入精力维护稳定性,特别是每次大促的时候应对突发流量

 

为此我们实现了对业务进行一站式托管服务。核心目标为:

  • 实现权益、导流这两个业务领域的低研发极速上线
  • 降低机器资源消耗,在线活动数量不再受机器资源限制
  • 托管业务全年0故障

 

通过拆解上文的任务管理流程图,可以看到服务端的工作主要包括曝光预判接口,以及页面内的业务数据接口。我们针对两部分分别进行部分托管建设,架构图设计如下:

任务管理服务

  • 针对曝光预判接口,我们提供了单场景多活动的人群预判复用能力,即将人群圈选的预判模式统一集中管理,底层与奥格人群平台二方包打通,上层单场景仅透出一个整合接口。从过去每次切换页面触发N次预判接口,变为仅触发一次。业务也无需自研人群接口,仅需把人群包ID进行配置即可。
  • 针对内容数据接口,我们仍在建设中。计划通过底层打通了拉菲权益平台二方包,将权益类型(红包、优惠券等)直接整合进搭建体系中,业务无需进行复杂的权益能力对接,仅需提供权益ID配置即可。

 

整体效果

除文章开头提到双十一期间的业务覆盖率已经达到75%之外,得益于搭建模式对研发效率的提升,今年双十一期间,手淘内Pop的业务量和整体流量也有了大幅度飞跃:

除此之外,今年我们快速稳定地响应了大促期间的全部紧急需求,避免出现过去几年因封网、研发效率等问题带来的无法上线Pop的情况。

 

写在最后

PopLayer目前除手淘外,已经服务了集团众多APP,包括天猫、淘宝特价版、闲鱼、淘宝直播、饿了么、Lazada、零售通、AE等等。后续也将继续以手淘为核心,服务更多的集团业务。

通过双十一大促期间以及日常的业务覆盖率,我们印证了搭建模式对业务的价值。站在业务的角度思考,Pop这类“既轻量又复杂”的业务域,经过一番深挖的底层支持,可以大幅度破除业务的桎梏,让其解放双手,去快速通过“提出idea-搭建-AB-看数据-再次迭代”的模式得到最佳的业务结果。这套业务研发模式的优化,从思考如何研发变为如何尽可能封装研发,对于相对轻量级的业务域来说也是有输出价值的。

后续,我们一方面将会继续完善相关建设,将AB、标签+推荐系统、引擎加载页面性能优化等等进行深度挖掘,从研发效率提升,升级到业务价值提升;另一方面也会将Pop的建设经验沉淀成流量域方法论的一部分,输出到其他流量域中,为业务探索与构建更有价值的流量增长矩阵。

 

手淘平台技术

我们背靠淘系基础架构和厂商,既有立足5G适配、网络加速、图片体验、网关调用、大内容上传下载等核心技术支撑业务体验升级和改造,

又为用户增长提供消息推送、浮层搭建、厂商触达、外链拉端等流量端能力,并沉淀一系列如最小核、全链路数据等架构能力,为手淘及产品升级提供平台支撑,并成为集团移动端基础设施。

 

职位:Android研发工程师、iOS研发工程师

感兴趣的同学可将简历发送到:yangqing.yq@alibaba-inc.com,获取优先内推资格!

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享: