IG-Creator anhand ihrer Veröffentlichungsdynamik bewerten: eine praktische Python-Pipeline

Zwei IG-Creator anhand eines einzelnen Profil-Snapshots zu vergleichen, ist einfach; zu erkennen, wer regelmäßig Inhalte veröffentlicht und welche Beiträge im Laufe der Zeit Reaktionen erhalten, ist schwieriger. Einzelne Prüfungen vermischen Beiträge unterschiedlichen Alters, und eine manuelle Tabelle veraltet schnell. Eine praktikable Lösung besteht darin, öffentliche Medien regelmäßig zu erfassen, jede Antwort als separate Beobachtung zu speichern und Veränderungen anhand eigener Daten zu berechnen.

Im Folgenden finden Sie einen praktischen Ablauf für Marketingfachleute, Analysten oder Entwickler, die öffentliche Konten derselben Nische wöchentlich vergleichen möchten. Für den Datenabruf kommt die IG Scraper API von jsonscraper zum Einsatz; Python übernimmt die Zeitplanung, Normalisierung und Speicherung des Verlaufs. Der Beitrag knüpft an das Thema Profil- und Konkurrenzbeobachtung an und konzentriert sich auf ein einheitliches Beobachtungsmodell für vergleichende Berichte.

Legen Sie zuerst fest, was Sie vergleichen möchten

Die Aufgabe wird oft allgemein formuliert: „effektive Creator finden“. Für ein technisch aussagekräftiges Monitoring sollten Sie sie auf messbare Fragen eingrenzen: Wie häufig erscheinen Beiträge, welche Formate werden veröffentlicht, wie viele öffentliche Likes und Kommentare sind bei der Erfassung sichtbar, und wie verändern sich diese Zahlen nach der Veröffentlichung? Damit lassen sich Konten für eine manuelle Prüfung auswählen oder vergleichende Übersichten erstellen.

Öffentliche Zähler sind Momentaufnahmen zum Zeitpunkt der Anfrage. Die entscheidende Architekturfrage ist daher kein komplexes Modell, sondern die Speicherung des Erfassungszeitpunkts zusammen mit dem Wert. Wenn Sie jede Nacht Informationen zu denselben Medien abrufen und die vorherige Zeile überschreiben, geht der für die Berechnung des Zuwachses benötigte Verlauf verloren. Speichern Sie Beobachtungen stattdessen unveränderlich: eine Zeile pro Beitrag und Erfassungszeitpunkt.

Beschränken Sie den Vergleich auf dieselben Zeiträume und vergleichbare Beiträge. Sie können beispielsweise Beiträge betrachten, die erstmals im selben Kalendermonat entdeckt wurden, oder das Alter eines Beitrags bei jeder Momentaufnahme berücksichtigen. Andernfalls wirkt ein Video von gestern allein deshalb schwächer als ein älterer Beitrag, weil es weniger Zeit hatte, Reaktionen zu sammeln.

Die Pipeline: Anfrage, Normalisierung, Verlauf

In der Minimalversion umfasst der Ablauf vier Schritte: eine Liste öffentlicher Medien der ausgewählten Profile abrufen, die Antwort in ein gemeinsames Schema überführen, Zeilen im Speicher ablegen und nach Zeitplan einen Bericht erstellen. Die Seite zur IG Scraper API zeigt die Basis-URL und eine Übersicht der Endpunkte, darunter eine Benutzerroute für die seitenweise Ausgabe von Beiträgen. Prüfen Sie die Parameter jeder Route und die Antwortbeispiele vor der Integration in der Postman-Sammlung.

Die Basis-URL der API lautet https://ig.jsonscraper.com. Für eine erste Prüfung zeigt die Dokumentation eine Profilabfrage anhand des Benutzernamens: GET /v1/user/by/username mit den Parametern username, license_key und cache_timeout im veröffentlichten Beispiel. Für den Abruf von Beiträgen ist die Route GET /v1/user/medias/chunk angegeben. Übernehmen Sie die genauen Argumente, Fortsetzungsfelder und die Antwortstruktur aus der Dokumentation zu genau dieser Anfrage; übertragen Sie kein Schema von einer Route auf eine andere.

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

