营销活动是公司进行 用户拉新、交易转化、召回激活、裂变引流的重要手段,在活动业务发展的过程中,一定会遇到两类问题,通用性活动和定制化活动。通常情况下,通用性活动方案无法满足个性化的定制需求,所以我们面向不同用户开放不同的平台能力来解决此类问题,面向业务用户开放SAAS可视化零代码模式帮助用户快速搭建活动,面向研发工程师开放底层PAAS低代码模式让业务自由开发和定制活动,让业务的发展不再受限于平台的规范。既满足了高价值业务需求的支撑,又平衡了定制化业务的诉求。
最后我们慢慢抽象活动业务的共性,耦合活动后台服务,再融合低代码平台打造了一站式活动平台,并将它命名为 魔笛 ,魔笛承载着我们的愿景,希望在技术领域持续探索和突破
在金融场有很多的活动在投放,这些活动大致分为两大类,一类为简单活动、一类为复杂活动,简单活动模式固定,通过简单的配置就能完成，这种活动我们通常定义为可复用活动,比如签到、领劵、大转盘等。复杂活动由于业务逻辑比较复杂且模式不固定,所以可复用性比较低,比如裂变类、信用红包、膨胀金活动等。随着业务的快速发展,活动的场景和种类越来越多,活动研发每天都在承接着各种各样的活动需求,由于资源有限,业务研发只能优先开发高优先级或者是高质量的活动,这样那些低优先级或者低质量的活动的发展就会受到限制,一开始可以借调人力进行支持,但也不是长久之计,因为资源永远是有限的
高代码开发是传统的解决方案,前端和服务端根据产品和UI的效果图进行开发,然后通过测试后发布上线并进行投放
•优点: 可以快速支持活动的需求,具有很大的研发空间,可以高效的实现活动效果
•缺点: 对于已上线的活动,一旦产生业务逻辑和内容变更的需求,就需要走开发、测试和上线的流程。如果线上有问题,则响应和解决问题的时间会比较长,成本较高。
这种模式属于是高代码开发的一个进阶优化。产品和运营沟通运营活动在线实时修改的需求,例如奖励、展示的内容、规则和策略等。研发工程师会根据产品的需求抽象出固化的配置,然后根据配置开发活动,活动上线后活动落地页会根据后端提供的API动态读取配置并实时渲染和展示活动。这种模式简化了配置缩短了业务逻辑和内容变更的路径,满足了线上实时变更的诉求
•优点: 该模式把活动的通用配置抽象出来,固化为活动的后台配置,帮组运营实现活动策略的实时变更,很大程度上提高了研发效率。
•缺点: 如果针对非周期性的活动进行活动配置的抽象和固化,则会增加开发成本,投入产出比会比较低。
各业务团队为了提升研发和运营的效率,开始沉淀通用的模板和活动配置,从而产生了不同的具有业务特性的活动管理后台
•优点:该模式可以快速生成预制的H5页面和配置,将常用的活动模板和H5页面内置于活动管理后台,活动运营就可以在活动管理后台选择符合需求的模板,快速完成创建
•缺点: 业务团队通常会根据自身的业务特性去创建活动平台,有资源的团队会持续优化和发展自己的活动模式,对于资源不足的业务团队,就无法在活动平台建设上有足够多的投入。由于不同的业务团队在自身发展和业务范围存在差异,因此可能无法将自身沉淀的能力赋能其他业务团队,随着营销业务的高速发展,活动后台的这种模式如雨后春笋一般涌现
通过分析活动传统的开发模式之后,并将相似能力和功能进行抽象和沉淀,让不同的业务团队都入驻到一个平台去开发活动,避免企业出现烟囱林立的现象,使彼此联系,打破信息孤岛,同时实现降本增效,提升内部生产力。
一个活动由页面、组件和素材组成,页面一般为H5页面,组件又有UI样式、事件、业务逻辑组成,如图所示
可以看出楼层组件和业务逻辑是一个互动类活动的重要组成部分,我们可以把组件和业务逻辑的开发交给业务团队再结合平台的能力一起来完成共建,这种模式可以走出现有活动开发遇到的困境,达到快速拉齐活动开发能力的目的
前面介绍了三种活动开发方式,都会用到一些基础能力,比如页面管理、组件管理、模板管理、配置管理等。每个活动开发完之后都会走测试、发布上线等环节,所以还需要发布和审批管理、用户权限管理等,如果需要验证活动页面转化效果还需要用到A/B测试的能力以及数据看板等能力,我们将这些基础能力进行整合,让业务只关注活动本身,基本上可以满足大多数的活动需求。
随着活动的增多,平台会积累大量优秀的活动模板,这些模板不仅服务于创建的业务方,还要赋能于其他业务方。让每个业务的创造力在这个平台上流动起来,更好的为平台用户提供服务。
虽然我们建设了活动平台的基础能力，但是活动在创建过程中也会涉及多系统的操作,比如费用、权益、活动搭建（可视化、通天塔、98k、自研）、互动玩法搭建（如任务、抽奖、裂变等）、CMS、鹰眼、奇点、银河画像（数资）、数据分析（数资）等,会造成多系统操作成本高,创建活动周期长,流程冗余,配置人效低的问题。解决此类问题我们可以基于活动场景的标准化流程集成费用、权益、活动搭建、素材投放、任务触达等能力帮助运营实现一站式的活动搭建与投放
运营和产品是活动平台的主要用户,他们根据需求在平台上选择模板或者自主创建H5页面和使用现有的楼层组件。一个活动落地页的核心组成部分就是组件和事件绑定的一些业务逻辑,这些组件和业务逻辑主要是研发同学提供,所以业务团队的研发同学也是平台的主要用户。所以需要为研发同学设计一款在线的开箱即用的开发平台,为研发同学带来一站式的开发体验,提升开发效率。
组件是落地页核心组成部分,组件开发可以参考设计稿直转楼层（D2C）的生产模式，无需编码能力开箱即用。对于存量组件需要支持二次开发的能力以及提供一键转换工具,支持多类型的存量工程一键转换。编码的开发和维护需要具备完善的迭代记录以及如何打造开发社区方便平台用户交流、表达诉求。
组件是活动的核心,那么玩法就是整个活动的齿轮,组件和玩法的相互配合,才使活动有了生命力。一般玩法是由多个业务逻辑组成,大部分的业务逻辑实现都是通过高代码实现,我们的业务研发同学每天都在重复开发这些业务逻辑代码,大量的if..else 语句和分支。如果要改变其中的一些逻辑和条件,就要走开发、测试、上线流程。这些低价值的工作并不能体现我们业务研发的价值,如何让业务研发从这些重复工作抽身出来,去做更有价值的事情,图形化的业务流程编排是一个解决方案,可以为研发同学提供BPMN流程编排的开发模式。对于存量高定制的通过高代码开发的逻辑可以提供一个接口服务,把接口注册到平台,沉淀一个业务逻辑。通过流程编排的方式不仅提高了研发效率,缩短了交付时间,而且通过接口注册的方式也能对业务逻辑进行整合。
统一了开发环境,可能会改变业务研发的开发习惯,所以一个友好并完善的开发人员文档是必不可少的。从组件代码初始化、本地开发和调试、接口MOCK、业务逻辑开发、逻辑编排等能力进行文档的编写,最好能附上视频的讲解,还要建立答疑机制和答疑群,方便支持研发同学在开发中遇到的问题。
2022年活动平台用户覆盖了京东健康、京东物流、京东保险、京东科技等,总计用户 (运营+研发) 600+,支持搭建活动1095个。目前平台支持的玩法有 裂变、抽奖、领奖、任务、答题、签到、拉新等,并且已沉淀200+个楼层组件供运营使用,在线运营了多款经典活动,如下图所示
答题、签到、积分兑换活动玩法
领奖活动玩法
商品列表
任务&裂变玩法
拉新玩法
多种玩法组合
主要模块分为活动H5页面、组件的开发与管理、发布管理、玩法和业务逻辑的开发与管理以及表单配置管理等
抽象关系结构,能帮助我们更容易理解活动搭建
•活动页面: 活动落地页,一般为H5页面
•组件: 前端组件
•玩法: 一套API/MQ集合
•业务逻辑: 对应一个BPMN文件或者BFF服务或者外部的一个接口
•Schema配置: 运营配置表单
H5页面的生成主要是通过可视化搭建技术,可视化搭建技术是比较成熟的技术,也是我们经常谈论到的技术,营销活动是搭建系统最重要的落地场景,将可复用的组件通过拖拽的方式放到画布上,生成最终的页面。可视化搭建极大的解放了前端研发对低价值重复活动的开发投入,让技术同学能能够更多的从可复用和可配置的方向去思考活动的实
•页面创建: 创建页面基础数据,包括页面埋点、页面标签、页面场景、页面有效期、页面成员等
•页面编辑: 页面内容的编辑是通过可视化编排的能力,可见即所得。通过预览功能也可以看到投放的效果
•页面发布: 页面修改好之后,投放到正式环境需要走打包发布流程,提交给页面决策人员进行审批。审批完成之后正式环境即可看到效果
一般组件的构成基本结构就是前端UI+服务端业务逻辑的实现,搭建平台也是一样，搭建平台为了弱化运营对业务逻辑的理解成本,把多个业务逻辑的组合抽象成了玩法，那么一个活动组件的构成如下图所示
互动类组件开发分前端和服务端,前端实现组件UI样式,服务端负责开发玩法。组件管理还支持组件的多版本管理及发布版本功能
•组件创建: 创建组件基础数据包括分类、样式类型、标签、组件成员等
•组件版本管理: 组件的每次改动和升级都会生成一个新的版本,可以进行变更比较、历史回溯以及快速回滚等
•组件发布: 每一个版的都支持单独发布,但是生产只允许一个版本生效
一种比较常见的业务逻辑的组织方式是流程图,我们都听说过 " 一图胜千言 " 这句话,我们人类大脑对可视化的信息的处理效率要远高于其他信息,所以流程图式的逻辑编排是一种对大多数人都非常友好的方式。在初期我们也调研了很多的低代码平台,综合接入成本或者自研的成本来进行评估,而且部门内部已经有成熟的低代码相关平台。后面我们采用了BPM流程引擎的方式,MOLO的流程引擎刚好符合我们的需求,通过可视化流程编排的方式,进行业务逻辑的开发。
再后来随着业务的发展.为了满足不同业务团队的诉求,我们也引入了BFF流程编排,BFF流程编排也是可视化的流程图示组织方式,有着比较友好的用户体验和强大的在线调试功能。平台为了快速满足业务团队诉求,也为了后续更方便的扩展,搭建平台抽象了业务逻辑层,帮助平台快速融合多种业务逻辑实现,如接口注册、BPMN编排、BFF服务编排等
概述
•一般是业务已经通过高代码的方式定制和实现了业务逻辑，使用逻辑编排进行沉淀成本会比较高,业务又想把相关能力快速沉淀到魔笛,可以通过接口注册的方式快速接入进来
特点
•主要支持JSF接口的注册,运营配置数据主要从DUCC获取
概述
•通过融合MOLO的流程引擎能力,借助可视化流程编排,把相关活动能力拆成可复用可编排的逻辑单元, 后续有变化和改动,可以尽量少的改动代码, 通过拖拽的方式快速满足业务诉求
特点
•实例隔离: 运营配置数据写入到BPMN文件,配置数据跟随BPMN文件部署并生效,一个BPMN文件一个实例。每个活动都是单独的实例
•控件集市: 可以把可复用的逻辑片段封装成控件,共享到控件集市,可供其他业务团队使用
•独立集群: 可以根据不同业务部署不同的集群
•多版本管理: 支持流程模板的方式,可以生成不同的流程实例版本。通过多版本的管理可以做到快速回滚
•在线调试: 支持在线调试能力,提升研发效率
•触发方式: 支持JMQ和接口触发方式
概述
•和BPMN逻辑编排一样,BFF逻辑编排是另外一个服务编排平台。拥有比较好的用户体验和强大的在线调试能力, 通过不同的编排方式快速满足业务诉求
特点
•配置隔离: 运营配置数据是通过DUCC获取, 多个活动会共用一个实例,但是会使用不同的配置数据
•接口管理: 支持JSF接口元数据管理能力,每个流程的接口实例都是独立的，互不影响
•配置管理: 支持多种配置模式,比如ducc、concrete等
•版本管理: 支持多版本管理,通过多版本的管理可以做到快速回滚
•在线调试: 强大的在线调试能力,非常友好的用户体验,提升研发效率
•触发方式: 目前只支持接口的触发方式,MQ的触发方式还在建设中
前面通过关系模型能看出来,玩法就是一堆业务逻辑的集合,通过玩法的开发流程形成玩法开发的标准和规范
魔笛提供一整套的解决方案,让用户直接在页面可视化区域填写配置表单,用户体验更友好
通过项目规则生成配置表单,配合魔笛提供的SDK获取运营配置数据,满足业务定制化需求。独立表单配置,集合模板市场,通过SOP标准流程让运营进行使用
魔笛后台审核通过之后推送数据到DUCC，业务系统通过平台提供的SDK获取数据
ab 实验是一个非常好的数据驱动归因工具，能够帮助业务解决很多场景下的归因和量化问题，为什么要进行 ab 实验，例如有2个UI设计，究竟是A更好一些还是B更好一些,这样我们就需要实验来进行判定。活动平台AB功能接入试金石,实现页面AB、楼层AB能力,该能力还在建设中,很快会投入使用
活动运营工作台是基于业务场景的标准化流程,集成费用、权益、魔笛、百舸(素材投放)、鹰眼(用户触达)等能力帮助运营实现一站式的活动搭建与投放,前期主要围绕活动前的管理功能建设,以及活动报备入口的统一。目前京东科技所有的活动报备都会走工作台的活动报备线上化流程。和前端共建主基座能力,引入微前端、制定前端交互协议,以及服务端交互标准。 比如什么样的系统通过SOP模式接入,什么样的系统通过活动模板模式接入
活动前主要围绕基座能力以及SOP模块的建设,用户通过浏览模板市场选择合适的活动模板进行创建活动，根据活动状态(草稿态、准备中、已上线、进行中、已结束、已下线) 进行活动生命周期的管理
•首页看板: 统计近30天创建的活动,包括活动各状态数据
•SOP模块管理:主要是各业务系统交互能力，包括运营活动费用申请、运营活动权益申请、任务申请、页面搭建、素材投放、用户触达
•我的代办: 当前承接各个活动创建环节未完成而生成的待办内容
•快速创建活动: 在工作台中快速创建活动，可一并完成费用申请、权益配置、页面搭建、规则创建、投放计划的创建与触达计划的创建
•我的消息: 接入消息中心的Pass组件能力，为后续接各个系统的消息流
活动中主要围绕资源位的管理包括资源位的上下架管理,以及活动参与数据和活动数据监控等
活动后主要侧重于活动数据的分析和活动复盘数据分析等能力
系统根据不同的人群(产品、研发、运营等)赋予了不同的角色
•超级管理员: 权限比较大,拥有系统所有权限,只有部门产品拥有此权限
•产品经理: 拥有活动管理、活动报备、页面管理、组件管理、标签管理、模板管理、审批管理、数据看板等,数据权限根据ERP隔离
•用户运营和产品运营: 拥有活动管理、活动报备、页面管理、组件管理、审批管理、数据看板等功能,运营可以通过该角色完成工作,数据权限根据ERP隔离
•研发工程师: 拥有活动管理、页面管理、组件管理、审批管理、玩法管理、业务逻辑管理等权限,数据权限根据ERP隔离
•实习生: 拥有权限比较少,一般只有查看权限
•客服BP: 拥有活动报备权限、活动报备审批权限
活动平台一路走来遇到了很多问题也遭受了很多的质疑,庆幸的是我们都把问题解决了，特别感谢Molo引擎团队、BFF 引擎团队的大力支持，活动平台的各个功能后续还会继续打磨,也希望各兄弟团队多提意见,你们的意见和建议也我们前进的动力, 让我们一起努力让活动平台赋能更多的业务团队
随着项目的发展，前端SPA应用的规模不断加大、业务代码耦合、编译慢，导致日常的维护难度日益增加。同时前端技术的发展迅猛，导致功能扩展吃力，重构成本高，稳定性低。因此前端微服务应运而生。
结合京东业务研发实际情况，针对后端研发人员，设计一个微服务低代码平台，助力更高效低交付业务需求。现已结业，将我在本次项目中沉淀设计出的设计文档整理成文，期待与大家有进一步的碰撞沟通