在你的Shopify集合页连点五个筛选之后，用户其实已经忘了自己选过什么

摘要：顾客在集合页连点几个筛选之后，多数店铺只在侧栏的复选框上打了个勾，页面正文一个字都没交代现在这批货是按什么条件筛出来的。Baymard的桌面基准里有28%的站点根本不提供这样一条总览。这篇把它拆成三件事：确认、撤销、上下文；再给出桌面三个摆放位置、手机两种溢出处理的取舍，跨境站该不该在标签里写筛选类型的判据，以及Shopify主题里active_values和url_to_remove这两个字段该怎么用。最后附上我自己把这条带做得太完整、结果手机端加购掉下去的复盘。

用户点完筛选之后，页面凭什么让他相信自己选对了？

先把这个模块要解决的三个具体缺口摆出来，每一个都对应用户的一个真实动作。

筛选点下去了，可页面上哪一处告诉过他

设想一个买烤箱手套的德国顾客站在你的集合页上。她点了耐热等级、点了材质、点了颜色，又拖了一下价格滑块。四个动作做完，列表确实换了一批货。

现在问一个很笨的问题：页面上哪一处，用人话告诉过她刚才发生了什么？

多数站的答案是：侧栏那四个复选框上多了四个勾。桌面端如果侧栏很短、四个勾又都在可视范围内，这个答案勉强成立。可只要筛选项一多，勾就散落在一条要滚两三屏才看得完的长栏里；换到手机上，筛选面板本身是个抽屉，选完就关掉了，那四个勾连同整个面板一起从屏幕上消失。

于是页面进入一种很微妙的状态：它确实按用户的意思换了一批货，却没有任何一处在说这批货是按什么换的。用户手里握着结果，却拿不到那张收据。

这篇要谈的就是那张收据——把当前生效的筛选条件，用一排可读、可点、可撤销的标签，摆在商品列表正上方。行业里管它叫已应用筛选总览。

第一个缺口：他不确定筛选到底生没生效

点击之后没有确认，是交互设计里最基础的一类失败。放到集合页上它的表现很具体：列表刷新了，用户却不知道是因为自己那一下，还是页面本来就在加载。

Baymard那篇关于已应用筛选总览的研究里，被试在桌面端为了确认自己勾了什么，得回到侧栏一格一格地扫。如果侧栏用了内嵌滚动区，部分选项还藏在滚动条下面，扫都扫不全。

这里有个容易被忽略的时间差。用户点第一个筛选时，注意力还在筛选面板上，确认成本几乎为零；等他点到第三、第四个，注意力早已跟着列表往下走了。越往后的选择，用户越记不住，而恰恰是越往后的选择越决定最终看到的是哪一批货。

结果就是那种谁都遇到过的迟疑：明明筛过了，还是忍不住回去再确认一遍。这一趟折返在数据里不会留下任何异常，它只是让整个挑选过程变慢，慢到一部分人干脆算了。

第二个缺口：想撤掉一个条件，他得回哪儿去撤

筛选这件事天然带着试错。用户先把条件收得很紧，发现只剩三件货，就要松开一个再看看。松开哪一个、怎么松，是这个流程里最高频的动作之一。

没有总览带的时候，撤销的路径是：想起自己勾过什么，找到那个筛选组，展开它，取消勾选。手机上还要先把抽屉重新拉出来。四步操作，每一步都可能出错。

有总览带的时候，撤销的路径是：看见那个标签，点它右边的叉。一步。

更关键的差别不在步数，在于前一条路径要求用户先回忆，后一条只要求他辨认。这两件事在大脑里的成本根本不是一个量级，下一节会拿一份研究把这层说透。

顺带说一句，撤销做得顺不顺，直接决定了用户敢不敢多点几个筛选。撤销越贵，用户越保守，他就越倾向于少筛几下、然后在一个几百件的列表里硬翻——而这恰恰是筛选功能存在的意义被架空的样子。

第三个缺口：他忘了自己现在看的是哪一批货

前两个缺口讲的是操作，第三个讲的是理解。

用户在列表里滚了两屏之后，脑子里那份筛选条件清单已经开始褪色。他看到一双39码的鞋，会本能地想：这是我筛过的尺码里的，还是漏进来的？他看到一个偏贵的价格，会想：我刚才是不是把价格上限拉太高了？

这些疑问单个看都很小，加起来却构成一种持续的低度不确定。用户不信任列表，就不会认真看列表，他会用扫的，扫完就走。

还有一种更隐蔽的情形：用户从别的入口回到这一页。他点进某件商品，看了看，按返回键退回列表——很多站在这一步会把筛选状态保留住，这本来是好事，但如果页面上没有任何标记，用户就会以为自己回到的是那个完整的集合页。接下来他会奇怪：怎么这个分类才这么点东西。

我在做电商站的转化诊断时见过好几次这种误会，用户在会话录像里反复上下滚动，看起来像是在挑，其实是在找一个解释。

这三个缺口，为什么在手机上会同时放大

桌面端的侧栏是常驻的，它至少提供了一份不完美的备份。手机端没有这份备份。

手机的筛选面板通常是全屏抽屉或者底部弹层，用户选完点应用，面板收起，屏幕上只剩商品。这一收，前面说的三样东西一起消失：确认没了，撤销入口没了，上下文也没了。

更麻烦的是手机端的可视面积。桌面端就算把总览带做得笨一点，占掉的也不过是一条窄边；手机上多一行就是多推掉半个商品卡片。这就带来一个后面要专门讲的矛盾：这个模块本身就在跟它要服务的商品抢地方。做得太省，用户看不见；做得太满，用户看不见货。我自己就在这上面栽过一次，第九节会完整交代。

所以别把它当成一个桌面端做好了顺手搬到手机的组件。它在两块屏上要解的是同一个问题，代价结构却完全不同。

还有多少站没做这件事，先看基准数字

Baymard的桌面基准显示，72%的站点提供了某种形式的已应用筛选总览，另外28%完全没有。

这个比例值得琢磨。它高到足以让用户形成期待——四分之三的站都这么干，用户会默认这条带存在，找不到就愣一下；又没高到成为常识，所以那28%里不少人根本没意识到自己缺了什么。

把它翻译成独立站的语言：这不是一个能带来优势的功能，而是一个缺席就会扣分的默认项。做了，用户不会夸你；没做，用户也不会投诉，他只是挑得更慢、更犹豫、更容易走。这类既没有掌声也没有骂声的缺口，在数据里最难被发现，因为它不产生任何报错。

顺便提醒一句，这个28%说的是提供与否，不是做得好不好——在做了的那72%里，实现质量的差距同样大得吓人。

已应用筛选总览是个什么模块？跟侧栏那套筛选面板差在哪？

边界划不清，改起来最容易改错地方，所以先把它和几个邻居分开。

一句话定义：它是选择的回执，不是选择的入口

已应用筛选总览是这样一个东西：一排横向排列的小标签，每个标签对应一条当前生效的筛选条件，标签右侧带一个可点的移除符号，整排通常还配一个清除全部。位置在商品列表正上方，或者紧贴筛选区下沿。

