数极客首页

想留住用户,就要让他们能容易地离开

编写软件时,工程师们会用很多不同的办法

来关注用户:例如听取用户的反响

,修正bug或添加用户呼吁的特性。由于基于网络的效劳
让用户能够

更容易地转向新的应用,树立
和维持用户的信任就变得愈加
重要。我们发现了一种固然
的确

违犯

直觉,但极端
有效的办法

来获取并坚持
用户的信任,那就是让用户能容易地带着他们的数据分开
你的产品。这不只
能避免

锁定并取得

信任,还能够

迫使你的团队为获取技术优势而不时
创新和竞争。我们管这叫“数据解放”。

锁定带来的问题

对软件工程师来说,从他们运用
的效劳
中导出数据显然要比普通
用户来得容易的多。假定

有可用的API,我们工程师能够

随意
拼凑个程序来搞定。就算没有API,用屏幕截图工具也能弄到一份数据的副本。不幸的是,对大多数用户来说这并不可行,他们经常只能疑惑于到底能不能拿到自己

的数据。直到最近,用户在向一个新的互联网效劳
中输入大量的个人数据之前,简直

都不会问能否
能够

把他们的数据快捷地取出来。他们更可能问这些问题:“我的朋友们也在用这个吗?” “这个牢靠

吗?” “提供这项效劳
的公司半年或一年后还存在的概率是多少?” 但是
,随着用户们将越来越多的个人数据存储到无法触及的网络效劳
当中,他们开端
认识
到假定

没有迁移数据的办法

,他们大量的网络遗产就会有丧失
的风险。将用户锁定的益处

是让他们难以分开
你而转投你的竞争对手。同样地,假定

你的对手锁定了他们的用户,那这些用户也很难转向你的产品。固然

如此,将研发肉体

投入到创新上要比树立
壁垒来阻止用户分开
更可取。往常

,让用户能更容易地实验
产品会极大地提升他们对你的信任,未来

也更有可能回到你的产品线来。

紧迫感

锁定用户会让公司变得并不急于创新。相反,出于商业缘由
,公司可能会决议
延缓你们产品的开发,并把开发资源转移到其他产品上。这将使你的产品在与其他创新速率更快的公司的竞争中处于弱势位置
。锁定让公司得到一个持续胜利

的表象,但失去了创新的支持,它理论

上可能曾经
在走向夭折了。

假定

你不想——或不能——锁定你的用户,那么参与竞争的最佳方式就是急速地创新。以Google搜索为例,这是一种无法锁定用户的产品:用户不需求
装置

软件,不需求
上传数据,也不需求
签什么合同; 假定

他们想尝试其他搜索引擎,只需
在阅读
器中输入地址,就绝尘而去了。

Google的搜索引擎是怎样
留住用户的呢?近乎执迷地专注于持续提升搜索质量。用户能够

随意

地转移到其他效劳
这一事实曾经
向Google的搜索质量和排名团队灌输了一种惊人的紧迫感。在Google,我们以为
假定

让用户能够

容易地分开
我们的任何产品,对产品改进

的失败就能立刻

反响

到工程师那里,他们则会开发更好的产品作为回应。

数据解放是什么样的
在Google,我们的态度是用户应该能够

控制他们在我们的产品中存储的数据,这意味着他们能导出自己

的数据。这不需求
额外的金钱支出,更重要的是,不论

数据总量大小,导出数据的工作量应该是一定的。分开下载一打照片不会带来多大的不便,但假定

用户不得不一张一张公开
载5000张照片呢?这得花上两周的时间。

假定

以专有的格式存储,就算用户有了数据的副本,依然

是被锁定的。一些15年前的文字处置
工具生成的文档无法用往常

的软件翻开
,就是由于
它们是以专有格式保管
的。所以重要的不只
是能够

访问数据,还要能将其以普遍
接受

的规范

格式存储。而且,这个规范

应该有合理的允许

条款:例如,对完成
应当是无版权约束的。关于
导出的数据,假定

曾经
存在一种开放的格式(例如关于
照片有JPEG或TIFF格式),就应该成为批量下载时的一个选择。假定

产品中的数据还没有一种工业规范

