移動搜尋產品分析

移動搜尋的形態有專門的搜尋APP，也有瀏覽器中自帶的搜尋。移動端無論是搜尋使用場景還是使用者使用習慣都與PC端有著明顯的不同，一方面搜尋功能多樣化，一方面搜尋的使用頻率在明顯降低。儘管使用率較PC端低，但鑑於使用者使用移動裝置的場景多樣化，移動搜尋的場景也豐富多樣，有使用者在PC端沒有的需求。下文針對移動搜尋進行產品分析

1、移動搜尋對比PC搜尋時的弱勢原因
移動搜尋起不到PC搜尋這樣的分量和流量已經是公認的了，很多大拿都發表過移動搜尋將要死的言論，而且目前使用者對於移動搜尋的使用率也相當低。具體原因有一下幾點

1）移動端服務的多樣性，使移動搜尋不再是流量的入口
PC端，大家都使用瀏覽器，流量都來自於網站，使用者依靠百度搜尋能得到一切內容。百度的地位就是流量的入口延伸到流量分發。而在移動端，由於服務的多樣化造成了APP成為主流，使用者有什麼需求就開啟相應APP，流量被分散到了APP中，因此搜尋服務範圍一下子就縮小了。
當搜尋的流量被APP分流了，不再是大眾化的流量入口，那麼也做不了流量分發的作用，基於搜尋的網頁連結生態也就不存在了。如果按照PC端的思路，那搜尋只能用在搜APP上了。目前還沒有APP中搜尋的功能（將來也不會有）

2）移動web使用率下降
如前所說，大家都去玩APP了，移動web玩的人就少了。移動web的表現形式與PC端的網頁類似，可供使用的功能有限，APP比web靈活得多。同時由於技術限制，移動web自身的特性就是載入慢，使用者體驗差。而且每次都需要開啟瀏覽器去查詢，遠不如APP顯得方便。
那麼，基於移動web的移動搜尋作用自然就減小了一大半。儘管搜尋自身還是一個應用，但使用者只能通過搜尋找到相應的web頁，即便有需求靠web頁也滿足不了。

3）使用者的搜尋需求被分散在了各個應用中
在移動端使用者並不是沒有搜尋需求了，而是搜尋需求被分散到了各個應用當中，使用場景變為了開啟APP，然後進行相應的搜尋，比如微信中的搜尋。除非應用能夠開放資料，不然這種搜尋就沒傳統的移動搜尋什麼事了。目前微信將資料開放給了搜狗算是一例，但本質上沒有改變。
同樣，在搜尋型別上使用者的需求搜尋需求也更加貼近自身需求了。PC端使用者只需要一個query，而移動端使用者在搜尋時有非常明確的型別和目標要求，因此只能用於應用內搜尋

4）移動搜尋使用者體驗差
移動端的搜尋使用者體驗比不上PC端和其他用於。首先手機的螢幕只有那麼大，不但只能展示兩條左右的搜尋結果，而且搜尋結果的介紹內容也得很簡略，對於搜尋這樣一種需要大量查詢的行為來說很不方便。其次，搜尋要開啟搜尋應用，輸入關鍵詞後再去搜尋，對比各種APP來說步驟繁瑣。之前百度等移動搜尋和PC搜尋一樣放上大量的推廣連結，搜尋進去後全是廣告，這還有誰要用？當然現在好多了

5）使用者沒有移動搜尋的習慣
APP已經成了使用者在移動端的使用習慣，各種不同的需求都可以通過APP實現，移動搜尋的使用率甚至不能排進APP型別的前十。對於養成習慣的使用者來說，通過移動搜尋來找資訊和服務已經不習慣了。

2、移動搜尋的作用點
那麼多問題看得出移動搜尋已經和PC搜尋是兩個世界了，然而移動搜尋並沒有死，還是有一些移動方向針對性的作用。總結起來移動搜尋有與PC端不同的使用者搜尋需求。

1）明確目標後分類搜尋的需求
使用者搜尋的需求依然存在，只是改變了方式而已，對搜尋目標的型別更加明確，比如應用搜尋，視訊搜尋等。因此移動搜尋肯定會更加分類化，同時搜尋應用自身也可以因分類而更好地整合結果形式。
分類搜尋更多地應用在各個領域中，搜尋APP若能成為某幾個領域的入口，那麼使用者的分類搜尋行為會大大增加

2）長尾詞搜尋網頁資訊的需求
大眾的詞彙使用者搜尋的目標更加明確，但是那些搜尋長尾的詞來獲取資訊的行為依舊沒有變。這也成了如今移動搜尋最常見的使用方式之一。這類需求通常不屬於專門的某一分類，使用者的目標更多的是得到包含相關資訊的網頁而不需要進一步的內容。
這類需求的形式比如問答等，需求型別和PC端一樣。PC端的搜尋在很大程度上也是由長尾的詞彙構成，因此這個方面移動搜尋可謂是繼承PC的模式。

