HI,下午好,欢迎来到抖音号交易转让!
抖音号交易,抖音号出售,抖音账号转让购买卖价格,抖音账号交易平台 24小时服务热线: 4000-163-301

新闻动态

NEWS CENTER

两年后台工作,我把这些讲给你听

2019-11-25

十五、核心指标

供给侧的核心指标是:

  • 新增注册数,成功注册的机构数;
  • 新增入库数,成功在库内建博主主表数;
  • 博主审核速度:审核时间-提交时间,刨去夜间因素;
  • 人均处理数,总提交审核数/工作人数;
  • 新增上架数:分业务线、分平台、分来源看;
  • 动销率:卖出去的SKU/总SKU;
  • 被下单博主数:被下单数>0的上架博主数总和;
  • 被支付博主数:被支付订单数>0的上架博主数总和;
  • 博主数量维度的周转率:被支付博主数/总在架博主数;
  • 博主曝光率:有曝光博主数/无曝光博主数;
  • 有曝光被访博主率:被访问UV数>0的有曝光博主数总和;
  • 加购率:被加入购物车博主件数之和/总的有曝光博主数。

这几个指标可以独立交易线,看供给侧的健康度和效率情况了;如果某天遇到异常,再往下拆解详细看。

十六、数据驱动

说一个小的数据驱动案例,就是主动渠道入库的分支里的上述的插件功能。

当采购从爆款博主监控工具发掘了目标博主以后,所执行的动作是点击、打开详情页、浏览、判定可入库、贴回浏览器的URL。

此时我看到了一个数据:从点击到入库的平均时长,在7分钟左右——按理说不应该有这么长,详细拆分数据,将这些博主的从打开入库界面到入库的时长在5分钟左右;因为我们处理抓取的任务优先级是先保证对外,再保证对内,而两端的操作、交互行为都是一致的,提交入库后就要等系统的返回通知,否则这个入库就可能会失败,所以5分钟的意思就是内部采购在等待机器返回成功结果通知。

当观察到了这个数据以后做了一个优化,就是在入库页面新增了批量入库的功能,也就是按照一个模板上传URL,等待入库结束的通知。

本以为会提效,没成想又变成降效。

首先这个功能确实抓住了痛点,但是没考虑到,当所有人都去这么使用的时候,方案错了:

  • 第一个是抓取的并发处理出现了问题,大量的任务堆积,导致失败率异常高;
  • 第二是拉长了处理周期;
  • 第三是看似减轻了成本,只不过采购同学由原来的贴近入库界面,变成了攒着贴进excel,路径是一样的。

所以这时候又要重新思考这件事:他们要的是快速的从A到B,而不是一匹马还是一个汽车还是一个火车的问题——如果交通工具没有了才好。

以此为思路,开发了基于主要平台的浏览器入库插件。

在chrome浏览器下,安装插件,登录自己的工作博主,当打开微信、微博等博主主页时,只要右键点击入库,即可完成传递的工作;当真正的入库抓取流程处理完毕,会推送通知提示采购者及时处理工单,这样系统并发也不存在了,处理周期真正缩短,操作路径真正缩短,完成了目标。

所以,最后观察的结果是从点击博主进入博主主页,到入库提交的时间从7分钟降为3分钟,达成真正的优化目的。

十七、第三方服务管理

我们在运行当中会调用很多第三方服务,比如短信通知,第三方支付服务(微信/支付宝/云闪付),企业资质校验的企查查,百度的机器视觉,法大大的电子签章等服务,钉钉的机器语音外呼。所以这对我们的管理和通用化思维提出了比较严格的前瞻性要求。

用短信举例,我们的短信是有3家服务商,最初的考虑是避免在注册收验证码,或者关键通知提醒的节点,因为服务挂了,导致业务进行不下去;可后面发现这块不简单,首先每家短信服务商的价格不一样,对应的就是到达率和及时率的不一样,贵有贵的道理,便宜也有便宜的道理,这就要求我们能够接入并合理运用。

像所有服务商的接入,必须可管理、可透明化运营场景。

以短信为例,我们除去常见的基础信息以外,还会要求收集服务商的业务性数据。

  • 基础信息有供应商名称、服务年限、企业资质、营业执照、调用费用、电子合同、接入人、介入时间、联系人信息等;
  • 业务性数据像哪个消息ID,发送多少个信息,消费多少,成功发出多少,到达多少,及时率多少;

也会有一个综合性数据,供下一个模块消息配置中心所承接。

像其它的逻辑和套路也像短信类似,不重复说了。

相比之下,刚刚说的其它服务可能就没有像短信这么复杂了,像企查查、第三方支付等,都是固定的节点在接入,其它节点也没业务场景和需求,我们只要监控日常的调用数据是否异常,及时报警。

十八、消息配置中心

我们每一个节点基本上都是有短信通知的,有通知补全信息,不成功有提示再来一回,提交有等待审核,长时间无活跃的促活召回等等之类的;这些都是运营该去想哪些要提示,哪些不要提示。而我们产品对于系统化来讲的意义就在于搭建框架,运营可以在里面随心用,怎样的需求基本都能支撑的原则。

