Slik vurderer du IG-skapere ut fra publiseringstakt: en praktisk Python-pipeline

Det er enkelt å sammenligne to IG-skapere ut fra ett profiløyeblikksbilde; det er vanskeligere å finne ut hvem som publiserer jevnlig, og hvilke innlegg som får reaksjoner over tid. Enkeltkontroller blander innlegg av ulik alder, og et manuelt regneark blir fort utdatert. En praktisk løsning er å samle inn offentlige medier etter en fast plan, lagre hvert svar som en egen observasjon og beregne endringer ut fra egne data.

Nedenfor finner du en fungerende fremgangsmåte for en markedsfører, analytiker eller utvikler som vil sammenligne offentlige kontoer i samme nisje hver uke. Datainnhentingen gjøres med IG Scraper API fra jsonscraper; Python tar seg av planlegging, normalisering og lagring av historikken. Dette bygger videre på temaet profilovervåking og konkurrerende innlegg, med fokus på én felles observasjonsmodell som egner seg for sammenlignende rapportering.

Bestem først hva du vil sammenligne

Oppgaven formuleres ofte bredt: «finne effektive skapere». For teknisk nyttig overvåking bør den avgrenses til målbare spørsmål: Hvor ofte publiseres det? Hvilke formater brukes? Hvor mange offentlige likerklikk og kommentarer er synlige når du sjekker, og hvordan endres tallene etter publisering? En slik samling måleverdier kan hjelpe deg med å velge kontoer for nærmere manuell vurdering eller utarbeide en sammenlignende oversikt.

Offentlige tellere er øyeblikksbilder fra tidspunktet forespørselen sendes. Derfor er den viktigste arkitekturbeslutningen ikke en komplisert modell, men å lagre tidspunktet for innsamling sammen med verdien. Hvis du henter informasjon om det samme mediet hver natt og overskriver den forrige raden, forsvinner historikken du trenger for å beregne vekst. Lagre i stedet observasjonene uforanderlig: én rad per innlegg og innsamlingstidspunkt.

Sammenligningen bør avgrenses til like perioder og sammenlignbare innlegg. Du kan for eksempel se på innlegg som først ble oppdaget i samme kalendermåned, eller ta hensyn til innleggets alder ved hver observasjon. Ellers kan en video fra i går se svakere ut enn et eldre innlegg rett og slett fordi den har hatt kortere tid til å samle reaksjoner.

Pipeline: forespørsel, normalisering, historikk

I en minimal løsning består prosessen av fire trinn: hente en liste over offentlige medier fra utvalgte profiler, konvertere svaret til et felles skjema, lagre radene i et datalager og lage en planlagt rapport. Siden for IG Scraper API viser basisadressen og en oversikt over endepunkter, blant annet en brukerrute for å hente innlegg i grupper. Kontroller parametrene for hver rute og eksempler på svar i Postman-samlingen før integreringen.

API-ets basisadresse er https://ig.jsonscraper.com. For en innledende kontroll viser dokumentasjonen en profilforespørsel etter brukernavn: GET /v1/user/by/username med parametrene username, license_key og cache_timeout i det publiserte eksemplet. For å hente innlegg er ruten GET /v1/user/medias/chunk oppgitt. Hent nøyaktige argumenter, fortsettelsesfelter og svarstruktur fra dokumentasjonen for akkurat denne forespørselen; ikke overfør skjemaet fra én rute til en annen.

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

Dette korte eksemplet følger den dokumenterte profilruten og viser hvordan parametere sendes med HTTP GET. Verdien cache_timeout=60 finnes i det publiserte eksemplet; bruk den bare for ruter som støtter parameteren, og kontroller detaljene i dokumentasjonen. Lagre nøkkelen i en miljøvariabel, ikke i kode eller en nettleserapplikasjon.

Koble til innhenting av innlegg

Når profilen er kontrollert, legger du til en forespørsel om medielisten. API-siden oppgir GET /v1/user/medias/chunk; bruk den dokumenterte logikken for gruppevis behandling av resultatet. Hent parameternavn og vilkår for når pagineringen er ferdig fra den gjeldende beskrivelsen av forespørselen i Postman, i stedet for å gjette ut fra rutenavnet.

Nedenfor er et skjelett for transportkallet, ikke en ferdig kontrakt for endepunktet: fyll ut params med dokumenterte argumenter før du kjører det. Når svaret er mottatt, skal en adapter bare lese felter som er bekreftet i den faktiske JSON-en for den valgte ruten.

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