3）沒有相關APP，或者只需要一次性服務的需求
對於有些資訊或者服務本身比較簡單，而使用者沒有針對性的APP的情況下，移動搜尋是最佳選擇。使用者的需求是以最快捷的方式獲取到資訊，比如旅遊時查詢景區介紹等場景。
這類需求的特性是使用者不需要額外下載APP，搜尋反而是最快捷的。同時使用頻次很低，很多都是一次性的，比如旅遊通常只去一次。只要資訊服務本身不復雜，搜尋是最佳選擇。當然這類作用中的進一步服務內容使用者會有其他需求

4）通過query直接進入相關服務
搜尋本身是智慧化程度很高的一種形式，技術的進步可以更加智慧的分析使用者的指令。當使用者的query作為使用者的直接需求能被搜尋引擎識別後，那麼通過移動搜尋一步到達服務將是移動搜尋發展的一個方向。
目前獲取相應的服務使用者都要進入相關APP去尋找，搜尋很不方便找到使用者要的服務。當搜尋達到一步直達的效果後，使用者體驗肯定大大加強，畢竟直接通過指令找肯定比在不同應用中漫天找資訊要快的多

3、移動搜尋的場景
分析移動搜尋，必須要理清楚使用者的使用場景，每個不同場景有什麼特徵。

1）搜尋新聞、天氣等常用資訊，場景同PC
特徵：使用者的搜尋目標比較確定，以獲取資訊內容為主
搜尋頻率：一般，因為有各種應用的分流

2）搜尋較為複雜的長尾詞，場景同PC
特徵：這類需求通常是APP中沒有的，或者很難找到的。使用者希望通過長尾詞的搜尋去查詢結果，得到資訊。目標資訊可能比較簡單。
搜尋頻率：高，等同於PC，因為APP中一般沒有

3）搜尋專門在移動裝置中使用的詞彙
特徵：搜尋詞限於移動裝置中，通常是通過其他應用直接複製過來
搜尋頻率：低

4）在外面，以提問形式搜尋
特徵：在外面遇到的問題，提問形式，希望獲得問答形式的答案，通常較緊急
搜尋頻率：低

5）在路上如車上，搜尋小說、電影等打發時間的內容
特徵：使用者利用碎片化時間的行為。搜尋的目標型別和搜尋詞都比較明確，搜尋需求不只是資訊，希望直接進入服務內容。結果需要儲存
搜尋頻率：高，碎片場合為主

6）在路上某地，搜尋該目的地相關的資訊
特徵：針對性明確如一個商家，搜尋目標包括各種資訊或者服務，全方位的瞭解。只是當下的瞭解，沒有進一步維持關係的想法
搜尋頻率：一般，多以一次性服務為主

7）在電影院/書店等店內，看到電影/書等，通過搜尋檢視詳細資訊
特徵：搜尋的目標型別和搜尋詞都比較明確，搜尋需求主要是資訊，評論等，對目標做一個深入的瞭解。與第五點略有不同
搜尋頻率：一般，在某固定場景下

8）在商場、購物街等，線下購物時，搜尋商品資訊
特徵：搜尋目標明確，需求主要是資訊比如價格。包含掃條碼、拍照的搜尋方式。結果需要儲存
搜尋頻率：一般，在某固定場景下

9）在路上，找路，找目的地位置
特徵：使用者在外面，需要結合自身位置資訊，查詢目的地，或交通訊息。沒有地圖的情況下找路線更多
搜尋頻率：低，因為有地圖

10）在路上，搜尋身邊有什麼或者周邊的某一目的地
特徵：在外面，需要結合自身位置資訊，搜尋可能目標不固定，需要對結果查詢。搜尋需求不限於資訊
搜尋頻率：中，通常結合地圖等應用

11）在商場等商圈內，直接通過搜尋進入商家主頁，完成商家的服務
特徵：前提是商家的主頁要有豐富的功能諸如預訂等，使用者通過搜尋商家名進入主頁，然後再進行各項服務。目前百度直達號做的就是這個方向
搜尋頻率：目前低，以後會高

4、根據場景分析使用者的需求
上述場景可以總結出使用者四個方向的場景需求，以及對搜尋結果的需求。每個方向都有相應的query形態
query型別：指向性明確，教簡單。如：杭州天氣，某新聞標題

1）獲取直觀資訊的需求
使用者通過單一的query獲取直觀的資訊，核心需求體現在獲取資訊本身，要直觀展示資訊

