Comment extraire les données de Google Shopping avec des proxys

Extraire les données de Google Shopping consiste à collecter des données structurées de produits (titres, prix, vendeurs, évaluations et notes de livraison) à partir des résultats de Google Shopping, à grande échelle. Comme ces résultats sont fortement protégés et localisés, le faire de façon fiable exige des IP rotatives et un géociblage précis plutôt qu’un scraper unique utilisant une seule connexion.

Ce guide privilégie le code. Il explique les requêtes géociblées, le routage via des proxys spécifiques à chaque pays, l’analyse de fiches produits dont Google brouille délibérément le balisage, la pagination, les nouvelles tentatives et les délais d’attente face aux limites de débit, une solution de repli avec navigateur headless qui gère la boîte de dialogue de consentement, un modèle de données propre avec export CSV, un suivi de l’historique des prix et une planification de la surveillance. Il reste aussi honnête sur la réalité des systèmes anti-bot, sur le compromis entre un scraper fait maison et une API SERP payante, ainsi que sur les limites juridiques à respecter.

DataImpulse est un fournisseur de proxys éthique qui propose plus de 90 millions d’adresses IP résidentielles, mobiles et de datacenter dans 195 pays. Son modèle de paiement à l’usage commence à 1 dollar par GB, sans expiration du trafic. Ce service est utilisé pour le web scraping, la vérification des publicités, la surveillance des prix, l’étude de marché et la gestion de comptes multiples.

Quelles données pouvez-vous extraire de Google Shopping ?

Google Shopping affiche des fiches produits avec plusieurs champs structurés utiles pour la tarification et l’étude de marché. Chaque résultat comporte généralement un ensemble cohérent d’attributs que vous pouvez extraire et normaliser en lignes.

• Détails du produit : titre, extrait de description, marque, modèle et URL de l’image du produit.
• Prix : le prix affiché, la devise et, parfois, une fourchette de prix selon les vendeurs.
• Vendeur : le nom du marchand et, sur la page de détail du produit, une liste de vendeurs concurrents proposant le même article.
• Évaluations et avis : la note moyenne en étoiles et le nombre d’avis lorsqu’ils sont présents.
• Disponibilité et livraison : l’état du stock et les notes de livraison qui varient selon la région.

Les champs exacts évoluent chaque fois que Google modifie sa mise en page, donc votre analyseur doit donc accepter les valeurs manquantes et un balisage évolutif. Traitez chaque champ comme facultatif et validez les types après l’extraction plutôt que de supposer qu’une évaluation ou un vendeur est toujours présent. Comme un même produit peut apparaître à des prix différents dans des pays différents, concevez votre schéma autour d’une clé (produit, pays, horodatage) dès le départ plutôt que d’ajouter la géographie plus tard.

Comment envoyer une requête géociblée à Google Shopping ?

Pour envoyer une requête géociblée, appelez le point d’accès de recherche de Google avec l’indicateur de l’onglet achats et les paramètres régionaux, puis reproduisez les signaux d’IP et de paramètres d’un véritable acheteur. Les deux paramètres les plus importants sont gl (le pays, par exemple gl=de pour l’Allemagne) et hl (la langue de l’interface, par exemple hl=de). Un troisième paramètre utile est location, à intégrer au contexte de la requête, mais gl associé à une IP de sortie correspondante fait l’essentiel du travail.

Définir uniquement les paramètres ne suffit pas, car Google lit aussi l’IP de la requête pour décider quels prix et vendeurs afficher. La requête minimale ci-dessous envoie des en-têtes réalistes et le couple de paramètres régionaux. Elle est délibérément sans proxy pour que vous puissiez voir l’appel de base avant d’ajouter une couche d’IP.

import requests

def build_params(query, country="us", lang="en", start=0):
    return {
        "q": query,
        "tbm": "shop",   # shopping vertical
        "gl": country,    # country bias, e.g. de, gb, fr
        "hl": lang,       # interface language
        "num": 40,        # results per page (soft cap)
        "start": start,   # pagination offset
    }

HEADERS = {
    "User-Agent": (
        "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
        "AppleWebKit/537.36 (KHTML, like Gecko) "
        "Chrome/124.0 Safari/537.36"
    ),
    "Accept-Language": "en-US,en;q=0.9",
}

