Category Archives: Website Analytics

保持传统思维

伊万·威廉姆斯(36.3, -0.28, -0.77%)(Evan Williams)终于参透了互联网。

这是他在美国波特兰举行的XOXO大会上对现场的一众科技行业领导者的表态。尽管说这话时多少带有一丝开玩笑的意味,但在30分钟的演讲中,他还是结合当今通行的行业理论和他个人20年来的苦思冥想,再加上创办Blogger和Twitter等一流互联网公司所积累起来的经验,做出了一番综合性的阐述。

威廉姆斯在演讲中阐述了互联网的属性、运作模式以及致富方法。需要承认的是,威廉姆斯并不是不一流的演讲家,但他传递出的信息却十分明确:在当今这个有众多互联网创业者聚首硅谷打造旷世产品的时代,真正的诀窍反而是追求那些已有的创意,并努力对其加以改进。这场演讲完全可以充当一个路标,为迫切渴望指引的硅谷年青一代指点迷津。

威廉姆斯说,从本质上讲,互联网“是一台满足人们需求的庞大机器”。它不是乌托邦,不是魔法,只是一台提供种种便利的引擎。只要能够充分适应这台引擎,以更快的速度和更简单的方法解决人类面临的基本问题,便可以立刻创造利润。而如果忽视了人类的根本需求,一味追求旷古烁今的奇思妙想,就难免遭遇阻力。

“我们经常会认为,互联网可以让我们从事一些新的事情,”威廉姆斯说,“但人们其实只是想要追求他们一直追求的东西。”

建立更多联系

1994年,威廉姆斯从内布拉斯加的一所大学辍学,卖起了教人们如何上网的视频。在这些视频中,他将这个全球电脑网络描述为“由三个东西组成的谜题:电脑、信息和人”。但他现在已经改变了看法。

在2011年离开Twitter并成立了Medium博客网络后,威廉姆斯开始反思自己当初的想法。电脑已经普及,无论是尺寸还是功能都实现了极大的多元化,甚至成了稀松平常的事物。信息也得到了极大的丰富,同样变成了人们生活中不可或缺的一部分。经过了20年的发展,人们在网上交流的对象与现实中的人际关系几乎一致。现在真正重要的,变成了人与机器之间的联系。

“硬件之间有联系,这些交互都要涉及数据和软件。”威廉姆斯说,“研究一下互联网行业的巨头便不难发现,他们都会涉及很多联系。‘关注’是一种联系,‘赞’也是一种联系。”

“互联网当前所做的,是通过各种方法联系所有人和所有物,所有时间和所有想法——一层联系叠加着一层联系。逐渐地,世界上发生的一切和我们所作的一切、你去过和住的所有地方、你有过和分享过的全部想法、你喜欢和思念过的每一个人,都会联系起来。这种联系还会激增。”

便利性是关键

这些联系不仅在迅速增加,还在向着特定的方向增加。无论要解释当今互联网的繁荣,还是要预测未来的繁荣,都可以使用同一个原则:便利性。

“互联网让人们可以更容易地达成所愿。换句话说,它可以提供便利性。”他说,“互联网的便利性原则有两大要素:速度飞快和容易认知。”换言之,人们不想等待,不想思考——互联网应当满足这种需求。“如果你仔细研究一下互联网上的重要产品,就会发现它们都可以提升速度,简化思考过程。”

威廉姆斯认为,谷歌(876.09, -11.90, -1.34%)、Facebook(49.18, -1.10, -2.18%)、亚马逊(314.76, -5.75, -1.79%)和苹果(483.41, -6.15, -1.26%)公司都很擅长提供这种便利性。他们之所以有如今的成就,多数都是通过简化原本复杂的流程实现的,这也是威廉姆斯当年创造Blogger的诀窍所在。借助这款服务,用户不必单独创建新文档,然后保存并上传到网上,而是可以直接在网络浏览器中查看和编辑,只需要输入内容,然后点击“发布”按钮即可。

威廉姆斯说,在网上致富的关键是像Blogger一样把常规活动中的多余步骤一一去掉。

“如果你想打造一家价值十亿美元的互联网公司,就应该满足人们的愿望,最好是一个已经存在了很长时间的愿望……确定愿望后,再用现代化的技术来实现它。”他说。

他还举了一个最近的例子:Uber。“人们想从一个地方到另一个地方的愿望存在了多久?实现的难度有多大?Uber采取了一些措施,在你与司机之间建立了联系。”

回归人性本源

威廉姆斯的理念或许有些缺乏想象,但这正是关键所在。互联网走向大众市场已经20年了,所以是时候明白这样一点:互联网不是无边的魔法,它只是一个改善生活品质的引擎而已。

