如何核对 Instagram 内容格式与发布节奏

你要收集的内容

Actor 是一个托管的数据收集程序。Task 是一份已保存的输入预设。Instagram Metrics Scraper 这个 Actor 收集来源行。日历、计数和排期选择由你来做。

当前公开版本是 1.0.35。该版本已于 2026-10-13 经过核对。接受的模式是 auto、contentUrls 和 profileUrls。这次核对使用 contentUrls。该模式表示由你提供内容网址。profileUrls 接收账号名称。把网址放在 startUrls 中。maxItems 是对行总数的可选上限。

一条内容行是至少带有一项公开指标的一项公开内容。失败的网址可能显示为缺口，而不是一条内容行。使用这些字段：

scrapedAt 不是发布时间。不要把它当作帖子日期。

你可能会看到这些公开计数。它们可能不存在。它们是 views、plays、playsInstagram、likes 和 comments。每个计数保留在自己的字段中。不要把它们相加。不要把它们变成私密受众规模。这次核对使用日期和格式。

日期可能缺失。格式标签可能缺失。缺失就是未知。未知不是零。

当前已保存的 Task 是 Instagram Content Publishing Cadence Source Data。Task 只是起始输入。它并不表示计数会自动完成。已保存的输入是：

{
  "mode": "profileUrls",
  "startUrls": ["@nike", "@adidas", "@playstation"],
  "maxItems": 60
}

在这次核对之前更改该输入。把 mode 设为 contentUrls。用已知的公开帖子网址或 Reel 网址替换 @nike、@adidas 和 @playstation。Reel 是一条公开的 Instagram 视频帖子。在已保存的行中，格式标签 reel 表示一条 Reel。试点是一次小型的首次测试。对于试点，把 maxItems 设为 3。使用三个网址，使上限与清单一致。

{
  "mode": "contentUrls",
  "startUrls": [
    "FIRST_KNOWN_PUBLIC_POST_OR_REEL_URL",
    "SECOND_KNOWN_PUBLIC_POST_OR_REEL_URL",
    "THIRD_KNOWN_PUBLIC_POST_OR_REEL_URL"
  ],
  "maxItems": 3
}

用真实的公开网址替换这三段占位文本。不要把示例账号名称留在 startUrls 中。

已保存的主页预设不被接受用于账号发现。它也不被接受作为完整历史。对 @nike 做的一次主页模式试点返回了 no_profile_content。发现记录是 blocked_or_challenged。该结果并不能证明 @nike 没有帖子。blocked_or_challenged 并不表示该账号是空的。

另一次测试使用了一条已知的公开 Reel 网址。这是本次核对所接受的路径。已保存的行有 postId。它包含账号字段。它的 mediaType 是 reel。它有 publishedAt。帖子说明文字存在。公开指标存在。那一条 Reel 并不能证明完整历史。这些是已核对的产品事实。它们不是本文后面的虚构日历。

没有经过核对的完整存档。没有经过核对的按日期范围搜索。一个看起来完整的页面并不能证明完整覆盖。达到上限并不能证明完整覆盖。指标上的成功并不能证明你列出了每一条帖子。

当前 README 是该 Actor 的公开说明。那些说明提到 maxItemsPerProfile。当前输入 schema 是已接受输入字段的列表。该列表不包含 maxItemsPerProfile。不要设置该字段。

maxItems 计算的是整个收集过程中的行数。它不是一次只计一个账号。较小的上限可以截断较长的网址清单。在已保存的输出中，检查 providedInputs、contentUrls、inputUrls、resolvedUrls、metricRows、stops 和 statuses。把这些部分与你计划收集的网址清单对应起来。

用八个步骤完成核对