短信服务要收集那些关键信息,就是在于每个节点对于服务商的需求是不一样的。比如注册时的验证码,那就要到达率高的,及时率快的;相比之下,召回短信就不用有此依赖,便宜就行,反正90%多的到达率,我一次发个万八千的,也能回来不少。所以这就要求我们在设计消息中心的时候,尽量提供便利性。

便利体现在两点:第一是在于节点识别的便利性,第二是在于服务商识别的便利性。

节点的意思是如何能让运营通俗易懂可视化,哪个节点需要配置,哪个节点在业务中的进程是什么。

我们当前做的是文字状态的展示,但是发现不太好,因为对于新人来讲的接手成本还是有点高。比如,提交后等审核短信,什么叫审核成功,什么叫审核失败,是哪个节点的审核失败?你可能问我或者问一个资深运营马上就能告诉你:是在企业资质资料的阶段,可新人并不一定知道。所以,接下来要迭代的一个大版本,就是一个可视化的配置界面。

这个需求的本源来源是来自BI,他们正在开发基于全系统、全流程、全状态的可视化图表,就像我短信节点这就是很小的一块了。

从注册到上架,到被交易,数据都发生了怎样的状态变更,上下级和分支是怎样,BI都会纳入可视化的范围,去呈现一个报表,供所有相关人查阅;看前一天的业务情况,卡在哪里,转化率锐减,或者哪里转化率不理想,可以提升,洞察问题,诊断问题很方便。

原始需求再那边,我这边只负责梳理状态和对应的状态路径之类的。

在当前现状下,辅助运营能相对方便的识别出哪些节点,可以配置短信,也可以配置灵活的短信策略。比如,最简单的注册,那就是当触发状态,立即发送;最复杂的就是在召回规则里,比如会有某些等级的资源,当非活跃持续7天后,下周1、3、7持续短信召回,精细化甚至可以达到某些类别、某些量级、某些单位区间内交易数量的博主——因为运营很可能会这么写短信:

各位母婴博主,平台最新发布本月母婴博主榜单,请及时查收。

也有一些错误配置的功能,比如注册,一般就会开启“当短信发送失败,立即重新发送”,而召回可能就不用。也会有服务商优先级的配置,刚刚说了,可能最好的是A,优先A,但是也可以把B,C列为第二、第三优先级。

所以这个消息配置中心是一个大支撑模块,所有节点都可以用。

短时间内开发成本确实很高,但是后续来看,是减轻长期开发成本了。

十九、订单中台

接下来是我负责的另一个比较重要的中台服务,就是订单中台;是属于OMS中的底层,偏抽象的,各端的都有各自的订单管理界面,进行独立的展示和管理。

订单中台这个事情做起来要比采购端容易太多了,因为他是具象目标,收敛的,很明确的目标,就是根据之前订单去抽象支撑未来业务发展的订单小中台。业务刚刚说过了,没有库存,也没有优惠营销,所以偏向虚拟服务订单类型,但是相比之下还会稍更简单一些。但是架不住业务本身复杂,还要兼容各种情况的出现。

公司决定整体重构以后,划分了非常多的系统,借此我们也重新梳理了订单流程(也就是订单被创建的标准流程),除去状态机有中台公用的状态机以外,系统流程也是,避免各自为政、管理混乱、统计混乱、重复开发、成本加大的问题。

1. 名词

我先介绍下名词:一个是非标原创,一个是标准通稿,这是由博主的内容质量分所决定的。

非标原创的意思是客户带着需求方向来,需要博主进行自定义的完全创作。比如客户就要做一个面膜的推广,品牌是欧莱雅,时间是双十一,面膜特色是补水、保湿和贵——那可能不同的博主创作出来的内容风格和最终交付的内容都不一样,我们把这类定义为非标原创。

标准通稿就是反过来的——因为业务非标,导致商品非标。

公司为了改善这个问题,在2017年的时候新增了一条标准化业务线,客户带着已经创作好的内容,你帮我发就可以了,不用管内容哪里来的,客户就是要刷屏效应,博主完全不需要二次创作,这叫通稿。

非标业务线与标准业务线的主要差异在于客户权益:

  • 非标业务线有些会出现差旅、版权授权、代言或竞品协议等其它特殊附加费,都是各不相同;
  • 标准业务线就很标准——博主多少钱就是多少钱,下单、支付、发布、验收就可以了。

鉴于非标业务线的特性,也造就这两条业务线在业务中的最大差异:非标业务线会在下单流程中增收保证金,因为沟通和后续成本太高了;另一条就不用了,非标品转化为标品,相对确定性。

对于保证金,在下单的时候会经历业务属性很强的价格预估模型,从而根据此计算保证金,客户有偿下单。而获取最终确定性的订单价格以后,也就是博主的反馈后,会生成子订单——所以第一条父订单是保证金层面,第二条子订单是尾款层面,两笔订单结合构成完整订单。

对于业务线的大划分,有微博/微信/抖音/快手/小红书/B站这几个平台,从最上层进行抽象其实就是两类:文本和视频。

文本的非标下单流程和视频的非标下单流程,哪怕都是非标业务,业务节点也有不一样。比如文本可能会有brief确认、大纲确认、图片素材拍摄确认、软文确认等流程。而视频会更为复杂——会有brief确认、镜头确认、脚本确认、视频确认、发布详情确认等环节。

每条业务线会组合有标品和非标品,所以大体上就是4种最核心的抽象。

相关推荐