(比如

blog就没有规范

的数据格式),那么至少这种格式应该是文档公开的——要是你的产品能提供一个开源的格式转换器的参考完成
就更好了。

重点在于用户对他们的数据应该有控制权,这意味着他们需求
一种便利
的方式来访问数据。提供一套API或者一次下载5000张照片的才干

并不完好

能够

让普通
用户容易地导入导出数据。从用户界面的角度看,数据解放对用户来说就是一组用于导入或导出一切
数据的按钮。

Google经过
”数据解放前线”(Data Liberation Front)来处置

这个问题,这是一个以简化Google产品的数据导入导出为目的
的研发团队。数据解放的工作重点是可能障碍
用户转移到其他效劳
或同类产品的数据——即那些用户创建

或导入的数据。这些都是用户经过
直接操作而有意存储的数据——例如照片,Email,文档或广告计划

——假定

用户在别的中央
展开
业务,很可能会需求
这些数据的副本。而间接产生的数据(比如

日志数据)与锁定无关,因而

不在任务的范围内。

另外一件数据解放不会去做的事是树立
新规范

:我们尽可能地让用户以现有的格式导出数据,比如

在Google Docs中用户能够

用OpenOffice或微软Office的格式下载文档。关于
有些产品,还没有一种开放的格式能包含一切
必要的信息,我们会提供计算机易读的格式,比如

XML(我们运用
Atom处置
包含内容和评论的Blogger源),开放它的文档,并且,可能的话,提供格式转换器的参考完成
(例如Google Blog Converters AppEngine项目)。我们希望提供给

用户的数据格式能易于导入到其他产品中。由于Google Docs所处置
的文档和电子表格始于开放的互联网兴起之前,所以我们提供了几种不同的导出格式;而关于
大多数产品,我们则尽量避免

堕入
“要支持一切
已知格式”的泥沼中。

用户的思索

在这几种状况

下,用户可能想要从你的产品中取得

数据的副本:他们找到了更契合
他们需求的产品,想把数据转移过去;你们宣布中止
对他们正在运用
的产品的支持;或者更糟的是,你做了一些失信于他们的事。

当然,用户想要一份数据的副本并不一定意味着他们要放弃你的产品。许多用户只是觉得在本地保管
一份数据的备份会更安全

。当我们第一
“解放”Blogger时,察看

到了这种状况

:许多用户开端
每周导出一次日志,同时还在继续运用
Blogger写博客。这种状况

更多地出于理性
而非理性要素
。用户自己

电脑中的大多数数据基本

没有备份,但托管的应用为了防备

硬件错误和自然灾害

,简直

都会在多个地点保管
多份用户数据的备份。不论

用户的忧虑能否
理性,他们需求
感到自己

的数据是安全

的:让你的用户信任你,这很重要。

案例剖析

:GOOGLE SITES

Google Sites是一款网站制造
工具,能够

经过
阅读
器中止

所见即所得的编辑。在Google内部我们运用
它编辑项目的页面,由于
它能便当
地创建

和整合项目文档。2009年初我们承担

了为Sites开发数据导入导出功用
的工作。

在设计之初,我们需求
决议
Google Site应该运用
什么样的外部文件格式。思索
到Sites提供的功用
是协作创建

网站,我们觉得要完成
真正的解放,最适合

的格式是XHTML。作为网页的开发言语
,HTML也是网站最笨重
的存储格式:只需求
把XHTML页面放到你自己

的网络效劳
器上,或者把它们上传到网络效劳
提供商那里。我们希望确保这种方式
的数据可移动

性能尽可能地简单,同时尽可能地减少数据损失。

Sites用它内部的数据格式封装一个网站中存储的一切
数据,包括对一切
页面的修正
。解放这些数据的第一步是创建

一套Google Data API。一个网站的完好
导出由应用Google Sites Data API的开源Java客户端工具提供,并且将数据转换为一组XHTML页面的汇合

与其他Google Data API相同,Google Sites Data API也是基于AtomPub规范

开发的。它支持以Atom文档作为线上传输格式对Google Sites中止

RPC(远程过程控制)式的程序化的访问。数据能够

很容易地封装为Atom的方式
,因而

在Google Sites的用例中Atom工作得很好。

