三大营销平台建设 第1篇
保利威是企业级视频SaaS领导品牌，致力于通过可集成、可定制的视频直播技术，为企业搭建自主私域直播系统，并提供直播全流程运营与现场执行服务，自2013年成立以来，已服务超过25万企业级用户，深度服务教育、医疗、汽车、B2B等行业。
在保利威的营销过程中，他们发现：
订单与客户没有打通：从市场投放的角度看，ROI的计算逻辑是从线索获取开始，到MQL/SQL就结束了，这条线索是否生成了订单，带来了收益，保利威很难判断。
在发现使用了四五年的CRM系统已经无法满足现阶段的需求时，保利威果断选择更换成了纷享销客。更换系统后，保利威：
打通了营、销、服全流程，将自己的市场品牌、增长获客、私域孵化和销售转化、CSM全线连通，让每一条市场线索到销售订单的转化，都实现了可视化和可量化；
同时，保利威通过CRM数据驾驶舱：
可以全面洞察营销效果，助力营销决策，还实现了智能化的营销培育：百度上投放的每一个词条、知乎上的每一条引流、字节体系里的每一条信息流，都可以清晰地跟踪到订单阶段，它们分别带来的产出以及ROI，该往哪个方向发力，往哪方面加大投入，都能更好地得到判断。
三大营销平台建设 第2篇
针对在 APP 端某一个相同的用户行为，多个业务部门需要有不同的转换方式。比如，我们要在打车的时候，给用户发放优惠券，在支付完成的时候，要给用户发券或者发放权益，以及做一些千人千面的场景。
在这些业务需求来的时候，我们同大多数人一样，刚开始来个需求做一个需求，然后自定义的需求多了的时候，会发现某一相同的用户行为，需要写多个 if else 来进行业务侧的适配，并且随着业务要求的千奇百怪，这套系统运维理解成本也成指数增加，最终到了一个改不动的地步，没办法，那就重构吧。
当一件事做的复杂的时候，我们需要回过头来看下，是不是源头就是错的，因此，我们开始对此进行抽象，我们开始抽象用户的行为，app 的行为，触发的时间，条件的过滤等，于是，一套 TCA 体系就这么诞生了，并基于这套框架，进行后续一步步的散枝开花。
三大营销平台建设 第3篇
陇萃堂成立于1994年，产品以玫瑰系列、百合系列等甘肃特色物产、甘肃道地中药材、甘肃特色文化工艺品系列为主，于2022年推出了蘭啵旺兰州牛肉面品牌，专研兰州牛肉面预包装食品的技术研发、生产加工及销售。
因而陇萃堂在组建了新的营销团队，品牌声量快速扩大的同时，有几个问题需要亟待解决：
以上问题归根结底是营销一体化的问题，上线了纷享销客CRM后， 基本解决了以上问题，陇萃堂实现了：
营销链路闭环，快速拓展渠道：品牌商与经销商高效协同，营销链路形成闭环，对全国业务人员以及渠道商进行赋能，快速突破和拓展线上线下各渠道；
缩短了产品触达消费者的时间周期：通过订货通实现B2B终端的客户管理、产品梳理及资金把控；通过高级外勤推动了渠道策略的落地，掌握了终端促销策略，产品触达消费者的时间周期大大缩短；
市场促销活动形成绝对闭环：TPM费用管理通过品牌管理、预算、客户管理、需求规划、综合销售和营销、零售执行和结算分析等环节的落地反馈，形成绝对闭环管理；
提高了决策时效性与准确性：海量的数据掌握与分析能力，让不同市场渠道终端的销售动态得以可视化，这让陇萃堂的市场决策时效性和准确性得到进一步提高，也更方便做出更好的价格设置、渠道部署、促销规划、产品策略等。
营销一体化除了可以优化营销资源、找到更多增长引擎，打造全价值链的战略营销，同样也有利于组织内部营销意识的重构、辅助战略方向的落地。
增长也许正处在低谷中，但厚积薄发，“猥琐发育”，等到再次亮相的时候，相信我们耐下心来为增长做的一切铺垫都不会白费。
三大营销平台建设 第4篇
编排顾名思义就是一套运营配置后台系统，主要是提供给运营进行营销活动的配置。这块唯一特别可以讲到的是，我们通过一块画布的形式，然后提供给运营，运营在这块画布上，通过我们提供的已有营销素材和组件进行自我绘画。然后产生一个个当下的营销活动，编排完成营销活动后，即可进行相关审核上线。
整个编排后的活动，我们将构建成一棵二叉树的机制，从左到右进行匹配，匹配到的 action 然后为当下需要执行的 action。
用户行为的触发事件，这些触发事件，我们可以用某些特定标识符进行标记，与前端形成一组约定，每次传递时，可以根据该字段进行初步匹配。
定时事件
定时需要执行的事件，这种情况，可以用分钟级别的定时任务进行特定处理，针对于大人群的活动，进行提前下载切片，关于这点，可以参考我之前写的定时器文章，大同小异，大家可以根据自身公司情况去寻找符合自身的需求。
引擎这块，主要用于活动的过滤，筛选出最终命中所需要执行的活动，大体架构图如下：
首先，我们会将所有活动编排缓存在内存中，构建多个符合场景筛选的数据结构和索引去匹配每一次请求。我们引擎的入口可以是 api 和 mq 两种形式，触发者可以是前端、业务方、以及定时任务等，通过 api 和 mq 两种方式进行引擎的每一次运行。
当请求过来时，先进行 trigger 过滤，筛选出符合触发条件的活动，当匹配到符合条件的活动后，我们根据优先级，然后一一进行活动内匹配，通过二叉树遍历的机制，去匹配到当前请求是否能走到该触发节点的执行动作，若走不到就下一个活动，否则就停下执行当前具体 action。
关于这块，我们会遇到很多条件过滤的场景，如上所述，每个 tca 都有不同的 c，我们需要去过滤掉这些不符合条件的动作，这个时候，我们采用到了规则引擎来判断不断增加的过滤条件，减少 if else 的编写。另外，我们也将规则引擎做了一层配置化，利用内部 Apollo 配置平台，将一些规则存储在配置中心进行读取，这样当新增规则时，只需要配置相关 dsl 语句即可，无需代码编写。
同时，我们要确保当前命中到只有一个活动下的一个动作行为，当然这块可以根据业务方的诉求去进行合理的拆解，比如，我可以命中一个 tca，也可以命中一串 tca。
当确定好要执行的 action 后，我们整理当前执行的 action 集合，并将其作为参数调用后续的 ap 项目，来进行动作的具体执行。
ap 我们可以理解为用户命中活动后，所需要执行的一系列营销行为，该过程不依赖于 db，却依赖于各个下游系统，并通过 redis key 来保障执行的幂等和顺序性。
我们在接收到上游传递过来的参数后，我们根据策略进行一波 action 的整理，得到排序后的 action，然后具体去执行这一套 action 营销行为。
我们根据 action_list 依次去执行调用下游，当遇到标记为异步的 action，我们直接无需要等返回，直接协程执行，当遇到同步的需要等待最终返回结果，若返回失败，则停留到当下，并将结果返回。
核心入口伪代码如下：
每个 action 都会实现 execute 这个接口，后续新增 action，只需要两步骤：
接口实现；
加入 switch 可执行对象当中。
一条 action 的执行，会根据 step 和 action index 产生一条唯一的执行 key，同时结束后会产生一个 mq，用于其他业务方的对接，以及自身后续的数据特征沉淀。
当然我们为什么要这么拆分？
原因个人理解最为简单的点，我们将 action 收集成一个素材库，每个 action 有自己独特的标识，然后每次新增的 action，只需要添加 action 对应接口的相关实现即可，若想废弃，也只需要删除指定的文件即可，这样可以保证整个项目的可读性和可维护性，而不用随着项目扩大，而迷失在各处环节的 if else 中，最终陷入到了无法改动的地步。代码一定冗余度，是后续可伸缩的关键点。
当命中执行后，可以收集用户参与的营销活动信息，并沉淀抽象相关用户行为特征，提供统一的特征数据获取服务，这块相当于后续自给自足。
数据特征管理，主要用于前面引擎当中的一些 condition 的匹配，我们针对不同业务方千奇百怪的匹配过滤条件需求，通过数据特征的沉淀，产生一些列数据特征，然后不同过滤条件对应不同特征，从而只需要匹配到当前特征即可满足过滤条件，化简了较为复杂的过滤条件运算，减少了从不同业务方去调用接口获取相关匹配信息。
文章暂且写在这，当读者有兴趣尝试去实现的时候，会发现整个系统内部还有很多细节可以深挖，以及流量增大时的处理、mq 积压、action 重试机制、engine 过滤规则、索引构建等问题，都可以后续一步步讨论，每个细节其实都有较为深刻的思考点以及优化方向。
若有兴趣的可以再去看下滴滴分享的 pope 系统直播课，本文抛砖引玉，并不涉及其核心代码。