1. 选择两到三个已知的竞品账号。为所有这些账号选择一个 UTC 窗口。UTC 是此处每个日期所使用的世界时钟。同一个时钟使较晚的帖子仍落在一个日期上。同一个窗口使比较保持公平。用繁忙的月份对比清淡的月份并不公平。示例长度：28 天，即 4 周。把结束时间写成排他的。排他表示结束瞬间在窗口之外。下一个窗口可以从同一瞬间开始。这样，一条帖子就不会同时落在两个窗口中。每个账号使用同一条纳入规则。纳入窗口内时间已知的普通公开帖子和 Reel。排除 Stories。Story 是一项存续时间很短的 Instagram 内容。这个 Actor 不收集 Stories。说明你如何处理置顶帖子。按发布日期纳入置顶帖子。不要使用它在屏幕上的位置。一条置顶可能是旧内容。
2. 手工建立网址清单。清单是你计划收集的已知内容网址列表。使用你选定的公开账号，或另一种你已经验证过的列举方法。本文不提供发现账号的方法。保存 inventory_date、账号键、内容网址和一条简短的收集备注。inventory_date 是你建立该清单的日期。只有在证据支持该标记时，才把覆盖标为 complete_for_checked_source。该标记表示已核对的来源已被覆盖。它本身并不表示整个账号历史已被覆盖。否则标为 partial/unknown。一个看起来完整的页面不是充分证据。达到上限也不是充分证据。
3. 以 contentUrls 模式发送已知内容网址。先使用较小的总上限。试点上限是 maxItems 为 3，并配三条已知网址。把每一条已保存的行与你发送的网址比较。查看 postId、账号字段、mediaType、publishedAt、status 和 statusReason。只使用当前 schema 接受的输入字段。不要添加 maxItemsPerProfile。小型试点能在长清单之前表明该路径可用。上面那条已知 Reel 是成功示例。@nike 的主页结果不是该示例。
4. 把每一个计划中的网址对应到一条已保存的行或一个缺口。把失败和不可用的输入保留在单独的清单上。把已知的 publishedAt 读作 UTC。当该时间在窗口内时，保留该行。如果 publishedAt 缺失，把该行放到未解决的侧清单上。不要把缺失的日期称为窗口之外。称为之外会藏起一条可能属于窗口之内的行。称为之内则会编造一个日期。scrapedAt 不决定窗口。带有指标的行仍可能在你的清单之外。指标并不能证明清单完整。使用像这样的对照表。用你的收集结果填写它。本文后面的日历是虚构的，不是这张表。

1. 同一条帖子只计一次。使用存在且你已核实的 postId。如果 postId 缺失，在计数该行之前复核已解析的帖子网址。缺失的标识需要复核。不要在没有备注的情况下删除它。不要把它当作确定的重复项。相同的标题或说明文字并不能证明重复。两条说明文字可能偶然相同。协作重复是同一内容 ID 被保存了不止一次。在一个账号清单内，该 ID 只计一次。保留来源行。当两行冲突时，保留一条备注。
2. 保留该行已有的 mediaType 文本。不要重命名标签。如果标签缺失，把格式保持为未知。为每个账号建立一份按日日历。建立一张格式计数表。某一天没有被纳入的行，表示那天没有被纳入的记录。只有当那天的覆盖足够好时，它才能证明该账号没有发布任何内容。如果覆盖是 partial/unknown，就写「没有被纳入的记录」。不要写什么都没有发布。
3. 用窗口内的周数去除已纳入且日期已知的帖子数。该结果是观察到的发布速率。使用这个简明公式。每周帖子数 = 已纳入且日期已知的帖子数 / 窗口内的周数。对于格式占比，把所有已纳入的帖子作为分母。占比是指一种格式在该分母中所占的部分。格式占比 = 该格式的计数 / 所有已纳入的帖子。把未知格式保留在该分母中。你也可以再做第二种组合，只使用已知格式。要说明分母已经改变。不要把任何一种组合称为最佳组合。不要把该速率称为对每个团队都最好的速率。部分清单上的速率是该清单的速率。它不是整个账号的速率。
4. 比较速率、观察到的最长间隔，以及格式组合。在每一次比较上附一条覆盖备注。把每个发布时间都保持为 UTC。两个已知日期之间的间隔是帖子间间隔。从窗口起点或窗口终点到最近一条已纳入帖子的间隔是边界间隔。把边界间隔分开保留。除非你先写下规则，否则不要把这两种间隔平均。没有规则的平均值会造出一个新数字。把一个规划问题与表格一起保存。问你的团队能否维持该排期。不要声称有多少人看到了这些帖子。不要声称同一批人关注了两个账号。不要声称你知道 Instagram 如何排列帖子。不要声称这些日期造成了更好的结果。

原创虚构中的演算示例

下面的日历是原创虚构。它用来教计数。它不是 Actor 的结果。它不是 @nike 试点。它不是那次已知 Reel 测试。这个虚构中的任何计数都不表明 Reel 更好。任何计数都不表明更高的速率更好。

虚构窗口从 2026-09-01 00:00 UTC 开始。它在 2026-09-29 00:00 UTC 结束。结束是排他的。长度是 28 天。28 / 7 = 4 周。

