Come valutare i creator IG attraverso l’andamento delle pubblicazioni: una pipeline pratica in Python

Confrontare due creator IG basandosi su un’unica istantanea dei profili è facile; capire chi pubblica con regolarità e quali post ottengono interazioni nel tempo è più difficile. I controlli una tantum mescolano pubblicazioni di età diverse, mentre un foglio di calcolo aggiornato manualmente diventa presto obsoleto. Una soluzione pratica consiste nel raccogliere periodicamente i contenuti pubblici, salvare ogni risposta come osservazione distinta e calcolare le variazioni sui propri dati.

Di seguito è descritto un flusso di lavoro concreto per marketer, analisti o sviluppatori che devono confrontare ogni settimana account pubblici di una stessa nicchia. Per ottenere i dati si utilizza IG Scraper API di jsonscraper; Python gestisce la pianificazione, la normalizzazione e la conservazione dello storico. È un approfondimento sul monitoraggio dei profili e delle pubblicazioni dei concorrenti, con un focus su un modello uniforme di osservazioni, adatto a creare report comparativi.

Per prima cosa, stabilisci che cosa confrontare

La richiesta di solito è formulata in modo ampio: «trovare creator efficaci». Per un monitoraggio tecnicamente utile, conviene restringerla a domande misurabili: con quale frequenza vengono pubblicate le notizie, quali formati compaiono, quanti Mi piace e commenti pubblici risultano al momento del controllo e come cambiano questi valori dopo la pubblicazione. Questi dati aiutano a selezionare gli account da esaminare manualmente o a preparare un riepilogo comparativo.

I contatori pubblici sono istantanee del momento in cui viene eseguita la richiesta. Perciò, nella progettazione, la decisione fondamentale non riguarda un modello complesso, ma la conservazione dell’ora di raccolta insieme al valore. Se ogni notte acquisisci i dati dello stesso contenuto e sovrascrivi la riga precedente, perdi lo storico necessario per calcolare la crescita. Salva invece le osservazioni senza modificarle: una riga per pubblicazione e orario di raccolta.

Il confronto dovrebbe essere limitato a periodi uguali e pubblicazioni comparabili. Per esempio, puoi esaminare le pubblicazioni notate per la prima volta nello stesso mese solare oppure considerare l’età del contenuto a ogni rilevazione. Altrimenti, un Reel pubblicato ieri sembrerà meno efficace di un post più vecchio soltanto perché ha avuto meno tempo per accumulare interazioni.

La pipeline: richiesta, normalizzazione, storico

Nella versione minima, il processo consta di quattro passaggi: ottenere l’elenco dei contenuti pubblici dei profili selezionati, uniformare la risposta a uno schema comune, registrare le righe in un archivio e generare un report secondo una pianificazione. La pagina di IG Scraper API mostra l’indirizzo di base e la mappa degli endpoint, incluso il percorso utente per ottenere pubblicazioni a blocchi. Prima dell’integrazione, verifica i parametri di ogni percorso e gli esempi di risposta nella raccolta Postman.

L’indirizzo di base dell’API è https://ig.jsonscraper.com. Per un controllo iniziale, la documentazione mostra una richiesta al profilo tramite nome utente: GET /v1/user/by/username, con i parametri username, license_key e cache_timeout nell’esempio pubblicato. Per ottenere le pubblicazioni è indicato il percorso GET /v1/user/medias/chunk. Recupera dalla documentazione della richiesta specifica gli argomenti esatti, i campi di continuazione e la struttura della risposta; non trasferire lo schema da un endpoint all’altro.

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

Questo breve esempio riprende il percorso documentato per i profili e mostra come passare i parametri tramite HTTP GET. Il valore cache_timeout=60 compare nell’esempio pubblicato: usalo soltanto per gli endpoint che supportano il parametro e verifica i dettagli nella documentazione. La chiave va conservata in una variabile d’ambiente, non nel codice o in un’applicazione browser.

Integra il recupero delle pubblicazioni

Dopo aver verificato il profilo, aggiungi una richiesta all’elenco dei contenuti. La pagina API indica GET /v1/user/medias/chunk; per elaborare il risultato, usa la logica di paginazione a blocchi prevista dalla documentazione. I nomi dei parametri e la condizione di fine paginazione vanno ricavati dalla descrizione aggiornata di questa richiesta in Postman, non dedotti dal nome del percorso.

