列表视图搜索教程：产品经理数据分析，避坑指南

列表页搜索量上升，不一定代表用户更容易找到目标记录；点击率提高，也不一定意味着任务完成得更快。分析“列表视图搜索”时，我更关心一条完整链路：用户带着什么目标来、输入或选择了什么条件、系统返回了什么、用户是否采取了正确的下一步动作。只盯着搜索框的使用次数，很容易把入口曝光、筛选习惯、权限限制和结果相关性混成一个问题。下面从产品设计、事件口径、数据诊断到不同场景下的取舍，拆解一套可落地的分析方法。

文中案例数据均为情景模拟，用于说明分析过程，不代表行业基准。

一、核心结论：别只问“搜了多少次”，要问“任务有没有完成”

1. 搜索不是一个控件，而是一段任务链路

列表视图搜索通常发生在用户已经进入一个对象列表之后，例如工单、订单、客户、内容或项目记录。用户输入关键词、组合筛选条件，系统再返回一组结果。真正要解决的，不是“页面上有没有搜索框”，而是用户能否在合理成本内找到目标记录，并完成查看、处理、分派或导出等后续任务。

因此，我会把搜索体验拆成五个可观察环节：入口是否被看到、条件是否表达了用户意图、结果是否符合预期、用户是否采取正确行动、行动是否完成任务。这五步中任意一环断掉，都可能出现“功能在用、问题还在”的情况。

例如，用户搜索某个客户名称，列表返回了匹配记录，但目标记录因为排序靠后没有被看到；这时搜索提交量正常、结果率也正常，问题却发生在排序与结果呈现。相反，如果用户输入工单编号后一直无结果，优先要查字段覆盖、数据权限、编号格式或索引同步，而不是先调整列表样式。

2. 产品分析的核心输出应是可验证的判断

我建议每次复盘都明确写出“观察到什么、可能原因是什么、如何验证、验证后采取什么动作”。例如，“无结果率偏高”是现象，不是原因；“用户经常把编号中的横线省略，当前匹配规则不支持容错”才是待验证假设。

一个指标只能描述结果，不能自动解释原因。搜索提交量低，可能是需求少，也可能是入口不明显；结果点击率低，可能是排序不准，也可能是用户只查看列表字段就已得到答案。指标要与行为路径、业务规则和用户任务一起看。

3. 先约定口径，再讨论好坏

“搜索成功率”不是天然统一的指标。团队可以把它定义为“搜索后发生目标记录点击的会话占比”，也可以定义为“搜索后在规定窗口内完成目标业务动作的会话占比”。两种定义回答的问题不同，不能只因为名称相同就直接比较。

在埋点设计前，我会先写清楚统计对象、分母、时间窗口、去重方式和排除条件。比如按用户、会话还是每次搜索提交计数；清空条件后重新提交是否算一次新搜索；权限不足导致的无结果是否纳入搜索无结果率。定义越清楚，后续复盘越少陷入“数据算得没错，但大家说的不是一件事”。

二、背景与真实场景：为什么列表搜索特别容易被误读

1. 用户在列表里找的通常不是“关键词”，而是“下一步要处理的对象”

在工单后台，客服可能要找“昨天创建、仍未解决、由我负责”的记录；在订单后台，运营可能要定位某个订单号并核对退款状态；在客户列表里，销售可能想找到最近一周没有跟进的重点客户。表面上看，这些需求都发生在列表页，背后的任务却可能是查找、筛选、核验或批量处理。

这也是为什么单独研究输入框里的搜索词会失真。用户可能先输入客户名称，再加上“待跟进”状态；也可能完全不输入关键词，只用日期和负责人筛选。若产品只统计文本搜索，就会低估筛选器对任务完成的贡献；若把筛选器操作全算作搜索，又会失去定位问题的能力。

2. 搜索、筛选、排序和分页要分开看

我会用一个简单判断来区分四者：搜索负责匹配对象，筛选负责缩小范围，排序负责安排先后，分页负责分批呈现。在实际产品中，它们可以组合出现，但数据分析时应分别记录。

• 搜索：用户输入编号、名称或关键词，系统按约定字段匹配记录。
• 筛选：用户选择状态、负责人、时间范围等条件，缩小候选集合。
• 排序：用户决定按更新时间、优先级或金额等字段排列结果。
• 分页或虚拟滚动：系统分批呈现记录，影响用户看到目标项的成本。