resp = requests.get(
    "https://www.google.com/search",
    params=build_params("wireless headphones", country="us", lang="en"),
    headers=HEADERS,
    timeout=30,
)
print(resp.status_code, len(resp.text))

Gardez l’en-tête Accept-Language aligné avec hl. Une page de prix allemande demandée avec un en-tête de langue anglaise est une incohérence qui paraît peu naturelle et peut renvoyer la mauvaise devise. Lorsque le volume augmente, cette fonction de base devient le seul endroit où la configuration régionale est décidée, ce qui assure la cohérence de tous les appels en aval.

Comment router les requêtes via des proxys ciblés par pays ?

Vous routez via un proxy géociblé en pointant requests vers une seule passerelle et en encodant le pays cible dans le nom d’utilisateur du proxy. Avec DataImpulse, la passerelle est gw.dataimpulse.com:823, et ajouter __cr.us ou __cr.de à votre nom d’utilisateur sélectionne le pays de sortie. Le ciblage par pays est inclus dans le tarif de base, tandis que le ciblage par État, ville, code postal et ASN est proposé en option payante. Si l’authentification des proxys est nouvelle pour vous, notre guide sur l’authentification des proxys couvre en profondeur le fonctionnement du nom d’utilisateur et du mot de passe.

import requests

USER = "your_login"
PASS = "your_password"
GATEWAY = "gw.dataimpulse.com:823"

def proxy_for(country):
    # __cr. pins the exit IP to that country
    cred = f"{USER}__cr.{country}:{PASS}"
    url = f"http://{cred}@{GATEWAY}"
    return {"http": url, "https": url}

resp = requests.get(
    "https://www.google.com/search",
    params=build_params("wireless headphones", country="de", lang="de"),
    headers=HEADERS,
    proxies=proxy_for("de"),
    timeout=30,
)
print(resp.status_code, len(resp.text))

L’essentiel est de modifier simultanément le pays du proxy et le couple gl/hl. Pour construire une comparaison de prix entre marchés, parcourez une liste de pays et gardez l’IP de sortie et les paramètres régionaux synchronisés afin que chaque réponse reflète un emplacement d’acheteur unique et cohérent.

MARKETS = [
    {"country": "us", "lang": "en"},
    {"country": "de", "lang": "de"},
    {"country": "gb", "lang": "en"},
    {"country": "fr", "lang": "fr"},
]

def fetch_market(query, market):
    c, lang = market["country"], market["lang"]
    return requests.get(
        "https://www.google.com/search",
        params=build_params(query, country=c, lang=lang),
        headers={**HEADERS, "Accept-Language": f"{lang};q=0.9"},
        proxies=proxy_for(c),
        timeout=30,
    )

for m in MARKETS:
    r = fetch_market("wireless headphones", m)
    print(m["country"], r.status_code, len(r.text))

DataImpulse fournit la couche IP, pas un service de scraping géré, donc le scraper vous appartient. Les proxys résidentiels rotatifs conviennent généralement ici car ils proviennent de vrais appareils de particuliers ; les proxys de datacenter sont moins chers mais plus faciles à repérer, et les proxys mobiles offrent des IP de niveau opérateur pour les cibles les plus difficiles.

Comment analyser les fiches produits de Google Shopping ?

Vous analysez les fiches produits avec une bibliothèque HTML tolérante et appuyez-vous sur des repères textuels stables plutôt que sur des sélecteurs profonds et fragiles, car Google brouille les noms de classe et changent fréquemment. Tout sélecteur que vous copiez aujourd’hui depuis les outils de développement de votre navigateur peut cesser de fonctionner en quelques semaines, alors concevez l’analyseur pour qu’il se dégrade en douceur au lieu de planter lors d’un changement de mise en page.

Une approche robuste lit chaque fiche candidate, récupère le titre et l’image à partir de la structure des balises et extrait le prix avec une expression régulière capable d’identifier la devise. Les sélecteurs ci-dessous sont des exemples réalistes, pas des garanties ; attendez-vous à les mettre à jour et gardez l’expression régulière comme solution de repli fiable.

from bs4 import BeautifulSoup
import re

# Currency-aware price matcher: symbol optional, thousands and decimals tolerated.
PRICE_RE = re.compile(r"(?:[$€£]|USD|EUR|GBP)\s?\d[\d.,]*")