这是一个Atom条目的范例,封装了Sites中的一个网页。能够

用Content Feed将它恢复

到Google Sites。

<entry xmlns:sites=”http://schemas.google.com/sites/2008″>
<id> https://sites.google.com/feeds/content/site/…</id>
<updated> 2009-02-09T21:46:14.991Z</updated>
<category scheme=” http://schemas.google.com/g/2005#kind
term=”http://schemas.google.com/sites/2008#webpage”
label=” webpage“/>
<title> Maps API Examples</title>
< sites:revision> 2< /sites:revision>
<content type=”xhtml”>
<div xmlns=”http://www.w3.org/1999/xhtml”>
… PAGE CONTENT HERE …
</div>
</content>
</entry>

我们用粗体标出了理论

被导出的数据,包括一个标识符、以ISO 8601格式表示的最终
更新时间、标题、版本号和网页的理论

内容。为了简化范例,强迫
认证元素和其他可选的信息被去掉了。一旦API准备就绪,第二步就是完成
从一组Atom源到一组可移动

的XHTML网页的转换。为了避免

数据丧失
,我们将每个Atom条目的元数据都嵌入到转换的XHTML中。假定

在转换得到的页面中没有这些元数据,就阐明

在导入过程中呈现
了问题——无法肯定
XHTML的元素与原有Atom条目的对应关系。侥幸

的是,我们不用自己

发明

元数据嵌入技术;只需
用hAtom微格式就行。

以刚才

的范例来阐明

微格式的功用
,下面是转换后的嵌入了hAtom微格式的XHTML:

<divwebkit-html-tag” style=”margin-top: 0px; margin-right: 0px; margin-boom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-boom: 0px; padding-left: 0px; “> hentry webpage
id=”https://sites.google.com/feeds/content/site/…”>
<h3>
<spanwebkit-html-tag” style=”margin-top: 0px; margin-right: 0px; margin-boom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-boom: 0px; padding-left: 0px; “> entry-title“> Maps API Examples</span>
</h3>
<div>
<divwebkit-html-tag” style=”margin-top: 0px; margin-right: 0px; margin-boom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-boom: 0px; padding-left: 0px; “>entry-content“>
<div xmlns=”http://www.w3.org/1999/xhtml”>
… PAGE CONTENT HERE …
</div>
</div>
</div>
<small>
Updated on
<abbrwebkit-html-tag” style=”margin-top: 0px; margin-right: 0px; margin-boom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-boom: 0px; padding-left: 0px; “>updated” title=”2009-02-09T21:46:14.991Z“>
Feb 9, 2009
</abbr>
(Version <spanwebkit-html-tag” style=”margin-top: 0px; margin-right: 0px; margin-boom: 0px; margin-left: 0px; padding-top: 0px; padding-right: 0px; padding-boom: 0px; padding-left: 0px; “>sites:revision“>2</span>)
</small>
</div>
高亮的类属性直接映射原来的Atom元素,标明
了将其导入到Sites时怎样
重新构建Atom。运用
微格式办法

的额外益处

是,只需
作者愿意向页面中的数据添加一些类属性,任何网页都能够

导入到Sites中。将用户导出的数据无损地重新导入的才干

是数据解放的关键——可能需求
花更多时间来完成
,但我们以为
这是值得的。

案例剖析

:BLOGGER

我们在做数据解放项目时经常遇到的一个问题是怎样
满足高级用户。这是我们最喜欢
的用户。他们喜欢用我们的效劳
,存入了大量的数据,并且希望能够

便当
地随时导入或导出大量的数据。例如,五年间更新的日志和照片很容易就能抵达

几个G的容量,想要一举移动

这么多数据的确

很有应战
性。为了让导入导出操作对用户来说尽可能简单,我们决议
完成
一种一键式的计划

,向用户提供一个Blogger导出文件,其中包括一切
的文章、评论、统计页面,致使

每个Blogger博客的设置。这个文件会被下载到用户的硬盘里,还能够

重新导入到Blogger,或者转换后迁移到其他博客效劳

我们在树立
Blogger的导入导出体验时犯的一个错误是,在一次导入或导出操作时依赖单个HTTP事务。当传输的数据质变
大时,HTTP衔接
会变得很脆弱。衔接
只需
中缀
就会使操作无效,构成