如果用户总是翻到第三页才点中目标记录，未必是搜索失效，也可能是默认排序不符合任务优先级。如果用户连续调整多个筛选条件后仍无结果，也可能是条件组合太窄，而不是搜索词匹配失败。先分清机制，才能选对数据切片。

3. 企业列表里的权限和数据状态会制造“假无结果”

在多人协作的系统中，用户看不到记录，原因可能是记录不存在，也可能是权限范围不包含该记录，或者记录尚未完成同步。对用户而言，这些情况都表现为“搜不到”；对产品分析而言，它们却对应完全不同的修复路径。

因此，如果业务允许，我会在日志或服务端诊断中区分“无匹配记录”“无权限记录”“数据未就绪”和“请求异常”，但不会把敏感信息暴露给前端用户。用户提示要安全、易理解；分析数据则应保留足够的原因分类，便于跨团队排查。

4. 用任务链路观察数据，而不是把一个比率当作答案

下面的图展示一个情景模拟的列表搜索链路。它不用于推断行业水平，而是说明每一层的用户流失都可能对应不同问题：从进入列表到提交搜索，关注入口和任务习惯；从提交到获得结果，关注字段、匹配和权限；从结果到完成动作，则要看相关性、呈现和业务操作是否顺畅。

三、常见误区：哪些数字看起来合理，实际容易误导

1. 把搜索使用量当成搜索价值

搜索量上升可能来自入口曝光增加、用户重复改词、一次任务多次尝试，甚至是默认筛选失效后用户被迫用搜索绕路。只看总量无法判断体验改善还是变差。

我会把搜索量至少拆成独立用户数、每位用户的提交次数、重复提交比例和完成任务的会话比例。若提交次数增加，但每次任务的改词次数、无结果比例和耗时也一起上升，更像是用户在反复尝试，而不是搜索功能更受欢迎。

2. 把有结果当成“搜对了”

系统返回记录，只能证明某些匹配规则命中了数据。它无法证明目标记录排在用户看得到的位置，也无法证明结果字段足以让用户判断相关性。比如用户搜索一个常见姓名，返回几十条记录，技术上属于“有结果”，任务上仍可能是失败。

因此，分析时要组合观察结果数分布、首屏结果点击、点击记录后的回退或改词行为，以及后续任务动作。对于高频、低区分度关键词，结果数量和排序往往比简单的有无结果更值得关注。

3. 把点击率当成搜索成功率

点击可能是用户打开了错误记录，也可能只是查看后发现不匹配。反过来，用户有时只需在列表首屏看到状态或金额，就已经得到答案，并不需要点开详情。将点击作为唯一成功信号，会同时误判这两类行为。

更稳妥的做法是把指标分层：结果点击用于观察列表到详情的转化；目标动作完成用于判断任务推进；返回列表、再次修改条件或短时间重复查询，则作为可能的摩擦信号。不同产品要结合业务确认这些行为的解释范围。

4. 忽略分母与去重口径

“无结果率是 10%”这句话信息不完整。分母可以是提交次数、搜索会话数或独立用户数。一个用户连续搜十次都无结果，在提交次数口径下会被计算十次；在用户口径下则只算一个人。两种数字分别反映尝试压力和用户覆盖，不能互相替代。

我通常先用会话口径回答一次任务是否顺利，再用提交口径定位反复尝试，最后按用户、角色或业务对象切分，检查问题是否集中在某类人群。统计窗口也要一致，例如将两分钟内连续改词归为同一轮搜索，还是作为多轮独立任务，需要提前定规则。

5. 用改版前后变化直接宣称因果

上线后搜索成功率上升，不代表提升一定来自搜索改版。如果同期新增了批量导入、调整了默认排序、清理了脏数据，或者业务流量结构发生变化，结果都可能受影响。简单前后对比可以作为线索，但不能单独证明因果。

条件允许时，可以按用户或业务范围做对照；无法实验时，至少记录同期变更、流量结构和业务周期，并按相同用户类型、相同任务入口进行比较。对样本较小的后台产品，逐条查看异常搜索记录，有时比追求一个“显著提升百分比”更有诊断价值。

6. 照搬所谓行业阈值

列表搜索的任务复杂度差异很大。一个输入唯一订单号的页面，与一个需要按客户、状态、金额和时间组合检索的运营后台，不适合直接共享同一套无结果率或点击率目标。没有公开来源、样本口径和适用场景的“行业平均值”，不应包装成产品验收标准。

