DataForSEO vs. o API doar pentru linkuri: ce se schimbă în pipeline-ul tău R

Greșeala care costă cel mai mult într-un astfel de pipeline

Majoritatea pipeline-urilor eșuează din punct de vedere financiar, nu din punct de vedere tehnic. Un loop care apelează un endpoint o dată pe rând transformă o sarcină ieftină într-una scumpă.

Cu noi, un apel costă la fel pentru 10 rânduri sau 1,000, astfel încât regula se inversează: cereți pagina cea mai mare pe care o puteți folosi. Setează per la 1000, sortează în funcție de ceea ce ai nevoie și oprește paginarea când întrebarea este răspunsă.

Paginarea profundă este limitată la 50,000 de rânduri, ceea ce este un avantaj pentru analiștii tentați să extragă totul. Dacă un domeniu are mai multe link-uri decât atât, probabil că vrei toppages sau anchors în schimb.

Compară cheltuialea vechiului loop cu versiunea cu un singur apel înainte de a sărbători. Uneori economisirea este zero deoarece furnizorul vechi factura deja pe bază de solicitare.

Erori, retry-uri și eșecurile pentru care poți planifica

Eșecurile sunt locul în care un pipeline doar pentru link-uri și unul mai amplu arată cel mai similar. Codul rămâne neterminat acolo. Pune căile de eșec în comparație, deoarece o decizie dataforseo vs link-only arată diferit odată ce erorile sunt în discuție.

HTTP 401 și HTTP 402 sunt cele două de gestionat

Două coduri de stare sunt cele mai importante. HTTP 401 înseamnă că cheia lipsește sau este greșită, iar remedierea se află în configurația ta, nu în datele tale. HTTP 402 înseamnă că soldul de credit s-a epuizat, iar remedierea este un reîncărcare de pe pagina contului, nu o modificare de cod.

Scrie ambele ca ramuri explicite. O captură generică care înghite statusul și scrie un tabel gol este modul în care are loc o extragere parțială silențioasă.

Timeout-uri și fișiere parțiale

Un timeout nu este un cod de stare, astfel încât codul tău propriu trebuie să îl trateze ca un eșec. Înconjoară apelul astfel încât un timeout să oprească rularea înainte ca orice output să fie scris.

Scrie într-un fișier temporar și redenumește-l la succes. Un fișier scris parțial care pare complet este cel mai rău rezultat al unei rulări întrerupte, deoarece nimeni nu se gândește să îl pună la îndoială.

Retry-uri și ritm

Această pagină nu citează un număr de cereri pe secundă, astfel încât dimensionează pipeline-ul în funcție de apeluri pe ciclu. Acesta este numărul care determină costul și este cel pe care îl controlezi.

Retry doar pentru erorile de rețea, cu o pauză între încercări. Nu retry niciodată un 401 sau un 402, deoarece fiecare va eșua în același mod la următoarea încercare.

Unde se află cheia în timpul testelor

Păstrează cheia într-o variabilă de mediu pe mașina ta și în depozitul de secrete CI, niciodată într-un fișier pe care testele îl citesc. Acțiunile gratuite nu necesită cheie, astfel încât prima rulare de testare este sigură pentru oricine clonează proiectul.

Pune aceeași întrebare fiecărui pipeline atins: cine poate citi cheia și unde este notată? O cheie care apare într-un fișier log este o scurgere, chiar și atunci când notebook-ul în sine este privat.

Logarea costului fiecărui apel

Fiecare răspuns de la un apel autentificat conține câmpul credits, care afișează costul și soldul rămas. Copiază-l în logul tău alături de timestamp și numele acțiunii, astfel încât o întrebare privind costul să poată fi răspunsă din fișier, nu din memorie.

Citește logul o dată pe lună, nu o dată pe an. O creștere lentă a costului pe ciclu este ușor de ratat într-un grafic și evidentă într-o coloană de numere.

O rulare eșuată ar trebui să își lase logul în urmă, cu codul de stare și etapa în care s-a oprit. Un log care înregistrează doar succese ascunde linia de care aveai nevoie.

Numărarea rândurilor pe etape

Multe bug-uri costisitoare ale pipeline-ului sunt bug-uri de numărare. Un tabel pierde rânduri într-un join, un filtru sau o deduplicare, iar graficul arată încă plauzibil ulterior.

Scrie o numărare la fiecare predare

Gândește pipeline-ul ca pe un lanț de tabele: răspunsul API, tibble-ul analizat, fișierul stocat și raportul. O numărare de rânduri la fiecare predare arată care etapă a pierdut rânduri, dacă a făcut-o.

Analiștii numără adesea doar la final. Până atunci, cauza se află la trei etape în urmă, iar tibble-ul a fost reformatat de două ori de atunci.

Un rând pe domeniu, un rând pe link

Granularitatea depinde de acțiune. O extragere a domeniilor de referință are un rând per site de linkuire, în timp ce o extragere de backlink-uri are un rând per link, iar un site poate trimite multe dintre ele. Numără la granularitatea greșită și două numere corecte vor părea că nu se potrivesc.

Pune granularitatea în numele fișierului stocat sau într-un comentariu antet, astfel încât următoarea persoană să nu trebuiască să ghicească. Glosarul de acțiuni listează granularitatea fiecărei acțiuni.

Paginare și plafonul de 50,000 de rânduri

Paginarea cu page și per funcționează până la 5000 de rânduri pe pagină, dar paginarea profundă se oprește la 50,000 de rânduri. O extragere care se așteaptă la mai mult de atât se întoarce limitată, iar numărul său poate părea suspect de rotund.

Compară numărul primit cu totalul așteptat. Când diferă, verifică acțiunea, sortarea și dimensiunea paginii înainte de a da vina pe sursă.

O numărare lucrată, ipotetic

Să presupunem că o extragere ipotetică cere site-uri de linkuire pentru 30 de domenii țintă și returnează 30 de rânduri de numărători. Unit la scoruri, tabelul păstrează 27 de rânduri. Cele trei rânduri lipsă necesită o privire înainte de a trasa orice grafic, începând cu cheile lor.

Scrie acele trei pe nume, nu doar ca o numărare. O numărare îți spune că au lipsit rânduri, în timp ce numele îți spun care chei trebuie curățate.

Join-uri care pierd rânduri silențios

Un left join păstrează fiecare rând din tabelul stâng, astfel încât un scor lipsă apare ca NA în loc de un rând dispărut. Un inner join ascunde aceeași problemă prin eliminarea rândului în totalitate.

Alege tipul de join în mod intenționat și numără scorurile NA după join. Această numărare aparține logului alături de câmpul credits.

Un plan de testare scurt înainte de a trece

Rulează ambele surse pentru un ciclu. Aceleași domenii, aceeași zi.

Ia 30 de domenii pe care le cunoști bine, extrage numărătorile de domenii de referință de la furnizorul tău actual și de la CranSEO și trasează-le unul împotriva celuilalt pe axe logaritmice. Ar trebui să vezi o diagonală aproximativă, nu una exactă, deoarece crawl-urile diferă și al nostru se reîmprospătează aproximativ lunar; DataForSEO, Ahrefs și Semrush văd fiecare un web ușor diferit.

Citește outlierii, nu media. Unde numărul nostru este mult sub, verifică dacă domeniul este nou sau s-a mutat recent. Unde este mult peste, verifică subdomeniile. Glosarul definește ceea ce numim domeniu de referință, iar manualul de rulare arată cum să stochezi ambele extrageri una lângă alta.