导出不完好
或导入时数据丧失
。对用户来说这是很令人懊丧
的状况

,而不幸的是,关于
数据量较大的高级用户,这种状况

愈加
常见。我们也疏忽

了部分

导出的功用
,招致
高级用户在导入时为了取得

更好的效果,有时需求
采取蠢笨

的伎俩

,例如手动分割导出的文件。我们认识
到这对用户来说是糟糕的体验,我们希望在Blogger未来

的版本中矫正
这个问题。

一个同我们处于竞争位置
的博客平台采用了一种更好的办法

,当在基于云的博客效劳
间迁移大量数据时,不以用户的硬盘作为中介。提供数据解放的最好方式是API,而提供数据可移动

性的最好方式是用这些API完成
云对云的迁移。这种迁移方式需求
效劳
间的多个RPC来分散移动

数据,每个RPC都能够

在失败时自动重试,而无需用户的干预。比起单事务的导入操作,这种模型要好的多。它增加了胜利

率,并且带给用户更好的整体体验。但只需

每项云效劳
都为用户的一切
数据提供用于解放的API时,真正的云对云的数据可移动

性才干
得到表现

应战

正如你从这些案例中看到的,数据解放之路的第一步就是决议
用户到底需求
导出什么。一旦触及
用户自己

创建

或导入到你产品中的数据,状况

就会变得复杂起来。以Google Docs为例:用户做导出操作时,显然对自己

创建

的文档具有一切
权,但是那些他修矫正

的由他人

创建

的文档呢?他只具有
阅读权限的文档又怎样
?假定

思索
到一切
可读的文档,用户有阅读权限的文档数据量
会远远大于他理论

读写过的文档数。最终
,你还要思索
到诸如访问控制列表这样的元数据文档。这只是个例子,但适用于任何允许用户分享或协作处置
数据的产品。

另一项需求
紧记的应战
是安全

性和受权

。当你运用
户能够

十分

快捷地导出数据时,也就大大减少了攻击者带着你全部数据逃窜
所需的时间。这就是为什么最好在导出敏感数据(例如搜索历史)前强迫
用户中止

受权

,并且对用户发送导出操作通知(例如用email通知用户发作
了导出操作)。我们在解放更多产品时,也不时

在探求

这些机制。

庞大

的数据汇合

会产生另一个应战
。例如,一组数据量
很多的照片数据量很容易抵达

几个G,在当前大多数家庭的网络传输速度下就会构成

一些艰难

。在这种状况

下,我们或者提供一个能够

与网络同步数据的客户端(例如Picasa),或者依托
已有的协议和API(例如Gmail运用
的POP和IMAP协议)来让用户逐步

地同步或导出数据。

结论

允许用户获取数据的副本只是数据解放征途的第一步:要完成
让用户能够

容易地在互联网上将数据在各种产品之间迁移的目的
,我们还有很长的路要走。我们等候

在未来

,工程师们能够

不用为数据的搬运省心
,而更多地专注于开发有趣的产品,以技术优势来竞争——而非经过
绑架用户的方式。把对数据的控制权交给用户,关于
树立
用户信任来说是很重要的一个部分

。我们希望更多的公司能够

认识到,假定

想耐久

地留住用户,最好的方式是让他们取得

自由

来源:http://article.yeeyan.org/view/178353/144453

给大家举荐

我国新一代大数据用户行为剖析

与数据智能平台:数极客(https://www.shujike.com),是支持无埋点、前端埋点、后端埋点、API导入四种混合数据采集方式,整合剖析

用户行为数据和业务数据,能够

自动监测网站、APP、小程序等多种渠道推行
效果剖析

,是增长黑客们必备的互联网数据剖析

软件。数极客支持实时多维剖析

、漏斗剖析

、留存剖析

、途径
剖析

等十大数据剖析

办法

以及APP数据剖析

网站统计网站剖析

小程序数据统计用户画像等应用场景,业内首创了六种提升转化率的数据剖析

模型,是用户行为剖析

范畴
首款应用定量剖析

与定性剖析

办法

数据剖析

产品

发表评论

评论已关闭。

相关文章