編寫軟件時，工程師們會用很多不同的方法來關(guān)注用戶:例如聽取用戶的反饋，修正bug或添加用戶呼吁的特性。由于基于網(wǎng)絡(luò)的服務(wù)讓用戶能夠更容易地轉(zhuǎn)向新的應(yīng)用，建立和維持用戶的信任就變得更加重要。我們發(fā)現(xiàn)了一種雖然確實違反直覺，但極其有效的方法來獲取并保持用戶的信任，那就是讓用戶能容易地帶著他們的數(shù)據(jù)離開你的產(chǎn)品。這不僅能防止鎖定并獲得信任，還可以迫使你的團隊為獲取技術(shù)優(yōu)勢而不斷創(chuàng)新和競爭。我們管這叫“數(shù)據(jù)解放”。

鎖定帶來的問題

對軟件工程師來說，從他們使用的服務(wù)中導(dǎo)出數(shù)據(jù)顯然要比一般用戶來得容易的多。如果有可用的API，我們工程師可以隨便拼湊個程序來搞定。就算沒有API，用屏幕截圖工具也能弄到一份數(shù)據(jù)的副本。不幸的是，對大多數(shù)用戶來說這并不可行，他們經(jīng)常只能疑惑于到底能不能拿到自己的數(shù)據(jù)。直到最近，用戶在向一個新的互聯(lián)網(wǎng)服務(wù)中輸入大量的個人數(shù)據(jù)之前，幾乎都不會問是否能夠把他們的數(shù)據(jù)快捷地取出來。他們更可能問這些問題：“我的朋友們也在用這個嗎？” “這個可靠嗎？” “提供這項服務(wù)的公司半年或一年后還存在的概率是多少？” 然而，隨著用戶們將越來越多的個人數(shù)據(jù)存儲到無法觸及的網(wǎng)絡(luò)服務(wù)當(dāng)中，他們開始意識到如果沒有遷移數(shù)據(jù)的方法，他們大量的網(wǎng)絡(luò)遺產(chǎn)就會有丟失的風(fēng)險。將用戶鎖定的好處是讓他們難以離開你而轉(zhuǎn)投你的競爭對手。同樣地，如果你的對手鎖定了他們的用戶，那這些用戶也很難轉(zhuǎn)向你的產(chǎn)品。盡管如此，將研發(fā)精力投入到創(chuàng)新上要比建立壁壘來阻止用戶離開更可取?，F(xiàn)在，讓用戶能更容易地試驗產(chǎn)品會極大地提升他們對你的信任，未來也更有可能回到你的產(chǎn)品線來。

緊迫感

鎖定用戶會讓公司變得并不急于創(chuàng)新。相反，出于商業(yè)原因，公司可能會決定延緩你們產(chǎn)品的開發(fā)，并把開發(fā)資源轉(zhuǎn)移到其他產(chǎn)品上。這將使你的產(chǎn)品在與其他創(chuàng)新速率更快的公司的競爭中處于弱勢地位。鎖定讓公司得到一個持續(xù)成功的表象，但失去了創(chuàng)新的支持，它實際上可能已經(jīng)在走向夭折了。

如果你不想——或不能——鎖定你的用戶，那么參與競爭的最佳方式就是急速地創(chuàng)新。以Google搜索為例，這是一種無法鎖定用戶的產(chǎn)品：用戶不需要安裝軟件，不需要上傳數(shù)據(jù)，也不需要簽什么合同; 如果他們想嘗試其他搜索引擎，只要在瀏覽器中輸入地址，就絕塵而去了。

Google的搜索引擎是怎么留住用戶的呢？近乎執(zhí)迷地專注于持續(xù)提升搜索質(zhì)量。用戶可以輕易地轉(zhuǎn)移到其他服務(wù)這一事實已經(jīng)向Google的搜索質(zhì)量和排名團隊灌輸了一種驚人的緊迫感。在Google，我們認(rèn)為如果讓用戶能夠容易地離開我們的任何產(chǎn)品，對產(chǎn)品改進的失敗就能立即反饋到工程師那里，他們則會開發(fā)更好的產(chǎn)品作為回應(yīng)。

數(shù)據(jù)解放是什么樣的
在Google，我們的態(tài)度是用戶應(yīng)該能夠控制他們在我們的產(chǎn)品中存儲的數(shù)據(jù)，這意味著他們能導(dǎo)出自己的數(shù)據(jù)。這不需要額外的金錢支出，更重要的是，不管數(shù)據(jù)總量大小，導(dǎo)出數(shù)據(jù)的工作量應(yīng)該是一定的。分開下載一打照片不會帶來多大的不便，但如果用戶不得不一張一張地下載5000張照片呢？這得花上兩周的時間。

