close

如何搞定站內搜索的產品設計及應用(下) -網上推廣


五、站內搜索的其它應用

1. 流量引導

針對站內搜索本身,流量引導的主要方式是關聯、推薦和熱榜。
關聯: 包括搜索結果關聯、關鍵字關聯 和推薦內容的關聯
。如,關注該關鍵字的用戶還搜索過,買了此類寶貝的用戶還買過
推薦:根據用戶搜索的需求分類 推薦相關的網站內容或商品。

熱榜:熱門關鍵字排行,或上升快的熱門關鍵字排行。

2. 特殊情況的設計:

當用戶的搜索行為無搜索結果時、用戶的搜索行為有輸入錯誤或障礙、搜索結果過少時。

由用戶行為造成的無結果或少結果,有下列幾種狀況:

用戶拼寫錯誤。
用戶輸入了限制過多的關鍵字條件
用戶誤操作。

處理上述狀況,首先應該由程序判斷是否存在輸入的拼寫錯誤,在搜索結果之前首先提供糾錯建議,提示和引導用戶進行有效的操作,并根據數據挖掘,提供能滿足用戶搜索需求的有效關鍵字。如:“沒有找到相關結果,不如試試搜索****。”等。

如用戶輸入了過多的關鍵字條件,(如用戶直接在搜索框里粘貼了一句很長的話,且搜索設置為多關鍵字之間的匹配關系是與運算)應建議用戶使用正確的條件輸入方式。

誤操作的狀況多出現與用戶直接點擊了搜索按鈕而沒有輸入關鍵字。這種狀況不同網站有不同處理。如同頁面刷新、跳轉到搜索結果頁面但提示誤操作、blank跳轉到目錄或索引頁面、js彈窗提示誤操作。

非用戶行為造成的無結果或少結果,有下列幾種狀況:

分詞錯誤:例如人名、專有名詞、地名等專業詞匯被錯誤地分詞,造成有效結果不多。
無有效數據
上述狀況都應該在搜索功能的管理設置中有所反映,必須有手工補充關鍵詞庫的功能。必須能對少結果或無結果的關鍵詞進行數據統計,以幫助決策內容維護方向。

另一種狀況是當搜索結果過多時:用戶輸入了一個涵蓋范圍太廣的關鍵字,搜索結果多于20頁的時候。

寬泛的關鍵字定義不能幫助用戶有效完成搜索目的,用戶翻20頁以上去檢索的可能性很小,對網站性能也會造成不必要的浪費。

所以在搜索結果頁面提供分類和篩選是首要前提,也應該在適當的位置體現用戶使用關鍵字組合的正確方法或使用分類、篩選功能。

在分頁設置上,可以以只顯示20頁為一個區間。

3. 內容價值的優化處理

在論壇、知道、百科之類應用中,設計者比較不愿意看見的一個狀況就是問題和條目的重復,既浪費資源、分流用戶貢獻的有價值內容,也不利于信息組構。(流量膜拜主義的不在此列)

這類應用中,可在用戶提問、發帖的title輸入框旁邊放置搜索提示或搜索框,引導用戶在提問之前先搜索。

這個類應用可以通過搜索功能對內容價值進行優化。

4. 海量信息或歷史內容的價值最大化

對于新聞、資訊、論壇站這類海量信息站而言,信息結構的設計是極為重要的,僅將內容價值建立在熱門話題和更新速度上,是一種不明智和浪費的運維思路。好的信息結構設計,讓用戶不會在掃完熱門和更新內容后就無事可做,降低用戶跳出率、提高單ip的頁面瀏覽數。設計思路除了明晰合理的多級信息目錄結構,還應該根據運營需求建立起 話題眼、新聞脈絡、信息時間軸 等內容聚合點和內容聚合線索。

搜索和數據挖掘是幫助優化此類設計的重要選擇。

百度貼吧的偉大之處在于極大地發揮了由搜索關鍵字創建話題眼這一設計。

說到這,可能有人已經聯想到了 tag 和 埋在正文中的關鍵字鏈接。

 

