SAMS：空間マーケティング自動化システム（学士論文 2010）

2010年。iPhone は3歳でアンマンではまだ物珍しい存在だ。「モバイル」といえば Nokia を意味する。BlackBerry は役員用だ。Android は2年前から出ているが開発者の実験みたいな感じがする。そして自分はヨルダン大学でコンピュータ情報システムの学士を終えていて、卒業プロジェクトとしてロケーション認識マーケティングシステムを作っている。

その大胆さよ。あの頃の自分が好きだ。

SAMS とは何だったか

Spatial Automated Marketing System。自分で命名した、これが2010年だったという証拠だ—まだ RFC を書いているかのように4単語の頭文字語でプロジェクトを命名していた。

システムは単純な前提の上に作られた：電話が自分の位置を知っていて、企業が顧客の位置を知っているなら、顧客が店舗や会場に地理的に近いときにターゲット型のプロモーションを送ることができる。ロケーションベースのマーケティング。2010年にこれは新奇なエンジニアリングの問題だった。2024年にはすべての広告プラットフォームの機能フラグだ。2010年には全部自分で作る必要があった。

アーキテクチャ—そして卒業プロジェクトにしては大きい言葉だが—は3層だった：

1. サーバーバックエンド：Java/PHP、リレーショナルデータベース（SQL Server）、GIS データレイヤー。企業は地理座標で会場を登録した。顧客プロファイルはオプトイン設定とともに維持された。マーケティングエンジンは会場の近接性を顧客プロファイルと照合してプロモーションメッセージをキューに入れた。

2. Windows Mobile クライアント：Windows Mobile ハンドセット向けの .NET Compact Framework アプリケーション。GPS ポーリング。マップレンダリング—2010年にはモバイルマッピング SDK が今のものではなかったから本当につらかった。しばしばタイル自分でレンダリングしていた。クライアントは位置の更新をサーバーに送り、近接ルールが発火したときにプロモーションのトリガーを受け取った。

3. Symbian クライアント：2010年のヨルダン市場での支配的なプラットフォームが Windows Mobile じゃなかったから—Nokia だった。Symbian Series 60 、具体的に。異なる SDK、異なるランタイム、同じプロトコルを持つ二番目のクライアントアプリケーション。これが「Write Once, Run Anywhere」は Java のマーケティングスローガンであってモバイルの現実の説明じゃないと学んだ場所だ。

実際に難しかった技術的問題

2010年のコンシューマーハンドセットの GPS は信頼性がなかった。精度は晴れた日に数十メートルで、屋内や密集した市街地では悪化した。開放的な屋外駐車場では正しく発火する200メートル半径の近接トリガーは、ショッピングモールでは常に誤検知する。サーバーサイドのジオフェンスロジックは GPS ドリフトを考慮する必要があった、つまり顧客の位置を点ではなく確率分布として扱う必要があった。最後の N 個の位置サンプルの移動平均とトリガー前の信頼度閾値でこれを処理した。これはカリキュラムにはなかった。第一原理から解決した、当時は調査のように感じて、振り返るとただのデバッグだった。

Symbian のネットワークスタックは寛大じゃなかった。Symbian Series 60 の HTTP は明示的なネットワークセッション管理が必要で、プラットフォームはデバイスモデルをまたいで互換性のない動作を持つ API の複数の世代を持っていた。クラスメートや家族から借りられる Nokia デバイスでテストした、つまりテストマトリクスは「2010年初頭にアンマンにいた人々が持っていた Nokia の電話」だった。これは厳密じゃない。非常に学部生的だ。

バッテリーは常に制約だった。30秒ごとにポーリングする GPS アプリは2010年の Nokia のバッテリーを数時間で使い果たす。ポーリング間隔は設定可能だった；適切なトレードオフがデプロイコンテキスト（会場の密度、顧客の移動速度、ビジネス要件）に依存する理由を説明するセクションをプロジェクトレポートに書いた。このセクションは必要以上に長かった。それについて考えたことを誇りに思っていた。

プロジェクトが実際に教えてくれたこと

「自分のマシンでは動く」と「実際の環境でも動く」のギャップ。

2つのクライアントとサーバーがあった。それぞれが異なる障害モードを持っていた。サーバーがダウンしているかもしれない。GPS が利用できないかもしれない。モバイルネットワークが切れるかもしれない。データベースクエリがタイムアウトするかもしれない。クライアントがリトライしたからプロモーションが重複するかもしれない。これらの障害モードのすべてに決断が必要だった—リトライ、無視、グレースフルデグレード、または大きな音で失敗—そして正しい答えはそれぞれ違った。

これが最初の分散システムだった。小さかった。本当に分散されてもいた：それぞれ別個の障害ドメインを持つ3つの別個のランタイム環境と各ペアの間のネットワーク。部分的な障害とグレースフルデグレードについて Elevatus、Bytro、それ以降のすべてのマルチサービスシステムで適用したレッスン—それらは最初に SAMS を作りながら学んだ。

プロジェクトを SAMS と命名してもより真剣に聞こえるようにはならないことも学んだ。すべてのプレゼンテーションで頭文字語を説明しなければならないだけだ。未来の自分へ：構築した後に名前を決めろ。

委員会プレゼンテーション

卒業プロジェクトはヨルダン大学のパネルにレビューされた。クラスメートから借りた GPS レシーバーを取り付けたデバイスで Windows Mobile クライアントをデモした、衛星の視認性が悪いビルの中で。GPS ロックは委員会が見ている前に4分かかった。この可能性に備えていて、屋外でフロー全体が正しく動いている録画ビデオを用意していた。委員会はきれいなライブデモよりも緊急時対応計画を評価した—ある教授は後で、障害モードを予期していたという事実が「GPS がただ動いた場合よりも印象的だ」と言ってくれた。

そのフィードバックは残り続けている。リハーサル済みのフォールバックで優雅に失敗するシステムは予測不可能に成功するシステムを上回る。

今はどこにあるか

アーカイブ済み。Windows Mobile は消えた。Symbian は消えた。テストした特定の Nokia ハンドセットは博物館の展示品だ。移動平均で回避しなければならなかった GPS 精度は今やすべてのモダンなロケーション SDK で自動的に処理されている。解決した問題はその後何度も解決されてきた、はるかに多くのリソースを持つチームによって、それについて考えずに数十億人が使うプラットフォームに統合された。

それでも：大学最終年度に、クラウドプロバイダーも言及する価値のあるマッピング SDK も屋内で4分かかる GPS レシーバーもなく、3つの異なるランタイムで機能する end-to-end のロケーション認識システムを作った。

それでいい。