新旧视频组与两张已保存的边界卡片相连。

先准备自己的发布记录和一张简单的工作表。如果能访问 Instagram Insights,也就是账号的私有分析报告,可以用这些报告帮助选择切实可行的发布时段。将这些报告与公开计数分开保存。一条公开指标记录不能说明粉丝何时在线。

读者既会问上传时间是否仍然重要,也会问如何找出计数与发布时间之间的基本规律。这些问题说明了本指南的用途。但它们没有提供受控的发布时间测试结果。

下面的方法会生成两份有用的记录:计划发布表和结果表。它也能帮助你明确下一步决策:继续测试、修改测试,或报告无法得出结论。

1. 确定一个账号、一种计数和一项决策

Reel 是 Instagram 上的视频帖子。指标是测量得到的数值,例如公开观看次数。在发布测试帖子之前,先选定一个指标。

例如,可以选择发布满 24 小时后的公开 `views`。这只是一个建议的测试规则,并不表示 24 小时就是最佳观测时点。

发布后时长是指从发布到观测时经过的时间。发布后 24 小时的计数与发布后两天的计数对应不同的时长。不要将它们放在一起比较。

采集结果之前,先写下这些规则:

  1. 注明要测试的账号。
  2. 明确 Reel 的形式和主题范围。
  3. 选择一种公开计数,并保持其定义不变。
  4. 确定每次读取计数时的发布后时长。
  5. 明确需要做出的发布安排决策。
  6. 写明如何处理缺失、延迟和不确定的读数。

将 `views`、`plays`、`playsInstagram`、`likes` 和 `comments` 分开处理。不要用播放次数代替缺失的观看次数。不要将点赞数加到观看次数上。观看次数不等于去重后的人数。

一个有用的决策可以是:在两个能长期执行的发布时段之间做出选择。这项测试不能确定 Instagram 的排序规则。它不测量用户观看了多长时间,也不测量私有触达数据,还不能区分付费与非付费结果。

2. 选择可行的发布时段,统一时间规则

选择两到三个适合你工作安排的发布时段。如果增加第三个时段会导致各组可比较的帖子过少,就先从两个时段开始。

明确定义每个时段。写明开始时间、结束时间和时区。说明结束时间是否包含在该时段内。例如,可以包含开始时间,但不包含结束时间。这条规则可以避免同一个发布时间同时属于两个相邻时段。

写明账号采用的时区及其夏令时规则。夏令时会改变某些地区的本地时间与 UTC 之间的对应关系。UTC 是一种通用时间标准。发布安排应保留本地发布时间。如果有精确的 UTC 时间,也要一并保存。用精确时间计算发布后时长。

如果测试期间发生夏令时切换,请遵守事先写下的规则。不要在未说明的情况下,将按本地时间确定的时段改为按固定 UTC 时间确定的时段。

账号所有者的 Insights 数据可以为计划提供背景信息,但不能代替测试。将所有私有受众信息保存在账号所有者的记录中。不要声称公开观看次数能确定受众在线的时段。

你可以用内容形式与发布频率指南描述当前的发布规律。发布频率是指你多久发布一次内容。那篇指南统计的是发布活动。本指南则帮助你选择未来的发布时间,并比较之后的结果。

3. 将可比较的 Reels 轮流安排到不同时段和日期

分配是指为每条 Reel 选定发布时段。在看到结果之前,先写下分配方案。

在工作条件允许的范围内,尽量让计划发布的帖子具有可比性。记录主题、形式及其他可能影响比较的差异。不要把所有有把握表现好的主题都放在一个时段,把所有表现不确定的主题都放在另一个时段。

通过轮换分配,分散这些差异。轮换是指让各类计划帖子轮流进入不同的发布时段。也可以采用随机分配,即用随机方式选择时段。这两种方法都不能消除小规模测试中的所有不确定性。

按以下顺序操作:

  1. 列出计划发布的 Reels。
  2. 将主题和形式相近的内容分组。
  3. 将各组内容分散安排到选定的发布时段。
  4. 让每个发布时段都覆盖计划测试的不同日期。
  5. 在发布前保存分配方案。
  6. 记录每次变更及其原因。

不要让一个时段只安排工作日帖子,另一个时段只安排周末帖子,除非你本来就想测试这种日期与时段相结合的安排。否则,日期和时间的影响仍然混在一起。

不要因为某次结果特别高,就将剩余最有把握表现好的 Reels 都移到那个时段。保留原计划。如果需要新计划,请将其标为新的测试期。

