用 12K+ 条亚马逊评论信号，定位机械键盘下一版该改什么

本文根据 AntsData 原文整理改写，重点保留数据口径、分析方法和可复现的 API 管线，弱化产品宣传表达。文中的数据来自原文所述的一次实际运行，更新时间为 2026 年 10 月 29 日。

一、问题：产品改版不应该只靠"感觉"

做机械键盘时，团队经常会遇到一个看似简单、实际上很难回答的问题：

买家究竟在抱怨什么？下一版产品应该优先解决哪些问题？

比较常见的做法是人工阅读评论，再凭经验总结。但当竞品池里有几十个 ASIN、累计评论超过十万条时，逐条阅读很难保持一致的判断标准，也很难在有限时间内完成跨商品比较。

这次分析采用了一个相对克制的思路：

1. 通过关键词搜索发现机械键盘商品；
2. 对搜索结果去重，得到唯一 ASIN；
3. 拉取每个 ASIN 的商品信息和评论摘要；
4. 统计不同抱怨主题在商品摘要中的出现次数；
5. 再将主题频次与评分、评论量、一星评论占比交叉查看。

这里不直接声称"某个功能一定能提升销量"，而是先回答一个更基础的问题：在这个品类快照中，哪些问题被买家反复提到？

二、数据概况

本次运行得到的结果如下：

指标	结果
关键词发现搜索	6 次
原始商品记录	120 条
去重后 ASIN	62 个
商品建档成功数	62 个
评论信号总量	121,606 条
平均评分	4.46
平均一星占比	6.3%
API 调用	17 次
消耗	0.0847 credits

需要注意，"121,606 条评论信号"是这些商品记录中的 reviews_count 合计，并不等于本次把 121,606 条原始评论逐条下载、逐条做 NLP。分析使用的主题来源是每个商品记录里的 customer_says 摘要。

三、字段和分析口径

每条商品 enrichment 记录中，本文主要使用以下字段：

• customer_says：Amazon 对该商品评论主题的摘要，本文的负面主题均从这里提取。
• rating_stars_distribution：评分星级分布，可用于观察一星评论占比。
• reviews_count：商品评论量，用于粗略观察评论护城河。
• rating：商品评分，用于观察整体满意度。

分析过程没有再搭建复杂的文本分类模型。Amazon 已经提供了统一口径的商品评论摘要，管线主要做两件事：

• 统计每个抱怨主题出现在多少条商品摘要中；
• 将主题频次与每个 ASIN 的评分、评论量和一星占比交叉。

这样做的优点是成本低、流程简单、容易重复运行。缺点也很明确：它分析的是平台摘要，而不是原始评论全文。

四、API 管线示例

AntsData 的 Amazon Scraper 的搜索结果可用于获得 ASIN 和商品 URL，商品采集可返回商品详情、评分和评论相关字段；实际调用时仍应以你账号对应的接口文档和控制台返回结构为准。

说明 ：下方 endpoint、字段名和异步 run 查询路径沿用本文原始实跑记录中的接口形式，不应替代当前版本的官方接口文档。首次接入时建议先打印一条完整 JSON 响应，再确认 records、items 和 status 的实际层级。

import os
import time
from typing import Any, Dict, Iterable, List

import requests

API = "https://api.antsdata.com/v1/scraper"
HEADERS = {
    "Authorization": f"Bearer {os.environ['ANTSDATA_API_KEY']}",
    "Content-Type": "application/json",
}


def post_json(path: str, body: Dict[str, Any]) -> requests.Response:
    response = requests.post(
        f"{API}{path}",
        headers=HEADERS,
        json=body,
        timeout=120,
    )
    response.raise_for_status()
    return response


def search(keyword: str, country: str = "us") -> List[Dict[str, Any]]:
    response = post_json(
        "/amazon-scraper/search",
        {
            "deliveryMode": "sync",
            "recordLimit": 20,
            "targets": [{"keywords": keyword, "country": country}],
        },
    )
    payload = response.json()
    return payload.get("data", {}).get("records", [])


