SAMS: Spatial Automated Marketing System (B.Sc. 2010)

Es ist 2010. Das iPhone ist drei Jahre alt und in Amman noch eine Kuriosität. “Mobile” bedeutet Nokia. Blackberry ist für Führungskräfte. Android gibt es seit zwei Jahren, fühlt sich aber wie ein Developer-Experiment an. Und ich bin an der University of Jordan und schließe meinen B.Sc. in Computer Information Systems ab - mit einem standortbasierten Marketing-System als Abschlussprojekt.

Die Kühnheit davon. Ich liebe diesen Typen.

Was SAMS war

Spatial Automated Marketing System. Den Namen habe ich mir selbst ausgedacht, was einem verrät, dass es 2010 war - wir benannten Projekte noch mit Vier-Wort-Akronymen, als würden wir RFCs schreiben.

Das System basierte auf einem einfachen Prinzip: Wenn dein Telefon weiß, wo du bist, und ein Unternehmen weiß, wo seine Kunden sind, kann man gezielt Promotionen an Kunden senden, wenn diese geografisch nah an einem Laden oder einer Veranstaltungsstätte sind. Standortbasiertes Marketing. In 2010 war das ein neuartiges Engineering-Problem. In 2024 ist es ein Feature-Flag in jeder Ad-Plattform. In 2010 musste ich das ganze Ding bauen.

Die Architektur - und ich benutze das Wort großzügig für ein Abschlussprojekt - war dreistufig:

1. Server-Backend: Java/PHP, relationale Datenbank (SQL Server), GIS-Datenschicht. Unternehmen registrierten ihre Standorte mit geografischen Koordinaten. Kundenprofile wurden mit Opt-in-Präferenzen gepflegt. Die Marketing-Engine matchte Standort-Nähe mit Kundenprofilen und stellte Promotions-Nachrichten in eine Queue.

2. Windows-Mobile-Client: Eine .NET-Compact-Framework-Anwendung für Windows-Mobile-Geräte. GPS-Polling. Map-Rendering - genuinely schmerzhaft in 2010, weil mobile Mapping-SDKs nicht das waren, was sie heute sind. Man renderte oft Tiles selbst. Der Client sendete Standort-Updates an den Server und empfing Promotions-Trigger, wenn Proximity-Regeln feuerten.

3. Symbian-Client: Weil Windows Mobile nicht die dominante Plattform im jordanischen Markt von 2010 war - Nokia war es. Symbian Series 60, im Speziellen. Eine zweite Client-Anwendung, anderes SDK, andere Runtime, dasselbe Protokoll. Hier lernte ich, dass “write once, run anywhere” ein Java-Marketing-Slogan ist und keine Beschreibung der mobilen Realität.

Die technischen Probleme, die wirklich schwer waren

GPS auf Consumer-Handsets im Jahr 2010 war nicht zuverlässig. Genauigkeit wurde an guten Tagen in Zehnern von Metern gemessen, schlechter drinnen oder in dichten urbanen Gebieten. Ein Proximity-Trigger bei 200m Radius, der auf einem offenen Parkplatz korrekt feuert, wird in einem Einkaufszentrum konstant false-positiven. Die Server-seitige Geofence-Logik musste GPS-Drift berücksichtigen, was bedeutete, den Kundenstandort als Wahrscheinlichkeitsverteilung zu behandeln, nicht als Punkt. Ich handhabte das mit einem Moving-Average über die letzten N Standortsamples und einem Confidence-Threshold vor dem Triggern. Das stand nicht in meinem Lehrplan. Ich arbeitete es aus den Grundprinzipien heraus, was sich damals wie Forschung anfühlte und im Nachhinein einfach Debugging war.

Der Symbian-Networking-Stack war nicht nachsichtig. HTTP auf Symbian Series 60 erforderte explizites Network-Session-Management, und die Plattform hatte mehrere API-Generationen mit inkompatiblen Verhaltensweisen über Gerätemodelle. Ich testete auf Nokia-Geräten, die ich von Kommilitonen und Familienmitgliedern ausleihen konnte, was bedeutete, dass meine Testmatrix “welche Nokia-Telefone Leute in Amman Anfang 2010 hatten” war. Das ist nicht rigoros. Es ist sehr Studentenprojekt.

