Як оцінювати креаторів IG за динамікою публікацій: практичний пайплайн на Python

Порівняти двох креаторів 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, а потім реалізуйте адаптер на тестовому акаунті й збережіть перший знімок. Коли схему буде підтверджено, додайте розклад, контроль помилок і звіт за вибраними метриками.