“互联网已经与我们20年前的认知大不相同,”威廉姆斯说,“它不是乌托邦,它与历史上的其他重大科技革命一样。”他甚至把互联网与农业作比,“农业改善了生活,它不仅让人们填饱了肚子,还让他们有更多时间从事其他事情——创造艺术,发明东西。”

不过,我们经常也会把便利性做得太过火。“看看那些把农业推向极端的技术——我们实现了农业的工业化发展,不仅破坏了环境,还影响了动物的生存,造成了营养失衡。”他说,“由于太容易接触到卡路里,导致了上瘾、肥胖和疾病。”在他看来,我们对转发、赞、粉丝和好友等互联网数据的过度痴迷,与农业领域的这场噩梦无异。

但威廉姆斯这番话并不是在抨击Twitter,只是对人性的一种观察。人终归是人,互联网的作用应该满足他们的需求。而懂得利用这一点的人,最终将会获得无与伦比的力量。(书聿)

如何评价推荐系统

推荐系统最早作为人工智能领域的研究成果,1995年由美国卡耐基.梅隆大学的Robert Armstrong提出,最初的应用场景,是个性化导航系统。后来互联网迅速发展,推荐系统也像其他学科一样,从学术领域逐渐渗透到工业界,并且发展成自己独立的业务分支。

由商业产品驱动的技术,往往能得到迅速的发展,推荐系统也不例外。2003年amazon的Greg Linden等人成功实现了Item2Item协同过滤引擎,通俗讲,就是买过A的用户还经常买B。根据Aamzon CTO的博客透露,协同过滤引擎为Amazon增加了25%到35%的销售额。受到Amazon成功的刺激,众多电子商务网站,以及社区,内容型网站,纷纷涉足推荐领域。

但是从公开的资料来看,目前对于推荐领域的研究,尤其是国内市场,大家集中在推荐算法的研究和工程实现,对于如何评价推荐系统的效果,还缺乏量化的数据指标和评价方法。在产品研发和运营的实际场景中,我发现产品经理,运营同事,引擎开发同事,数据分析同事,对于如何量化推荐引擎,效果评价,存在不同理解。

本文我同大家分享一下我对搜索引擎评价的系统的看法。
评价一款引擎,需要考虑两方面因素  , 引擎应用的业务场景  以及 业务场景独特的运营指标

1  引擎应用的业务场景,不同业务核心关注点不同

电商类的产品,关注订单成交量和成交金额,关注用户重复购买行为和衍生购买行为
社区类产品,关注用户贡献内容数量,质量,用户粘性
门户等内容类产品,关注单用户页面浏览量 (PageView Per User)

2 业务场景独特的业务指标

电商产品的订单转化率不适用与社区类的产品,同样社区产品度量用户的粘性指标对电商网站也没有意义
我们当前运营的业务场景为分享类云存储产品,对我们来讲

  1. 帮助用户探索感兴趣的文件
  1. 帮助用户连接兴趣相投的用户

是推荐引擎核心使命
因此,针对这个业务场景,好的推荐引擎,可以让用户浏览更多的页面,带来更高的用户粘性

直接影响通用指标

  1. Page View 页面浏览量
  2. Page View/Visit 单次访问页面数
  3. Avg Visit Duration 平均页面停留时间

间接影响业务指标

  1. File Download times  文件下载数
  2. File Share times 文件分享数

关于度量指标详细情况,请参考我的另外一篇博客

网站分析常用度量(Analytics measures) 辨析

Twitter 一些数据

#tweets
从第一条微博到第10亿条微博,Twitter花费了 3年2个月 零1 天
现在用户只需要一周的时间,就能发布10亿条微博
2010,平均每天发布5000万条微博
2011.3,平均每天发布1.4亿条微博
2011.3.11 当日发布1.77亿.
2009.6.25 每秒发布456条  (Michael Jackson 去世)
2011.1.1 每秒发布6,939. (新年,日本)
#注册用户数
572,000. 2011.3.12  日注册用户数
460,000. 2011年二月,平均日注册用户数
182%. 2010年移动用户增长率
#雇员数
8. 29. 130. 350. 400.  2008.1, 2009.1, 2010。1, 2011.1 and 现在.

深入理解Facebook Messages’ 应用服务器

在众多Facebook 产品中,消息系统无疑是技术挑战最大的一个。因此我们需要建立一个专有的应用服务器来管理这些基础设施。

我们最近讨论了消息系统的后端组件,以及我们如何扩展我们的服务以处理来自Email ,SMS, Facebook Chat ,收件箱的海量消息,本文我们就分享一下应用服务器的设计细节。