對于論壇 或 非正規的信息站而言,通過tag來支撐一套信息維度是不現實的。

而正文中埋鏈接,多用于 產品庫(名人庫)這類專有詞,主要用于導流量,在文中高密度使用也是不現實的。

所以使用分詞技術或詞頻分析,在某篇文章中獲取核心關鍵字后,在側欄或標題/正文下方列出,是一個很好的處理方法。這種流量引導方式比“相關新聞”賦予用戶更大的選擇性,也更利于用戶深度挖掘內容發現內容。

通過處理發布時間排序,可以形成以時間為脈絡 新聞線索。

銀杏搜索和我曾經提出一個概念產品設計,用于大型新聞/資訊網站的新聞搜索,讓新聞關鍵字成為一個信息時間軸。

這個產品可根據某個關鍵字的搜索結果在時間軸上的分布,按時間區間輸出搜索結果量的指數圖,體現出到該關鍵字的新聞性時間趨勢。

 

當鼠標移上某個節點,會顯示該節點的日期和詳細結果數。

 

用戶可以通過點擊年份,放大趨勢圖,查看某年的搜索結果的詳細指數圖。

這個產品可以很容易通過時間體現新聞趨勢,強化傳播的時間維度上的表現力,用戶體驗新鮮,更重要的是可以利用埋藏著的歷史信息實現價值最大化。

 

這個應用還可以擴展為更高端的趨勢比較。當用戶輸入2個以上的關鍵字時,可以在指數圖中看見兩個關鍵字的對比折線圖,用戶可以對兩者搜索結果在時間分布上進行趨勢比較。

5. 應用于內容發布系統

站內搜索除了在前端使用,在信息發布系統中也有重要的應用。典型例子的是幫助使用者篩選相關新聞(包括專題組織中的相關新聞列表)。

我講一個我遇到過的案例:傳媒類網站的cms系統,最初的設計:使用者點擊“查找相關新聞”按鈕,blank彈出結果頁面,搜索條件直接取值于文章title和tag,全文檢索。但使用者總是對篩選出來的相關新聞不滿意,覺得匹配度不夠高。

例如

當使用者 為 ********(上)查詢相關新聞時,當然最希望出來的是*******(中)和*******(下),但是標題被分詞以后,再加上tag,由于詞頻權重的原因,中和下篇可能并不是排在前頭。
當使用者為一篇標題里包含 美國銀行 這個詞的文章查詢相關新聞時,排在前幾位的可能和美國銀行沒關系,而是奧巴馬競選或中美外貿。這是因為美國銀行會被分詞,拆為美國和銀行,出現美國或銀行頻度最高的文章會被排在最上面,如果美國和銀行之間采取 或運算 的話,結果就更糟糕。
經過溝通和分析使用者需求,我把一個“查找相關新聞”按鈕,拆分成了3個按鈕,以滿足使用者不同的搜索意圖。

按鈕1 “根據標題精確搜索”,用于查找系列文章,多個關鍵字之間采取 與運算,滿足精確關聯需求。
按紐2 “根據作者搜索” 僅匹配作者字段,用于精確查找該作者寫過的所有文章。
按鈕3“相關性搜索”,匹配title分詞和tag,滿足查找寬泛關聯的需求。
客戶此后就滿意了,幾乎不再需要手工自定義搜索條件,提供了處理效率。

這個案例的啟示是:1 站內搜索的應用設計中,搜索條件提取、多關鍵字的處理、匹配字段的處理 這些設定的變化,能對搜索結果、應用效率造成巨大差異,好的應用壞的應用由細節中產生。2 通用化設計往往是最不易用的。

原文:http://blog.xiqiao.info/2009/06/19/388

如何搞定站內搜索的產品設計及應用(上)http://blog.xiqiao.info/2009/06/02/343 
如何搞定站內搜索的產品設計及應用(中)http://blog.xiqiao.info/2009/06/03/357


arrow
arrow
    創作者介紹
    創作者 pagepe 的頭像
    pagepe

    pagepe的部落格

    pagepe 發表在 痞客邦 留言(0) 人氣()