IG-makers beoordelen op basis van publicatietrends: een praktische Python-pipeline

Twee IG-makers vergelijken op basis van één profielmomentopname is eenvoudig; begrijpen wie consequent content publiceert en welke posts na verloop van tijd reacties krijgen, is lastiger. Eenmalige controles mengen publicaties van verschillende leeftijden, terwijl een handmatige spreadsheet snel veroudert. Een praktische oplossing is om openbare media volgens een schema te verzamelen, elk antwoord als een afzonderlijke observatie op te slaan en veranderingen op basis van je eigen gegevens te berekenen.

Hieronder staat een werkbare aanpak voor een marketeer, analist of ontwikkelaar die openbare accounts in dezelfde niche wekelijks wil vergelijken. Voor het ophalen van gegevens wordt de IG Scraper API van jsonscraper gebruikt; Python verzorgt de planning, normalisatie en opslag van de geschiedenis. Dit bouwt voort op het monitoren van profielen en concurrerende publicaties: de nadruk ligt hier op één uniform observatiemodel dat geschikt is voor vergelijkende rapportage.

Bepaal eerst wat je precies wilt vergelijken

De opdracht wordt vaak breed geformuleerd: ‘effectieve makers vinden’. Voor technisch bruikbare monitoring kun je dit beter beperken tot meetbare vragen: hoe vaak verschijnen publicaties, welke formats worden gebruikt, hoeveel openbare likes en reacties zijn zichtbaar op het moment van controle en hoe veranderen die aantallen na publicatie? Met deze gegevens kun je accounts selecteren voor handmatig onderzoek of een vergelijkend overzicht opstellen.

Openbare tellers zijn momentopnamen van het tijdstip waarop het verzoek wordt gedaan. Daarom is het belangrijkste architectuurbesluit geen complex model, maar het samen met de waarde opslaan van het tijdstip waarop de gegevens zijn verzameld. Als je elke nacht gegevens van dezelfde media ophaalt en de vorige rij overschrijft, verdwijnt de geschiedenis die nodig is om groei te berekenen. Sla observaties in plaats daarvan onveranderlijk op: één rij per publicatie en verzameltijdstip.

Beperk de vergelijking tot dezelfde perioden en vergelijkbare publicaties. Je kunt bijvoorbeeld publicaties bekijken die voor het eerst in dezelfde kalendermaand zijn waargenomen, of rekening houden met de leeftijd van een publicatie op elk moment van observatie. Anders lijkt een video van gisteren zwakker dan een oudere post, simpelweg omdat die minder tijd heeft gehad om reacties te verzamelen.

De pipeline: verzoek, normalisatie en geschiedenis

Een minimale versie bestaat uit vier stappen: een lijst met openbare media van geselecteerde profielen ophalen, het antwoord omzetten naar een uniform schema, rijen opslaan in een gegevensopslag en volgens een schema een rapport maken. De pagina van de IG Scraper API toont het basisadres en een overzicht van endpoints, waaronder een gebruikersroute voor het ophalen van publicaties in batches. Controleer vóór integratie de parameters van elke route en de voorbeeldantwoorden in de Postman-collectie.

Het basisadres van de API is https://ig.jsonscraper.com. Voor een eerste controle toont de documentatie een profielverzoek op basis van gebruikersnaam: GET /v1/user/by/username met de parameters username, license_key en cache_timeout in het gepubliceerde voorbeeld. Voor het ophalen van publicaties is de route GET /v1/user/medias/chunk vermeld. Haal de exacte argumenten, velden voor voortzetting en antwoordstructuur uit de documentatie van dat specifieke verzoek; neem het schema van de ene route niet over voor een 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"))

Dit korte voorbeeld volgt de gedocumenteerde profielroute en laat zien hoe je parameters via HTTP GET doorgeeft. De waarde cache_timeout=60 staat in het gepubliceerde voorbeeld; gebruik deze alleen voor routes die de parameter ondersteunen en controleer de details in de documentatie. Bewaar de sleutel in een omgevingsvariabele, niet in de code of een browserapplicatie.

Haal publicaties op

Voeg na de profielcontrole een verzoek toe om de medialijst op te halen. De API-pagina vermeldt GET /v1/user/medias/chunk; gebruik voor de verwerking van het resultaat de batchlogica die in de documentatie staat. Haal parameternamen en de voorwaarde voor het einde van de paginering uit de actuele beschrijving van dit verzoek in Postman, in plaats van ze af te leiden uit de routenaam.

Hieronder staat een raamwerk voor een transportverzoek, geen kant-en-klaar endpointcontract: vul vóór uitvoering params in met de gedocumenteerde argumenten. Na ontvangst van het antwoord mag de adapter alleen velden uitlezen die worden bevestigd door de daadwerkelijke JSON voor de gekozen route.

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

