滴滴用户增长运营|不懂BI的产品,不是好运营
题图来自 Pexels ,基于 CC0 协议 作者:kuanso 全文共 8098 字,阅读需要 16 分钟 —— BEGIN —— 六月来到了滴滴做用户增长,经过了异常忙碌的两个月,终于抽时间,把这段转型期中零散的记录的一些思考,系统的整理成文。总结一下就是“不懂BI的产品,不是好运营”。 从数据产品转用户增长运营,这是我的几点思考:一、用户增长运营是什么,做什么要解释用户增长运营,首先要先明确:什么是运营,怎么做用户增长? 关于这两个问题,我想引用下我比较赞同的两个业内人士的观点: 运营是通过用户、内容、品牌等运营方式,传递产品价值、打造内容生态、创造新玩法,将产品和用户更好的连接,达到产品最终目的 ——韩叙 “增长黑客”是以数据驱动营销、以市场指导产品,通过技术手段贯彻增长目标的一群人。这就需要他们既了解技术,写得了代码;又能了解人性,能捕捉用户的心理感受和真实需求;最重要的是,他们经常能突发奇想,发挥创意,大开脑洞,以小的投入获取较多的用户和收入。 ——范冰《增长黑客》 所以在我看来起来,用户增长运营的工作,就是: 在滴滴,我所在的市内增长组,会以项目FT的形式,联合产品BI研发等部门共同协作,通过AB测试与数据敏捷分析等方法来指导业务发展,从而快速迭代产品,实现增长目标。 为了实现用户增长,除了要深入了解业务,在产品的全流程中拆解增长公式,寻找增长空间;还需要不断学习,通过新维度找到新的增长方向。 比如对于用户增长最重要的数据分析能力,就从最开始的在大学只会用excel的数据透视表和vlookup等几个函数处理大量数据,到在网易通过学习使用网易有数这样的敏捷BI工具实现数据的可视化分析,通过维度下钻与用户分群找到增长空间,再到滴滴切换到Tableau进行可视化分析的同时,对于新尝试的分解维度,学习直接用SQL跑数据进行快速分析,开始接触算法调优。 对于用户增长,每一个新的实验方式与新的数据分析维度,都是可能的新增长点。 至于为什么需要用户增长运营: 例如对于内容运营: 传统运营主要是依靠长期积累的经验,去抓住目标用户的内容需求,靠类似于传统媒体主编的模式,进行选题与内容生产。 而对于用户增长来说,我们更倾向于:从经验驱动转向方法论驱动,依靠用户群划分与快速实验,数据驱动迭代;在经验的的基础上,进一步找到优化空间。 也只有这样通过方法论驱动,才能实现分发针对性内容,做到千人千面,不再是主编的经验与个人倾向决定。 再比如对于电商运营: 如果将企业营收指标拆解为:流量*转化率*客单价,那么传统运营的主要抓手是渠道运营去拉更多的流量,通过品类运营的各种资源与工具的熟练运用,去提升转化与客单价。 而用户增长的思路可能会更多的根据渠道的具体数据情况,对应的进行用户群的划分与运营方式的探索,通过数据驱动,针对不同用户匹配不同运营策略,实现增长指标。 可能在部分人看来,用户增长只是从过去的靠经验变为靠实验数据验证,并不是脑暴式的底层创新;但实际上,脑暴式的创新是依靠于灵感的不可持续的创新。 而通过实验与数据驱动运营方式的快速迭代,是一套可持续的创新思路;即使每次只能做出很小的提升,但持续下去一定可以收获更大的成果,最终当产品的全流程都找到了增长的方向后,这就是一个伟大的创新。 靠用户增长这一个单一指标似乎可以在一级市场里唤风唤雨,让VC/PE来跪舔,但是在二级市场,必须有好几个可供差遣腾挪的增长因素,否则分分钟打脸。 优秀的经营者,都是节奏大师:知道什么时候该在几个增长指标之间调兵遣将,不会把单一指标快用“死”了才找援兵,懂得休养生息。 譬如Facebook让ad load休息了好几个季度,直到Instagram开始大规模商业化才重新激活这个指标。 更伟大的经营者,是可以重写企业的收入公式,扩展疆域,这是华丽的冒险,也是最激动人心的旅程。 譬如:丁老板去养猪,我从来没嘲笑过。 网易做严选和考拉,电商收入在2017Q2已经占到20%的收入了,如果这个比例再持续增加一些,网易的收入公式就改写成功了。 ——朱时雨《增长的接力棒》 最后,正如上文所说用户增长的最终目标,可能就是找到每一个可能的增长点,梳理出产品的增长公式,并根据增长需求对增长指标进行合理调配均衡,找到恰当的增长节奏,甚至通过挖掘新的增长点,重写产品的增长公式。 二、“运营是个筐,啥都往里装”说到运营,似乎是个门槛不高的行业,相比于“人人都是产品经理”,好像“人人都在做运营”,但说到实际的工作内容,又好像都不太一样。
…… 笑谈背后,是运营纷繁复杂的职能种类:用户运营、内容运营、活动运营、内容运营、社区运营、电商运营、渠道运营、新媒体运营。 甚至连具体的岗位,不同的公司不同阶段的工作内容,也不尽相同。 比如我所在的滴滴顺风车的用户增长运营,按大类应当属于用户运营;由于面对亿级用户,更偏向于策略性运营,根据用户属性划分相应的用户组,并制定相应的策略以实现拉新,激活,留存,转化,传播的用户增长。 但是中等规模的产品中,可能用户运营的主要工作是促进核心用户群体的活跃与转化,激励用户产出优质内容;在小规模的创业公司,由于量级小,用户运营可能更多的是做用户反馈的处理与用户群运营。 社区运营在产品早期,做得更多的可能是天使用户的引入与社区内容的准备,以实现冷启动;而在成熟社区,可能关注点就转向了用户内容分发机制与激励体系,建设社区生态。 再比如新媒体运营,在滴滴是属于市场部门的工作。 所以,面对庞大复杂的运营体系,相比于急于求成做“全栈运营”,我更倾向于从用户增长运营的角度深度切入,试图在实践中总结出一套适用于自己的运营方法论,并试图应用到扩展到其他运营领域中,逐渐向真正的“全栈运营”迈进。 三、运营和产品岗之间,并不一定“泾渭分明”在滴滴,加入的用户增长团队是属于运营组。 从网易的数据产品,到滴滴的用户增长运营,本以为会经历一段时间的适应期;但其实现在回看,从业务数据梳理与分析,到数据与实验导向的业务决策,再到项目推动与团队沟通,其实两边工作的日常有很多都是类似的——只是可能思考的角度从产品更关注的需求与逻辑,转向了运营所关注的流程与细节。 当然,这也与我所在的运营是用户增长方向的特殊性,与公司的部门结构有关。 之前在网易时,我所在的事业部运营以内容运营(编辑)为主,对于需求的把控能力有限——提出需求后,作为产品需要重新进行调研评估明确需求,产出产品方案并交付开发,是产品作为项目的主导推动项目进度。运营在方案评审后,对于项目就参与较少,基本上除了定期的进度沟通和共同探索遇到的项目问题,就直接等待交付验收。 而在滴滴顺风车的用户增长运营组,对于车主日这样的运营活动,项目的前期调研与规划,活动模式策划,项目节点的划分与推进,完成后的数据分析与优化迭代,都是运营的工作;产品更多的是在原型交互产出,与开发排期沟通中参与,是运营来作为项目的主导,承担项目经理的角色,对从项目目标到项目产出的全程负责,更考验运营的项目把控能力。 所以很幸运这次可以在经历较为“无痛”的转型的同时,更深入了解与参与实际业务——这也是我对于这次转型最大的期待。 相比于之前做的数据分析都只能作为运营结果的监控与复盘,对业务提出优化建议;在这里,可以深度参与业务,通过用户群划分细化运营策略,通过AB测试的数据分析来验证各种业务方向上可能的增长点,并根据实验结论指导业务决策。 在我看来,这种从偏向理论的数据分析到利用数据做出决策的宝贵转变机会,对业务理解的加深和个人成长的促进是无价的。 四、产品和运营间为什么“水火不容”说到产品和运营,虽然互相需要紧密协作,但是似乎关系总是有一丝微妙——运营需求好像总是排不上优先级,为新功能策划活动带来的收益却归给了产品;产品好像也总是面对着运营提出的完全没有产品思维的需求。 所以这次从产品转运营之初,还是有那么一丝担心:是否能够在作为运营,从运营目标为出发点考虑问题的同时,保持和产品的高效沟通协作? 但可能是由于之前有过产品经历,比较了解产品对于运营需求常见的需要确认的细节,并提前准备;在这边作为运营,在和产品提需求时,还是比较顺畅的。 但在实际的沟通中,也体会到了为什么运营产品之间,可能存在沟通不畅的问题——在我看来,可能一个重要的原因就是思维角度的差异。 对于运营来说 负责的是从目标到结果,注重流程化,精细化与数据化思维。 对于一次大型活动,运营的侧重点更倾向于从活动目标开始进行拆解,明确在流程每个环节中要达到的指标,与团队职责的划分,最终实现项目结果。 比如对于活跃车主增长的指标,可以拆解为: 活跃车主增长=新车主活跃增长+老车主活跃增长 老车主活跃增长又可以拆解为: 老车主活跃增长=活跃车主留存提升+沉默车主激活 对于沉默车主激活的动作又可以拆解为目标用户选取,选择用户触达文案触达方式,引导触达后转化等流程,并把增长指标划分到每一个具体环节,关注触达率、点击率、转化率等多重指标,通过不断试验寻找增长空间。 团队职责划分上,对于新增车主可能与市场部的品牌建设关联较大,车主留存率除了通过运营动作提升外,和产品机制与体验的关联较大,需要产品共同负责。 对于运营,面对最终的KPI,只有拆解到每个流程环节,明确到每一个时间节点与负责部门,才能在项目周期中始终明确目标,有效推进进度,共同完成任务。 对于产品来说 负责的是从需求到方案,注重逻辑性,细节化与投入产出比。 同样对于一次大型活动,产品可能更关注需求的逻辑,是否真正满足了用户在使用场景下的需求,需求的逻辑与细节是否明确可实现。 毕竟只有拿出完备的流程,准备好每个细节可能的问题,才能顺利通过技术评审不被问倒,技术排期的时间预估相对准确。 同时面对永远开发不完的需求池,产品也需要注重功能开发的投入产出比,可能就会拒掉一些相对收益不够高的运营需求。 五、产品和运营间如何高效沟通其实无论是产品还是运营,共同的目标都是让产品更好,让用户更喜欢;只是可能由于职位不同,角度不同,地位不同,得出的观点不同。要想实现高效沟通,就必须换位思考,找到共同语言。 对于需求的逻辑性,无论是产品还是运营,对于用户需求场景的敏感度与站在用户角度思考的同理心,都是基础条件;并且运营作为离用户最近的人,对于用户需求的把控应当是更加精准的。 在需求逻辑上,只要耐心沟通,明确用户需求与具体场景,有数据作支撑,应该可以达成一致。 而对于需求的细节化,实际上与运营的精细化有着相同性,对于用户我们会进行用户分层并进行不同的动作: 对于流程我们会进行拆解,在每个环节进行ab试验与数据分析以找到增长方向,那么在给产品提需求时,也应当对于产品的细节进行明确,避免不必要的返工。 当然,对于细节的梳理应当是和产品一同完成的工作,对于从需求逻辑到产品逻辑的梳理和提前排掉技术上的一些常见坑,产品会更加专业。 最后,对于投入产出比,可能是最见仁见智的问题。 对于运营,如果一个小的产品改动可以节省大量的运营精力,提高运营活动效果,当然会认为投入产出比很高,应该提高优先级。 但对于产品,可能同时一起等待排期的会是大型版本需求,涉及全量用户的体验提升,自然要优先保证,相比下运营需求自然排不上优先级。 那么,面对这样的认知差异,如何让产品运营双方的认知同步呢? 最好的方法还是:摒弃主观的重要性判断,用客观的数据说话。
六、如何用数据说话?
|