NG搭建,星汇搭建,平台开发,平台搭建,一个产品发展初期靠解决了用户哪些痛点问题，中期要考虑基于现有的产品如何持续不断的解决用户不同场景的问题，再往前可能要考虑产品矩阵，即解决同类型的用户痛点问题，又或者是发现产品的第二曲线。在产品发展的整个生命周期都需要运营去维护，但是往往在产品发展初期忽略这一事情。
运营平台就是在运营人员达到一定规模、公司产品发展到一定阶段时自然而然的产出。
运营平台，顾名思义，它的主要用户是运营，间接用户是前台产品的用户和前台的各个产品线。从运营工具来划分，大致分为三大系统：消息系统、广告系统、福利活动系统。
消息的触发形式，一般分为两类，一种是用户行为触发的消息，这里的用户包括内部用户和外部用户，比如用户支付成功的消息通知他属于外部用户的支付行为产生的消息，而审核的通知、订单处理进度的通知等等，往往是由内部员工的某一个行为触发的消息，这类属于内部用户行为的消息，他们最终的呈现都是给用户端。另一种是批量消息，即运营配置的给满足一定条件的用户下发的消息。
1、用户行为消息。
这里需要对用户的行为进行定义，用户的行为可能还会应用到其他的场景，比如加积分，所以它属于底层服务，设计时不要柔和太多的其他业务，就是单纯的行为管理。
消息需要关联用户行为，即这个行为下给哪些渠道发了什么样的模板消息都是可配置可管理，运营可根据不同的节假热点配置不一样的消息。这个接口主要是提供给业务方去使用，业务方不需要关注哪些渠道怎么发消息怎么对接第三方，直接按照约定的变量传递相应的值即可。这样行为下的消息渠道和模板都是灵活的，只要不是约定的变量发生变化，可以直接修改文案，即可生效。每个渠道都有自己的特性，在后面的消息系统中会详细说明，这里不再累赘。
2、批量消息。
在不同的时间节点，产品和运营需要给特定的用户通过不同的渠道发不一样的消息。这里多半是由运营直接配置发送，所以定时发送、用户标签细分群、渠道、消息外链及呈现等各个方便都需要考虑清楚。每个渠道有不同的参数需要配置，比如公众号消息的跳转链接可以是web链接也可以是小程序的链接等等。
大批量的消息按照用户的数量需要提前组装好，特别是有变量的比如昵称，那组装和发送之间的时间间隔的把握就要靠研发了
- 二、广告系统的搭建。广告要实现多个端不同位置的千人千面。
这里引入广告位sdk的概念，即前端写的广告组建，这个组建完成三件事：
1、展示规则，这个规则可以是根据用户身份设定、用户行为设定，也可以是展示次数等设定；
2、加入大数据的埋点机制，自动上报广告的曝光和点击相关的数据；
3、对接广告系统获取广告活动内容；
这么一来，作为支撑的运营平台只需要业务对接方引入这个广告位sdk即可，不用关心埋点等问题，方便业务对接，同时也统一管理了所有的广告。
对于广告位的划分，从性质上我们分为两类，一类是产品位，它一般不允许修改，一般是产品设定的较为固定的模块，之所以纳入广告位体系，是借助于广告的埋点，可以看产品位的相关曝光、点击等数据。另一类是运营位，就是我们常说的由运营去配置的广告。从广告位所属的产品上划分，又可以划分为pc端官网、wap商城、App、小程序、专题页等等，每个平台对应的广告特性及跳转路径都不太一致。比如App的广告活动，可能是跳转到某一个菜单也可能是某个web链接。一个广告位可能有多个广告活动。
广告系统主要要给运营提供配置界面的功能，广告的定时上下架、广告物料的限定、预览、排序、千人千面等等，在配置界面的设计上都得考虑。还有一个重要的点，就是一个广告一旦曝光，它的物料信息及目标细分群用户是否可修改，如果可以修改，需要建立统计数据和修改之间的关系，所以早期，建议直接定死，不许修改。这样如果这个广告的曝光不尽如人意，那就重新创建一个广告活动，进行局部调优。
- 三、福利系统。为了促进用户的注册、活跃、制作、传播、付费等，需要一些福利去刺激他，这些福利需要打通底层，如用户系统、支付系统、积分体系等等。
福利的划分根据不同的业务划分也不同，一般有优惠券、兑换券、权益、会员体验券、积分等等。
福利的发放分为：系统发放、用户领取。这里同消息系统，系统发放又可以划分为运营批量下发的福利和用户满足某一个特定行为触发的福利。比如我们说签到送积分，用户签到这是一个行为，这个行为会触发加积分这个福利。
运营的策略需要针对不同的用户展示不一样的，也就是所谓的千人千面，怎么实现千人千面呢？其实就是结合用户的标签建立的群，以下是之前画的一个简单的标签分析图，不同的业务有自己特有的标签，仅供参考。
总结：以上就是运营平台的三个基础服务的拆分和基础详解，在它的上层还有一层业务专项服务。还有一个需要思考的就是怎么关联运营的目标，怎么让每一次消息、广告活动、福利赠送的效果沉淀下来为后面做类似的推广宣传起到推荐的作用，后面我们在深入交流。
发表回复