Akku war eine konstante Beschränkung. Eine GPS-Anwendung, die alle 30 Sekunden pollt, entleert den Akku eines Nokia 2010 in Stunden. Das Polling-Intervall war konfigurierbar; ich schrieb einen Abschnitt im Projektbericht, der erklärte, warum der richtige Trade-off vom Deployment-Kontext abhing (Standortdichte, Kundenbewegungsgeschwindigkeit, Geschäftsanforderungen). Dieser Abschnitt war wahrscheinlich länger als nötig. Ich war stolz darauf, darüber nachgedacht zu haben.

Was das Projekt mir wirklich lehrte

Die Lücke zwischen “es funktioniert auf meiner Maschine” und “es funktioniert in freier Wildbahn”.

Ich hatte zwei Clients und einen Server. Jeder hatte andere Failure-Modes. Der Server konnte unten sein. Das GPS konnte nicht verfügbar sein. Das Mobilnetz konnte unterbrochen sein. Die Datenbankabfrage konnte timeouten. Die Promotion konnte ein Duplikat sein, weil der Client retryed. Jeder dieser Failure-Modes erforderte eine Entscheidung - retry, ignorieren, graceful degradieren oder laut scheitern - und die richtige Antwort war für jeden verschieden.

Das war mein erstes Distributed System. Es war winzig. Es war auch genuinely verteilt: drei separate Laufzeitumgebungen mit separaten Failure-Domains und ein Netzwerk zwischen jedem Paar. Die Lektionen über partielles Scheitern und graceful Degradation, die ich bei Elevatus, bei Bytro, bei jedem Multi-Service-System angewendet habe, das ich seitdem gebaut habe - sie wurden zuerst beim Bauen von SAMS gelernt.

Ich lernte auch, dass ein Projekt SAMS zu nennen es nicht ernster klingen lässt. Es bedeutet nur, dass man das Akronym in jeder Präsentation erklären muss. Zukünftiger Mo: wähl den Namen, nachdem du das Ding gebaut hast.

Die Komitee-Präsentation

Mein Abschlussprojekt wurde von einem Gremium an der University of Jordan bewertet. Ich demonstrierte den Windows-Mobile-Client auf einem von einem Kommilitonen ausgeliehenen Gerät, mit einem angeschlossenen GPS-Empfänger, in einem Gebäude mit schlechter Satelliten-Sichtbarkeit. Der GPS-Lock dauerte vier Minuten, während das Komitee zusah. Ich hatte mich auf diese Möglichkeit vorbereitet und hatte ein aufgezeichnetes Video des vollständigen Flows, der draußen korrekt funktionierte. Das Komitee schätzte die Notfallplanung mehr als eine saubere Live-Demo - ein Professor sagte mir anschließend, dass die Tatsache, dass ich den Failure-Mode antizipiert hatte, “beeindruckender war als wenn das GPS einfach funktioniert hätte”.

Dieses Feedback ist mir geblieben. Das System, das graceful mit einem eingeübten Fallback scheitert, schlägt das System, das unvorhersehbar erfolgreich ist.

Wo es jetzt ist

Archiviert. Windows Mobile ist verschwunden. Symbian ist verschwunden. Die spezifischen Nokia-Handsets, auf denen ich testete, sind Museumsexponate. Die GPS-Genauigkeit, mit der ich mit Moving-Averages umgehen musste, wird jetzt automatisch von jedem modernen Location-SDK gehandhabt. Das Problem, das ich gelöst habe, wurde seitdem viele Male gelöst, von Teams mit deutlich mehr Ressourcen, integriert in Plattformen, die Milliarden von Menschen nutzen, ohne darüber nachzudenken.

Und dennoch: Ich baute in meinem letzten Universitätsjahr ein funktionierendes End-to-End-standortbasiertes System, auf drei verschiedenen Runtimes, ohne Cloud-Provider und ohne erwähnenswerte Mapping-SDK, mit einem GPS-Empfänger, der drinnen vier Minuten zum Einrasten brauchte.

Ich nehm’s.