def poll_run(run_id: str, max_polls: int = 30, interval: int = 10):
    for _ in range(max_polls):
        response = requests.get(
            f"{API}/runs/{run_id}",
            headers=HEADERS,
            timeout=30,
        )
        response.raise_for_status()
        payload = response.json()
        status = payload.get("status")

        if status == "succeeded":
            data = payload.get("data", {})
            return data.get("items", data.get("records", []))
        if status in {"failed", "error", "cancelled"}:
            raise RuntimeError(f"run {run_id} failed: {payload}")

        time.sleep(interval)

    raise TimeoutError(f"run {run_id} unfinished after {max_polls * interval}s")


def unique_asins(records: Iterable[Dict[str, Any]]) -> List[str]:
    seen = set()
    asins = []
    for record in records:
        asin = record.get("asin") or record.get("ASIN")
        if asin and asin not in seen:
            seen.add(asin)
            asins.append(asin)
    return asins


def enrich(asins: List[str], country: str = "us") -> List[Dict[str, Any]]:
    output = []

    for start in range(0, len(asins), 10):
        batch = asins[start:start + 10]
        targets = [
            {
                "country": country,
                "url": f"https://www.amazon.com/dp/{asin}",
                "zip_code": "90001",
            }
            for asin in batch
        ]
        response = post_json(
            "/amazon-scraper/product",
            {
                "deliveryMode": "sync",
                "recordLimit": len(targets),
                "targets": targets,
            },
        )
        payload = response.json()

        if response.status_code == 202 or "id" in payload:
            records = poll_run(payload["id"])
        else:
            records = payload.get("data", {}).get("records", [])

        output.extend(records)

    return output

一个最小运行示例：

keywords = [
    "mechanical keyboard",
    "wireless mechanical keyboard",
    "bluetooth mechanical keyboard",
]

search_records = []
for keyword in keywords:
    search_records.extend(search(keyword))

asins = unique_asins(search_records)
product_records = enrich(asins)

print(f"unique ASINs: {len(asins)}")
print(f"product records: {len(product_records)}")

原文中的实际运行过程是：6 组关键词各获取 20 条记录，合计 120 条；去重后得到 62 个 ASIN。随后按每批不超过 10 个 ASIN 的方式进行商品建档。AntsData 还将 Amazon Scraper 的典型输出范围概括为商品信息、价格、库存、卖家、评分与评论等字段，因此后续分析可继续从实际返回 JSON 中核对 customer_says、rating_stars_distribution、reviews_count 和 rating 是否存在。

五、主题统计结果

对 62 条 customer_says 摘要进行主题计数后，得到以下结果：

抱怨主题	被提及的商品记录数
connect	15
battery	7
break	7
software	4
cheap	3
stop working	3
rattle	1
delay	1

这张表反映的是"有多少个商品摘要提到了某主题"，不是原始评论条数，也不是用户人数。它更适合用来做品类层面的优先级排序，而不适合直接推导市场占比或统计显著性。

1. 连接问题是最集中的主题

connect 出现在 15 个商品摘要中，明显高于其他主题。battery 出现 7 次，delay 出现 1 次。

如果把这些主题放在无线键盘场景中看，它们可能共同指向一组体验问题：

• 首次配对不顺利；
• 使用过程中断连；
• 电量不足导致设备停止工作；
• 重连或输入响应存在延迟。

不过，connect、battery 和 delay 不能在没有原始评论的情况下直接合并为同一个根因。更稳妥的做法是将它们列为同一排查簇，再用自己的产品评论、售后记录和测试数据继续验证。

2. 软件问题应单独处理

software 出现 4 次。它更可能对应配套 App、灯效控制、配置工具或固件更新体验。

这类问题不一定需要改模具或更换硬件，优先排查的可能是：

• 配置软件是否稳定；
• 设备识别是否可靠；
• 固件升级流程是否容易理解；
• RGB 或按键映射是否存在异常。

3. 结构和耐用性问题

break 出现 7 次，rattle 出现 1 次，stop working 出现 3 次。这些主题可能与结构强度、装配质量、轴体或个别部件失效相关。

