简介这份PDF文档面向初次接触竞品分析的产品新人、市场调研人员与运营从业者系统拆解了制作一份完整竞品分析报告的六个关键步骤帮助读者摆脱直接对比竞品的常见误区建立从行业认知到结论输出的完整方法论。内容依次覆盖了解行业信息、明确分析目标、寻找划分挑选竞品、分析竞品、对比竞品以及输出结论其中对产业链梳理、目标类型区分、垂直与间接及翘楚竞品的划分、二八原则挑选竞品等知识点均有展开说明并补充了产品不同生命周期阶段竞品分析侧重点的差异。资源包内为1个PDF文件约6.7MB便于在电脑或移动端随时查阅与标注。目前已有189人学习适合作为市场调研与产品文档写作的入门参考也可用于团队内部培训时对照梳理分析框架。1. 竞品分析六步拆解从「抄作业」到「建坐标系」的落地路径很多人做竞品分析第一反应是打开对手官网把功能列表截图然后拼成一份 PPT。这种「抄作业」式的做法交差可以但没法指导决策。真正能用的竞品分析核心不是罗列对手有什么而是回答「我该做什么、不做什么、按什么顺序做」。这份六步拆解就是把这套判断过程拆成可复现的步骤从锁定竞品范围到采集公开数据再到功能矩阵、定价策略、用户反馈、技术实现最后落到自己的行动清单。它适合产品经理、技术负责人、独立开发者尤其是资源有限、经不起试错的小团队。下面按我实际做过的流程一步步拆开讲。2. 第一步锁定竞品范围别把「友商」当「竞品」2.1 直接竞品、间接竞品、潜在竞品的筛选标准很多人一上来就把行业里所有叫得上名字的产品都列进去结果分析到一半发现有些产品跟自己的目标用户根本不重叠。我一般用三个筛子第一目标用户是否重合第二解决的核心问题是否相同第三用户是否会在同一个决策场景里比较你们。三个都满足是直接竞品满足前两个但使用场景不同是间接竞品只满足第一个但技术路线可能颠覆现有方案的是潜在竞品。筛选时给每个候选产品打标签用表格管理最清楚产品名称目标用户重合度核心问题相同同场景比较竞品类型A高是是直接竞品B高是否间接竞品C中否否潜在竞品这张表不用给别人看但自己必须填一遍。填完你会发现真正需要花精力深挖的直接竞品通常不超过 3 个。2.2 用「用户决策路径」反推竞品清单如果拿不准用户到底会拿谁跟你比就去翻用户社区、问答平台、行业论坛里「求推荐」「有没有类似」的帖子。把用户提到的替代方案全部记下来按出现频次排序。频次最高的前五个就是用户心智里的真实竞品。这一步不需要任何工具手动翻两三百条帖子规律自然浮现。我做过一次发现用户拿来对比的竟是一个我完全没关注的开源方案后来证明那个方案确实在抢我们的早期用户。提示竞品清单不是一次性的每季度按用户决策路径重新跑一遍尤其是当你的产品定位发生调整时。3. 第二步公开数据采集把「感觉」变成「字段」3.1 功能信息的结构化采集模板竞品分析最怕的是「我觉得它有这个功能」而不是「它在哪个版本、哪个入口、以什么形式提供了这个功能」。我一般建一张功能采集表字段包括功能名称、所属模块、入口路径、操作步骤、输出结果、限制条件、首次出现版本。前六个字段靠实际使用截图记录最后一个字段靠版本更新日志或应用商店历史版本比对。采集时用固定格式记录方便后续对比功能名称批量导出 所属模块数据管理 入口路径首页 → 项目列表 → 更多操作 → 导出 操作步骤勾选多条记录 → 点击导出 → 选择格式 → 确认 输出结果生成一个压缩包内含 CSV 文件 限制条件单次最多 100 条免费版不可用 首次出现版本v2.3.0从更新日志推断这套字段看起来笨但到了第三步做矩阵对比时你会感谢自己当初没偷懒。3.2 定价与商业化信息的抓取方法定价页面的信息往往比功能页更隐蔽。除了官网定价表还要看免费版的功能边界、付费版的计费单位按人、按量、按项目、是否有隐藏的用量限制、企业版是否必须联系销售。我一般会注册一个免费账号把能点的按钮都点一遍记录哪些操作会触发付费提示。同时用浏览器的开发者工具看定价页的接口返回有时能看到不同套餐的完整参数。# 用 curl 抓取定价页接口观察返回的套餐结构 curl -s https://example.com/api/pricing | python -m json.tool这段命令只是把接口返回格式化方便阅读。参数说明-s静默模式不输出进度python -m json.tool做 JSON 美化。如果接口需要鉴权就在请求头里带上登录后的 token。注意只抓取公开可访问的接口不要尝试绕过权限。3.3 用户反馈的批量获取与清洗用户反馈是最容易被忽略的数据源。应用商店评论、社区帖子、社交平台讨论都是公开的。我一般用关键词搜索加时间范围过滤把最近半年的反馈导出成文本然后按「功能缺失」「性能问题」「价格抱怨」「迁移意愿」四类打标。不需要复杂的 NLP手动读两百条分类统计就够了。import re # 简单清洗去掉表情、链接、多余空白 def clean_text(text): text re.sub(rhttp\S, , text) # 去链接 text re.sub(r[^\w\s\u4e00-\u9fff.,!?], , text) # 保留中英文和基本标点 text re.sub(r\s, , text).strip() return text raw 这个功能太慢了 http://t.cn/xxx 希望能改进 print(clean_text(raw)) # 输出这个功能太慢了 希望能改进逻辑说明先去掉 URL再过滤掉非文字字符最后压缩空白。参数\u4e00-\u9fff是中文字符范围确保中文不被误删。清洗后的文本按类别归档统计每类出现的频次就能看出竞品最被诟病的点在哪里。4. 第三步功能矩阵与定价对比找到「人无我有」的缝隙4.1 功能矩阵的维度设计与打分规则功能矩阵不是把功能列表并排贴而是按用户任务链拆维度。比如一个项目管理工具维度可以拆成任务创建、任务分配、进度跟踪、文件协作、报表导出、权限管理。每个维度下再列具体功能点。打分用 0/1/2 三档0 表示没有1 表示有但难用2 表示有且好用。打分必须附证据比如截图或操作记录否则就是主观臆断。维度竞品A竞品B自家产品任务创建212任务分配120进度跟踪221文件协作012报表导出101权限管理220这张表一出来自家产品的短板和机会点一目了然。任务分配和权限管理是明显缺口文件协作是优势项。4.2 定价策略的拆解按人、按量、按功能定价对比不能只看数字要看计费逻辑。按人计费适合团队协作型产品按量计费适合 API 或资源消耗型产品按功能计费适合模块化产品。把竞品的计费单位、免费额度、超额单价、企业版门槛列成表再结合自己的成本结构就能判断哪种模式更适合自己的用户群。我一般会算一个「典型用户月成本」假设一个 10 人团队每月使用 1000 次核心操作分别代入竞品和自家产品的计费公式看谁更贵。这个数字比定价页上的标价更有说服力。注意定价对比要区分「标价」和「实际成交价」。企业版往往有折扣可以通过销售询价或公开的采购公告推断折扣区间。4.3 用「功能-价格」四象限定位机会点把功能完整度和价格高低画成四象限高功能低价格是「性价比区」高功能高价格是「专业区」低功能低价格是「入门区」低功能高价格是「危险区」。自家产品落在哪个象限竞品落在哪个象限一目了然。如果自家产品在「危险区」要么补功能要么降价要么换目标用户。如果发现某个象限空着那就是机会点。5. 第四步用户反馈与技术实现挖出「为什么」和「能不能抄」5.1 从差评里提取「未满足需求」的编码方法差评是金矿但需要编码。我一般把差评按「期望-现实」的差距来分类期望有但现实没有功能缺失、期望好用但现实难用体验问题、期望便宜但现实贵价格敏感、期望稳定但现实崩溃可靠性问题。每类下面再记具体场景。编码完成后统计每类出现的频次和情感强度就能排出优先级。# 简单的关键词匹配分类 categories { 功能缺失: [没有, 缺少, 希望增加, 什么时候支持], 体验问题: [难用, 卡顿, 慢, 复杂, 找不到], 价格敏感: [太贵, 收费, 免费, 性价比], 可靠性: [崩溃, 闪退, 丢失, 报错] } def classify(text): for cat, keywords in categories.items(): if any(kw in text for kw in keywords): return cat return 其他 reviews [这个功能太慢了, 希望能增加导出, 太贵了, 经常崩溃] for r in reviews: print(r, -, classify(r))逻辑说明用关键词匹配做粗分类适合快速处理几百条反馈。参数categories里的关键词需要根据实际语料调整不要直接照搬。分类结果人工复核一遍避免误判。5.2 技术实现的反推从公开信息看架构与依赖技术实现的反推不是去逆向工程而是从公开信息推断。比如官网的招聘信息会透露技术栈开发者文档会暴露 API 设计风格状态页面会显示基础设施提供商开源仓库会展示依赖库。把这些信息拼起来就能大致判断竞品的技术路线和迭代速度。我一般会看三个地方第一招聘岗位的技能要求第二开发者文档的 API 版本和更新频率第三如果竞品有开源组件看它的提交记录和 issue 处理速度。这些信息足够判断对方的技术债和迭代节奏。5.3 判断「能不能抄」的三个边界不是所有功能都值得跟进。我一般用三个边界来筛第一技术边界——我们有没有能力在合理时间内做出来第二成本边界——做出来之后的维护成本是否可接受第三战略边界——这个功能是否符合我们的长期定位。三个边界都通过才进入排期。任何一个不通过就记录在案但不行动。提示抄功能容易抄体验难。如果竞品的优势来自长期积累的数据或网络效应单纯抄功能没有意义。6. 第五步避坑与排查六步拆解里最容易翻车的五个地方6.1 竞品选错把行业龙头当直接竞品现象花了两周分析行业龙头结论是「它功能太全了我们做不了」。原因龙头产品的目标用户和你的早期用户根本不重合它的功能是为大客户定制的。解决回到用户决策路径找那些和你抢同一批早期用户的产品哪怕它规模小、界面丑。6.2 数据过期用两年前的截图做对比现象功能矩阵里竞品缺一个功能但实际上对方半年前就上线了。原因采集时用了旧版本文档或缓存页面。解决所有功能信息必须标注采集日期和版本号超过三个月的重新验证。定价信息超过一个月的重新抓取。6.3 打分主观没有证据的「我觉得」现象功能矩阵里自家产品全是 2 分竞品全是 1 分。原因打分没有附证据凭印象填。解决每个打分必须附截图或操作记录没有证据的留空不参与对比。打分人至少两人分歧超过一档的重新验证。6.4 只分析不行动报告写完就归档现象六步走完PPT 很漂亮但没人知道接下来做什么。原因缺少行动清单和优先级排序。解决最后一步必须输出「做什么、不做什么、什么时候做」的清单每条行动对应一个负责人和时间节点。6.5 忽略间接竞品被跨界玩家掀桌子现象盯着直接竞品打结果被一个完全不同的方案抢了用户。原因间接竞品和潜在竞品没有纳入监控。解决每季度扫一遍用户社区里提到的替代方案哪怕它现在看起来很粗糙。7. 第六步输出行动清单把分析变成排期7.1 行动清单的字段与优先级规则行动清单不是待办列表而是带优先级的决策记录。每条行动包含行动描述、依据来自哪一步的分析、预期收益、成本估算、优先级、负责人、截止日期。优先级用「高/中/低」三档规则是高优先级 用户反馈频次高 技术可行 成本可控中优先级 满足其中两项低优先级 只满足一项。行动依据预期收益成本优先级补任务分配功能功能矩阵缺口减少用户流失中高调整定价页定价对比提升转化率低高优化导出速度差评编码提升满意度中中调研潜在竞品间接竞品监控提前预警低低7.2 用「假设-验证」的方式跟踪行动效果行动清单执行后不能只看「做完了没有」要看「假设是否成立」。比如「补任务分配功能」的假设是「减少用户流失」那就跟踪功能上线后三个月的流失率变化。如果流失率没降说明假设错了要么功能没做到位要么流失原因不是这个。把每次验证结果记录下来下一轮竞品分析时就有了更准的起点。7.3 把六步拆解变成季度循环竞品分析不是一次性项目而是季度循环。每季度跑一遍六步重点更新变化的部分竞品清单有没有新增、功能矩阵有没有变动、定价有没有调整、用户反馈有没有新趋势。跑完一轮行动清单更新一次排期调整一次。坚持四个季度你会发现自己对市场的判断比对手快半步。我自己的习惯是每季度第一周做数据采集第二周做矩阵和定价对比第三周做用户反馈和技术反推第四周输出行动清单并排期。这个节奏不重但能保证信息不过期。希望帮到你。本文还有配套的精品资源点击获取