def parse_cards(html):
    soup = BeautifulSoup(html, "html.parser")
    rows = []
    # These class names ROTATE; treat them as hints, keep the fallbacks.
    candidates = soup.select("div.sh-dgr__content, div.sh-dlr__list-result, div[data-docid]")
    if not candidates:
        candidates = soup.find_all("div")  # last-resort sweep
    for card in candidates:
        text = card.get_text(" ", strip=True)
        price_match = PRICE_RE.search(text)
        if not price_match or len(text) > 400:
            continue
        img = card.find("img")
        link = card.find("a", href=True)
        rows.append({
            "title": _first_text(card, ["h3", "h4"]),
            "price_raw": price_match.group(0),
            "image": img.get("src") if img else None,
            "url": link["href"] if link else None,
        })
    return rows

def _first_text(card, tags):
    for t in tags:
        el = card.find(t)
        if el and el.get_text(strip=True):
            return el.get_text(strip=True)
    return None

CURRENCY = {"$": "USD", "€": "EUR", "£": "GBP"}

def normalize_price(raw):
    if not raw:
        return None, None
    symbol = next((s for s in CURRENCY if s in raw), None)
    code = CURRENCY.get(symbol, "USD")
    digits = re.sub(r"[^\d.,]", "", raw).replace(",", "")
    try:
        return float(digits), code
    except ValueError:
        return None, code

Le balisage brouillé étant la norme ici, certaines équipes se tournent plutôt vers un DOM après rendu. Pour les compromis plus larges entre l’analyse du HTML statique et des pages rendues, consultez notre guide sur le scraping de pages web dynamiques.

Comment paginer et temporiser lorsque Google renvoie un 429 ?

Pour paginer, augmentez le décalage start par pas correspondant à la taille de page, et gérez les limites de débit en traitant le HTTP 429 (ainsi que les réponses vides ou avec CAPTCHA) comme un signal indiquant qu’il faut attendre puis réessayer avec une nouvelle IP. Google limite de façon agressive les requêtes automatisées répétées, donc la pagination et la temporisation appartiennent à la même boucle.

Parcourez les pages jusqu’à ce qu’une requête ne renvoie aucune fiche ou que vous atteigniez une limite de pages. Faites tourner l’IP de sortie entre les pages en relisant le dictionnaire du proxy, et détectez les blocages légers en vérifiant les marqueurs de consentement ou de CAPTCHA dans le corps plutôt qu’en vous fiant au seul code de statut.

BLOCK_MARKERS = ("unusual traffic", "/sorry/", "consent.google", "captcha")

def is_blocked(resp):
    if resp.status_code in (429, 503):
        return True
    body = resp.text.lower()
    return any(m in body for m in BLOCK_MARKERS)

def paginate(query, market, max_pages=5, page_size=40):
    all_rows = []
    for page in range(max_pages):
        params = build_params(query, market["country"], market["lang"],
                              start=page * page_size)
        resp = get_with_retry(
            "https://www.google.com/search",
            params=params, proxies=proxy_for(market["country"]),
        )
        if resp is None:
            break
        rows = parse_cards(resp.text)
        if not rows:
            break  # no more results
        all_rows.extend(rows)
    return all_rows

L’assistant de nouvelles tentatives ci-dessous utilise une temporisation exponentielle avec jitter, qui étale les tentatives afin qu’une rafale de workers bloqués ne ne réessaie pas tout au même instant. Chaque tentative récupère à nouveau le dictionnaire du proxy, donc un pool rotatif vous attribue une nouvelle IP à l’essai suivant.

import time, random

def get_with_retry(url, params, proxies, max_attempts=4):
    for attempt in range(max_attempts):
        try:
            resp = requests.get(url, params=params, headers=HEADERS,
                                proxies=proxies, timeout=30)
        except requests.RequestException:
            resp = None
        if resp is not None and not is_blocked(resp):
            return resp
        # exponential backoff: 2, 4, 8 seconds, plus jitter
        wait = (2 ** (attempt + 1)) + random.uniform(0, 1.5)
        time.sleep(wait)
    return None  # exhausted; caller decides what to do

Maintenez un rythme de requêtes raisonnable même lorsque les nouvelles tentatives réussissent. Un délai de base courtois entre les pages, combiné à la rotation, améliore bien plus la stabilité à long terme que de marteler le service en comptant sur les nouvelles tentatives. Nos notes sur les bonnes pratiques de web scraping traitent plus en détail du rythme et de l’hygiène des en-têtes.

