Michael JohnsonPorovnat dva instagramové tvůrce podle jediného snímku profilu je snadné; zjistit, kdo publikuje pravidelně a které příspěvky postupně získávají reakce, je složitější. Jednorázové kontroly míchají příspěvky různého stáří a ručně vedená tabulka rychle zastarává. Praktickým řešením je podle plánu sbírat veřejná média, ukládat každou odpověď jako samostatné pozorování a počítat změny z vlastních dat.
Níže je praktický postup pro marketéra, analytika nebo vývojáře, který potřebuje každý týden porovnávat veřejné účty ve stejném oboru. Data získává IG Scraper API od jsonscraper; Python zajišťuje plánování, normalizaci a ukládání historie. Navazuje na téma monitorování profilů a konkurenčních příspěvků, přičemž se soustředí na jednotný model pozorování vhodný pro srovnávací report.
Nejprve určete, co přesně chcete porovnávat
Úkol se obvykle formuluje obecně: „najít úspěšné tvůrce“. Pro technicky užitečné monitorování je lepší zúžit ho na měřitelné otázky: jak často příspěvky vycházejí, jaké formáty se objevují, kolik veřejných lajků a komentářů je při kontrole vidět a jak se tato čísla po zveřejnění mění. Taková sada metrik pomůže vybrat účty k ručnímu prozkoumání nebo připravit srovnávací přehled.
Veřejné počty jsou snímky pořízené v okamžiku požadavku. Klíčovým architektonickým rozhodnutím proto není složitý model, ale ukládání času sběru spolu s hodnotou. Pokud každou noc načtete údaje o stejném médiu a přepíšete předchozí řádek, přijdete o historii potřebnou k výpočtu přírůstku. Místo toho ukládejte pozorování neměnně: jeden řádek na příspěvek a čas sběru.
Porovnávejte příspěvky ze stejných období a podobné typy obsahu. Můžete například sledovat příspěvky poprvé zaznamenané v témže kalendářním měsíci nebo zohlednit stáří příspěvku při každém snímku. Jinak bude včerejší video vypadat hůř než starší příspěvek jen proto, že mělo méně času na získání reakcí.
Postup: požadavek, normalizace, historie
Minimální proces má čtyři kroky: získat seznam veřejných médií vybraných profilů, převést odpověď na společné schéma, zapsat řádky do úložiště a podle plánu vytvořit report. Stránka IG Scraper API uvádí základní adresu a přehled endpointů včetně uživatelské trasy pro stránkované načítání příspěvků. Před integrací ověřte parametry jednotlivých tras i příklady odpovědí v kolekci Postman.
Základní adresa API je https://ig.jsonscraper.com. Pro úvodní ověření dokumentace uvádí požadavek na profil podle uživatelského jména: GET /v1/user/by/username s parametry username, license_key a cache_timeout v publikovaném příkladu. Pro získání příspěvků je uvedena trasa GET /v1/user/medias/chunk. Její přesné argumenty, pole pro pokračování a strukturu odpovědi zjistěte v dokumentaci této konkrétní trasy; nepřenášejte schéma z jedné trasy na druhou.
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"))
Tento stručný příklad odpovídá dokumentované trase profilu a ukazuje předávání parametrů prostřednictvím HTTP GET. Hodnota cache_timeout=60 je uvedena v publikovaném příkladu; používejte ji pouze u tras, které tento parametr podporují, a ověřte si podrobnosti v dokumentaci. Klíč ukládejte do proměnné prostředí, nikoli do kódu nebo aplikace v prohlížeči.
Přidejte načítání příspěvků
Po ověření profilu přidejte požadavek na seznam médií. Stránka API uvádí trasu GET /v1/user/medias/chunk; výsledek zpracujte pomocí stránkovací logiky popsané v dokumentaci. Názvy parametrů a podmínku ukončení stránkování převezměte z aktuálního popisu tohoto požadavku v Postmanu; neodvozujte je pouze z názvu trasy.
Níže je kostra přenosového volání, nikoli hotový kontrakt endpointu: před spuštěním vyplňte params argumenty uvedenými v dokumentaci. Adaptér pak musí z odpovědi číst pouze pole potvrzená skutečným JSONem pro zvolenou trasu.
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()
Dále napište funkci adaptéru, která převede odpověď na interní formát. Pro analýzu se mohou hodit stabilní identifikátor příspěvku, autor, odkaz, datum zveřejnění, typ média a dostupné veřejné počty. Přesné názvy a typy polí ověřte v dokumentaci a ukázkovém JSONu. Pokud metrika chybí, uložte ji jako prázdnou hodnotu, nikoli jako nulu: nula znamená naměřený nulový počet, zatímco prázdná hodnota znamená, že údaj není k dispozici.
def normalize_media(item: dict, username: str, observed_at: str) -> dict:
# Klíče doplňte až po ověření JSONu vybraného endpointu.
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,
}
Zástupné názvy nahraďte přesnými klíči z odpovědi konkrétního endpointu a mapování ověřte testem nad uloženou ukázkou JSONu. Změna schématu tak bude při aktualizaci integrace viditelná a příklad nebude vydávat předpokládané názvy polí za potvrzený kontrakt.
Ukládejte pozorování, ne pouze aktuální hodnoty
Pro prototyp postačí CSV, pro pravidelný provoz se hodí PostgreSQL, Supabase nebo analytické úložiště. Tabulka pozorování může obsahovat pole username, media_id, published_at, observed_at, likes, comments a nezpracovaný JSON. Dvojice media_id a observed_at určuje jedinečný snímek. Samostatná tabulka profilů uchovává seznam sledovaných účtů a datum jejich přidání do monitorování.
Ukládání nezpracované odpovědi se hodí při ladění a opětovném sestavení normalizovaných dat. Omezte dobu uchovávání podle účelu projektu a pravidel organizace, kontrolujte přístup k tabulkám a nesbírejte informace, které pro zvolenou analýzu nepotřebujete. U CRM a přímých marketingových aktivit samostatně určete použitelný právní základ: samotná technická dostupnost veřejných údajů tuto otázku neřeší.
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)
);
Záznamy přidávejte hromadně až po úspěšné kontrole odpovědi. Při opakovaném spuštění stejné úlohy zabrání kombinace hodnot primárního klíče nechtěnému vytvoření duplicitního snímku; v aplikaci lze použít vložení, které při konfliktu záznam přeskočí. Nové spuštění v jiném čase uloží samostatný řádek a rozšíří časovou řadu.
Počítejte metriky, které odpovídají na vaši otázku
Základní metrikou tempa publikování je počet jedinečných médií účtu ve zvoleném období. Lze ji snadno spočítat podle published_at, pokud toto pole existuje a je správně rozpoznáno. Chcete-li odhadnout změnu veřejných reakcí, porovnejte dvě pozorování stejného media_id: absolutní změna počtu lajků se rovná pozdější hodnotě minus dřívější, relativní změna je rozdíl vydělený dřívější hodnotou. Stejný výpočet platí pro komentáře.
Pokud dřívější hodnota chybí nebo je nulová, relativní přírůstek není definován; zobrazte absolutní rozdíl a výslovně uveďte, že pro výpočet procent chybí výchozí hodnota. Počty se mohou mezi pozorováními měnit, proto musí report uvádět interval mezi snímky a čas posledního sběru. Tyto údaje pomohou čtenářům správně interpretovat čísla.
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}
Neshrnujte účty do jediného žebříčku bez vysvětlených vah. Praktický report obvykle vedle sebe ukazuje počet příspěvků, medián lajků a komentářů na příspěvek, rozložení formátů a změnu reakcí za stejně dlouhé období od zveřejnění. Medián omezuje vliv jednoho výrazně odlišného příspěvku; počet příspěvků ukazuje velikost vzorku, na němž je srovnání založeno.
Stáří příspěvku lze zohlednit dvěma způsoby. Prvním je pravidelné pořizování snímků počtů, například ve stejných intervalech od prvního zaznamenání média. Druhým je porovnávání příspěvků spadajících do stejného časového rozmezí na základě pozorování přibližně stejného stáří. Pokud plánované spuštění vynecháte, neoznačujte skutečný vývoj jako přesný přírůstek za den; interval vypočítejte z časových značek.
Automatizujte spouštění a kontrolu kvality
Sběr plánujte pomocí cron, GitHub Actions nebo nástroje pro orchestraci ETL. Postup úlohy je jednoduchý: načíst seznam účtů, vyžádat potřebné dávky, zkontrolovat stav HTTP a strukturu odpovědi, normalizovat data, uložit snímek a zaznamenat průběh. U každého spuštění evidujte počet zpracovaných účtů a médií, chyby i dobu trvání — díky tomu rozlišíte skutečnou změnu aktivity od selhání sběru.
U dočasných chyb použijte omezený počet opakování s prodlevou a u chybové odpovědi uložte kontext požadavku bez tajného klíče. Nespouštějte nekonečnou smyčku přes kurzory: zpracování ukončete podle podmínek uvedených v odpovědi endpointu. Pokud dokumentace stanoví limity nebo pravidla používání, přizpůsobte jim frekvenci i velikost vzorku.
Parametr cache_timeout je na stránce IG API uveden u podporovaných tras. Cache se hodí, když opakovaný požadavek v krátkém intervalu nepřináší další hodnotu; interval sběru zvolte podle analytické otázky. Denní snímek například lépe poslouží týdennímu přehledu než časté opakované požadavky na stejné profily bez konkrétního účelu.
Než zapnete pravidelné plánování, otestujte malý vzorek. Uložte ukázkovou odpověď, ověřte identifikátory a data, porovnejte normalizovaná pole s původním JSONem a ručně zkontrolujte několik řádků. Přidejte testy na chybějící hodnoty, prázdné seznamy a neočekávaný formát. Při změně API tyto kontroly odhalí problém rychleji než nesouvislý report na konci týdne.
Kde se hodí AI
AI má své místo v závěrečné fázi, kdy stručně popisuje již vypočtené výsledky. Předávejte modelu agregované údaje a odkazy na příspěvky, nikoli celý nezpracovaný archiv: například počet médií za týden, medián veřejných reakcí a seznam příspěvků s největší změnou za zadaný interval. Požádejte model, aby formuloval zjištění a připojil identifikátory záznamů, z nichž vychází.
Výpočet metrik raději svěřte běžnému kódu, aby stejné pravidlo poskytovalo reprodukovatelné výsledky. Model může připravit textové shrnutí, seskupit popisky podle předem stanovených témat nebo navrhnout otázky k ručnímu ověření. U tematické klasifikace ukládejte štítek modelu odděleně od původního popisku a evidujte verzi instrukce nebo klasifikátoru, aby pozdější změny nenápadně nepřepisovaly historii.
Automatický report nepřetvářejte v automatické rozhodnutí o přijetí, smlouvě či hodnocení konkrétního člověka. Veřejná data používejte k omezené analýze obsahu a závěry kontrolujte ručně, zejména pokud ovlivňují obchodní rozhodnutí. Monitorování tak zůstane užitečné a měřené počty budou oddělené od jejich interpretace.
Jak vypadá výsledek
Po několika cyklech sběru vznikne tabulka, z níž bude patrné, kdy byl každý příspěvek zaznamenán, kolik reakcí měl při jednotlivých pozorováních a jak se jeho ukazatele měnily. Týdenní přehled pak odpoví na praktické otázky: kdo publikoval pravidelně, jaké formáty používal častěji, které příspěvky získávaly reakce mezi srovnatelnými snímky a kde zatím není dost dat pro spolehlivé porovnání.
Takový postup nahradí občasné ruční kontroly opakovatelným zkoumáním. Nenahrazuje kvalitativní analýzu obsahu: metriky popisují četnost publikování a dostupné veřejné reakce, zatímco význam, publikum a soulad se značkou je třeba hodnotit zvlášť. Stejný harmonogram, uložená historie a jasná logika výpočtů však umožňují tato hodnocení ověřovat a využívat v týmu.
Začněte na stránce IG Scraper API, ověřte parametry trasy pro příspěvky v dokumentaci Postman, implementujte adaptér na testovacím účtu a uložte první snímek. Jakmile bude schéma ověřené, přidejte plánování, kontrolu chyb a report založený na vybraných metrikách.