应用服务业务逻辑层

应用服务器整合了很多Facebook服务,封装了访问这些服务的复杂性。 他为客户端,封装了一个简单的接口来处理标准的消息操作,包括创建,读取,删除,更新消息和收件箱。

下面介绍一个每个操作的流程。

当创建一个新的消息或者回复一个消息的时候,应用服务器将消息投递到接收方(用户),如果接收方是个email地址,应用服务器还会去HayStack检查一下,是否有附件,然后创建一个html格式,遵从RFC2822标准的消息。

当消息(邮件)通过外部的邮件地址发送到Facebook内部用户系统的时候,服务器会将消息投递到用户的收件箱,根据一些预设的条件,对消息进行必要的处理,决定消息投递到哪个目录,那个话题里面。

当读取消息的时候,服务器会获取多项关于用户Mailbox的统计数据,例如容量,消息数量,话题数量,回复数量; 用户的活跃联系人数量。 服务器还会获取收件箱里面目录的统计信息和属性信息。在读取话题列表的时候,是通过一系列的搜索条件(目录,属性,作者,关键词等),话题列表里面包括话题的基本属性和话题下面的消息。

当删除消息的时候,服务器将消息和话题标识成删除状态,然后一个离线的作业会执行具体的删除消息操作。

当更新消息和话题的时候,服务器变更消息和话题的属性,比如【已读/未读】 ,归档状态,Tag 等等。更新操作还负责处理针对话题的订阅,退订操作。

管理话题组

Facebook 通过聊天室的模型管理群组话题消息。 用户可以加入(订阅),或者离开(退订)某一话题。在回复某个话题,当收件人不是某个用户,而是一个Email地址的时候,应用服务器会创建一个回复处理器,就像聊天室ID一样,当收件人通过回复了这个话题,消息会通过回复处理器,直接投递到那个话题。

为了优化读性能,简化迁移和备份过程,话题消息存储通过一个非规范化的模式来存储,因此每个用户,都有他自己的一份话题元数据,和消息的拷贝。服务器广播订阅和退订事件,在所有的接收者中,同步话题的元数据数据,从而可以用去中心化得方式,来处理订阅和回复等请求。当处理老的系统时候,比如用户的老的收件箱,或者通过Email地址来订阅,应用服务器会做些特别的适配工作,以保证业务流畅。

缓存用户的元数据

当用户访问收件箱的时候,应用服务器加载用户常见的元数据,(我们叫做活动元数据),然后缓存在LRU里面,后续请求可以尽量少查询HBASE,从而提升效率。

我们尽量减少对HBASE          的查询,是因为HBASE不支持join. 为了服务一个读请求,服务器可能要查找多个索引,在不同的     HBASE查询中抓取元数据和消息内容。Hbase针对写,而不是读做的优化,幸运的是,用户行为通常具有良好的时间和空间局部性,因此通过Cache可以解决性能问题。

我们也做了很多努力,通过减少用户内存痕迹,采用更细粒度的架构来提高Cache效率。我们可以缓存5%-10%的用户,命中率在95%左右。对于超热点数据,比如主页的未读消息数,我们将其放到全局的Memcache层。当新的消息到达时,应用服务器负责将缓存中的数据做过期处理。

同步

HBase对于交易的隔离提供了有限的支持。因此对于用户的多个并发更新,为了解决更新冲突,Facebook采用应用服务器来解决这个问题。每个用户,都会被分配到特定的应用服务器,因此针对这个用户的更新操作,都可以在这个应用服务器内,通过代码做到完全的同步隔离。

存储模式

MTA代理,将附件和大的消息到达应用服务器以前,将他们提提取出来,存储在Haystack中。当然元数据,包括搜索索引数据和小消息体,存储在HBASE中,由应用服务器来维护。每个用户的邮箱同其他用户的邮箱,都是相互独立的;用户数据在Hbase中,是不会共享的。每个用户的数据,都会存储在HBase中的一行中,Hbase行的数据结构如下:

元数据实体和索引

元数据实体,包含着收件箱对象的属性,比如文件夹,话题,消息等等。 每个实体存储在他自己的HBASE列中,不像传统的RDBMS,HBASE没有原生的索引支持。我们在应用层面,维护着二级索引。每个单独的列都已key/value对的形式存储。

例如,当我们查询“在其他目录的第二页加载未读话题”,应用服务器首先查询元数据索引,获取符合查询条件的话题,然后抓取特定话题的元数据实体,通过他们的属性来构造响应对象。