Comment afficher les pages bloquées avec un navigateur headless ?

Lorsqu’une simple requête HTTP rencontre à répétition des murs de consentement ou à du contenu rendu en JavaScript, repliez-vous sur un navigateur headless qui exécute la page comme un vrai client et fermez la boîte de dialogue de consentement avant de lire le DOM. Playwright convient bien car il prend en charge les proxys par contexte et des mécanismes d’attente fiables.

Le script ci-dessous lance Chromium via un proxy DataImpulse ciblé par pays, gère la boîte de dialogue de cookies ou de consentement que les paramètres régionaux européens affichent habituellement, attend le contenu et renvoie le HTML rendu afin que vous puissiez le transmettre à la même fonction parse_cards.

from playwright.sync_api import sync_playwright

def render_shopping(query, country="de", lang="de"):
    cred_user = f"{USER}__cr.{country}"
    params = f"?q={query.replace(' ', '+')}&tbm=shop&gl={country}&hl={lang}"
    url = "https://www.google.com/search" + params
    with sync_playwright() as p:
        browser = p.chromium.launch(headless=True)
        context = browser.new_context(
            proxy={
                "server": "http://gw.dataimpulse.com:823",
                "username": cred_user,
                "password": PASS,
            },
            locale=f"{lang}-{country.upper()}",
            user_agent=HEADERS["User-Agent"],
        )
        page = context.new_page()
        page.goto(url, wait_until="domcontentloaded", timeout=45000)
        _dismiss_consent(page)
        page.wait_for_timeout(2000)
        html = page.content()
        browser.close()
        return html

def _dismiss_consent(page):
    # Consent dialogs vary by locale; try a few common accept buttons.
    for label in ("Accept all", "Alle akzeptieren", "Tout accepter",
                  "I agree", "Accept"):
        try:
            btn = page.get_by_role("button", name=label)
            if btn.count() > 0:
                btn.first.click(timeout=3000)
                page.wait_for_timeout(1000)
                return
        except Exception:
            continue

Un navigateur headless consomme plus de CPU et de mémoire qu’une simple requête, alors utilisez-le comme solution de repli ciblée pour les pages qui ont vraiment besoin d’un rendu plutôt que comme voie par défaut. De nombreuses équipes exécutent du HTTP direct pour la vitesse et n’escaladent vers Playwright que lorsque is_blocked se déclenche sans cesse. Si votre stack est en JavaScript plutôt qu’en Python, le même schéma s’applique avec Puppeteer ; voir web scraping avec JavaScript.

Comment structurer et exporter les données extraites ?

Structurez les données autour d’un enregistrement stable qui inclut toujours le marché et un horodatage de capture, puis vous exportez en CSV afin que la sortie soit facile à comparer, à charger dans un tableur ou à envoyer dans un entrepôt de données. Une dataclass fournit des annotations de type et une définition claire d’une ligne.

from dataclasses import dataclass, asdict, field
from datetime import datetime, timezone
import csv

@dataclass
class Offer:
    query: str
    country: str
    title: str | None
    price: float | None
    currency: str | None
    seller: str | None = None
    url: str | None = None
    captured_at: str = field(
        default_factory=lambda: datetime.now(timezone.utc).isoformat()
    )

def to_offers(rows, query, country):
    offers = []
    for r in rows:
        price, currency = normalize_price(r.get("price_raw"))
        offers.append(Offer(
            query=query, country=country, title=r.get("title"),
            price=price, currency=currency, url=r.get("url"),
        ))
    return offers

Pour écrire le CSV, il suffit ensuite de sérialiser les champs de la dataclass. Le mode ajout associé à une protection d’en-tête permet à une tâche planifiée d’enrichir un même fichier au fil du temps sans le réécrire.

import os

def export_csv(offers, path="google_shopping.csv"):
    if not offers:
        return
    fieldnames = list(asdict(offers[0]).keys())
    write_header = not os.path.exists(path)
    with open(path, "a", newline="", encoding="utf-8") as f:
        writer = csv.DictWriter(f, fieldnames=fieldnames)
        if write_header:
            writer.writeheader()
        for o in offers:
            writer.writerow(asdict(o))

