DataForSEO versus een link-only API: wat verandert er in je R-pipeline

De fout die het meest kost in dit soort pipelines

De meeste pipelines falen op het geld, niet op de code. Een loop die een endpoint één keer per rij aanroept, verandert een goedkope taak in een dure.

Bij CranSEO kost een call hetzelfde voor 10 rijen of 1.000, dus de regel keert om: vraag de grootste pagina aan die je kunt gebruiken. Stel per in op 1000, sorteer op wat je nodig hebt en stop met pagineren zodra de vraag beantwoord is.

Diepe paginatie is beperkt tot 50.000 rijen, wat een feature is voor analisten die geneigd zijn alles op te halen. Als een domein meer links heeft dan dat, wil je waarschijnlijk toppages of anchors gebruiken in plaats daarvan.

Vergelijk de uitgaven van je oude loop met de single-call-versie voordat je viert. Soms is de besparing nul omdat de oude provider al per request factureerde.

Fouten, retries en de fouten waar je op kunt anticiperen

Fouten zijn waar een louter link-pipeline en een bredere pipeline het meest op elkaar lijken. Code blijft daar vaak onaf. Neem de failure-paden op in de vergelijking, want een keuze tussen dataforseo en een louter link-pipeline ziet er anders uit als fouten een rol spelen.

HTTP 401 en HTTP 402 zijn de twee die je moet afhandelen

Twee statuscodes zijn het belangrijkst. HTTP 401 betekent dat de key ontbreekt of fout is, en de oplossing ligt in je configuratie in plaats van in je data. HTTP 402 betekent dat je kredietbalans op is, en de oplossing is een top-up via de accountpagina, geen code-aanpassing.

Schrijf beide als expliciete branches. Een generic catch die de status opslokt en een lege tabel schrijft, is hoe een stille partiële pull gebeurt.

Timeouts en partiële bestanden

Een timeout is geen statuscode, dus je eigen code moet het als een fout behandelen. Wrap de call zodat een timeout de run stopt voordat er output wordt weggeschreven.

Schrijf naar een tijdelijk bestand en hernoem het bij succes. Een halfgeschreven bestand dat compleet lijkt, is de ergste uitkomst van een onderbroken run, omdat niemand eraan denkt het ter discussie te stellen.

Retries en pacing

Deze pagina citeert geen requests-per-second figuur, dus dimensioneer de pipeline op basis van calls per cycle. Dat is het getal dat de kosten bepaalt, en dat is hetgetal dat je controleert.

Herhaal alleen netwerkfouten, met een pauze tussen pogingen. Herhaal nooit een 401 of een 402, omdat elke poging op dezelfde manier zal falen.

Waar de key zich bevindt tijdens tests

Houd de key in een environment variable op je machine en in de CI secret store, nooit in een bestand dat de tests lezen. De free actions hebben geen key nodig, dus de eerste testrun is veilig voor iedereen die het project clone.

Stel dezelfde vraag aan elke pipeline die je aanraakt: wie kan de key lezen, en waar is deze genoteerd? Een key die in een logbestand verschijnt, is een leak, zelfs als het notebook zelf privé is.

Loggen van de kosten per call

Elk antwoord van een geauthenticeerde call bevat het veld credits, dat de kosten en de resterende balans toont. Kopieer dit naar je log naast de timestamp en de actienaam, zodat een kostenvraag uit het bestand kan worden beantwoord in plaats van uit het geheugen.

Lees de log een keer per maand, niet een keer per jaar. Een geleidelijke stijging van de kosten per cycle is makkelijk te missen in een grafiek, maar duidelijk in een kolom met getallen.

Een mislukte run moet ook zijn log achterlaten, met de statuscode en de stap waar het stopte. Een log die alleen successen registreert, verbergt de regel die je nodig had.

Rijen tellen over fasen heen

Veel dure pipeline-bugs zijn count-bugs. Een tabel verliest rijen in een join, een filter of een deduplicatie, en de grafiek ziet er daarna nog steeds aannemelijk uit.

Schrijf een count bij elke overdracht

Zie de pipeline als een keten van tabellen: de API-response, de geparseerde tibble, het opgeslagen bestand en het rapport. Een row count bij elke overdracht toont welke fase rijen heeft verloren, mocht dat zo zijn.

Analisten tellen vaak alleen aan het einde. Dan zit de oorzaak drie fasen terug, en is de tibble al twee keer herschikt.

Eén rij per domein, één rij per link

De grain hangt af van de actie. Een referring-domain pull heeft één rij per linking site, terwijl een backlink pull één rij per link heeft, en één site kan er veel sturen. Tel op de verkeerde grain en twee juiste getallen lijken tegenstrijdig.

Zet de grain in de bestandsnaam van het opgeslagen bestand of in een header comment, zodat de volgende persoon niet hoeft te raden. De action glossary geeft de grain van elke actie weer.

Paging en de 50.000-rij plafond

Paging met page en per werkt tot 5000 rijen per page, maar deep pagination stopt bij 50.000 rijen. Een pull die meer dan dat verwacht, wordt afgekapt, en de count kan verdacht rond lijken.

Vergelijk het aantal dat je ontving met het totaal dat je verwachtte. Als ze verschillen, controleer dan de actie, de sortering en de page size voordat je de bron de schuld geeft.

Een uitgewerkte count, hypothetisch

Stel dat een hypothetische pull linking sites vraagt voor 30 target domains en 30 rijen counts retourneert. Gekoppeld aan de scores, houdt de tabel 27 rijen over. De drie missende rijen moeten worden bekeken voordat er een grafiek wordt getekend, beginnend met hun keys.

Schrijf die drie op bij naam, niet alleen als een count. Een count vertelt je dat rijen zijn verdwenen, terwijl de namen vertellen welke keys je moet opschonen.

Joins die rijen stilweg verwijderen

Een left join houdt elke rij van de linkertabel vast, dus een ontbrekende score verschijnt als NA in plaats van als een verdwenen rij. Een inner join verbergt hetzelfde probleem door de rij volledig te verwijderen.

Kies de join type bewust, en tel de NA scores na de join. Die count hoort in de log naast het credits veld.

Een korte testplan voordat je overschakelt

Voer beide bronnen uit voor één cycle. Dezelfde domeinen, dezelfde dag.

Neem 30 domeinen die je goed kent, haal referring-domain counts op van je huidige provider en van CranSEO, en plot ze tegen elkaar aan op log-asen. Je zou een ruwe diagonale lijn moeten zien, geen exacte, omdat crawls verschillen en onze ongeveer maandelijks ververst; DataForSEO, Ahrefs en Semrush zien elk een iets andere web.

Lees de outliers, niet het gemiddelde. Waar onze count ver onder ligt, controleer dan of het domein nieuw is of recent verhuisd. Waar het ver boven ligt, controleer dan subdomeinen. De glossary definieert wat wij tellen als een referring domain, en het runbook toont hoe je beide pulls naast elkaar opslaat.