专栏名称: 猫窝
Junyu 曾经是豌豆荚联合创始人,现在是轻芒的设计师。不保证勤快更新。
目录
相关文章推荐
纪法指引  ·  【镜鉴】市委组织部原副部长,被查! ·  2 天前  
CHINADAILY  ·  全国采集医保药品耗材追溯码超158亿条 ·  2 天前  
求是网  ·  系统观念是具有基础性的思想和工作方法 ·  3 天前  
主编温静  ·  主编温静丨今天发生了什么? ·  3 天前  
主编温静  ·  最新!多家电视台发布声明 ·  3 天前  
51好读  ›  专栏  ›  猫窝

「一起读」如何边运营边设计?这是我们上次 F8 一起读活动的总结(然后我们等一下就要接着办 Google I/O 一起读了

猫窝  · 公众号  ·  · 2017-05-17 22:13

正文

最新节目预告

北京时间 18 号凌晨 1 点也就是三个小时后,Google I/O 2017 就要开幕了。

尽管 Google 的同学盛情邀请,但今年我因故没有去现场。不过,我们会继续举办「一起读 Google I/O」的活动,通过活动来参与。

跟之前的「一起读 Facebook F8」一样,这会是一个在线讨论,我们邀请了许多专家来一起读 Google I/O,并且会通过微信群来「直播」文章讨论的成果。在北京时间 18~20 号这三天的时间里,我们会在其中不间断的发送不同角度的、经过我们的朋友们批注的关于 Google 的文章,欢迎大家来一起阅读、讨论。

如果你感兴趣的话,可以找「光涧实验室」,它会把你加到群里。微信号:

lightstream-

以下是应我们邀请来做分享、批注的朋友,谢谢他们。(按首字母排序):

  • 崔绮雯,《好奇心日报》编辑。

  • 陈毓珊,她目前在亚马逊 Alexa 工作。

  • 范怀宇,轻芒联合创始人,之前是豌豆荚技术负责人之一,《Android 开发精要》作者。

  • 李蓉慧,《第一财经周刊》驻硅谷的记者。

  • 李天放,最早在微软西雅图总部工作,2007 年加入数据公司 Palantir,负责最早期的大数据平台架构与产品设计。2012 年在北京创办「课程格子」。2017 年加入创新工场人工智能工程院,负责数据平台建设、自然语言、金融科技方面的数据研究。

  • 刘智聪,巴克云联合创始人,原迅雷网络首席架构师。迅雷 Bolt 界面引擎的发明人,负责了迅雷核心产品和核心系统的架构,在 P2P、云存储、前端等多个领域有丰富的经验。2016 年创立深圳巴克云网络,致力于下一代计算平台的研发,并即将推出首个 serverless 的 PaaS 产品「小应用云」。

  • 卢毅,「硅谷密探」联合创始人。

  • 庞向才,七牛大客户服务负责人,10 年程序员。

  • 宋晨枫,小鱼在家创始人兼 CEO。连续创业者,前美国微软 Xbox 产品经理,易城蓝天创始人,前 YY 开放平台总经理兼助理 CTO。

  • 曲凯,「42 章经」创始人、2016 年度 36 氪最受欢迎作者。

  • 项亮,《推荐系统实践》作者,推荐系统大会发起人,深度学习的研究者。

  • 徐涛,36kr 硅谷负责人,《硅谷早知道》和《声东击西》两档 podcast 的制片人和主播。

  • 张晶华,Google VR 和 AR 用户研究负责人。

  • 周昌印,VR 创业公司 Visbit 创始人、CEO。之前是 Google X 的 Google Glass and Android HDR+ mode 项目成员,也曾在微软研究院和 NVIDIA 就职。

  • 还有我。

以下是坐在我斜对面的崔瑾写的我们之前「一起读 Facebook F8」活动的 post-mortem,文章稍微有点长,但是很全面的介绍了我们的 learnings,推荐给大家。

Junyu

我叫崔瑾,轻芒的联合创始人,之前是豌豆荚的联合创始人,过去十六年的经验都在品牌和推广方面。最近做了一个虽然看起来并不复杂,但是却让我小兴奋了一下的市场活动。这个活动让我自己感觉惊讶的点在于,我们用很精简的人力,不到两人,在一天半的时间,做了一场超过 650 人参加的一起读 Facebook 全球开发者大会的活动。这个活动是借用「轻芒杂志」小程序「一起读」(下称「一起读」)这个「批注分享工具」进行的。

决定一个新功能是不是值得开始推广的重点是产品质量指标

「一起读」是一个批注分享利器,在「轻芒杂志」小程序里面就可以使用。如果你在「轻芒杂志」小程序中看到一篇很喜欢的文章,你可以把它分享给你的微信好友或者微信群,这样你们就可以一起来读这篇文章,就具体的内容进行批注、讨论。

「一起读」在今年 3 月 7 日上线,通常在产品上线的时候,我们并不急于推广,第一步还是要通过数据来看用户对这个产品的反馈,来判断这个功能是不是值得推。如何判断一个功能要不要推广?重点是看产品质量相关的数据。

到 3 月底,我们观察到「一起读」慢慢形成了两个主要的使用场景,一个是几个人的小群文章分享,热络地聊天;另一个就是认真地就文章进行批注。另一方面呢,「一起读」的数据也表明,这个功能的质量到了可以推广试试的阶段。因为「一起读」的设计重点是「边读边聊」,以及「独乐乐不如众乐乐」,那我们衡量的指标就应该是指向这里的:一个是「独乐乐」到「众乐乐」的转化率,在这个功能中就是「成组率」;第二,「聊」没「聊」,我们内部具体在这个功能中观察的是马克聊天次数/分享次数。到 3 月底,这两个数据分别是 65%,这意味着 65% 的用户可以通过分享真的找到交流对象;0.74 ,这意味着平均 1 个「一起读」里可以产生 0.74 句话。并且,这个数据持续保持稳定。

通过 Facebook 全球开发者大会把有影响力的人吸引过来

确定可以推广之后,要考虑怎么推。对于创业公司,没有丰富的资源,我们决策的关注点会放在,第一,通过让有影响力的人喜欢来产生口碑;第二,自己擅长什么。

4 月 10 日,「轻芒杂志」被「知晓程序」 MINA 奖推荐,而他们觉得「轻芒杂志」小程序很独特的地方恰好就是「一起读」。那么这就是一个机会点。推广上,持续的声音是很重要的,所谓持续发声的频率是每个月都要有传播的波峰出现,每周都要有声音出来。这是我很个人的经验值,并没有什么严格的依据。根据这个经验值,我们把目光盯向了 4 月 19 号举行的 Facebook 全球开发者大会。

下一步,就需要判断,Facebook 全球开发者大会是不是真的是一个要抓的机会。

核心有两个考虑:第一,我们的团队比较擅长的是行业内传播,第二,我们要影响有影响力的人,如果我们对功能有信心的话,那么这些人将是口碑传播的策源地。Facebook 全球开发者大会这个机会我会认为格外好一些,因为 Facebook 可以说几乎从来没有进过中国,在中国没什么用户基础,国内关于 Facebook 的新闻报道也不算多。那么,Facebook 全球开发者大会对于 Google I/O 的知名度也要弱很多。在这种情况下,还会关注 Facebook 全球开发者大会的是对这个行业相对更加感兴趣的人。当然,任何事情都是一体两面的,在 Facebook 认知度不深入的背景下,也可能出现活动参与度低的情况,但这几年,国内做海外业务的创业企业很多,Facebook 又是推广的主要阵地,所以,我觉得这事情是很值得来试试的。

让有影响力的人通过体验产品而不是通过新闻稿来了解一个产品

我是在 4 月 17 号中午 12 点结束休假到达北京,Facebook 全球开发者大会将在 4 月 19 号北京时间凌晨 1 点开始,文莲和我需要在一天半的时间里面把这个活动做上线。

作为一个新功能上线,传统意义上的想法是要发一篇新闻稿,如果新闻点比较大或者企业比较大那么就需要包装一个概念做专访,然后想办法在朋友圈进行推转。可是,这样除了能有知名度以外,是完全不能达到我们的目标的,是没法吸引有影响力的人并让他们留下好印象甚至产生口碑的。

「体验,让有影响力的人把产品用起来」是产生口碑的基础。

所以,我们还是需要回归到这个产品本身。本质上我们需要问自己,这个产品独一无二的地方是什么?你是否相信这个独一无二的地方是有价值的?有没有方法不是让有影响力的人看到的是新闻稿,而是在其中使用起来?有没有方案促成有影响力的人分享这个产品直接相关的信息?

我们认为这个产品最独一无二的部分是「用户可以就文章的具体段落进行讨论」,就是说这个讨论不是针对整篇文章而是就事论事地针对一个细节展开。这是非常独特的地方。那么下一步重点就是要围绕这个独一无二的地方设置用户可以进行体验的机会和场景。不是让用户在新闻稿件中看到这个功能,而是让用户亲自来用、来体会。

下一步就是思考这个事情如何具体执行的问题,最后我们决定不是通过文章分享到朋友圈的形式来扩大影响力而是通过讨论群组的方式来做,主要是用户整个使用流程能够形成闭环进行完整的体验,否则用户进入的流程会非常的复杂,用户不会用起来。

内容优先,影响力靠后

「一起读」是一个「批注分享的利器」,真正用户要用起来,基础是文章以及批注的质量。这就决定了我们选择来做批注分享的专家属性,第一,一定要有见地、负责任;第二,要多元化,覆盖 Facebook 全球开发者大会会议议程主要涉及的内容:VR、人工智能、AI,也希望介绍 Facebook 的社会责任感、企业的前世今生。从 4 月 17 日中午到  4 月 18 日,我们最终邀请了:方可成,宾夕法尼亚大学在读博士、新闻实验室发起人;王健飞,品玩Pingwest 新技术组高级主笔;李蓉慧,《第一财经周刊》驻硅谷记者;曲凯,「42 章经」创始人;徐涛,36kr 硅谷负责人,《硅谷早知道》和《声东击西》两档 podcast 的制片人和主播;张晶华,Google VR 用户研究负责人;和王咏刚,创新工场技术副总裁兼人工智能工程院副院长,来参加这次 Facebook 一起读的活动。

在 4 月 17 号中午到 4 月 18 号深夜,我们邀请这 6 位朋友为参与「Facebook 一起读」的朋友推荐了 18 篇文章,产出了 161 条笔记,1088 条马克。其中,「42 章经」的曲凯老师在《YC 合伙人对话 Mark Zuckerberg:关于 Facebook 的低谷、增长、产品、招聘、未来等的一切》这篇文章中做了 36 条批注,该文章有 191 人读完。以下为创新工场技术副总裁兼人工智能工程院副院长王咏刚在文章中做的批注:

此外,从用户侧的数据是比较让我们满意的。这次我们选择的文章都很深度,并不好读,其中最多人读完的文章《Facebook 开发者大会全程回顾,增强现实是否是 Facebook 的「第二春」?》,有 220 人读完,做了 273 条标注。整个活动共有超过 650 多位朋友参加。

「一起读」做到了什么?还想做什么?

「一起读」是一个把宏大的想法不断验证、不断做减法的产物。它源于我们一个代号为「此间」的产品尝试。直到今天,「分享」这个动作都并不是那么容易的,人们不仅仅要对一个领域有知识,并且很多时候还需要能够写出来。「此间」当时想尝试的是同样兴趣的人怎么能够把自己肚子里的知识最容易的倒出来并分享、交流。就像我们在每篇文章底部的介绍「独乐乐不如众乐乐,分享文章给爱好相同的朋友们,一起边读边聊。」

之前讲到,3 月底的时候我们就观察到了用户的两种典型使用场景,通过一起读 Facebook 这次活动,在产品方向上我们验证是要进一步深入的追踪「批注分享」这个方向,比如「领读」是一种场景,重大活动的快速上线也是一种很好的使用场景。

有什么重大事项同之前的假设是不同的?

我们之前市场的预测一个场景是,大家会推荐文章并激烈的就事论事的讨论,那么这个场景在我们这个活动中没有发生。平时普通房间的讨论,聊天是批注的 3~8 倍,而这次的活动,里面是没有聊天;一方面有可能是性能优化,进来的人点不开聊天;还有一方面,几百人和文章本身形成了比较严肃的「会场」,大家不太倾向去聊天,更是「领读的效应」。

二十多天过去了,「一起读」在这期间的主要进展

活动过程中我们收到了用户非常多的反馈,过去这二十天里,我们也已经更新了两个版本,主要集中在:

  • 「一起读」的吵杂环境下不能安静的阅读,不断有人进出文章、底部的进度条也时常有人头攒动。我们是这么来思考这个问题的,就内容的讨论是有意义的但确实也会产生一定噪音,所以我们需要做的是区分哪些是有意义的讨论哪些是噪音,然后把噪音帮大家过滤掉。具体来说,我们认为头像在底部进度条的滚动是噪音,就不会让所有人的头像都在那儿滚动,只让他看到与他相关的人的头像;

  • 比如性能问题,「一起读」人数超过 100 人的时候,有时会出现进不去文章,文章内马克延迟、可能过 4 秒才能加载出来,而现在只需要 0.2 秒,我们也仍在继续优化;

  • 标题显示不全的问题,这个 bug 我们已经修复。

所谓「公关无小事」

我在公关的第一个老师在我起步的时候告诉我「公关无小事」,这些年下来,我越来越相信,「没有烂点子,只有烂执行」。即便是探索性的项目,也一定要关注执行,否则到最后如果项目没有成功,你仍会纠结于是自己执行失误还是方向错误的迷雾中。

这个项目中,我只举两个小例子,由专家提供文章,而不是我们来准备文章由专家批注。第一,要求专家提供文章,这本身也是对专家的筛选;第二,专家们是不会喜欢由企业挑选的文章的。虽然,这个选择加大了沟通、协调量,但是,这是一个真实的让多元化发挥作用的做法,是逻辑统一的。

第二个例子,有很多朋友问我们,为什么不把这 650 人的群留下来,而是选择了解散?核心是群留下,但不拿出人力好好运营的话,一定会是一个沉睡的群,这样最后变成一个聊天群,事实上对品牌是有伤害的。所以,最后我们决定与其这样,不如让大家的微信清爽一些。

类似这样的考虑还有很多,比如,再小的活动上线前都一定要画出一个用户从进入到流出的整个流程图,并在图上一步一步标注清楚需要注意的点、容易出错的点,一点一滴的想好解决方案。

其他

最后,再分享几个对我们有帮助,但是对有经验的朋友可能是常识的发现:

  • 很细小的一个点,我们原先的设计是每小时分享两篇文章,最后,我们发现用户在早晨 11 点以及下午 2 点到 6 点之间是很少阅读的,其实这个道理特别简单,用户在工作是没有精力来看文章;

  • 即便是很喜欢深度阅读的用户,每天读超过 10 篇深度文章也是超过极限的;

  • 还有一些很有趣的小事,我们平时都明白,但是做起活动来会让你有些措手不及的地方,比如说用户进群会发红包,比如说有的人会在群里面直接发布自己写的文章,这些都是对一个阅读群规则的执行产生挑战的地方;

  • 650 人群,我们是分成了 500 人群和 150 人群,事实上 150 人群的氛围是要比 500 人的差的,所以,群的人数安排也许 300 和 350 是更加合理的。