写点什么

流量明星小红书的增长组织架构和数据分析实例

2018 年 12 月 11 日

流量明星小红书的增长组织架构和数据分析实例
  • 从软件公司转型为互联网公司,会发生哪些变化?

  • 小红书为什么决定由数据驱动?

  • 如何知道自己产品里的用户属性?


你是不是也曾经思考过这些问题呢?这些问题是否曾经困扰过你呢?那么你一定不能错过 TGO 鲲鹏会上海分会《技术领导者的增长黑客落地实践》活动中,小红书增长技术负责人占雪亮为大家带来了主题为《小红书增长的术和道》的演讲。


以下根据当天演讲整理,有部分不改变原意的删减。



占雪亮现场分享图


我的题目叫《小红书增长的术和道》,道的内容会尽量少讲,因为它更多要靠大家自己实践,我觉得术相对来讲更能够落地。本次演讲主要分为两部分,第一部分是组织架构,第二部分是数据!


组织架构


传统软件公司和互联网公司的组织架构差异



微软是典型的传统软件公司,而 Facebook 和谷歌就是典型的互联网公司,它们没有绝对好或者绝对坏。比如,微软的产品 windows 几年才会发一个版本,一定要在 Release 之前保证质量。在传统的软件公司组织架构下,先讨论需求文档,文档出来了再做实现,然后由 QA 测试,这是传统的流程。大家的工作机制是分层的,每一个横向的部门都会有一个类似工头的角色,可能是客户端负责人、服务端负责人或者是数据上网负责人、运维负责人,大家一起来共同讨论需求,确定需求之后再到部门里传达。大家可以看到,这里面很多沟通环节是割裂的,要靠文档或一些纸面上的东西。


而在互联网的公司里面,这套可能不是那么适用。在互联网公司的组织架构,是有了想法先看一下现有的数据或者应用功能,考虑是不是值得改进,如果改进了会影响到多少线上用户。数据分析出来之后觉得这个事应该干,就分享一下找到了什么,大家预期的收益等等。组中的设计师或者数据分析师觉得这个事可以做就做了。快速完成、快速迭代,做小流量实验,只让一小部分用户先看到,收集用户真实的反馈。然后再来开会共同解读这些数据,判断结果是好是坏,是否继续推广。这种做法最大的好处是效率更高。


从软件公司转型为互联网公司,总结一下有这样几个变化:


  • 按照功能划分团队(vs 按照职能划分团队);

  • 大目标对齐的情况下分布式的团队协力决策;

  • 更紧密的跨职能团队协作;

  • 团队关注于对用户产生实际影响;

  • 面对不确定性的敏捷;

  • 所有参与者共同对结果负责(vs 对过程负责)。


为什么小红书内部要做这样的转变呢,因为我们认为迭代速度比不出问题更重要、效率比流程更重要、数据比权威更重要。


增长团队的组织架构



这种模式叫 Independent Model,上面是 CEO,下面有一个 Growth VP,专门负责 Growth。其下的部门完全按照模型划成不同工种组成,形成独立的闭环团队,好处是资源协调更加方便,而且迭代更加快速高效,但坏处是需要更加谨慎处理和其他团队的关系。



这种模式叫 Functional Modal,它的区别是增长团队向工程 VP 汇报。这种模式是按照功能来划分的,它的优点很明显,部门之间的关系不会那么紧张,但缺点是效率会受影响,因为需要跟其他的团队沟通,不管公司文化有多好,跨团队沟通都是有成本的,只是成本高低的问题。


小红书采用的是第一种模式,Growth VP 部门涉及 Performance marketing(SEM,信息流,应用市场,厂商预装等)、小程序(微信,百度,今日头条等等)、推送、新人体验(新人引导,注册登录,Feed,Search)等业务。我们最开始时也是分散到各个不同的部门里的,暴露出了效率问题和组织沟通的问题。后来,考察硅谷增长做得比较好的一些一线互联网公司,发现他们都有一个独立的完全闭环的系统,于是我们也做了这样的转变。