账号 A 有六条已纳入且日期已知的帖子。日期是 9月2日、9月5日、9月9日、9月13日、9月20日和 9月27日。四行使用标签 reel。两行使用标签 carousel。carousel 在这里是一个虚构的格式标签。它并不是在主张每一份实际使用中的标签列表都是这样。账号 A 还有一条观察到的无日期行。该行不进入这六条。

账号 B 有四条已纳入的帖子。日期是 9月3日、9月10日、9月17日和 9月24日。一行使用 reel。两行使用 image。一行没有格式标签，因此格式保持未知。账号 B 的清单只收录部分公开内容，并不是访问权限受限的清单。这里的样本是指那份只收录部分公开内容的清单。它不是科学样本。B 的速率是该清单的速率。它不是已确认的整个账号速率。

两个账号都是 partial/unknown。这个虚构不支持 complete_for_checked_source。它也不支持整个账号的完整标记。

十一条虚构行

第 7 行是无日期的侧清单行。它不是六条日期已知帖子中的一条。账号 A 的窗口总数在复核后可能改变。这个虚构没有给第 7 行一个格式。格式保持未知。

这十一行是：A 有 6 条 included，加上 A 有 1 条 unresolved，加上 B 有 4 条 included。

按周日历

第 1 周是 2026-09-01 至 2026-09-07。第 2 周是 2026-09-08 至 2026-09-14。第 3 周是 2026-09-15 至 2026-09-21。第 4 周是 2026-09-22 至 2026-09-28。2026-09-29 的结束瞬间在全部四周之外。

最后一列中的一天是一条观察到的零记录。它表示那天没有被纳入的行。它并不能证明该账号没有发布任何内容。两个账号的覆盖都是 partial/unknown。对于账号 A，9月1日没有被纳入的记录。从 9月1日到 9月2日的边界间隔是另一条备注。它不是第二条帖子。A-07 不填入任何一天。它的日期是未知，不是一个计为零的日期。

按周的格式计数

本表中的零表示那一周该格式没有被纳入的记录。它不是什么都没有发布的证明。

核对合计。账号 A 各周是 2 + 2 + 1 + 1 = 6。账号 B 各周是 1 + 1 + 1 + 1 = 4。A 的 reel 是 2 + 1 + 1 + 0 = 4。A 的 carousel 是 0 + 1 + 0 + 1 = 2。

速率、占比与覆盖

占比计算如下：

• A 的 reel：4 / 6 = 0.667，即 66.7%。
• A 的 carousel：2 / 6 = 0.333，即 33.3%。
• B 的 reel 在全部已纳入帖子中：1 / 4 = 0.25，即 25%。
• B 的 image：2 / 4 = 0.5，即 50%。
• B 的 unknown：1 / 4 = 0.25，即 25%。
• B 的已知格式是 1 条 reel + 2 条 image = 3。unknown 那一行不进入这第二种组合。
• B 的 reel 仅在已知格式中：1 / 3 = 0.333，即 33.3%。

不要把 A 的 66.7% 与 B 的 33.3% 并排放成同一种占比。A 的分母是 6 条已纳入帖子。B 的 33.3% 使用的是 3 条已知格式帖子。每次都写明分母。

间隔

账号 A 日期已知的间隔按顺序是 3、4、4、7 和 7 天。观察到的最长帖子间间隔是 7 天。

B 的帖子间间隔使用与 A 的间隔相同的减法。它们是部分清单中的间隔。它们并不能证明账号 B 在中间没有发布任何内容。A 的 7 天间隔是其已知日期中最长的间隔。除非那些天的覆盖足够好，否则它不能证明有一个空周。这个虚构没有那样的覆盖。

不要把边界间隔平均进帖子间间隔。对于账号 A，边界间隔是 1 天和 2 天。它们回答的是另一个问题。它们表示从窗口起点或窗口终点起的等待。它们不表示帖子之间的等待。

从这个虚构得出的一个规划选择

账号 A 已核对的速率是每周 1.5 条帖子。账号 B 的部分清单速率是每周 1 条帖子。无法维持 1.5 的团队不应采用 1.5。在这个虚构里，一次公平的试行是连续 4 周、每周 1 条帖子。这与 B 那份只收录部分公开内容的清单上观察到的较低发布速率一致。记录这 4 条帖子各自的格式。你可以查看 A 的组合，即 6 条已纳入帖子中有 4 行 reel。不要把该组合设为能改善结果的目标。这个虚构没有显示一种胜出的格式。询问团队能否在整个窗口内维持所选格式。如果答案是否定的，就选择更慢的排期。然后在接下来的 28 天重复相同的窗口规则。