Conserver le pays et l’horodatage sur chaque ligne vous permet ensuite de répondre à des questions comme quel marché est le moins cher aujourd’hui pour un SKU, ou comment un prix a évolué cette semaine. Cette clé de géographie et de temps est le fondement du suivi de l’historique des prix de la section suivante.

Comment suivre l’historique des prix de Google Shopping dans le temps ?

Vous suivez l’historique des prix en insérant ou en mettant à jour (upsert) chaque observation dans une petite base de données dont la clé associe produit, pays et jour, de sorte que relancer le scraper met à jour la ligne du jour au lieu de la dupliquer tout en conservant les jours précédents. SQLite suffit pour des millions de lignes et ne nécessite aucun serveur, ce qui en fait une solution autonome de surveillance.

Le schéma ci-dessous utilise une clé unique composite et un upsert ON CONFLICT. Exécuter le scraper deux fois dans une journée remplace le dernier prix enregistré pour ce (produit, pays, jour) ; l’exécuter sur plusieurs jours construit la série temporelle que pourrez ensuite représenter graphiquement.

import sqlite3

DDL = """
CREATE TABLE IF NOT EXISTS price_history (
    product   TEXT NOT NULL,
    country   TEXT NOT NULL,
    day       TEXT NOT NULL,
    price     REAL,
    currency  TEXT,
    seller    TEXT,
    captured_at TEXT,
    PRIMARY KEY (product, country, day)
);
"""

def init_db(path="prices.db"):
    conn = sqlite3.connect(path)
    conn.execute(DDL)
    conn.commit()
    return conn

def upsert_offers(conn, offers):
    sql = """
    INSERT INTO price_history
        (product, country, day, price, currency, seller, captured_at)
    VALUES (?, ?, ?, ?, ?, ?, ?)
    ON CONFLICT(product, country, day) DO UPDATE SET
        price=excluded.price,
        currency=excluded.currency,
        seller=excluded.seller,
        captured_at=excluded.captured_at;
    """
    for o in offers:
        day = o.captured_at[:10]  # YYYY-MM-DD
        conn.execute(sql, (o.title, o.country, day, o.price,
                           o.currency, o.seller, o.captured_at))
    conn.commit()

def price_trend(conn, product, country, days=14):
    cur = conn.execute(
        """SELECT day, price, currency FROM price_history
           WHERE product = ? AND country = ?
           ORDER BY day DESC LIMIT ?""",
        (product, country, days),
    )
    return cur.fetchall()

Faire correspondre les titres d’un jour à l’autre est la partie difficile en pratique, car les titres de Google varient légèrement d’une capture à l’autre. Pour une petite liste de suivi, associez les titres bruts à un identifiant produit canonique que vous contrôlez avant de faire l’upsert, plutôt que de vous fier au titre extrait comme clé stable.

Comment planifier une surveillance continue des prix ?

Pour planifier la surveillance, regroupez les étapes de récupération, d’analyse et de stockage en un seul point d’entrée et en l’exécutant à intervalles fixes avec cron, afin que les prix se rafraîchissent automatiquement sans exécutions manuelles. Une exécution une fois par jour est un choix par défaut raisonnable pour le suivi des prix ; des exécutions plus fréquentes augmentent tant le coût que le risque de blocage sans apporter beaucoup de signal supplémentaire pour la plupart des catalogues.

# run_monitor.py
def run_once(queries):
    conn = init_db()
    for query in queries:
        for market in MARKETS:
            rows = paginate(query, market, max_pages=3)
            offers = to_offers(rows, query, market["country"])
            export_csv(offers)
            upsert_offers(conn, offers)
            print(f"{query} / {market['country']}: {len(offers)} offers")
    conn.close()

if __name__ == "__main__":
    WATCHLIST = ["wireless headphones", "mechanical keyboard"]
    run_once(WATCHLIST)

Enregistrez-le ensuite avec cron. L’entrée ci-dessous exécute le moniteur chaque jour à 06:15 et journalise la sortie pour le débogage, car, sans cela, un scraper planifié échoue silencieusement.

# crontab -e
# minute hour day month weekday  command
15 6 * * * cd /opt/shopping && /usr/bin/python3 run_monitor.py >> monitor.log 2>&1

Ajoutez un léger jitter à l’intérieur de la tâche (une pause aléatoire de quelques minutes au début) afin que les requêtes n’atteignent pas Google exactement à la même seconde chaque jour. Faites tourner les pays de sortie et cadencez les requêtes comme indiqué précédemment, et surveillez dans le journal un taux croissant de blocages, qui est le signe le plus précoce que Google a renforcé ou modifié ses défenses ou que vos schémas sont devenus trop réguliers.