Di seguito trovi uno scheletro per la chiamata di trasporto, non un contratto dell’endpoint pronto all’uso: prima di eseguirlo, compila params con gli argomenti documentati. Una volta ricevuta la risposta, l’adattatore dovrà leggere soltanto i campi confermati dal JSON effettivo dell’endpoint scelto.

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

Successivamente, scrivi una funzione adattatrice che converta la risposta nel formato interno. Per l’analisi possono essere utili un identificatore stabile della pubblicazione, l’autore, il link, la data di pubblicazione, il tipo di contenuto e i contatori pubblici disponibili. Verifica i nomi e i tipi esatti dei campi nella documentazione e nell’esempio JSON. Se una metrica non è presente, memorizzala come valore vuoto anziché sostituirla con zero: zero significa che il contatore misurato è nullo, mentre un valore vuoto indica l’assenza di dati.

def normalize_media(item: dict, username: str, observed_at: str) -> dict:
    # Indica le chiavi solo dopo aver verificato il JSON dell’endpoint scelto.
    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,
    }

Sostituisci i nomi segnaposto con le chiavi esatte della risposta dell’endpoint specifico e fissa la mappatura con un test basato su un esempio JSON salvato. In questo modo, eventuali modifiche allo schema saranno rilevate durante l’aggiornamento dell’integrazione e l’esempio non presenterà nomi di campi ipotetici come se facessero parte di un contratto confermato.

Conserva le osservazioni, non soltanto i valori correnti

Per un prototipo può bastare un CSV; per un uso regolare, scegli PostgreSQL, Supabase o un archivio analitico. La tabella delle osservazioni può includere i campi username, media_id, published_at, observed_at, likes, comments e il JSON grezzo. La coppia media_id e observed_at identifica un’istantanea univoca. Una tabella separata dei profili conserva l’elenco degli account monitorati e la data in cui sono stati aggiunti al monitoraggio.

Conservare la risposta grezza è utile per il debug e per ricostruire i dati normalizzati. Limita il periodo di conservazione in base allo scopo del progetto e alle regole dell’organizzazione, controlla l’accesso alle tabelle e non raccogliere informazioni non necessarie per l’analisi scelta. Per CRM e azioni di marketing diretto, definisci separatamente la base giuridica applicabile: la disponibilità tecnica dei dati pubblici non risolve da sola la questione.

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

Aggiungi i record in blocco dopo aver verificato con successo la risposta. Se la stessa attività viene eseguita di nuovo, la combinazione della chiave primaria impedisce di creare per errore un duplicato dell’istantanea; nell’applicazione puoi usare un inserimento che ignori i conflitti. Un nuovo avvio in un momento diverso salverà una riga distinta e prolungherà la serie temporale.

Calcola le metriche che rispondono alla domanda

La metrica di base per la frequenza di pubblicazione è il numero di contenuti unici di un account nell’intervallo scelto. Si calcola facilmente usando published_at, se il campo è presente e viene interpretato correttamente. Per valutare i cambiamenti nelle interazioni pubbliche, confronta due osservazioni dello stesso media_id: la variazione assoluta dei Mi piace è il contatore più recente meno quello precedente; la variazione relativa è la differenza divisa per il valore precedente. Lo stesso calcolo vale per i commenti.

Se il valore precedente è zero o non è disponibile, la crescita relativa non è definita: mostra la differenza assoluta e indica chiaramente che manca una base per calcolare la percentuale. I contatori possono cambiare tra le osservazioni, quindi il report dovrebbe specificare l’intervallo tra le istantanee e l’ora dell’ultima raccolta. Questi dettagli aiutano chi legge a interpretare correttamente i numeri.

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}

Non ridurre gli account a un’unica classifica senza pesi giustificabili. Un report pratico mostra di norma, affiancati, il numero di pubblicazioni, la mediana di Mi piace e commenti per pubblicazione, la distribuzione dei formati e la variazione delle interazioni a parità di età del contenuto. La mediana riduce l’influenza di un singolo post anomalo; il numero di pubblicazioni indica l’ampiezza del campione su cui si basa il confronto.

Ci sono due modi per tenere conto dell’età di una pubblicazione. Il primo consiste nel rilevare regolarmente i contatori, per esempio a intervalli uguali dalla prima individuazione del contenuto. Il secondo consiste nel confrontare pubblicazioni che rientrano nello stesso intervallo temporale, utilizzando osservazioni di età simile. Se un’esecuzione pianificata viene saltata, non presentare la variazione effettiva come un incremento esatto di un giorno: calcola l’intervallo usando le indicazioni temporali.

