專利名稱：收集用戶體驗數(shù)據(jù)的方法及終端的制作方法
技術領域：
本發(fā)明涉及通信領i或，具體而言，涉及一種收集用戶體-驗凄t才居 的方法及纟冬端。
背景技術：
如今，無線通信^支術^皮廣泛應用到人們的日程生活中，移動電 話終端因其使用的便利性得到了廣泛的普及。隨著手機的品種越來 越多，功能也越來越強大，用戶對手才幾也越來越*匕剔。如何增強客 戶體驗，抓住客戶的心，成為各個手機廠商的重要話題。
目前的手機體驗的收集，主要有兩種方式， 一是由手機廠商設
置用戶體驗部門，對手機進行體驗并收集數(shù)據(jù)；二是直接接觸客戶， 讓用戶填寫表格后再收集起來。這兩種方式都費時費力費錢，而且 收集的數(shù)據(jù)也不能完整體現(xiàn)出結果。另外對于手機的程序錯誤 (BUG)，在出廠前，研發(fā)人員會對其不斷的測試并修改，然而這 些并不能解決所有的BUG。常常就是這些流出的BUG 4吏一些研發(fā) 人員感覺不錯的手機的銷量一直處于下游?？焖倭私饬鞒龅腂UG 并及時解決是影響手機銷量的一個重要因素。
因此，需要一種方案更方^更、更完整的收集用戶的體-瞼數(shù)據(jù)和 手機的錯誤數(shù)據(jù)，以期給用戶帶來更好的體驗。針對相關技術中收集用戶體驗數(shù)據(jù)的方式用時多、成本高，而
且收集的^:據(jù)也不能完整體現(xiàn)出結果以及不能解決所有手^L的 BUG的問題，目前尚未才是出有歲支的解決方案。

發(fā)明內(nèi)容
針對相關技術中收集用戶體驗數(shù)據(jù)的方式用時多、成本高，而 且收集的數(shù)據(jù)也不能完整體現(xiàn)出結果以及不能解決所有手才幾的 BUG的問題而提出本發(fā)明，為此，本發(fā)明的主要目的在于提供一種 收集用戶體騶^t據(jù)的方法及終端，以解決上述問題。
為了實現(xiàn)上述目的，根據(jù)本發(fā)明的一個方面，提供了一種收集 用戶體驗數(shù)據(jù)方法。
才艮據(jù)本發(fā)明的收集用戶體驗數(shù)據(jù)方法包括終端收集用戶體驗 的數(shù)據(jù)；終端將收集到的用戶體驗的數(shù)據(jù)發(fā)送給服務器。
優(yōu)選地，在終端收集用戶體驗的數(shù)據(jù)之后，方法還包括終端 對用戶體一險的凄t據(jù)進4刊呆存。
優(yōu)選地，終端對用戶體驗數(shù)據(jù)進行保存之后，方法還包括將 保存下來的用戶體驗的數(shù)據(jù)組裝為數(shù)據(jù)包。
優(yōu)選地，數(shù)據(jù)包為短信、彩信或電子郵件才各式中之一。
優(yōu)選地，終端將收集到的用戶體驗的數(shù)據(jù)發(fā)送給服務器還包括 終端將收集到的用戶體驗的數(shù)據(jù)以WEB網(wǎng)絡方式發(fā)送給服務器。
優(yōu)選地，用戶體驗的數(shù)據(jù)包括用戶體驗的錯誤數(shù)據(jù)。優(yōu)選地，終端將收集到的用戶體驗的數(shù)據(jù)發(fā)送給力良務器還包括 終端判斷是否發(fā)送收集到的用戶體驗的數(shù)據(jù)；如果確定發(fā)送，則發(fā) 送給服務器。
為了實現(xiàn)上述目的，根據(jù)本發(fā)明的另 一方面，提供了 一種終端。
該終端包括收集模塊，用于收集用戶體驗的數(shù)據(jù)；發(fā)送沖莫塊， 用于將收集到的用戶體驗的數(shù)據(jù)發(fā)送給服務器。
優(yōu)選地，終端還包括組裝沖莫塊，用于將收集到的用戶體-險的 數(shù)據(jù)組裝為數(shù)據(jù)包。
優(yōu)選地，終端還包括判斷模塊，用于判斷是否發(fā)送用戶體驗 的數(shù)據(jù)。
通過本發(fā)明，采用終端收集用戶體驗數(shù)據(jù)；終端將收集到的用 戶體驗數(shù)據(jù)發(fā)送給服務器，解決了相關技術中收集用戶體驗數(shù)據(jù)的 方式用時多、成本高，而且收集的凄t據(jù)也不能完整體現(xiàn)出結果以及 不能解決所有手4幾的BUG的問題，進而達到了可以更方l更更全面 地收集用戶數(shù)據(jù)或錯誤數(shù)據(jù)，并且能更好的針對用戶改善自己的手 才幾系統(tǒng)歲文果。


