Scraping des données d'évaluations, de loyers et d'hypothèques pour les plateformes PropTech

Les équipes PropTech ont tendance à décrire leur besoin en données comme des « données immobilières », comme si les évaluations, les loyers et les taux hypothécaires étaient trois colonnes d’une seule table. Ce sont trois problèmes différents. Ils proviennent de sources différentes, portent des contraintes de licence et de confidentialité différentes, et, surtout, ils signifient des choses différentes.

Les échecs qui découlent du fait de les traiter comme un seul jeu de données ne sont pas des échecs de collecte. Ce sont des échecs d’étiquetage, et ils apparaissent bien plus tard, quand un utilisateur conteste un chiffre que votre produit a présenté comme un fait.

Trois types de données, trois réalités d’approvisionnement

Avant d’écrire un collecteur, sachez clairement lequel de ces éléments vous acquérez réellement, car la réponse détermine à la fois la méthode et ce que vous pouvez affirmer.

Type de donnée	Source faisant autorité	Ce que le web vous donne	Ce que ce n’est pas
Prix de transaction	Registres publics : cadastre, actes, rôles d’évaluation	Prix de vente, dates de transfert, attributs de parcelle	Pas la valeur marchande actuelle
Valeurs évaluées	Rôles de l’évaluateur fiscal	Une évaluation à des fins fiscales	Pas une valorisation de marché
Estimations de portail	Le modèle propre du portail	Le résultat d’un modèle propriétaire	Pas une expertise, pas un fait
Loyers demandés	Annonces actives	Ce que les propriétaires demandent aujourd’hui	Pas ce que les locataires paient
Loyers effectifs	Jeux de données sous licence, données d’opérateurs	Rarement publics	Non déductibles des annonces
Taux hypothécaires	Pages de taux des prêteurs, séries statistiques officielles	Taux publiés par produit et par palier	Pas le taux obtenu par un emprunteur donné

La discipline la plus utile en matière de données PropTech consiste à garder « observé », « évalué », « demandé » et « estimé » dans des colonnes séparées et à ne jamais les laisser se fondre dans un seul champ appelé value.

Commencez par les sources faites pour être utilisées

Descendez cet ordre, et n’atteignez le bas que pour ce que les couches supérieures ne couvrent véritablement pas.

D’abord les sources officielles et en masse. Les cadastres, les bureaux d’évaluation et les agences statistiques publient fréquemment des fichiers en masse ou des API. Elles font autorité, elles sont autorisées, et elles portent un historique que vous ne pouvez pas reconstituer de l’extérieur. Pour les prix de transaction et les attributs de parcelle, c’est généralement toute la réponse.

Ensuite les flux sous licence. Les données des courtiers et des multi-listings sont généralement disponibles sous licence. Là où votre produit a besoin d’une couverture complète des annonces avec des champs fiables, une licence coûte moins cher que l’exposition technique et juridique de l’alternative.

L’observation du web public en dernier, pour ce que les deux premières couches ne fournissent pas : les loyers demandés et leurs concessions, l’inventaire en direct, les tableaux de taux publiés par les prêteurs, et la façon dont chacun de ces éléments diffère selon le marché.

Sauter directement à la couche du bas est l’erreur la plus courante et la plus coûteuse dans cette catégorie. Le volet annonces de ce travail est couvert dans proxies pour les données immobilières.

Évaluations : ne jamais présenter un modèle comme une mesure

Les estimations de portail sont des résultats de modèle entraînés sur des données que vous ne pouvez pas voir, avec des distributions d’erreur que le portail peut publier ou non. Elles sont utiles comme caractéristique dans votre propre modèle et ne constituent pas une évaluation.

Trois règles rendent cela défendable. Stockez l’estimation avec sa source et la date à laquelle elle a été observée, jamais comme un simple chiffre nu. Ne la réétiquetez pas : une estimation est une estimation, pas une « valeur de marché ». Et si votre propre produit produit une évaluation, publiez un intervalle de confiance à ses côtés, car une estimation ponctuelle présentée sans cela sera lue comme une précision que vous n’avez pas.