2）查詢到碎片化資訊的需求
使用者通過複雜的或者是問題形式來查詢資訊，主要需求就是某一點，但會在大量結果中查詢
query型別：長尾詞，複雜，字數多，指向性不明確，措辭不一定清楚

3）消磨時間的娛樂性需求
使用者通過單一的query，希望結果能夠直接進入最終的服務內容，不只是資訊，注重方便
query型別：指向性明確，型別明確，如書名電影名

4）獲取某實體具體資訊的需求
使用者通過單一的query獲取實體資訊，希望有一個資訊上的全方位瞭解，並且能收藏
query：名詞為主，明確，如某景點名稱。也有通過拍照掃碼的形式搜尋

5）結合自己位置的周邊需求
使用者結合自身的位置，希望查詢到周邊對自己有幫助的地方或者某地位置
query：目的地名稱，路名，交通名。如：2路；或者一類線下服務。如：附近的酒店

6）識別指令直達服務的需求
使用者能夠根據指令直接進入商家的服務內容頁面，在具備較完善的功能的商家主頁中完成相應的服務
query：商家名如海底撈，或指令性語句，如：附近的海底撈訂餐

5、根據query分析具體展示結果的方式
根據上述需求，舉例query，做展示結果的具體分析

第一類需求：
1）杭州天氣
期望展示結果：最大的需求是今天的天氣資料，此外還有最近幾天天氣，選擇城市，氣溫趨勢等
結果模擬：由於只需要來自某網站的一條結果。佔據整個螢幕。內容參見天氣應用首頁。下方顯示其他搜尋結果入口

2）蘋果CEO庫克宣佈出櫃
期望展示結果：該條新聞具體內容頁面，同時還有該專題頁面與相關新聞報導評論等。
結果模擬：首頁顯示5條結果。第一條顯示該新聞概要，新聞專題的入口和相關報導列表，佔到大半螢幕。後四個結果為主要入口網站的專題頁面，結果中包含該新聞連結與相關專題連結。後面幾頁形式與PC端一樣。或者標題匹配完全的直接進入某網頁的新聞具體內容中。

第二類需求：
3）美團校招產品設計一輪電面後多久能夠得到訊息
期望展示結果：通過結果列表找到問題的答案，問答的形式最好
結果模擬：與PC端一樣，一頁結果數為10條。第一個結果以百度知道等問答的形式出現，並且輔以幾個差不多的問題連結

第三類需求：
4）後會無期
期望展示結果：對於一部電影，上面的場景主要有幾種，打發時間的時候想看，線上下影院的時候想了解資訊，想去電影院看要買票。因此使用者希望看到該電影的觀看入口、介紹入口、評分和上映資訊、購票入口。最好要收藏頁面。一般看電影和買電影票會在不同的網站上
結果模擬：首頁結果以三種形式顯示三條結果。一條顯示電影介紹，簡單劇情，主演，評分這些資訊。一條顯示電影的排期和預訂入口。還有一條直接就是視訊本身。視訊的結果提供收藏按鈕。三條結果可以平行顯示讓使用者選擇，不用用列表。第二頁開始搜尋其他網站的該電影入口，同名書籍介紹等。每條結果同樣包含快捷入口

第四類需求
5）西湖
期望展示結果：使用者希望得到該景區的資訊以獲取全方位的瞭解，包括了介紹時間價格，景區地圖，子景點列表等。也包括攻略遊記資訊，同時輔以訂票的需求
結果模擬：首頁結果以三種形式顯示三條結果。第一條顯示景區時間價格介紹，子景點列表與入口，和景區地圖之類的使用工具，或者景區位置導航。該結果佔據整個螢幕。第二條顯示門票購買的資訊和幾個門票列表，帶上預訂按鈕。第三條顯示一些熱門的攻略遊記。第二頁再同PC端搜尋

6）iphone 6 價格
期望展示結果：最常見的是在購買時檢視價格列表做參考。除了報價以外還需要了解商品資訊，附近購買商家與電商商家等
結果模擬：三到五條左右。第一條展示商品的資訊，圖片，報價參考和報價列表，列表可以點選進入。後面兩條為地圖形式附近的商家檢視，和該商品的網購資訊。再往後以及第二頁是針對價格的新聞或問答資訊。

第五類需求
7）2路
期望展示結果：在路上，檢視公交路線資訊和公交車目前所在站點資訊。最好以地圖的形式。
結果模擬：一條結果，地圖，將路線標出在地圖上，將目前在路上的車標出來。第二頁的結果再以傳統形式