此處所說明的附圖用來^是供對本發(fā)明的進一步理解，構成本申 請的一部分，本發(fā)明的示意性實施例及其說明用于解釋本發(fā)明，并 不構成對本發(fā)明的不當限定。在附圖中
圖1是根據(jù)本發(fā)明實施例的收集用戶體驗數(shù)據(jù)方法的流程圖2是4艮據(jù)本發(fā)明實施例的優(yōu)選的用戶體-驗凄t據(jù)采集流程圖；圖3是根據(jù)本發(fā)明實施例的錯誤數(shù)據(jù)采集流程圖； 圖4是根據(jù)本發(fā)明實施例的數(shù)據(jù)收集服務器流程圖； 圖5是根據(jù)本發(fā)明實施例的系統(tǒng)總體框架示意圖； 圖6是沖艮據(jù)本發(fā)明實施例的終端的示意圖。
具體實施方式
功能相克述
考慮到相關技術中收集用戶體驗數(shù)據(jù)的方式用時多、成本高， 而且收集的^t據(jù)也不能完整體現(xiàn)出結果以及不能解決所有手4幾的 BUG，本發(fā)明實施例才是供了 一種收集用戶體-瞼凄t據(jù)的方法及終端。 該方法包括終端收集用戶體驗數(shù)據(jù)；終端將收集到的用戶體驗數(shù) 據(jù)發(fā)送給服務器。
需要說明的是，在不沖突的情況下，本申請中的實施例及實施 例中的特征可以相互組合。下面將參考附圖并結合實施例來詳細說 明本發(fā)明。
方法實施例
根據(jù)本發(fā)明的實施例，提供了一種收集用戶體驗數(shù)據(jù)的方法。 圖1是根據(jù)本發(fā)明實施例的收集用戶體驗數(shù)據(jù)方法的流程圖。 如圖l所示，該方法包4舌如下的步驟S102至步驟S104: 步驟S102 ，終端收集用戶體驗數(shù)據(jù)；步驟SI04,終端將收集到的用戶體驗數(shù)據(jù)發(fā)送給服務器。
圖2是#4居本發(fā)明實施例的優(yōu)選的用戶體-驗凄史據(jù)采集流程圖； 圖5是才艮據(jù)本發(fā)明實施例的系統(tǒng)總體框架示意圖。
該;危禾呈通過終端來實i見。
如圖2和圖5所示，該流禾呈包4舌以下步艱《
終端不停的收集其關心的用戶體驗的數(shù)據(jù)，該處的用戶體驗的 凄丈據(jù)例如可以為用戶^f吏用纟冬端中某個新禾呈序的頻率、時間或者j吏 用中出現(xiàn)的程序4晉誤(bug )。
步驟S202 ，當用戶12對手機系統(tǒng)(終端)10進行操作時，首 先查看用戶12的操作是否是關心的用戶體驗相關的操作。
步驟S204，如果是則收集其關心的用戶體驗數(shù)據(jù)，對此操作進 行記錄。
如果不是關心的用戶體驗相關的操作，則繼續(xù)查看用戶12的操 作是否是關心的用戶體驗相關的操作。
步驟S206,將收集的用戶體驗數(shù)據(jù)保存在手才幾系統(tǒng)10的存儲 器中。
步驟S208，判斷是否到達預設的發(fā)送時間。
步驟S210,當?shù)竭_事前設定的時間后，準備對用戶體-驗數(shù)據(jù)進 行發(fā)送，首先根據(jù)當前手機系統(tǒng)的狀態(tài)判斷使用何種方式來發(fā)送用戶體-驗數(shù)據(jù)，方式的優(yōu)先級順序可以為Web網(wǎng)絡、Email、短信/彩 信等，也可以為用戶定義的其他順序的優(yōu)先級。
如果沒有到達事前i殳定的時間，則返回繼續(xù)查看用戶12的才喿作 是否是關心的用戶體驗相關的操作。
步驟S212,根據(jù)發(fā)送的方式來對用戶體驗數(shù)據(jù)進行組裝。可以 z使用短信、彩信、Email等lt據(jù)包，該處的組裝均可以通過現(xiàn)有的 手才幾平臺來完成。
步驟S214,提示用戶12是否要發(fā)送此用戶體驗數(shù)據(jù)。
步驟S216,如果用戶12確定要發(fā)送此用戶體-驗凄t據(jù)，則終端 將用戶體驗數(shù)據(jù)發(fā)送給服務器。
如果用戶確定不發(fā)送，則返回繼續(xù)查看用戶12的操作是否是關 心的用戶體馬全相關的揭:作。
此流程可以循環(huán)進行。
優(yōu)選地，在該5危禾呈之后，還可以包4舌以下步驟
步驟S218,服務器接收并保存用戶體驗數(shù)據(jù)，該服務器可以相 對于終端返回的數(shù)據(jù)的類型來估支相應的改進以能夠識別終端所返回 的用戶體驗的數(shù)據(jù)。
步驟S220，手才幾廠商對收集的數(shù)據(jù)進4于過濾、統(tǒng)計、發(fā)布等。
所述的用戶體驗數(shù)據(jù)可以為用戶進行某個操作的次數(shù)、使用某
個服務的頻率、使用習慣、界面停留時間等手機廠商或服務商關心 的用戶體驗數(shù)據(jù)。圖3是根據(jù)本發(fā)明實施例的錯誤數(shù)據(jù)采集流程如圖3所示，該流禾呈包含如下步驟
步驟S302，終端監(jiān)測當前是否有程序錯誤(bug)發(fā)生。
步驟S304,錯誤發(fā)生時，終端檢測是否是關心的錯誤，可以通 過在終端建立一個錯誤類型列表來判斷，如果發(fā)生的錯誤類型在該 列表內(nèi)，則是關心的錯誤；
如果沒有發(fā)生錯誤，則返回繼續(xù)查看用戶12的操作是否有錯誤 發(fā)生。
步驟S306，如果是關心的錯誤，對錯誤的數(shù)據(jù)進行收集并保存， 4普誤的H據(jù)可以為文字、圖片等才各式。
如果不是關心的錯誤，則返回繼續(xù)查看用戶12的操作是否有錯 誤發(fā)生。
步驟S308,確定發(fā)送方式，首先^4居當前手才幾系統(tǒng)的狀態(tài)10 判斷使用何種方式來發(fā)送用戶體驗數(shù)據(jù)，發(fā)送方式的優(yōu)先級順序可 以為Web網(wǎng)絡、Email、短信/彩信等。
步驟S310,將保存下來的錯誤數(shù)據(jù)根據(jù)發(fā)送的方式來進行組 裝，可以l吏用短信、彩信、Email或WEB網(wǎng)絡支持的凝:據(jù)包。優(yōu)選 地，其題目可以充分體現(xiàn)數(shù)據(jù)內(nèi)容。
步驟S312，并提示用戶是否要發(fā)送此用戶體驗數(shù)據(jù)。
步驟S314,當用戶選擇是后，用戶確定發(fā)送此數(shù)據(jù)，則調(diào)用相 應的模塊進行數(shù)據(jù)的發(fā)送。如果用戶選擇不發(fā)送，則返回繼續(xù)查看用戶12的才喿作是否有镅-誤發(fā)生。
以上步-驟可以纟盾環(huán)進4亍。
優(yōu)選地，在以上步艱《之后還可以包4舌以下步驟
步驟S316，服務器接收并保存用戶體驗數(shù)據(jù)。
步驟S318,手機廠商對收集到的錯誤數(shù)據(jù)進行過濾、統(tǒng)計、發(fā) 布、修改等。
上述的手才幾系統(tǒng)賴-i吳可以為手扭4呈序運4亍異常情況。 圖4是根據(jù)本發(fā)明實施例的數(shù)據(jù)收集服務器流程圖； ^口圖4所示，該流禾呈可以包4舌以下步艱《 步驟S402,服務器監(jiān)聽用戶體驗數(shù)據(jù)。
步驟S404,服務器判斷是否有用戶體驗數(shù)據(jù)或錯誤數(shù)據(jù)到達。
步驟S406，當有數(shù)據(jù)到達后，服務器才艮據(jù)發(fā)送方式對這些數(shù)據(jù) 進行解碼，提取有用的數(shù)據(jù)后。
步驟S408,服務器將這些數(shù)據(jù)保存在凄t據(jù)庫中。數(shù)據(jù)庫可以使 用^Oracle、 SQL Server等。
以上流程可以循環(huán)進行，對用戶體驗數(shù)據(jù)進行監(jiān)聽、提取和保存。在得到這些數(shù)據(jù)后，數(shù)據(jù)采集員18就可以利用這些數(shù)據(jù)進4亍相 應的工作，例如可以發(fā)布統(tǒng)計報表，為研發(fā)決策提供數(shù)據(jù)支持；也 可以將收集到的錯誤凝:據(jù)發(fā)送給相關的項目來解決具體問題。
從以上的描述中，可以看出，本發(fā)明實現(xiàn)了更方便更全面地收 集用戶數(shù)據(jù)或錯誤數(shù)據(jù)，并且能更好的針對用戶改善自己的手才幾系 統(tǒng)的歲文果。
裝置實施例
根據(jù)本發(fā)明的實施例，提供了 一種收集用戶體驗數(shù)據(jù)的系統(tǒng)及 終端。
圖5是根據(jù)本發(fā)明實施例的收集用戶體驗數(shù)據(jù)的系統(tǒng)總體框架 示意如圖5所示，該系統(tǒng)包括手機系統(tǒng)(終端)10、服務器16。
具體地，手機系統(tǒng)IO是整個收集系統(tǒng)的監(jiān)控對象，主要是對其 產(chǎn)生的用戶體驗數(shù)據(jù)和異常數(shù)據(jù)進行監(jiān)控、收集、保存，并組裝為 一個特定的格式，可以為短信、彩信、Email許可的格式，如果用 戶開通了GPRS,也可以通過web網(wǎng)絡來進4亍傳輸。由于部分內(nèi)容 涉及到用戶12的隱私，所以這些數(shù)據(jù)的發(fā)送需要經(jīng)過用戶12的許 可。在用戶許可后即可發(fā)送到手機廠商或服務提供商的數(shù)據(jù)采集服 務器16中，數(shù)據(jù)采集服務器16可以使用數(shù)據(jù)庫對收集到的數(shù)據(jù)進 行保存，數(shù)據(jù)采集員18可以操作收據(jù)采集服務器16來對收集來的 數(shù)據(jù)進行過濾、發(fā)布等操作。
圖6是才艮據(jù)本發(fā)明實施例的終端的示意圖。
如圖6所示，該終端600包括收集才莫塊602和發(fā)送模塊604。，該收集模塊 602可以根據(jù)用戶體驗的數(shù)據(jù)的類型(例如用戶使用終端中某個新 程序的頻率、時間或者使用中出現(xiàn)的程序4晉誤)來基于原有的手枳i 平臺來確定，只需要在現(xiàn)有的手機平臺上植入相應的模塊即可完成， 現(xiàn)有的終端也是根據(jù)終端中各種數(shù)據(jù)的類型來設置不同的收集模 塊；發(fā)送模塊604用于將收集到的用戶體驗數(shù)據(jù)發(fā)送給服務器。
優(yōu)選地，終端還包括組裝模塊606，用于將收集到的用戶體 驗數(shù)據(jù)組裝為數(shù)據(jù)包；判斷模塊608,用于判斷是否發(fā)送用戶體驗數(shù)據(jù)。
根據(jù)本發(fā)明實施例的利用該終端收集用戶體驗數(shù)據(jù)的流程可以 ^口下
當用戶對終端600進行操作時，終端600首先查看用戶的操作 是否是關心的用戶體驗相關的操作；如果是則收集才莫塊602收集其 關心的用戶體驗數(shù)據(jù)，對此操作進行記錄。將收集的用戶體驗數(shù)據(jù) 保存在終端600的存儲器中；組裝模塊606將收集到的用戶體驗數(shù) 據(jù)組裝為數(shù)據(jù)包；終端600判斷是否到達預設的發(fā)送時間，當?shù)竭_ 事前i殳定的時間后，準備對用戶體驗凄t據(jù)進行發(fā)送，首先4艮據(jù)當前 終端600的狀態(tài)判斷使用何種方式來發(fā)送用戶體驗數(shù)據(jù)；判斷模塊 608提示用戶是否要發(fā)送此用戶體驗數(shù)據(jù)。如果用戶確定要發(fā)送此 用戶體驗數(shù)據(jù)，則調(diào)用發(fā)送模塊604發(fā)送數(shù)據(jù)。
以上所述4又為本發(fā)明的優(yōu)選實施例而已，并不用于限制本發(fā)明， 對于本領域的技術人員來說，本發(fā)明可以有各種更改和變化。凡在 本發(fā)明的精神和原則之內(nèi)，所作的任何修改、等同替換、改進等， 均應包含在本發(fā)明的^f呆護范圍之內(nèi)。
權利要求
1.一種收集用戶體驗數(shù)據(jù)的方法，其特征在于，包括終端收集用戶體驗的數(shù)據(jù)；所述終端將收集到的所述用戶體驗的數(shù)據(jù)發(fā)送給服務器。
2. 4艮據(jù)片又利要求1所述的方法，其特4正在于，在所述終端收集用 戶體驗的數(shù)據(jù)之后，所述方法還包括所述終端對所述用戶體-瞼的凄t據(jù)進^^f呆存。
3. 根據(jù)權利要求2所述的方法，其特征在于，所述終端對所述用 戶體驗數(shù)據(jù)進行保存之后，所述方法還包括將保存下來的所述用戶體驗的數(shù)據(jù)組裝為數(shù)據(jù)包。
4. 根據(jù)權利要求3所述的方法，其特征在于，所述數(shù)據(jù)包為短信、 彩信或電子郵件格式中之一 。
5. 根據(jù)權利要求1至4中任一項所述的方法，其特征在于，所述 終端將收集到的所述用戶體驗的數(shù)據(jù)發(fā)送給服務器還包括所述終端將收集到的所述用戶體驗的數(shù)據(jù)以WEB網(wǎng)絡方 式發(fā)送給所述服務器。
6. 根據(jù)權利要求1至4中任一項所述的方法，其特征在于，所述 用戶體-驗的凄t據(jù)包括用戶體-驗的錯誤數(shù)據(jù)。
7. 根據(jù)權利要求1至4中任一項所述的方法，其特征在于，所述 終端將收集到的所述用戶體驗的數(shù)據(jù)發(fā)送給服務器還包括所述終端判斷是否發(fā)送收集到的所述用戶體驗的數(shù)據(jù)； 如果確定發(fā)送，則發(fā)送給所述服務器。
8. —種終端，其特4正在于，包^舌收集模塊，用于收集用戶體驗的數(shù)據(jù)；發(fā)送模塊，用于將收集到的所述用戶體驗的數(shù)據(jù)發(fā)送給服 務器。
9. 根據(jù)權利要求8所述的終端，其特征在于，所述終端還包括組裝模塊，用于將收集到的所述用戶體驗的數(shù)據(jù)組裝為數(shù) 據(jù)包。
10. 根據(jù)權利要求8所述的終端，其特征在于，所述終端還包括判斷模塊，用于判斷是否發(fā)送所述用戶體驗的數(shù)據(jù)。
全文摘要
本發(fā)明公開了一種收集用戶體驗數(shù)據(jù)的方法及終端，該方法包括終端收集用戶體驗數(shù)據(jù)；終端將收集到的用戶體驗數(shù)據(jù)發(fā)送給服務器。通過本發(fā)明解決了相關技術中收集用戶體驗數(shù)據(jù)的方式用時多、成本高，而且收集的數(shù)據(jù)也不能完整體現(xiàn)出結果以及不能解決所有手機的BUG的問題，進而達到了可以更方便更全面地收集用戶數(shù)據(jù)或錯誤數(shù)據(jù)，并且能更好的針對用戶改善自己的手機系統(tǒng)效果。
文檔編號H04W24/00GK101646200SQ20091016753
公開日2010年2月10日 申請日期2009年8月21日 優(yōu)先權日2009年8月21日
發(fā)明者鑫 郭 申請人:中興通訊股份有限公司