DataForSEO vs un'API solo link: cosa cambia nella tua pipeline R

L'errore che costa di più in questo tipo di pipeline

La maggior parte delle pipeline fallisce per i soldi, non per il codice. Un loop che chiama un endpoint una volta per riga trasforma un lavoro economico in uno costoso.

Con noi, una chiamata costa lo stesso per 10 righe o 1.000, quindi la regola si inverte: chiedi la pagina più grande possibile. Imposta per a 1000, ordina in base a ciò che ti serve e interrompi il paging quando la domanda è stata soddisfatta.

Il deep pagination è limitato a 50.000 righe, il che è una funzionalità per gli analisti tentati di scaricare tutto. Se un dominio ha più link di quelli, probabilmente vuoi usare toppages o anchors.

Confronta la spesa del tuo vecchio loop con la versione a chiamata singola prima di festeggiare. A volte il risparmio è zero perché il provider vecchio fatturava già per richiesta.

Errori, retry e i fallimenti che puoi pianificare

I fallimenti sono il punto in cui una pipeline solo link e una più ampia appaiono più simili. Il codice viene spesso lasciato incompleto lì. Inserisci i percorsi di errore nel confronto, perché una decisione dataforseo vs link-only appare diversa una volta che gli errori sono in gioco.

HTTP 401 e HTTP 402 sono i due da gestire

Due codici di stato sono i più importanti. HTTP 401 significa che la chiave manca o è errata, e la soluzione risiede nella tua configurazione piuttosto che nei dati. HTTP 402 significa che il saldo dei crediti è esaurito, e la soluzione è un ricarico dalla pagina dell'account, non una modifica al codice.

Scrivi entrambi come rami espliciti. Un catch generico che inghiotte lo status e scrive un table vuoto è il modo in cui avviene un prelievo parziale silenzioso.

Timeout e file parziali

Un timeout non è un codice di stato, quindi il tuo codice deve gestirlo come un fallimento. Avvolgi la chiamata in modo che un timeout interrompa l'esecuzione prima che venga scritto qualsiasi output.

Scrivi su un file temporaneo e rinominalo al successo. Un file scritto a metà che sembra completo è il peggior esito di un'esecuzione interrotta, perché nessuno pensa a metterlo in discussione.

Retry e pacing

Questa pagina non cita una figura di richieste al secondo, quindi dimensiona la pipeline per chiamate per ciclo. È il numero che guida il costo, ed è quello che controlli.

Riprova solo gli errori di rete, con una pausa tra i tentativi. Non riprovare mai un 401 o un 402, perché ciascuno fallirà allo stesso modo al tentativo successivo.

Dove risiede la chiave durante i test

Mantieni la chiave in una variabile d'ambiente sulla tua macchina e nel deposito dei segreti CI, mai in un file che i test leggono. Le azioni gratuite non hanno bisogno di chiave, quindi la prima esecuzione di test è sicura per chiunque cloni il progetto.

Fatti la stessa domanda per ogni pipeline che tocchi: chi può leggere la chiave e dove è scritta? Una chiave che appare in un file di log è una perdita, anche quando il notebook è privato.

Logging del costo di ogni chiamata

Ogni risposta da una chiamata autenticata porta il campo credits, che mostra il costo e il saldo residuo. Copialo nel tuo log accanto al timestamp e al nome dell'azione, così una domanda sul costo può essere risposta leggendo il file piuttosto che dalla memoria.

Leggi il log una volta al mese, non una volta all'anno. Un lento aumento del costo per ciclo è facile da perdere in un grafico e ovvio in una colonna di numeri.

Un'esecuzione fallita dovrebbe lasciare il suo log, con il codice di stato e il passo in cui si è fermata. Un log che registra solo i successi nasconde la riga che ti serviva.

Contare le righe attraverso le fasi

Molti bug costosi della pipeline sono bug di conteggio. Una tabella perde righe in un join, un filtro o una deduplicazione, e il grafico sembra ancora plausibile dopo.

Scrivi un conteggio a ogni passaggio

Pensa alla pipeline come a una catena di tabelle: la risposta API, il tibble parsato, il file archiviato e il report. Un conteggio di righe a ogni passaggio mostra quale fase ha perso righe, se ce n'è stata una.

Gli analisti contano spesso solo alla fine. A quel punto la causa risiede tre fasi indietro, e il tibble è stato rimodellato due volte da allora.

Una riga per dominio, una riga per link

La grana dipende dall'azione. Un pull di domini di riferimento ha una riga per sito linkante, mentre un pull di backlink ha una riga per link, e un sito può inviarne molti. Conta alla grana sbagliata e due numeri corretti appariranno in disaccordo.

Metti la grana nel nome del file archiviato o in un commento header, così la prossima persona non dovrà indovinare. Il glossario delle azioni elenca la grana di ogni azione.

Paging e il soffitto di 50.000 righe

Il paging con page e per funziona fino a 5000 righe per pagina, ma il deep pagination si ferma a 50.000 righe. Un pull che si aspetta più di quello torna limitato, e il suo conteggio può sembrare sospettamente arrotondato.

Confronta il numero ricevuto con il totale che ti aspettavi. Quando differiscono, controlla l'azione, il suo sort e la dimensione della pagina prima di dare la colpa alla fonte.

Un conteggio di esempio, ipoteticamente

Supponiamo che un pull ipotetico chieda siti linkanti per 30 domini target e restituisca 30 righe di conteggi. Unitos alle punteggi, la tabella mantiene 27 righe. Le tre righe mancanti richiedono un'occhiata prima che venga disegnato qualsiasi grafico, partendo dalle loro chiavi.

Scrivi quelle tre per nome, non solo come un conteggio. Un conteggio ti dice che sono mancate delle righe, mentre i nomi ti dicono quali chiavi pulire.

Join che perdono righe silenziosamente

Un left join mantiene ogni riga della tabella sinistra, quindi un punteggio mancante appare come NA invece che come una riga scomparsa. Un inner join nasconde lo stesso problema rimuovendo la riga del tutto.

Scegli il tipo di join intenzionalmente e conta i punteggi NA dopo il join. Quel conteggio appartiene al log accanto al campo credits.

Un breve piano di test prima di cambiare

Esegui entrambe le fonti per un ciclo. Stessi domini, stesso giorno.

Prendi 30 domini che conosci bene, estrai i conteggi dei domini di riferimento dal tuo provider attuale e da CranSEO, e tracciali l'uno contro l'altro su assi logaritmici. Dovresti vedere una diagonale approssimativa, non esatta, perché i crawls differiscono e il nostro si aggiorna circa mensilmente; DataForSEO, Ahrefs e Semrush vedono ciascuno un web leggermente diverso.

Leggi gli outlier, non la media. Dove il nostro conteggio è molto inferiore, controlla se il dominio è nuovo o si è spostato di recente. Dove è molto superiore, controlla i sottodomini. Il glossario definisce cosa contiamo come dominio di riferimento, e il runbook mostra come archiviare entrambi i pull fianco a fianco.