让 TikTok 关键词研究在各查询组之间保持可比

制定采集计划

已保存的公开 Task 输入使用三条示例查询，`expandQueries` 设为 false，共享的 `maxResults` 上限为 150 条不重复视频，`resultsPerQuery` 设为 50，`maxPagesPerQuery` 设为 1，`searchDistribution` 设为 "balanced"。在运行完整查询面板之前，用你的目标词替换这些示例查询。

要在公开的 Search build 1.1.5 下验证你的设置，先做一次有界的试运行。把示例查询列表替换为一个拟定词。将 `expandQueries` 设为 false，`maxExpandedQueries` 设为 0，`maxResults` 设为 2，`resultsPerQuery` 设为 2，`maxPagesPerQuery` 设为 1，`searchDistribution` 设为 "balanced"。

一次使用 "python tutorial" 的基线检查返回了两行元数据，包含帖子 ID、帖子 URL、作者 ID、账号标识、五月和八月的发布日期，以及 OUTPUT 停止原因 `max_results_reached`。这次试运行确认了基本搜索字段和来源记录，但它不是多查询趋势基准，也不是广告活动测试。

原生数据集字段与运行证据

原生数据集记录包含 `postId`、`postUrl`、`authorId`、`profileHandle`、`publishedAt` 和 `observedAt`。搜索来源字段记录查询上下文：`rootQuery` 是原始查询族，`query` 是实际执行的搜索词，`querySource` 标识该词的来源。`pageIndex` 和 `pageRank` 记录该条目在已采集源页面上的位置。`status` 和 `statusReason` 报告条目级结果状态。源中缺失的可选字段保持为 null。

`OUTPUT` 对象提供的是运行证据，而不是自动的查询映射。关键字段包括：

• `queriesSearched`：实际执行的词组成的数组。
• `queryPlans`：查询、根查询和来源定义的计划列表。
• `effectiveResultsPerQuery`：在均衡分配过程中计算出的、被降低后的每词已保存视频上限。
• `rowsSaved`：写入数据集的不重复视频总数。
• `duplicatesSkipped`：因全局去重而略过的候选视频。
• `stopReason`：整次运行的停止状态，例如 `max_results_reached`。
• `sourceStatusCounts`：汇总后的源状态，例如 `{ok: 1}`。
• `status` 和 `statusReason`：顶层执行结果，例如 `status: "ok"` 和 `statusReason: null`。

在单查询对照运行中，`OUTPUT` 报告 `stopReason: "max_results_reached"`、`rowsSaved: 2`、`sourceStatusCounts: {ok: 1}`、`status: "ok"` 和 `statusReason: null`。

有用比例的定义是：对某个已尝试的词，已审阅、相关且 ID 已知的视频数，除以该词可比较、可审阅的候选样本；失败或未尝试的词没有有效比例。

制定采集计划

1. 在搜索之前先定义研究问题和查询族。仅当各词表示同一概念时才归为一组，并保留一份明确的查询列表。
2. 设定共享的 `maxResults`、`resultsPerQuery`、`maxPagesPerQuery`、是否扩展，以及 `searchDistribution`。比较一份精确的固定列表时，关闭扩展。共享的 `maxResults` 是所有查询合计的已保存视频上限，而 `resultsPerQuery` 限制单个词。
3. 若需要为每个词预先规划一份配额，选择均衡分配。只有当你的目标是先填满查询列表中较前词的上限时，才选择顺序分配。均衡分配可能会降低 `effectiveResultsPerQuery`，以便分摊总上限，但它不保证配额会被填满，也不保证未用配额会被重新分配。
4. 把计划预算和实际有用数据分开。记录尝试状态、已保存行、已知视频 ID、重复项、身份缺失和源失败状态。源失败之后，有用数据行的数量为 0，表示可用性未知，而不是该主题的兴趣为零。
5. 保留来源记录，并谨慎处理全局去重。来源记录是指同时保留确切的已保存来源，以及记录在 `observedAt` 中的采集时间。原生全局去重只在某条视频首次被观察到的查询下保存一次。若要捕获每一次查询出现，请为每个查询分别保留运行账本。
6. 对所有组使用同一条人工相关性规则。通过核对确切的 `postId` 和 `postUrl`，把候选视频和有用条目区分开。只用已尝试且可用的数据计算有用比例，并把失败或未尝试的词视为未知。
7. 在比较各组之前先报告缺口。把未尝试的词标为 `not_attempted`，而不是零，并让源上限保持可见。当采集上限或失败情况不同时，绝不要只按原始总数给查询组排名。
8. 保存你的查询计划和实际样本账本。在做趋势或广告创意分析之前，查看 `OUTPUT` 中的 `queriesSearched`、`queryPlans`、`rowsSaved`、`duplicatesSkipped` 和 `stopReason` 等字段，以记录确切的停止证据。

原创虚构采集账本

下面的全部数值都是为说明采集预算、停止状态和全局去重限制而创作的原创虚构内容。它们不代表实时产品基准或试运行结果。

设想三个词 A、B 和 C：`maxPagesPerQuery` 设为 1，扩展关闭，`maxResults` 设为 6，请求的 `resultsPerQuery` 设为 6。

• 均衡运行：报告的 `effectiveResultsPerQuery` 为 2，因此每个词的计划上限是 2 条已保存视频。如果每个词都返回 2 条互不相同的相关视频，账本显示 A=2、B=2、C=2，共保存 6 条视频。每个词的有用比例都是 2/2。
• 顺序运行：词 A、B 和 C 配置的每词上限都是 6。词 A 返回 6 条已保存视频，并填满共享的 `maxResults` 上限 6。词 B 和词 C 从未被尝试。账本记录每个词的计划上限为 6，其中 A 保存 6，B 保存 0（`not_attempted`），C 保存 0（`not_attempted`）。把 B 和 C 记为保存 0 行只是记账；它们的样本可用性仍然未知。
• 均衡运行中的源失败：词 A 保存 2 条有用视频（比例 2/2），词 C 保存 2 条有用视频（比例 2/2），词 B 遇到源错误。词 B 记录已保存行 0、有用行 0，相关性比例未知。标签 `source_failed` 是读者账本中的记号，不是原生数据集的枚举值。

虚构查询归属账本

另一次独立的虚构查询运行在不让全局去重滤掉重叠的情况下，评估视频在各词中的出现情况。

这张归属表在 5 个不同的视频 ID 上共有 6 次归属。一次全局去重后的导出只在词 A 下保留 V2。为 V2 保留词 A 的来源记录，并不能证明 V2 未出现在词 B 中。只有为每个查询分别保存有界运行账本，才能追踪完整的查询归属。