它有三个必须同时满足的属性，缺一个就算不上总览。第一是完整：所有生效的条件都要在里面有位置，包括价格区间这种不是勾选出来的；第二是可读：写出来的是筛选值本身，不是数量；第三是可撤：每个标签自己就是撤销入口。

倒过来看就是三种最常见的假总览：只显示筛选(3)这样的计数、只列出部分类型的条件、标签只能看不能点。第三种尤其阴险，它长得跟真的一模一样，用户点上去没反应才发现被耍了。

说它是回执，是因为它在流程里的位置很特别：它出现在动作之后，不参与动作本身。这一点决定了它的所有设计取舍，包括后面要讲的位置、宽度和溢出处理。

它跟筛选面板的分工，到底是怎么划的

侧栏那套筛选面板负责让用户做出选择，总览带负责让用户知道自己做过什么选择。前者是输入设备，后者是显示设备。

很多人第一反应是：面板上不是已经有勾了吗，为什么还要再显示一遍？这个疑问在纸面上很有道理，在真实使用里站不住，原因是面板上那些勾的可见性是有条件的，而总览带的可见性是无条件的。面板要么被滚动挪出视野，要么在手机上被整个收起，它随时可能不在场。

还有一层分工更容易被忽略。面板里的信息组织方式是按筛选类型分组的——颜色一组、尺码一组、价格一组，用户要拼出自己的完整选择，得在脑子里从几组里各挑出一条再合起来。总览带的组织方式是按已选事实平铺的，不需要任何拼装。

所以哪怕在面板全程可见的宽屏上，两者也不重复。类目页那套完整机制里，面板解决的是发现有哪些维度可筛，总览带解决的是确认我筛到了哪一格。

识别比回忆便宜，便宜在哪一层

前面反复说撤销那条路径要求用户先回忆，这句话不是修辞，它背后有一份很老实的认知研究。

尼尔森团队关于识别与回忆的那篇文章把区别讲得很干净：回忆是从零把信息捞出来，识别是在给定的选项里认出正确的那个；识别之所以更容易，是因为它提供了更多线索，而线索会把相关记忆的激活度推高。

那篇文章还列了影响激活度的三个因素：练习次数、最近使用时间、以及关联。筛选场景把这三条全占了个不利的位置——用户不会反复练习自己刚点了什么，那次点击发生在几十秒前但中间隔了两屏滚动，而列表里的商品跟他选过的条件之间也没有直接提示性的关联。

把总览带放上去，等于把一道开放式问答改成了选择题。文章里那个比喻很到位：在街上遇见一个人，认出他很容易，叫出他的名字很难。用户对自己十几秒前的筛选，就是那种认得出但叫不出名字的状态。

这一层也解释了为什么单纯显示数量没用。数量提供的线索太少，用户看到筛选(4)只能确认有四条，仍然要靠回忆去补齐是哪四条。

它跟面包屑、跟搜索词回显，是不是同一类东西

是同一族，但职责不同，混着做会出乱子。

面包屑说的是这个页面在站点结构里的位置，它是层级性的，父子关系明确，通常要打结构化数据。筛选总览说的是这个页面此刻的状态，它是平行的，几个条件之间没有从属关系，也不应该打成面包屑标记。

见过有站把筛选值直接续在面包屑后面，做成首页 > 厨房用品 > 烤箱手套 > 硅胶 > 红色。看着挺整齐，问题有两个：一是用户点面包屑里的某一级期待的是跳转到更上层，点筛选标签期待的是移除这一条，两种期待撞在同一个控件上；二是如果顺手把这段也写进面包屑结构化数据，就等于告诉引擎有一条并不存在的分类路径。

搜索关键词回显是另一个近亲。用户在站内搜了烤箱手套，结果页上方回显一句显示烤箱手套的搜索结果，这跟筛选总览的逻辑几乎一样。区别在于搜索词通常只有一条，而筛选条件天生是多条并且可以逐条撤销。如果你的搜索结果页也支持筛选，那这两个模块就得共存，并且要能一眼看出哪个是搜索词、哪个是筛选值。

三个模块的职责，用一张表分清楚

下面这张表是我自己在改站时用的，主要防止改错地方——很多时候团队说筛选体验不好，实际要改的是面板不是总览，反过来也一样。

判断该改哪个，有个很土的办法：把用户的抱怨改写成一句话。抱怨里如果出现找不到，那是面板的事；出现不知道、忘了、撤不掉，那是总览的事。这两类抱怨在客服工单里的措辞差别很稳定，比问卷可靠。

为什么说这条带是集合页上唯一说得清现在是什么的地方？

这一节是全篇的地基，也解释了它跟站内那几篇筛选网址治理为什么不是一层。

用户筛完之后，这个页面上到底有多少东西真的变了

把一次筛选拆成机器视角，变化比你想的多。以Shopify为例，用户勾一个变体选项，URL会多出一段filter.v.option.color这样的参数，商品列表被重新计算，官方那份门店筛选文档里还写了一条很多人不知道的细节：当变体级筛选生效时，列表里每个商品的主图和链接都会切换成第一个匹配该筛选的变体。

换句话说，用户筛了红色之后，看到的图确实是红色那一版，点进去也直接落在红色变体上。平台在数据层做得相当细。

再看没变的部分：页面的H1还是那个集合的名字，标题标签没变，元描述没变，页面上那段品类导购文案没变，通常canonical也还指着不带参数的集合页本体。

于是页面进入一种分裂状态：所有描述这个页面是什么的地方，说的都是母集合；而真正摆在用户眼前的那批货，属于一个子集合。这个分裂不是bug，绝大多数站都这样，也应该这样——你不可能给每个筛选组合都单独写一套标题。

但既然分裂存在，就必须有一处东西站出来说清楚当前状态。整个页面上，能承担这个职责的只有那条总览带。

为什么标题和H1不跟着筛选变，反而是对的

偶尔有人问：干脆让H1跟着变不就行了，筛了红色就改成红色烤箱手套。

这个想法在少数场景下成立，在多数场景下会闯祸。筛选组合的数量是乘出来的，而标题是要人写的，四个维度各五个值就是六百多种组合，自动拼出来的标题读起来像机器报菜名，还会跟你真正想做的那几个着陆页互相抢。

更要紧的是，H1一旦跟着参数动，页面就从一个稳定实体变成了一台状态机。分面导航治理要解决的那堆麻烦，很大一部分就来自这种把每个组合都当成独立页面来包装的冲动。

所以正确的做法是承认分裂：标题和H1描述稳定的那一层，总览带描述易变的那一层。两者各司其职，谁也别抢谁的活。

这也是我把这条带叫作状态声明而不是装饰的原因。它不是好看不好看的问题，它是页面上唯一一处随参数变化而变化的、以人类语言书写的自述。

这跟站内讲的那几篇筛选URL治理，不是一回事

站内已经有几篇专门讲筛选产生的URL怎么管：组合爆炸怎么防、哪些该写Disallow、五类参数各自怎么处理。那几篇回答的是同一个问题的不同侧面：这些URL该不该让爬虫看见、该不该进索引。

