Marketing Automation
/07. April 2026- Aktualisiert am 07. April 2026/4 Min. LesezeitSmartes Geo-Targeting: Distanzberechnungen nativ in Bloomreach umsetzen
Im modernen Omnichannel-Handel ist die Verknüpfung von Online-Daten und stationärem Geschäft mittlerweile eine Grundanforderung, um ein nahtloses Kundenerlebnis zu ermöglichen. Ein klassisches Szenario: Ein Kunde plant eine exklusive Instore-Aktion und möchte per Newsletter nur die Kontakte einladen, für die der Weg in die Filiale zumutbar ist – sprich, die in einem Umkreis von 20 km wohnen.
Zusätzlich haben wir die Möglichkeit, durch die Verknüpfung von Webseite-, E-Mail- und Kaufdaten Kundeninteressen zu erstellen und so für den Kunden relevant Inhalte zu liefern.
Die Standardlösung vieler Marketer? Externe Geo-APIs via Webhooks anbinden. Das Problem dabei? Jeder Aufruf produziert Events und Kosten. Wir haben für unsere Kunden einen eleganten Weg mit Bloomreach-Standardfunktionen gefunden.
Die Herausforderung: Location Intelligence "on the fly"
Unser Kunde betreibt ein Netz an stationären Filialen. Die Zielsetzung war klar:
- Präzision: Kunden nur dann anschreiben, wenn sie im 20-km-Radius einer Filiale leben.
- Relevanz: Falls ein Kunde zwischen zwei Filialen wohnt, soll die geografisch nächste Filiale (inkl. ID) zugewiesen werden.
- Effizienz: Keine zusätzlichen Toolkosten und idealerweise ohne zusätzliche Events.
Der BI-Ansatz: Jinja statt Drittanbieter
Anstatt die Distanzberechnung an einen externen Dienst auszulagern, haben wir die Logik direkt in einem Jinja-Snippet innerhalb von Bloomreach implementiert.
Die technische Basis bilden die Koordinaten (Längengrad/Breitengrad) der Postleitzahlen. Über die Versandadresse ist die PLZ der Kunden häufig bereits bekannt als Kundenattribut in Bloomreach gespeichert. Zusätzlich ist ein Katalog für die Filialen mit ID und PLZ notwendig.Ein externer Katalog fungiert als Mapping zwischen PLZ und den entsprechenden Längen- und Breitengraden dieses PLZ-Gebiets.
So funktioniert die Lösung im Detail:
1{% for filiale in filialen_chunk %}
2 {% set current_filial_id = filial_list_chunk[loop.index0] %}
3
4 {% if filiale is not none and filiale.PLZ %}
5 {% set plz_coords = catalogs['zip_coordinates_cities'].item_by_id(filiale.PLZ|string) %}
6
7 {% if plz_coords is not none %}
8 {% set filial_lat = plz_coords.lat | float %}
9 {% set filial_lon = plz_coords.lng | float %}
10
11 {% set diff_lat = (customer_lat - filial_lat) | abs %}
12 {% set diff_lon = (customer_lon - filial_lon) | abs %}
13 {% set current_d_lon_limit = d_lon_table[filial_lat|int] | default(0.28) %}
14
15 {% if diff_lat <= d_lat_limit and diff_lon <= current_d_lon_limit %}
16 {# Distanz-Quadrat berechnen (Normiert) #}
17 {% set lat_ratio = diff_lat / d_lat_limit %}
18 {% set lon_ratio = diff_lon / current_d_lon_limit %}
19 {% set score = (lat_ratio * lat_ratio) + (lon_ratio * lon_ratio) %}
20
21 {# Wenn Score <= 1.0, liegt sie im 20km Radius #}
22 {% if score <= 1.0 %}
23 {# Wir speichern ein Dictionary mit Score und ID #}
24 {% append {"id": current_filial_id, "dist_score": score} to found_filialen %}
25 {% endif %}
26 {% endif %}
27 {% endif %}
28 {% endif %}
29 {% endfor %}- Approximative Distanzberechnung: Innerhalb des Snippets nutzen wir eine mathematische Annäherung an die Haversine-Formel. Das Snippet vergleicht die Koordinaten des Kunden mit denen der verfügbaren Filialen.
- Winner-takes-it-all Logik: Befindet sich ein Kunde im Überschneidungsbereich zweier Filialen, berechnet das Snippet die geringere Distanz und gibt ausschließlich die ID der nächstgelegenen Filiale zurück.
- Effizientes Profil-Update: Das Ergebnis wird im Rahmen eines Szenarios als Attribut direkt in der Customer View gespeichert. So kann das Marketing-Team dieses Attribut jederzeit für Segmentierungen nutzen, ohne jedes Mal die Logik neu aufzusetzen.
Unsere Lösung bietet drei entscheidende Vorteile:
- Zero-Event-Cost: Die Berechnung findet intern statt. Es werden keine zusätzlichen API-Calls produziert. So können Latenz und zusätzliche Kosten vermieden werden.
- Echtzeit-Segmentierung: Da die filial_id direkt am Kundenprofil hängt, können Kampagnen ohne Zeitverzug für lokale Store-Openings oder regionale Sales ausgesteuert werden.
- Wartungsarm: Die Liste der Filialkoordinaten lässt sich im Katalog zentral pflegen, ohne das Snippet erneut anfassen zu müssen. So können Filialöffnungen und -schließungen berücksichtigt werden, was für das Marketing Team relevant ist.
Fazit: BI-Kompetenz bedeutet, Tools an ihre Grenzen zu bringen
Dieser Case zeigt, dass sich mit der richtigen Jinja-Logik komplexe Datenoperationen "In-House" lösen lassen. So wird keine externe Architektur benötigt und Bloomreach bleibt die Single-Source-of-Truth. Es gilt immer abzuwägen, welcher Grad an Komplexität benötigt wird für den vorliegenden Use Case. Für den Use Case unseres Kunden ist eine geografische Annäherung über den oben beschriebenen Weg die optimale Lösung. Durch das Bereitstellen dieser Lösung können wir dem Marketing-Team es ermöglichen, ihre relevanten Kampagnen selbstständig umzusetzen und das performant, kosteneffizient und skalierbar.
Ausblick
Zusätzlich, sofern wir keine Postleitzahl zu einem Kunden haben, haben wir die Möglichkeit, die Koordinaten von Seitenaufrufen und E-Mail-Interaktionen aus der nahen Vergangenheit für dieselbe Distanzberechnung zu nutzen.
Lust auf einen
Austausch?
Newsletter
Als Erstes informiert, wenn es Neuigkeiten in der digitalen Welt gibt!
Durch die Bereitstellung Ihrer E-Mail-Adresse erklären Sie sich damit einverstanden, Newsletter und Werbe-E-Mails von uns zu erhalten. Wir respektieren Ihre Privatsphäre und werden Ihre Informationen nicht an Dritte weitergeben. Sie können sich jederzeit abmelden.
You've reached the end
Linienstrasse 222, 10119 Berlin
Raboisen 30, 20095 Hamburg
Conversion Optimierung
Business Intelligence
Digital Analytics
Marketing Automation
Team
Kontakt
Jobs
Datenschutzerklärung
Impressum
Cookie-Einstellungen
©2026 Peaks & Pies GmbH