Skriv deretter en adapterfunksjon som konverterer svaret til et internt format. For analyse kan det være nyttig med en stabil ID for innlegget, forfatter, lenke, publiseringstidspunkt, medietype og tilgjengelige offentlige tellere. Kontroller de nøyaktige feltnavnene og typene mot dokumentasjonen og JSON-eksemplet. Hvis en måleverdi mangler, lagrer du den som en tom verdi i stedet for å sette den til null: null betyr at telleren er målt til null, mens en tom verdi betyr at data mangler.

def normalize_media(item: dict, username: str, observed_at: str) -> dict:
    # Oppgi nøkler først etter at JSON-en fra valgt endepunkt er kontrollert.
    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,
    }

Bytt ut plassholdernavnene med de nøyaktige nøklene fra svaret til det aktuelle endepunktet, og lag en test basert på et lagret JSON-eksempel. Da blir endringer i skjemaet oppdaget når integreringen oppdateres, og eksemplet fremstiller ikke antatte feltnavn som en bekreftet kontrakt.

Lagre observasjoner, ikke bare gjeldende verdier

CSV kan passe til en prototype; for regelmessig bruk kan du velge PostgreSQL, Supabase eller et analyselager. En observasjonstabell kan inneholde feltene username, media_id, published_at, observed_at, likes, comments og rå JSON. Kombinasjonen media_id og observed_at identifiserer et unikt øyeblikksbilde. En egen profiltabell lagrer listen over kontoer som overvåkes, og datoen de ble lagt til i overvåkingen.

Det er nyttig å lagre det ubehandlede svaret ved feilsøking og når normaliserte data skal bygges opp på nytt. Begrens lagringstiden ut fra prosjektets formål og organisasjonens regler, kontroller tilgangen til tabellene, og ikke samle inn opplysninger som ikke trengs for den valgte analysen. For CRM og direkte markedsføring bør du avklare hvilket rettslig grunnlag som gjelder; at offentlige data er teknisk tilgjengelige, avgjør ikke dette spørsmålet.

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

Legg inn rader i grupper etter at svaret er kontrollert. Hvis den samme jobben kjøres på nytt, hindrer kombinasjonen av primærnøkler at et duplikat av øyeblikksbildet opprettes ved et uhell; i applikasjonen kan du bruke en innsetting som hopper over konflikter. En ny kjøring på et annet tidspunkt lagrer en egen rad og viderefører tidsserien.

Beregn måleverdier som svarer på spørsmålet

Den grunnleggende måleverdien for publiseringstakt er antall unike medier fra en konto i et valgt tidsintervall. Den er enkel å beregne ut fra published_at, dersom feltet finnes og er riktig tolket. For å vurdere endringer i offentlige reaksjoner sammenligner du to observasjoner av samme media_id: den absolutte endringen i likerklikk er den senere telleren minus den tidligere, mens den relative endringen er differansen delt på den tidligere verdien. Den samme beregningen gjelder for kommentarer.

Hvis den tidligere verdien er null eller mangler, er den relative veksten ikke definert. Vis da den absolutte forskjellen, og oppgi tydelig at det ikke finnes et grunnlag for en prosentberegning. Tellerne kan endre seg mellom observasjoner, så rapporten bør angi intervallet mellom øyeblikksbildene og tidspunktet for siste innsamling. Disse opplysningene hjelper leseren med å tolke tallene riktig.

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}

Ikke reduser kontoer til én rangering uten forklarlige vekter. En nyttig rapport viser vanligvis antall innlegg, medianen for likerklikk og kommentarer per innlegg, fordelingen av formater og endringer i reaksjoner for samme aldersintervall side om side. Medianen reduserer påvirkningen fra ett avvikende innlegg; antall innlegg viser størrelsen på datagrunnlaget sammenligningen bygger på.

Innleggets alder kan tas hensyn til på to måter. Den første er å registrere tellere jevnlig, for eksempel med like intervaller etter at mediet først ble oppdaget. Den andre er å sammenligne innlegg innenfor samme tidsrom ved å bruke observasjoner fra omtrent samme alder. Hvis en planlagt kjøring uteblir, skal du ikke omtale den faktiske utviklingen som nøyaktig vekst over ett døgn: beregn intervallet ut fra tidsstemplene.

Automatiser kjøringen og kvalitetskontrollen

