KOO业务运营支撑系统简介
一、简介
KOO业务运营支撑系统是一个灵活，强大的实时运营工具，可以高度灵活配置，实时在线修改目标用户筛选逻辑和触达方式，快速满足产品需求，快速上线。
KOO业务运营支撑系统结合公司平台现有的系统，承接KOO分期标准化和个性化营销需求，可实时监控用户行为，实时做出判断是否符合目标用户，进而做一些特定的营销内容或者激励措施。提供了触达、发券、提额、返现、落地页活动等功能，同时也承接了KOO弹窗、KOO资源位的实时目标用户筛选。
二、系统介绍
2.1 名词解释
为了更好的理解全文，这里对本文中的一些名词做一个解释。
入池： 让用户进入到运营活动中 运营活动（campaign）: 具体的一次运营活动，比如老客纯触达活动 活动Plan（plan）: 运营活动的某一个分支，比如话费月月充，20号未领券的逻辑分支 活动主体: 运营活动对用户进行什么行为，比如发券 用户触达（reachway）: 活动主体执行成功，对用户进行触达，比如短信、微信客服消息、站内信 用户变量（var）: 通过用户ID，进行实时查询计算得到的变量，比如额度、是否绑定了微信 活动规则（rule）: 通过对活动进行配置规则，让不同的用户进行不同的活动Plan。规则是由一些用户变量+自定义函数写的一串jexl表达式的脚本，自定义函数是一段业务逻辑的封装，可通过用户ID或其他查询到的数据进行逻辑判断，在系统中定义好自定义函数后，可以在活动规则中灵活应用，自定义函数封装的好坏一定程度上决定了活动规则的灵活程度和系统二次开发的工作量 动态文本: 因触达的文案中会带有用户变量值，所以会使用占位符，触达发送时，进行变量替换
2.2 流程说明
以一个常规的触达活动《老客纯触达活动》 为例，讲解整个流程。
老客纯触达活动目的是对进入APP内，10天内未发现金标，并退出APP的用户，进行push挽留。
在开始活动之前，我们一般会在现有的用户群体中圈出一部分用户，就当前活动来说，我们会将所有老客先给圈出来，圈出来的用户全体会带上一个活动标识campaignCode，在系统的后续流程中使用该标识识别用户具体要参与哪个运营活动，这一步骤在我们称作入池。当前系统支持的入池方式有：实时消息MQ、离线数据-Impala、线上实时数据以及静态数据导入，除了实时消息MQ，离线数据-Impala、线上实时数据、静态数据导入均可以通过配置cron表达式通过定时任务重复进行，也可以手动进行触发。
入池后的用户系统会以入池时打上的活动标识campaignCode判断该用户应该要进入的运营活动，系统加载本次运营活动对应的活动规则后，会让进入到该活动用户进入规则的决策，在名词解释中有说明，活动规则是由一些用户变量+自定义函数写的一串jexl表达式的脚本。活动规则决策后，会输出一个planCode，planCode对应运营活动的某一个逻辑分支。
运营活动plan一般由2部分组成。第一部分是动作，系统内置了一些动作触发器，如发券、提额等；第二部分是触达，系统内置了一些触达器，通过简单的配置即可对用户发送相关的触达消息。用户进入到具体的某一个plan中后，会依次先执行该运营活动对应的动作，动作执行完成后再依次执行触达。如果某一动作执行失败，则停止后续的触达，一般而言一个plan仅存在一个动作，某一触达器执行失败不会影响其他触达器的执行。
触达器对应的触达文案可设置用户自定义变量，达到不同用户看到的文案差异化，在配置对应文案时，将差异化的部分配置为占位符，占位符对应的变量可以是系统内置的用户变量，也可以是在执行规则时生成的一个变量，通过上下文context带入到触达器中，在发送时进行变量的替换。
2.3 系统架构图
通过流程说明部分，我们了解了一个常见触达活动在系统中的执行步骤，对活动执行大家有了一个基本的印象，接下来我们从整体看下系统的模块划分。
架构图中最上层数据接入层，这部分对应的是活动流程中的入池部分，触发节点可以是由公司PMQ实时消费触发，也可以是由XXL-JOB定时任务触发。
业务处理层是KOO业务运营支撑系统的核心部分，提供了变量获取、规则执行、触发action、触达通知、数据记录、数据统计等核心功能。系统action模块内置了发券、提额等动作，随业务发展，可通过接口扩展新的action，通过在活动中配置对应action灵活使用；触达模块当前内置了一些触达器，这些触达器对接了公司不同的服务，如微信群发对接的是微信中台的群发消息接口，若需要新增触达器，后续只需要通过触达器接口扩展即可，使用时再在对应的活动规则中配置。
系统的很多功能实现依赖公司现有的中台服务，如用户相关的变量是调用用户组接口查询的，标的相关的自定义函数查询的则是标的中台服务。
2.4 变量
系统将一些用户的共有属性或者业务定义抽象成一系列变量，通过用户ID，进行实时查询计算得到的对应的值。
当前系统已累计定义了79个变量，如用户姓（firstName） 、性别（gender）、新老客、bizId、最近一次还款成功的时间等
变量可以用于在规则中参与活动的逻辑判断处理，也可以用于触达文案中，作为占位符实现文案的差异化等，常见的差异化文案配置如：“尊敬的${firstName}${gender}”，比如姓黄、男性，则会变成“尊敬的黄先生”文案。
2.5 规则决策
主要是基于Apollo配置中心，利用JexlScript模板引擎实现的。
运营活动的规则决策返回的是planCode，对应的是一个活动plan，而资源位、APP弹框对应的规则决策返回的是一个布尔值，表示符不符合目标用户条件。
规则决策脚本除了一个返回值以外，还可以输出一个执行脚本对应的上下文，我们可以通过这个上下文在规则执行过程中保存一些后续流程可以使用到的变量，如上文中提到过的差异化文案的占位符等。
2.6 触达器
当前系统内置了APP PUSH触达、站内信触达、微信客服消息触达、微信群发消息触达、微信模板消息触达、短信触达等。
以一个线上在用的短信触达配置为例，@type字段标识使用的是哪个触达器，templateAlias字段标识使用的短信模板，parameters中是短信模板需要使用到的动参，${cashAlt}、${lowDiscountCouponType}为变量占位符，会在触达发送时，替换成对应的值。
{"@type": "com.koo.boss.framework.rw.SmsReachWay","templateAlias": "tpl_xccdzhcd1_XXXX","parameters": {"cashAlt": "${cashAlt}","couponType": "${lowDiscountCouponType}"}}
三、应用场景
KOO业务运营支撑系统主要的应用场景有以下3个：
运营活动 资源位、APP弹窗目标用户实时筛选 首页、落地页活动
系统自2020年4月上线以来，经过不断的迭代发展，承接了KOO的用户端营销活动与销售端营销活动，目前线上生效的运营活动有106个，日均生成的活动记录50万条以上（仅通过目标用户筛选的记录数）。
作者简介
tianci 信也科技研发资深专家