更实用的基准，是同一产品在相同任务、相同用户类型下的历史表现，或者经过明确定义的对照组。如果暂时没有基线，先建立可信口径，再观察趋势，比编一个看似漂亮的目标更负责。

四、专业判断逻辑：从事件设计到问题定位

1. 先把关键事件串起来

事件不必追求越多越好，重点是能还原用户从进入列表到完成任务的过程。至少考虑列表曝光、搜索提交、条件变更、结果展示、无结果、结果点击、记录操作完成、清空条件和离开页面。对于支持组合筛选的页面，还要记录实际生效的筛选字段，而不只是“筛选按钮被点击”。

事件属性应尽量支持诊断，同时避免采集不必要的敏感内容。可以记录查询类型、条件字段、匹配结果数量、耗时区间、权限状态和入口来源；原始搜索词若含个人信息或商业敏感信息，应按合规要求做脱敏、哈希或限制留存，不要为了分析而默认完整保存。

2. 把指标分成四层，避免“指标大杂烩”

第一层是可达性。观察列表曝光、搜索框使用和条件面板展开，用来判断入口是否被看见、功能是否进入用户路径。入口使用少时，应先核对目标任务和入口设计，不急着扩大搜索字段。

第二层是匹配质量。观察有结果比例、结果数量分布、查询后改词或改条件的比例，并区分无数据、无权限和异常请求。无结果比例升高可能指向字段覆盖或数据质量；结果过多则可能说明条件不够具体、排序不合适或用户需要更细的筛选能力。

第三层是结果利用。观察首屏结果点击、结果位置与后续回退、重复搜索等行为。不要把“点击更多”直接理解为“更相关”，而要查看用户是否在点击后继续完成目标动作。

第四层是任务结果。观察从列表进入到目标动作完成的时长、完成比例和失败情况。时长需要结合任务类型解读：核对订单号可能本来就很快，批量处理工单则可能需要更长时间。不要把所有列表任务压成一个平均耗时。

3. 给每个异常写出“现象，假设，验证”

当数据出现异常时，我会先形成可被证伪的假设，而不是立刻提改版需求。比如“某类查询无结果增多”，可以拆成输入格式变化、字段未纳入索引、权限范围调整和数据延迟等候选原因，再用服务日志、查询字段分布和相关记录抽样逐一验证。

1. 确认现象：异常发生在哪个指标、哪类用户、哪种查询和哪个时间段。
2. 提出候选原因：至少列出两个可区分的解释，避免过早锁定单一原因。
3. 选择证据：用事件日志、结果样本、服务端状态或用户访谈验证假设。
4. 实施最小改动：先修复已确认的根因，避免一次同时改字段、排序和交互。
5. 检查副作用：观察误匹配、响应时间、权限边界和其他任务路径是否受影响。

4. 让指标承担诊断角色，而不是成为汇报装饰

下面这组模拟观察展示不同信号分别指向什么检查方向。它不是产品目标，也不是行业对标值。其价值在于把同一个“搜索体验不好”的笼统判断拆成入口、匹配、结果利用和任务完成四类问题。

5. 复盘时必须保留指标定义与数据边界

每次分析结论旁边都应写清数据范围，例如观察周期、纳入的用户类型、任务入口、去重规则和异常排除方式。若只分析了某个部门或某一类工单，就不要把结论写成“全体用户搜索体验已改善”。若数据量不足，也要明确指出趋势不稳定，而不是用小数点制造精确感。

对于搜索词和记录内容，尤其要注意隐私和访问控制。产品分析的目标是发现模式，不一定需要看到每个用户输入的原文。优先使用分类标签、字段类型、长度区间和匿名化样本；只有确有诊断必要且符合治理要求时，才访问更细粒度信息。

五、案例拆解：工单列表中的“搜不到”到底发生在哪一层

1. 场景设定与观察范围

以下是一个虚构的企业工单列表场景，用于演示分析流程，不对应任何真实组织或产品。用户需要按工单编号、标题、状态、负责人和创建时间寻找待处理记录。观察周期设为四周，模拟得到 12,480 次搜索提交、10,860 次至少返回一条记录、7,213 次发生结果点击、4,800 次完成目标动作。

仅凭这些总数，我不会先得出“搜索体验不错”或“体验很差”的结论。还要看提交由谁发起、查询字段是什么、无结果如何分类、结果点击后有没有处理，以及不同任务之间是否可比。总量只能告诉我们哪里值得继续拆。

