Zillow scraping : identifiants, prix et historique

Zillow scraping pose une question de modèle avant celle de la collecte : quel enregistrement compare-t-on exactement ? Bien physique, annonce source, offre et observation sont des entités différentes. Écraser une ligne selon son URL actuelle peut masquer une republication, confondre loyer et prix de vente, puis faire d’un échec d’actualisation un faux événement de marché. BotBrowser fournit des entrées déclarées de navigateur et de géographie pour les observations autorisées ; il ne fournit pas les données immobilières et n'accorde pas l’accès à un portail. Utilisez une source approuvée, ne conservez que l’historique permis et rattachez chaque changement à une occurrence d’annonce définie.

Résumé

• Clé d’annonce, référence du bien et URL ont des sens différents. Vérifiez leur sémantique sans supposer une clé globale permanente.
• Comparez les prix seulement si devise, type de transaction et base tarifaire correspondent. Des nombres égaux peuvent désigner des offres différentes.
• Séparez statut source et résultat d’observation. Carte absente, délai dépassé ou erreur d’analyse ne prouvent ni vente ni retrait.
• Traitez une actualisation permise comme une comparaison typée avec une observation acceptée, pas comme un écrasement inconditionnel.
• API officielle et norme ne donnent pas à elles seules accès ou rétention indéfinie. Appliquez l’accord réel et arrêtez si la permission manque.

Sommaire

• Établir l’accès autorisé aux annonces
• Séparer bien, annonce et identité d’observation
• Comparer les prix avec leur sens transactionnel
• Conserver les statuts sans inventer d’événements de marché
• Appliquer une comparaison typée à chaque actualisation
• Borner les rôles du navigateur et du stockage
• Conclusion pratique

Établir l’accès autorisé aux annonces

La documentation MLS Listings de Zillow Group présente Bridge Listing Output comme un accès aux annonces MLS normalisées selon RESO Data Dictionary. Elle précise que chaque partenaire MLS aux États-Unis et au Canada décide de l’accès et que la plateforme fonctionne actuellement sur invitation. L’intégration documentée est une option conditionnelle, pas un droit à un jeu de données public. Lire la documentation n’établit aucun accès authentifié aux annonces.

Le catalogue développeurs répertorie des services pour le public et les partenaires dans différentes activités immobilières. Il n’établit pas qu’une application peut obtenir tous les champs ou les réutiliser librement. Identifiez fournisseur, données disponibles, champs permis et finalité avant de créer le collecteur. L’accord doit aussi résoudre rétention et redistribution. Disponibilité technique et intégration prise en charge restent moins fortes qu’une permission pour l’application précise.

RFC 9309 dit explicitement que les règles robots ne sont pas une autorisation. La visibilité publique ne règle pas davantage l’accord. Si une source interdit la collecte envisagée, n’utilisez pas le navigateur comme solution de remplacement ; choisissez une source approuvée ou renvoyez le besoin non pris en charge. Vérifiez les conditions actuelles du portail lorsqu’elles s’appliquent. Aucune clause non inspectée n’est dite vérifiée et aucun accès documentaire réussi ne vaut permission de données.

La chaîne partagée d’observations sépare collecte et analyse. L’immobilier ajoute à cette frontière les permissions et la sémantique des entités. Flux approuvé, exemple expurgé fourni et observation d’interface autorisée séparément sont des choix différents. Conservez celui qui fournit l’enregistrement. Une table commune en aval ne rend pas interchangeables droits, exhaustivité ou sens des champs.

Séparer bien, annonce et identité d’observation

RealEstateListing décrit une annonce d’une ou plusieurs offres immobilières, l’annonce globale étant représentée par une page web. Ce n’est pas un autre nom du bien physique. Le vocabulaire relève de la nouvelle zone de schema.org et ne prouve aucun balisage ou identifiant propre à Zillow. Utilisez-le pour distinguer les concepts, pas pour déduire un contrat d’extraction. Les clés doivent venir de la source approuvée et de leur sens documenté.

Composant	Preuve ou référence à conserver	Limite
Espace de noms source	Fournisseur et jeu de données réels	Des clés semblables de sources distinctes peuvent désigner des enregistrements différents
Occurrence d’annonce	Référence du fournisseur lorsqu’elle existe	Une republication ne continue pas automatiquement l’offre précédente
Bien physique	Référence étayée séparément	Clé d’annonce ou adresse commune ne donnent pas une identité universelle
Sens de l’offre	Vente ou location et base tarifaire	Prix d’achat et loyer périodique ne sont pas comparables
Observation	Temps source si fourni, temps d’observation et résultat	Collecte n’est ni publication ni transaction
Emplacement de référence	URL réelle ou autre référence prise en charge	Changer d’URL ne crée pas automatiquement bien ou annonce

