n8n模板：从竞品应用评论里挖出功能缺口

原文要点

原模板由Daniel Shashko发布在n8n模板库（免费）。流程每周一早晨（或手动）运行：从Settings读取竞品Google Play与App Store链接、你已发布的功能清单、抓取与报告上限；经Bright Data对两个商店分别触发评论数据集抓取并轮询至快照就绪（有最大轮询上限）；下载后统一两个商店的字段格式，按可配置天数窗口裁剪评论并限制每个应用的评论条数；扫描含「想要某功能」语气的句子，拼成编号诉求清单，交OpenAI把每条诉求命名成短功能名，再与你的功能清单比对，分类为路线图缺口（roadmap gap）或定位问题（positioning issue）；每条引文追加一行到Google Sheets，把缺口记分卡或「无诉求」消息发到Slack，失败时把错误发到专门告警频道。

这次做成什么

做一条每周自动挖竞品应用评论中功能诉求的流水线：输出「用户想要但我们没有」的缺口清单和「用户想要但我们已有」的定位问题清单。练习方案：先用1个竞品、50条评论上限、14天窗口手动跑通，再开周一定时。

准备什么

• n8n实例（云版或自托管均可）
• Bright Data API token及Google Play、App Store评论数据集权限
• OpenAI API key（Chat模型，用于命名功能）
• Google Sheets OAuth凭据及一张已建好的目标电子表格
• Slack凭据、一个记分卡频道和一个告警频道

具体怎么做

1. 配凭据

   新建HTTP Header Auth凭据：名称Authorization，值填Bearer加Bright Data token；再配OpenAI、Google Sheets OAuth、Slack三类凭据，并在Slack建好记分卡频道和告警频道。

2. 在Settings填竞品与功能清单

   粘贴竞品的Google Play应用页URL和App Store应用页URL；把你已上线的功能写成短名列表（每项一句话）；设置reviews per app（练习用50）、days back（练习用14）、max asks和max polls上限。

3. 手动运行并核对中间结果

   手动触发后检查：Bright Data两侧快照都轮询到ready；字段归一化后每条评论有统一的作者、评分、日期、正文；日期窗口裁剪后条数不超过每应用上限；诉求扫描输出的编号清单只含「想要/希望有」语气的句子。

4. 核对产出并开定时

   确认Sheets每条引文一行、Slack收到缺口与已覆盖诉求的记分卡；把竞品换成无评论的测试链接跑一次验证「无诉求」消息分支；确认无误后启用每周一早晨的定时触发。

可直接复制的材料

你是产品分析师。下面是从竞品应用评论中抽出的用户诉求，已编号。请完成两步：
第一步：给每条诉求起一个不超过8个字的中文短功能名。
第二步：把每个功能名与「我们已上线的功能清单」逐一比对，若语义上已被覆盖则标为「定位问题」，否则标为「路线缺口」。
只输出JSON数组，每项含id、feature_name、classification（取值为路线缺口或定位问题）、reason（不超过30字）。
我们已上线的功能清单：深色模式、离线缓存、导出PDF、团队协作空间
用户诉求：
1. wish there was a way to use this without internet on flights
2. please add a dark theme, my eyes hurt at night
3. would love to sync my data to my smartwatch

{
  "google_play_urls": ["https://play.google.com/store/apps/details?id=com.example.rival"],
  "app_store_urls": [],
  "shipped_features": ["深色模式", "离线缓存", "导出PDF", "团队协作空间"],
  "reviews_per_app": 50,
  "days_back": 14,
  "max_asks": 20,
  "max_polls": 30,
  "scorecard_channel": "#product-insights",
  "alerts_channel": "#alerts"
}

[
  {"store":"google_play","author":"u_8812","rating":4,"date":"2026-09-08","text":"Great app but wish there was a way to use this without internet on flights."},
  {"store":"google_play","author":"u_2033","rating":3,"date":"2026-09-09","text":"please add a dark theme, my eyes hurt at night"},
  {"store":"google_play","author":"u_5540","rating":5,"date":"2026-09-10","text":"Best tracker I have used, no complaints at all."}
]

输入与输出示例

本站虚构演示，输入的清单与输出分类一一对应，非原作者运行结果，未实际调用模型。

输入

用上述合成评论与功能清单（深色模式、离线缓存、导出PDF、团队协作空间），days_back=14，reviews_per_app=50。

对应输出

诉求清单含2条（第3条被过滤）。OpenAI输出示意：[{"id":1,"feature_name":"离线使用","classification":"定位问题","reason":"已上线离线缓存，属宣传不足"},{"id":2,"feature_name":"深色主题","classification":"定位问题","reason":"深色模式已覆盖该诉求"}]。Sheets追加2行引文；Slack记分卡：路线缺口0个，定位问题2个（离线使用、深色主题），提示加强功能宣传而非排期开发。

做完检查这些

• 两个商店的评论在归一化后字段结构一致，Sheets行不会因商店不同而缺列
• 超出days_back窗口的旧评论和超出reviews_per_app上限的评论不进入后续处理
• OpenAI输出是合法JSON数组，每条都有feature_name和classification两个字段
• 功能清单中已有的诉求被分类为定位问题，清单没有的分类为路线缺口，不出现第三种取值

容易卡住的地方

• Bright Data对两个商店是不同的数据集，字段名不同，归一化节点漏掉一侧会导致该侧评论静默丢失
• 轮询次数到max_polls上限会放弃该快照，网络慢时需调大上限而不是让流程报错
• 诉求扫描靠措辞匹配，反讽或纯抱怨的句子可能混入，需人工抽查OpenAI的命名质量
• OpenAI输出若不强制JSON格式，后续比对节点可能解析失败，提示词中必须写明只输出JSON
• 竞品链接必须是应用详情页URL而非商店首页，否则数据集抓取会返回空结果