本篇问的是另一个层次的问题：不管这一页最后索不索引，它先得能把自己说清楚。

这两层的对象都不一样。治理层的对象是URL集合和抓取预算，本篇的对象是一个页面上的一块可见区域。治理做得再好，那条带缺席，用户照样一头雾水；反过来，那条带做得再漂亮，也不能替你决定六百个组合里哪一个值得被收录。

我把它们分开写，是因为在实际项目里最常见的错配就是拿治理方案去回答体验问题——技术同学说筛选页我们都noindex了，运营同学说那用户为什么老抱怨看不出筛了什么。两句话都对，说的根本不是一件事。

你决定放行索引的那几个组合页，最依赖的恰恰是这条带

治理做到最后，总会留下一小撮值得单独做成着陆页的筛选组合，比如四人帐篷、无线吸尘器、防滑硅胶手套这种本身就有搜索需求的组合。这类页面通常保留索引，甚至专门优化。

这里有个很容易踩的坑。假设你留了/collections/oven-mitts?filter.v.option.material=silicone这个组合页，它的H1是烤箱手套，标题是烤箱手套，正文导购是烤箱手套，整页唯一提到硅胶这个限定词的地方，就是那条总览带上的一个小标签。

如果那条带做得薄——只显示一个数量，或者干脆没有——这个页面对机器来说就是一个跟母集合高度雷同的近重复页。你花力气保下来的着陆页，自己没能说出自己是谁。

这一层放到AI搜索的语境下更明显。集合页在AI购物里的角色本来就是被拿去回答某某品类里适合某某条件的选择这类问题的，模型要判断这一页覆盖的是哪个条件，靠的就是页面上那几处显式写出来的限定词。可见性和可引用性在这里合成了同一件事。

如果这条带只活在JavaScript里，机器读到的是哪一版

不少第三方筛选应用是纯前端实现的：筛选状态存在内存里，标签由脚本生成，URL有时候只跟一个井号片段。这在用户侧看起来没问题，在机器侧问题不小。

Google那份JavaScript SEO基础文档里有两条直接相关的提醒：一是别用井号片段来切换页面内容，要用History API，否则爬虫解析不出这些网址；二是虽然所有返回200的页面都会进渲染队列，服务端渲染或预渲染仍然值得做，因为并不是所有机器人都能跑JavaScript。

后半句在今天分量更重了。抓取你页面的已经不只是搜索引擎爬虫，还有一批取回内容就直接用的模型抓取器，它们对脚本的容忍度普遍更低。

Shopify原生的门店筛选在这一点上做对了：状态走的是正经查询参数，标签由主题模板在服务端渲染出来。用第三方应用替换掉原生筛选之前，这一条值得单独验一遍——把浏览器的JavaScript关掉，刷新一个带筛选参数的页面，看那排标签还在不在。

桌面端这条带该摆在哪儿？三个位置分别要付什么代价？

位置决定用户看不看得见，也决定商品被推走多少，两笔账得一起算。

位置一：商品列表正上方，最常见也最不容易出错

把标签排在列表第一行商品的正上方，是流传最广的做法，理由很朴素：用户的视线从筛选动作结束到落回商品，必然经过这条线。它不需要用户额外去找。

还有一层好处是语义上的：标签和它描述的那批货紧挨着，中间没有别的元素插进来。换成任何一个离得远的位置，用户都得在脑子里多接一根线。

代价也很直白：它会把商品往下推。桌面端一行标签大约三十来个像素，一般不至于把第一排商品挤出首屏；可一旦用户筛得多，标签换到第二行、第三行，推下去的量就开始肉疼了。

所以选这个位置的站，几乎都要配一套溢出策略。这一节最后会讲截断的做法，手机端的溢出更棘手，留到下一节单说。

位置二：筛选侧栏顶部，省地方但离货远了一步

第二种做法是把标签堆在左侧筛选栏的最上方，不占列表区的垂直空间。对商品密度敏感的站，这个方案很有诱惑力：怎么筛都不推商品。

它的问题在于视线路径。用户点完最后一个筛选，注意力会自然往右往下走去看结果，而标签在左上角——那是他刚刚离开的方向。要让用户看见，就得指望他回头，而回头这个动作本身就是我们想省掉的成本。

还有一个更实际的麻烦：侧栏宽度通常只有两百多个像素，一个带筛选类型的标签就能占满一行。八个筛选条件在列表上方可能只占两行，在侧栏里就是八行，把下面所有筛选组都推走了。省下来的垂直空间，在另一个地方还了回去。

我的判断是：这个位置只适合筛选维度少、用户平均只点一两条的站。极简版式那一路的站常这么做，也确实没出什么事，但那是因为它们本来就没几个筛选可点。

位置三：跟着横向筛选工具条走，绑定关系要想清楚

现在越来越多的站不用左侧栏了，改成顶部一条横向的筛选工具条。这种版式下，标签自然而然会落在工具条下沿。

视线路径上这个位置很好，几乎和位置一等价。真正要想清楚的是绑定关系：工具条如果是吸顶的，那条标签带跟不跟着吸顶？

跟着吸顶，好处是用户滚到第五屏还能随时撤销条件，坏处是它会永久占掉一条屏幕高度，手机上尤其明显；不跟着吸顶，好处是不占地方，坏处是用户滚下去之后又回到了什么都看不见的状态，只不过这次连侧栏那份不完美的备份都没有。

我倾向于一个折中：工具条吸顶时不带全部标签，只保留一个显示条件数量并且可点开的入口——注意这跟后面要批评的只显示数量不是一回事，那是页面上唯一的呈现，而这里是滚动到远处之后的压缩态，完整的那排标签在页面顶部一直躺着。

标签排到第二行第三行，是截断还是全展开

桌面端一行大概能横着放下四到八个标签，取决于标签宽度。超过一行怎么办，有三种处理。

第一种是全展开，有几行摆几行。好处是绝对不会有信息看不见，坏处是商品被推走的量不可控——极端情况用户点了十几个条件，商品第一排直接跌出首屏。

第二种是只显示第一行，后面折起来，给一个还有5项之类的展开控件。好处是垂直占用固定，坏处是用户不点开就不知道被折起来的是哪几条，而被折起来的那几条恰恰是他最后点的、也是最记不住的。

第三种是纵向堆叠，每个标签独占一行，最坏情况被直接放大到极致：五个条件就是五行。除非你的筛选维度真的很少，否则不建议。

三种里我推荐第二种，但要加一个补丁：折叠的阈值按行数定，不按数量定。定成显示前五个，标签宽度一变，五个可能是一行也可能是三行；定成显示前两行，无论标签多宽，占用都是确定的。

三个位置的取舍，一张表摆平

这张表是按桌面端来的，手机端另有一套算法，下一节讲。

如果你实在拿不定主意，就选第一种。它不是最巧妙的方案，但它是最难做错的方案，而在一个多数站压根没做这件事的领域里，先把不容易做错的版本上线，比琢磨最优解划算得多。

手机上标签放不下了怎么办？横向滚动和堆叠换行怎么挑？

