如何搞定站内搜索的产品设计及应用（上）http://blog.xiqiao.info/2009/06/02/343

如何搞定站内搜索的产品设计及应用（中）http://blog.xiqiao.info/2009/06/03/357

五、站内搜索的其它应用

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 通用化设计往往是最不易用的。