Le vocabulaire Place décrit les propriétés physiques, dont l’adresse. Une adresse observée aide au rapprochement, mais ne prouve pas que deux annonces concernent le même lot, la même parcelle juridique ou la même offre. Immeubles partagés et formats d’adresses différents imposent cette distinction. Gardez l’identité résolue du bien facultative si la preuve manque. N’effacez pas les occurrences indépendantes pour une simple ressemblance d’adresses visibles.

La comparaison des identités d’offres d’emploi distingue occurrence source et entité réelle. Une offre expirée et une annonce ultérieure peuvent concerner le même bien tout en restant deux occurrences. Conservez cette distinction sauf continuité établie par la source. Une nouvelle URL ou référence pose une question de rapprochement, pas un événement de marché automatique. Si aucune clé fiable n’existe, notez l’identité provisoire et sa limite.

Le RESO Data Dictionary définit ressources, champs et valeurs cohérents pour l’interopérabilité. C’est un langage de données, pas les données ou une licence d’accès. Mappez les champs réels selon la version et la sémantique de l’intégration approuvée. Une étiquette familière ne garantit ni remplissage universel, ni actualisation simultanée, ni clé d’annonce comparable chez tous les fournisseurs.

Comparer les prix avec leur sens transactionnel

Le vocabulaire Offer sépare prix et devise et décrit la transaction par l’objet offert et la fonction commerciale. Une colonne numérique évite ainsi de porter trop de sens. Le montant exige devise, vente ou location et période ou unité réellement fournies. C’est une règle d’interprétation, pas une affirmation sur une réponse Zillow actuelle. Le contexte inconnu ne se déduit pas de la langue du navigateur ou d’un symbole monétaire.

Un exemple construit rend la distinction explicite : USD 2,500 par mois et USD 500,000 de prix demandé ne constituent pas une hausse entre observations comparables, mais des sens transactionnels différents. Deux montants identiques dans des devises différentes ne sont pas non plus un prix inchangé. Établissez même occurrence et base comparable avant de calculer un écart. Si la portée de l’offre change, conservez ce changement séparément du calcul numérique.

La recommandation sur les prix de schema.org utilise priceCurrency séparément plutôt que des symboles ambigus. Une représentation typée de valeurs permises ne doit pas inventer devise ou période absentes. Conservez le sens source et la règle de normalisation dans la rétention autorisée. Le format localisé concerne l’analyse ; changer de séparateur ne prouve pas un mouvement de marché. Chaîne affichée et montant comparable sont deux représentations.

Le champ de publication RealEstateListing définit datePosted comme date de publication de l’annonce. Elle diffère du temps d’observation et de la date d’une révision de prix. Découvrir un montant aujourd’hui ne prouve pas qu’il a changé aujourd’hui. Si la source fournit un temps d’effet, conservez son sens distinct. L’analyse historique ne doit pas remplacer silencieusement le temps d’événement manquant par le traitement pour parler de chronologie des transactions.

Conserver les statuts sans inventer d’événements de marché

Le dictionnaire RESO organise champs et valeurs, mais l’application doit utiliser le mappage réel pris en charge. Conservez statut brut et règle d’interprétation sans supposer un graphe universel de transitions. Un état hors marché ne prouve pas à lui seul une vente achevée. Ne pas trouver une carte établit moins encore : une absence dans cette observation, pas le résultat juridique ou commercial du bien.

Événement construit	Observation permise	Interprétation acceptée
Premier enregistrement accepté	Annonce L, prix demandé USD 500,000, statut source active	Observation de référence, pas nouvelle transaction achevée
Enregistrement ultérieur comparable	Même annonce L, prix demandé USD 490,000	Révision observée du prix demandé avec temps d’observation
Échec d’actualisation	Aucun enregistrement source accepté	Incident de collecte ; ni suppression de prix ni changement de statut
Carte absente d’une liste	Aucune observation de L dans cette liste	Absence ; vente et retrait non établis

La table est un exemple applicatif, pas une séquence mesurée sur Zillow ou un MLS. La seconde ligne établit une observation comparable de prix demandé, pas un prix final ou une négociation. L’échec doit préserver la valeur précédente comme preuve historique selon l’accord, sans la présenter comme observation fraîche réussie. Dernière valeur acceptée et dernier résultat de collecte répondent à des questions distinctes.

La sémantique RealEstateListing et Offer distingue annonce et offres d’une transaction réelle achevée. Exigez une preuve source explicite et correctement bornée pour toute classification vendue ou retirée. Si la source ne l’établit pas, conservez inconnu ou le statut brut plus limité. L’absence répétée peut motiver l’enquête, mais ne fait pas d’une inférence non étayée un fait source. Ne faites pas des échecs des statistiques de marché.

Appliquer une comparaison typée à chaque actualisation