Pour tout ce qui s’approche d’une évaluation formelle, la donnée collectée est une entrée dans un processus professionnel, pas un substitut à celui-ci.

Loyers : ce qui est demandé n’est pas ce qui est obtenu, et la concession est dans le texte

Les loyers d’annonce sont des loyers demandés. Dans un marché mou, ils dépassent ce que les locataires paient réellement, et l’écart, c’est là où se logent les concessions : un mois gratuit, des frais levés, une place de parking incluse, un bail plus court à un prix différent.

Ces concessions se trouvent généralement dans la description en texte libre plutôt que dans un champ structuré, ce qui signifie qu’une série de loyers demandés construite à partir du seul champ de loyer est systématiquement fausse précisément dans les conditions que l’on cherche le plus à mesurer. Analysez la description à la recherche du langage de concession et stockez-le comme son propre champ, même si tout ce que vous pouvez extraire est un indicateur et la phrase brute.

Deux précautions pratiques supplémentaires. Normalisez vers une unité comparable, typiquement le loyer par période et par nombre de chambres ou par surface au sol, car une médiane sur des types d’unités mixtes mesure autant le mélange que le marché. Et gardez séparées les observations au niveau de l’unité et au niveau de l’immeuble, car un immeuble affichant une unité n’est pas un immeuble louant à ce prix.

Données hypothécaires : les taux forment une matrice, pas un nombre

Les taux publiés par les prêteurs varient selon le produit, le terme, la tranche de ratio prêt/valeur, le palier de l’emprunteur, la région et parfois le canal. Un scraper qui stocke « le taux » depuis la page d’un prêteur a capturé une cellule d’une matrice et jeté les axes.

Enregistrez le produit, le terme, la tranche de LTV, toute condition d’emprunteur énoncée, les points ou frais, si le chiffre est un taux nominal ou un APR, la date d’effet indiquée par le prêteur, et la date à laquelle vous l’avez observé. La distinction entre nominal et APR est celle qui provoque le plus de confusion en aval, car les deux ne sont pas comparables et tous deux apparaissent sur la même page.

Les séries statistiques officielles des banques centrales et des agences du logement sont la vérité de terrain permettant de vérifier la cohérence de votre collecte. Quand votre moyenne collectée diverge de la série publiée, c’est généralement la collecte qui a changé.

Une limite qui n’est pas négociable : collectez les taux et les conditions publiés, jamais des données au niveau de l’emprunteur. Les demandes individuelles, les dossiers de crédit et les détails financiers personnels ne sont pas des données du web public, et rien dans une feuille de route PropTech ne justifie de les poursuivre.

La couche de collecte

Deux propriétés de ces sources font du point de vue une partie intégrante de la méthode.

Les tableaux de taux des prêteurs et le contenu des portails sont régionalisés, de sorte que le taux ou l’annonce que vous voyez dépend de l’endroit d’où la requête semble provenir. Et les taux en particulier peuvent différer selon l’État ou la région au sein d’un même pays, ce qui signifie qu’un point de vue national unique rapporte silencieusement les taux d’une région comme étant ceux du marché.

Avec la passerelle Shifter, le point de vue et la session vont dans les identifiants face à p.shifter.io:443 :

customer-USERNAME-country-us-state-tx-sid-rates-tx-11-ttl-600:PASSWORD

country-us et state-tx placent la requête dans le marché dont vous lisez les taux, sid-rates-tx-11 maintient une sortie sur toute la durée du parcours d’un tableau de taux afin que chaque cellule d’un instantané provienne d’une seule session, et ttl-600 conserve cette adresse pendant dix minutes. ttl ne fait quoi que ce soit qu’accompagné de sid ; sans identifiant de session, la passerelle tourne à chaque requête, ce qui convient pour des recherches indépendantes mais pas pour un tableau paginé. Le compromis est exposé dans proxies résidentiels fixes vs rotatifs.

Ajoutez strict-true quand une correspondance régionale exacte compte plus que l’obtention d’une réponse, afin que la passerelle renvoie un 502 plutôt que de vous servir silencieusement une région voisine.

