Jak oceniać twórców na IGie na podstawie dynamiki publikacji: praktyczny pipeline w Pythonie

Porównanie dwóch twórców na IGie na podstawie pojedynczej migawki profilu jest łatwe; trudniej ustalić, kto regularnie publikuje treści i które posty z czasem zdobywają reakcje. Jednorazowe sprawdzenia mieszają publikacje w różnym wieku, a ręczny arkusz szybko się dezaktualizuje. Praktyczne rozwiązanie to regularne zbieranie publicznych materiałów, zapisywanie każdej odpowiedzi jako osobnej obserwacji i obliczanie zmian na podstawie własnych danych.

Poniżej znajduje się praktyczny schemat dla marketera, analityka lub programisty, który chce co tydzień porównywać publiczne konta z tej samej niszy. Do pobierania danych służy IG Scraper API firmy jsonscraper; Python odpowiada za harmonogram, normalizację i przechowywanie historii. To rozwinięcie tematu monitorowania profili i konkurencyjnych publikacji: koncentruje się na jednolitym modelu obserwacji, który można wykorzystać w raporcie porównawczym.

Najpierw określ, co chcesz porównywać

Cel często formułuje się szeroko: „znaleźć skutecznych twórców”. Warto zawęzić go do mierzalnych pytań, które przydadzą się w monitoringu technicznym: jak często pojawiają się publikacje, jakie formaty są wykorzystywane, ile publicznych polubień i komentarzy widać podczas sprawdzania oraz jak te wartości zmieniają się po publikacji. Taki zestaw pomaga wybrać konta do ręcznej analizy lub przygotować zestawienie porównawcze.

Publiczne liczniki to migawki z chwili wysłania zapytania. Dlatego kluczową decyzją architektoniczną nie jest złożony model, lecz zapisywanie czasu pobrania razem z wartością. Jeśli każdej nocy pobierasz dane o tym samym materiale i nadpisujesz poprzedni wiersz, tracisz historię potrzebną do obliczenia przyrostu. Zamiast tego zapisuj obserwacje w sposób niezmienny: jeden wiersz dla publikacji i czasu pobrania.

Porównanie powinno obejmować takie same okresy i porównywalne publikacje. Możesz na przykład analizować publikacje zauważone po raz pierwszy w tym samym miesiącu kalendarzowym albo uwzględniać wiek publikacji przy każdej migawce. W przeciwnym razie wczorajszy film będzie wyglądać słabiej niż stary post tylko dlatego, że miał mniej czasu na zgromadzenie reakcji.

Pipeline: zapytanie, normalizacja, historia

Minimalny proces składa się z czterech kroków: pobrania listy publicznych materiałów z wybranych profili, przekształcenia odpowiedzi do wspólnego schematu, zapisania wierszy w magazynie danych i wygenerowania raportu zgodnie z harmonogramem. Strona IG Scraper API przedstawia podstawowy adres i mapę endpointów, w tym trasę użytkownika do stronicowanego pobierania publikacji. Przed integracją sprawdź parametry poszczególnych tras i przykłady odpowiedzi w kolekcji Postman.

Podstawowy adres API to https://ig.jsonscraper.com. Do wstępnego sprawdzenia dokumentacja pokazuje zapytanie o profil według nazwy użytkownika: GET /v1/user/by/username z parametrami username, license_key i cache_timeout w opublikowanym przykładzie. Do pobierania publikacji wskazano trasę GET /v1/user/medias/chunk. Dokładne argumenty tej trasy, pola kontynuacji i strukturę odpowiedzi należy sprawdzić w dokumentacji tego konkretnego zapytania; nie przenoś schematu z jednej trasy na drugą.

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"))

Ten krótki przykład odtwarza udokumentowaną trasę profilu i pokazuje przekazywanie parametrów przez HTTP GET. Wartość cache_timeout=60 występuje w opublikowanym przykładzie; stosuj ją tylko na trasach, które obsługują ten parametr, i sprawdzaj szczegóły w dokumentacji. Klucz przechowuj w zmiennej środowiskowej, a nie w kodzie ani aplikacji przeglądarkowej.

Dodaj pobieranie publikacji

Po sprawdzeniu profilu dodaj zapytanie o listę materiałów. Strona API wymienia trasę GET /v1/user/medias/chunk; do przetwarzania wyniku zastosuj logikę stronicowania opisaną w dokumentacji. Nazwy parametrów i warunek zakończenia paginacji należy zaczerpnąć z aktualnego opisu tego zapytania w Postmanie, zamiast zgadywać na podstawie nazwy trasy.

Poniżej znajduje się szkielet wywołania transportowego, a nie gotowy kontrakt endpointu: przed uruchomieniem uzupełnij params o udokumentowane argumenty. Po otrzymaniu odpowiedzi adapter powinien odczytywać wyłącznie te pola, których obecność potwierdza rzeczywisty JSON dla wybranej trasy.

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()