Quelle approche de collecte choisir : DIY, endpoints cachés, API SERP ou navigateur headless ?

Choisissez en fonction de la fragilité et de l’ingénierie que vous êtes prêt à assumer par rapport à ce que vous êtes prêt à payer par requête. Il n’y a pas de réponse unique ; le compromis honnête oppose le contrôle et le coût à la charge de maintenance et à l’exposition aux systèmes anti-bot.

La réalité anti-bot : Google défend activement ces résultats avec la limitation de débit, des CAPTCHA, des murs de consentement, un balisage brouillé et rotatif, et des signaux comportementaux. Tout scraper fait maison cassera périodiquement et nécessite une maintenance continue. Les proxys et la temporisation réduisent les blocages ; ils ne les éliminent pas. Quiconque promet un scraper Google indéblocable en permanence exagère.

API SERP contre DIY : une API SERP tierce renvoie des résultats Shopping déjà analysés en JSON et absorbe pour vous le travail d’analyse et de déblocage, à un prix par requête et avec une dépendance au fournisseur et moins de contrôle sur ce qui est exactement récupéré. Un scraper fait maison sur proxys coûte bien moins par requête et vous donne un contrôle total, mais l’analyseur, les nouvelles tentatives et la maintenance lorsque Google change vous appartiennent. Pour être clair sur la place de DataImpulse : c’est la couche de proxy sous n’importe laquelle de ces approches DIY, ni une API SERP ni un service de scraping géré. Si vous voulez zéro travail d’analyse, une API SERP est la solution la plus adaptée ; si vous voulez un faible coût et du contrôle et pouvez maintenir un scraper, le DIY avec des proxys rotatifs est plus économique. Les points d’accès JSON cachés peuvent être encore moins chers mais sont les plus fragiles de tous, puisque Google peut les modifier ou les supprimer sans préavis.

Est-il légal et éthique d’extraire les données de Google Shopping ?

Extraire des données de produits visibles publiquement est généralement considéré comme moins risqué que d’accéder à du contenu privé ou restreint, mais cela ne vous dispense pas de respecter certaines règles, et ceci n’est pas un conseil juridique. Les prix et les fiches de Google Shopping sont publics, mais la façon dont vous les collectez et les utilisez compte tout de même, et vous devriez confirmer votre cas précis avec un conseiller qualifié.

• Conditions d’utilisation : l’accès automatisé peut entrer en conflit avec les conditions d’utilisation de Google, ce qui est une question contractuelle distincte du droit d’auteur ou du droit d’accès informatique.
• Données personnelles : les fiches produits ne sont généralement pas des données personnelles, mais évitez de collecter les noms des auteurs d’avis ou d’autres identifiants, et respectez le RGPD là où il s’applique.
• Débit et charge : gardez un volume de requêtes raisonnable afin de ne pas dégrader le service que vous interrogez.
• Utilisation des données : réutiliser en masse des images ou des descriptions protégées par le droit d’auteur comporte plus de risque que d’analyser les prix comme des faits.

Du côté de la collecte, l’éthique commence par les IP que vous utilisez. DataImpulse obtient ses IP auprès d’utilisateurs qui donnent leur consentement et sont rémunérés, se conforme au RGPD et propose un accord de traitement des données, ce qui permet de bâtir un pipeline défendable. Pour un traitement plus complet du consentement, de l’origine et de la pratique responsable, consultez notre guide sur le web scraping éthique. Associez une source d’IP éthique à un rythme courtois et à un usage restreint et factuel des données, afin de limiter à la fois les risques juridiques et les risques de réputation.

Questions fréquentes

Guides connexes

• Comment extraire les données de Google Trends
• Comment extraire les annonces d’hôtels
• Extraire des pages web dynamiques

Commencez à extraire les données de Google Shopping avec des proxys fiables

Si vous êtes prêt à collecter les données de Google Shopping sur plusieurs pays, DataImpulse vous offre des IP résidentielles, mobiles et de datacenter rotatives et fixes avec le ciblage par pays inclus, à partir d’un dollar par GB. Créez un compte et faites passer votre premier scraper par un pool d’IP fiable.