編輯導語：當下使用者面對的是爆炸級增長的海量資訊，使用者若想獲得自己想要的内容，則需要通過一定功能來達成目标，如搜尋功能，即使用者發出檢索行為，幫助使用者獲得結果的功能。不過，搜尋功能的開發是每個産品必需的嗎？本篇文章裡，作者就搜尋的定義、條件、應用場景等方面進行了總結，一起來看一下。
在最近跟近的項目中，有涉及搜尋這個功能。搜尋功能上線後，使用者沒有辦法通過搜尋找到想要查找的資訊，是以針對搜尋進行了一次優化疊代。
在日常使用各類産品搜尋的過程中，也發現不同的産品搜尋次元，搜尋結果的相關性也不相同，故想借此次思考，來對搜尋進行基礎的總結：什麼樣的産品需要做搜尋？以及在設計搜尋功能時需要注意什麼？友善大家以後在做搜尋功能的過程中進行參考，進而根據自己産品業務的特性進行調整。
<h1 toutiao-origin="h2">一、搜尋的定義</h1>
搜尋：仔細查找、搜尋的意思。即先有目标，才能進行查找。
比如：我在淘寶搜尋到了“收納盒”的資訊。是因為我想買個收納盒，是以才去淘寶上進行搜尋。引申到網際網路産品中，意指使用者通過在輸入框中輸入目标詞，按照某種規則，在某個範圍，查找符合目标詞的内容，并按照一定的規則為使用者展示相關結果。
為了避免資訊的遺漏，在系統檢索的過程中，需要對特定次元的全部的資訊進行查找。
以小紅書為例：當使用者想買面膜時，就會在小紅書上将“面膜”作為目标詞進行搜尋。系統會在已有的筆記庫内進行搜尋，并且根據筆記的特征和關鍵詞來做一個比對，完成比對後，會按照相應的規則進行一個排序、展示，呈現出搜尋引擎在小紅書筆記中抓取到的内容。
在此過程中：可以發現搜尋涉及到的流程：目标詞、搜尋規則、搜尋範圍、搜尋結果。
搜尋範圍：即使用者搜尋的目标詞與系統資料庫中哪些字段進行比對。
資料庫：就是存儲資料的倉庫，其本質是一個檔案系統，資料按照特定的格式将資料存儲起來，使用者可以對資料庫中的資料進行增加、修改、删除及查詢等操作。
資料庫中以表為組織機關存儲資料。根據表字段所規定的資料類型，我們可以向其中填入一條條的資料。以小紅書筆記表為例：組成筆記表的字段包含：筆記ID、标題、圖檔、筆記内容、發表使用者、發表時間、話題、标簽、釋出地點等資訊。使用者每釋出一則筆記都成為了筆記表中的一條資料。
當使用者搜尋“面膜”時，會根據小紅書筆記表中的标題、筆記内容、标簽字段進行比對。查找與之相關的内容。
搜尋結果：将符合的結果，按照某種規則排序後，呈現給使用者。
核心規則：與目标詞的相關程度，而相關程度的量化名額，即權重。在系統中，某一名額在整體評價中相對重要程度，在這裡意指，一條筆記的标題中、筆記中各個位置、标簽、評論、收藏點贊等資料中涉及“面膜”這一目标詞時，計算的權重比例是不同的。
搜尋的結果有若幹條，而使用者想要的可能就隻有一條。如何在若幹條相似的搜尋結果中，找到使用者符合使用者期望的那條資訊，就涉及到多種資料次元名額計算，根據不同資料名額的權重，找到更符合使用者預期的資料，按權重的高低，盡快在一堆整體差别不是很大的資料中，對資訊進行排序，幫助使用者更快找到想要的資料。
對小紅書的整篇筆記來說，位置不同，面膜在這篇筆記中的權重也會不一樣。權重越高，排序在前（筆記品質本身帶來的權重、筆記釋出賬号自身的權重、筆記點選率、點贊、評論收藏等等這些資料帶來的權重，甚至還包括評論你的使用者它自身的一個權重）。
搜尋作為一種工具，具有很強的使用者主動性，幫助使用者在海量的資訊中，快速找到自己的目标項。
在系統中，資訊不是自己産生的，它們放在哪裡，資訊裡面包含了什麼詞，對于使用者而言，一無所知，在資訊爆炸的今天，除了搜尋别無選擇。
是以搜尋變成了剛需，但不是所有的産品都要一開始就要先做搜尋。“别人有什麼，我也要有什麼”這種邏輯要不得，凡是都有成本，有利有弊，是否值得做，要看個友善是否合适。
不要高估搜尋對網站的作用，也不要低估建索引的成本。
第一是空間成本。
可以想象下，如果對深圳市的戶籍記錄按照人名建一個索引，再按照畢業學校、工作機關、家庭住址等等建索引，是需要占用很多空間的，建的索引越多，使用起來雖然會友善，但是空間成本也就高了。
如果我們把産品裡面的内容都建立起索引，索引本身建立的空間，大約是原來内容總容量的50%。也就是說如果你的産品的伺服器原來是42t，現在隻有21t來存放使用者生成的各種資料，要留出21t來放索引。當然，伺服器的記憶體還是足夠大的，占用多了，産品的速度會成倍地下降。
除了建立索引外，全表搜尋也是搜尋資訊方式，是将所有記錄一一取出，和查詢條件進行一一對比，然後傳回滿足條件的記錄，這樣做會消耗大量資料處理時間，并造成大量輸入和輸出操作。
第二是時間成本。在産品的初期，所有的研發都是在圍繞産品的核心需求進行開發，對于資料量還不大的産品而言，優先滿足高頻的場景功能是更優先的。
<h1 toutiao-origin="h2">二、搜尋的條件</h1>
<h2 toutiao-origin="h3">1. 使用者有明确的目标</h2>
當使用者有明确目标時，會通過搜尋來找到目标項，進而快速的找到自己所需的目标項。當使用者想要買一瓶洗發露，會打開淘寶進行搜尋；當使用者想買一本電商産品的書籍，會打開知乎先了解，找到想要的那本，然後去某寶搜尋進行購買……等等。
系統内資料量大。
<h2 toutiao-origin="h3">2. 産品資料量大</h2>
産品内資料量足夠多，使用者沒有辦法在短時間内快速找到自己的目标，可通過搜尋進行查找。
一個隻有50條資料的資訊網站，使用者在檢視尋找時，翻找5頁就可以了，不需要通過搜尋來找到目标項。在産品的初期，也不需要急急忙忙地把搜尋的功能堆砌上去，可優先考慮核心使用者高頻的場景的功能，等資料量上來了，再進行版本的疊代，避免資源的浪費。
<h1 toutiao-origin="h2">三、什麼樣的場景下會使用搜尋功能？</h1>
使用者在使用某産品時，想要找某個目标項，但是不好找，這種時候，就需要搜尋功能。能夠通過關鍵詞幫助使用者快速定位想要的資料。
由此可以看到搜尋場景的特征有：資料量大、目标項（關鍵詞）、目标項不好找，沒有辦法通過分類或者翻頁快速的找到目标項。
【得到APP】在産品初期也是沒有搜尋功能的。産品的種類有限，主要是為使用者提供音頻課程，剛開始的課程較少，使用者通過課程分類就可以找到自己想要的課程，随着時間的推移，得到的音頻課程數量的增加，以及産品種類的擴充：聽書、看書、錦囊等。為了友善使用者快速找到自己的目标項，上線了搜尋功能。
故可以得出，搜尋的場景：在某一産品中，内容資料量大，無法通過翻頁，以及分類快速找到自己想要的目标項時，這個時候就靠搜尋了。
首先，我知道自己要什麼？
其次，我知道去哪裡找？
最後，通過搜尋功能快速查找到。
不同的産品，搜尋到的資訊是不一樣的，想要買一顆生菜，就要去叮咚買菜、每日生鮮、美團買菜，而不是百度、知乎、小紅書。
搜尋作為一個功能，可以幫助使用者在産品内部的全量資訊中進行仔細查找，找到與之相關的資訊。
<h1 toutiao-origin="h2">四、沒有搜尋這個功能會怎麼樣？</h1>
從搜尋的場景中，我們能夠發現，搜尋場景解決的核心問題：在海量資料中，很難找到目标項、即目标項不好找。
沒有搜尋功能會對産品造成什麼影響？
使用者的查找效率變低。在海量的資料中，沒有辦法通過快捷的方式找到目标項，隻能逐條資訊翻看，勢必會影響查找的效率。如若目标項很難找到或找不到，進而也會給使用者造成不好的使用體驗，進而降低使用者再次使用産品的機率。
由此，我們可以發現，如果産品能夠提供搜尋功能，能夠有效提高使用者的查找效率，也能給使用者良好的使用體驗，再次使用系統。
<h1 toutiao-origin="h2">五、總結</h1>
1）搜尋的定義：使用者通過在輸入框中輸入目标詞，按照某種規則，在某個範圍，查找符合目标詞的内容，并按照一定的規則為使用者展示相關結果。
2）搜尋的要素：目标詞、搜尋規則、搜尋範圍、搜尋結果。
目标詞：即搜尋的關鍵詞，使用者想要搜尋的資訊；
搜尋規則：即目标詞與内容的比對規則；
搜尋範圍：即使用者搜尋的目标詞與系統資料庫中哪些字段進行比對；
3）搜尋場景是重點，産品内資料量大的時候再考慮。
搜尋不是小功能，莫要随便就開發，既要考慮空間成本，也要考慮時間成本。條件有了，再觸發。
參考：
1.第062封信：從windows Vista系統的失敗看到哪些商業邏輯——得到·矽谷來信2·谷歌方法論
2.3步闡述：簡單的搜尋框，為何不簡單？——人人都是産品經理·菜花
本文由 @鲸魚 原創釋出于人人都是産品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協定。