但仅凭摘要无法确定具体故障位置。因此，改版前仍然需要回到原始评论、退货原因、质检记录和售后图片，确认问题是集中在键帽、轴体、外壳、连接模块，还是个别批次。

4. cheap 更接近价值感知问题

cheap 出现 3 次。它未必表示某个零件损坏，更可能是在表达"价格和实际质感不匹配"。

对这类反馈，解决方案不一定是简单堆料，还可能包括：

• 调整产品定位；
• 改善材质和装配细节；
• 优化配件组合；
• 让页面信息更准确，减少预期落差。

六、评论量和竞品结构

按 reviews_count 分组后，原文得到以下分布：

评论量区间	ASIN 数量
0--99	13
100--999	33
1,000--4,999	38
5,000 以上	18

原文同时提到的品牌 ASIN 数量包括：

• Redragon：10 个；
• AULA：8 个；
• Logitech：3 个；
• SteelSeries：3 个；
• RK ROYAL KLUDGE：3 个；
• Razer：3 个。

评论量可以作为竞争壁垒的一个粗略指标，但不能等同于品牌实力、销量或产品质量。一个 ASIN 的评论量高，说明它有更厚的历史积累；不代表它在所有具体需求上都更强。

七、如何把统计结果转成产品动作

可以先建立一个"主题---验证---动作"的决策表：

数据现象	下一步动作
某个主题在多个商品摘要中高频出现	将其列为品类问题，进一步检查原始评论和售后数据
自有 ASIN 一星占比高于样本均值 6.3%	优先拆解自有产品的一星评论，不直接照搬竞品结论
低评论量商品也能达到样本均值 4.46	关注这些商品的规格、体验或定位，寻找切入点
高评论量竞品在某个规格上形成壁垒	不必正面复制，考虑解决第二优先级但更明确的痛点
software 主题集中出现	优先安排 App、固件和配置流程排查
break、rattle 等主题出现	补充结构强度、装配一致性和来料检验验证

关键点在于：主题统计只能帮助排优先级，不能替代产品验证。尤其是"连接问题"这样的大主题，必须继续拆解成可测试的场景，例如配对成功率、断连频率、低电量表现、睡眠唤醒时间和重连时延。

八、这套方法的边界

1. customer_says 不是原始评论全文

它是 Amazon 的评论主题摘要。摘要口径相对统一，便于对多个 ASIN 做横向比较，但会损失上下文和细节。

如果要回答"具体是哪一批次、哪一个轴体、什么使用环境出了问题"，仍然需要获取和分析原始评论文本。

2. 62 个 ASIN 只是一个品类快照

这些商品来自特定关键词、特定地区和特定时间。关键词矩阵、站点、类目筛选条件或抓取日期发生变化后，主题排序可能发生变化。

因此，connect 出现 15 次应该理解为本次样本中的高频信号，而不是整个机械键盘市场永久不变的结论。

3. 频次不是抽样调查结果

本次数据来自商品记录池，而不是严格设计的随机样本。某主题出现 15 次，说明它在这批商品摘要中覆盖面较高，但不能直接换算成"15% 的用户都有这个问题"。

4. 评论量不能直接代表销量

评论量可能受到销售时间、品牌知名度、评论激励、站内流量和产品生命周期影响。它可以作为竞争壁垒的观察指标，但不应单独作为市场份额判断依据。

九、结论

这次分析的价值不在于得出一个非常复杂的模型，而在于把一个模糊问题变成了可复跑的流程：

1. 用关键词构建品类商品池；
2. 先去重，再按 ASIN 建档；
3. 用统一字段统计评论主题；
4. 将主题频次和评分、评论量、一星占比交叉；
5. 把结果转成可验证的产品和页面动作。

在这批 62 个 ASIN 中，连接相关问题最集中，其次是电池、结构耐用性和软件体验。但真正进入路线图前，仍应使用自有产品原始评论、退货原因和测试数据完成验证。

对于需要定期做竞品分析的团队，这种"先用低成本摘要做方向筛选，再对重点问题深入分析"的两阶段方法，通常比一开始就试图处理全部原始评论更容易落地。