Bedöm IG-kreatörer utifrån publiceringstakt: en praktisk Python-pipeline

Det är enkelt att jämföra två IG-kreatörer utifrån en enda profilbild; svårare är att förstå vem som publicerar regelbundet och vilka inlägg som får reaktioner över tid. Enstaka kontroller blandar inlägg av olika ålder, och ett manuellt kalkylblad blir snabbt inaktuellt. En praktisk lösning är att samla in offentliga medier enligt ett schema, spara varje svar som en separat observation och beräkna förändringar utifrån egna data.

Nedan följer ett praktiskt upplägg för en marknadsförare, analytiker eller utvecklare som varje vecka behöver jämföra offentliga konton inom en och samma nisch. För att hämta data används IG Scraper API från jsonscraper; Python hanterar schemaläggning, normalisering och historiklagring. Det här bygger vidare på ämnet profilbevakning och konkurrerande inlägg, med fokus på en enhetlig observationsmodell som passar för jämförande rapportering.

Bestäm först vad du vill jämföra

Uppgiften formuleras ofta brett: ”hitta effektiva kreatörer”. För en tekniskt användbar bevakning bör den avgränsas till mätbara frågor: hur ofta publiceras inlägg, vilka format förekommer, hur många offentliga gilla-markeringar och kommentarer syns vid kontrollen, och hur förändras dessa siffror efter publiceringen? En sådan uppsättning hjälper dig att välja konton för manuell granskning eller ta fram en jämförande sammanställning.

Offentliga räknare är ögonblicksbilder av läget när förfrågan görs. Därför är det viktigaste arkitekturbeslutet inte en avancerad modell, utan att spara insamlingstidpunkten tillsammans med värdet. Om du hämtar uppgifter om samma inlägg varje natt och skriver över den tidigare raden försvinner historiken som behövs för att beräkna ökningen. Spara i stället observationerna oföränderliga: en rad per inlägg och insamlingstidpunkt.

Jämförelsen bör avgränsas till samma perioder och jämförbara inlägg. Du kan till exempel granska inlägg som först upptäcktes under samma kalendermånad eller ta hänsyn till inläggets ålder vid varje ögonblicksbild. Annars kan en video från i går verka svagare än ett äldre inlägg bara för att den haft mindre tid på sig att samla reaktioner.

Pipeline: förfrågan, normalisering, historik

I en minimal version består processen av fyra steg: hämta en lista över offentliga medier från utvalda profiler, omvandla svaret till ett gemensamt schema, skriva raderna till lagring och skapa en rapport enligt ett schema. Sidan för IG Scraper API visar basadressen och en översikt över endpointar, inklusive en användarväg för att hämta inlägg i omgångar. Kontrollera parametrarna för varje väg och exempel på svar i Postman-samlingen före integreringen.

API:ets basadress är https://ig.jsonscraper.com. För en första kontroll visar dokumentationen en profilförfrågan med användarnamn: GET /v1/user/by/username med parametrarna username, license_key och cache_timeout i det publicerade exemplet. För att hämta inlägg anges vägen GET /v1/user/medias/chunk. Hämta de exakta argumenten, fortsättningsfälten och svarsstrukturen från dokumentationen för just den förfrågan; överför inte schemat från en väg till en annan.

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

Det här korta exemplet följer den dokumenterade profilvägen och visar hur parametrar skickas via HTTP GET. Värdet cache_timeout=60 finns i det publicerade exemplet; använd det endast för vägar som stöder parametern och kontrollera detaljerna i dokumentationen. Lagra nyckeln i en miljövariabel, inte i koden eller en webbläsarapp.

Lägg till hämtning av inlägg

När profilen har kontrollerats lägger du till en förfrågan om listan över medier. API-sidan listar GET /v1/user/medias/chunk; använd den chunklogik som dokumentationen anger för att hantera resultatet. Parameternamn och villkoret för när pagineringen är klar ska hämtas från den aktuella beskrivningen av förfrågan i Postman, inte gissas utifrån vägens namn.