Kjør innsamlingen etter en fast plan med cron, GitHub Actions eller en ETL-orkestrator. Oppgaven følger en enkel rekkefølge: les listen over kontoer, hent nødvendige grupper, kontroller HTTP-status og svarstruktur, normaliser dataene, lagre øyeblikksbildet og loggfør kjøringen. Registrer antall behandlede kontoer og medier, feil og varighet for hver kjøring. Dette gjør det enklere å skille en reell endring i aktivitet fra en innsamlingsfeil.

Ved midlertidige feil kan du bruke et begrenset antall nye forsøk med pauser imellom. For feilsvar bør du lagre konteksten for forespørselen uten den hemmelige nøkkelen. Ikke kjør en uendelig løkke over markører: stopp når vilkårene for ferdig behandling som er oppgitt i endepunktets svar, er oppfylt. Hvis dokumentasjonen angir grenser eller bruksregler, må frekvensen og utvalgsstørrelsen tilpasses dem.

Parameteren cache_timeout er oppgitt på IG API-siden for ruter som støtter den. Hurtigbuffer er nyttig når en ny forespørsel innenfor et kort tidsrom ikke gir merverdi; velg et innsamlingsintervall som passer til analysespørsmålet. En daglig observasjon egner seg for eksempel bedre til en ukentlig gjennomgang enn hyppige gjentatte forespørsler til de samme profilene uten et konkret formål.

Test et lite utvalg før du setter opp en fast kjøreplan. Lagre et eksempelsvar, kontroller ID-er og datoer, sammenlign normaliserte felter med den opprinnelige JSON-en, og gå gjennom noen rader manuelt. Legg til tester for manglende verdier, tomme lister og uventede formater. Når API-et endres, oppdager slike kontroller problemer raskere enn en uoverensstemmende rapport ved slutten av uken.

Her kan KI være nyttig

KI passer på det siste trinnet, når allerede beregnede resultater skal oppsummeres kort. Send modellen aggregerte tall og lenker til innlegg, ikke hele råarkivet. Det kan for eksempel være antall medier per uke, medianen for offentlige reaksjoner og en liste over innlegg med størst endring i et angitt tidsintervall. Be modellen formulere observasjoner og ta med ID-ene til postene de bygger på.

Selve beregningen av måleverdier bør gjøres med vanlig kode, slik at den samme regelen gir et reproduserbart resultat hver gang. En modell kan lage en tekstlig oppsummering, gruppere bildetekster etter forhåndsdefinerte temaer eller foreslå spørsmål for manuell kontroll. Ved tematisk klassifisering bør modellens etikett lagres separat fra den opprinnelige bildeteksten. Oppgi også versjonen av instruksjonen eller klassifikatoren, slik at senere endringer ikke skriver om historikken uten at det blir lagt merke til.

Ikke gjør en automatisk rapport til en automatisk beslutning om ansettelse, kontrakt eller vurdering av en bestemt person. Bruk offentlige data til avgrenset innholdsanalyse, og kontroller konklusjonene manuelt – særlig når de påvirker forretningsbeslutninger. Da forblir overvåkingen nyttig, og målte tellere holdes atskilt fra tolkningen.

Slik ser resultatet ut

Etter flere innsamlingsrunder får du en tabell som viser når hvert innlegg ble oppdaget, hvor mange reaksjoner det hadde ved hver observasjon, og hvordan måleverdiene endret seg. En ukentlig oppsummering kan svare på praktiske spørsmål: Hvem publiserte jevnlig? Hvilke formater ble brukt oftere? Hvilke innlegg fikk flere reaksjoner mellom sammenlignbare observasjoner? Hvor er datagrunnlaget foreløpig for tynt til en sikker sammenligning?

En slik prosess erstatter sporadiske manuelle kontroller med en repeterbar undersøkelse. Den erstatter ikke en kvalitativ analyse av innholdet: Måleverdiene beskriver publiseringsfrekvens og tilgjengelige offentlige reaksjoner, mens mening, målgruppe og merkevaretilpasning krever en egen vurdering. Men en fast tidsplan, lagret historikk og tydelige beregningsregler gjør vurderingene etterprøvbare og nyttige for teamet.

For å komme i gang kan du åpne siden for IG Scraper API, kontrollere parameterne for innleggsruten i Postman-dokumentasjonen, implementere en adapter for en testkonto og lagre det første øyeblikksbildet. Når skjemaet er bekreftet, kan du legge til en fast kjøreplan, feilhåndtering og rapportering av de valgte måleverdiene.