Automatizza l’esecuzione e il controllo della qualità

Pianifica la raccolta tramite cron, GitHub Actions o un orchestratore ETL. La sequenza dell’attività è semplice: leggere l’elenco degli account, richiedere i blocchi necessari, verificare lo stato HTTP e la struttura della risposta, normalizzare i dati, salvare l’istantanea e registrare l’esecuzione. Per ogni avvio, annota il numero di account e contenuti elaborati, gli errori e la durata: così sarà più facile distinguere un vero cambiamento di attività da un errore di raccolta.

Per gli errori temporanei, esegui un numero limitato di tentativi con pause; in caso di risposta errata, conserva il contesto della richiesta senza la chiave segreta. Non avviare un ciclo infinito sui cursori: l’interruzione deve seguire le condizioni di completamento indicate nella risposta dell’endpoint. Se la documentazione definisce limiti o regole d’uso, imposta la frequenza e la dimensione del campione di conseguenza.

Il parametro cache_timeout è indicato nella pagina IG API per gli endpoint che lo supportano. La cache è utile quando una nuova richiesta in un breve intervallo non aggiunge valore; scegli la frequenza di raccolta in base alla domanda analitica. Per esempio, un’istantanea giornaliera è più adatta a un riepilogo settimanale che richieste ripetute e frequenti agli stessi profili senza uno scopo preciso.

Prima di attivare la pianificazione regolare, prova il sistema su un campione ridotto. Salva una risposta di esempio, verifica identificatori e date, confronta i campi normalizzati con il JSON originale e controlla manualmente alcune righe. Aggiungi test per valori mancanti, elenchi vuoti e formati imprevisti. Se l’API cambia, questi controlli permetteranno di rilevare il problema prima di un report incoerente a fine settimana.

Quando è utile l’IA

L’IA è utile nella fase finale, per descrivere brevemente risultati già calcolati. Fornisci al modello dati aggregati e link alle pubblicazioni, non l’intero archivio grezzo: per esempio, il numero di contenuti per settimana, le interazioni pubbliche mediane e un elenco delle pubblicazioni con la maggiore variazione nell’intervallo specificato. Chiedi al modello di formulare osservazioni e di indicare gli identificativi dei record da cui derivano.

È meglio lasciare il calcolo delle metriche al codice ordinario, così che la stessa regola produca risultati riproducibili. Il modello può preparare un riepilogo testuale, raggruppare le didascalie in base a temi predefiniti o suggerire domande da verificare manualmente. Per la classificazione tematica, conserva l’etichetta del modello separatamente dalla didascalia originale e indica la versione dell’istruzione o del classificatore, così che modifiche successive non riscrivano lo storico senza che ci si accorga.

Non trasformare un report automatico in una decisione automatica di assunzione, stipula di un contratto o valutazione di una persona specifica. Usa i dati pubblici per analisi circoscritte dei contenuti e verifica manualmente le conclusioni, soprattutto quando influiscono su decisioni aziendali. In questo modo il monitoraggio resta utile e i contatori misurabili rimangono distinti dalla loro interpretazione.

Che aspetto ha il risultato

Dopo alcuni cicli di raccolta, avrai una tabella che mostra quando è stata individuata ciascuna pubblicazione, quante interazioni aveva a ogni osservazione e come sono cambiati i valori. Un riepilogo settimanale potrà rispondere a domande concrete: chi ha pubblicato con regolarità, quali formati sono stati utilizzati più spesso, quali pubblicazioni hanno ottenuto interazioni tra istantanee comparabili e dove i dati sono ancora insufficienti per un confronto affidabile.

Questo processo permette di sostituire controlli manuali sporadici con un’analisi ripetibile. Non sostituisce l’analisi qualitativa dei contenuti: le metriche descrivono la frequenza di pubblicazione e le interazioni pubbliche disponibili, mentre significato, pubblico e coerenza con il marchio richiedono una valutazione distinta. Tuttavia, una pianificazione uniforme, uno storico conservato e una logica di calcolo esplicita rendono queste valutazioni verificabili e utilizzabili dal team.

Per iniziare, consulta la pagina di IG Scraper API, verifica i parametri del percorso delle pubblicazioni nella documentazione Postman, quindi implementa l’adattatore su un account di prova e salva la prima istantanea. Dopo aver confermato lo schema, aggiungi la pianificazione, il controllo degli errori e un report basato sulle metriche scelte.