搜索日志分析实战：Query 分类与搜索满意度指标设计
一、搜索日志：数据金矿怎么挖
每个有搜索功能的产品，后台都沉淀着海量的搜索日志。用户每天在搜索框里敲下的每一个词，本质上都是一条用户意图的显式表达——他想要什么，他觉得这个产品能提供什么，甚至他对产品的期望是什么。
搜索日志分析的价值点至少有三个：
- 发现需求缺口：搜了但没有结果的词，就是产品该补的内容
- 优化排序策略：哪个结果被高频点击，哪个被快速跳过，直接影响排序调权
- 衡量产品质量：搜索满意度本身就是产品体验的核心指标
为什么搜索日志是"用户意图的显式表达"而数据分析里大部分数据不是？用户浏览商品、点击推荐、下单支付——这些行为数据都是"隐含意图"（implicit signal），你需要推断。但搜索日志不同：用户在搜索框里敲下的每一个字都是他主动告诉你的——"我想要这个"。一个搜索"无线降噪耳机 500以下"的用户，比一个浏览了10个耳机商品页的用户更准确地表达了他的需求。搜索日志的价值门槛不在技术，而在于"你把它当运维日志扔那了，还是当成需求池来分析了"。一个零结果词不是一句"搜索又掉了"的维保事项，而是一个"有明确用户需求但我们没满足"的产品线索。
本文整理了我做搜索日志分析的一套完整方法论，从 Query 分类到满意度指标设计，再到工程落地的细节。
搜索日志分析全景流程：
二、Query 清洗与意图分类
2.1 清洗流程
真实世界的搜索日志有多脏？各种特殊字符、拼音打错、emoji、火星文，甚至用户直接粘贴一篇文章到搜索框里。清洗是第一步：
import re import pandas as pd from collections import Counter def clean_search_query(query): """清洗搜索查询词，去除噪音字符和统一格式 参数: query: 原始查询字符串 返回: 清洗后的字符串 """ if not query or not isinstance(query, str): return '' # Step 1: 去除头尾空白 query = query.strip() # Step 2: 截断过长的查询（可能是误操作或粘贴内容） if len(query) > 100: query = query[:100] # Step 3: 去除 URL、邮箱等非查询内容 query = re.sub(r'https?://\S+', '', query) # 移除 URL query = re.sub(r'\S+@\S+', '', query) # 移除邮箱地址 # Step 4: 统一空白字符 query = re.sub(r'\s+', ' ', query) # Step 5: 去除纯特殊字符查询 if re.match(r'^[^\w\u4e00-\u9fff]+$', query): return '' # Step 6: 去除首尾的非中英文标点 query = query.strip('，。！？、；：""''（）…—·～,.!?;:\'"()[]{}') return query.strip() def batch_query_analysis(df, query_column='search_query'): """批量分析搜索日志，统计基础指标 参数: df: 包含搜索日志的 DataFrame query_column: 查询词所在列名 返回: 分析结果字典和清洗后的 DataFrame """ # 清洗所有查询词 df['cleaned_query'] = df[query_column].apply(clean_search_query) # 标记无效查询 df['is_invalid'] = df['cleaned_query'] == '' invalid_rate = df['is_invalid'].mean() # 统计查询长度分布 df['query_length'] = df['cleaned_query'].str.len() # Top 20 高频查询 top_queries = df[~df['is_invalid']]['cleaned_query'].value_counts().head(20) summary = { 'total_searches': len(df), 'invalid_searches': df['is_invalid'].sum(), 'invalid_rate': round(invalid_rate * 100, 2), 'avg_query_length': round(df['query_length'].mean(), 1), 'unique_queries': df['cleaned_query'].nunique(), 'top_queries': top_queries.to_dict() } print(f"总搜索次数: {summary['total_searches']:,}") print(f"有效搜索: {summary['total_searches'] - summary['invalid_searches']:,}") print(f"无效率: {summary['invalid_rate']}%") print(f"平均查询长度: {summary['avg_query_length']} 字符") return summary, df2.2 Query 意图分类
分类是 Query 分析的核心。我们定义了几种主要的搜索意图：
| 类别 | 示例 | 特征 |
|---|---|---|
| 精确搜索 | "iPhone 15 Pro Max 256G" | 包含品牌、型号等精确词 |
| 模糊搜索 | "好用的蓝牙耳机" | 包含"推荐""好用""便宜"等修饰词 |
| 功能搜索 | "怎么退货""修改密码" | 以疑问词或动词开头 |
| 导航搜索 | "我的订单""设置" | 指向特定页面 |
| 零结果搜索 | 搜了但没有任何结果返回 | 需求缺口信号 |
import jieba def classify_query_intent(query): """基于规则 + 关键词的搜索意图分类 参数: query: 清洗后的查询词 返回: 意图分类标签 """ # 导航类搜索：指向产品功能的短词 nav_keywords = ['我的订单', '购物车', '设置', '个人中心', '收藏', '优惠券', '收货地址', '余额', '会员'] if query in nav_keywords or query.replace('我', '') in nav_keywords: return '导航搜索' # 功能类搜索：以疑问词或动词开头 question_patterns = ['怎么', '如何', '为什么', '什么是', '怎样', '哪里', '为什么', '怎么办'] if any(query.startswith(p) for p in question_patterns): return '功能搜索' # 精确搜索：包含明显品牌/型号/规格词的较长查询 # （实际项目中这里会接入一个品牌/类目词库做匹配） if len(query) > 6 and (any(kw in query for kw in ['版', '型', '款', '代', '色', 'G', 'GB'])): return '精确搜索' # 模糊搜索：包含推荐/评价类修饰词 fuzzy_keywords = ['推荐', '好用', '好用的', '性价比', '便宜', '热卖', '排行', '必买', '值得', '哪个'] if any(kw in query for kw in fuzzy_keywords): return '模糊搜索' # 默认归入模糊搜索 return '模糊搜索' # 批量分类 # df['intent_type'] = df['cleaned_query'].apply(classify_query_intent) # intent_distribution = df['intent_type'].value_counts() # print(intent_distribution)三、搜索满意度指标设计
3.1 满意度从哪来
搜索满意度不是单一指标，而是多信号融合的结果：
搜索满意度 = f(点击行为, 停留时长, 转化行为, 回搜行为, 零结果)每个信号都有不同的权重和解读：
| 信号 | 积极信号 | 消极信号 | 权重 |
|---|---|---|---|
| 首条点击率 | 点了第一个结果 | 跳过前三都不点 | 30% |
| 搜索后停留时长 | 在结果页停留 > 30s | 秒关结果页 | 20% |
| 搜索转化率 | 加购/下单/收藏 | 搜索后无任何操作 | 25% |
| 回搜率 | 一次搜索就满足 | 5分钟内重新搜索 | 15% |
| 零结果率 | 有结果返回 | 搜索无结果 | -10% (罚分) |
3.2 SQL 实现满意度计算
-- 搜索满意度综合评分计算 -- 每行为一次搜索会话，输出 0-100 分的满意度评分 WITH search_session AS ( SELECT s.user_id, s.session_id, s.search_query, s.search_time, -- 点击第一个搜索结果判定 MAX(CASE WHEN c.result_rank = 1 THEN 1 ELSE 0 END) AS clicked_top1, -- 是否有任何点击 MAX(CASE WHEN c.click_id IS NOT NULL THEN 1 ELSE 0 END) AS has_click, -- 搜索后页面停留时间（秒） COALESCE(MAX(c.stay_duration), 0) AS max_stay_seconds, -- 是否在搜索结果页后有转化行为 MAX(CASE WHEN o.order_id IS NOT NULL THEN 1 ELSE 0 END) AS has_conversion, -- 是否5分钟内有回搜 CASE WHEN COUNT(DISTINCT s2.session_id) > 1 THEN 1 ELSE 0 END AS has_research, -- 是否有搜索结果 MAX(CASE WHEN s.result_count = 0 THEN 0 ELSE 1 END) AS has_result FROM search_log s LEFT JOIN search_click_log c ON s.session_id = c.session_id AND c.click_time BETWEEN s.search_time AND DATE_ADD(s.search_time, INTERVAL 5 MINUTE) LEFT JOIN order_log o ON s.user_id = o.user_id AND o.create_time BETWEEN s.search_time AND DATE_ADD(s.search_time, INTERVAL 30 MINUTE) -- 检测回搜：同一个用户5分钟内的搜索次数 LEFT JOIN search_log s2 ON s.user_id = s2.user_id AND s2.search_time BETWEEN s.search_time AND DATE_ADD(s.search_time, INTERVAL 5 MINUTE) AND s2.session_id != s.session_id GROUP BY s.user_id, s.session_id, s.search_query, s.search_time ) SELECT session_id, search_query, -- 综合满意度评分（0-100分） ROUND( -- Top1 点击：30分（点中了就满分） clicked_top1 * 30 -- 停留时长：20分（按比例给分，60秒满分） + LEAST(max_stay_seconds / 60.0, 1.0) * 20 -- 转化：25分（有转化就给满分） + has_conversion * 25 -- 无回搜：15分（一次满足给满分，回搜不给分） + (1 - has_research) * 15 -- 零结果罚分：有结果得10分，无结果扣10分 + CASE WHEN has_result = 1 THEN 10 ELSE -10 END , 2) AS satisfaction_score, -- 满意度等级 CASE WHEN ROUND( clicked_top1 * 30 + LEAST(max_stay_seconds / 60.0, 1.0) * 20 + has_conversion * 25 + (1 - has_research) * 15 + CASE WHEN has_result = 1 THEN 10 ELSE -10 END , 2) >= 80 THEN '满意' WHEN ROUND( clicked_top1 * 30 + LEAST(max_stay_seconds / 60.0, 1.0) * 20 + has_conversion * 25 + (1 - has_research) * 15 + CASE WHEN has_result = 1 THEN 10 ELSE -10 END , 2) >= 50 THEN '一般' ELSE '不满意' END AS satisfaction_level FROM search_session;四、从分析到行动
分析结果的落地要做到"可执行"：零结果的词按搜索量排序给出内容补全计划，低点击率的词给出排序策略调整建议，回搜率高的词做相关推荐优化。
为什么搜索满意度用"多信号融合"而不是单一指标？如果你只用"首条点击率"衡量满意度，当搜索算法把热门但不相关的商品排到第一位时，点击率反而会上升——因为用户看到第一个结果点进去才发现不相关。如果你只用"转化率"，那就漏掉了大量"搜到了想要的、确认了信息、但没下单"的满意用户（比如搜索"退货政策"成功找到退换货页面的用户，他们不会下单但非常满意）。多信号融合的核心理念是：一个信号可能被误导，五个信号同时被误导的概率极低。回搜率是一个特别重要的负向信号——用户在 5 分钟内换了词重新搜索，几乎等于在说"刚才那次搜索我没找到想要的"。
五、总结
🚨 踩坑提醒
查询词截断 100 字符可能丢失长尾需求：
query[:100]的截断假设是"超过 100 个字符就是粘贴内容"，但电商场景下存在商品全名搜索（比如"索尼 WH-1000XM5 无线降噪耳机 头戴式 蓝牙 高解析度音频 2024 旗舰款 银色"），长度可能 40-80 个字符但不违规。截断应该用正则检测"是否包含 URL"和"是否包含句子结构（多空格+多标点）"，而不是一刀切的长度阈值。满意度评分权重有主观性，上线前要做权重稳定性分析：你设了"首条点击 30% + 停留时长 20% + 转化 25% + 回搜 15% + 零结果 10%"，但如果"转化"的信号在 90% 的搜索 session 里都是 0（用户搜了产品信息但不一定会下单），这个 25% 的权重就相当于白设了——评分主要由其他 4 个信号撑起。建议用真实数据跑一遍各信号的覆盖率和方差，然后根据实际贡献度调整权重分配。
回搜率检测的 5 分钟窗口在不同产品上需要不同设置：电商产品用户 5 分钟窗口合理（比价行为），但内容型产品（新闻/视频搜索）用户可能在 30 秒内连搜 3 次不同关键词——这不是"不满意"，而是在探索不同的资讯主题。建议先统计用户连续搜索的时间间隔分布（P50/P75/P90），基于 P75 来设置回搜窗口。
搜索日志分析是一个典型的"数据驱动产品优化"场景：
- Query 清洗是地基，各种异常 case 要多积累，正则表达式要反复打磨
- 意图分类决定分析深度，规则 + 词库的方式在中小规模场景中足够好用
- 满意度是综合指标，不要只看点击率，多信号融合才接近真实用户体验
- 分析结果 = 可执行的行动项，零结果词按搜索量排序 → 内容补全计划，这个闭环一定要走通
- 搜索日志是产品的"需求探测器"，每一个零结果词都在告诉你：用户想要这个，你快补上！
你们的搜索功能有做日志分析吗？零结果率大概在多少？评论区交流一下~
