Bästa alternativen till DataForSEO, som en beslutsstruktur för R-användare

Varför vi placerade länk-API på en egen gren

Analytiker vill sällan att en leverantör gör allt, så att dela upp stacken är vanligt. Varje kolumnfamilj har sin egen uppdateringsrytm och sina egna felkällor.

Nyckordsvolyter förändras veckovis, medan en länkgraf byggd från vår egen crawler förändras ungefär en gång i månaden. Att placera dem i samma pipeline-steg döljer den skillnaden och ger diagram som ser mer precisa ut än de är.

En smal API håller också koden kort. Ett request() per åtgärd, en tibble per anrop, och samma kostnad oavsett om anropet returnerar 10 rader eller 1 000.

Inget av detta innebär att en bredare leverantör är sämre. DataForSEO täcker mer mark än vi gör, och om din pipeline redan lutar åt den för SERP-data är det ofta klokt att lämna den delen orörd.

Kod först, eller ett arbetsflödesverktyg först?

De flesta analytiker som jämför de bästa alternativen till DataForSEO fokuserar på leverantören och glömmer verktyget runt den. Verktyget är bara schemaläggaren och limmet. Designa jobbet först. Det är fortfarande ett anrop, en fil och en rapport.

Behåll API-anropet i ett skript du kan diff:a

Säg att du kör om en länkrapport varje månad. Ett skript i versionskontroll visar vilken åtgärd som kördes, vilken domänlista som matade den och vilka parametrar som ställdes in, så att förra månadens siffror kan förklaras rad för rad.

En arbetsflödescanvas kan uttrycka samma steg, men ändringshistoriken är svårare att läsa och granska. Vilket verktyg du än väljer, låt anropet som spenderar krediter skriva en daterad fil. Rapporten ska läsa den filen, inte anropa API:t igen.

När en vanlig schemaläggare räcker

En cron-post eller ett schemalagt CI-jobb som kör ett R-skript täcker de flesta månatliga hämtningar. Inget annat behöver vara vaknande. Om skriptet avslutas med ett fel registrerar schemaläggaren det, och loggen finns där nästa morgon.

Arbetsflödesverktyg tjänar sin plats i andra situationer. Någon som inte skriver kod kan behöva trigga hämtningen, eller så kan ett anrop behöva meddela flera kanaler. Dessa behov är verkliga, men de är sällan en notebook-analytikers behov.

Var ett arbetsflödesverktyg tjänar sin plats

Ett team som vill ha en knapp för hämtningen, ett meddelande i teamchatten vid ett fel och en delad körningshistorik kan dra nytta av ett arbetsflödesverktyg. Behåll HTTP-anropet i en funktion som verktyget anropar, så att logiken förbliver testbar utanför canvasen.

Kontrollera gränserna innan du binder dig. Kan kollegor öppna nyckeln som lagras i verktyget? Kan du exportera flödet som text som du kan granska? Om svaret på något av dessa är nej har bekvämligheten en kostnad som visar sig senare.

Vem som ska få lov att köra om det

Kollegor som kör om en notebook behöver inte din betalda nyckel. Democeller som anropar domain eller overview kräver ingen nyckel, så de körs för alla som öppnar filen.

De betalda cellerna läser nyckeln från miljön. Den vana håller nyckeln borta från notebooken, från arbetsflödesdefinitionen och från en skärmdump som delas i ett möte.

Skriv regeln bredvid nyckelcellen, med vanliga ord: gratis celler körs för alla, och betalda celler behöver nyckeln från miljön. En läsare som stöter på regeln en gång slutar att fråga.

Blandade pipelines och var kopplingen sitter

En blandad pipeline har två källor som matar en tabell. Behåll varje källa i sitt eget steg, skriv varje output till sin egen daterade fil och koppla ihop dem först i rapportstadiet. När en källa ändrar format vet du då vilket steg som brast.

Genomsnittliga inte över leverantörer som räknar olika. Jämför dem sida vid sida under en cykel, som nedbrytningen beskriver, och behåll kopplingsnyckeln identisk på båda sidor.

Att gå igenom ett hypotetiskt jobb genom trädet

Säg att ditt jobb hämtar refererande domäner och ankor för 40 konkurrentdomäner varje månad, och inget annat. Den första raden frågar om nyckordsvolymer eller SERP-positioner. Svaret är nej, så trädet skickar dig till rad 2.

Rad 2 frågar om länkdelen endast är refererande domäner, ankor och ett förtroendebetyg. Här är det så, så en länk-API räcker för det stadiet. Rad 3 frågar efter dagligt färsk crawldata. Svaret är nej, eftersom en månatlig ögonblicksbild är acceptabel för denna rapport, så vandringen slutar på länk-grenen med ett pris per anrop.

Tre korta fallsskisser

Läs dessa som skisser snarare än kunder. Skiss ett: en analytiker bygger en månatlig konkurrensrapport från 40 domäner och vill ha refererande domänräkningar och ankor. Länk-grenen passar. Prissid visar att det kostar cent.

Skiss två: ett team behöver nyckelordspositioner för 2 000 fraser varje dag. Inget här hjälper. Stanna hos en SERP-leverantör.

Skiss tre är det blandade fallet. Det är det vanligaste. Behåll SERP-stadiet som det är, flytta bara länkstadiet och koppla ihop de två tabellerna nedströms. Nedbrytningen går igenom stadierna, och förtroendekontroll-sidan täcker bulkscoring-anropet som ersätter en loop.

När svaret är det beror på

De flesta gånger beror svaret på uppdateringsbehov, och det är det ärliga svaret.

Om en månatlig ögonblicksbild är acceptabel är du i länk-territorium, och en förbetald modell per anrop passar. Om du behöver reagera på en förlorad länk samma dag behöver du en källa byggd för det, och vår månatliga graf är det fel verktyget oavsett pris.