Następnie napisz funkcję-adapter, która przekształci odpowiedź do wewnętrznego formatu. W analizie mogą przydać się stabilny identyfikator publikacji, autor, link, data publikacji, typ materiału i dostępne publiczne liczniki. Sprawdź dokładne nazwy i typy pól w dokumentacji oraz przykładzie JSON. Jeśli metryki brakuje, zapisz pustą wartość, zamiast podstawiać zero: zero oznacza zmierzony licznik równy zeru, a pusta wartość — brak danych.

def normalize_media(item: dict, username: str, observed_at: str) -> dict:
    # Podaj klucze dopiero po sprawdzeniu JSON wybranego endpointu.
    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,
    }

Zastąp nazwy-zastępniki dokładnymi kluczami z odpowiedzi konkretnego endpointu i zabezpiecz mapowanie testem opartym na zapisanym przykładzie JSON. Dzięki temu zmiana schematu będzie widoczna podczas aktualizacji integracji, a przykład nie będzie przedstawiał przypuszczalnych nazw pól jako potwierdzonego kontraktu.

Przechowuj obserwacje, a nie tylko bieżące wartości

Do prototypu wystarczy CSV, a do regularnej pracy — PostgreSQL, Supabase lub magazyn analityczny. Tabela obserwacji może zawierać pola username, media_id, published_at, observed_at, likes, comments i surowy JSON. Para media_id oraz observed_at identyfikuje unikalną migawkę. Osobna tabela profili przechowuje listę monitorowanych kont i datę dodania ich do monitoringu.

Przechowywanie surowej odpowiedzi przydaje się podczas debugowania i ponownego tworzenia znormalizowanych danych. Ogranicz czas przechowywania stosownie do celu projektu i zasad organizacji, kontroluj dostęp do tabel i nie zbieraj informacji, które nie są potrzebne do wybranej analizy. W przypadku CRM i bezpośrednich działań marketingowych osobno ustal właściwą podstawę prawną: sama techniczna dostępność publicznych danych nie rozstrzyga tej kwestii.

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)
);

Dodawaj rekordy zbiorczo po pomyślnym sprawdzeniu odpowiedzi. Przy ponownym uruchomieniu tego samego zadania złożony klucz główny zapobiegnie przypadkowemu utworzeniu zduplikowanej migawki; w aplikacji można użyć wstawiania z pominięciem konfliktu. Nowe uruchomienie o innej porze zapisze osobny wiersz i uzupełni szereg czasowy.

Obliczaj metryki, które odpowiadają na pytanie

Podstawową miarą tempa publikowania jest liczba unikalnych materiałów z konta w wybranym okresie. Łatwo ją obliczyć na podstawie published_at, jeśli to pole istnieje i jest poprawnie rozpoznawane. Aby ocenić zmianę publicznych reakcji, porównaj dwie obserwacje tego samego media_id: bezwzględna zmiana liczby polubień to późniejszy licznik minus wcześniejszy, a zmiana względna to ta różnica podzielona przez wcześniejszą wartość. Tak samo oblicza się zmianę liczby komentarzy.

Jeśli wcześniejsza wartość wynosi zero lub jej brakuje, względny przyrost jest nieokreślony; pokaż różnicę bezwzględną i wyraźnie zaznacz, że nie ma podstawy do obliczenia procentu. Liczniki mogą zmieniać się między obserwacjami, dlatego raport powinien podawać odstęp między migawkami i czas ostatniego pobrania. Te informacje pomagają prawidłowo zinterpretować liczby.

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}

Nie sprowadzaj kont do jednego rankingu bez uzasadnionych wag. Praktyczny raport zwykle pokazuje obok siebie liczbę publikacji, medianę polubień i komentarzy na publikację, rozkład formatów oraz zmianę reakcji w porównywalnym przedziale wieku publikacji. Mediana ogranicza wpływ pojedynczego odstającego posta; liczba publikacji pokazuje wielkość próby, na której opiera się porównanie.

Wiek publikacji można uwzględnić na dwa sposoby. Pierwszy polega na regularnym rejestrowaniu liczników, na przykład w jednakowych odstępach od pierwszego wykrycia materiału. Drugi to porównywanie publikacji mieszczących się w tym samym przedziale czasowym, na podstawie obserwacji wykonanych mniej więcej w tym samym wieku. Jeśli harmonogram pominie uruchomienie, nie przedstawiaj rzeczywistej dynamiki jako dokładnego przyrostu dobowego: oblicz odstęp na podstawie znaczników czasu.

Zautomatyzuj uruchamianie i kontrolę jakości