就像我们前面提到的,缓存和有效的预加载减少了Hbase的查询次数,提升了系统效率。

动作日志

任何对于用户收件箱的操作(例如创建,删除,标记话题为已读等) 都会按照时间寻出立刻追加到一个列族,这个动作被动作日志。小的消息体也会存储在动作日志里面。

我们通过重放动作日志,可以重建或者恢复用户当前的收件箱的状态。我们用最后动作日志的ID作为元数据实体和索引的版本。当加载一个用户的收件箱的时候,应用服务器比较元数据版本和最后动作日志ID,如果元数据的版本号落在了后面,那么更新收件箱的内容。

在应用端存储动作日志带来了巨大的灵活性:

a)         我们可以通过重放动作日志,产生新的元数据实体和索引,重建的过程既可以通过离线的MapRedue 任务,也可以通过应用服务器在线完成,从而保证我们可以无缝的切换到新的存储架构。

b)         我们可以进行大批量的Hbase异步写入以节省网络带宽和Hbase压缩成本。

c)         他是一个跟其他组件进行持久层数据交换的标准协议。例如,我们可以通过将动作日志写入到Scribe日志上,实现在应用级别进行备份。迁移管道将用户老的收件箱转换成动作日志,然后通过离线的MapReduce生成元数据和索引。

搜索索引

为了支持全文检索,我们维护了一个关键词的倒排索引列表。当新的消息到达时,我们用Apache Lucene 来解析和转换成包含关键词,消息ID,位置的有序列表,然后将列表增量的添加到Hbase的列族上面。每个关键词,有他自己的列。所有的消息,包括聊天的历史,email,sms,都会被实时的索引。

通过Dark Launch进行测试

应用服务器是我们从概念开始设计起来的全新软件,在我们将其用于5亿用户之前,我们需要监控他的性能,可靠性,扩展性。 我们最初开发了一个压力测试机器人,用来发起测试请求,但是我们发现测试结果,会受一些因素的影响,比如消息大小,不同请求类型的分布,不同用户活动程度的分布等待。

为了模拟生产环境下的负载情况,我们做了个Dark launch,通过这个系统我们镜像了来自聊天室和显存的收件箱的流量,将10%的用户流量导入了一个测试的集群. Dark  launches 帮助我们发现了很多性能问题和性能瓶颈。 我们同时也用他来做性能改善的评价标准。随着时间的推移,我们会向所有用户推出我们新的消息系统。

社会化媒体营销的5个常见错误

最近, Mashable 谈论了在 Facebook上进行Marketing的5个常见错误, 启发了我写一篇社会化媒体营销的5个常见错误.

1. 不切实际的期待.  现在关于通过社交媒体进行市场活动,在国内没有被大量采用,但是很多公司,对这个新兴领域,还是充满期待的,大家相信社交媒体是银弹,很牛的方案,能够在段时间内产生神奇的效果 – 产生更多的订单,更好的客户服务, 更多的网站流量.那么时间情况那?是大家看不到立竿见影的效果.然后那,大家很受挫折,干脆放弃了这个平台.

2. 没有意识到,社会媒体营销是个体力活. 社会媒体,不会自然生效,自动传播,基于社会媒体的营销,市场活动,需要每天持续的,投足大量精力.在我们确定完推广方案后,剩下的 就是艰苦,琐碎的执行工作.他需要我们有专人投入精力,创造内容,跟消费者互动,建立一个圈子,然后用户感觉到你的存在.

3. 采用多个社交媒体,多管奇下,速战速决方案. 很多公司倾向于扁平化传播,最后得到一个马马虎虎的结果.我们的建议是,不要过早铺开太广,要深耕一个渠道.这个渠道成熟以后,在考虑扩展到新的平台.

4. 不倾听.在某些情况下,社交媒体里面倾听是最好的方法.创造内容很重要, 倾听用户很重要,他不单给我们反馈,更重要的是给我们洞见(InSight) ,让我们更有效的在社交媒体上面定位用户.很多公司,拼命的在社交平台说啊说啊,忽略了听,或者听了,但是没有重视,从而丧失了重要的信息反馈渠道.

5. 社会媒体孤立化. 我们在社会媒体上面,可以做很多事情,但是如果没有公司其他业务方的支持,最后也很难成功,就是我们常说的,媒体孤岛化. 很多公司认为,社会媒体很神奇,因此不需要支持或者驱动,常见的错误是,在公司的官网上面,没有高亮社会媒体的链接,或者在销售,市场活动里面,不提社会媒体的事情.在真实的社会中,社会媒体和公司业务,是相互支持的.

如果你有其它的补充,可以留言,我们一起讨论.