站內搜索(站內搜索是什么意思)

本文從為什么要做站內搜索出發，對做站內搜索存在的問題和具體設計步驟展開了梳理和分析，并從用戶角度對需要注意的問題進行了總結，與大家分享。

一、為什么要做站內搜索

對于一個單獨的內容站來說，搜索其實不算是用戶的常用功能，因為在絕大部分情況下，用戶會更加偏向于詢問他人，也就是傳說中的伸手黨。當無法從他人獲取自己想要的內容時，用戶才會傾向于去找進行搜索這個動作，而這個動作的發生環境通常也不是在一個單獨的內容站內，更多地會更偏向使用 Google、百度等搜索引擎。

站在用戶的角度，這樣做當然是更有意義的，能夠用較低的成本增加找到自己想要內容的幾率。但是與此同時，一個單獨的內容站為什么還需要自己做搜索呢？

1. 讓用戶盡可能少地離開網站去獲取信息

如果讓用戶都去通過搜索引擎獲取本站信息，用戶搜索關鍵詞的結果排序里，你的網站不一定能夠進入第一頁內。我們其實也都知道讓搜索引擎去獲取本站信息得以被搜索的初衷，不是去維護現有用戶，而是希望獲得更多精準用戶。

所以，站內搜索的主要目的是提高用戶使用本站的深度，獲取用戶搜索關鍵詞數據等。不過這部分需要時間去積累。

2. 部分網站不開放數據

有些網站由于業務上、戰略上等等原因，不會開放數據給搜索引擎使用，那么為了降低用戶找到內容的成本，提供站內搜索就是必然的選擇。

這種現象多出現于電商、O2O 等平臺，同時也由于移動互聯網的發展，入口和用戶習慣的改變，導致信息孤島急速擴張，更多的平臺選擇了只有部分開放甚至不開放數據。（現在也有巨頭在嘗試打破這個現象，比如說曾經的小米傳送門，和現在的微信搜一搜）

3. 用戶使用習慣的改變

這一部分其實前面已經提到了，當前使用互聯網的第一大入口已經從瀏覽器等傳統 PC 環境轉向移動設備上的 App。呈現給用戶的形式再也不是一連串不知所謂的網址，而是手機桌面上可見的、鮮艷的 App 圖標，至于傳統 PC 上用戶用得很多的網站聚合頁，也更多被各種 App Store 所替代。

當用戶進入 App，呈現給他的就只有當前 App 的內容，這種情況下用戶本能地會去選擇使用 App 內的搜索。

不過做站內搜索也有一些需要說明的問題：

（1）開發成本相對較高

如果一旦要求高一點，希望做一個體驗還過得去的站內搜索，涉及的東西就很多了，大體上可以分為：

每一部分都直接影響到最終的用戶體驗。

當然如果隨便一點，或者內容復雜度低，MVP 試行等等，都可以考慮先直接用 SQL 去模糊查詢。

搜索詞處理（糾錯、改寫、分詞等）關鍵詞和數據的匹配（標題匹配、內容匹配、生產者匹配以及權重）排序（時間、相關性、數據類型）

（2）投入產出比相對較低

前面說到了開發成本較高，那么在開發完成之后，這個功能的使用率會是多少呢？搜索是一個主動行為，在沒有額外機制和獎勵的情況下，用戶是被動的。同樣的，除非是知網、淘寶、知乎這種平臺，在絕大部分平臺上，這項功能的使用頻次必定不會太高。

這也屬于那種重要但不緊急的任務，站內搜索對于一個網站的必要性就有點像是，手機上發短信的功能，用戶可以不用，但是你不能沒有。

（3）內容量問題

搜索不到內容是一個搜索功能使用的時候最尷尬的時候，盡管可以通過一些手段，比如說相似內容推薦、熱門搜索推薦等等；但是不可否認的是，在正常情況下（用戶搜索正常詞句，且與平臺相關）如果搜索不到內容，盡管做了這些處理，但依舊是沒有徹底解決根本的用戶效率問題。

所以，在做這個功能的時候，平臺的內容量一定是必須要考慮的問題。

二、搜索：詞、匹配、排序

在講具體內容之前，需要給大家先介紹一下搜索引擎搜索方式—— Site。

這應該也算是大家都會經常用到的搜索技巧了，這種搜索方式其實完全可以理解成各大搜索引擎給網站提供的免費站內搜索。

那就有個問題出現了，為什么不去使用搜索引擎的 Site 方式作為網站的站內搜索呢？這樣的網站其實是有一些的，比如說 V2EX。

用搜索引擎的站內搜索好處有很多，比如說開發成本極低，用戶使用成本低，搜索精準度相對較高等等

但是壞處其實也有一些：

首先是排序，搜索引擎的排序算法是你無法干預的，這就導致無法提供業務上所需要的排序；比如說商品網站，搜索電飯煲，搜索引擎可能更偏向相關度、時間等等，但是其實在業務層面，銷量、好評率等等也是非常重要的考量因素，而這些數據不說搜索引擎能不能納入權重，就算能，那這些數據是否能夠提供給第三方也是個問題然后是網站類型不同導致的數據類型問題，資訊、問答、社區、商品等等類型的平臺，所提供可供搜索的內容是完全不一樣的，而現在搜索引擎很大程度并不能完全滿足絕大部分的內容類型。最后就是更新，目前想要讓搜索引擎快速收錄網站鏈接的方式中最主流的是站點地圖，但是站點地圖的最大問題就是更新不及時，也很難預測到什么時候會編入索引，什么時候會收錄。1. 搜索詞處理