手机端的溢出不是极端情况而是默认情况，选方案之前先去数一个数字。

手机上的约束，跟桌面完全不是一个量级

先把数摆出来，感受一下差距。一块常见的手机屏，横向能排下的筛选标签是两到三个；而用户在电商站上点几个筛选很正常，四个、五个都不稀奇。也就是说，手机端溢出不是极端情况，是默认情况。

垂直方向更紧张。商品列表上方通常已经排了一串东西：面包屑、H1、有时候还有一段品类文案、排序按钮、筛选按钮。总览带插在这堆东西和第一排商品之间，多一行就是往下推一行。

这里有个技术账要提前记住。这条带如果是页面加载后由脚本补进来的，它就是一次典型的布局偏移。web.dev关于累积布局偏移的那份说明里点名了这类成因：资源异步加载，或者DOM元素被动态插到已有内容前面。它给的合格线是0.1及以下，超过0.25算差。

把标签带做成服务端渲染的一部分，这笔账就完全不存在。这也是我不喜欢纯前端筛选应用的又一个理由——它把一个本该零成本的模块变成了要花预算去优化的东西。

方案一：横向滚动，成败全在截断那一下

第一种做法是把标签排成一条可以左右滑的横条，超出屏幕的部分靠滑动看。它顺着手机用户的天然习惯来，实现也简单。

唯一的风险是：用户得知道右边还有东西。手机上没有滚动条给他提示，全靠视觉线索。

最有效的线索是截断——让最右边那个标签被屏幕边缘切掉一半，露出的那半截本身就是在说这里没完。次一级的线索是把右侧边缘做一层渐隐，暗示内容延续。再次一级是在这条带上方写一行已应用4个筛选之类的文字。

文字这一条我要泼点冷水：用户扫页面时跳过纯文本提示是常态，它适合当补丁，不适合当地基。三种线索叠着用效果最好，成本也不高。

露多少才算露出来了

截断这件事，做与不做是一道题，做到什么程度是另一道题，后面这道更容易翻车。

我见过太多站的截断是这样的：最右边那个标签只露出七八个像素，看起来像边距没对齐，完全不像内容。用户不但不会去滑，还可能觉得这站做得糙。

给一个可执行的口径：最右侧那个被切掉的标签，至少要露出自身宽度的四成到五成。露到这个程度，它是一个词的一半，用户一眼就知道那是个没说完的东西。露不到三成，视觉上就退化成了一条装饰边。

实现上有个小技巧：别指望标签宽度正好落在合适的位置，那是随机的。给这条带的右侧留一个固定的内边距，让内容天然向左偏移一小段，截断位置就可控了。

再加一条：横向滚动的这条带，本身不能吃掉整页的横向滑动手势。有些实现会让用户在商品区往左滑时也触发标签带滚动，这种误触很恼人，而且很难被用户描述清楚，工单里只会写成页面乱动。

方案二：堆叠换行，看得全但推得狠

第二种做法是让标签自动换行，有几行摆几行。它的优点无法反驳：用户不需要任何额外动作就能看见全部条件。

缺点也同样无法回避。手机上一行放两个标签，五个条件就是三行；每行按四十来个像素算，三行就是一百二十多个像素，加上原本就挤的那堆元素，第一排商品很可能直接跌出首屏。

用户此时看到的页面是：满屏都是自己刚才的选择，一件货都没有。这个画面听起来有点滑稽，但它在真实项目里出现的频率比想象中高，我自己就制造过一次，第九节完整交代。

首屏该放什么这件事，在集合页上有个跟首页不同的答案：集合页首屏的唯一职责是让用户看见货。任何挤占它的元素，不管本身多有道理，都要按挤掉多少商品来计价。

折中方案：先堆两行，剩下的折起来

把两种方案的优点各取一半，就是我目前最推荐的做法：手机端显示前两行标签，超出部分折叠，给一个查看全部的入口。

这样做的账是这么算的：绝大多数用户点的条件在四条以内，两行装得下，他们完全感觉不到折叠存在；点了六条八条的重度用户，本来就更愿意跟界面交互，多点一下不构成障碍。把成本转嫁给愿意付的那部分人，而不是平摊给所有人。

折叠时有个细节别忘了：清除全部这个入口必须留在可见的那两行里，不能跟着被折起来。它是用户重来一次的唯一出口，藏起来等于把逃生门锁上。

另外，展开之后别自动收起。用户主动展开说明他在管理这堆条件，页面自作主张收回去只会打断他。

两种方案怎么选：先去数一个数字

选横向滚动还是堆叠换行，不该靠品味，该靠一个数：你的用户在手机上平均同时应用几个筛选条件。

这个数从分析工具里拿并不难，集合页的落地网址里带着筛选参数，数一下参数个数的分布就有了。如果你的筛选走的是查询参数而不是井号片段，这件事更简单。

拿到分布之后的判断很直接：中位数在两条以内，两种方案都行，选实现成本低的；中位数在三到四条，堆两行加折叠最合适；中位数超过五条，说明用户在做精细挑选，横向滚动的滑动成本会开始烦人，还是折叠更稳。

顺带一提，如果你的筛选参数根本没进网址，那这个数你拿不到，同时你还丢掉了用户分享筛选结果、收藏筛选结果、以及从搜索引擎直接落到某个筛选组合的全部可能。这属于另一个层面的问题了，分页与无限滚动那一篇里讲的状态该不该进网址是同一类取舍。

只显示筛选数量的那些站，为什么等于没做总览？

这一节把四种看着像总览、实际不顶用的残次实现逐个拆开。

写成筛选(3)的那些站，到底少给了用户什么

有一类做法看起来已经交代清楚了：筛选按钮上挂个数字，写成筛选(3)，或者在列表上方写一句已应用3个筛选。数字准确，位置也对。

可它少了两样东西，而且是最要紧的两样。

第一样是内容。用户知道有三条，仍然不知道是哪三条。前面讲过，回忆是笔贵账，一个数字提供的线索少到几乎不起作用；他要么去猜，要么打开面板核对，而打开面板正是这个模块要替他省掉的动作。

第二样是撤销入口。数字不能点着删，要撤掉某一条，只能进面板。整条撤销路径原封不动。

所以数字型严格来说不是简化版的总览，它更接近一盏指示灯——指示灯有它的价值，但替代不了仪表盘。

为什么它在横向筛选工具条上尤其致命

数字型实现的危害在不同版式下不一样，这一点很多人没分清。

桌面端如果有常驻的左侧筛选栏，用户至少还有个地方能看勾。这时候数字型不算好，但没到断路的程度。

换成横向筛选工具条就不同了。工具条上的筛选项本身就是折叠的，点开才看得见选项，页面上没有任何一处常驻显示已选内容。这时候只给一个数字，就意味着用户想知道自己选了什么，唯一的办法是把每个筛选组挨个点开看一遍。

手机端同理，而且更糟，因为抽屉一关，什么都没了。

把这条翻译成决策规则：凡是筛选选项默认不可见的版式，总览带就不是加分项，是必需品。横向工具条和手机抽屉都属于这一类。

另一种半吊子：只显示一部分类型的条件