2. 先用分群找到异常集中在哪里

假设进一步拆分后发现：编号查询的无结果比例较低，标题关键词查询的无结果和反复改词明显更多；同时，部分用户在搜索后经常增加状态条件。此时优先假设标题字段覆盖、分词规则或状态筛选默认值可能不符合用户预期，而不是笼统地认为“搜索算法不好”。

下一步抽样查看标题查询的实际输入和返回结果。如果大量输入是简称、内部缩写或常见别名，就检查别名映射和字段匹配；如果用户已经找到目标工单，却继续改状态条件，则更可能是状态字段展示或业务状态命名不清晰。一个相似的行为信号，背后可以对应不同根因。

3. 模拟分群数据如何改变判断

下表是一组情景模拟的提交数据。它的重点不是比较哪类查询“最好”，而是提醒分析者同时看无结果和后续动作。编号查询结果通常更精确，但不代表其他查询也应达到相同水平；标题检索的业务价值可能在于探索和发现，不能只按编号查询的标准验收。

注意，这里的“后续动作完成比例”必须对所有查询类型使用同一窗口和完成定义，才能进行有限度的横向观察。若编号查询多用于单条核验，而状态筛选多用于批量处理，两类任务复杂度不同，比例差异不等于功能质量差异。

4. 从标题查询的反复改词追到实际原因

假设抽样记录后发现，部分用户先搜部门内部简称，返回零条；改成完整名称后出现结果。此时可以验证是否需要同义词或别名支持。另一部分用户搜索后返回几十条记录，随后添加“待处理”条件才找到目标；这类问题更可能需要状态筛选更显眼、支持组合条件，或者调整默认排序。

两类用户都表现为“搜索后修改条件”，但解决方案不同。第一类可能要改匹配规则，第二类可能要改条件设计或结果组织。若一上来就扩大关键词匹配范围，反而可能让模糊结果变多，增加误点和数据暴露风险。

5. 试验方案要同时观察收益与副作用

如果决定支持常见别名，试验目标不应只有“无结果率下降”。还要同步观察结果数量分布、首屏目标记录点击、错误记录打开、后续动作完成和响应耗时。匹配越宽，可能越容易找到目标，也可能越容易返回无关结果；任何单一指标都不足以代表净收益。

若调整默认排序，则可观察目标记录是否更快出现在首屏、用户是否减少翻页和改条件，同时确认高优先级记录不会长期遮蔽其他记录。若增加筛选项，则要留意设置成本：条件越多未必越好，低频条件堆在首屏可能让常用任务更难操作。

6. 用“证据闭环”而不是“功能上线”结束案例

一个完整复盘至少包括：确认问题人群与查询类型；定位到匹配规则、条件设计或结果呈现的具体环节；实施一项边界清楚的调整；观察预先约定的主指标与护栏指标；检查其他用户和任务是否受损。上线只是开始，不是结论。

若结果改善只出现在标题查询，且错误记录打开没有增加，可以认为该方向值得继续验证；若无结果率下降，但结果数暴涨、误点增加，则应收窄匹配范围或调整排序。复盘的价值不在于证明方案正确，而在于确认收益、代价和适用边界。

六、不同情况下的行动建议：先做低风险、可验证的检查

1. 搜索使用量低

先核对入口曝光、用户是否进入对应列表、主要任务是否真的需要搜索，以及默认筛选能否覆盖高频工作。若用户通常按状态和负责人处理队列，搜索框使用少可能是合理现象；若用户频繁滚动列表、导出后再查找，才更像入口或能力缺失。

1. 按角色和任务入口拆分列表访问，避免只看全站平均。
2. 观察用户是否采用替代路径，例如导出表格、浏览器查找或反复翻页。
3. 访谈少量目标用户，确认他们找记录时首先想到的条件。
4. 只有明确存在查找任务且当前路径成本高时，再调整入口或默认条件。

2. 无结果比例高

不要立刻扩大模糊匹配。先区分用户输入、数据字段、权限规则、同步状态和请求错误。对于业务编号，可以检查前后缀、大小写、分隔符和前导零；对于名称或标题，可抽样查看简称、别名、错别字和字段覆盖。若权限是原因，应修复权限解释或申请路径，而不是让搜索跨越权限边界。

如果原因尚不清楚，可在短周期内增加有限的诊断日志，记录查询类型、匹配字段、结果数量和错误分类，不必默认长期保留完整原始查询词。确认根因后，删减不再需要的临时采集，避免诊断埋点永久堆积。

