如何审核 Instagram 评论中的购买相关问题

1. 明确审核范围

选择品牌自己发布的、已知的公开产品帖子。开始前，记下帖子链接，并设定一个较短的审核时间范围。说明是只审核一次评论，还是稍后还会再次检查。

顶层评论是直接发表在帖子下的评论。回复则位于另一条评论之下。本方法使用公开的顶层评论。审核人员可以查看可见回复以了解上下文，但下方的采集输入配置不会导出回复文本。

写一份简短的范围说明，包含以下内容：

1. 所选的公开产品帖子。
2. 选择这些帖子的原因。
3. 审核的时间范围。
4. 每篇帖子最多采集多少条评论。
5. 负责核实产品事实的人员。
6. 处理个人订单详情的常规支持流程。

本指南源于一位读者提出的问题：“如何筛选 Instagram 私信和评论中的潜在客户？”在这里，“筛选”是指核实一个问题还需要哪些信息，才能给出有用的回复。DM 指私信，不在本采集方法的范围内。所提供的问题来自一则与供应商有关联的公开讨论。它只能说明有人问过这项工作，不能证明市场需求、产品使用情况或付费意愿。读者问题，发表于 2026 年 7 月 2 日；一条与供应商有关联的观察记录。

不要用点赞、账号名称或个人资料来猜测谁会购买。应根据问题的文字和产品上下文作出决定。

2. 仅在需要时采集少量样本

Actor 是在托管环境中运行的数据采集程序。根据文档，Instagram Comments Scraper 适合保存已知公开帖子或 Reels 短视频中的公开顶层评论。它不返回私信、回复文本、购买意向或销售数据。这些限制来自所提供的 0.1.21 构建版本公开接口约定检查。本指南未进行付费运行。公开默认构建版本，核查于 2026 年 10 月 25 日；仅检查接口约定。

可从以下简短输入配置开始：

{
  "collectAllAvailable": false,
  "commentSortMode": "default",
  "maxCommentsPerPost": 10,
  "postUrls": ["https://www.instagram.com/reel/DIwcCZgxVZP/"]
}

将示例 Reel URL 替换为品牌自己发布的、已知的公开产品帖子链接。示例 URL 不能作为有关你方产品的证据。这组输入已通过公开输入规则检查，但本文未用它实际运行采集。

`postUrls` 用于填写帖子链接。`maxCommentsPerPost` 将每篇帖子的采集上限设为 10 条不重复的顶层评论。10 是上限，不是承诺返回的结果数量。

将 `commentSortMode` 设为 `default` 会保留来源的默认顺序。这不保证采集到最新评论，也不保证样本是随机的。文档中列出的其他选项会按日期对已采集的样本排序。

将 `collectAllAvailable` 设为 false 会保留数量上限。设为 true 会取消该上限，费用可能大幅增加。公开数据流结束、运行超时或来源出现故障时，运行仍可能停止。取消上限不能证明采集覆盖了全部评论。

Actor 还接受两个可选日期字段：`commentsFrom` 和 `commentsUntil`。本示例未使用它们。如果添加日期，请将这些设置与审核说明一同保存。

Task 是为 Actor 保存的一组预设输入。公开的 Instagram Customer Feedback Comment Dataset Task，核查于 2026 年 10 月 25 日；仅确认页面存在 可作为起点。已确认其公开页面存在，但未通过已登录账号读取其保存的输入，也未运行该 Task。使用前，请检查设置并替换示例值。

3. 将来源字段与审核决定分开

添加标签前，先保存原始导出文件。字段是每条已保存记录中一个有名称的值。一行代表一条采集到的顶层评论。

保留文档中列出的以下来源字段：

这些是 Actor 字段。问题标签和批准状态应放在另设的人工填写字段中。公开输出约定列出了上述来源字段。公开默认构建版本，核查于 2026 年 10 月 25 日；未进行运行测试。

使用电子表格时，将标识符保存为文本。标识符用于标记一条记录，不是用于计算的数字。文件处理方法请参阅 Instagram 评论导出指南。本次审核应专注于问题本身，以及回答问题所需的事实。

按 `commentId` 删除重复导入的记录。即使文字相同，只要 ID 不同，就应保留这两条评论。如果缺少 ID，就将该条记录保留为待解决状态。不要因为两条记录的 ID 都为空或文字相同就将它们合并。

保留缺失值。null 值表示无法获取该值。零是实际观察到的数值。`repliesCount` 为 null 不代表回复数为零。回复数为零也不会提供回复文本。这两个值都不能说明有用的产品回复应当写什么。

4. 先阅读帖子，再给问题加标签

打开原始产品帖子。阅读帖子说明，并查看展示的产品。然后根据问题，核实当前产品页面、价格条款、库存信息或配送条款。

一句简短的问题可能有多种含义。“多少钱？”可能指同一篇帖子中的单件产品、套装或某个款式。“这个适用吗？”需要先明确产品和用途。“能寄到这里吗？”并未说明目的地。

