Collecter des annonces sur un seul portail est un problème de scraping, et un problème bien compris. Les collecter sur trente portails répartis dans une douzaine de pays et présenter le résultat comme un inventaire unique et consultable est un tout autre travail, et la difficulté ne se situe presque jamais dans la collecte elle-même.
Elle réside dans le fait que deux portails décrivant le même appartement seront en désaccord sur sa surface, son nombre de pièces, son prix et même son type de bien, et chacun aura raison selon sa propre convention locale.
Si vous êtes encore en train de mettre en place la collecte elle-même, proxies for real estate data couvre ce terrain. Ce guide traite de ce qui se passe après l’arrivée des données.
Les champs qui ne veulent pas dire ce qu’ils disent
Cinq catégories causent la majorité des échecs d’agrégation inter-portails.
La surface. Mètres carrés, pieds carrés, et dans certains marchés des unités locales. Pire, la base de mesure diffère : surface brute intérieure, surface nette intérieure, et dans plusieurs pays une norme de mesure définie légalement qui exclut ou minore certaines parties d’un bien. Convertir les unités est trivial ; réconcilier les bases ne l’est pas, et une conversion directe mélange silencieusement les deux.
Le nombre de pièces. Dans une grande partie de l’Europe continentale, le chiffre principal compte les pièces y compris les salons plutôt que les chambres. Un “3 pièces” et un “3 bedroom” ne sont pas le même bien. Stocker les deux dans une seule colonne bedrooms produit un inventaire faux d’une manière qui ne se révèle que lorsque quelqu’un compare des marchés.
La sémantique du prix. Prix demandé, prix indicatif, “offers over”, mise à prix aux enchères, prix sur demande, et sur les marchés locatifs, la question de savoir si le chiffre inclut les charges, les services publics ou les taxes locales. Ce sont des quantités différentes portant le même symbole monétaire.
La tenure et le type de propriété. Pleine propriété, bail à long terme avec une durée restante, copropriété ou arrangements de type strata, propriété coopérative. Un bail à long terme avec une durée non expirée courte est un actif matériellement différent d’une pleine propriété au même prix.
Les taxonomies de types de biens. Chaque portail a la sienne, et elles ne se correspondent pas proprement. Décider si une maisonnette, un duplex et un appartement avec un escalier intérieur constituent une, deux ou trois catégories est une décision produit qui doit être prise une fois pour toutes et appliquée partout.
Le principe qui rend cela gérable : stockez toujours les valeurs originales de la source telles quelles, à côté de vos valeurs normalisées. Quand vous découvrez plus tard que la base de surface d’un portail diffère de ce que vous supposiez, les champs bruts vous permettent de re-dériver. Sans eux, vous devez recollecter, et les données historiques sont simplement perdues.
Construisez le modèle canonique avant le deuxième portail
L’ordre compte. Les équipes qui intègrent le portail un, puis greffent le portail deux sur son schéma, finissent avec un modèle canonique qui est en réalité le modèle du portail un portant un nom différent, et chaque intégration suivante se bat contre lui.
Un enregistrement canonique fonctionnel sépare trois couches :
| Couche | Contenu | Pourquoi séparer |
|---|---|---|
| Brute | Les champs de la source exactement tels que publiés, plus les métadonnées de collecte | Permet de re-dériver quand vos hypothèses changent |
| Normalisée | Vos unités, votre taxonomie, votre sémantique de prix, avec la conversion enregistrée | Ce que le produit interroge |
| Dérivée | Prix par unité de surface, indices calculés, scores | Recalculable, jamais la source de vérité |
Chaque champ normalisé doit porter une note indiquant quelle règle l’a produit. Quand un client demande pourquoi un bien affiche 68 mètres carrés sur votre plateforme et 73 sur le portail, la réponse doit être une consultation plutôt qu’une enquête.
La devise, et ne jamais stocker uniquement la valeur convertie
Pour les inventaires multi-pays, stockez le montant original et son code devise tel que publié, ainsi que le taux de change appliqué et la date de ce taux.
Ne stocker qu’un chiffre converti détruit l’information de manière irréversible. Les taux évoluent, des corrections sont publiées, et un client consultant une annonce historique veut le prix qui était demandé, pas ce prix ré-exprimé au taux d’aujourd’hui. Convertissez au moment de la requête à partir de l’original stocké, ou stockez la conversion avec son taux daté afin qu’elle puisse être auditée et refaite.
Réconcilier le même bien provenant de plusieurs portails
Le même bien apparaît régulièrement sur plusieurs portails, mis en ligne par différents agents, avec des photographies différentes, des descriptions différentes et parfois des prix différents. La résolution d’identité est ce qui transforme cela en un seul enregistrement, et elle est traitée en détail dans building a real-time housing market data feed, puisque le même mécanisme y régit également le comptage de l’inventaire.
Ce qui est spécifique à l’agrégation, c’est ce que vous faites une fois les doublons regroupés : décider quelle valeur l’emporte.
Définissez une préséance de source par champ plutôt que par portail. Un portail peut avoir les chiffres de surface les plus fiables tandis qu’un autre a de meilleures photographies et un troisième met à jour les prix le plus rapidement. Un classement global unique jette cela aux oubliettes.
Ensuite, gérez explicitement les désaccords. Quand des annonces regroupées sont en désaccord sur le prix au-delà d’une tolérance, c’est un signal plutôt qu’une erreur : cela peut signifier un changement de prix qu’un agent n’a pas encore répercuté, ou un regroupement mal fait. Signalez-le, montrez la fourchette, et gardez les alternatives liées. Choisir silencieusement une valeur et écarter les autres est la façon dont un agrégateur perd la confiance.
La discipline générale de correspondance, y compris la mesure et la publication de votre taux de correspondance, est la même que celle décrite dans competitor assortment and catalog gaps.
La couverture est nationale, pas mondiale
Il n’existe pas de marché immobilier mondial ni d’ensemble de portails mondial. Chaque pays a ses propres portails leaders, son propre comportement d’agents, et ses propres conventions sur ce qui est publié publiquement. Sur certains marchés, une part importante des transactions n’apparaît jamais sur un portail public.
Traitez donc un inventaire mondial comme une union de panels nationaux, chacun avec son propre ensemble de portails défini, et enregistrez la couverture par marché plutôt qu’en agrégat. Un seul chiffre global à travers les pays masque le marché où vous avez un portail et celui où vous en avez six.
Deux règles pratiques. Ne comparez pas l’inventaire absolu entre marchés à moins que la couverture soit comparable, car vous ne mesureriez alors que votre propre panel. Et là où des flux sous licence existent pour un marché, prenez la licence : la couverture et la qualité des champs sont généralement bien meilleures que la collecte publique, et la position légale est plus simple.
La couche de collecte
Les portails localisent fortement. Ce que vous voyez, la devise affichée, la langue, parfois le site lui-même, dépend de l’endroit d’où la requête semble provenir. Un agrégateur multi-pays collectant depuis un seul point d’observation recevra silencieusement la vue d’un seul pays sur plusieurs marchés.
Avec la passerelle Shifter, le marché et la session sont placés dans les identifiants face à p.shifter.io:443 :
customer-USERNAME-country-fr-sid-listings-fr-12-ttl-600:PASSWORDcountry-fr utilise le code ISO alpha-2, sid-listings-fr-12 conserve une seule sortie sur une recherche complète y compris la pagination afin qu’un ensemble de résultats soit cohérent en interne, et ttl-600 garde cette adresse pendant dix minutes. Sans sid, la passerelle change à chaque requête, ce qui convient pour des recherches indépendantes mais pas pour une recherche paginée.
Gardez les signaux de locale cohérents avec la sortie, car un décalage change ce que certains portails retournent, et gardez des taux de requêtes ordinaires avec un vrai backoff, comme dans rate limiting and request throttling. Suivez le taux de succès de la collecte par portail et par marché en parallèle des annonces, car un portail qui commence silencieusement à retourner moins de résultats ressemble exactement à un marché avec moins d’offre.
La complétude des champs est une métrique de qualité, pas un détail
Les portails diffèrent énormément dans la façon dont ils remplissent les champs optionnels. Un agrégateur qui traite un champ manquant comme absent plutôt que comme non publié rapportera, par exemple, qu’un marché n’a presque aucun bien avec une note énergétique alors qu’en réalité un portail ne l’expose tout simplement pas.
Notez la complétude par portail et par champ, publiez-la en interne, et utilisez-la pour choisir la préséance des sources. Cela vous indique également où un flux sous licence améliorerait réellement le produit plutôt que de simplement coûter de l’argent.
FAQ
Dois-je normaliser à l’ingestion ou au moment de la requête ?
Normalisez à l’ingestion et conservez les champs bruts. La normalisation au moment de la requête est plus lente et rend l’indexation pénible, mais sans les valeurs brutes vous ne pouvez pas corriger une mauvaise règle rétroactivement.
Comment gérer les portails qui publient des pièces plutôt que des chambres ?
Stockez les deux concepts comme des champs séparés et remplissez ce que la source fournit. N’inférez pas le nombre de chambres à partir d’un nombre de pièces, et ne laissez pas un filtre produit interroger un champ qui n’est rempli que sur certains marchés.
Une seule taxonomie canonique de type de bien est-elle réaliste à travers les pays ?
Une taxonomie peu profonde l’est. Gardez le niveau supérieur restreint et portable, et placez la spécificité locale dans un champ secondaire plutôt que de la forcer dans la taxonomie principale.
Quelle est la chose à plus forte valeur à corriger en premier ?
La base de surface et la sémantique du prix. Elles affectent chaque métrique dérivée, et les erreurs qu’elles contiennent sont invisibles jusqu’à ce que quelqu’un compare deux marchés.
En résumé
L’agrégation inter-portails est un problème de normalisation déguisé en problème de scraping. La collecte est la partie déjà résolue.
Construisez le modèle canonique avant la deuxième intégration, conservez les valeurs brutes de la source pour toujours, stockez la devise originale avec un taux daté, définissez la préséance de source par champ plutôt que par portail, traitez les désaccords comme un signal plutôt qu’une erreur, et enregistrez la couverture par marché car il n’existe pas de panel mondial. La vue produit se trouve sur la page large-scale data gathering, avec les tarifs sur la pricing page.