搜索詞解析方式目前比較普遍一點的就是分詞和糾錯。

前者目前來講，稍微好做一點。GitHub 上也要大量開源的分詞框架庫可以使用，同時也支持自定義。這一部分建議之后要好好收集一下用戶的搜索詞，看看分詞出來的詞語是否切合用戶當時希望表達的意思。同時也要根據業務調整，比如說在電商平臺搜索 ”智能電視“，不能結果出來只有 ”智能“ 和 ”電視“，”智能電視“ 這個詞本身就應該也作為一個關鍵詞存在。

后者難度稍微高一點，因為現在的糾錯不在于說沒有方法去做，而是在于說假如不契合業務，可能會導致一些奇怪的結果。

尤其是錯誤糾正方面（糾錯的流程大體為 錯誤字(詞)識別 → 錯誤字(詞)糾正）。不過錯字(詞)有時候確實會影響到分詞效果，進一步影響到搜索的結果，所以這個還是有必要去做的，不過可以考慮用戶量再大一些，數據更加豐富的時候去做會更好。

以及后面可以涉及到更加深入的用戶搜索詞預測，這個就更加復雜了，筆者也不了解，就不多說了。

2. 匹配

互聯網上的能看到的內容都可以叫做數據，而絕大部分數據都會存在于數據庫的一張一張表之中。匹配的根本就是將搜索詞拿來去這些表里查找，找到合適的數據。

但是這樣做效率太低了，為了提高效率和精準度，自然要規定一下搜索的范圍，所以通常我們會對搜索進行分類處理，比如說這個關鍵詞是搜索商品的，這個關鍵詞是搜索文章的。

當然，讓用戶去選要搜什么分類已經是古早互聯網時期的做法了，現在更加常見的做法是展示出所有的內容，但是分塊展現，比如說知乎，綜合下就帶有話題、專欄、問題三種形式。

上面說的是匹配的范圍，匹配還有另外一個重點就是匹配的覆蓋面：

同一個類型的數據，比如說一篇文章，可能包括標題、作者、時間、內容、評論等等數據。那么你的匹配是要覆蓋到哪些數據？標題？作者？時間？或者內容？

如果上面很多都想做匹配的話，那就叫多字段匹配或者多字段搜索，最簡單的方式就是把多個字段組合起來建索引。

另外，如果說你還希望搜索匹配這篇文章的內容，而文章的內容通過都是很長的富文本或者文本形式，那么可能你還需要使用全文匹配來幫助你。

以上兩種其實只是目前比較常見的搜索匹配方式，技術領域中有很多方法來解決這些問題，但是還是建議產品有時間可以多了解一下，可以更加理解技術的局限、邊界和成本。

3. 排序

排序一般會根據相關度、內容用戶相關數據、時間等等情況排序，比較依賴于業務屬性。比如說新聞網站，時間維度的權重可能就會比較重；電商網站可能就比較看重銷量、知名度、利潤、優惠（比如說特定打折時期，將品類中讓利較多的商品展現出來吸引用戶）；內容網站可能還會涉及到用戶是否讀過，解決用戶想憑借幾個詞找到之前度過的文章這個場景。

所以這部分很難說有什么標準的解法，視業務和用戶群體而定。

三、用戶視角

這部分是相對比較偏設計的，也是整個搜索的最后一部分，我大概整理了一些點可供參考：

1. 搜索框位置

現在的網站和 App 中，搜索框位置通常處于上方，這個位置屬于一個不會阻擋正常內容消費，也能夠很方便使用的位置。

我個人出于對用戶習慣的考慮，比較建議如果沒有特殊情況或者產品結構傾向的話，放在頂部即可，可以不是搜索框的形式，但是一定要有足夠清晰的標識，降低用戶找功能的成本。

2. 引導文

引導文就是指搜索框內，未輸入時的提示；古早時期，比較常見 ”請輸入搜索關鍵詞“ 這種說法，但其實這個位置還是比較重要的，既可以提前展示重要信息又可以作為推廣的渠道。所以更加建議和運營方商量去決定如何處理。

3. 熱門搜索詞

點擊搜索的時候，在部分 App 和網站，會展示出熱門搜索詞。這些搜索詞和引導文一樣可以起到引導用戶使用的作用，同時也在一定程度上降低了用戶的使用成本。

不過這部分做起來不算簡單（主要是運營規則和邏輯），同時效果在前期通常不太明顯，建議初期不做。

4. 搜索歷史

這在大部分網站或 App 中都屬于一個補足用戶體驗的功能，但并不是剛需。所以我個人認為和熱搜一起屬于初期無需做的功能。

5. 結果相對較少或者沒有時的處理

結果少或者沒有，有時候其實不是數據的問題，而是在前面的搜索詞處理上出了問題，比如說沒有糾錯等等。

但是畢竟已經展示給用戶了，還是得思考一下如何展示。

展示相關度比較高的內容應該更加推薦的做法，因為這樣會相對更加符合用戶的預期。

當然，重點就是相關度了，相關度的理解也比較取決于業務——文章的分類、商品的品類和可能有的具體 SKU 屬性、求職產品的職業或城市或行業等等。

有了對相關度的解讀，之后就是具體的文案提示和結果展示了。

四、總結

其實上面有很多我自己說的，在現實中的項目也沒有做到，但是由于其中的搜集、學習，因此對這個功能有了更加全面的了解，之后的迭代才會更有把握做好，希望這篇文章對大家有點用吧。

作者：許珂誠，微信公眾號：XKC的123

本文由 @許珂誠 原創發布于人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基于CC0協議