对每条评论，记录核实的内容和时间。尽可能附上来源链接。如果帖子展示了多款产品，请写明问题似乎针对哪款产品，以及判断理由。如果无法判断，就将所指产品保留为待确认。

有帮助时，人工阅读可见讨论中的上下文。评论可能提到先前的一条回复，而导出文件中没有这条回复。不要编造这些上下文。如果帖子或相关回复无法查看，请记录这一缺口，并安排人工核查。

拟写回复时，应使用当前产品条款。评论日期和采集时间各有用途。前者说明问题何时出现，后者说明工具何时保存了它。两者都不能证明今天的价格或库存与此前的销售条件一致。

5. 标记请求类型，明确下一步要核实的事实

使用少量标签。标签描述对方想了解的信息，不用于评估这个人的价值，也不预测购买行为。

这些是建议由分析人员使用的标签。分析人员是指审核记录的人。Actor 不提供这些标签。

一条评论可能需要多个标签。“蓝色那款多少钱，能寄到这里吗？”需要同时核实价格和配送情况。保留一条评论记录，并记下两个标签。不要将它算成两位买家。

把下一步要核实的事实写成具体任务。“核实蓝色款的价格”能让负责人清楚要做什么。“跟进”则不能。

不要在共享的公开问题表中保存配送目的地、订单号或其他个人详情。如果工作需要这些信息，请使用品牌常规的获准支持流程。公开问题表可以注明需要进行非公开核查，无须复制这些详情。

已有订单投诉也需要谨慎处理。评论只是报告了一个订单问题，不能独立核实订单是否属实，也不能确认评论者的买家身份。

6. 建立人工回复审核表

在保持原样的来源字段旁添加审核列。记录足够的细节，让其他人也能理解这项决定。

可使用“待补充上下文”“待核实产品事实”“待批准”“已批准”和“已记录操作”等状态。也应允许使用“无需回复产品问题”。这些是你方设置的人工状态，不是 Actor 输出字段。

即使尚不知道对方是否会购买，明确的问题也可能值得回复。应根据回答的准确性和实用性来决定是否批准。

为每条评论留下可追溯的决定。赠品活动审核指南 也使用相同的记录原则，但用途不同。在这里，决定针对的是下一步回复操作。让未解决的问题保持可见，不要勉强批准。

7. 完整示例：六条评论，未确定已确认买家总数

原创虚构示例：本示例中的所有评论、ID、上下文和审核决定均为教学虚构。它们不是 Actor 结果，也不是真实品牌的记录。

在这个虚构案例中，一篇产品帖子展示了标准款和蓝色款。帖子未注明价格。审核人员已查看这篇虚构帖子，但尚未核实当前价格，也未核实评论者的收货目的地。

拟议操作与已完成操作仍应分开记录：

本示例未声称已发布任何回复。提出操作不等于批准操作，批准操作也不能证明有人已发布回复。

以下计算统计的是评论记录行数：

• 产品问题行数 = 2 行价格问题 + 1 行配送问题 = 3 行。
• 已有订单服务行数 = 1 行。
• 无需操作的赞美行数 = 1 行。
• 待解决行数 = 1 行。
• 合计 = 3 + 1 + 1 + 1 = 6 行评论记录。

产品问题占比为 3 行产品问题除以 6 行已审核评论记录，即这个虚构样本中评论记录行数的 50%。这不是买家比例，也不是购买率。

这里未确定已确认买家数量。不要写成零位买家，因为买家身份尚未核实。也不要写成三位买家，因为只是三行记录提出了产品问题。本示例同样未确定这六条评论由多少人撰写。

C3 仍需核实目的地。“能寄到这里吗？”这句话不能证明可以配送。

8. 批准操作前，检查信息缺口

逐条检查记录是否存在以下问题：

1. 缺少来源标识：没有可用评论 ID 的记录应保持待解决状态。不要根据重复文字猜测它是哪条评论。
2. 上下文无法获取：记录无法查看的帖子、不明确的款式或无法查看的回复。安排人工核查或澄清。
3. 缺少产品事实：在负责人核实当前来源之前，不要作出有关价格、库存、配送或适用性的断言。
4. 需要个人服务详情：共享表格只记录已批准的支持操作。个人详情应留在常规支持流程中处理。
5. 达到采集上限或覆盖范围不确定：只描述已保存的样本。不要声称样本包含了所有产品问题。
6. 未保存任何记录：不要据此断定帖子下没有问题。先人工查看来源，再判断空结果的含义。
7. 操作状态未知：保持操作未确认。草稿或批准记录不能证明回复已经发布。

发布前，负责人应再次打开评论。确认产品上下文、当前回答依据，以及拟定回复是否仍然合适。这是在核查操作，不代表导出文件包含所有回复。

后续购买和服务结果应保存在仅负责人可访问的记录中，并各自附上证据。仅凭公开询价评论，不能将一笔销售归因于该评论。不要添加收入评分，让不完整的记录看起来像已有确定结论。