3. 有结果但少点击

先检查用户是否能仅凭列表字段完成判断，再观察结果数量、首屏位置、排序和关键词高亮。若用户只需确认状态或金额，低点击可能代表信息呈现有效；若用户不断改词、翻页或退出，才需要进一步排查结果相关性和信息密度。

对常见名称、宽泛关键词和重复对象，优先让关键区分字段更易见，例如编号、所属部门、状态、更新时间。不要只增加高亮效果，却不解决结果之间无法区分的问题。

4. 结果点击多，任务完成少

这种情况要检查点击后的页面、权限提示、操作入口和业务状态约束。用户可能打开记录后发现不匹配，也可能没有操作权限，或必须再经过审批才能完成任务。把问题全部归因于搜索排序，会漏掉真正的后续流程阻塞。

可以抽样观察“点击，返回列表，再次搜索”的序列，并按对象类型、用户角色和操作结果拆分。如果用户点击后很快返回且重复换词，相关性值得检查；如果用户停留较久但没有完成动作，可能需要研究详情页信息、权限和操作规则。

5. 搜索响应慢

响应时间要结合任务复杂度、结果量和请求状态观察。先区分前端渲染、网络请求、查询执行和索引更新，再决定优化方向。只看平均耗时会掩盖长尾问题，建议同时查看中位数和高分位延迟，并按关键词搜索、组合筛选和大结果集分层。

如果数据量增长导致组合条件变慢，可以先评估默认查询范围、分页策略、索引字段和返回列；若只有某类查询异常慢，则检查对应查询路径。分页加载速度提升不一定等于用户任务更快，最终仍要看目标记录是否更容易找到。

七、不同情况下的取舍：没有一种搜索方案适用于所有列表

1. 精确匹配与模糊匹配的取舍

精确匹配适合唯一编号、编码或强约束字段，优势是结果明确、误匹配少；代价是用户输错字符、漏掉前缀时可能搜不到。模糊匹配对名称、标题和描述更友好，但可能带来大量低相关结果、查询耗时和权限审查成本。

我通常不把两者做成非此即彼，而是按字段选择策略：唯一编号优先精确或可控容错，名称字段允许有限的前缀或别名匹配，长文本字段则需评估搜索范围、排序和索引成本。匹配规则越宽，越要同步检查误点和数据可见范围。

2. 常用条件前置与高级筛选的取舍

把更多筛选项放到首屏，可能让熟练用户少点一步，但会提高新用户的认知负担，也挤压列表空间。把条件全部收进高级筛选，页面更简洁，却可能让高频任务变慢。

可先按任务频率和错误代价排序条件。高频且用户容易理解的条件适合前置；低频、需要解释或组合风险较高的条件，可以放入高级区域。上线后观察条件使用率和完成任务耗时，并通过用户任务验证，而不是仅凭“看起来更整齐”决定布局。

3. 默认排序与用户自选排序的取舍

默认排序能减少操作，但产品团队替用户做了选择。按更新时间排序，适合追踪近期变化；按优先级排序，适合处理紧急任务；按创建时间排序，则有利于队列式处理。没有一种排序能同时服务所有角色。

如果不同用户的任务差异明显，可以提供清晰的排序切换，并让当前排序状态可见；如果任务高度统一，稳定且可解释的默认值更有价值。需要避免无提示地频繁改变排序，否则用户会失去对列表位置的预期。

4. 单次搜索速度与结果质量的取舍

缓存、索引和异步加载可以改善响应体验，但如果结果排序不贴近任务，用户仍会花时间翻找。相反，复杂的相关性计算也可能增加延迟。产品判断应把系统耗时和用户耗时分开：前者是请求性能，后者包含输入、修改条件、阅读结果和执行动作。

在高风险业务中，准确性和权限边界通常比极短延迟更重要；在高频、低风险的运营查询中，响应速度和批量操作可能更影响整体效率。取舍要由任务风险、数据规模、用户频率和错误成本共同决定。

5. 提升可见性与保护隐私的取舍

展示更多字段能帮助用户识别目标记录，也可能暴露不必要的信息。列表设计应遵循最小必要原则：显示足以区分对象和完成当前任务的信息，不因搜索分析方便而扩大数据可见范围。搜索结果必须继续受权限规则约束，埋点也要遵循同样的数据治理要求。