Uruchamiaj pobieranie według harmonogramu za pomocą crona, GitHub Actions lub orkiestratora ETL. Kolejność kroków jest prosta: odczytaj listę kont, pobierz potrzebne fragmenty, sprawdź status HTTP i strukturę odpowiedzi, znormalizuj dane, zapisz migawkę i zarejestruj przebieg zadania. Dla każdego uruchomienia zapisuj liczbę przetworzonych kont i materiałów, błędy oraz czas trwania — pomoże to odróżnić rzeczywistą zmianę aktywności od awarii procesu pobierania.

W przypadku błędów przejściowych stosuj ograniczoną liczbę ponowień z przerwą, a przy odpowiedzi z błędem zapisuj kontekst zapytania bez tajnego klucza. Nie uruchamiaj nieskończonej pętli po kursorach: zatrzymanie powinno następować zgodnie z warunkami zakończenia wskazanymi w odpowiedzi endpointu. Jeśli dokumentacja określa limity lub zasady korzystania z usługi, dostosuj do nich częstotliwość i wielkość pobieranej próbki.

Parametr cache_timeout jest wymieniony na stronie IG API dla obsługiwanych tras. Pamięć podręczna jest przydatna, gdy kolejne zapytanie w krótkim odstępie nie wnosi wartości; dobierz częstotliwość pobierania do pytania analitycznego. Na przykład migawka dobowa lepiej sprawdzi się w cotygodniowym przeglądzie niż częste ponowne zapytania o te same profile bez konkretnego celu.

Przed włączeniem regularnego harmonogramu przetestuj małą próbkę. Zapisz przykładową odpowiedź, sprawdź identyfikatory i daty, porównaj znormalizowane pola z oryginalnym JSON-em i ręcznie zweryfikuj kilka wierszy. Dodaj testy dla brakujących wartości, pustych list i nieoczekiwanego formatu. Po zmianie API takie kontrole szybciej wykryją problem niż niespójny raport pod koniec tygodnia.

Gdzie przydaje się AI

AI ma zastosowanie na końcowym etapie — do krótkiego opisu już obliczonych wyników. Przekazuj modelowi agregaty i linki do publikacji, a nie całe surowe archiwum: na przykład tygodniową liczbę materiałów, medianę publicznych reakcji oraz listę publikacji o największej zmianie w wyznaczonym okresie. Poproś model o sformułowanie obserwacji i dołączenie identyfikatorów rekordów, na których się opierają.

Obliczanie metryk lepiej pozostawić zwykłemu kodowi, aby ta sama reguła dawała powtarzalny wynik. Model może przygotować podsumowanie tekstowe, pogrupować podpisy według z góry określonych tematów lub zaproponować pytania do ręcznej weryfikacji. W przypadku klasyfikacji tematycznej przechowuj etykietę modelu osobno od oryginalnego podpisu i zapisuj wersję instrukcji lub klasyfikatora, aby późniejsze zmiany nie nadpisywały niepostrzeżenie historii.

Nie przekształcaj automatycznego raportu w automatyczną decyzję o zatrudnieniu, umowie lub ocenie konkretnej osoby. Wykorzystuj dane publiczne do ograniczonej analizy treści i ręcznie weryfikuj wnioski, zwłaszcza gdy mają wpływ na decyzje biznesowe. Dzięki temu monitoring pozostaje użyteczny, a mierzalne liczniki są oddzielone od interpretacji.

Jak wygląda wynik

Po kilku cyklach zbierania danych powstanie tabela pokazująca, kiedy wykryto każdą publikację, ile reakcji miała w poszczególnych obserwacjach i jak zmieniały się wskaźniki. Cotygodniowe zestawienie będzie mogło odpowiedzieć na praktyczne pytania: kto publikował regularnie, które formaty były częściej wykorzystywane, które publikacje zdobywały reakcje między porównywalnymi migawkami oraz gdzie nadal brakuje danych do wiarygodnego porównania.

Taki proces pozwala zastąpić sporadyczne ręczne sprawdzanie powtarzalnym badaniem. Nie zastępuje jakościowej analizy treści: metryki opisują częstotliwość publikacji i dostępne publiczne reakcje, a znaczenie, odbiorcy i dopasowanie do marki wymagają osobnej oceny. Jednak stały harmonogram, zachowana historia i jawna logika obliczeń sprawiają, że te oceny można zweryfikować i wykorzystać w pracy zespołu.

Aby rozpocząć, otwórz stronę IG Scraper API, sprawdź parametry trasy publikacji w dokumentacji Postman, a następnie zaimplementuj adapter na koncie testowym i zapisz pierwszą migawkę. Gdy schemat zostanie potwierdzony, dodaj harmonogram, obsługę błędów i raport z wybranymi metrykami.