Les équipes qui collectent déjà des données de marketplace ont tendance à aborder Walmart comme elles ont abordé Amazon, et les chiffres ressortent faux d’une manière facile à manquer. Rien ne plante. Les prix semblent plausibles. Ils ne correspondent simplement pas à ce qu’un acheteur à Dallas ou Tampa voit réellement, et l’écart est systématique plutôt qu’aléatoire.
La raison est structurelle. Walmart est un réseau de magasins avec un site web devant, pas un catalogue national. Le prix et la disponibilité se résolvent par rapport à un magasin spécifique, et le magasin est choisi pour vous à partir de signaux que vous ne contrôlez peut-être pas.
Le magasin est l’unité de vérité
Pour une grande part de l’assortiment, trois éléments varient selon le magasin :
Prix. Les rollbacks, les liquidations et la tarification régionale font que le même article peut afficher des prix différents dans deux magasins situés à soixante kilomètres l’un de l’autre.
Disponibilité. Le stock en magasin est par définition propre à chaque emplacement, et les options d’expédition et de retrait proposées dépendent du magasin et du centre de traitement des commandes auquel la session est liée.
Assortiment. Certains articles ne sont tout simplement pas proposés dans certains magasins, ce qui apparaît comme un produit manquant plutôt que comme une rupture de stock.
Si votre couche de collecte ne fixe pas de magasin, le site en choisit un pour vous en fonction de la localisation apparente de la requête, et il peut en choisir un différent demain. Le résultat est une série temporelle où les variations de prix sont en partie réelles et en partie dues au fait que le magasin change silencieusement sous vos pieds. C’est pire que des données manquantes, parce que cela ressemble à une tendance.
Le même piège s’applique à tout détaillant avec exécution locale. La version générale de cet argument se trouve dans le suivi de la disponibilité et du stock des produits.
Deux signaux déterminent le magasin que vous obtenez
Il y a la localisation d’où votre requête semble provenir, c’est-à-dire l’adresse IP et sa géolocalisation, et il y a le magasin ou le code postal que vous sélectionnez explicitement dans la session. Ce sont des mécanismes différents et ils doivent concorder.
Une IP de datacenter en Virginie avec une session prétendant viser un magasin de Phoenix forme une paire incohérente. Cela fonctionne parfois, se résout parfois silencieusement vers autre chose, et c’est exactement le genre de signal que les systèmes anti-bot du commerce de détail pondèrent lourdement. Une IP résidentielle dans la métropole que vous ciblez rend la paire cohérente, ce qui est le but : vous reproduisez un acheteur, vous n’affirmez pas une localisation.
Fixer la géographie, puis fixer la session
Avec la passerelle Shifter, le ciblage se fait dans le nom d’utilisateur plutôt que via un appel API séparé. Pointez vers p.shifter.io:443 et encodez la localisation et la session dans les identifiants :
customer-USERNAME-country-us-city-dallas-sid-store2354-ttl-600:PASSWORDTrois éléments comptent ici. country-us et city-dallas placent la sortie dans la bonne métropole. sid-store2354 nomme une session persistante, de sorte que chaque requête étiquetée avec cet identifiant sort de la même IP. ttl-600 conserve cette IP pendant dix minutes, assez longtemps pour sélectionner un magasin, parcourir une catégorie et lire un ensemble de pages produit sans que la localisation ne change en cours de crawl.
Notez que ttl n’a de sens qu’avec sid. Sans identifiant de session, il n’y a rien à maintenir en vie, et la rotation par défaut s’applique.
Le modèle mental à retenir : une session persistante par magasin, réutilisée pour les articles que vous vérifiez pour ce magasin, plutôt qu’une session par requête. Faire tourner la session à chaque page produit est l’erreur de configuration la plus courante ici, parce que cela redéclenche constamment la résolution du magasin et produit exactement la dérive que vous cherchiez à éliminer. Les compromis sont exposés dans sessions persistantes vs rotatives.
Les villes utilisent des noms en minuscules avec des underscores pour les espaces, et les pays utilisent les codes ISO alpha-2. Si un filtre est trop restrictif pour être satisfait, la passerelle répond 502 plutôt que de vous donner silencieusement une sortie ailleurs, ce qui est le comportement souhaité quand la précision du magasin est tout l’enjeu.
Enregistrer le magasin, pas seulement le prix
Le schéma est ce qui fait gagner ou perdre la plupart des panels Walmart. Une ligne indiquant “l’article X coûtait 14,98 $ mardi” n’est pas une observation exploitable, parce qu’elle omet ce qui détermine le prix.
Au minimum, capturez :
- l’identifiant de l’article
- l’identifiant du magasin auquel la session s’est effectivement résolue
- le prix, et séparément tout prix barré ou prix antérieur
- l’état de disponibilité, décomposé en magasin, retrait et expédition
- le vendeur, car les annonces tierces se comportent différemment des annonces en propre
- le pays et la ville d’où la requête est sortie
- l’horodatage de collecte en UTC
L’identifiant du magasin doit être relu depuis la réponse plutôt que supposé à partir de ce que vous avez demandé. Ce seul champ transforme un saut de prix inexplicable en un changement de magasin visible, et c’est la différence entre un panel que vous pouvez défendre et un graphique dont vous devez vous excuser.
Distinguer les quatre façons dont une vérification échoue
La collecte dans le commerce de détail produit des modes d’échec qui ressemblent tous à “pas de données” à moins de les séparer :
Bloqué. Vous avez reçu un challenge ou une page intermédiaire. L’observation est manquante, et l’article doit être retenté, pas enregistré comme indisponible.
Rupture de stock. Une page valide indiquant que l’article est indisponible dans ce magasin. C’est une donnée réelle et elle appartient à la série.
Non proposé. L’article n’existe pas dans l’assortiment de ce magasin. Également réel, et différent de la rupture de stock.
Mauvais magasin. La page s’est affichée, mais pour un magasin que vous n’avez pas demandé. C’est le cas dangereux, parce qu’il produit une ligne d’apparence propre avec la mauvaise valeur.
Seul le premier justifie une nouvelle tentative. Confondre les deux cas du milieu aplatit de véritables différences d’assortiment, et traiter le quatrième comme valide est la façon dont de mauvais chiffres finissent sur un tableau de bord. Côté transport, 407 signifie des identifiants incorrects ou un indicateur de ciblage mal formé, 502 signifie qu’aucune sortie ne correspond à votre filtre, et 509 signifie que le quota de bande passante est épuisé.
Cadence, et pourquoi elle devrait être ennuyeuse
Les panels de prix ont une forte tentation de haute fréquence. Résistez-y pour deux raisons.
La première est que le volume de requêtes contre un site de commerce de détail est le signal le plus susceptible de faire remarquer un schéma de collecte, et la solution n’est pas davantage d’IP mais un calendrier qui ressemble à de la demande plutôt qu’à un balayage. Répartissez les vérifications sur la journée, gardez une concurrence modeste par magasin, et ralentissez en cas d’erreurs plutôt que d’insister. Les mécanismes sont couverts dans limitation de débit et régulation des requêtes.
La seconde est le coût. Le trafic résidentiel est facturé à la bande passante, donc le levier est le nombre d’octets par observation, pas de requêtes par heure. Évitez les images, préférez la réponse la plus légère qui porte les champs dont vous avez besoin, et ne récupérez pas une page de catégorie entière quand vous n’avez besoin que de trois articles dedans. Un traitement plus approfondi se trouve dans réduire les coûts de bande passante des proxies.
Pour la plupart des panels de commerce de détail, une lecture quotidienne par magasin et par article suffit à détecter les mouvements qui comptent, avec une cadence plus rapide réservée à une petite liste de surveillance d’articles à forte valeur.
Dimensionner un panel Walmart
La bande passante suit un produit simple : articles suivis, fois magasins suivis, fois vérifications par jour, fois octets par vérification. Le multiplicateur de magasin est celui que l’on oublie, et c’est celui qui croît le plus vite, parce qu’ajouter vingt métropoles à un panel de cinq mille articles fait cent mille observations par passage.
Commencez avec un ensemble restreint de magasins qui reflète les marchés sur lesquels vous prenez réellement des décisions, mesurez les octets réels par vérification pendant une semaine, puis étendez. Une méthode détaillée se trouve dans estimer la bande passante proxy résidentielle mensuelle, et les tarifs actuels sont sur la page de tarification des proxies résidentiels.
FAQ
Ai-je besoin d’une IP résidentielle si je sélectionne déjà un code postal dans la session ?
Pour la cohérence, oui. Sélectionner une localisation tout en arrivant depuis une plage de datacenter dans une autre région forme une paire incohérente, et elle est traitée comme telle. La sélection explicite indique au site ce que vous voulez ; l’IP est ce qu’il croit.
Combien de magasins une session doit-elle couvrir ?
Un seul. Réutilisez une session persistante pour les articles d’un seul magasin, puis prenez une nouvelle session pour le magasin suivant. Mélanger des magasins dans une même session est ce qui produit des erreurs d’attribution.
La collecte de données Walmart est-elle différente d’Amazon ?
Les mécanismes se recoupent, mais la dimension du magasin est spécifique à Walmart et modifie le schéma. Si vous étendez un pipeline de marketplace existant, le scraping des données produit Amazon couvre les parties qui se transposent.
Qu’en est-il des annonces de marketplace tierces ?
Capturez le champ vendeur et traitez les lignes en propre et tierces comme des séries distinctes. Les mélanger produit des historiques de prix qui sautent pour des raisons qui n’ont rien à voir avec des décisions de tarification.
L’essentiel
Les données de prix et d’inventaire Walmart ne sont utiles que si elles sont rattachées à un magasin, et les rattacher à un magasin signifie contrôler à la fois la localisation apparente de la requête et la persistance de la session qui l’a résolue. Des sorties résidentielles géociblées avec des sessions persistantes vous donnent ce contrôle ; enregistrer le magasin résolu vous donne la capacité de le prouver.
Faites ces deux choses correctement et le reste du pipeline est une collecte de commerce de détail ordinaire. Faites-les mal et vous obtiendrez un tableau de bord qui est faux avec confiance et constance. Un contexte plus large sur le commerce de détail se trouve dans les proxies pour les activités e-commerce et le cas d’usage de l’intelligence tarifaire.