如果用户经常因为列表字段不足而打开详情核验，可以研究是否能安全地补充摘要字段；如果字段包含敏感数据，则应评估角色权限、脱敏策略和审计要求。效率提升不能以降低信息安全标准为代价。

八、落地清单：从需求评审到上线复盘

1. 需求评审前：先把任务说清楚

• 用户要找的对象是什么，目标记录有哪些可区分字段？
• 用户通常知道唯一编号，还是只知道名称、状态和时间范围？
• 找到记录后，下一步是查看、更新、分派、审批还是批量处理？
• 搜索、筛选、排序和分页分别负责解决什么问题？
• 哪些数据受权限限制，哪些查询内容可能包含敏感信息？

如果这些问题答不清楚，先补任务观察或用户访谈，而不是立即增加更多搜索字段。字段增加会扩大实现、测试、权限和维护范围，却未必解决真正的找数困难。

2. 设计阶段：写清行为与边界

把空输入、无结果、加载中、请求失败、权限不足、条件组合冲突、清空重置和条件回显逐项写清。特别要约定日期边界、状态定义、空值含义、编号格式和默认排序，避免前端交互与后端查询规则不一致。

对每个查询字段说明匹配方式：精确、前缀、包含、别名或范围查询。字段越多、规则越复杂，越需要把响应时间、误匹配和权限影响纳入评审。对用户而言，“搜索支持标题”还不够，需要知道标题按什么规则匹配、结果如何排序以及无结果时如何调整。

3. 埋点阶段：先定义指标，再实现事件

产品、数据和研发应共同确认主指标与护栏指标。主指标用于验证任务是否改善，护栏指标用于发现副作用。例如主指标可以是目标动作完成率或任务耗时；护栏可以是误操作、无权限访问提示、响应长尾和数据返回范围。具体选哪些指标取决于产品任务，不需要机械地全量采集。

埋点上线前用真实操作路径验收：一次查询会产生哪些事件？快速连续改词如何归会话？空结果和请求失败是否区分？批量动作如何确认完成？这些问题最好在开发联调阶段回答，而不是上线后才发现数据无法解释。

4. 上线阶段：建立基线并控制变化范围

如果产品已有稳定基线，按相同任务入口和用户类型进行比较；如果没有，先运行一段时间建立基准，同时检查埋点完整性。一次只改动一个主要因素更容易解释结果。若同时调整匹配规则、默认排序和筛选布局，即使指标变化，也很难判断哪项改动起作用。

上线后除了总体数据，还要看高频查询、低频但高风险任务、不同用户角色和异常案例。对影响权限或重要业务状态的搜索改动，应增加人工抽样与回滚方案，而不是只靠总量指标判断安全。

5. 复盘阶段：保留结论、限制和下一步

复盘结论可以按四部分写：确认了什么现象；哪些假设获得或没有获得支持；改动带来什么收益和副作用；下一步需要补什么证据。若样本小、观察期短或业务流量有明显变化，要明确写出限制。

如果指标没有变化，也不代表分析失败。可能说明假设不成立、改动没有触达问题环节，或当前指标不够敏感。把“没有证据支持原假设”记录下来，能减少团队重复开发，也比用模糊表述宣称成功更有价值。

九、结语：判断搜索好坏，最终要回到用户完成任务的成本

1. 一套值得复用的判断顺序

列表搜索分析最容易走偏的地方，是把控件表现当作用户价值：搜得多就说需求旺盛，有结果就说匹配成功，点击多就说体验改善。更可靠的顺序是先明确任务，再区分搜索、筛选、排序和分页，接着建立事件链路，最后用可验证的假设解释异常。

我会优先追问三个问题：用户是否能表达想找的对象？系统返回的结果是否足以支持判断？用户是否完成了下一步业务动作？如果其中任何一步没有证据，就不要用一个总点击率代替完整结论。

2. 读者可以立刻开始做的三件事

1. 选一个高频列表任务，写出用户从进入页面到完成动作的完整路径。
2. 检查现有埋点能否区分提交、结果、点击、条件修改和任务完成，并补齐指标口径。
3. 抽样复盘一批无结果、反复改词或点击后返回的记录，先找根因，再决定改匹配、筛选、排序还是权限提示。

列表搜索的质量，不由搜索框有多醒目决定，而由用户找到正确对象并完成正确动作所付出的成本决定。先把这笔成本测清楚，再讨论功能做大还是做小；这比追逐一个没有定义的“搜索成功率”更能帮助产品团队做出稳健决策。