Dieses kurze Beispiel entspricht der dokumentierten Profilroute und zeigt, wie Parameter per HTTP GET übergeben werden. Der Wert cache_timeout=60 ist im veröffentlichten Beispiel enthalten; verwenden Sie ihn nur für Routen, die den Parameter unterstützen, und gleichen Sie die Details mit der Dokumentation ab. Speichern Sie den Schlüssel in einer Umgebungsvariable, nicht im Code oder in einer Browseranwendung.

Rufen Sie Beiträge ab

Ergänzen Sie nach der Profilprüfung eine Anfrage an die Medienliste. Die API-Seite führt GET /v1/user/medias/chunk auf; verarbeiten Sie das Ergebnis mit der in der Dokumentation vorgesehenen seitenweisen Logik. Die Parameternamen und die Abbruchbedingung der Paginierung müssen Sie der aktuellen Beschreibung dieser Anfrage in Postman entnehmen, statt sie anhand des Routennamens zu erraten.

Das folgende Beispiel ist ein Gerüst für den Transportaufruf, kein fertiger Endpunktvertrag: Ergänzen Sie vor der Ausführung params um die dokumentierten Argumente. Nach dem Abruf sollte ein Adapter nur jene Felder auslesen, die durch das tatsächliche JSON für die gewählte Route bestätigt sind.

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

Schreiben Sie anschließend eine Adapterfunktion, die die Antwort in ein internes Format überführt. Für die Analyse können eine stabile Beitrags-ID, der Autor, der Link, das Veröffentlichungsdatum, der Medientyp und verfügbare öffentliche Zähler nützlich sein. Prüfen Sie die genauen Feldnamen und Datentypen anhand der Dokumentation und eines JSON-Beispiels. Fehlt eine Kennzahl, speichern Sie einen leeren Wert, statt null einzusetzen: Null bedeutet, dass ein Zählerstand von null gemessen wurde, ein leerer Wert bedeutet, dass keine Daten vorliegen.

def normalize_media(item: dict, username: str, observed_at: str) -> dict:
    # Tragen Sie Schlüssel erst ein, nachdem Sie das JSON des gewählten Endpunkts geprüft haben.
    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,
    }

Ersetzen Sie die Platzhalternamen durch die genauen Schlüssel aus der Antwort des jeweiligen Endpunkts und sichern Sie die Zuordnung mit einem Test anhand eines gespeicherten JSON-Beispiels ab. So fällt eine Schemaänderung bei der Aktualisierung der Integration auf, und das Beispiel stellt keine vermuteten Feldnamen fälschlich als bestätigten Vertrag dar.

Speichern Sie Beobachtungen statt nur aktueller Werte

Für einen Prototyp eignet sich CSV, für den regelmäßigen Betrieb PostgreSQL, Supabase oder ein Analyse-Data-Warehouse. Eine Beobachtungstabelle kann die Felder username, media_id, published_at, observed_at, likes, comments und das unverarbeitete JSON enthalten. Das Paar media_id und observed_at kennzeichnet eine eindeutige Momentaufnahme. Eine separate Profiltabelle enthält die Liste der überwachten Konten und das Datum, an dem sie ins Monitoring aufgenommen wurden.

Das Speichern der unverarbeiteten Antwort ist bei der Fehlersuche und beim erneuten Aufbau normalisierter Daten hilfreich. Begrenzen Sie die Aufbewahrungsdauer entsprechend dem Projektzweck und den Organisationsregeln, kontrollieren Sie den Tabellenzugriff und erfassen Sie keine Informationen, die für die gewählte Analyse nicht erforderlich sind. Legen Sie für CRM und direkte Marketingmaßnahmen gesondert die anwendbare Rechtsgrundlage fest: Die technische Verfügbarkeit öffentlicher Daten klärt diese Frage nicht von selbst.

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