如果以專有的格式存儲，就算用戶有了數(shù)據(jù)的副本，依然是被鎖定的。一些15年前的文字處理工具生成的文檔無法用現(xiàn)在的軟件打開，就是因為它們是以專有格式保存的。所以重要的不僅是能夠訪問數(shù)據(jù)，還要能將其以廣泛接受的標(biāo)準(zhǔn)格式存儲。而且，這個標(biāo)準(zhǔn)應(yīng)該有合理的許可條款：例如，對實現(xiàn)應(yīng)當(dāng)是無版權(quán)約束的。對于導(dǎo)出的數(shù)據(jù)，如果已經(jīng)存在一種開放的格式（例如對于照片有JPEG或TIFF格式），就應(yīng)該成為批量下載時的一個選擇。如果產(chǎn)品中的數(shù)據(jù)還沒有一種工業(yè)標(biāo)準(zhǔn)（比如blog就沒有標(biāo)準(zhǔn)的數(shù)據(jù)格式），那么至少這種格式應(yīng)該是文檔公開的——要是你的產(chǎn)品能提供一個開源的格式轉(zhuǎn)換器的參考實現(xiàn)就更好了。

重點在于用戶對他們的數(shù)據(jù)應(yīng)該有控制權(quán)，這意味著他們需要一種便捷的方式來訪問數(shù)據(jù)。提供一套API或者一次下載5000張照片的能力并不完全能夠讓一般用戶容易地導(dǎo)入導(dǎo)出數(shù)據(jù)。從用戶界面的角度看，數(shù)據(jù)解放對用戶來說就是一組用于導(dǎo)入或?qū)С鏊袛?shù)據(jù)的按鈕。

Google通過”數(shù)據(jù)解放前線”(Data Liberation Front)來解決這個問題，這是一個以簡化Google產(chǎn)品的數(shù)據(jù)導(dǎo)入導(dǎo)出為目標(biāo)的研發(fā)團隊。數(shù)據(jù)解放的工作重點是可能阻礙用戶轉(zhuǎn)移到其他服務(wù)或同類產(chǎn)品的數(shù)據(jù)——即那些用戶創(chuàng)建或?qū)氲臄?shù)據(jù)。這些都是用戶通過直接操作而有意存儲的數(shù)據(jù)——例如照片，Email，文檔或廣告方案——如果用戶在別的地方開展業(yè)務(wù)，很可能會需要這些數(shù)據(jù)的副本。而間接產(chǎn)生的數(shù)據(jù)（比如日志數(shù)據(jù)）與鎖定無關(guān)，因此不在任務(wù)的范圍內(nèi)。

另外一件數(shù)據(jù)解放不會去做的事是建立新標(biāo)準(zhǔn)：我們盡可能地讓用戶以現(xiàn)有的格式導(dǎo)出數(shù)據(jù)，比如在Google Docs中用戶可以用OpenOffice或微軟Office的格式下載文檔。對于有些產(chǎn)品，還沒有一種開放的格式能包含所有必要的信息，我們會提供計算機易讀的格式，比如XML（我們使用Atom處理包含內(nèi)容和評論的Blogger源），開放它的文檔，并且，可能的話，提供格式轉(zhuǎn)換器的參考實現(xiàn)（例如Google Blog Converters AppEngine項目）。我們希望提供給用戶的數(shù)據(jù)格式能易于導(dǎo)入到其他產(chǎn)品中。由于Google Docs所處理的文檔和電子表格始于開放的互聯(lián)網(wǎng)興起之前，所以我們提供了幾種不同的導(dǎo)出格式；而對于大多數(shù)產(chǎn)品，我們則盡量避免陷入“要支持所有已知格式”的泥沼中。

用戶的考慮

在這幾種情況下，用戶可能想要從你的產(chǎn)品中獲得數(shù)據(jù)的副本：他們找到了更符合他們需求的產(chǎn)品，想把數(shù)據(jù)轉(zhuǎn)移過去；你們宣布停止對他們正在使用的產(chǎn)品的支持；或者更糟的是，你做了一些失信于他們的事。

當(dāng)然，用戶想要一份數(shù)據(jù)的副本并不一定意味著他們要放棄你的產(chǎn)品。許多用戶只是覺得在本地保存一份數(shù)據(jù)的備份會更安全。當(dāng)我們首先“解放”Blogger時，觀察到了這種情況：許多用戶開始每周導(dǎo)出一次日志，同時還在繼續(xù)使用Blogger寫博客。這種情況更多地出于感性而非理性因素。用戶自己電腦中的大多數(shù)數(shù)據(jù)根本沒有備份，但托管的應(yīng)用為了防范硬件錯誤和自然災(zāi)害，幾乎都會在多個地點保存多份用戶數(shù)據(jù)的備份。不論用戶的憂慮是否理性，他們需要感到自己的數(shù)據(jù)是安全的：讓你的用戶信任你，這很重要。