L’actualisation permise doit établir source et occurrence prévues avant de valider représentation et champs. Seules les observations acceptées et comparables entrent dans la comparaison. Le modèle de champs RESO informe le mappage sans décider de l’acceptation. Précisez si l’incomplet est rejeté ou conservé avec des champs inconnus. Aucune politique ne doit faire silencieusement d’un échec un remplacement vide.

La règle ordonnée est concrète : identifier l’occurrence ; classer le résultat ; interpréter les champs ; comparer des valeurs du même type ; enregistrer les écarts étayés ; conserver les questions séparément. Si l’identité est incertaine, reportez la comparaison au lieu de fabriquer une révision. Si devise ou base diffèrent, classez le changement de sens avant l’arithmétique. Si seule l’URL change, inspectez sa sémantique au lieu de créer un autre bien par défaut.

Le modèle d’observation des annonces d’emploi conserve les répétitions sous une clé source. L’immobilier exige cet historique en plus des prix et statuts typés. Un enregistrement accepté inchangé est une observation supplémentaire, pas une transaction réelle dupliquée. Un échec est un incident, pas la disparition de tous les champs. Dédupliquer le stockage ne doit pas effacer entité, enregistrement et preuves de moments distincts.

Dans un test maîtrisé, rejouez les quatre événements de la table et vérifiez leur sens. Le résultat attendu après la référence est une révision comparable, un incident et une absence non résolue. Aucune vente, nouveau bien ou suppression de prix ne doit apparaître. Cette acceptation teste le modèle sans collecter le contenu protégé. Gardez sa nature synthétique explicite ; réussir ne prouve ni cadence actuelle ni exhaustivité d’un fournisseur.

Borner les rôles du navigateur et du stockage

La documentation GeoIP de BotBrowser décrit recherche géographique, prérequis de profil et routage proxy. Ce sont des entrées d’environnement pour l’observation autorisée. Elles n’établissent ni position du bien, ni devise, ni exhaustivité géographique. Vérifiez indépendamment l’état réel permis. Une région configurée ne remplace pas un champ d’annonce absent.

Le guide de configuration des profils décrit les réglages fondés sur un profil. Utilisez la configuration prise en charge et vérifiez son chargement lors d’une observation réelle. La configuration seule n’établit pas une observation du portail. Des entrées stables rendent l’environnement plus explicite, sans accès accordé ni contenu identique garanti. Changement source et incident navigateur restent deux explications possibles.

La référence IndexedDB de MDN décrit un stockage transactionnel de données structurées indexées par clé, limité par l’origine. Il peut servir un exemple local ou des observations permises, pas faire du navigateur une autorité historique immobilière. Limites et éviction comptent aussi ; persistance locale ne garantit pas l’archivage indéfini. Choisir une base n’élargit pas la rétention et n’autorise pas un jeu de données manquant.

Conservez contenu et preuves opérationnelles selon l’accord. Si l’historique brut ne peut être stocké, redessinez la trace dans le périmètre autorisé plutôt que de renommer une archive complète de réponses. RFC 9309 ne change pas robots en droits d’archive. Arrêtez si permission ou preuve requise manque. Une autre identité de navigateur ou une transaction de base n’établissent ni autorisation ni fait de marché manquants.

Questions fréquentes

Une URL immobilière est-elle une clé permanente fiable ?

Seulement si la source approuvée établit ce sens. URL, occurrence et bien physique répondent à des questions différentes. Conservez références et incertitude sans faire de tout changement d’URL un nouveau bien.

Une annonce absente signifie-t-elle une vente ?

Non. Carte absente, échec ou observation incomplète ne prouvent pas une vente. Conservez le résultat et exigez une preuve explicite du cycle de vie requis.

Peut-on comparer tous les prix comme un nombre ?

Non. Devise, vente ou location, période et unité doivent être comparables. Le contexte manquant ne se déduit pas de la langue ou de la ponctuation affichée.

Une API officielle ou BotBrowser accordent-ils l’accès ?

Non. L’option MLS documentée dépend des partenaires et d’une invitation. BotBrowser fournit des entrées, pas le contenu ou la permission. L’accord détermine accès et rétention.

Sources

• Zillow Group MLS Listings
• Catalogue développeurs Zillow Group
• RESO Data Dictionary
• schema.org RealEstateListing
• schema.org Place
• schema.org Offer
• IndexedDB API de MDN
• RFC 9309
• Base GeoIP de BotBrowser
• Configuration des profils BotBrowser

Conclusion pratique

Construisez l’historique permis avec occurrences source et observations acceptées, pas par écrasement des URL. Comparez les prix avec leur sens transactionnel, conservez statuts bruts et inconnus, puis séparez échecs et marché. Navigateur et stockage soutiennent l’application ; source approuvée et accord déterminent les données disponibles, leur sens et l’historique permis.