同时记录推广、节假日和合作账号。合作账号是指参与该帖子的另一个账号。即使采用轮换分配,这些差异也可能仍然很重要。

4. 保存发布安排和观测记录

一次观测是指在已知时间读取并保存一次计数。将计划读取时间与实际读取时间分开记录。

下表列出了工作表中有用的列。其中一些使用 Actor 字段名。Actor 是托管运行的数据采集程序。其他列则由你自行记录。

4. 保存发布安排和观测记录
记录项目保存内容
账号和测试期账号身份、测试开始时间、测试结束时间和决策
时段分配计划时段、计划日期和分配变更
内容备注主题、形式、推广、节假日和合作账号备注
帖子身份已知的直接网址,以及返回结果中提供的 `postId` 和 `postUrl`
发布时间依据账号所有者的发布记录、`publishedAt`、时区和时间精度
观测计划选定指标、目标发布后时长和计划读取时间
实际观测Actor 读数的 `scrapedAt`,或手动读取时记录的时间
已保存计数指标字段、返回值、来源和已知精度
采集状态返回结果中提供的 `status`、`statusReason` 和 `postMetricStatus`
比较状态已纳入、延迟、失败、计数缺失或时间待确认
复核备注排除原因、信息冲突或其他不确定性

检查发布时间的精度。只有日期的值只能说明是哪一天,不能确定发布的具体小时。不要将日期转换为当天零点的时间戳。

如果需要精确到小时的发布时间,请单独保存账号所有者的发布记录。如果该记录与公开的发布时间字段冲突,请保留两者,并在使用发布后时长之前解决冲突。

手动读取时,要保存来源,并注明显示的计数是精确值还是经过舍入的值。不要将屏幕上经过舍入的数字与已保存的精确计数混在一起,当作同等精度的数据。

5. 采集选定的公开计数

如果能在计划的发布后时长读取并保存同一种公开计数,就可以用手动记录完成测试。各时段应使用一致的来源。每次都要记录实际读取时间。

Instagram Metrics Scraper 提供了一条有文档说明的途径,可从已知内容网址采集当前的公开指标记录。其公开构建版本 1.0.35 接受将 `mode` 设为 `contentUrls`,并在 `startUrls` 中提供直接网址。所提供的公开接口规范已于 2026 年 10 月 25 日核查。本指南没有进行付费运行。因此,这些证据支持的是文档中的输入和字段说明,并非当前实际运行的结果。参见公开默认构建版本记录。

一次运行是指执行一次 Actor。以下小型输入已对照公开输入结构定义进行核查。该定义规定了可接受的输入字段。这份输入尚未实际运行:

json
{
  "maxItems": 1,
  "mode": "contentUrls",
  "startUrls": ["https://www.instagram.com/reel/DIwcCZgxVZP/"]
}
5. 采集选定的公开计数

将示例网址替换为测试中某条已知公开 Reel 的网址。请完整替换示例值。如果在自己的网址旁边保留示例网址,就会增加一个无关的采集目标。

`maxItems` 限制返回的指标记录总数。设为 1 适合这次单网址检查。如果采集规模更大,请检查该限制,避免计划列表被截断。仍需逐一核对每个计划网址,确认它有对应结果,或记录其结果缺失。

Instagram Reels Performance Tracker 是一个公开 Task。Task 是保存好的输入预设。其页面和预设身份已核查。本指南没有通过已登录账号读取其保存的设置,也没有运行该 Task。使用前,请检查这些设置,并替换示例输入。

Actor 提供当前的公开观测数据。发布分配方案、读取计划、比较和决策需要由你完成。不要假定该预设会安排读取时间或完成这项实验。

6. 比较前检查每一次计划读数

对 Actor 读数,使用 `scrapedAt` 作为实际采集时间。不要用运行开始时间或计划提醒时间代替。`publishedAt` 是发布时间的依据。这些字段各有不同用途。

用核查后的发布时间和观测时间计算发布后时长。设置发布后 24 小时采集的提醒只是一项计划,不能证明采集确实发生在发布后 24 小时。

下面的精确 24 小时方法只将发布后恰好 24 小时的观测纳入汇总。提前或延迟的读数要单独列出。如果你的工作流程需要允许一定的时间误差,请在测试前明确规定。报告比较结果时,应说明对应的发布后时长区间,并列出实际时长。不要将其描述为精确的 24 小时数据。

检查以下异常状态:

