Michael Johnson根据单个主页快照比较两位 IG 创作者很容易；但要了解谁能持续发布内容，以及帖子如何随着时间推移获得互动，就没那么简单了。一次性检查会把不同发布时长的帖子混在一起，手动表格也很快就会过时。实用的做法是定期收集公开媒体内容，将每次响应作为独立观测保存，并基于自己的数据计算变化。
下面介绍一套可行方案，适用于需要每周比较同一领域内公开账号的营销人员、分析师或开发者。数据通过 jsonscraper 的 IG Scraper API 获取；Python 则负责安排任务、规范化数据并保存历史记录。这是对主页和竞品帖子监测主题的延伸：重点在于建立统一的观测模型，以便生成对比报告。
先明确要比较什么
这类任务通常会被宽泛地描述为“寻找高效的创作者”。要开展有技术依据的监测，不妨将问题缩小到可衡量的指标：帖子发布频率、出现的内容形式、检查时可见的公开点赞数和评论数，以及这些数值在发布后如何变化。这样的指标组合有助于筛选值得人工研究的账号，或准备对比摘要。
公开计数器是请求时刻的快照。因此，架构上的关键决策不是采用复杂模型，而是将采集时间与数值一起保存。如果每晚获取同一条媒体内容的信息后覆盖旧记录，就会丢失计算增量所需的历史数据。应改为不可变地保存观测：每条帖子在每个采集时间对应一行记录。
比较时应限定相同的时间段，并选择可比的帖子。例如，可以查看同一自然月内首次发现的帖子，或考虑每次快照时帖子的发布时长。否则，昨天发布的短视频看起来会比旧帖子表现差，原因可能只是它积累互动的时间较短。
流程：请求、规范化、历史记录
最简流程包含四个步骤：获取所选主页的公开媒体列表，将响应转换为统一结构，把记录写入存储，并按计划生成报告。IG Scraper API 页面展示了基础 URL 和端点图，其中包括用于分块获取用户帖子的路由。集成之前，请在 Postman 集合中核对各路由的参数和响应示例。
API 基础 URL 为 https://ig.jsonscraper.com。对于初步检查，文档展示了按用户名查询主页的请求：GET /v1/user/by/username，并在已发布的示例中使用了 username、license_key 和 cache_timeout 参数。获取帖子的路由为 GET /v1/user/medias/chunk。该路由的准确参数、续传字段和响应结构应以对应请求的文档为准；不要把一个路由的结构套用到另一个路由上。
import os
import requests
BASE = "https://ig.jsonscraper.com"
KEY = os.environ["JSONSCRAPER_LICENSE_KEY"]
def get_profile(username: str) -> dict:
response = requests.get(
f"{BASE}/v1/user/by/username",
params={
"username": username,
"license_key": KEY,
"cache_timeout": 60,
},
timeout=30,
)
response.raise_for_status()
return response.json()
print(get_profile("example_account"))
这个简短示例复现了文档中的主页查询路由，并展示如何通过 HTTP GET 传递参数。已发布示例中包含 cache_timeout=60；仅在支持该参数的路由上使用，并根据文档核对具体细节。密钥应存放在环境变量中，而不是代码或浏览器应用里。
接入帖子获取功能
确认主页查询正常后，添加媒体列表请求。API 页面列出了 GET /v1/user/medias/chunk；处理结果时应使用文档规定的分块逻辑。参数名称和分页结束条件应查阅 Postman 中该请求的最新说明，而不是根据路由名称猜测。
下面是传输请求的框架，并非完整的端点契约：运行前，请将文档明确列出的参数填入 params。收到响应后，适配器只能读取所选路由实际返回的 JSON 中已确认存在的字段。
def fetch_media_chunk(username: str, params: dict) -> dict:
query = {
**params,
"username": username,
"license_key": KEY,
}
response = requests.get(
f"{BASE}/v1/user/medias/chunk",
params=query,
timeout=30,
)
response.raise_for_status()
return response.json()
接下来编写适配函数，将响应转换为内部格式。分析时可能需要帖子的稳定标识符、作者、链接、发布时间、媒体类型，以及可获取的公开计数器。请根据文档和 JSON 示例核对字段的准确名称和类型。如果某项指标缺失，应将其保存为空值，而不是填入零：零表示测得的计数为零，空值则表示没有数据。
def normalize_media(item: dict, username: str, observed_at: str) -> dict:
# 仅在核对所选端点的 JSON 后填写对应键名。
return {
"username": username,
"media_id": item.get("DOCUMENTED_MEDIA_ID_KEY"),
"media_url": item.get("DOCUMENTED_MEDIA_URL_KEY"),
"published_at": item.get("DOCUMENTED_PUBLISHED_AT_KEY"),
"media_type": item.get("DOCUMENTED_MEDIA_TYPE_KEY"),
"likes": item.get("DOCUMENTED_LIKE_COUNT_KEY"),
"comments": item.get("DOCUMENTED_COMMENT_COUNT_KEY"),
"observed_at": observed_at,
}
请将占位字段名替换为具体端点响应中的准确键名，并使用已保存的 JSON 样本为映射添加测试。这样，集成更新时就能及时发现结构变化，也能避免示例把未经确认的字段名误当成已证实的契约。
保存观测记录，而不只是当前值
原型可以使用 CSV；常规运行则可选择 PostgreSQL、Supabase 或分析型数据仓库。观测表可以包含 username、media_id、published_at、observed_at、likes、comments 和原始 JSON 等字段。media_id 与 observed_at 的组合可唯一标识一个快照。另建一张主页表，用于保存正在监测的账号列表及其加入监测的日期。
保存原始响应有助于排查问题和重新构建规范化数据。应根据项目目标和组织规则设定保留期限，控制表格访问权限，并避免收集分析所不需要的信息。对于 CRM 和直接营销活动，还应单独明确适用的法律依据：技术上能够获取公开数据，并不能解决这个问题。
CREATE TABLE media_observations (
username TEXT NOT NULL,
media_id TEXT NOT NULL,
media_url TEXT,
published_at TIMESTAMPTZ,
observed_at TIMESTAMPTZ NOT NULL,
media_type TEXT,
likes BIGINT,
comments BIGINT,
raw_json JSONB,
PRIMARY KEY (media_id, observed_at)
);
成功验证响应后，再批量添加记录。重复运行同一任务时，主键组合可以防止意外创建重复快照；应用程序可以使用遇到冲突时跳过的插入方式。在不同时间再次运行则会保存为独立行，从而延续时间序列。
计算能回答问题的指标
衡量发布节奏的基础指标，是账号在指定时间段内发布的不同媒体数量。如果 published_at 字段存在且解析正确，就能轻松统计。评估公开互动变化时，应比较同一个 media_id 的两次观测：点赞数的绝对变化等于较晚的计数减去较早的计数；相对变化则是该差值除以较早的数值。评论数也采用相同的计算方法。
如果较早的数值为零或缺失，则相对增长率没有定义；应显示绝对差值，并明确说明缺少计算百分比所需的基准。计数器可能在两次观测之间发生变化，因此报告应标明快照间隔和最近一次采集时间。这些细节能帮助读者正确解读数据。
def growth(previous, current):
if previous is None or current is None:
return {"delta": None, "rate": None}
delta = current - previous
rate = None if previous == 0 else delta / previous
return {"delta": delta, "rate": rate}
不要在没有明确权重依据的情况下，将账号压缩成一个排名。实用的报告通常会并列显示帖子数量、每帖点赞数和评论数的中位数、内容形式分布，以及在相同发布时长下的互动变化。中位数能减少个别异常帖子的影响；帖子数量则说明比较所依据的样本规模。
可以通过两种方式考虑帖子的发布时长。第一种是定期采集计数器，例如在首次发现媒体内容后，每隔相同时间采集一次。第二种是比较处于相同时间范围内的帖子，并使用发布时长大致相同的观测数据。如果计划任务有遗漏，不要把实际变化说成准确的单日增幅；应根据时间戳计算实际间隔。
自动运行并进行质量控制
可以通过 cron、GitHub Actions 或 ETL 编排工具按计划运行采集。任务流程很简单：读取账号列表、请求所需数据块、检查 HTTP 状态和响应结构、规范化数据、保存快照，并记录运行日志。每次运行都应记录已处理的账号数、媒体数、错误和耗时，以便区分真实的活跃度变化与采集故障。
对于临时错误，可采用有限次数的重试并设置等待时间；如果响应出错，应保存请求上下文，但不要记录密钥。不要让游标进入无限循环：应根据端点响应中说明的结束条件停止。如果文档规定了使用限制或规则，就应据此设置采集频率和样本规模。
IG API 页面指出，受支持的路由可以使用 cache_timeout 参数。如果短时间内重复请求无法带来额外价值，使用缓存会很有帮助；对于变化追踪，应选择符合分析问题的采集间隔。例如，若目标是每周回顾，每日快照会比在没有明确任务的情况下频繁重复请求相同主页更合适。
在启用定期运行之前，先用小规模样本进行测试。保存响应样本，核对标识符和日期，将规范化字段与原始 JSON 对照，并手动检查若干行。还应针对缺失值、空列表和意外格式添加测试。API 发生变化时，这些检查能比一份不一致的周报更早发现问题。
AI 在这里能发挥什么作用
AI 适合用于最后一步：简要描述已经计算出的结果。向模型提供聚合数据和帖子链接，而不是整个原始档案；例如，提供每周媒体数量、公开互动的中位数，以及指定时间段内变化最大的帖子列表。请模型概述观察结果，并附上对应的数据记录标识符。
指标计算最好交给常规代码完成，以确保同一规则能够产生可复现的结果。模型可以撰写文字摘要、按预设主题对说明文字分类，或提出供人工核查的问题。进行主题分类时，应将模型标签与原始说明文字分开保存，并注明指令或分类器版本，以免后续更改在不知不觉中改写历史记录。
不要把自动报告变成对具体人员进行招聘、签约或评价的自动决策。应将公开数据用于范围有限的内容分析，并在结论影响商业决策时进行人工核查。这样既能保留监测的实用价值，也能将可测量的计数器与解释区分开来。
结果是什么样的
经过几个采集周期后，就会得到一张表格，显示每条帖子何时被发现、每次观测时获得了多少互动，以及指标如何变化。每周摘要可以回答一些实际问题：谁保持规律发布、哪些内容形式使用得更频繁、哪些帖子在可比的快照之间获得了更多互动，以及哪些地方的数据仍不足以支持可靠比较。
这个流程有助于用可重复的研究取代偶发的人工检查，但不能替代对内容的定性分析：指标描述的是发布频率和可获取的公开互动数据；内容含义、受众和品牌契合度则需要另行评估。不过，固定的采集安排、保存的历史记录和明确的计算逻辑，能让这些评估可供核查，也便于团队使用。
开始时，先打开 IG Scraper API 页面，在 Postman 文档中核对帖子路由参数，然后用测试账号实现适配器并保存第一份快照。确认数据结构后，再添加定时任务、错误控制和所选指标的报告。