Nedan är ett skelett för ett transportanrop, inte ett färdigt endpoint-kontrakt: fyll i params med dokumenterade argument innan du kör det. Efter att svaret hämtats ska en adapter endast läsa fält som bekräftats i den faktiska JSON-strukturen för den valda vägen.

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 sedan en adapterfunktion som omvandlar svaret till ett internt format. För analysen kan du behöva ett stabilt inläggs-ID, upphovsperson, länk, publiceringsdatum, medietyp och tillgängliga offentliga räknare. Kontrollera fältnamn och typer i dokumentationen och JSON-exemplet. Om ett mätvärde saknas ska du spara det som ett tomt värde i stället för att sätta noll: noll betyder att ett räknat värde faktiskt var noll, medan ett tomt värde betyder att data saknas.

def normalize_media(item: dict, username: str, observed_at: str) -> dict:
    # Ange nycklar först efter att JSON-svaret för vald endpoint har kontrollerats.
    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,
    }

Byt ut platshållarnamnen mot de exakta nycklarna i svaret från den specifika endpointen och lås mappningen med ett test baserat på ett sparat JSON-exempel. Då blir schemaändringar synliga när integreringen uppdateras, och exemplet framställer inte antagna fältnamn som ett bekräftat kontrakt.

Spara observationer, inte bara aktuella värden

CSV fungerar för en prototyp; för regelbunden drift passar PostgreSQL, Supabase eller ett analysdatalager bättre. En observationstabell kan innehålla fälten username, media_id, published_at, observed_at, likes, comments och rå JSON. Kombinationen media_id och observed_at definierar en unik ögonblicksbild. En separat profiltabell lagrar en lista över bevakade konton och datumet då de lades till i bevakningen.

Att spara det obearbetade svaret är användbart vid felsökning och när normaliserade data behöver byggas om. Begränsa lagringstiden utifrån projektets syfte och organisationens regler, kontrollera åtkomsten till tabellerna och samla inte in uppgifter som inte behövs för den valda analysen. För CRM och direkt marknadsföring bör du separat fastställa tillämplig rättslig grund: att offentliga data är tekniskt tillgängliga avgör inte den frågan.

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

Lägg till poster i omgångar efter att svaret har validerats. Vid en upprepning av samma jobb förhindrar kombinationen av primärnycklar att en identisk ögonblicksbild skapas av misstag; i applikationen kan du använda en infogning som hoppar över konflikter. En ny körning vid en annan tidpunkt sparar en separat rad och fortsätter tidsserien.

Beräkna mätvärden som besvarar frågan

Ett grundläggande mått på publiceringstakt är antalet unika medier från ett konto under en vald period. Det går enkelt att räkna ut från published_at, om fältet finns och har tolkats korrekt. För att bedöma förändringar i offentliga reaktioner jämför du två observationer av samma media_id: den absoluta förändringen i gilla-markeringar är den senare räknaren minus den tidigare, medan den relativa förändringen är skillnaden dividerad med det tidigare värdet. Samma beräkning gäller för kommentarer.

Om det tidigare värdet är noll eller saknas går den relativa ökningen inte att fastställa. Visa då den absoluta skillnaden och ange tydligt att det saknas en bas för procentberäkningen. Räknare kan förändras mellan observationerna, så rapporten bör ange intervallet mellan ögonblicksbilderna och tidpunkten för den senaste insamlingen. Det hjälper läsaren att tolka siffrorna korrekt.

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}

Sammanfatta inte konton i en enda rangordning utan tydliga vikter. En praktisk rapport visar vanligtvis antal inlägg, medianen för gilla-markeringar och kommentarer per inlägg, formatfördelningen och förändringen i reaktioner under samma åldersintervall. Medianen minskar effekten av ett enstaka avvikande inlägg; antalet inlägg visar hur stort urval jämförelsen bygger på.

Inläggets ålder kan beaktas på två sätt. Det första är att regelbundet registrera räknare, till exempel med samma tidsintervall efter att mediet upptäckts första gången. Det andra är att jämföra inlägg inom samma tidsintervall och använda observationer från ungefär samma ålder. Om schemaläggningen missar en körning ska du inte beskriva den faktiska utvecklingen som en exakt ökning över ett dygn: beräkna intervallet utifrån tidsstämplarna.

Automatisera körning och kvalitetskontroll