这两种模式其实都有非常好的互联网公司在应用实践,所以不存在哪个绝对好、哪个绝对坏。你要选一个最契合公司氛围或者公司最能够快速落地的方案,根据自己的实际情况组织增长部门。


数据!数据!数据!


为什么我们认为数据如此重要?


因为数据永远都不会说谎,数据陈述的是客观事实,不带任何主观意识和假设。它能有效地帮我们看清之前做的决策是否正确,使问题变得更容易察觉。未来,精细化运营是大势所趋,流量越来越贵,如何更好地利用来之不易的流量,数据的指导意义至关重要。


用户次日留存低的数据分析实例


就在上个月,我们的数据部门发现来自信息流等渠道的用户次日留存低,他们的人群特征是低龄,行动特征是“点赞即走”。当时我们就做了一个很符合逻辑的假设,认为这是些学生,只能在周末用手机,但是周一到周五因为上课没有办法用我们的 APP。这听起来很合乎逻辑,但真的是这样吗?我们分三个维度分析。


不同低龄用户表现是否有差异


经过进一步细分年龄段分析,我们发现真正留不住的是 15 岁以下的初中和小学生,而高中生还可以,所以不是因为周内上课无法使用导致的留存低,所以年龄划分(both for 分析 & 分发)需要重新考虑按照学龄。同时,这些 15 岁以下的用户主要来自付费渠道、信息流和百度 SEM,所以需要对投放进行更严格的年龄定向,避免浪费金钱。


他们来小红书看什么,有没有看到他们想看到的东西


我们分析发现,15 岁以下主要是画画、动漫、头像和明星,16 岁以上开始有穿搭、护肤、减肥,19 岁以上增加了彩妆,更年长用户有了菜谱、装修、品牌。经进一步统计分析,发现搜索后低点击词主要集中在明星、时尚品类词,且都是由年轻用户主要贡献了无点击,搜索之后高点击词,主要集中在减肥、护肤、美甲上,SEM 可以在这些品类上多做投放。


他们的 Feed 流推的是他们想看的内容吗?




我们做了一个数据收集,得到三个结论:1、多样化更加明显,更符合标记我的生活;2、头部不集中;3、尾部不长尾。而内容丰满度说明,对音乐、情感、电影、餐厅、游戏、动漫、萌宠、搞笑的曝光相比标签选择过少。特别需要关注那些即是年轻人更偏好的类目,又是曝光过少的类目:音乐、游戏、动漫、搞笑。这些类目很可能优质笔记不足。我们运营团队要在社区更多地创作这样一些优质的内容,分发到我们的用户。同时我们发现,不同年龄的喜好是不一样的,分发的时候即使同一品类,在不同的年龄纬度上也需要有不同的分发策略。


以上都是数据告诉我们的,如果没有数据,再聪明也猜不出来的。


小红书经常使用以下数据分析维度,大家可以参考:


  • 性别(男,女);

  • 新老用户(新注册,7 天内注册,28 天内注册,existing);

  • 年龄段(<=15,16~18,18~23,23~28,28+);

  • 平台(iOS,Android);

  • 机型(iPhone,OPPO,VIVO,华为,小米,其他,各 Android 设备再 break down 到中高低端);

  • 地域(一二线城市,三到五线城市,其他);

  • 获客来源(Organic,SEO,SEM,信息流,小程序,Branding,应用市场等等,SEM,信息流等渠道还可以 break down 到具体是什么投放词拉进来的用户)。


小红书为什么这么数据驱动?


小红书能够如此地数据驱动,主要是由于三个方面:


  • 第一个是文化,我们的公司文化就是从上往下在引导这样的氛围;

  • 第二个是工具,它让我们人人能用数据、人人会用数据;

  • 第三个是实验,想法好不好,行不行得通,靠实验来验证,看数据是不是符合你自己的预期。


差不多就是这三件事,使我觉得小红书现在在公司内数据驱动以及对实验的重视,比外面一般的公司要好一些。


Q&A


你们产品里面怎么知道用户属性的,是用户输入还是数据开放平台?


