La plupart des agences arrivent à leur configuration de proxy par accident. L’équipe SEO a acheté quelque chose pour le suivi de classement. L’équipe de médias payants a trouvé autre chose pour vérifier les annonces. Un stratège s’est inscrit à un troisième outil pour extraire les prix des concurrents en vue d’un pitch. Trois fournisseurs, trois intégrations, trois jeux de codes de localisation, trois factures, et aucun moyen de répondre à une question client simple : quand notre rapport SEO et notre rapport publicitaire disent tous deux « Madrid », parlent-ils de la même chose ?
C’est l’argument en faveur de la consolidation sur un seul réseau. Pas parce qu’un seul outil est moins cher, bien que ce soit souvent le cas, mais parce que les trois charges de travail posent la même question sous-jacente, à savoir ce que voit un véritable utilisateur sur ce marché, et elles devraient y répondre de la même manière.
Trois charges de travail, trois formes de trafic
Les charges de travail partagent un besoin de points d’observation locaux et diffèrent sur presque tout le reste. Comprendre ces différences est ce qui permet à un seul réseau de fonctionner pour les trois.
Le suivi SEO est à volume élevé et léger. De nombreuses requêtes indépendantes, chacune petite, chacune nécessitant une localisation précise et un profil d’appareil, et chacune indépendante de la précédente. Il nécessite une rotation à chaque requête et un ciblage au niveau de la ville, car les résultats locaux changent à une granularité plus fine que le pays. Les mécanismes sont décrits dans geo-targeted SERP APIs for local SEO.
La vérification publicitaire est à faible volume et lourde. Moins de vérifications, chacune constituant un parcours en plusieurs étapes depuis l’impression jusqu’à la page d’atterrissage, souvent rendu dans un navigateur, et chacune nécessitant des signaux de localisation cohérents du début à la fin. Il nécessite des sessions persistantes et des paramètres d’appareil et de langue cohérents. La conception du programme est décrite dans verifying ad placements at scale.
L’intelligence concurrentielle se situe entre les deux. Parcours de catégories, jeux de résultats paginés, pages d’atterrissage et offres, chacun nécessitant une cohérence interne sur une séquence de requêtes. Il nécessite des sessions persistantes par parcours et une cadence modeste et régulière. Couvert dans competitive campaign intelligence.
| Charge de travail | Modèle de session | Poids par vérification | Ciblage important |
|---|---|---|---|
| Suivi SEO | Rotation par requête | Léger | Ville et appareil |
| Vérification publicitaire | Persistant par parcours | Lourd, souvent rendu | Pays, ville, cohérence de la locale |
| Intelligence concurrentielle | Persistant par parcours | Moyen | Pays, parfois ville |
Pourquoi un seul réseau l’emporte sur trois
Un seul modèle de ciblage. Lorsque les trois charges de travail expriment la localisation de la même manière, une observation concernant un client à Madrid signifie la même chose dans le rapport SEO, le rapport publicitaire et le dossier concurrentiel. Avec trois fournisseurs, vous réconciliez trois définitions de « Madrid » qui peuvent ne pas concorder, et un client qui le remarque demandera pourquoi.
Une seule intégration à maintenir. Chaque fournisseur représente un format d’identifiants, un vocabulaire d’erreurs, un ensemble de codes de ciblage et une relation de support. La consolidation supprime le travail que personne ne facture.
Des points d’observation comparables. Lorsque l’équipe SEO voit un concurrent local progresser et que l’équipe payante voit ce même concurrent enchérir plus fort dans la même ville, les deux observations proviennent de sorties comparables, elles peuvent donc être mises côte à côte plutôt que débattues.
Un seul endroit pour comprendre les dépenses. La bande passante résidentielle est le facteur de coût principal, et il est bien plus facile de la prévoir lorsque les trois charges de travail sont mesurées dans la même unité sur le même tableau de bord. La méthode est décrite dans forecasting residential proxy bandwidth.
Avec la passerelle Shifter, les trois charges de travail utilisent le même point de terminaison, p.shifter.io:443, et expriment leurs différences entièrement dans les identifiants :
# SEO: rotate every request, city-level
customer-USERNAME-country-es-city-madrid:PASSWORD
# Ad verification: one exit for the whole journey
customer-USERNAME-country-es-city-madrid-sid-adv-221-ttl-600:PASSWORD
# Competitive intel: one exit per category walk
customer-USERNAME-country-es-sid-ci-walk-09-ttl-600:PASSWORD
# Any of the above, counted for one client on a shared plan
customer-USERNAME-subaccount-acme-country-es-city-madrid:PASSWORDOmettre sid donne une rotation par requête. L’ajouter maintient une seule sortie, et ttl définit la durée. Cette seule différence est ce qui permet à un réseau unique de servir les trois formes de trafic sans trois configurations. L’étiquette subaccount se place juste après le nom d’utilisateur et indique au panneau à quel client appartient le trafic.
Pour la charge de travail SEO spécifiquement, une SERP API mérite d’être envisagée comme alternative à la gestion des requêtes soi-même, car elle renvoie des résultats structurés avec la localisation et l’appareil déjà gérés.
Séparer les clients
Consolider les charges de travail est juste. Consolider les clients dans un seul pot indifférencié ne l’est pas, pour trois raisons.
Attribution des coûts. Les clients sont facturés pour du travail. Si la collecte de chaque client passe par un seul plan sans rien pour les distinguer, vous ne pouvez pas dire ce que chacun a coûté, et la marge par client devient une supposition. Un sous-compte par client résout ce problème sur un plan partagé : le panneau et l’API rapportent le trafic de chaque client séparément.
Confinement du budget. Le pic de campagne d’un client ne devrait pas consommer l’allocation dont dépend le reporting d’un autre client. Les sous-comptes suivent le trafic mais ne le plafonnent pas, les clients à volumes importants ou imprévisibles devraient donc avoir leur propre plan.
Départ propre. Lorsqu’un client part, son accès, son plan et son historique devraient partir avec lui, sans perturber qui que ce soit d’autre.
Sur Shifter, chaque client peut avoir son propre plan, ou son propre sous-compte sur un plan partagé. Lorsqu’un client a besoin de sa propre facturation ou souhaite voir sa propre utilisation, il peut aussi avoir son propre espace de travail avec ses propres plans, portefeuille et factures, et les responsables de compte de l’agence le rejoignent en tant que membres, avec un seul identifiant de connexion et un sélecteur dans la barre latérale. Les plans ne se croisent jamais entre espaces de travail. La configuration est expliquée dans sub-accounts and usage tracking for multiple clients.
Enregistrer le point d’observation dans chaque livrable client
L’avantage pratique d’un réseau unique ne se concrétise que si les rapports le montrent. Chaque observation qui parvient à un dossier client devrait comporter le marché, la ville le cas échéant, le profil d’appareil et l’horodatage. Les trois disciplines peuvent alors être recoupées dans une seule conversation, et un chiffre contesté peut être retracé exactement jusqu’à l’endroit où il a été observé.
C’est aussi ce qui distingue une agence qui rapporte des données d’une agence qui peut les défendre. Un client qui demande « où avez-vous vu cela ? » devrait obtenir une réponse en quelques secondes.
FAQ
Le crawling intensif d’un client affectera-t-il les résultats d’un autre client ?
Les sorties tournent à travers le pool plutôt que d’être assignées à un seul client, il n’existe donc pas d’ensemble fixe d’adresses qu’un client peut épuiser. Ce qui est partagé, c’est le comportement : une adresse trop sollicitée contre une cible est pire pour celui qui la tire ensuite, donc maintenez les taux de requêtes de chaque client à un niveau ordinaire. Le budget est l’autre ressource partagée, c’est pourquoi chaque client devrait avoir son propre plan.
Un seul réseau suffit-il pour chaque client sur chaque marché ?
Pour la plupart des agences, oui, à condition qu’il couvre les pays et villes dans lesquels vos clients opèrent à la granularité dont votre travail SEO a besoin. Vérifiez la couverture au niveau des villes sur vos principaux marchés avant de consolider.
L’équipe SEO devrait-elle utiliser des proxies ou la SERP API ?
Si l’équipe souhaite des résultats structurés sans gestion des requêtes, la SERP API. Si elle doit observer des pages que l’API ne couvre pas, ou souhaite un contrôle total, les proxies. De nombreuses agences utilisent les deux.
Comment facturer les clients pour la collecte ?
Donnez à chaque client son propre plan, ou son propre sous-compte sur un plan partagé, et facturez à partir de cette utilisation. Le panneau et l’API rapportent l’utilisation par plan et par sous-compte, ce qui rend l’attribution au niveau client claire.
En résumé
Les agences gèrent trois charges de travail de collecte qui diffèrent par le modèle de session, le poids et le ciblage, et partagent une seule question : ce que voit un véritable utilisateur sur ce marché. Y répondre avec un seul réseau et un seul modèle de ciblage rend les trois disciplines comparables, supprime deux intégrations, et place les dépenses dans une seule unité.
Consolidez les charges de travail, pas les clients. Gardez chaque client dans son propre plan ou sous-compte, et son propre espace de travail lorsque la facturation l’exige, enregistrez le point d’observation dans chaque livrable, et laissez les identifiants, et non le fournisseur, exprimer la différence entre une vérification SEO et un parcours publicitaire. Le produit lui-même se trouve sur la page residential proxies, avec les tarifs sur la pricing page.