Fügen Sie Datensätze erst nach erfolgreicher Prüfung der Antwort stapelweise ein. Bei einem erneuten Lauf verhindert die Kombination aus Primärschlüsselfeldern versehentlich doppelte Momentaufnahmen; in der Anwendung können Sie eine Einfügeoperation verwenden, die Konflikte überspringt. Ein neuer Lauf zu einem anderen Zeitpunkt speichert eine separate Zeile und setzt die Zeitreihe fort.

Berechnen Sie Kennzahlen, die Ihre Frage beantworten

Die grundlegende Kennzahl für die Veröffentlichungsfrequenz ist die Zahl der eindeutigen Medien eines Kontos im ausgewählten Zeitraum. Sie lässt sich anhand von published_at leicht berechnen, sofern dieses Feld vorhanden und korrekt erkannt ist. Um Veränderungen öffentlicher Reaktionen zu messen, vergleichen Sie zwei Beobachtungen derselben media_id: Die absolute Änderung der Likes entspricht dem späteren Zählerstand abzüglich des früheren; die relative Änderung ergibt sich aus der Änderung geteilt durch den früheren Wert. Für Kommentare gilt dieselbe Berechnung.

Ist der frühere Wert null oder fehlt er, ist der relative Zuwachs nicht definiert; zeigen Sie die absolute Differenz an und weisen Sie ausdrücklich darauf hin, dass keine Basis für eine Prozentangabe vorliegt. Zählerstände können sich zwischen Beobachtungen verändern, daher sollte der Bericht den Abstand zwischen den Momentaufnahmen und den Zeitpunkt der letzten Erfassung angeben. Diese Details helfen den Lesern, die Zahlen richtig einzuordnen.

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}

Verdichten Sie Konten nicht ohne nachvollziehbare Gewichtung zu einer einzigen Rangliste. Ein praktischer Bericht zeigt meist nebeneinander die Zahl der Beiträge, den Median der Likes und Kommentare pro Beitrag, die Formatverteilung sowie die Veränderung der Reaktionen bei gleichem Beitragsalter. Der Median verringert den Einfluss eines Ausreißers; die Zahl der Beiträge zeigt, wie groß die Stichprobe für den Vergleich ist.

Das Alter eines Beitrags lässt sich auf zwei Arten berücksichtigen. Erstens können Sie Zählerstände regelmäßig erfassen, zum Beispiel in gleichen Abständen nach der ersten Entdeckung eines Mediums. Zweitens können Sie Beiträge vergleichen, die in denselben Zeitbereich fallen, und Beobachtungen mit ungefähr gleichem Alter heranziehen. Wird ein geplanter Lauf versäumt, bezeichnen Sie die tatsächliche Entwicklung nicht als exakten Tageszuwachs: Berechnen Sie den Zeitraum anhand der Zeitstempel.

Automatisieren Sie den Lauf und die Qualitätskontrolle

Führen Sie die Erfassung nach Zeitplan mit cron, GitHub Actions oder einem ETL-Orchestrator aus. Die Abfolge ist einfach: Kontenliste einlesen, benötigte Seiten abfragen, HTTP-Status und Antwortstruktur prüfen, Daten normalisieren, Momentaufnahme speichern und die Ausführung protokollieren. Halten Sie für jeden Lauf die Zahl der verarbeiteten Konten und Medien, Fehler und Dauer fest – so können Sie eine tatsächliche Aktivitätsänderung von einem Erfassungsausfall unterscheiden.

Bei vorübergehenden Fehlern sollten Sie eine begrenzte Zahl von Wiederholungen mit Pausen verwenden und bei einer fehlerhaften Antwort den Anfragekontext ohne geheimen Schlüssel speichern. Lassen Sie keine Endlosschleife über Cursor laufen: Der Abbruch muss den in der Antwort des Endpunkts angegebenen Bedingungen folgen. Wenn die Dokumentation Nutzungsgrenzen oder -regeln vorgibt, richten Sie Häufigkeit und Umfang der Erfassung danach aus.

Der Parameter cache_timeout wird auf der IG-API-Seite für unterstützte Routen aufgeführt. Ein Cache ist nützlich, wenn eine erneute Anfrage innerhalb eines kurzen Zeitfensters keinen zusätzlichen Nutzen bringt; wählen Sie das Erfassungsintervall passend zur Analysefrage. Für eine wöchentliche Übersicht eignet sich beispielsweise eine tägliche Momentaufnahme besser als häufige Wiederholungsanfragen zu denselben Profilen ohne konkreten Zweck.

