Das Sammeln von Angeboten aus einem einzigen Portal ist ein Scraping-Problem, und zwar ein gut verstandenes. Sie aus dreißig Portalen in einem Dutzend Ländern zu sammeln und das Ergebnis als ein durchsuchbares Inventar darzustellen, ist eine völlig andere Aufgabe, und fast nichts von der Schwierigkeit liegt im Abrufen selbst.
Sie liegt in der Tatsache, dass zwei Portale, die dieselbe Wohnung beschreiben, sich über ihre Größe, ihre Zimmerzahl, ihren Preis und sogar darüber, um welche Art von Immobilie es sich handelt, uneinig sein werden, und alle nach ihrer eigenen lokalen Konvention recht haben.
Wenn Sie noch mit der Datensammlung selbst beschäftigt sind, behandelt proxies for real estate data dieses Terrain. Dieser Leitfaden befasst sich mit dem, was passiert, nachdem die Daten eingetroffen sind.
Die Felder, die nicht bedeuten, was sie sagen
Fünf Kategorien verursachen die meisten Fehler bei der portalübergreifenden Aggregation.
Fläche. Quadratmeter, Quadratfuß und in manchen Märkten lokale Einheiten. Schlimmer noch, die Berechnungsgrundlage unterscheidet sich: brutto innen, netto innen, und in mehreren Ländern ein gesetzlich definierter Messstandard, der Teile einer Immobilie ausschließt oder abzieht. Einheiten umzurechnen ist trivial; die Grundlagen in Einklang zu bringen ist es nicht, und eine reine Umrechnung vermischt sie stillschweigend.
Zimmerzahlen. In weiten Teilen Kontinentaleuropas zählt die Kennzahl alle Zimmer einschließlich Wohnzimmer, nicht die Schlafzimmer. Eine „3 pièces“ und eine „3 bedroom“-Immobilie sind nicht dieselbe Immobilie. Beide in einer einzigen bedrooms-Spalte zu speichern erzeugt ein Inventar, das auf eine Weise falsch ist, die erst auffällt, wenn jemand Märkte vergleicht.
Preissemantik. Angebotspreis, Richtpreis, „offers over“, Auktionsmindestpreis, Preis auf Anfrage, und bei Mietmärkten, ob die Zahl Nebenkosten, Betriebskosten oder lokale Steuern einschließt. Das sind unterschiedliche Größen, die dasselbe Währungssymbol tragen.
Besitzverhältnis und Eigentumsart. Volleigentum, Erbpacht mit verbleibender Laufzeit, Strata- oder Eigentumswohnungsregelungen, genossenschaftliches Eigentum. Eine Erbpacht mit kurzer Restlaufzeit ist ein materiell anderes Vermögensobjekt als Volleigentum zum gleichen Preis.
Immobilientyp-Taxonomien. Jedes Portal hat seine eigene, und sie lassen sich nicht sauber aufeinander abbilden. Zu entscheiden, ob eine Maisonette, ein Duplex und eine Wohnung mit Innentreppe eine Kategorie oder drei sind, ist eine Produktentscheidung, die einmal getroffen und überall angewendet werden muss.
Das Prinzip, das dies handhabbar macht: Speichern Sie die ursprünglichen Werte der Quelle wörtlich, zusätzlich zu Ihren normalisierten Werten, immer. Wenn Sie später entdecken, dass die Flächenbasis eines Portals von dem abweicht, was Sie angenommen hatten, erlauben die Rohfelder eine Neuableitung. Ohne sie müssen Sie neu sammeln, und historische Daten sind schlicht verloren.
Bauen Sie das kanonische Modell vor dem zweiten Portal
Die Reihenfolge ist entscheidend. Teams, die Portal eins integrieren und dann Portal zwei an dessen Schema anflanschen, enden mit einem kanonischen Modell, das eigentlich das Modell von Portal eins unter anderem Namen ist, und jede folgende Integration kämpft dagegen an.
Ein funktionierender kanonischer Datensatz trennt drei Ebenen:
| Ebene | Inhalt | Warum getrennt |
|---|---|---|
| Roh | Die Felder der Quelle exakt wie veröffentlicht, plus die Abruf-Metadaten | Erlaubt Neuableitung, wenn sich Ihre Annahmen ändern |
| Normalisiert | Ihre Einheiten, Ihre Taxonomie, Ihre Preissemantik, mit dokumentierter Umrechnung | Was das Produkt abfragt |
| Abgeleitet | Preis pro Flächeneinheit, berechnete Indizes, Scores | Neu berechenbar, nie die Quelle der Wahrheit |
Jedes normalisierte Feld sollte einen Vermerk tragen, welche Regel es erzeugt hat. Wenn ein Kunde fragt, warum eine Immobilie auf Ihrer Plattform 68 Quadratmeter und auf dem Portal 73 zeigt, sollte die Antwort ein Nachschlagen sein und keine Untersuchung.
Währung, und niemals nur den umgerechneten Wert speichern
Speichern Sie bei länderübergreifenden Inventaren den ursprünglichen Betrag und dessen Währungscode wie veröffentlicht, plus den von Ihnen angewendeten Wechselkurs und das Datum dieses Kurses.
Nur eine umgerechnete Zahl zu speichern zerstört Informationen unwiderruflich. Kurse bewegen sich, Korrekturen werden herausgegeben, und ein Kunde, der ein historisches Angebot betrachtet, möchte den Preis sehen, der damals verlangt wurde, nicht diesen Preis neu ausgedrückt zum heutigen Kurs. Rechnen Sie zum Abfragezeitpunkt aus dem gespeicherten Original um, oder speichern Sie die Umrechnung mit ihrem datierten Kurs, sodass sie geprüft und neu berechnet werden kann.
Dieselbe Immobilie über mehrere Portale hinweg abgleichen
Dieselbe Immobilie erscheint routinemäßig auf mehreren Portalen, gelistet von verschiedenen Maklern, mit unterschiedlichen Fotos, unterschiedlichen Beschreibungen und manchmal unterschiedlichen Preisen. Identitätsauflösung ist das, was daraus einen einzigen Datensatz macht, und wird ausführlich in building a real-time housing market data feed behandelt, da dieselbe Maschinerie dort auch die Inventarzählung antreibt.
Was spezifisch für Aggregation ist, ist das, was Sie tun, sobald die Duplikate gruppiert sind: entscheiden, welcher Wert gewinnt.
Definieren Sie eine Quellenpriorität pro Feld statt pro Portal. Ein Portal mag die zuverlässigsten Flächenangaben haben, während ein anderes bessere Fotos hat und ein drittes Preise am schnellsten aktualisiert. Ein einziges globales Ranking verwirft das.
Behandeln Sie dann Widersprüche explizit. Wenn gruppierte Angebote über eine Toleranz hinaus beim Preis abweichen, ist das ein Signal statt eines Fehlers: Es kann eine Preisänderung bedeuten, die ein Makler noch nicht nachgezogen hat, oder eine fehlerhafte Gruppierung. Markieren Sie es, zeigen Sie die Spanne, und behalten Sie die Alternativen verknüpft. Stillschweigend eine auszuwählen und die anderen zu verwerfen ist der Weg, wie ein Aggregator das Vertrauen verliert.
Die allgemeine Abgleichsdisziplin, einschließlich der Messung und Veröffentlichung Ihrer Match-Rate, ist dieselbe, die in competitor assortment and catalog gaps beschrieben wird.
Abdeckung ist national, nicht global
Es gibt keinen globalen Immobilienmarkt und keinen globalen Portalsatz. Jedes Land hat seine eigenen führenden Portale, sein eigenes Maklerverhalten und seine eigenen Konventionen darüber, was überhaupt öffentlich gelistet wird. In manchen Märkten erscheint ein großer Anteil der Transaktionen nie auf einem öffentlichen Portal.
Behandeln Sie ein globales Inventar daher als Vereinigung nationaler Panels, jedes mit seinem eigenen definierten Portalsatz, und erfassen Sie die Abdeckung pro Markt statt aggregiert. Eine einzelne Gesamtzahl über Länder hinweg verbirgt den Markt, in dem Sie ein Portal haben, und den Markt, in dem Sie sechs haben.
Zwei praktische Regeln. Vergleichen Sie keine absoluten Inventarzahlen über Märkte hinweg, es sei denn, die Abdeckung ist vergleichbar, denn sonst messen Sie nur Ihr eigenes Panel. Und wo lizenzierte Feeds für einen Markt existieren, nehmen Sie die Lizenz: Abdeckung und Feldqualität sind in der Regel weit besser als bei öffentlicher Sammlung, und die rechtliche Lage ist einfacher.
Die Sammelebene
Portale lokalisieren stark. Was Sie sehen, die angezeigte Währung, die Sprache, manchmal die Website selbst, hängt davon ab, woher die Anfrage scheinbar kommt. Ein länderübergreifender Aggregator, der von einem einzigen Standpunkt aus sammelt, wird still und leise die Sicht eines Landes auf mehrere Märkte erhalten.
Mit dem Shifter-Gateway kommen Markt und Sitzung in die Zugangsdaten gegen p.shifter.io:443:
customer-USERNAME-country-fr-sid-listings-fr-12-ttl-600:PASSWORDcountry-fr verwendet den ISO-Alpha-2-Code, sid-listings-fr-12 hält einen Ausgang über eine vollständige Suche einschließlich Paginierung, sodass eine Ergebnismenge intern kohärent ist, und ttl-600 behält diese Adresse für zehn Minuten. Ohne sid rotiert das Gateway pro Anfrage, was für unabhängige Abfragen richtig, für eine paginierte Suche jedoch falsch ist.
Halten Sie Locale-Signale konsistent mit dem Ausgang, da eine Diskrepanz ändert, was manche Portale zurückgeben, und halten Sie Anfrageraten normal mit echtem Backoff, wie in rate limiting and request throttling. Verfolgen Sie den Sammel-Erfolg pro Portal pro Markt zusammen mit den Angeboten, denn ein Portal, das still und leise weniger Ergebnisse zurückzugeben beginnt, sieht genau aus wie ein Markt mit weniger Angebot.
Feldvollständigkeit ist eine Qualitätskennzahl, kein Detail
Portale unterscheiden sich enorm darin, wie vollständig sie optionale Felder befüllen. Ein Aggregator, der ein fehlendes Feld als nicht vorhanden statt als unveröffentlicht behandelt, wird beispielsweise berichten, dass ein Markt fast keine Immobilien mit Energieausweisen hat, obwohl ein Portal sie schlicht nicht offenlegt.
Bewerten Sie die Vollständigkeit pro Portal pro Feld, veröffentlichen Sie sie intern, und nutzen Sie sie bei der Wahl der Quellenpriorität. Sie zeigt Ihnen auch, wo ein lizenzierter Feed das Produkt tatsächlich verbessern würde, statt nur Geld zu kosten.
FAQ
Sollte ich bei der Erfassung oder zum Abfragezeitpunkt normalisieren?
Normalisieren Sie bei der Erfassung und behalten Sie die Rohfelder. Normalisierung zum Abfragezeitpunkt ist langsamer und macht die Indizierung schmerzhaft, aber ohne die Rohwerte können Sie eine schlechte Regel nicht rückwirkend korrigieren.
Wie gehe ich mit Portalen um, die Zimmer statt Schlafzimmer veröffentlichen?
Speichern Sie beide Konzepte als separate Felder und befüllen Sie, was die Quelle liefert. Leiten Sie Schlafzimmer nicht aus einer Zimmerzahl ab, und lassen Sie einen Produktfilter nicht ein Feld abfragen, das nur in manchen Märkten befüllt ist.
Ist eine kanonische Immobilientyp-Taxonomie über Länder hinweg realistisch?
Eine flache ist es. Halten Sie die oberste Ebene klein und portabel, und packen Sie lokale Spezifität in ein sekundäres Feld, statt sie in die Haupttaxonomie zu zwingen.
Was ist das Wichtigste, das zuerst zu beheben ist?
Flächenbasis und Preissemantik. Sie beeinflussen jede abgeleitete Kennzahl, und Fehler darin sind unsichtbar, bis jemand zwei Märkte vergleicht.
Fazit
Portalübergreifende Aggregation ist ein Normalisierungsproblem im Gewand eines Scraping-Problems. Das Abrufen ist der Teil, der bereits gelöst ist.
Bauen Sie das kanonische Modell vor der zweiten Integration, bewahren Sie die Rohwerte der Quelle für immer auf, speichern Sie die Originalwährung mit einem datierten Kurs, legen Sie die Quellenpriorität pro Feld statt pro Portal fest, behandeln Sie Widersprüche als Signal statt als Fehler, und erfassen Sie die Abdeckung pro Markt, da es kein globales Panel gibt. Die Produktansicht finden Sie auf der Seite large-scale data gathering, mit Preisen auf der pricing page.