占雪亮:我们是自己收集为主,第三方也会用一些。我们的产品在用户一进来就会填性别、年龄,选自己感兴趣的内容。


一些增长资料经常看到,任何注册的环节都有可能导致用户流失,你们有没有对比过让用户选择标签或者输入一个数字,是不是对留存有影响?


占雪亮:肯定会的,小红书最开始的时候用户一进来就要一堆信息,要求注册。现在我们将注册后置了,进来你可以先玩,之后要交互、点赞、评论的时候,再要求登录。对此我们做了实验,实验之前觉得这样用户门槛更低了,讲道理他应该要来玩。但实际却是先注册的留存率会更高。前面设置了这么多前置环节,肯定是会影响很多用户。但是他如果经过了漫长过程,其实就是他花了心思,愿意玩的概率会更高一些。如果得来很容易,反而可能很快就忘了。


做实验的要用资源,包括时间资源、人力资源和钱。一家公司不可能无限地做实验,所以每个实验的边界一般您是怎么来定的?


占雪亮:首先,不要去做没有意义的实验,如果想想都能够想得通,就没必要做实验。其次,要快速得出实验结果,一般来讲可能 80~90% 的实验一两周就会有一个初步的大结论。前提是要有好用的工具,让实验没那么麻烦,有好的工程来配套。要注意尽量不要过度分析,先在实验之前把这个标题衡量好。就跟赛跑一样,先定好这就是终点,谁先跑到谁就赢了,不要输了还要跟裁判解释什么原因。




TGO 鲲鹏会是极客邦科技旗下高端技术人聚集和交流组织,目前已在北京、上海、杭州、广州、深圳、成都、硅谷、台湾、南京全球九个城市设立分会。现在全球累计 700 多名会员,60% 为 CTO、技术 VP、技术合伙人。


如果你想和这些优秀的科技领导者们一起前行,欢迎点击「报名表单,申请加入」


2018 年 12 月 11 日 09:551747

评论 1 条评论

发布
暂无评论
发现更多内容

架构师训练营第 8 周学习总结

菜青虫

极客大学架构师训练营

TronChain波场链系统APP开发|TronChain波场链软件开发

开發I852946OIIO

系统开发

【架构师训练营第 1 期 12 周】 学习总结

Bear在挨踢

极客大学架构师训练营

架构师训练营第二期 Week 8 作业

bigxiang

极客大学架构师训练营

第七周-作业1

Mr_No爱学习

大数据应用总结一

天天向上

极客大学架构师训练营

第12周 作业

Pyr0man1ac

第12周 C!数据有这么大

Pyr0man1ac

十二周作业

orchid9

架构师训练营第二期 Week 8 总结

bigxiang

极客大学架构师训练营

训练营第十二周作业 1

仲夏

量化交易软件系统开发|量化交易APP开发

开發I852946OIIO

系统开发

架构师训练营 week12作业

FG佳

架构师一期

架构师训练营week12总结

FG佳

第十二周 数据应用(一)作业

钟杰

极客大学架构师训练营

第八周作业

Griffenliu

第八周学习总结

Griffenliu

Vim搜索神器fzf

Rayjun

vim fzf

hashmap 是如何炼成的

哈希说

数据结构

十二周总结

orchid9

量化交易APP软件系统开发(现成)

开發I852946OIIO

系统开发

第十二周 数据应用(一)

9527

极客大学 - 架构师训练营 第十二周作业

9527

第十二周作业

TheSRE

极客大学架构师训练营

第三周学习总结

J

极客大学架构师训练营

架构师训练营第 8 周课后练习

菜青虫

极客大学架构师训练营

架构师训练营 week8 学习总结

花果山

极客大学架构师训练营

HiveQL分析

天天向上

极客大学架构师训练营

训练营第十二周作业 2

仲夏

架构师训练营 week8 课后作业

花果山

极客大学架构师训练营

第七周-学习总结

Mr_No爱学习

流量明星小红书的增长组织架构和数据分析实例-InfoQ