比数字型稍好但同样有害的做法是选择性显示——把颜色、尺码这类显示出来，把价格区间、有货状态、促销标记这些藏起来。

这通常不是设计决定的，是实现偷懒：勾选类好渲染，区间类和布尔类要额外写逻辑，于是先做了容易的那部分。

危害在于它比完全不做更容易骗人。用户看到一条像模像样的总览带，会默认它是完整的，于是把上面列的三条当成自己的全部条件。等他发现列表里没有一件超过两百块的货，才想起自己拖过价格滑块——而那条从头到尾没在页面上出现过。

我在诊断中遇到过一个更绕的版本：有货状态这个筛选被主题默认打开，用户压根没点过，页面也没显示，结果是一个用户从没主动选择过的条件，正在悄悄决定他看到哪些货。这种默认条件更应该显示出来，理由和默认项那件事是一样的：默认值是最强的无形推手，越是用户没意识到的，越要摆到明面上。

标签摆着好看却点不动，这是最阴的一种

第三种残次品是标签渲染齐全、位置也对，就是不能点。

它比前两种更让人恼火，因为它触发了正确预期又不兑现。一个带叉号的小标签长得就是能点掉的样子，用户得试两三次才确信不是自己手指的问题。

这种实现多半出现在两种场合：一是主题模板抄了个静态样式没接逻辑；二是第三方筛选应用和主题各渲染一套，用户看到的是没接上事件的那一套。

验证起来很容易：随便挑一个标签点一下，看网址有没有掉一段参数、列表有没有变多。两件事同时发生才算通过，只变一样都算故障——网址变了列表没变，是缓存问题；列表变了网址没变，是状态没进网址。

最常被漏掉的一类：价格区间这种非勾选条件

把区间类筛选写进总览带，是这堆细节里最容易被跳过的一件，也是我每次审站都会专门看的一件。

价格区间的麻烦在于它不是一个值，是两个：下限和上限。渲染成标签时得决定写成什么样，写成100到200元最清楚，写成100+就有歧义，写成两个独立标签则会让用户以为可以只撤掉一半——事实上多数实现撤掉一半会直接把整个区间清掉。

我的建议：区间类做成一个标签、一次撤掉整个区间，并且把币种写全。跨境站尤其要写币种，用户在多市场之间切来切去，一个光秃秃的100到200会让他停下来想一秒，而这一秒本可以不花。这跟跨境价格展示那套规矩是一脉的：数字周围的那点上下文，成本极低，省掉它却会持续制造小额摩擦。

有货状态、是否促销这类布尔筛选也别漏。它们通常只有一个标签的位置，却往往是砍掉最多商品的那一条。

跨境站的筛选类型该不该写进标签？判据和本土站为什么不一样？

通行规则按品类分档，跨境要按值本身分档，这里给出替换的判据和一张对照表。

先看看通行的那条规则，它在什么前提下成立

标签上到底写红色，还是写颜色：红色，这是已应用筛选总览里争议最多的一处细节。

行业里流传的规则大致是这样：规格密集型的品类要带上筛选类型，因为一个90厘米可能是宽也可能是高；视觉驱动型的品类不必带，因为红色、皮质这种值自己就说得明白。服装站通常不带，五金和家电站通常要带。

这条规则是对的，但它有个默认前提：值的写法本身没有歧义，歧义只来自缺少维度名。在一个单一市场里，这个前提基本成立——美国用户看到8，在服装语境下就是美码8。

跨境把这个前提拆了。

跨境站的前提不成立在哪：同一个值有好几套编码

一双女鞋的同一个尺码，美国写8，英国写6，欧盟写39，日本写25。一件上衣的同一个尺寸，欧洲写38，美国写8，国内写165/88A。数字长得都是数字，含义完全不同，而且几套体系的数值区间还大面积重叠。

于是标签上孤零零一个39，用户第一反应不是这不清楚，而是我筛的到底是哪一个39。他甚至可能确信自己知道，然后错。这比看不懂更糟——看不懂会让他停下来查，自以为看懂了会让他直接下单，然后变成一单尺码退货。

长度和重量同理。36英寸和91厘米是同一个东西，但标签上只写36，德国用户会当成厘米；温度更狠，350在美国用户眼里是华氏，在其他地方是摄氏，两个数字差着一整个数量级的体感，温标换算这件事在厨具和小家电品类上几乎每天都在出问题。

电压、插头制式、认证标记也都是这一类：值本身是一个短字符串，而它属于哪个体系，全靠上下文。

新判据：这个值在目标市场有没有竞争性编码

所以我把判据从品类换成了值本身。问题不是这个站是规格密集型还是视觉驱动型，而是这个筛选值在目标市场是否存在一套或多套竞争性编码。

判定方法很土，一句话就能问出来：把这个值单独抄在一张纸上，拿给目标市场的用户看，他能不能唯一地说出它是什么？说得出，就不用带类型；说不出、或者要反问一句你说的是哪种，就必须带。

按这个判据重排，结论跟品类规则有几处明显不同：服装站原本划进不用带类型那一档，可它的尺码恰恰是竞争性编码最严重的一项；五金站的材质和颜色虽在规格密集型的站上，其实完全不需要类型。

换句话说，类型带不带，是逐个筛选维度决定的，不是整站一刀切。这跟通行规则里那句要么全带要么全不带的建议直接冲突，我理解那句话是为了版式统一，但在跨境语境下，版式统一的代价是把用户推到一个可能选错的位置上，这买卖不划算。

一张判据表，把常见维度分完

表里那句安全与合规风险不是吓唬人。电压和功率这类值一旦被误读，牵扯的就不是体验而是属性数据本身怎么建模的问题了，属性里存的到底是数值还是数值加单位的字符串，会一路影响到标签能不能正确渲染。

带上类型就会变宽，有没有不变宽的带法

带类型的代价是实打实的：颜色：深海蓝比深海蓝宽了三个字，手机上一行本来放两个，现在只能放一个。

有个办法能绕开这笔账：把类型名做成标签内部的浮动小标签，压在值的上方，用更小的字号和更浅的颜色。这样标签的宽度由值决定，类型名不参与撑宽，只吃掉一点高度。一些器材类站点用的就是这种版式，效果相当好。

视觉层级上还要注意一件事：类型名必须比值弱。用户扫这排标签时找的是值，类型名是拿来消除歧义的，不该抢注意力。字号小一档、颜色浅一档、不加粗，这三样一起用就够了。

还有一种更省地方的做法是缩写体系名，比如把美码写成US、欧码写成EU。这个在鞋服上通行度很高，用户认得。但缩写只适合有公认写法的场合，自己造缩写会比不写还糟。

标签上的字，本身也得本地化

最后一层容易被完全忽略：标签文案是要翻译的，而且不能靠机器顺手翻。

Shopify的filter_value对象文档里，对label字段的说明是面向顾客的筛选值标签，举的例子直接就是Red或Rouge——平台在设计这个字段时就假定了它会随市场变化。这是个好信号，说明本地化的位置是留出来的，用不用起来看你。