6. 比较前检查每一次计划读数
状态处理要求
计数缺失保留为未知值。不要填零。
返回的计数为零如果来源和质量检查支持该值,就保留零。
读取延迟保存实际发布后时长。不要纳入精确时长汇总。
发布时间只有日期除非有独立依据提供具体时间,否则精确的发布后时长应保留为待确认。
采集失败保存失败记录及返回的原因。保留该计划帖子的记录。
指标不同不要将该读数纳入选定指标的比较。
计数精度不确定在问题解决前,不要将其纳入精确计数汇总。
目标没有匹配结果保留缺失记录并调查。不要假定没有活动。

如果返回结果中有 `status`、`statusReason` 和 `postMetricStatus`,请读取并保留它们的值。不要因为返回了一条记录,就假定其中每个指标都可用。

重新运行无法补回此前错过的读数。每月计数保存指南说明了过去报告边界上的同类限制。本测试将这一限制应用于每条帖子的计划发布后时长。

7. 比较符合条件的帖子,列明缺失情况

符合条件的读数是指满足测试前所定规则的读数。列出每条帖子,包括不符合条件的帖子。然后,仅汇总各计划分组内符合条件的读数。

对每个发布时段,报告以下信息:

  1. 计划帖子数。
  2. 符合条件的读数数量。
  3. 缺失或被排除的读数数量及原因。
  4. 每一个符合条件的计数。
  5. 计数的中位数。
  6. 符合条件计数中的最小值和最大值。

中位数是将计数排序后位于中间的值。如果计数的数量为偶数,就取中间两个值的平均数。这里的平均数等于这两个值的和除以二。

取值范围显示最小值和最大值。它能帮助读者判断:较小的中位数差异,是否处于帖子结果较大的波动范围内。报告中位数时,必须同时列出帖子数量和缺失情况。

再次检查分配方案。某个时段是否有更多经过推广的帖子?是否由某一个主题占据多数?读取失败是否导致某一组缺少了一整类帖子?将这些限制与结果一起说明。

差异只描述符合条件的样本中发生的情况,不能证明发布时间具有普遍适用的影响。

8. 完整演示一个原创虚构示例

本例中的所有内容均为原创虚构。这些记录为教学而编造,并非 Actor 输出,也不是真实账号的结果。

这个虚构账号测试两个切实可行的发布时段 A 和 B。它使用发布后恰好 24 小时的精确公开 `views`。虚构的账号所有者拥有精确的发布记录。可比较的主题在两个时段和不同测试日期之间轮换分配。

计划中共有九条 Reels。其中八条有符合条件的精确 24 小时读数。第九条只有发布后 25 小时的延迟读数。它的计数不纳入 24 小时汇总。

8. 完整演示一个原创虚构示例
Reel分配时段实际读取时的发布后时长发布后恰好 24 小时的观看次数比较状态
A1A24 小时100符合条件
A2A24 小时120符合条件
A3A24 小时140符合条件
A4A24 小时160符合条件
B1B24 小时110符合条件
B2B24 小时130符合条件
B3B24 小时150符合条件
B4B24 小时170符合条件
B5B25 小时缺失延迟读数单独保留

B5 缺失的是未观测到的发布后恰好 24 小时的计数。这个值不是零。延迟读数不能填补这一缺失。

时段 A 符合条件的观看次数排序后为 100、120、140 和 160 次。中间两个值为 120 和 140 次观看:

中位数 A = (120 + 140) / 2 = 130 views.

时段 B 符合条件的观看次数排序后为 110、130、150 和 170 次。中间两个值为 130 和 150 次观看:

中位数 B = (130 + 150) / 2 = 140 views.

观测到的中位数差异为:

140 views − 130 views = 10 views.

以 A 为基准,相对差异为:

10 views / 130 views × 100 = 7.69%.

在这次除法中,观看次数的单位相互抵消。这个百分比比较的是两个中位数。它不是人数占比,不衡量结论的确定程度,也不承诺增长。

8. 完整演示一个原创虚构示例
时段计划帖子数符合条件的读数数量精确时长读数的缺失数量中位数最小值至最大值
A440130 次观看100 至 160 次观看
B541,因读取延迟140 次观看110 至 170 次观看

在符合条件的读数中,B 的观测中位数较高。两组的取值范围有重叠,而且 B 缺少一次精确时长的读数。这个小型虚构样本不能证明存在普遍适用的最佳发布时间。审慎的下一步决策是先按计划重复比较,再考虑是否将 B 作为长期优先选择。

来源和延伸阅读

作者 Chronometrica · 更新日期

返回顶部 ↑