DataForSEO vs une API uniquement de liens : ce qui change dans votre pipeline R

L'erreur qui coûte le plus cher dans ce type de pipeline

La plupart des pipelines échouent sur le plan financier, et non sur le code. Une boucle qui appelle un point de terminaison une fois par ligne transforme une tâche peu coûteuse en tâche onéreuse.

Avec nous, un appel coûte autant pour 10 lignes que pour 1 000, donc la règle s'inverse : demandez la plus grande page possible. Définissez per à 1000, triez selon vos besoins, et arrêtez la pagination lorsque la question est résolue.

La pagination profonde est limitée à 50 000 lignes, ce qui est une fonctionnalité pour les analystes tentés de tout extraire. Si un domaine a plus de liens que cela, vous voudrez probablement utiliser toppages ou anchors à la place.

Comparez les dépenses de votre ancienne boucle avec la version à appel unique avant de célébrer. Parfois, l'économie est nulle parce que l'ancien fournisseur facturait déjà par requête.

Erreurs, tentatives et les échecs que vous pouvez anticiper

Les échecs sont là où un pipeline uniquement de liens et un plus large se ressemblent le plus. Le code y est souvent laissé inachevé. Intégrez les chemins d'échec dans la comparaison, car une décision dataforseo vs link-only semble différente une fois les erreurs prises en compte.

HTTP 401 et HTTP 402 sont les deux à gérer

Deux codes d'état sont les plus importants. HTTP 401 signifie que la clé est manquante ou incorrecte, et la correction réside dans votre configuration plutôt que dans vos données. HTTP 402 signifie que le solde de crédit est épuisé, et la correction est un rechargement depuis la page du compte, et non un changement de code.

Écrivez-les tous les deux comme des branches explicites. Une capture générique qui avale le statut et écrit une table vide est la façon dont un prélèvement partiel silencieux se produit.

Timeouts et fichiers partiels

Un timeout n'est pas un code d'état, donc votre propre code doit le traiter comme un échec. Enveloppez l'appel de sorte qu'un timeout arrête l'exécution avant qu'une sortie ne soit écrite.

Écrivez dans un fichier temporaire et renommez-le en cas de succès. Un fichier à moitié écrit qui semble complet est le pire résultat d'une exécution interrompue, car personne ne pense à le remettre en question.

Tentatives et rythme

Cette page ne cite pas de chiffre de requêtes par seconde, donc dimensionnez le pipeline par appels par cycle. C'est le nombre qui entraîne le coût, et c'est celui que vous contrôlez.

Ne réessayez que les erreurs réseau, avec une pause entre les tentatives. Ne réessayez jamais un 401 ou un 402, car chacun échouera de la même manière lors de la prochaine tentative.

Où se trouve la clé pendant les tests

Gardez la clé dans une variable d'environnement sur votre machine et dans le magasin de secrets CI, jamais dans un fichier que les tests lisent. Les actions gratuites n'ont pas besoin de clé, donc la première exécution de test est sûre pour quiconque clone le projet.

Posez la même question à chaque pipeline que vous touchez : qui peut lire la clé, et où est-elle consignée ? Une clé qui apparaît dans un fichier de logs est une fuite, même lorsque le notebook lui-même est privé.

Journaliser le coût de chaque appel

Chaque réponse d'un appel authentifié contient le champ credits, qui indique le coût et le solde restant. Copiez-le dans votre journal à côté de l'horodatage et du nom de l'action, afin qu'une question sur le coût puisse être répondue à partir du fichier plutôt que de la mémoire.

Lisez le journal une fois par mois, pas une fois par an. Une augmentation lente du coût par cycle est facile à manquer dans un graphique et évidente dans une colonne de nombres.

Une exécution échouée doit également laisser son journal derrière, avec le code d'état et l'étape où elle s'est arrêtée. Un journal qui n'enregistre que les succès cache la ligne dont vous aviez besoin.

Compter les lignes à travers les étapes

De nombreux bugs coûteux de pipeline sont des bugs de comptage. Un tableau perd des lignes lors d'une jointure, d'un filtre ou d'une déduplication, et le graphique a encore l'air plausible par la suite.

Écrivez un comptage à chaque transfert

Pensez au pipeline comme à une chaîne de tableaux : la réponse API, le tibble analysé, le fichier stocké et le rapport. Un comptage de lignes à chaque transfert montre quelle étape a perdu des lignes, si elles l'ont fait.

Les analystes ne comptent souvent qu'à la fin. À ce moment-là, la cause remonte de trois étapes, et le tibble a été remodelé deux fois depuis.

Une ligne par domaine, une ligne par lien

La granularité dépend de l'action. Un tirage de domaines référents a une ligne par site de liaison, tandis qu'un tirage de backlinks a une ligne par lien, et un site peut en envoyer plusieurs. Comptez à la mauvaise granularité et deux nombres corrects sembleront en désaccord.

Indiquez la granularité dans le nom du fichier stocké ou dans un commentaire d'en-tête, afin que la prochaine personne n'ait pas à deviner. Le glossaire des actions liste la granularité de chaque action.

Pagination et le plafond de 50 000 lignes

La pagination avec page et per fonctionne jusqu'à 5000 lignes par page, mais la pagination profonde s'arrête à 50 000 lignes. Un tirage qui en attend plus revient limité, et son comptage peut paraître suspectement rond.

Comparez le nombre que vous avez reçu avec le total que vous attendiez. Lorsqu'ils diffèrent, vérifiez l'action, son tri et la taille de page avant de blâmer la source.

Un comptage travaillé, hypothétiquement

Disons qu'un tirage hypothétique demande des sites de liaison pour 30 domaines cibles et retourne 30 lignes de comptages. Joint aux scores, le tableau conserve 27 lignes. Les trois lignes manquantes nécessitent un examen avant que tout graphique ne soit dessiné, en commençant par leurs clés.

Écrivez ces trois noms par leur nom, pas seulement comme un comptage. Un comptage vous dit que des lignes ont manqué, tandis que les noms vous disent quelles clés nettoyer.

Les jointures qui perdent des lignes silencieusement

Une jointure à gauche conserve toutes les lignes de la table de gauche, donc un score manquant apparaît comme NA plutôt que comme une ligne disparue. Une jointure interne cache le même problème en supprimant la ligne tout à fait.

Choisissez le type de jointure à dessein, et comptez les scores NA après la jointure. Ce comptage appartient au journal à côté du champ credits.

Un court plan de test avant de changer

Exécutez les deux sources pour un cycle. Mêmes domaines, même jour.

Prenez 30 domaines que vous connaissez bien, tirez les comptages de domaines référents de votre fournisseur actuel et de CranSEO, et tracez-les l'un contre l'autre sur des axes logarithmiques. Vous devriez voir une diagonale approximative, pas une exacte, car les crawls diffèrent et le nôtre s'actualise environ mensuellement ; DataForSEO, Ahrefs et Semrush voient chacun un web légèrement différent.

Lisez les valeurs aberrantes, pas la moyenne. Là où notre comptage est bien en dessous, vérifiez si le domaine est nouveau ou récemment déplacé. Là où il est bien au-dessus, vérifiez les sous-domaines. Le glossaire définit ce que nous comptons comme un domaine référent, et le manuel d'exécution montre comment stocker les deux tirages côte à côte.