实际操作里最常见的两类翻车：一是颜色词直译，某些颜色在特定市场有约定俗成的商品叫法，直译过去会变成一个当地人不用的词；二是尺码体系名跟着翻译一起被翻掉了，US被翻成美国，EU被翻成欧盟，读起来像地理课。体系缩写属于不该翻的那一类，跟型号、认证名一个待遇。

还有一个很小但很烦的细节：某些语言里筛选值会带上语法变化，同一个词做定语和做独立标签时形态不同。这类问题在波兰语这类多格变化的语言上尤其明显，标签是独立成分，用原形通常是对的，但值得让当地人扫一眼，成本几乎为零。

筛到零结果的那一刻，这条带就从确认变成了诊断

零结果最考验这个模块，也是它能创造最多价值的场景，顺带还能白捡一份选品数据。

结果被筛成零的那一秒，用户脑子里只有一个问题

用户点到第五个条件，列表突然空了。这一刻他想知道的不是抱歉，也不是要不要看看别的推荐，他只想知道一件事：是哪一条把结果杀没的。

因为答案决定了他的下一个动作。如果是价格上限卡得太紧，他愿意把预算往上抬一点；如果是颜色太挑，他可以换个颜色；如果是尺码没货，那这个站今天确实没他的东西，他走得心服口服。

三种情况对应三种完全不同的结局，而区分它们只需要一样东西：把当前生效的条件摆出来，让他一条一条地摘。

所以这条带在零结果页上的身份变了。在有结果的页面上它是确认，在零结果的页面上它是诊断工具——而且是页面上唯一的诊断工具。

没有找到商品这句话，为什么等于什么都没说

多数主题的零结果状态是一句居中的没有找到符合条件的商品，有的会加一句请调整筛选条件试试。

这句话的问题不在语气，在信息量：它复述了用户已经看见的事实，没提供任何能据以行动的东西。读完之后他能做的动作和读之前一模一样。

更糟的是有些实现会在零结果时把筛选区一起收起来或者置灰，理由大概是没结果了筛选也没意义。这个逻辑正好反了：零结果恰恰是筛选控件最该保持可用的时刻，因为用户此刻唯一的正事就是调整筛选。

我在审站时见过最离谱的一版：零结果页把总览带也一起隐藏了，页面上只剩一行提示和一个返回分类的链接。用户想撤掉某个条件，得先点返回，然后从头筛一遍。这不是引导，这是罚站。

顺便区分一下另一件容易混起来的事：集合本身就没有产品是另一个问题，那属于目录侧的空分类，处理方式是索引层面的取舍。本节说的是集合有货、被筛选筛成了零，页面照样返回200，索引层面通常也不需要做任何事——它纯粹是个体验问题。

这条带在零结果页上该多做哪几件事

常规状态下够用的实现，到零结果页得再加三样。

第一是必须保持完整可见，不折叠、不省略。用户此刻需要看到全部条件，折叠会让被藏起来的那条永远不被怀疑。

第二是每条标签旁边最好带上结果数。Shopify的筛选值对象上有个count字段，返回的正是该值对应的结果数量。把这个数渲染出来之后，用户一眼就能看出哪一条是零、哪一条还剩几十件——凶手自己举了手。

第三是清除全部要显眼。它在有结果的页面上是个次要动作，在零结果页上是主要动作之一，视觉权重应该跟着变。

这三条加起来的效果，是把一个死胡同改造成了一个岔路口。看不见的摩擦那一篇里讲过死胡同页面该怎么变成第二次机会，零结果的筛选页是其中最容易改、也最容易被忽略的一种，因为它在报表里根本不算错误页。

再往前一步：直接告诉用户是哪一条卡住了

如果愿意多写点逻辑，还有个更主动的做法：在零结果页上直接算出哪一条筛选是瓶颈，并且给出撤掉它之后还剩多少件。

实现思路不复杂：拿当前条件集合，逐条剔除后各查一次结果数，找出那个剔掉之后结果数从零跳到最大的条件。然后在页面上写一句撤掉红色这一条，还有24件符合，并把那个标签高亮出来。

成本主要在查询次数上。多数独立站的人均条件数在四条以内，多算四次完全可以承受；实在担心就只在零结果时触发这段逻辑，正常状态下一次都不跑。

这是我见过投入产出比最高的一处小改动之一：改动量是一段几十行的逻辑，收益是把一批本来要离站的用户接了回来。而且它天然自带解释，用户不会觉得自己被推销，他会觉得这个站在帮他。

换个角度：零结果其实是一份免费的选品报告

零结果在体验上是个坏消息，在数据上是个好消息——它是用户主动、具体、免费地告诉你他想要什么而你没有。

把零结果的筛选组合记下来，按出现频次排个序，这份清单的信息密度比大多数问卷都高。它记录的不是用户说他想要什么，是用户在准备掏钱的那一刻实际找了什么。

读这份清单时有个分辨的技巧：把组合拆开看是哪一维度贡献了零。如果零结果集中在某个尺码，那是库存深度问题；集中在某个价格带，那是价格带覆盖问题；集中在某个属性组合，那可能是真正的选品缺口。三种情况的应对完全不同，混在一起看只会得出我们货不够全这种没用的结论。

这份数据也能反哺关键词。用户在筛选里表达的条件组合，跟他在搜索框里会打出的词高度重合，做细分品类洞察时它是个很便宜的补充源，而且是自家站的一手数据，不用等第三方工具更新。

在Shopify集合页上落地，先从认清筛选归谁管开始

平台把数据都备好了，缺的只是显示层那几十行模板，另外两个平台一并说了。

先认清一件事：你店里的筛选到底是谁在管

动手改之前得先弄清楚筛选是从哪来的，不然改半天改的是没在跑的那一套。

Shopify店里的筛选通常有三个来源。一是平台原生的门店筛选，数据来自变体选项、商品标签、价格、库存状态和元字段，由后台的搜索与发现工具配置；二是第三方筛选应用，很多站装了但没意识到自己装了；三是主题自带的老式实现，一些年头长的付费主题会用商品标签硬拼一套筛选。

判断方法很简单：在店里随便筛一下，看网址。出现filter.v.option.或filter.p.tag这类参数，走的是原生；出现应用自己的一套参数名，甚至只有个井号，那是第三方或者老主题。

三者混用很常见。装了应用又没关掉原生筛选，页面上会同时出现两套控件，用户点哪套都对，总览带却只跟其中一套联动。应用栈冲突的排查里，这类重影是最好发现也最容易被放过的一种，因为它不报错。

那两个字段，等于平台已经替你干了一半

用原生筛选的话，模板层拿到的东西比多数人以为的丰富。官方filter对象文档上列着这么几个字段，值得逐个念一遍：

• active_values：当前生效的那些值，直接就是一个数组
• url_to_remove：把这个筛选的参数从当前网址里去掉之后的网址
• label：面向顾客的筛选名，可本地化
• param_name：这个筛选对应的网址参数名
• type：布尔、列表还是价格区间
• operator：多选时是并且还是或者的关系

筛选值一级还有active、count和自己的url_to_remove。