Schrijf vervolgens een adapterfunctie die het antwoord omzet naar een intern formaat. Voor analyse kunnen een stabiele publicatie-ID, auteur, link, publicatiedatum, mediatype en beschikbare openbare tellers van pas komen. Controleer de exacte veldnamen en -typen aan de hand van de documentatie en een JSON-voorbeeld. Als een statistiek ontbreekt, sla die dan op als een lege waarde in plaats van er nul van te maken: nul betekent dat een teller daadwerkelijk op nul is gemeten, een lege waarde betekent dat er geen gegevens zijn.

def normalize_media(item: dict, username: str, observed_at: str) -> dict:
    # Vermeld sleutels pas nadat je de JSON van het gekozen endpoint hebt gecontroleerd.
    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,
    }

Vervang de tijdelijke namen door de exacte sleutels uit het antwoord van het betreffende endpoint en leg de mapping vast met een test op basis van een opgeslagen JSON-voorbeeld. Zo vallen schemawijzigingen op wanneer je de integratie bijwerkt, en doet het voorbeeld geen onbevestigde veldnamen voor als contract.

Sla observaties op, niet alleen de huidige waarden

Voor een prototype volstaat CSV; voor regelmatig gebruik zijn PostgreSQL, Supabase of een analytische gegevensopslag geschikt. Een observatietabel kan de velden username, media_id, published_at, observed_at, likes, comments en de onbewerkte JSON bevatten. De combinatie media_id en observed_at bepaalt een unieke momentopname. Een aparte profielentabel bevat de lijst met gevolgde accounts en de datum waarop ze aan de monitoring zijn toegevoegd.

Het opslaan van het onbewerkte antwoord is nuttig voor foutopsporing en het opnieuw opbouwen van genormaliseerde gegevens. Beperk de bewaartermijn op basis van het projectdoel en de regels van de organisatie, beheer de toegang tot tabellen en verzamel geen gegevens die niet nodig zijn voor de gekozen analyse. Bepaal voor CRM- en directe marketingactiviteiten afzonderlijk welke rechtsgrond van toepassing is: de technische beschikbaarheid van openbare gegevens beantwoordt die vraag op zichzelf niet.

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

Voeg rijen in batches toe nadat het antwoord succesvol is gecontroleerd. Bij een herhaalde uitvoering voorkomt de combinatie van primaire sleutels dat per ongeluk een dubbele momentopname wordt gemaakt; in de applicatie kun je een invoeging gebruiken die conflicten overslaat. Een nieuwe uitvoering op een ander tijdstip slaat een aparte rij op en zet de tijdreeks voort.

Bereken statistieken die antwoord geven op de vraag

De basismaatstaf voor het publicatietempo is het aantal unieke media van een account binnen een gekozen interval. Dit is eenvoudig te berekenen met published_at, als dat veld aanwezig is en correct wordt geïnterpreteerd. Om veranderingen in openbare reacties te beoordelen, vergelijk je twee observaties van dezelfde media_id: de absolute verandering in likes is de latere teller minus de eerdere teller; de relatieve verandering is het verschil gedeeld door de eerdere waarde. Voor reacties geldt dezelfde berekening.

Als de eerdere waarde nul is of ontbreekt, is de relatieve groei niet gedefinieerd; toon dan het absolute verschil en geef duidelijk aan dat er geen basis voor een percentage is. Tellers kunnen tussen observaties veranderen, dus vermeld in het rapport het interval tussen momentopnamen en het tijdstip van de laatste verzameling. Daarmee kan de lezer de cijfers correct interpreteren.

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}

Vat accounts niet samen in één score zonder uitlegbare weging. Een praktisch rapport toont doorgaans naast elkaar het aantal publicaties, de mediaan van likes en reacties per publicatie, de verdeling van formats en de verandering in reacties over dezelfde leeftijdsperiode. De mediaan beperkt de invloed van één uitschieter; het aantal publicaties geeft aan hoe groot de steekproef is waarop de vergelijking berust.

Je kunt op twee manieren rekening houden met de leeftijd van een publicatie. De eerste is tellers regelmatig vastleggen, bijvoorbeeld met gelijke tussenpozen nadat media voor het eerst zijn ontdekt. De tweede is publicaties vergelijken die binnen hetzelfde tijdsbereik vallen, op basis van observaties van ongeveer dezelfde leeftijd. Als een geplande uitvoering wordt overgeslagen, presenteer de feitelijke ontwikkeling dan niet als een exacte groei over één dag: bereken het interval aan de hand van de tijdstempels.

