PLZ oder Radius: Was funktioniert besser beim Matchmaking?
Eine Standardfunktion von Online-Plattformen ist die Umkreissuche. Die beiden gängigsten Ansätze sind die Verwendung von Postleitzahlen (PLZ Umkreissuche) oder die Radius-Suche. Doch was passiert, wenn man beides kombiniert?
Die Mischung von Radius und PLZ kann zu ungenauen oder irreführenden Suchergebnissen führen – weil Postleitzahlenbereiche unregelmäßige Formen haben und ein Radius nur Teile einer PLZ abdecken kann.
Das Problem: PLZ trifft auf Radius
Uns wurde ein interessantes Problem vorgestellt: Ein Job wird auf einer Plattform gepostet, wobei der Standort und ein gewünschter Arbeitsradius angegeben werden. Das System sollte dann automatisch erkennen, welche Postleitzahlen in diesem Radius liegen und diese dem Job zuordnen.
Die Schwierigkeit liegt darin, dass Postleitzahlenbereiche oft unregelmäßige Formen haben und ein vorgegebener Radius nur Teile einer bestimmten PLZ abdeckt.
Wenn beispielsweise ein Job in 53111 gepostet wird und einen Radius von 5 km angibt, kann dieser Radius Teile von 53119 überlappen, obwohl der größte Teil von 53119 außerhalb dieses Radius liegt. Ein Jobsuchender aus 53119 könnte dann den Job als verfügbar sehen, obwohl er eigentlich nicht in seinem Bereich liegt.
Drei Lösungsansätze
Statt PLZ und Radius zu vermischen, empfehlen wir einen der folgenden Ansätze – je nach Anforderung und Budget:
Rein postleitzahlenbasierte Suche ohne Radius. Lässt sich ohne externe APIs und Geocoding umsetzen – günstig, einfach und für viele Anwendungsfälle ausreichend.
Nutzer geben ihren genauen Standort und den gewünschten maximalen Umkreis ein. Die Plattform zeigt Ergebnisse, die in diesem Radius verfügbar sind – präzise und nachvollziehbar.
Die Google Maps Distance-Matrix ermöglicht es, die Reisezeit mit verschiedenen Verkehrsmitteln zu ermitteln. So können Nutzer z.B. nach Jobs filtern, die mit dem ÖPNV innerhalb einer Stunde erreichbar sind.
Eine Vermischung von PLZ- und Umkreissuche ist nicht zu empfehlen, weil es zu unerwarteten Ergebnissen führen kann. Klar kommunizieren, wie gematched wird.
Umsetzung in der Praxis
Welchen Ansatz man wählt, hängt von drei Faktoren ab: Genauigkeit, Kosten und Komplexität.
Die PLZ-basierte Suche ist der einfachste Weg. Man pflegt eine Tabelle mit allen deutschen Postleitzahlen und ihren Mittelpunkt-Koordinaten (frei verfügbar). Die Suche vergleicht dann PLZ gegen PLZ – ohne Geocoding, ohne externe API. Für Plattformen, bei denen eine grobe Zuordnung reicht (Handwerker-Vermittlung, regionale Jobbörsen), ist das oft ausreichend und kostet nichts im Betrieb.
Die Radius-Suche arbeitet mit Geokoordinaten. Nutzer geben eine Adresse ein, diese wird per Geocoding-API (z.B. Google Maps oder OpenStreetMap/Nominatim) in Koordinaten umgewandelt, und die Datenbank sucht per Haversine-Formel alle Einträge im gewünschten Umkreis. Laravel bietet dafür keine native Lösung, aber mit einem einfachen DB::raw()-Query lässt sich das in wenigen Zeilen umsetzen. Die Genauigkeit ist hoch, aber jeder Geocoding-Request kostet – bei Google Maps ab 5 USD pro 1.000 Anfragen.
Die Reisezeit-basierte Suche ist die nutzerfreundlichste, aber auch die teuerste Variante. Die Google Maps Distance Matrix API berechnet die tatsächliche Fahrzeit zwischen zwei Punkten – inklusive Verkehrslage und Verkehrsmittel. Für Pendler ist "30 Minuten mit dem ÖPNV" deutlich relevanter als "15 km Luftlinie". Die API-Kosten liegen bei 5 USD pro 1.000 Elemente (Kombinationen aus Start und Ziel), was bei großen Plattformen schnell ins Geld geht.
Unsere Empfehlung
Für die meisten Plattformen empfehlen wir einen gestuften Ansatz: PLZ-basiertes Matching als Standard (kostenlos, schnell), mit optionaler Radius-Verfeinerung für Nutzer, die genauere Ergebnisse wollen. Die Reisezeit-Suche lohnt sich erst, wenn das Geschäftsmodell davon abhängt – etwa bei Pendler-orientierten Jobbörsen oder Lieferdiensten.
Fazit
Eine Umkreissuche sollte nachvollziehbare und akkurate Matching-Ergebnisse liefern. Entscheidend ist: Klar kommunizieren, wie gematched wird – ausschließlich auf Basis des User-Standorts und des eingestellten Radius, oder ausschließlich auf PLZ-Ebene. Die Vermischung beider Ansätze führt zu Verwirrung und falschen Erwartungen bei den Nutzern.
Es folgt ein simples Beispiel, welches das Problem mit realen Adressen beschreibt und veranschaulicht.