把这份清单和前面提的要求对一遍就会发现，完整、可读、可撤这三条，平台把数据全备好了。遍历所有筛选的active_values，每个值渲染一个标签，链接指向它的url_to_remove，一条合格的总览带就出来了。

这里有个小提醒：价格区间不在active_values里，它走min_value和max_value，得单独判断一次。前面说的最常被漏掉的那一类，多半就漏在这儿。

Dawn主题默认给了什么，还差什么

官方主题在这件事上做得算及格，但离好还有距离，而且不同版本差异不小，别照着别人的截图改。

先自己验一遍再说，验法是三步：桌面端筛两条，看列表上方有没有标签；手机端筛四条，把抽屉关掉，看标签在不在、能不能滑到最后一个；把筛选筛成零结果，看标签还在不在。

常见的三处欠缺是：手机端溢出没做截断提示，用户不知道右边还有；价格区间没渲染成标签；零结果时整块区域被隐藏。三处都在模板层，改动量都不大。

还有一处更隐蔽的：标签的可点区域太小。叉号图标本身可能只有十来个像素，手指点不准。把可点区域扩到整个标签，或者至少给叉号留出足够的触控范围，这是纯CSS的事，收益却立竿见影。

如果店里还在用改得面目全非的老主题，别在旧模板上缝补，新手最常摔的那几跤里就有一条是在自己都读不懂的主题上叠改动。

换第三方筛选应用之前，先验这四件事

第三方应用的筛选能力通常更强，尤其是元字段筛选和多级分组，但它们对页面的接管程度差异极大。装之前验这四条，比装完再后悔便宜。

第一，筛选状态进不进网址。只走内存或者井号片段的，前面讲的那一串代价你都要付。

第二，标签是服务端渲染还是脚本生成。关掉浏览器脚本刷新一次就知道了。

第三，零结果页是它接管还是主题接管。两边各有一套空状态，很容易出现应用的空状态覆盖了主题的，而应用那套压根没有总览带。

第四，多语言市场下标签文案走哪套翻译。有些应用的界面文案跟商品数据走的是两套翻译体系，结果标签上一半是本地语言一半是英文。

WooCommerce和Magento上的对应做法

不是Shopify的站，逻辑一样，位置不同。

WooCommerce这边，筛选多半来自属性筛选小工具或第三方插件。原生小工具的已选状态显示得相当弱，要靠一个单独的已激活筛选小工具补上，而它默认不在模板里，得手动加。WooCommerce那份路线图里讲分类页时提过属性筛选的坑，这一条可以接着往下做。

Magento的分层导航自带一块已应用筛选区，它在这件事上其实是三个平台里做得最早也最完整的，字段能力也强。代价是模板层级深，改起来要动layout XML，而且分层导航本身的治理就够复杂了，改显示层时别顺手动了参数逻辑。

三个平台的共性是：数据层都不缺，缺的都是显示层的那几十行模板。这也是我一直觉得这件事性价比高的原因——它几乎不需要新增任何数据，只是把已有的东西摆出来。

六项要求对上三个平台，一张表收尾

表里那一整行手机端溢出处理三个平台都写着要自己写，不是巧合。这一块所有平台都没管，而它恰恰是移动端体验差距最大的一块。

保哥的失手复盘：这条带做得越完整，手机端加购为什么反而掉了？

一次方案全对、数据全对、结果还是办砸了的改造，以及之后我怎么定指标和排期。

那个厨具站，我把这条带做得又完整又漂亮

去年帮一个出海厨房小家电与烘焙器具站做集合页改造。品类是烤箱手套、硅胶模具、电动打蛋器这一路，主力市场德国和美国，SKU一千出头，筛选维度不少：材质、耐热温度、尺寸、颜色、是否可洗碗机。

改造前那个站属于典型的数字型实现，筛选按钮上挂个括号数字，页面上什么都没有。我把总览带加上了，而且是照着最完整的规格做的：所有条件都渲染，包括价格区间和布尔项；每个标签带筛选类型前缀，写成材质：不锈钢、耐热：230摄氏度这样；手机端堆叠换行，有几行摆几行，保证一条都不藏；最后配了个清除全部。

做完我自己看了很满意。对照前面写的那些要求，这版几乎每一条都满分。

第一个月数据全是好的，我还写进了月报

上线一个月后拉数据：筛选使用率涨了，人均条件数从2.1涨到3.4，零结果页退出率降了将近三成，筛选后的会话时长也变长了。

整体的筛选后加购率是涨的，涨了一点几个百分点。我在月报里写了一句集合页筛选体验改造有效，翻篇了。

现在回头看，那句话不算撒谎，但它是一句被平均数保护起来的话。

第六周开始，运营那边提了一句很随口的话：最近手机端的转化好像有点怪。她说的不是投诉，是那种月度会上顺嘴带过的观察。我当时的反应是先去查了广告投放和落地页速度，两边都没问题。

拆开设备看，那一天才算真正开始

第三天我才想起把筛选后加购率按设备拆开。

数字是这样的：桌面端涨了四个多百分点，移动端跌了两个多百分点。而这个站移动端占七成流量，两边一平均，整体还是正的——那一点几个百分点的好看数字，是桌面端的涨幅垫出来的。

接着去看会话录像，画面挺让我难受。用户在手机上筛完四个条件，屏幕上是：面包屑、标题、排序和筛选两个按钮，三行标签，然后就到底了。一件商品都没有。

用户的动作也很一致：往下滑一屏，看两眼货，再滑回顶部去看那堆标签，再滑下去。来回两三次之后，相当一部分人退出了。

为什么是三行？因为我给每个标签都加了类型前缀。材质：不锈钢这样一个标签，比不锈钢宽了将近一倍，手机上一行本来能放两个，现在只能放一个多一点。人均3.4个条件，加上偶尔的价格区间，稳定就是三行。

根因：一个替用户记账的模块，占的是他看货的地方

把这件事想透之后，我给自己写了一句话：这个模块的价值上限，被它挤掉的商品数量封死了。

它的作用是省掉用户的回忆成本，而回忆成本本来就不高——用户忘了自己选过什么，损失是几秒的迟疑；看不见货，损失是整个页面的存在意义。我用一个大代价，去消除一个小代价。

更让我在意的是我为什么这么久没发现。三个原因叠在一起：一是我按最完整的标准去做，而完整在这里不是免费的；二是桌面端确实变好了，我预览时用的也是桌面；三是我看的是聚合指标，而移动端和桌面端在这个模块上的成本结构根本不是一回事——同样一条标签带，桌面上占屏幕高度的百分之三，手机上占百分之二十。

这跟前面第五节算的那笔首屏账是同一类问题，但角度反过来了：那笔账讲的是首屏本来就该规划好，这次的教训是一个后加上去的、看起来纯属净收益的模块，怎么在没人注意的情况下变成了新的首屏占用者。加东西的时候没人会去重新算首屏预算，因为大家默认加的是好东西。

改了三处，六周后回到基线之上

改法很直接，都在前面几节讲过。

第一，手机端从堆叠换行改成横向滚动加截断，第三个标签切掉一半露出来，右侧配渐隐。一行搞定，省掉两行。