Automatiseer de uitvoering en kwaliteitscontrole

Voer de verzameling volgens een schema uit met cron, GitHub Actions of een ETL-orchestrator. De taakvolgorde is eenvoudig: de accountlijst lezen, de benodigde batches opvragen, de HTTP-status en antwoordstructuur controleren, de gegevens normaliseren, de momentopname opslaan en de uitvoering loggen. Houd voor elke uitvoering het aantal verwerkte accounts en media, fouten en de duur bij — zo kun je een echte verandering in activiteit onderscheiden van een verzamelstoring.

Gebruik voor tijdelijke fouten een beperkt aantal pogingen met tussenpozen en bewaar bij een foutantwoord de context van het verzoek zonder geheime sleutel. Start geen eindeloze lus over cursors: de verwerking moet stoppen volgens de voorwaarden die het endpointantwoord aangeeft. Als de documentatie limieten of gebruiksregels vermeldt, stem de frequentie en steekproefomvang daar dan op af.

De parameter cache_timeout wordt op de IG API-pagina vermeld voor routes die deze ondersteunen. Caching is nuttig wanneer een herhaald verzoek binnen een kort tijdsbestek geen extra waarde oplevert; kies voor het volgen van veranderingen een verzamelinterval dat past bij de analytische vraag. Een dagelijkse momentopname is bijvoorbeeld geschikter voor een wekelijks overzicht dan frequente herhaalde verzoeken aan dezelfde profielen zonder een specifieke reden.

Test een kleine steekproef voordat je een regelmatig schema inschakelt. Sla een antwoordvoorbeeld op, controleer ID’s en datums, vergelijk de genormaliseerde velden met de oorspronkelijke JSON en controleer handmatig enkele rijen. Voeg tests toe voor ontbrekende waarden, lege lijsten en onverwachte formaten. Bij API-wijzigingen signaleren zulke controles problemen sneller dan een rapport dat aan het einde van de week niet klopt.

Waar AI van pas komt

AI is geschikt voor de laatste stap: een korte beschrijving maken van resultaten die al zijn berekend. Geef het model aggregaten en links naar publicaties, niet het volledige onbewerkte archief: bijvoorbeeld het aantal media per week, de mediane openbare reacties en een lijst met publicaties waarvan de cijfers binnen een bepaald interval het sterkst zijn veranderd. Vraag het model observaties te formuleren en de ID’s te vermelden van de records waarop die zijn gebaseerd.

Laat de berekening van statistieken bij voorkeur over aan gewone code, zodat dezelfde regel steeds een reproduceerbaar resultaat oplevert. Een model kan een tekstuele samenvatting opstellen, bijschriften groeperen volgens vooraf bepaalde thema’s of vragen voor handmatige controle voorstellen. Bewaar bij thematische classificatie het modellabel apart van het oorspronkelijke bijschrift en noteer de versie van de instructie of classifier, zodat latere wijzigingen de geschiedenis niet ongemerkt overschrijven.

Maak van een automatisch rapport geen automatische beslissing over het aannemen, contracteren of beoordelen van een specifieke persoon. Gebruik openbare gegevens voor een beperkte inhoudsanalyse en controleer conclusies handmatig, vooral wanneer ze zakelijke beslissingen beïnvloeden. Zo blijft de monitoring nuttig en blijven meetbare tellers gescheiden van interpretatie.

Zo ziet het resultaat eruit

Na enkele verzamelrondes ontstaat een tabel die laat zien wanneer elke publicatie is ontdekt, hoeveel reacties er bij elke observatie waren en hoe de cijfers veranderden. Een wekelijks overzicht kan praktische vragen beantwoorden: wie publiceerde regelmatig, welke formats werden vaker gebruikt, welke publicaties kregen meer reacties tussen vergelijkbare momentopnamen en waar zijn nog te weinig gegevens voor een betrouwbare vergelijking?

Deze aanpak vervangt incidentele handmatige controles door herhaalbaar onderzoek. Hij vervangt geen kwalitatieve inhoudsanalyse: statistieken beschrijven de publicatiefrequentie en beschikbare openbare reacties, terwijl betekenis, publiek en merkfit afzonderlijk moeten worden beoordeeld. Maar een vast schema, een opgeslagen geschiedenis en een expliciete berekeningsmethode maken die beoordelingen wel controleerbaar en bruikbaar voor het team.

Om te beginnen open je de pagina van de IG Scraper API, controleer je de parameters van de publicatieroute in de Postman-documentatie, implementeer je vervolgens een adapter met een testaccount en sla je de eerste momentopname op. Zodra het schema is bevestigd, voeg je planning, foutcontrole en een rapport met de gekozen statistieken toe.