案例分析：GOOGLE SITES

Google Sites是一款網(wǎng)站制作工具，可以通過瀏覽器進行所見即所得的編輯。在Google內(nèi)部我們使用它編輯項目的頁面，因為它能方便地創(chuàng)建和整合項目文檔。2009年初我們承擔(dān)了為Sites開發(fā)數(shù)據(jù)導(dǎo)入導(dǎo)出功能的工作。

在設(shè)計之初，我們需要決定Google Site應(yīng)該使用什么樣的外部文件格式?？紤]到Sites提供的功能是協(xié)作創(chuàng)建網(wǎng)站，我們覺得要實現(xiàn)真正的解放，最適合的格式是XHTML。作為網(wǎng)頁的開發(fā)語言，HTML也是網(wǎng)站最輕便的存儲格式：只需要把XHTML頁面放到你自己的網(wǎng)絡(luò)服務(wù)器上，或者把它們上傳到網(wǎng)絡(luò)服務(wù)提供商那里。我們希望確保這種形式的數(shù)據(jù)可移動性能盡可能地簡單，同時盡可能地減少數(shù)據(jù)損失。

Sites用它內(nèi)部的數(shù)據(jù)格式封裝一個網(wǎng)站中存儲的所有數(shù)據(jù)，包括對所有頁面的修改。解放這些數(shù)據(jù)的第一步是創(chuàng)建一套Google Data API。一個網(wǎng)站的完整導(dǎo)出由應(yīng)用Google Sites Data API的開源Java客戶端工具提供，并且將數(shù)據(jù)轉(zhuǎn)換為一組XHTML頁面的集合。

與其他Google Data API相同，Google Sites Data API也是基于AtomPub標(biāo)準(zhǔn)開發(fā)的。它支持以Atom文檔作為線上傳輸格式對Google Sites進行RPC（遠(yuǎn)程過程控制）式的程序化的訪問。數(shù)據(jù)可以很容易地封裝為Atom的形式，因此在Google Sites的用例中Atom工作得很好。

這是一個Atom條目的范例，封裝了Sites中的一個網(wǎng)頁。可以用Content Feed將它還原到Google Sites。

我們用粗體標(biāo)出了實際被導(dǎo)出的數(shù)據(jù)，包括一個標(biāo)識符、以ISO 8601格式表示的最后更新時間、標(biāo)題、版本號和網(wǎng)頁的實際內(nèi)容。為了簡化范例，強制認(rèn)證元素和其他可選的信息被去掉了。一旦API準(zhǔn)備就緒，第二步就是實現(xiàn)從一組Atom源到一組可移動的XHTML網(wǎng)頁的轉(zhuǎn)換。為了防止數(shù)據(jù)丟失，我們將每個Atom條目的元數(shù)據(jù)都嵌入到轉(zhuǎn)換的XHTML中。如果在轉(zhuǎn)換得到的頁面中沒有這些元數(shù)據(jù)，就說明在導(dǎo)入過程中出現(xiàn)了問題——無法確定XHTML的元素與原有Atom條目的對應(yīng)關(guān)系。幸運的是，我們不用自己發(fā)明元數(shù)據(jù)嵌入技術(shù)；只要用hAtom微格式就行。

以剛才的范例來說明微格式的功能,下面是轉(zhuǎn)換后的嵌入了hAtom微格式的XHTML：

案例分析：BLOGGER

我們在做數(shù)據(jù)解放項目時經(jīng)常遇到的一個問題是如何滿足高級用戶。這是我們最喜愛的用戶。他們喜歡用我們的服務(wù)，存入了大量的數(shù)據(jù)，并且希望能夠方便地隨時導(dǎo)入或?qū)С龃罅康臄?shù)據(jù)。例如，五年間更新的日志和照片很容易就能達到幾個G的容量，想要一舉移動這么多數(shù)據(jù)確實很有挑戰(zhàn)性。為了讓導(dǎo)入導(dǎo)出操作對用戶來說盡可能簡單，我們決定實現(xiàn)一種一鍵式的方案，向用戶提供一個Blogger導(dǎo)出文件，其中包括所有的文章、評論、統(tǒng)計頁面，甚至每個Blogger博客的設(shè)置。這個文件會被下載到用戶的硬盤里，還可以重新導(dǎo)入到Blogger，或者轉(zhuǎn)換后遷移到其他博客服務(wù)。