Kör insamlingen enligt schema med cron, GitHub Actions eller en ETL-orkestrerare. Jobbet följer en enkel ordning: läs listan över konton, hämta nödvändiga omgångar, kontrollera HTTP-status och svarsstruktur, normalisera data, spara ögonblicksbilden och logga körningen. Registrera antalet behandlade konton och medier, fel och tidsåtgång för varje körning – då går det att skilja en verklig aktivitetsförändring från ett insamlingsfel.

Använd ett begränsat antal återförsök med väntetid vid tillfälliga fel, och spara sammanhanget kring en misslyckad förfrågan utan den hemliga nyckeln. Kör inte en oändlig loop över markörer: den ska avslutas enligt villkoren i endpointens svar. Om dokumentationen anger begränsningar eller användningsregler ska du anpassa frekvensen och urvalets storlek efter dem.

Parametern cache_timeout anges på IG API-sidan för vägar som stöder den. Cache är användbart när en upprepad förfrågan inom ett kort tidsfönster inte tillför något; välj ett insamlingsintervall som passar analysfrågan när du följer förändringar. En daglig ögonblicksbild lämpar sig till exempel bättre för en veckosammanställning än täta upprepade förfrågningar om samma profiler utan ett konkret syfte.

Testa ett litet urval innan du aktiverar ett regelbundet schema. Spara ett svarsexempel, kontrollera ID:n och datum, jämför normaliserade fält med den ursprungliga JSON-strukturen och granska några rader manuellt. Lägg till tester för saknade värden, tomma listor och oväntade format. Om API:t ändras upptäcker sådana kontroller problemet snabbare än en inkonsekvent rapport i slutet av veckan.

Var AI kan vara användbart

AI passar i det sista steget – för att kort beskriva redan beräknade resultat. Skicka sammanställda mått och länkar till inlägg till modellen, inte hela råarkivet: till exempel antal medier per vecka, medianen för offentliga reaktioner och en lista över inlägg med störst förändring under ett angivet intervall. Be modellen formulera observationer och bifoga ID:n till de poster som ligger till grund för dem.

Låt vanlig kod beräkna mätvärdena, så att samma regel ger ett reproducerbart resultat. En modell kan förbereda en textbaserad sammanfattning, gruppera bildtexter efter fördefinierade ämnen eller föreslå frågor för manuell kontroll. Vid ämnesklassificering ska modellens etikett lagras separat från den ursprungliga bildtexten. Ange också instruktionens eller klassificerarens version så att senare ändringar inte i tysthet skriver om historiken.

Gör inte en automatiserad rapport till ett automatiserat beslut om anställning, kontrakt eller bedömning av en specifik person. Använd offentliga data för en avgränsad innehållsanalys och kontrollera slutsatserna manuellt, särskilt när de påverkar affärsbeslut. Då förblir bevakningen användbar, samtidigt som mätbara räknare hålls åtskilda från tolkningar.

Så ser resultatet ut

Efter några insamlingscykler får du en tabell som visar när varje inlägg upptäcktes, hur många reaktioner det hade vid varje observation och hur måtten förändrades. En veckosammanställning kan besvara praktiska frågor: vem publicerade regelbundet, vilka format användes oftast, vilka inlägg fick fler reaktioner mellan jämförbara ögonblicksbilder och var det fortfarande finns för lite data för en tillförlitlig jämförelse.

Processen hjälper dig att ersätta enstaka manuella kontroller med en upprepningsbar undersökning. Den ersätter inte en kvalitativ innehållsanalys: mätvärdena beskriver publiceringsfrekvens och tillgängliga offentliga reaktioner, medan innebörd, målgrupp och varumärkespassning kräver en separat bedömning. Men ett enhetligt schema, sparad historik och tydliga beräkningsregler gör bedömningarna kontrollerbara och användbara för teamet.

Börja med att öppna sidan för IG Scraper API, kontrollera parametrarna för inläggsvägen i Postman-dokumentationen, implementera sedan en adapter för ett testkonto och spara den första ögonblicksbilden. När schemat har bekräftats lägger du till schemaläggning, felkontroller och en rapport över de valda mätvärdena.