2026 上半年 Momcozy App 商店负面评价分析
数据周期： 2026-01-01 ～ 2026-06-24
数据源： App Store + Google Play（US / GB / CA / AU）
分析口径： 只看 1-3 星真实负面 / 中性负面；不使用平均评分、好评率、五星占比作为判断依据。
生成时间： 2026-06-27
0. 一句话结论
上半年负面评价的核心矛盾，不是“用户不喜欢 App”，而是 App 承载硬件核心能力时的可靠性不足。
吸奶器 / 哺乳记录仍是上半年最大量负面来源；App 基础稳定性是横跨所有设备的底层问题；BBM / 婴儿监视器在 Q2 明显升温，从 Q1 的 7 条增加到 Q2 的 10 条，并且问题性质从体验缺口升级到“通知不可信、摄像头离线、宝宝哭声漏报”等安全感链路。
因此，BBM 不一定是“总量最大”的问题，但它是 Q2 最需要被单独升级认领的高风险问题。
1. 数据口径说明
由于存在主动拉升五星评价的情况，本报告不以以下指标作为核心判断：
- 平均评分
- 好评率
- 五星占比
- 负面占全部评价比例
本报告只关注：
- 1-3 星负面评价的绝对数量
- 问题类型结构
- Q1 → Q2 的绝对数量变化
- 严重程度 P0 / P1 / P2
- 是否出现版本回归线索
- 是否涉及用户信任 / 安全感链路
1-2 星视为明确差评；3 星视为中性负面 / 建议型问题。
2. 上半年负面大盘
| 指标 | 数量 |
|---|---|
| 上半年抓取评论总数 | 118 |
| 1-3 星负面 / 中性负面 | 79 |
| 1-2 星严格差评 | 64 |
| 1 星 | 48 |
| 2 星 | 16 |
| 3 星 | 15 |
| App Store 负面 | 31 |
| Google Play 负面 | 48 |
H1 负面问题结构
| 问题类型 | H1 条数 | Q1 | Q2 | 判断 |
|---|---|---|---|---|
| 吸奶器 / 哺乳记录 / 泵控制 | 29 | 16 | 13 | 最大量问题，Q2 略降，但仍是主盘 |
| App 基础稳定性 / 服务错误 / 登录白屏 | 21 | 11 | 10 | 持续存在，1月最集中，是底层信任问题 |
| BBM / 摄像头 / 婴儿监视器 | 17 | 7 | 10 | Q2 明显升温，风险权重最高 |
| 其他 IoT：白噪音、夜灯、体温计等 | 11 | 4 | 7 | Q2 增加，需要持续看 |
| 隐私 / 权限 | 1 | 1 | 0 | 单点问题，但一旦出现必须高优 |
读法：
- 上半年最大量问题是 吸奶器 / 哺乳记录。
- 横跨所有设备的底层问题是 App 基础稳定性 / 服务错误。
- BBM 是 Q2 最值得单独升级的问题：数量增加，且问题性质更重。
3. Q1 vs Q2：问题结构变化
Q1：服务错误和吸奶器问题更突出
Q1 负面共 39 条。
| 问题类型 | Q1 条数 |
|---|---|
| 吸奶器 / 哺乳记录 / 泵控制 | 16 |
| App 基础稳定性 / 服务错误 | 11 |
| BBM / 摄像头 | 7 |
| 其他 IoT 设备 | 4 |
| 隐私 / 权限 | 1 |
Q1 的核心问题是：
- 1 月底 server error / region 页面错误集中爆发，用户进不去 App，导致泵、摄像头、体温计等设备无法使用。
- 吸奶器侧集中在连接失败、泵控制、记录丢失、奶量不准。
- BBM 已有早期信号：连接不稳定、画面冻结不提醒、PiP 缺失、BM4 回放 / 时间戳问题。
Q2：BBM 和其他 IoT 问题升温
Q2 负面共 40 条。
| 问题类型 | Q2 条数 |
|---|---|
| 吸奶器 / 哺乳记录 / 泵控制 | 13 |
| BBM / 摄像头 | 10 |
| App 基础稳定性 / 服务错误 | 10 |
| 其他 IoT 设备 | 7 |
Q2 的关键变化：
- BBM 从 Q1 的 7 条增加到 Q2 的 10 条。
- App 基础稳定性仍然持续，但没有像 1 月那样集中爆发。
- 其他 IoT 设备负面增加，白噪音、夜灯、体温计、设备连接等问题开始更多出现。
- BBM 问题性质明显变重：从“缺功能 / 不好用”，升级到“通知不可信 / 摄像头离线 / 宝宝哭声漏报”。
4. 月度趋势：不要看比例，看爆发点
| 月份 | 1-3 星负面条数 | 主要问题 |
|---|---|---|
| 1月 | 23 | server error / region 选择异常、App 进不去、泵和摄像头无法使用 |
| 2月 | 9 | 吸奶器记录 / 耗电、白噪音夜灯亮度、多设备登录限制 |
| 3月 | 7 | BBM 信号抬头：画面冻结不提醒、PiP 缺失、BM4 连接和回放问题 |
| 4月 | 19 | BBM 通知延迟 / 离线 + 泵连接 / 数据丢失集中出现 |
| 5月 | 15 | server error 仍有反馈；BBM 摄像头离线、泵控制问题继续出现 |
| 6月 | 6 | 样本少，但 BBM 出现 “unsafe / serious failure” 高危原话 |
判断：
- 1月是 App 基础服务事故型问题最明显。
- 4月是 Q2 的负面高点，BBM 和泵连接问题同时明显。
- 6月虽然数量少，但 BBM 评价的情绪强度很高，出现明显信任风险表述。
5. 严重程度：Q2 的 P0 问题增加
严重程度定义：
- P0： 核心功能不可用 / 安全感风险 / 数据丢失 / 隐私风险 / 硬件价值被 App 阻断
- P1： 核心体验明显受损，但不一定完全阻断
- P2： 体验建议或局部不便
| 周期 | P0 | P1 | P2 |
|---|---|---|---|
| Q1 | 14 | 24 | 1 |
| Q2 | 19 | 18 | 3 |
| H1 | 33 | 42 | 4 |
判断：
Q2 的 P0 从 Q1 的 14 条增加到 19 条。这说明 Q2 不是简单“吐槽更多”，而是高严重度问题更多。
P0 主要集中在：
- App server error / 无法登录 / 无法进入
- 设备连接失败导致硬件不可用
- 数据丢失
- BBM 通知漏报 / 延迟 / 摄像头离线
- 泵控制失败或档位异常
- 隐私/权限风险
6. BBM 专项分析
6.1 BBM 是否 Q2 特别严重？
结论：是。
但更准确地说，不是“突然爆雷”，而是 Q1 有早期信号，Q2 问题性质升级。
| 周期 | BBM 负面条数 | 主要问题性质 |
|---|---|---|
| Q1 | 7 | 连接、PiP、多设备、回放、画面冻结 |
| Q2 | 10 | 通知漏报 / 延迟、摄像头离线、夜间 / 回放、温度乱报 |
| H1 | 17 | 连接可靠性 + 通知可信度 + 视频体验 |
Q1 的 BBM 问题更像：
- 功能不完善
- 连接不稳定
- PiP / 多设备缺失
- 回放体验不好
Q2 的 BBM 问题变成：
- 宝宝哭了不通知
- 宝宝哭了 30-40 分钟后才通知
- 摄像头离线，需要物理重启
- 背景噪音乱报，真正哭声漏报
- 用户直接说 unsafe / serious failure
这就是“问题性质升级”。
6.2 BBM 负面问题拆解
| BBM 问题类型 | H1 条数 | 代表问题 |
|---|---|---|
| 连接 / 离线 / 加载 | 6 | camera 连接失败、离线、App 端 monitor 加载慢 |
| 通知 / 告警不可信 | 4 | 哭声漏报、通知延迟、乱通知 |
| 多设备 / 家庭共享 / 通知 | 1 | 父母不能同时登录和收通知 |
| PiP / 多设备 | 2 | 不支持画中画、多设备同时看 |
| 回放 / 时间戳 / 夜间 / 预览 | 2 | 回放难用、时间戳错、夜间白底刺眼、首页预览不准 |
| 通知过量 + 云台 / 电池 | 1 | 温度阈值乱报、云台控制不灵敏、手持屏电池快 |
| 泛摄像头差评 | 1 | “3rd class camera product” |
注：部分评论同时涉及多个问题，表格按主诉归类。
6.3 BBM 代表性原话
通知不可信：
“Even when our baby is clearly crying, we do not receive notifications… For a baby monitor, this is a serious failure.”
2026-06-24，App Store，1 星
通知延迟：
“notification is lag. 40mins after baby cry.”
2026-04-05，Google Play，1 星
摄像头离线：
“The camera will go offline until you power cycle the camera… unplugging the camera above my half asleep 5 month old.”
2026-05-29，Google Play，1 星
画面冻结但不提醒：
“The camera system shows last image but doesn't notify you if it loses connection… staring at footage that could be 10 minutes old while your baby is in trouble.”
2026-03-09，Google Play，2 星
回放 / 时间戳：
“Fails to connect to the BM4 baby monitor half the time… The timestamp for the monitor is an hour off… The playback feature is cumbersome.”
2026-03-29，Google Play，1 星
6.4 BBM 判断
BBM 的问题不能按普通 App 体验问题处理。
原因有三点：
- 场景特殊： baby monitor 是安全感产品，用户对可靠性的容忍度极低。
- 问题集中： Q2 集中在通知、离线、回放、夜间体验这些核心链路。
- 情绪强度高： 用户使用 unsafe、serious failure、baby crying、camera offline 等高风险表达。
因此，BBM 建议升级为 IoT 产品专项闭环。
7. 版本线索
7.1 v2.1.13 / v2.1.14 附近：server error / region 页面问题集中
1 月底大量评价集中在：
- region 页面无法选择
- server error / 504
- App 进不去
- 设备依赖 App，结果设备无法使用
这类问题横跨泵、摄像头、体温计，是基础服务层问题。
7.2 v2.2.0.13 附近：白噪音夜灯亮度、浮窗、权限类体验
2 月中下旬出现：
- DreamSync 夜灯亮度不能低于 15
- App 耗电严重
- pump 浮窗关不掉
- 蓝牙设备却要求定位 / 网络
7.3 v2.2.5 附近：BBM 通知延迟 / 乱报开始明显
4 月初出现两个强信号：
- baby monitor 通知延迟 30 分钟
- 宝宝哭了 40 分钟后才通知，宝宝不在又乱通知
其中一条明确说 worked great before，疑似版本回归。
7.4 v2.2.6 / v2.2.7 附近：泵连接、数据丢失、白屏、server error 延续
4 月下旬到 5 月上旬：
- 泵连接失败
- 数据丢失
- 账号 / 网络报错
- 白屏，需要退出重开
- server error 仍有反馈
7.5 v2.2.12：BBM 高危通知漏报
6 月 24 日出现高危 BBM 评价：
- 宝宝明显哭了不通知
- 背景噪音乱通知
- 用户说 unsafe / serious failure
建议回看 v2.2.5 到 v2.2.12 之间 BBM 通知链路、声音检测、后台推送、灵敏度设置的改动与监控数据。
8. 问题类型分析
8.1 吸奶器 / 哺乳记录：最大量问题，但 Q2 略降
H1 共 29 条，Q1 16 条，Q2 13 条。
主要问题：
- 泵连接失败 / 只识别一边
- 记录不保存 / session 丢失
- 奶量估算不准
- 档位控制异常
- 浮窗关不掉
- 必须联网才能控制蓝牙设备
- Samsung Fold 等机型控制适配问题
判断：
吸奶器仍是最大负面来源，但 Q2 绝对数量略降。它是基本盘问题，需要持续治理，但当前“升温风险”不如 BBM 明显。
8.2 App 基础稳定性：横跨所有设备的底层问题
H1 共 21 条，Q1 11 条，Q2 10 条。
主要问题：
- server error / 502 / 504
- region 页面无法进入
- App 崩溃、白屏
- 登录或网络异常
- App 进不去导致设备不可用
判断：
这类问题不是某个产品线的问题，而是整个 App 作为硬件控制中枢的信任问题。尤其 1 月底集中爆发，必须保留事故复盘视角。
8.3 其他 IoT 设备：Q2 有增加
H1 共 11 条，Q1 4 条，Q2 7 条。
主要问题：
- 白噪音 / 夜灯连接失败或亮度设置异常
- 体温计单位错误或无法使用
- nightlight offline
- 设备配对成功但不显示
- DreamSync 蓝牙同步异常
判断：
其他 IoT 设备的数量还不算最大，但 Q2 上升，说明“设备接入和设备控制可靠性”不是 BBM 单点，而是 IoT 设备整体都需要关注的能力。
9. 管理判断：这不是单一产品 bug，而是“App × 硬件”可靠性问题
上半年负面评价反复出现一个共同模式：
用户买的是硬件，但核心体验被 App 卡住。App 一旦不稳定，硬件价值就被用户认为打折，甚至失效。
在吸奶器上，表现为：
- 不能控制泵
- 记录丢失
- 奶量不准
- session 不保存
在 BBM 上，表现为：
- 摄像头离线
- 通知漏报 / 延迟
- 画面冻结
- 回放难用
在其他 IoT 上，表现为：
- 夜灯 / 白噪音连不上
- 体温计无法正常显示
- 设备配对成功但 App 里不出现
所以，后续商店评价不能只按“App bug”或“设备问题”二选一处理，而要按 硬件核心能力是否被 App 可靠承载 来看。
10. 建议动作
10.1 建议一：建立 H1 负面问题台账，不要只做周报
第一版建议用 H1 作为基线，后续每月更新：
- 负面总量
- 产品线负面绝对数量
- P0 数量
- Top 问题变化
- 本月新增高危原话
- 闭环状态
不建议一开始只看周，因为商店评价单周样本太小，容易误判。
10.2 建议二：BBM 升级专项闭环
BBM 建议专项处理，不是因为它总量最大，而是因为：
- Q2 绝对数量上升：7 → 10
- Q2 出现更多 P0 链路问题
- 涉及通知漏报、摄像头离线、宝宝哭声检测
- 用户原话已经出现 unsafe / serious failure
建议专项拆成四条线：
- 通知链路： 声音检测、哭声检测、后台推送、灵敏度、误报漏报
- 连接链路： 摄像头在线状态、拉流、secure connection、离线恢复
- 视频体验： 回放、时间戳、首页预览实时性、夜间模式
- 家庭使用： 多设备同时看、父母共同接收通知、PiP
10.3 建议三：评价分析周报增加“产品线风险雷达”
用户增长 / App 运营侧每周不用写很复杂，但必须新增 5 个字段：
- 产品线
- 问题类型
- 严重程度 P0 / P1 / P2
- 版本线索
- 责任团队 / 闭环状态
周报管理层摘要只回答：
- 本期新增负面里，哪个产品线最需要关注？
- 是否出现 P0？
- 是否有版本回归线索？
- 哪个问题需要产品团队认领？
- 上期问题闭环到了哪一步？
10.4 建议四：不要只看评论流转，要看闭环状态
每个高危问题必须有状态：
- 新发现
- 已升级
- 产品确认中
- 研发定位中
- 已排期
- 已上线
- 观察中
- 不处理 / 无法复现，并说明原因
否则 VOC 会停留在“收集和转发”，不会变成产品经营能力。
11. 给团队的一段话
可以这样对团队说：
上半年商店负面评价里，吸奶器和 App 基础稳定性仍然是最大盘问题，但 BBM 在 Q2 明显升温，从 Q1 的 7 条增加到 Q2 的 10 条。更关键的是，BBM 的问题性质已经从 PiP、多设备、回放体验，升级到通知漏报 / 延迟、摄像头离线、宝宝哭声检测不可信。
>
这类问题不能按普通 App 体验问题处理。Baby monitor 是安全感产品，只要用户认为“宝宝哭了 App 没告诉我”“摄像头画面可能是旧的”，就会直接伤害产品信任。
>
后续商店评价不再只看评分和单条反馈流转，而要按产品线、问题类型、严重程度和闭环状态做风险雷达。用户增长负责发现和预警，IoT 产品负责判断和闭环，App 平台负责底层稳定性问题归因。
12. 下一步建议追踪指标
从 7 月开始，建议每月固定追踪：
| 指标 | 目标 |
|---|---|
| 1-3 星负面绝对数量 | 看真实问题规模 |
| P0 负面数量 | 看高危问题是否下降 |
| BBM 负面绝对数量 | 看专项是否有效 |
| BBM 通知 / 离线类负面 | 看安全感链路是否改善 |
| App 基础服务错误 | 看 server error / 白屏 / 登录是否复发 |
| 版本回归关键词 | 看更新是否引入新问题 |
| 上月 Top 问题闭环状态 | 防止问题重复出现但没人负责 |
最终判断：
上半年最大量负面仍在吸奶器和 App 基础稳定性；但 Q2 最值得警惕的是 BBM，因为它的负面数量上升且问题性质升级。BBM 应作为 Q2/Q3 的专项风险跟踪对象，而不是普通体验优化项。