第二，类型前缀改成标签内的浮动小标签，压在值上方，字号小两档、颜色浅一档。宽度回到只由值决定，一行又能放回两个多。

第三，按前面那张判据表逐维度决定要不要带类型：尺寸和耐热温度带，材质和颜色不带。这一改，多数用户的标签里根本没有前缀。

三处改完六周后，移动端筛选后加购率回到改造前基线以上，桌面端的涨幅保住了。整体数字比第一版还好看，但这次我不敢只看整体了。

顺便说一句，这次改动我没做严格的A/B测试，因为流量不够支撑按设备拆分之后还要拆版本，样本量那笔账算下来要等太久。我用的是前后对比加设备拆分，并且明说了同期还上了一批新品，所以恢复的幅度不能全算在这套改动头上。

两个指标必须配着看，单看哪个都会被骗

这次之后我给自己定了两个必须一起看的数。

第一个是筛选使用率：进了集合页的会话里，有多大比例至少用了一次筛选。它衡量的是这套东西有没有被用起来。

第二个是筛选后加购率，且必须按设备拆开。它衡量的是用起来之后有没有带来生意。

为什么要配着看：使用率单独涨，可能是用户在费劲地找东西，不是好事；加购率单独涨，可能只是筛选的人变少了、剩下的都是意图特别强的人。两个一起涨才算真的对了。

还有一个辅助数值得盯：清除全部的点击率。这个数偏高不一定是坏事，它说明用户在积极地重来；但如果它伴随着会话结束率一起高，那就是用户清完就走，问题多半出在筛完根本没什么货上。指标怎么摆才不误导，测试方案那一篇里那套配对看的思路可以直接搬过来。

四周落地路径，以及上线前的十二项自查

如果你现在要动手，我建议这么排。

第一周一行代码都别改：拉三个数——筛选使用率、人均应用条件数的分布、零结果会话占比。第二个数直接决定你选横向滚动还是折叠，没这个数就是拍脑袋。

第二周做最小可用版：所有条件都渲染、写值不写数量、每条可撤销、清除全部。先不管类型前缀，先不管溢出。

第三周做移动端：按第一周那个分布选溢出方案，做截断或者两行折叠，扩大触控区域。

第四周做零结果和本地化：零结果保持完整可见、加结果数、做瓶颈提示；标签文案按市场核一遍，尺码和单位类的按判据表决定带不带类型。

上线前照这十二条过一遍：所有生效条件都在带里；价格区间单独渲染并带币种；布尔项没漏；写的是值不是数量；每条可点撤销；点一下网址掉参数且列表变化；清除全部存在且不被折叠；手机端最后一个标签露出四成以上；标签带是服务端渲染的；零结果时不隐藏；标签文案按市场翻译且体系缩写没被翻掉；触控区域覆盖整个标签。

最后给四个反信号，出现任何一个就该回头看：整体指标涨但按设备拆开有一边在跌；用户在会话录像里反复在顶部和列表之间来回滚；客服工单里开始出现看不出筛了什么、撤不掉之类的措辞；零结果会话占比涨了但零结果页的二次筛选率没跟着涨。

常见问题解答

只有精力做一个，该先做筛选面板还是先做这条总览带

看你现在缺哪个。如果筛选维度本身就不够用，用户想按耐热温度筛却根本没有这个维度，那先补面板，总览带再漂亮也解决不了没得筛的问题。

但如果维度已经够了，只是选完之后页面什么都不说，那总览带的性价比高得多：它不需要新增任何数据，只是把平台已经准备好的字段渲染出来，工作量通常是一两天，而面板改造往往要动商品属性和数据结构。

还有一个判断捷径：你的筛选是不是默认不可见的版式。横向工具条和手机抽屉都属于这一类，这两种版式下没有总览带等于用户全程摸黑，优先级要往上提。

筛选状态进网址，会不会造出一堆没用的页面拖累抓取

会产生大量网址，但这跟总览带是两件事，别混在一起决策。

状态进网址带来的好处是实打实的：用户能分享和收藏筛选结果，回退按钮的行为符合预期，你能从数据里知道用户实际怎么筛，页面也能被服务端渲染出来给机器读。这些好处都不依赖那些网址被不被索引。

网址的治理是另一套活，用规范网址、noindex、robots规则和内链控制来做，站内讲索引膨胀怎么诊断的那篇写得很细。正确的顺序是状态照进网址，然后老老实实做治理，而不是为了省事让状态不进网址——那样省下的抓取预算，代价是把一整套体验和数据能力都砍掉了。

手机上太占地方，能不能做成一个可展开的按钮

不建议做成纯按钮，那等于退回到只显示数量的实现，前面讲的两样缺失原样回来。

可以做的是折中：默认显示一到两行标签，超出部分折叠，给一个查看全部的入口。这样最常见的那批用户根本感觉不到折叠存在，重度用户多点一下也不算负担。

另一个能省地方的办法是砍掉标签里的筛选类型前缀。前缀往往比值本身还长，按维度逐个判断哪些真的需要类型，多数站能把标签宽度砍掉三分之一，一行多放一个。真需要类型的维度，改用压在值上方的小字浮动标签，也不占宽度。

标签上要不要顺带显示每个条件对应的商品数量

常规状态下可有可无，零结果状态下强烈建议加。

常规状态下用户已经看得见列表，数量是冗余信息，加了还让标签变宽。真要加也别加在总览带上，加在筛选面板的选项旁边更合适——那是用户做决定的地方。

零结果就不一样了。这时候用户唯一想知道的是哪一条把结果杀没了，每条标签旁边的数字直接就是答案。Shopify的筛选值对象上有现成的count字段，取出来渲染即可，不用额外查询。

用第三方筛选应用的站，还值得自己动手改吗

先验四件事再决定：状态进不进网址、标签是不是服务端渲染、零结果页归谁接管、多语言下文案走哪套翻译。

四件里前两件不达标，建议换应用或回到平台原生筛选，别在这套实现上继续叠改动。纯前端的筛选实现是个持续付利息的选择，它同时影响体验、布局稳定性和机器可读性，改显示层修不了根子。

如果前两件达标，只是显示细节不好，那多数应用都开放模板或样式的自定义入口，改起来跟改主题差不多。改之前记得对着工具选型的三层框架看一眼，同时装了两套筛选的站比想象中多。

改完之后多久能看到效果，用什么数确认

这类交互改动的反馈很快，一到两周的数据通常就够看趋势，不用等一个月。

看两个数：筛选使用率和按设备拆开的筛选后加购率。务必按设备拆，这条是我用一次翻车换来的——整体涨、移动端跌的情况完全可能发生，而且移动端往往是流量大头，被平均掉之后你在报表上什么都看不出来。

另外配一个定性观察：随机看十段筛选后的会话录像。如果用户在页面顶部和商品列表之间来回滚动，说明标签带占的地方太多；如果用户筛完之后直接往下滑再没回来过，说明这条带没被注意到，可能是位置或者对比度的问题。数据告诉你有没有事，录像告诉你是哪件事。

权威参考资料