La cadence doit suivre la vitesse à laquelle chaque série évolue réellement. Les taux des prêteurs justifient une collecte quotidienne et parfois infrajournalière. Les annonces et les loyers demandés sont quotidiens. Les registres publics se mettent à jour selon leur propre calendrier, souvent hebdomadaire ou mensuel, et les collecter plus vite qu’ils ne publient produit simplement des lignes en double. Gardez des taux de requête ordinaires avec un vrai backoff, comme dans limitation de débit et régulation des requêtes.

Le schéma qui vous garde honnête

Chaque enregistrement doit porter, en plus du chiffre lui-même : le type d’observation issu du tableau ci-dessus, la source, la date d’effet indiquée par la source, la date à laquelle vous l’avez observée, le marché et l’emplacement de sortie depuis lequel vous avez observé, et un indicateur de confiance ou de validation.

La date d’effet et la date d’observation sont des champs différents, et les confondre est un vrai bug. Une fiche de taux d’un prêteur ayant pris effet mardi dernier, collectée aujourd’hui, est un taux de mardi. Un indice construit sur les dates d’observation montrera un mouvement qui n’a pas eu lieu au moment où votre robot d’indexation était en retard.

L’argument général en faveur de l’enregistrement du lieu et du moment d’une observation se trouve dans l’argumentaire pour une norme de point de vue.

Confidentialité et conformité

Les données immobilières sont plus proches des individus que la plupart des données web commerciales, et les règles varient fortement selon la juridiction.

Les registres publics nomment les propriétaires dans certains pays ; ailleurs, cette information est restreinte. Traitez les noms de propriétaires, les coordonnées et tout ce qui identifie un occupant comme des données personnelles par défaut, ne les collectez que là où vous avez une base légale, et supprimez-les à l’ingestion là où votre produit n’en a pas besoin. Un indice de loyers n’a pas besoin du nom d’un locataire.

Respectez les conditions de chaque source, gardez des volumes proportionnés, et là où une licence est la voie prévue, prenez la licence. Le cadrage général se trouve dans proxies résidentiels et conformité RGPD et proxies résidentiels éthiques pour la collecte de données IA.

FAQ

Puis-je utiliser les estimations de portail comme évaluations dans mon produit ?

Pas comme évaluations. Comme caractéristique, ou comme estimation tierce clairement attribuée, oui, sous réserve des conditions du portail. L’étiquetage est la partie qui compte.

Comment obtenir des loyers effectifs plutôt que des loyers demandés ?

Généralement via des jeux de données sous licence ou des partenariats avec des opérateurs. Les annonces ne les contiennent pas, et les déduire des loyers demandés relève de la modélisation, ce qui devrait être communiqué comme tel.

Le scraping des registres publics est-il nécessaire si des fichiers en masse existent ?

Non, et les fichiers en masse sont meilleurs : ils font autorité, sont complets et autorisés. N’utilisez le web que pour ce qui n’est pas publié en masse.

Pourquoi nos taux hypothécaires diffèrent-ils de la moyenne nationale publiée ?

Généralement parce que vous avez collecté une seule région, une seule tranche de LTV ou un seul palier d’emprunteur et fait une moyenne sur un mélange non représentatif. Enregistrez les axes et le désaccord s’explique généralement de lui-même.

En résumé

Les évaluations, les loyers et les taux hypothécaires sont trois problèmes de collecte qui partagent un vocabulaire et rien d’autre. Les équipes qui construisent des données PropTech fiables se tournent d’abord vers les sources officielles et sous licence, utilisent le web public pour le résidu, et gardent observé, évalué, demandé et estimé comme des champs séparés et étiquetés, avec à la fois une date d’effet et une date d’observation.

Collectez chaque marché depuis ce marché, gardez les sessions cohérentes sur un tableau ou un ensemble de résultats, et ne laissez jamais un résultat de modèle être stocké comme un fait. Transformer ces observations en une série de marché en direct est couvert dans construire un flux de données du marché immobilier en temps réel. La vue produit se trouve sur la page proxies résidentiels pour la collecte de données, avec les tarifs sur la page de tarification.