Michael JohnsonKahta IG-sisällöntuottajaa on helppo verrata yhden profiilinäkymän perusteella; vaikeampaa on selvittää, kuka julkaisee säännöllisesti ja mitkä julkaisut keräävät reaktioita ajan mittaan. Yksittäisissä tarkistuksissa sekoittuvat eri-ikäiset julkaisut, ja käsin ylläpidetty taulukko vanhenee nopeasti. Käytännöllinen ratkaisu on kerätä julkisia medioita aikataulun mukaan, tallentaa jokainen vastaus erillisenä havaintona ja laskea muutokset omasta aineistosta.
Alla on toimiva malli markkinoijalle, analyytikolle tai kehittäjälle, joka haluaa verrata saman toimialan julkisia tilejä viikoittain. Tietojen hakemiseen käytetään jsonscraperin IG Scraper APIa; Python huolehtii aikataulutuksesta, yhdenmukaistamisesta ja historian tallentamisesta. Tämä jatkaa profiilien ja kilpailevien julkaisujen seurannan aihetta: tässä keskitytään yhtenäiseen havaintomalliin, jota voi käyttää vertailuraportissa.
Määritä ensin, mitä haluat vertailla
Tehtävä muotoillaan usein laveasti: ”etsi tehokkaita sisällöntuottajia”. Teknisesti hyödyllisessä seurannassa se kannattaa rajata mitattaviin kysymyksiin: kuinka usein julkaisuja ilmestyy, mitä formaatteja käytetään, kuinka monta julkista tykkäystä ja kommenttia tarkistushetkellä näkyy ja miten luvut muuttuvat julkaisun jälkeen. Tällainen kokonaisuus auttaa valitsemaan tilejä tarkempaan käsin tehtävään arviointiin tai kokoamaan vertailuyhteenvedon.
Julkiset laskurit ovat pyyntöhetken tilannekuvia. Siksi arkkitehtuurissa tärkeintä ei ole monimutkainen malli vaan keräysajan tallentaminen arvon kanssa. Jos haet joka yö tiedot samasta mediasta ja korvaat aiemman rivin, kasvun laskemiseen tarvittava historia katoaa. Tallenna sen sijaan havainnot muuttumattomina: yksi rivi julkaisua ja keräyshetkeä kohti.
Vertailu kannattaa rajata samoihin ajanjaksoihin ja keskenään vertailukelpoisiin julkaisuihin. Voit esimerkiksi tarkastella julkaisuja, jotka havaittiin ensimmäisen kerran saman kalenterikuukauden aikana, tai huomioida julkaisun iän jokaisessa tilannekuvassa. Muuten eilinen video näyttää heikommalta kuin vanha julkaisu vain siksi, että sillä on ollut vähemmän aikaa kerätä reaktioita.
Putki: pyyntö, yhdenmukaistaminen, historia
Yksinkertaisimmillaan prosessi sisältää neljä vaihetta: hae valittujen profiilien julkisten medioiden luettelo, muunna vastaus yhteiseen rakenteeseen, tallenna rivit tietovarastoon ja muodosta raportti aikataulun mukaan. IG Scraper APIn sivulla esitellään perusosoite ja endpoint-kartta, johon kuuluu käyttäjän reitti julkaisujen osittaiseen hakuun. Tarkista kunkin reitin parametrit ja vastausesimerkit Postman-kokoelmasta ennen integrointia.
APIn perusosoite on https://ig.jsonscraper.com. Alustavaa tarkistusta varten dokumentaatiossa näytetään profiilipyyntö käyttäjänimellä: GET /v1/user/by/username, jonka julkaistussa esimerkissä käytetään parametreja username, license_key ja cache_timeout. Julkaisujen hakemiseen on ilmoitettu reitti GET /v1/user/medias/chunk. Tarkat argumentit, jatkoparametrit ja vastausrakenne tulee tarkistaa juuri kyseisen pyynnön dokumentaatiosta; älä siirrä yhden reitin rakennetta toiseen.
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"))
Tämä lyhyt esimerkki vastaa dokumentoitua profiilireittiä ja näyttää parametrien välittämisen HTTP GET -pyynnössä. Arvo cache_timeout=60 esiintyy julkaistussa esimerkissä; käytä sitä vain reiteillä, jotka tukevat parametria, ja tarkista yksityiskohdat dokumentaatiosta. Avain tallennetaan ympäristömuuttujaan, ei koodiin tai selainpohjaiseen sovellukseen.
Lisää julkaisujen haku
Kun profiili on tarkistettu, lisää pyyntö medioiden luetteloon. API-sivulla mainitaan GET /v1/user/medias/chunk; käsittele tulos dokumentaation mukaisella osahaun logiikalla. Parametrien nimet ja sivutuksen päättymisehto tulee tarkistaa Postmanin kyseisen pyynnön ajantasaisesta kuvauksesta, eikä niitä pidä päätellä reitin nimestä.
Alla on kuljetuspyynnön runko, ei valmis endpoint-sopimus: täydennä params dokumentoiduilla argumenteilla ennen suorittamista. Vastauksen saatuaan sovittimen tulee lukea vain ne kentät, joiden olemassaolo on vahvistettu valitun reitin todellisesta JSON-vastauksesta.
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()
Kirjoita seuraavaksi sovitintoiminto, joka muuntaa vastauksen sisäiseen muotoon. Analyysissa voivat olla hyödyllisiä julkaisun pysyvä tunniste, tekijä, linkki, julkaisupäivä, mediatyyppi ja saatavilla olevat julkiset laskurit. Tarkista kenttien täsmälliset nimet ja tyypit dokumentaatiosta ja JSON-esimerkistä. Jos mittari puuttuu, tallenna se tyhjänä arvona äläkä korvaa sitä nollalla: nolla tarkoittaa mitattua nollatulosta, tyhjä arvo tietojen puuttumista.
def normalize_media(item: dict, username: str, observed_at: str) -> dict:
# Määritä avaimet vasta valitun endpointin JSON-vastauksen tarkistamisen jälkeen.
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,
}
Korvaa paikkamerkkien nimet kyseisen endpointin vastauksen täsmällisillä avaimilla ja varmista vastaavuus tallennetulla JSON-esimerkillä tehtävällä testillä. Näin skeemamuutos havaitaan integraatiota päivitettäessä, eikä esimerkissä esitetä oletettuja kenttänimiä vahvistettuna sopimuksena.
Tallenna havaintoja, älä pelkästään nykyisiä arvoja
CSV sopii prototyyppiin, säännölliseen käyttöön PostgreSQL, Supabase tai analytiikkatietovarasto. Havaintotaulukossa voi olla kentät username, media_id, published_at, observed_at, likes, comments ja käsittelemätön JSON. Pari media_id ja observed_at yksilöi tilannekuvan. Erillisessä profiilitaulukossa säilytetään seurattavien tilien luettelo ja niiden lisäämispäivä.
Käsittelemättömän vastauksen tallentaminen auttaa virheiden selvittämisessä ja yhdenmukaistettujen tietojen uudelleenmuodostamisessa. Rajoita säilytysaikaa projektin tarkoituksen ja organisaation sääntöjen mukaisesti, valvo taulukoiden käyttöoikeuksia äläkä kerää tietoja, joita valittu analyysi ei tarvitse. Määritä CRM-käyttöä ja suoraa markkinointia varten erikseen sovellettava oikeusperusta: julkisten tietojen tekninen saatavuus ei ratkaise tätä kysymystä.
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)
);
Lisää tietueet erissä vasta, kun vastaus on tarkistettu onnistuneeksi. Jos sama tehtävä suoritetaan uudelleen, yhdistelmäpääavain estää saman tilannekuvan tahattoman kopioitumisen; sovelluksessa voi käyttää lisäystä, joka ohittaa ristiriidan. Eri aikaan tehty uusi ajo tallentaa erillisen rivin ja jatkaa aikasarjaa.
Laske mittareita, jotka vastaavat kysymykseen
Julkaisutiheyden perusmittari on tilin yksilöllisten medioiden määrä valitulla aikavälillä. Sen voi laskea published_at-kentän perusteella, jos kenttä on saatavilla ja tunnistettu oikein. Julkisten reaktioiden muutoksen arvioimiseksi vertaa saman media_id-tunnisteen kahta havaintoa: tykkäysten absoluuttinen muutos on myöhempi laskuri miinus aiempi, suhteellinen muutos taas saadaan jakamalla muutos aiemmalla arvolla. Sama laskutapa toimii kommenteille.
Jos aiempi arvo on nolla tai puuttuu, suhteellista kasvua ei voi määrittää; näytä absoluuttinen ero ja kerro selvästi, ettei prosenttilaskennalle ole vertailuarvoa. Laskurit voivat muuttua havaintojen välillä, joten raportissa tulee ilmoittaa tilannekuvien välinen aika ja viimeisimmän keräyksen ajankohta. Näiden tietojen avulla luvut voi tulkita oikein.
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}
Älä tiivistä tilejä yhdeksi luokitukseksi ilman perusteltuja painokertoimia. Käytännöllisessä raportissa esitetään yleensä rinnakkain julkaisujen määrä, tykkäysten ja kommenttien mediaani julkaisua kohti, formaattien jakauma sekä reaktioiden muutos saman ikäisissä julkaisuissa. Mediaani vähentää yksittäisen poikkeavan julkaisun vaikutusta, ja julkaisujen määrä kertoo, kuinka suureen otokseen vertailu perustuu.
Julkaisun iän voi huomioida kahdella tavalla. Ensimmäinen on laskea laskurit säännöllisesti esimerkiksi yhtä pitkien aikavälien kuluttua median ensimmäisestä havaitsemisesta. Toinen on verrata samalle aikavälille osuvia julkaisuja ja käyttää suunnilleen samanikäisiä havaintoja. Jos aikataulun mukainen ajo jää väliin, älä esitä toteutunutta muutosta täsmällisenä vuorokausikasvuna: laske aikaväli aikaleimoista.
Automatisoi ajo ja laadunvalvonta
Aja keruu aikataulun mukaan cronilla, GitHub Actionsilla tai ETL-orkestrointityökalulla. Tehtävän kulku on yksinkertainen: lue tililuettelo, hae tarvittavat osat, tarkista HTTP-tila ja vastausrakenne, yhdenmukaista tiedot, tallenna tilannekuva ja kirjaa suorituksen tiedot. Tallenna jokaisesta ajosta käsiteltyjen tilien ja medioiden määrä, virheet sekä kesto — näin voit erottaa todellisen aktiivisuuden muutoksen keruun häiriöstä.
Käsittele tilapäiset virheet rajatulla määrällä uusintayrityksiä ja viiveellä. Virheellisen vastauksen yhteydessä tallenna pyynnön tiedot ilman salaista avainta. Älä käynnistä loputonta kursoreiden läpikäyntiä: pysäytyksen tulee perustua endpointin vastauksessa määritettyihin päättymisehtoihin. Jos dokumentaatiossa määritetään rajoituksia tai käyttöehtoja, säädä keruutiheys ja otoskoko niiden mukaan.
cache_timeout-parametri mainitaan IG APIn sivulla tuetuilla reiteillä. Välimuistista on hyötyä, kun uusi pyyntö lyhyen ajan sisällä ei tuo lisäarvoa; valitse keruuväli analyysikysymyksen mukaan. Päivittäinen tilannekuva sopii esimerkiksi viikkokatsaukseen paremmin kuin samojen profiilien tiheät toistopyynnöt ilman selkeää tarvetta.
Testaa pienellä otoksella ennen säännöllisen aikataulun käyttöönottoa. Tallenna vastausesimerkki, tarkista tunnisteet ja päivämäärät, vertaa yhdenmukaistettuja kenttiä alkuperäiseen JSONiin ja tarkista muutama rivi käsin. Lisää testit puuttuville arvoille, tyhjille listoille ja odottamattomille muodoille. Tällaiset tarkistukset havaitsevat API-muutoksen nopeammin kuin viikon lopussa paljastuva ristiriitainen raportti.
Mihin tekoäly sopii
Tekoälystä on hyötyä viimeisessä vaiheessa jo laskettujen tulosten tiiviissä kuvailussa. Anna mallille koontitiedot ja linkit julkaisuihin koko raakaa arkistoa sisältävän aineiston sijasta: esimerkiksi medioiden määrä viikoittain, julkisten reaktioiden mediaanit ja luettelo julkaisuista, joiden luvut muuttuivat eniten tietyllä aikavälillä. Pyydä mallia muotoilemaan havainnot ja liittämään mukaan tietueiden tunnisteet, joihin havainnot perustuvat.
Jätä mittareiden laskeminen tavalliselle koodille, jotta sama sääntö tuottaa toistettavan tuloksen. Malli voi laatia tekstiyhteenvedon, ryhmitellä kuvatekstejä ennalta määriteltyjen aiheiden mukaan tai ehdottaa kysymyksiä käsin tarkistettavaksi. Jos luokittelet aiheita, tallenna mallin antama luokka erillään alkuperäisestä kuvatekstistä ja kirjaa ohjeen tai luokittelijan versio, jotta myöhemmät muutokset eivät huomaamatta kirjoita historiaa uudelleen.
Älä muuta automaattista raporttia automaattiseksi päätökseksi työsuhteesta, sopimuksesta tai yksittäisen ihmisen arvioinnista. Käytä julkisia tietoja rajattuun sisältöanalyysiin ja tarkista päätelmät käsin, etenkin jos ne vaikuttavat liiketoimintapäätöksiin. Näin seuranta pysyy hyödyllisenä ja mitattavat laskurit erillään niiden tulkinnasta.
Miltä lopputulos näyttää
Muutaman keruukierroksen jälkeen käytössä on taulukko, josta näkee, milloin kukin julkaisu havaittiin, paljonko reaktioita oli jokaisessa havainnossa ja miten luvut muuttuivat. Viikkoyhteenveto voi vastata käytännön kysymyksiin: kuka julkaisi säännöllisesti, mitä formaatteja käytettiin useimmin, mitkä julkaisut keräsivät reaktioita vertailukelpoisten havaintojen välillä ja missä luotettavaan vertailuun ei vielä ole riittävästi tietoa.
Tällainen prosessi korvaa satunnaiset käsin tehtävät tarkistukset toistettavalla tutkimuksella. Se ei korvaa sisällön laadullista analyysia: mittarit kuvaavat julkaisutiheyttä ja saatavilla olevia julkisia reaktioita, mutta merkitys, yleisö ja sopivuus brändille vaativat erillistä arviointia. Yhtenäinen aikataulu, tallennettu historia ja selkeä laskentalogiikka tekevät arvioista kuitenkin tarkistettavia ja tiimin käyttöön sopivia.
Aloita avaamalla IG Scraper APIn sivu, tarkista julkaisureitin parametrit Postman-dokumentaatiosta, toteuta sitten sovitin testitilillä ja tallenna ensimmäinen tilannekuva. Kun skeema on varmistettu, lisää aikataulutus, virheiden valvonta ja valittuihin mittareihin perustuva raportti.