8）附近的快捷酒店
期望展示結果：根據自己位置列出酒店列表，包含的資訊包括名稱位置價格，預訂按鈕。結果自己篩選。地圖形式更直觀
結果模擬：訂酒店有很多網站。首頁五條結果左右。第一條為地圖，顯示使用者的位置和周邊酒店位置，支援點選酒店進入相關頁面。後面幾條為代理商的酒店列表，大致羅列三四家酒店，提供預訂按鈕和檢視詳細

第六類需求
9）附近的海底撈訂餐
期望展示結果：以百度直達號為例，使用者希望直接進入商家主頁的訂餐頁面
結果模擬：進入直達號（或商家的web頁面相應功能），顯示訂餐的頁面元素如時間人數，和餐廳選擇。下方可以選擇退出直達號，進入傳統搜尋結果

6、移動搜尋目前與未來的發展點
移動搜尋要滿足使用者進一步的需求，那麼勢必有一些發展的方向。目前百度推出的輕應用和直達號已經在這上面走了兩步，豐富了很多移動搜尋的場景

1）移動web頁功能豐富化
移動搜尋既然是基於移動web網頁，那麼移動web頁如何發展會影響到移動搜尋的未來。目前的web頁面更多的只是作為資訊展示，要做到功能豐富化，至少要讓web頁開啟後以APP的形式展示同時具備APP的基本功能。
目前HTML5正在發展，技術上正在改善。由於行動網路和APP或者PC網站都是不一樣的，要讓各大網際網路都開發移動web頁面，那麼搜尋應用必須做到web分發的平臺化，讓各網際網路和使用者能夠通過搜尋這個入口分發流量，方式要接近PC端搜尋
這方面，百度在前段時間推出的輕應用就是一個很好的典範。輕應用相當於重新包裝了一下web網頁，將其顯示成APP應用的形式，並提供基礎的APP功能。目前已經有很多網站開發了相關輕應用。百度自身作為了一個輕應用的分發平臺，彙集輕應用，支援使用者自主訂閱，不用安裝。輕應用今後的作用還不好說。
作為移動搜尋應用，在結合輕應用這種形式後，最好能夠通過搜尋來得到甚至直接進入該應用，能將使用者的搜尋需求結合到輕應用中。當功能豐富化的web頁能夠給使用者提供基本的服務，那麼移動搜尋快捷的特性就能顯露了。

2）根據query直達最終的服務
直達最終的服務，就是分析使用者的搜尋指令，直接進入相關服務頁面。影響使用者體驗的一個重要因素就是使用者找到目標網頁的方便性。當搜尋達到一步直達的效果後，使用者體驗肯定大大加強，畢竟直接通過指令找肯定比在不同應用中漫天找資訊要快的多。
直達服務，就是要改變結果展示的形式，在能識別關鍵詞的情況下直接進入搜尋結果的頁面，而不是逐條羅列結果。最簡單的形式比如搜尋天氣直接顯示一條詳細的天氣預報。
目前百度推出了直達號。直達號是企業在百度上類似於公眾號形式的一個網頁應用，功能更全面。使用者只要搜尋直達號就能直接進入。直達號做到了利用使用者搜尋連線商家服務，將使用者搜尋行為到最終服務更近了一步。
直達號的特點更多的是企業號本身的服務，還沒有對於使用者query的進一步分解。這點在去哪兒攜程中已經有所涉及。這兩款旅遊應用可以通過語音的智慧查詢來轉到相應的結果頁面，比如分析query中的時間地點詞彙進行結果的篩選。搜尋應用要做到智慧化包含的query分析更加複雜化，但這一定是一個發展趨勢

3）整合不同應用的分類搜尋
當使用者的流量都被各個APP分流，使用者的搜尋習慣也變為了分類搜尋時，搜尋應用就應該順應這樣的場景。目前在做的方法是分類搜尋，能夠解決使用者一部分的需求，但至少進入不了其他應用，只是限於web頁的內容
整合應用最關鍵的就是要有進入應用中獲取資料的許可權。儘管對於大部分應用來說這沒可能，但是當搜尋應用和其他應用之間能夠達成一定的利益關係之後，開放資料一方面能夠方便搜尋引擎檢索，豐富內容，另一方面目標應用自身也能夠從搜尋中匯入使用者的流量。（PC端的感覺）目前微信將公眾號內容開放給了搜狗搜尋，就是一個典型的例子。
移動搜尋本身的形式比較簡單，只是一個搜尋框，可以內嵌在其他應用中比如瀏覽器。當應用中搜尋的場景更加豐富之後，在應用中將搜尋變為第三方服務，就像現在的應用中內嵌地圖一樣，有利於雙方的資料打通，未嘗不是一種選擇