Michael JohnsonСравнить двух IG-креаторов по одному снимку профиля легко; понять, кто стабильно публикует контент и какие посты набирают реакции со временем, сложнее. Разовые проверки смешивают публикации разного возраста, а ручная таблица быстро устаревает. Практичное решение — собирать публичные медиа по расписанию, хранить каждый ответ как отдельное наблюдение и считать изменения на собственных данных.
Ниже — рабочая схема для маркетолога, аналитика или разработчика, которому нужно еженедельно сравнивать публичные аккаунты в одной нише. Для получения данных используется IG Scraper API от jsonscraper; Python отвечает за расписание, нормализацию и сохранение истории. Это продолжение темы мониторинга профилей и конкурирующих публикаций: здесь фокус на единой модели наблюдений, пригодной для сравнительного отчёта.
Сначала определите, что именно сравнивать
Задача обычно формулируется широко: «найти эффективных креаторов». Для технически полезного мониторинга её стоит сузить до измеримых вопросов: как часто выходят публикации, какие форматы появляются, сколько публичных лайков и комментариев видно при проверке, и как эти числа меняются после публикации. Такой набор помогает отбирать аккаунты для ручного изучения или готовить сравнительную сводку.
Публичные счётчики — снимки на момент запроса. Поэтому ключевое решение в архитектуре не сложная модель, а сохранение времени сбора вместе со значением. Если каждую ночь получать сведения о том же медиа и перезаписывать предыдущую строку, исчезает история, нужная для расчёта прироста. Вместо этого храните наблюдения неизменяемо: одна строка на публикацию и время сбора.
Сравнение следует ограничить одинаковыми периодами и сопоставимыми публикациями. Например, можно смотреть публикации, впервые замеченные в одном календарном месяце, или учитывать возраст публикации на каждом снимке. Иначе вчерашний ролик будет выглядеть слабее старого поста просто потому, что у него было меньше времени на накопление реакций.
Пайплайн: запрос, нормализация, история
В минимальной версии процесс состоит из четырёх шагов: получить список публичных медиа выбранных профилей, привести ответ к общей схеме, записать строки в хранилище и сформировать отчёт по расписанию. Страница IG Scraper API показывает базовый адрес и карту endpoint, включая маршрут пользователя для чанковой выдачи публикаций. Параметры каждого маршрута и примеры ответа проверяйте в коллекции Postman перед интеграцией.
Базовый адрес API — 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, а не угадывать по названию маршрута.
Ниже — каркас транспортного вызова, а не готовый контракт endpoint: перед запуском заполните 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 выбранного endpoint.
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,
}
Замените имена-заполнители точными ключами из ответа конкретного endpoint и закрепите маппинг тестом на сохранённом образце 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-статус и структуру ответа, нормализовать данные, сохранить снимок и записать журнал выполнения. Для каждого запуска фиксируйте число обработанных аккаунтов, медиа, ошибки и длительность — это поможет отличить реальное изменение активности от сбоя сбора.
Для временных ошибок применяйте ограниченное число повторов с паузой, а для ответа с ошибкой сохраняйте контекст запроса без секретного ключа. Не запускайте бесконечный цикл по курсорам: остановка должна происходить по условиям завершения, указанным в ответе endpoint. Если документация задаёт лимиты или правила использования, настройте частоту и размер выборки в соответствии с ними.
Параметр cache_timeout указан на странице IG API для поддерживаемых маршрутов. Кэш полезен, когда повторный запрос в коротком окне не добавляет ценности; для отслеживания изменений выберите интервал сбора, соответствующий аналитическому вопросу. Например, ежедневный снимок лучше отвечает на недельный обзор, чем частые повторные запросы к тем же профилям без конкретной задачи.
До включения регулярного расписания протестируйте небольшую выборку. Сохраните образец ответа, проверьте идентификаторы и даты, сравните нормализованные поля с исходным JSON и вручную проверьте несколько строк. Добавьте тесты на отсутствующие значения, пустые списки и неожиданный формат. При изменении API такие проверки быстрее обнаружат проблему, чем несогласованный отчёт в конце недели.
Где здесь полезен ИИ
ИИ уместен на последнем этапе — для краткого описания уже рассчитанных результатов. Передавайте модели агрегаты и ссылки на публикации, а не весь сырой архив: например, число медиа по неделям, медианные публичные реакции и список публикаций с наибольшим изменением за заданный интервал. Попросите модель сформулировать наблюдения и приложить идентификаторы записей, из которых они получены.
Расчёт метрик лучше оставить обычному коду, чтобы одно и то же правило давало воспроизводимый результат. Модель может подготовить текстовую сводку, сгруппировать подписи по заранее заданным темам или предложить вопросы для ручной проверки. Для тематической классификации храните метку модели отдельно от исходной подписи и указывайте версию инструкции или классификатора, чтобы последующие изменения не переписывали историю незаметно.
Не превращайте автоматический отчёт в автоматическое решение о найме, контракте или оценке конкретного человека. Используйте публичные данные для ограниченного анализа контента и проверяйте выводы вручную, особенно когда они влияют на деловые решения. Это сохраняет полезность мониторинга и отделяет измеряемые счётчики от интерпретации.
Как выглядит результат
После нескольких циклов сбора появится таблица, в которой видно, когда обнаружена каждая публикация, сколько реакций было при каждом наблюдении и как менялись показатели. Еженедельная сводка сможет ответить на прикладные вопросы: кто публиковал регулярно, какие форматы чаще использовались, какие публикации набирали реакции между сравнимыми снимками и где данных для уверенного сравнения пока мало.
Такой процесс помогает заменить эпизодические ручные проверки повторяемым исследованием. Он не подменяет качественный анализ содержания: метрики описывают частоту публикаций и доступные публичные реакции, а смысл, аудитория и соответствие бренду требуют отдельной оценки. Зато одинаковое расписание, сохранённая история и явная логика расчётов делают эти оценки проверяемыми и пригодными для команды.
Для старта откройте страницу IG Scraper API, проверьте параметры маршрута публикаций в документации Postman, затем реализуйте адаптер на тестовом аккаунте и сохраните первый снимок. Когда схема подтверждена, добавьте расписание, контроль ошибок и отчёт по выбранным метрикам.