Testen Sie eine kleine Stichprobe, bevor Sie den regelmäßigen Zeitplan aktivieren. Speichern Sie ein Antwortbeispiel, prüfen Sie IDs und Datumsangaben, vergleichen Sie normalisierte Felder mit dem ursprünglichen JSON und kontrollieren Sie einige Zeilen manuell. Ergänzen Sie Tests für fehlende Werte, leere Listen und unerwartete Formate. Bei einer API-Änderung erkennen solche Prüfungen Probleme schneller als ein widersprüchlicher Bericht am Ende der Woche.

Wo KI nützlich ist

KI eignet sich für den letzten Schritt: eine knappe Beschreibung bereits berechneter Ergebnisse. Übergeben Sie dem Modell aggregierte Werte und Beitragslinks statt des gesamten Rohdatenarchivs – etwa die Zahl der Medien pro Woche, den Median öffentlicher Reaktionen und eine Liste der Beiträge mit den größten Veränderungen in einem festgelegten Zeitraum. Bitten Sie das Modell, Beobachtungen zu formulieren und die IDs der Datensätze anzugeben, auf denen sie beruhen.

Die Berechnung der Kennzahlen sollte gewöhnlichem Code überlassen bleiben, damit dieselbe Regel reproduzierbare Ergebnisse liefert. Ein Modell kann eine textliche Zusammenfassung erstellen, Bildunterschriften vorgegebenen Themen zuordnen oder Fragen für eine manuelle Prüfung vorschlagen. Speichern Sie bei einer thematischen Klassifizierung das Modelllabel getrennt von der ursprünglichen Bildunterschrift und geben Sie die Version der Anweisung oder des Klassifikators an, damit spätere Änderungen den Verlauf nicht unbemerkt überschreiben.

Machen Sie aus einem automatisierten Bericht keine automatisierte Entscheidung über Einstellung, Vertrag oder Bewertung einer bestimmten Person. Nutzen Sie öffentliche Daten für eine begrenzte Inhaltsanalyse und prüfen Sie Schlussfolgerungen manuell, insbesondere wenn sie geschäftliche Entscheidungen beeinflussen. So bleibt das Monitoring nützlich, und messbare Zählerstände werden klar von ihrer Interpretation getrennt.

So sieht das Ergebnis aus

Nach mehreren Erfassungszyklen entsteht eine Tabelle, aus der hervorgeht, wann jeder Beitrag entdeckt wurde, wie viele Reaktionen bei jeder Beobachtung vorlagen und wie sich die Kennzahlen verändert haben. Eine wöchentliche Übersicht kann praktische Fragen beantworten: Wer hat regelmäßig veröffentlicht, welche Formate wurden häufiger verwendet, welche Beiträge erhielten zwischen vergleichbaren Momentaufnahmen mehr Reaktionen und wo reichen die Daten für einen verlässlichen Vergleich noch nicht aus?

Mit diesem Prozess lassen sich gelegentliche manuelle Prüfungen durch eine wiederholbare Untersuchung ersetzen. Er ersetzt keine qualitative Inhaltsanalyse: Kennzahlen beschreiben die Veröffentlichungsfrequenz und verfügbare öffentliche Reaktionen, während Bedeutung, Zielgruppe und Markenpassung gesondert bewertet werden müssen. Ein einheitlicher Zeitplan, ein gespeicherter Verlauf und eine transparente Berechnungslogik machen solche Bewertungen jedoch überprüfbar und für das Team nutzbar.

Rufen Sie zum Einstieg die Seite zur IG Scraper API auf, prüfen Sie die Parameter der Beitragsroute in der Postman-Dokumentation, implementieren Sie anschließend einen Adapter für ein Testkonto und speichern Sie die erste Momentaufnahme. Sobald das Schema bestätigt ist, ergänzen Sie Zeitplan, Fehlerkontrolle und einen Bericht zu den ausgewählten Kennzahlen.