Domän-DR är en dold räknare. Rakt på sak. Det ökar när fler unika webbplatser länkar till en domän, och logaritmiska skalan gör att varje ny punkt är svårare att uppnå än den föregående. Behåll den här meningen i diagrammet.
En bra widget svarar på en trendfråga per domängrupp: närmar vi oss de tre rivalerna, växer samarbetena, flyttade en kampanj något? En dålig widget blandar in trafik eller intäkter och inbjuder till en orsakskedja som datan inte kan bära.
Spara det råda antalet länkande domäner också. Om poängen ändras med ett steg kan du se om det var 40 nya domäner eller 4 000, och det säger dig om du bör oroa dig.
Vad tabellen bör och inte bör innehålla
En sammanfattningstabell är ett minne. Den bör innehålla det du behöver för att förklara ett diagram om ett år, och inget som inbjuder till felaktiga förklaringar. Börja med den minsta mängden kolumner som svarar på trendfrågan. Lägg till en bara när ett möte kräver det.
Vissa kolumner förtjänar sin plats från dag ett. Färre än du tror. Domänen, poängen, antalet länkande domäner, hämtningsdatumet och källnamnet täcker de flesta frågor. En trafik-kolumn ser hjälpsam ut, men den kommer från en annan källa och ett annat datum, så den hör hemma i en annan tabell.
Lämna ut allt du kan beräkna om från resten. En månadsvis förändring är en subtraktion, så behåll den i en vy snarare än som en fjärde kopia av samma fakta.
Skriv kolumnlistan också i diagrammet. En läsare som öppnar diagrammet om ett år bör se var varje nummer kommer ifrån, och vilken hämtning fyllde det.
Nycklar som stoppar dubbla rader
Primärnyckeln på domain och pull date gör mer än att blockera duplicering. Den säger också vilken hämtning en rad kommer från, vilket är viktigt när en omkörning sker efter ett timeout. Två rader för samma domän under en månad bör vara omöjliga, och schemat bör säga så.
Källnamn du kan filtrera på
Skriv källan som en fast etikett, t.ex. rankwiser_bulk_dr, inte som en fritekt-notering. En filtrering på den etiketten håller denna poäng åtskild från alla andra poäng du laddar in senare. Håll listan över etiketter kort och skriv ner den bredvid tabellen.
Körkostnader, beräknade för tre liststorlekar
Beräknat från credit-priserna ovan. Exempel, inte mätningar.
Spårade domäner
Anrop per månad
Credits
Dollars
50
1
1
$0.0001
500
1
1
$0.0001
5,000
3
3
$0.0003
När körningen misslyckas
En 401 betyder en saknad eller fel nyckel. En 402 betyder att credit-talet är slut, så ladda upp med USDT från kontosidan. Varna för alla svar där ok inte är true, snarare än att skriva nollor i diagrammet.
Testa pipeline:n på tre domäner först
1
Välj tre kända domäner
Använd en webbplats du känner väl, en rival och en liten webbplats. Tre är tillräckligt för att visa svarets form.
2
Skicka testanropet
Anropa bulk_dr med de tre domänerna och spara det råa svaret, inte bara de parserade raderna.
3
Kontrollera ok och saldot
Bekräfta att ok är true och läs _credits. Anropet bör kosta ett credit, och det återstående saldot bör minska med det beloppet.
4
Jämför en rad för hand
Sök upp en av domänerna med den kostnadsfria uppslagsfunktionen på denna webbplats. Om poängen matchar det din parser sparade, är parsern korrekt.
Skyddsräcken värt att lägga till från dag ett
Behåll en andra tabell över misslyckade hämtningar. En rad med HTTP-status, tid och svarskropp slår ett tyst glapp i diagrammet. Varna för allt utom ok true.
Fäst domänlistan i versionskontroll. Korta diffar hjälper. När någon lägger till en rival visar diffen vem som lade till den och när, och diagrammet får en anteckning. Annars dyker linjen för den rivalen upp ur tomrummet och folk undrar varför den började i mars.
Planera också för källbyten. Om du senare lägger till Ahrefs- eller Moz-värden, ge dem sitt eget source-värde i tabellen, som diskuterades när vi jämförde Ahrefs och Majestic.
En snabb hälsokontroll för varje månatlig körning
Innan du litar på ett diagram, kontrollera jobbet som fyllde det. Titta sedan på diagrammet. En hälsosam körning returnerar ok satt till true, en rad för varje domän du bad om, och ett saldo som minskat med det förväntade beloppet. Allt annat är en anledning att läsa svaret, inte att dra linjen ändå.
Räkna raderna som flyttade sig. Om en stor del förändrades med tre poäng eller mer, kontrollera domänlistan innan du skyller på indexet. En plötslig översvämning av förändringar betyder oftast att listan ändrades, inte webben.
Ett radantal som matchar listan är minimum. Färre rader betyder att en domän tappades bort någonstans mellan filen och tabellen. Hitta det innan nästa körning.
Vad en platt månad berättar för dig
En månad med nästan inga förändringar är inte bevis på stabilitet. Indexet uppdateras ungefär en gång i månaden, så en platt rad kan helt enkelt inte ha uppdaterats ännu. Läs en tyst månad bredvid dess hämtningsdatum, och kom ihåg att diagrammet fortfarande följer kalendern.
Vem får varningen
En varning som skickas till en gemensam inkorg ignoreras inom en månad. Namnge en person för jobbet och en andra för de veckor personen är borta. Varningen bör namnge domänlistan, HTTP-statusen och tiden, så att läsaren inte behöver öppna skriptet för att agera.
Att testa en förändring innan den går live
Om du ändrar listan eller schemat, kör de gamla och nya versionerna sida vid sida under en cykel. Matchande rader visar att förändringen inte gjorde något annat. En skillnad du inte kan förklara bör stoppa rullningen, hur liten den än ser ut.
En notering om hastighet och rytm
Inget här behöver hastighet. En månatlig körning är en handfull anrop, även för stora listor, och varje svar anländer som ett JSON-dokument. Om din schemaläggare försöker om vid fel, gör omkörningen idempotent, vilket primärnyckeln på domain och pull date redan ger dig.
Motstå frestelsen att köra jobbet dagligen bara för att det är billigt. Gör det inte. Vårt index uppdateras ungefär en gång i månaden. Dagliga hämtningar returnerar samma rader i veckor, och ditt diagram fylls med platta linjer som ser ut som stabilitet men bara speglar crawl-kalendern. Läs Majestic-alternativens recept för andra hämtningar som är värda att schemalägga, som ankare och snittmängder.
Att äga jobbet efter lansering
Ett månatligt jobb lever längre än personen som byggde det. Sex månader senare öppnar någon ny cron-posten och undrar varför listan bor i en fil. Skriv en kort anteckning. Lägg den högst upp i skriptet med syftet, schemat och credit-kostnaden. Den anteckningen är billigare än ett möte om den.
Granska domänlistan varje kvartal. Ta bort vad som inte längre är viktigt, och lägg till rivalerna som ett beslut faktiskt bygger på. Varje förändring går in i versionskontroll med ett datum, så att diagrammet kan visa förändringen istället för att dölja den.
Budgeten är också en del av granskningen. Ett credit i månaden. Kostnaden förblir liten. Kontrollera saldot samma dag som diagrammet, och skriv nästa påfyllnadsdatum i samma anteckning.
Frågor folk ställer om det månatliga jobbet
Fyra frågor dyker upp när jobbet har körts i några månader. Varje svar är en regel du kan skriva in i installationsanteckningen.
Varför inte hämta dagligen, eftersom anropen är billiga?
Datat ändras på en månatlig kalender, så en daglig hämtning upprepar samma rader i veckor. Kostnaden är liten, men diagrammet fylls med platta linjer som ser ut som stabilitet. Ett diagram som skickas till en styrelse behöver också styrelsens körmanual fotnot.
Vad händer om en rival försvinner från listan?
Behåll dess historik, markera domänen som borttagen och sluta hämta den. En saknad rad ser ut som ett datagapp, så skriv orsaken bredvid diagrammet.
Kan jag köra jobbet en annan dag?
Ja, om du väljer en dag och behåller den. Poängen är en jämn rytm. Att flytta datumet med några dagar varje månad gör trenden svårare att läsa.
Vad gör jag med en 402 mitt i månaden?
Stoppa jobbet, ladda upp från kontosidan med USDT, och kör om bara det misslyckade anropet. Behåll det misslyckade svaret i din logg, så att gapet i diagrammet har en skriftlig förklaring.