我們在建立Blogger的導(dǎo)入導(dǎo)出體驗時犯的一個錯誤是，在一次導(dǎo)入或?qū)С霾僮鲿r依賴單個HTTP事務(wù)。當(dāng)傳輸?shù)臄?shù)據(jù)量變大時，HTTP連接會變得很脆弱。連接只要中斷就會使操作無效，造成導(dǎo)出不完整或?qū)霑r數(shù)據(jù)丟失。對用戶來說這是很令人沮喪的情況，而不幸的是，對于數(shù)據(jù)量較大的高級用戶，這種情況更加常見。我們也忽略了部分導(dǎo)出的功能，導(dǎo)致高級用戶在導(dǎo)入時為了獲得更好的效果，有時需要采取笨拙的手段，例如手動分割導(dǎo)出的文件。我們意識到這對用戶來說是糟糕的體驗，我們希望在Blogger未來的版本中改正這個問題。

一個同我們處于競爭地位的博客平臺采用了一種更好的方法，當(dāng)在基于云的博客服務(wù)間遷移大量數(shù)據(jù)時，不以用戶的硬盤作為中介。提供數(shù)據(jù)解放的最好方式是API，而提供數(shù)據(jù)可移動性的最好方式是用這些API實現(xiàn)云對云的遷移。這種遷移方式需要服務(wù)間的多個RPC來分散移動數(shù)據(jù)，每個RPC都可以在失敗時自動重試，而無需用戶的干預(yù)。比起單事務(wù)的導(dǎo)入操作，這種模型要好的多。它增加了成功率，并且?guī)Ыo用戶更好的整體體驗。但只有每項云服務(wù)都為用戶的所有數(shù)據(jù)提供用于解放的API時，真正的云對云的數(shù)據(jù)可移動性才能得到體現(xiàn)。

挑戰(zhàn)

正如你從這些案例中看到的，數(shù)據(jù)解放之路的第一步就是決定用戶到底需要導(dǎo)出什么。一旦涉及用戶自己創(chuàng)建或?qū)氲侥惝a(chǎn)品中的數(shù)據(jù)，情況就會變得復(fù)雜起來。以Google Docs為例：用戶做導(dǎo)出操作時，顯然對自己創(chuàng)建的文檔具有所有權(quán)，但是那些他修改過的由別人創(chuàng)建的文檔呢？他只擁有閱讀權(quán)限的文檔又如何？如果考慮到所有可讀的文檔，用戶有閱讀權(quán)限的文檔數(shù)量會遠(yuǎn)遠(yuǎn)大于他實際讀寫過的文檔數(shù)。最后，你還要考慮到諸如訪問控制列表這樣的元數(shù)據(jù)文檔。這只是個例子，但適用于任何允許用戶分享或協(xié)作處理數(shù)據(jù)的產(chǎn)品。

另一項需要緊記的挑戰(zhàn)是安全性和授權(quán)。當(dāng)你使用戶可以非?？旖莸貙?dǎo)出數(shù)據(jù)時，也就大大減少了攻擊者帶著你全部數(shù)據(jù)逃跑所需的時間。這就是為什么最好在導(dǎo)出敏感數(shù)據(jù)（例如搜索歷史）前強制用戶進行授權(quán)，并且對用戶發(fā)送導(dǎo)出操作通知（例如用email通知用戶發(fā)生了導(dǎo)出操作）。我們在解放更多產(chǎn)品時，也一直在探索這些機制。

巨大的數(shù)據(jù)集合會產(chǎn)生另一個挑戰(zhàn)。例如，一組數(shù)量很多的照片數(shù)據(jù)量很容易達到幾個G，在當(dāng)前大多數(shù)家庭的網(wǎng)絡(luò)傳輸速度下就會造成一些困難。在這種情況下，我們或者提供一個可以與網(wǎng)絡(luò)同步數(shù)據(jù)的客戶端（例如Picasa），或者依靠已有的協(xié)議和API（例如Gmail使用的POP和IMAP協(xié)議）來讓用戶逐漸地同步或?qū)С鰯?shù)據(jù)。

結(jié)論

允許用戶獲取數(shù)據(jù)的副本只是數(shù)據(jù)解放征途的第一步：要實現(xiàn)讓用戶可以容易地在互聯(lián)網(wǎng)上將數(shù)據(jù)在各種產(chǎn)品之間遷移的目標(biāo)，我們還有很長的路要走。我們期待在未來，工程師們可以不用為數(shù)據(jù)的搬運費心，而更多地專注于開發(fā)有趣的產(chǎn)品，以技術(shù)優(yōu)勢來競爭——而非通過綁架用戶的方式。把對數(shù)據(jù)的控制權(quán)交給用戶，對于建立用戶信任來說是很重要的一個部分。我們希望更多的公司能夠認(rèn)識到，如果想長久地留住用戶，最好的方式是讓他們獲得自由。

來源：http://article.yeeyan.org/view/178353/144453