Unbediente Nachfrage verstehen
Unbediente Nachfrage ist eines der stillen Umsatzlecks im Shared-Mobility-Geschäft: Ein Rider öffnet die App, sucht ein Fahrzeug, und in der Nähe ist keines. Er schließt die App und fährt nicht. Sie sehen die verlorene Transaktion nie in Ihrer Rides-Tabelle, weil die Fahrt nie stattfand — aber die Nachfrage war real, und AI Ops erfasst sie jetzt.
Was als Unmet-Demand-Ereignis zählt
Jedes Mal, wenn ein Rider die Levy-Mobile-App öffnet und die Fahrzeugliste in der Zone null fahrbereite Fahrzeuge im Umkreis von 500 Metern um den Suchort zurückgibt, schreibt AI Ops ein Ereignis in die Tabelle unmet_demand_events. Das Ereignis enthält:
| Feld | Beschreibung |
|---|---|
h3_index | Die H3-Hex-Zelle, in der die Suche stattfand |
occurred_at | Zeitstempel der Suche |
available_vehicles_500m | Anzahl der Fahrzeuge im Umkreis von 500 m (bei Unmet-Events immer 0) |
search_lat / search_lng | Wo der Rider gesucht hat |
customer_uuid | Der Rider, falls authentifiziert |
Die Instrumentierung liegt in POST /api/mobile/app-session-search — die Rider-App ruft sie bei jedem Karten-Open und jeder Fahrzeuglisten-Anfrage auf.
Warum wir es erfassen
Zwei Gründe:
- Verlorenen Umsatz quantifizieren. Wenn Sie wissen, dass eine Hex-Zelle 30 Unmet-Events pro Tag hat und Ihr Durchschnittsfahrpreis 4 $ beträgt, sind das rund 120 $ potenziellen Tagesumsatzes allein aus dieser Zelle. Das Empfehlungssystem nutzt das, um seine Vorschläge zu dollarisieren.
- Die Prognose um Zensierung korrigieren. Historische Fahrten sind ein zensiertes Nachfragesignal — Sie sehen nur die Fahrten, die stattfanden, nicht die, die stattgefunden hätten, wäre ein Fahrzeug dort gewesen. Das Prognosemodell verwendet Unmet-Demand-Ereignisse, um die wahre Nachfrage zu rekonstruieren, damit chronisch unterversorgte Hex-Zellen nicht unterschätzt werden.
Der Unmet-Demand-Heatmap-Layer
Unter Dashboard > Analytics > Heat Maps schalten Sie den Unmet demand-Layer ein. Hex-Zellen werden nach Anzahl der Unmet-Events im sichtbaren Fenster eingefärbt (Standard: letzte 24 Stunden).
Hellrote Zellen sind, wo Sie am meisten Umsatz verlieren. Sie sind die Ziele mit der höchsten Priorität für das Empfehlungssystem — Fahrzeuge dorthin zu bewegen, hat den höchsten erwarteten Mehrertrag.
Klicken Sie auf eine Hex-Zelle, um zu sehen:
- Anzahl Unmet-Events im Fenster
- Verteilung nach Tageszeit (wann Rider suchen)
- Prognose für die nächsten 4 Stunden (vorhergesagte Nachfrage in derselben Zelle)
Unmet Demand mit Prognose vergleichen
Unmet Demand ist beobachtete Historie. Prognose ist Vorhersage. Sie ergänzen sich:
- Hohe Unmet, hohe Prognose — chronische Unterversorgung. Das Empfehlungssystem priorisiert sie zuerst.
- Hohe Unmet, niedrige Prognose — kurzlebige Spitze (z. B. eine einmalige Veranstaltung). Das Empfehlungssystem behandelt das vorsichtig, weil der Prognosehorizont sie nicht vorhersagt.
- Niedrige Unmet, hohe Prognose — Sie sind dem Bedarf gerecht geworden. Die Prognose sagt, machen Sie weiter so.
- Niedrige Unmet, niedrige Prognose — ruhige Zelle, in Ruhe lassen.
Aufbewahrung
Unmet-Demand-Ereignisse werden in einer TimescaleDB-Hypertable mit 30-Tage-Aufbewahrungspolicy gespeichert. Ältere Zeilen werden automatisch verworfen. Aggregate werden in die Prognose-Feature-Pipeline gerollt, bevor sie ablaufen, sodass das Modell das Signal behält, auch wenn einzelne Ereignisse gelöscht sind.
Datenschutz
Suchorte (search_lat / search_lng) sind personenbezogene Daten. Sie sind durch die bestehenden Rider-Nutzungsbedingungen abgedeckt und werden nur für das 30-Tage-Aufbewahrungsfenster gespeichert. Sie werden niemals in MDS-Feeds oder Dritt-Exporte aufgenommen.
Verwandt
- Nachfragekarte — vollständige Anleitung zur Heat-Maps-Seite.
- Rebalance-Empfehlungen — wie unbediente Nachfrage zu einer vorgeschlagenen Bewegung wird.