竞品定价变动平均延迟发现14天，等你知道对手降价，客户已经跑光了。一位SaaS产品经理告诉我，他们曾连续3个月没注意到主要对手推出免费 tier，结果Q2流失率飙到12%。
手动刷竞品网站是21世纪最隐蔽的工时黑洞。我见过最夸张的团队：4个人轮班盯5个对手的定价页，Excel 表格版本多到分不清哪个是最新。
今天这套方案用 Python + SQLite 搭一套自动化情报系统，核心代码不到200行。不是让你变成爬虫工程师，是让定价、市场、销售各自拿到实时仪表盘。
01 | 架构：把"偷看对手"变成流水线
系统分三层：数据采集层负责爬取，存储层用 SQLite 做时间序列，应用层输出变更提醒。整个设计像便利店补货系统——货架空了自动下单，不需要店长每天清点。
核心类 CompetitiveIntel 初始化时干三件事：建数据库连接、配置请求会话、初始化三张表。请求头里塞个常见 User-Agent，绕过基础反爬。
数据库设计直接对应业务问题。competitors 表存对手档案，intel 表存通用情报（招聘、博客、新闻），pricing 表专门追踪定价。每张表都带时间戳，天然支持历史对比。
有个细节：intel 表用了 UNIQUE(competitor_id, content_hash) 约束。内容哈希去重，同一篇博客更新不会重复入库，但改版了能抓到。
02 | 定价监控：从"肉眼识别"到结构化数据
定价页是最难爬的——用 React/Vue 渲染的价格，直接 requests 抓回来是空壳。方案做了两手准备：默认直接请求，配置了 ScraperAPI 密钥就走代理渲染。
_fetch 方法的逻辑很简单：有 API 密钥就加 render=true 参数，让第三方服务执行 JavaScript；没有就走直连，省成本。
track_pricing 方法接收四个参数：对手ID、目标URL、套餐选择器、价格选择器。CSS 选择器用 BeautifulSoup 解析，匹配到套餐名称、价格数字、功能列表。
价格提取用了正则 \$(\d+\.?\d*)，兼容 $29、$29.9、$29.99 各种写法。功能列表直接扫所有 li 标签，存成 JSON 数组。
入库时自动打时间戳。同一套餐多次抓取会生成多条记录，为后面的变更分析留原材料。
03 | 变更检测：比对手早知道，比内部早同步
原始数据堆在那里没用，关键是比较。系统提供两种对比维度：横向看同一时间点各对手定价，纵向看单一对手的历史变动。
定价变更查询用 SQL 按时间倒排，Python 层做差分计算。连续两条记录价格不同，就生成一条变更事件。这个设计故意把逻辑放在应用层——SQL 只负责取数，业务规则随时改。
更隐蔽的监控是招聘情报。对手招"客户成功经理"还是"解决方案架构师"，透露了战略重心。招销售代表是扩张信号，招产品经理可能是要发新品。
招聘页通常比新闻稿早2-4周暴露动向。把 Indeed、LinkedIn 的职位抓取接进系统，等于给竞品装了早期预警雷达。
04 | 落地：从代码到晨会仪表盘
技术方案再漂亮，用不起来就是垃圾。这套系统的部署门槛故意压得很低：单文件 Python 脚本，SQLite 零配置，定时任务用 crontab 或 GitHub Actions 都行。
输出层建议接两个渠道：Slack/飞书机器人做实时提醒，Metabase/Superset 做可视化仪表盘。销售总监每天早上扫一眼定价变动面板，比翻 17 个网站高效得多。
有个踩坑经验：别贪多。先盯 3 个核心对手的定价，跑通闭环再扩展。我见过团队一上来列 20 个监控目标，维护成本压垮，三个月弃坑。
反爬策略也要分级。定价页通常防护松，博客和招聘页可能上 Cloudflare。遇到拦截再切 ScraperAPI，成本可控。
数据合规是底线。只抓公开页面，不碰登录后的内容，频率控制在礼貌范围内（建议单域名每分钟不超过 10 次）。
这套方案的价值不在技术复杂度，在把"竞品情报"从偶发动作变成系统能力。市场团队不再需要等产品经理有空才同步对手动态，定价调整从"季度复盘"变成"周级响应"。
最后留一个问题：你们公司现在怎么跟踪竞品定价？是专人盯、销售口耳相传，还是干脆等客户流失了才知道？如果有个工具每天早 8 点推送"昨日定价变动摘要"，谁会第一个抢着用？
热门跟贴