Cisco Meraki Japan

アカウントをお持ちの場合

  •   パーソナライズされたコンテンツ
  •   製品とサポート

アカウントをお持ちでない場合

アカウントを作成

はじめに

モバイル デバイスの急速な普及により、実環境における通行人の行動パターンをより深く理解できるデータが活用できるようになりました。 ワイヤレスおよび Bluetooth に関する 802.11 標準規格を中心とするロケーション情報を活用すれば、ユーザ エンゲージメントやマーケティング戦略を最適化できます。小売業では実店舗での販売が減少傾向ですが、ロケーション情報を活用すればオンライン小売業者に対抗できます。オンライン小売業者は長年の間、オンライン ツールによって生成されたロケーション情報と同様のデータ(オンライン広告におけるコンバージョン率など)を分析・利用してきました。

 

Wi-Fi 対応のスマートフォンが普及していますが、これらは顧客の動向分析ツールとして使用できます。ここでは、Wi-Fi 対応デバイスすべてに共通するプローブ要求を活用します。プローブ要求などの 802.11 管理フレームは、Wi-Fi デバイスから一定の間隔で送信されます。フレームには、Wi-Fi アクセス ポイントがカバーする範囲における人数、滞留時間、訪問回数を特定するための情報が格納されています。Wi-Fi アクセス ポイントは、接続されていない Wi-Fi デバイスでも検出できます。つまり、ワイヤレス ネットワークに接続されていないデバイスであっても、デバイスがネットワーク圏内にあり、デバイスの Wi-Fi アンテナがオンであれば、そのデバイスの数を検出できます(1)

 

今やスマートフォンの普及率は一般人口の 50 % を超えています(2)。そこでプローブ要求を活用すれば、特定のアクセス ポイントがカバーする範囲で Wi-Fi 対応デバイスの数に関する大規模な統計データ セットを生成・検出できます。Meraki のワイヤレス アクセス ポイントとクラウド インフラストラクチャは、このデータを収集して集約し、Meraki ダッシュボードに表示します。データの表示に使用されるのは、直感的でカスタマイズが可能なグラフです。これらのグラフでは、訪問率(通行人対訪問者)、ユーザ エンゲージメント(合計滞留時間)、訪問者のロイヤルティ(初めての訪問であるか、再訪であるか)などといった傾向を理解できます。Meraki はこれらの分析を、Cisco Meraki の全製品を背後で支える業界トップクラスのクラウド アーキテクチャを利用することで、あらゆる組織に提供しています。さらに Meraki Scanning API では、観測されたプローブ要求から未加工のデータをエクスポートできます。このデータは、サード パーティーのデータ ウェアハウジングや分析プラットフォームに直接統合できます。これにより、従来の顧客関係管理(CRM)プラットフォームとより統合できるだけでなく、そのリアルタイム性により次世代のカスタマー エンゲージメント イニシアチブを実現します。

 

大まかに言えば、Meraki のロケーション分析ビューとリアルタイム ロケーション API は既存のトラフィック分析機能を補完し、Cisco Meraki ネットワーク内に位置するデバイスを包括的に分析・理解します。このホワイトペーパーでは、Cisco Meraki のロケーション機能を探り、これらの機能を支えるテクノロジーと、そのテクノロジーによって実現可能な一部のユース ケースについて解説します。これらのロケーション機能は、Cisco Meraki の MR シリーズ ワイヤレス アクセス ポイントに搭載されています。

1 ロケーション情報の収集と使用は、一般消費者の間でプライバシーに関する懸念を生じさせています。Meraki はこのような懸念を重く受け止めており、プライバシー保護を念頭にロケーション分析を設計しました。ロケーション分析システムによってデバイスの存在が検出されることを懸念する場合は、デバイスの Wi-Fi をオフにするだけで、デバイスの検出を回避できます。

2 https://www.comscore.com/Insights/Market-Rankings/comScore-Reports-October-2014-US-Smartphone-Subscriber-Market-Share


ロケーション データの収集

Cisco Meraki アクセス ポイントは、デバイスの接続状態を問わず(3)、プローブ要求と 802.11 データ フレームを検出してあらゆる Wi-Fi 対応デバイスからプレゼンス シグニチャを生成します。Wi-Fi デバイスは一般に、その状態に応じて一定間隔でプローブ要求を送信します(表 1 を参照)。たとえばスマートフォンは、周囲のワイヤレス ネットワークを検出するためにプローブ要求を送信し、ネットワークをユーザが使用できるようにします。

 

デバイス状態
プローブ要求間隔(スマートフォン)
スリープ(画面オフ) 1 分あたり 1 回
スタンバイ(画面オン) 1 分あたり 10 ~ 15 回
接続済み 状況に依存。ユーザが手動でネットワークを検索する必要が生じる場合もあります。

Sorry, no results matched your search criteria(s). Please try again.

表 1

スマートフォンの OS ベンダー(iOS、Android など)でのプローブ要求間隔は、アプリケーション、デバイス アップグレードなどの要因により大幅に異なります(4)

 

Meraki アクセス ポイント上では、接続されている Wi-Fi デバイスすべてから受信したデータ フレームと、カバーする範囲内(通常は最大 100 フィート以上)にあるデバイスすべてから検出したプローブ要求により、「デバイス確認」イベントが生成されます。トリプル無線 AP はスキャン専用の無線を備えており、常時すべてのチャネルでプローブ要求を受信します。スキャン専用の無線を使用できないデュアル無線 AP でも、あらゆるチャネルで、Wi-Fi デバイスがプローブを行った際にプローブ要求を受信できます。確認されたデバイス情報は、アクセス ポイントと Meraki クラウド間のセキュアな管理トンネルを介してアップロードされます。

 

Meraki のセキュア管理トンネルは、設定の統計と大量の情報の送受信に対応するように高度に最適化されています。また、確認されたデバイスのデータによって追加されるオーバーヘッドは、ほぼ無視できるほどです。具体的には、管理トンネルによって消費される帯域幅合計は約 1 kbit/s です。

 

Meraki アクセス ポイント はデータ フレームとプローブ要求の信号強度も検出します。この情報を使用することで、Wi-Fi デバイスの物理的な位置を推定できます。 

 

 

図 1:iOS デバイスから送信される典型的なプローブ要求 - Wireshark を使用して表示した、Meraki AP から取得した 60 秒のパケット キャプチャ。

 

ロケーション データの大部分は、デバイスごとに、そのデバイスの Media Access Control(MAC)アドレスを固有識別子として使用してキャプチャされます。一部のモバイル OS では、プライバシー保護手法の一環として、デバイスが使用する WLAN MAC アドレスをランダム生成する機能が追加されています。これらのデバイスは、Meraki ロケーション分析のようなソリューションによる追跡も困難です。 ランダム化を実装したモバイル デバイスの数が増えるにつれ、デバイスを検出して位置を特定するためのソリューションも変化してきました。Cisco Meraki では、Meraki Scanning  API を介して Bluetooth 情報などの機能を追加し、Cisco Meraki のお客様がロケーション分析データ セットの一部として匿名でウェアラブル デバイスも追跡できるようにしています。

4 Meraki 独自の実験と分析パートナーの実験によって明らかになった経験的証拠に基づきます。この動作は、スマートフォンの OS やインストール済みアプリによって大幅に異なる傾向があります。たとえば、特定のアプリが非常にアクティブであれば、スリープ状態のデバイスでも 1 分あたり複数回プローブを行うことがあります。


データの集約と表示

ネットワーク内の AP すべてからのプレゼンス シグニチャは、Meraki クラウドで受信された後に集約されます。集約後は、ダッシュボードでの表示に備え、観測された各クライアント デバイスからのデータに一連の計算処理が適用されて分類されます。たとえば、小売業者は訪問率(通行人対訪問者)を把握する必要があります。訪問率とは、店舗の前を通る通行人と、実際に店内に入ってきた訪問者の比率です。訪問率を判断するため、Meraki クラウドは各クライアント デバイスの信号強度と、該当する位置内での滞留時間を分析します(信号強度自体が高いからと言って、それが訪問者であることを意味するわけではありません。そのデバイスのユーザが店頭を素早く通り過ぎただけの場合もあります)。 

 

 

Cisco Meraki のデータベース内にはさまざまなクライアント状態が作成されて保管され、さまざまな手法によって計算されます。表 2 に、カテゴリとそれぞれの定義を記載します。

 

パラメータ
定義
計算
訪問率(Capture Rate) 通行人のうち訪問者になった人の比率。「通行人」とは、観測されたあらゆるデバイスを指します。「訪問者」とは、信号強度が高い状態が特定の期間を超えて観測されたデバイスを指します。このグラフには、観測されたすべてのデバイスと各デバイスの分類(通行人/訪問者)が示されます。観測されたクライアントの合計数に対する訪問者数の割合が訪問率となります。

1.通行人の分類:少なくとも 1 回観測されたデバイス

2.訪問者の分類基準:20 分の時間枠内で 5 分以上観測されたデバイス。 RSSI の値が 15 以上の場合はセッションが開始されます。以降は、RSSI の値が 10 以上である限りセッションが維持されます。

エンゲージメント(Engagement) 訪問者がワイヤレス ネットワーク範囲内に滞留した時間を示す値(分数)。 クライアントのプレゼンス シグニチャのタイムスタンプを調べて、訪問者がワイヤレス ネットワーク範囲内に滞留した時間を計算します。
ロイヤルティ(Loyalty) 新規訪問者と再訪訪問者の比率。 訪問者ごとに追加されるデータベース エントリにより、特定期間における訪問回数が検出されます。たとえば、クライアントが 1 か月以内に 4 回観測されると、そのクライアントは週次訪問者として分類されます。8 日以内に 5 回以上観測されたクライアントは、日次訪問者として分類されます。

Sorry, no results matched your search criteria(s). Please try again.

4 RSSI - 95 = 信号強度(dBm)

ロケーション分析

Meraki クラウドは上記の計算処理をリアルタイムで実行して各種のクライアント統計を算出します。一方、Meraki ダッシュボードは、キャプチャー レート、エンゲージメント、ロイヤルティを視覚化し、算出結果を直感的なグラフとして表示します。これらのグラフは、シンプル ビューと複合ビューとの間で切り替えることができます。カレンダー機能により特定期間にズームインまたはズームアウトすれば、1 日単位のきめ細かいビュー(通行人のトラフィックが特定の日にどのように変動し、ピークに達したかを確認可能)から、数か月にわたるビュー(季節的な変動を確認可能)まで表示できます。

 

時間カレンダー機能により、特定の期間を選択して表示できます。つまり、上記のグラフの x 軸を調整して、特定期間のデータを表示できます(たとえば、特定の日/週における訪問者数の変化を時系列で確認できます)。 

 

プロキシミティ グラフ

「訪問率」は、通行人のうち訪問者になった人の比率です。

「訪問者」とは、ネットワークを訪問したワイヤレス デバイスを意味します。Meraki AP が RSSI の値が 15 以上のプローブを検出した時点で「訪問」が開始されます。20 分の時間枠内において、デバイスが送信するプローブの RSSI 値が 10 以上の状態が 5 分以上になると、訪問者として見なされます。

「通行人」とは、訪問者と見なすためのプローブと滞留時間の要件を満たしていない、Meraki AP でプローブが検出されたワイヤレス デバイスを意味します。

エンゲージメント グラフ

「訪問者」とは、信号強度が高い状態を 5 分以上維持したワイヤレス デバイスを意味します。このグラフには、訪問者が Wi-Fi ネットワーク範囲内に滞留した時間が示されます。

ロイヤルティ グラフ

このグラフには、再訪した頻度に基づいて訪問者が表示されます。たとえば、週次訪問者とは、過去 1 か月間に 2 回から 6 回再訪した訪問者を意味します。

比較する

Cisco Meraki には、オーガナイゼーション内の特定ネットワーク間で違いをより深く理解するための強力な比較分析ツールが組み込まれています。比較を実行すると、Meraki ダッシュ ボードは最初のデータ セットから取得したロケーション データを、2 番目のデータ セットのロケーション データの上にオーバーレイします。比較を実行することで、さまざまなデータ セットを分析できます。たとえば、以下のような比較を実行できます。

 

  1. 単一サイトにおける 2 つの異なる期間(今週と先週など)の比較
  2. 2 つ以上のサイト間またはサイト グループ間に対するマルチサイト比較
  • 2 つの異なるサイト(サイト A とサイト B)の比較
  • 1 つのサイトとサイト グループとの比較(サイト A と全サイトとの比較、またはサイト A とサイト A から D までの平均との比較)
  • 2 つの異なるサイト グループの比較(全サイトとサイト A から D までの平均との比較)

2 つの異なる期間での比較分析は、[分析(Analytics)] ページに表示される時間スケールを展開するだけで実行できます。 

 

サイト グループの比較では、Cisco Meraki のネットワーク タギング機能を使用します。これにより、管理者は 1 つ以上のタグをそれぞれのネットワークに割り当てて、階層型ネットワーク構造を作成できます。この方法では、複数のサイトを持つ組織内で、必要なレポート(たとえば、特定のサイトを組織内の全国平均と比較するレポートや、東日本サイトを西日本サイトと比較するレポートなど)に応じてさまざまな比較を実行できます。

 

 

新しいロケーション分析によって推奨される Cisco Meraki ワイヤレス ネットワークの展開方法が変わることはありません。AP の配置や向きを変更したり、さらに AP を追加したりする必要はありません。上記のセクションで説明したヒューリスティックにより、既存の展開環境から自動的にデータが取得されて分析され、通行人に関するデータが提供されます。

 

ロケーション分析用に最適化した Cisco Meraki ネットワークを展開する際は、以下のことをはじめとし、さまざまな一般的なガイドラインおよび要素を念頭に置く必要があります。

  • 物理アクセス ポイントを通常と同じように展開して、ワイヤレス ネットワーク カバレッジを提供します。
  • Meraki ダッシュボードで、展開環境を組織/ネットワーク トポロジで構造化し、ロケーションごとに 1 つのネットワークを割り当てます。ロケーション分析データはネットワークごとに計算されて表示されるため、(単一のネットワーク内にすべてのロケーションを含めるのではなく)ロケーションごとに 1 つのネットワークを作成することを推奨します。ダッシュボードのインターフェイスは、数百ものネットワークを容易に管理できるように設計されています。
  • [組織(Organization)] > [概要(Overview)] ページで、ネットワークのグループごとにタグを付けます。これにより、一連のサイトごとにグループ化して、タグを基準としたデータ分析を実行して比較できるようになります。
  • ネットワークによってタイムゾーンが異なる場合は、一貫性のある比較を実行できるよう、[構成(Configure)] > [ネットワーク全体(Network-wide)] 設定ページで各ネットワークのタイムゾーンを正しく設定してください。
  • Cisco Meraki データベースがネットワークの情報を取り込めるよう、時間の猶予(数日)を設けてください。

 

マーケティング チームとビジネス インテリジェンス チームにとっての価値

データ分析や表示されるグラフにおける全体的な目標は、IT 部門だけでなく、IT 以外の部門でもユーザ動向を理解できるプラットフォームを提供することです。一日の時間帯による通行人のトラフィックのパターンやサイトごとの訪問率の変動などを把握すれば、IT 部門ではネットワークの使用状況と傾向をより深く理解できます。マーケティング チームやビジネス インテリジェンス チームなどの IT 以外の部門は、たとえばサイト A での新しいマーケティング キャンペーンが効果を上げているのかどうかを通行人のトラフィック量に基いて判断したり、ピーク時間帯にサイト B のスタッフを増員する必要があるかといった質問に、十分な情報に基づいて答えられるようになります。 以下の表に、ロケーション分析が役立つさまざまなユース ケースのいくつかを抜粋します。

 

ユース ケース
  • クライアントの合計訪問数を検出する
  • 時間枠でのコンバージョンを分析して最適化する
  • 1 日の時間帯ごとのスタッフ配属を最適化する
  • 訪問者の滞留時間と再訪の頻度を分析する
  • サイト間の比較またはサイトのグループの平均を基に、平均未満または平均を超える店舗の通行人トラフィック量、滞留時間、再訪の頻度を理解する
  • 特定の変数を変化させ、測定可能なパラメータ(訪問率など)の結果に影響が出るかどうかを確認するために、A/B テストを最適化して実行する
  • データを分析し、外部 KPI(サイトあたりの平均滞留時間、ユーザあたりの平均滞留時間、店舗あたりの平均コスト)と比較する
  • ポリシーを最適化して、週ごとの変動や季節的な変動に備えてネットワークを準備する
  • ロケーション分析データをトラフィック分析データおよびデバイス フィンガープリント データと相互に関連付けて、包括的なユーザ プレゼンス、デバイス、およびオンライン行動を把握する 

Sorry, no results matched your search criteria(s). Please try again.

ロケーション ヒートマップ

Meraki のロケーション機能には、特定日の特定のロケーションでの人々の滞留時間を経時的に視覚化できます(ワイヤレス ネットワークへの接続状況を問わず、この機能は有効です)。フロア プランまたは Google マップにオーバーレイされたこのデータから、ネットワーク管理者やマーケティング/オペレーション チームは店舗やビルの特定のエリア内でのゲスト通行人の流れに関する情報を入手できます。   

 

LocationHeatmap.png

 

ヒートマップの機能

フロア プランでは、各フロアのビューを切り換えられるだけでなく、表示から AP を除外したり、AP に関する各数値(モデル番号、現在のクライアント数、クライアント数の履歴など)を表示したりすることもできます。ヒートマップ ページには「再生」機能も組み込まれていています。再生ボタンを押すと、その日全体のクライアント密度の変化を時系列で確認できます。日付を切り替えて、過去の特定日におけるクライアント密度を確認することもできます。 

 

基礎となる数値 

ヒートマップが計算に使用する 2 つの数値は、(a)該当する期間中に検出されたデバイスの数、および(b)該当するエリア内にそれらのデバイスが滞留した時間です。 マップ上では、最も「プレゼンス」の密度が高いエリアが色分けして示されます。"この密度は、該当する期間中に検出されたデバイスの数と、それらのデバイスがそのエリア内に滞留した時間に基づきます。濃い赤で示されるエリアは、多数のデバイスが検出されたか、あるいは少数のデバイスすべてが 1 時間にわたって滞留したかのどちらかです。 

 

クライアントのインジケータ 

ヒートマップには、ワイヤレス ネットワーク内におけるクライアントの位置も計算されて描画されます。グレーの円は、ワイヤレス ネットワークに未接続の、プローブ中のクライアントを示します。青い円は、ワイヤレス ネットワークの SSID のいずれかに接続されているクライアントを示します。

 

Scanning API

はじめに

Wi-Fi や BLE を搭載したスマート デバイスが広く利用可能になったことで、Cisco Meraki のワイヤレス アクセス ポイントで、ユーザの行動を報告するためのロケーション アナリティクスの実施と提供を行うことができるようになりました。これは特に、IT 部門以外の管理者や部署が、トレンドやユーザの関与についてさらに詳しく把握したいと希望しているマルチサイトの小売りや企業の環境で便利です。Cisco Meraki では、クライアント デバイス、アプリケーション、Web サイトの Wi-Fi ネットワークを利用した従来のレポート機能と組み合わせることで、オンラインおよびオフラインでのユーザ トラフィックの包括的な把握を可能にしています。

グローバルに分散したシスコのデータセンター アーキテクチャを活用することで、Cisco Meraki はエンドツーエンドのシステムを構築しています。このシステムでは、数千ものエンドポイントからのデータを集約して、Meraki ダッシュボードでの効果的な収集、アナリティクス、プレゼンテーションに利用することができます。複数のサイトや期間を対象とした比較ができることに加えて、Cisco Meraki のネットワークのタギング機能を通じて、区域、地域、その他の属性に基づいてグループ化したネットワークのバッチを作成することで、制約のない様々な種類の比較を行うことができるようになります。ロケーション アナリティクス ビューに加えて、Scanning API を利用することにより、カスタム アプリケーション用にリアルタイムのデータを検出して集約できます。

この Scanning API は、Meraki クラウドからデータをリアルタイムで提供します。こうしたリアルタイム データを活用すれば、Wi-Fi(接続状態を問わず)および Bluetooth Low Energy(BLE)デバイスをリアルタイムで検出できます。これらの要素は JSON データの HTTP POST を使用して、指定された宛先サーバにエクスポートされます。データは、Meraki クラウド上のネットワーク内のすべてのアクセス ポイントから集約され、クラウドから組織のデータ ウェアハウスまたはビジネス インテリジェンス センターへ直接送信されます。JSON は頻繁に送信されます(一般的には、各 AP に対して 1 分ごとにバッチ処理されます)。

Meraki クラウドはでは、ダッシュボードのマップとフロアプランからアクセス ポイントの物理的な配置を把握することによりクライアントの位置を推測します。地理的な位置の座標(緯度と経度)と X、Y の位置データの正確性は多数の要因に基づいており、ベストエフォートの推測と考える必要があります。AP の配置、環境の状態、クライアント デバイスの方向により、X、Y の推測は影響を受ける可能性があります。試験を行うことで、結果の精度を高めたり、データ ポイントに対して許容される不確実性の最大値を決定したりすることができます。

スキャン データの要素

Scanning API バージョン 2.0 のデータ アーキテクチャは、デバイスの分類と位置情報で構成されます。ダッシュボードのマップとフロアプランからアクセス ポイントの物理的な配置を把握することにより、クラウドはクライアントの位置を推測します。

 

データ要素

名前
形式
説明
apMac string 探索中の AP の MAC アドレス
apTags [string] ダッシュボード内の AP に適用されるすべてのタグの JSON アレイ
apFloors [string] この AP が表示されるすべてのフロアプランの JSON アレイ
clientMac string デバイスの MAC
seenTime ISO 8601 日付文字列 UTC での探索時間。たとえば "1970-01-01T00:00:00Z""
seenEpoch integer UNIX エポック タイムからの探索時間(秒)
rssi integer AP によって表示されるデバイスの RSSI
location location デバイスの地理位置情報。地理位置情報を確認できない場合は null
lat decimal デバイスの緯度(赤道との角度 N)
lng decimal デバイスの経度(子午線との角度 N)
unc decimal メートル単位での不確実性
x [decimal] 各フロアプランの左隅からの x オフセット(メートル単位)の JSON アレイ
y [decimal] 各フロアプランの左隅からの y オフセット(メートル単位)の JSON アレイ

Sorry, no results matched your search criteria(s). Please try again.

HTTP POST の本文形式

{
   "version":"2.0",
   "secret":<string>,
   "type":<event type>,
   "data":<event-specific data>
}

 

イベント固有のデータ形式

{
  "apMac": <string>,
  "apTags": [<string, ...],
  "apFloors": [<string>, ...],
  "observations": [
    {
      "clientMac": <string>,
      "ipv4": <string>,
      "ipv6": <string>,
      "seenTime": <string>,
      "seenEpoch": <integer>,
      "ssid": <string>,
      "rssi": <integer>,
      "manufacturer": <string>,
      "os": <string>,
      "location": {
        "lat": <decimal>,
        "lng": <decimal>,
        "unc": <decimal>,
        "x": [<decimal>, ...],
        "y": [<decimal>, ...]
      },
    },...
  ]
}

 

Scanning API を有効化する

Scanning API は、Meraki ダッシュボードの [ネットワーク全体(Network Wide)] > [一般(General)] 設定ページで、簡単な数ステップにより設定できます。

  1. ドロップダウン ボックスで Scanning API の有効化を選択して、API を有効にします。

  2. POST 用の URL と認証シークレットを指定します(認証シークレットは、現在の HTTP サーバで、JSON の送信元が Meraki クラウドであることを検証するために使用されます)。
  3. 現在の HTTP サーバで受信と処理の準備ができている Scanning API のバージョンを指定します。
  4. JSON オブジェクトを受け取るように HTTP サーバを設定し、ホストします。
  5. Meraki クラウドは、最初の接続時に HTTP GET を 1 度実行します。サーバからは、応答として組織固有の検証用文字列が返されるはずです。この文字列は、組織の ID を Cisco Meraki のユーザとして検証します。次に、Meraki クラウドが JSON の送信を開始します。 

 

 

 

Meraki クラウドとサードパーティ サーバ間のプロトコル フロー

 

Bluetooth Scanning API

Bluetooth Low Energy(BLE)無線と統合された Meraki AP は、付近の Bluetooth Low Energy デバイスを検出し、位置を確認します。このデータは、API 経由でサードパーティ アプリケーションに提供されます。このようなデバイスの例には、スマート ウォッチ、バッテリー ベースのビーコン、Apple iBeacons、フィットネス モニタ、リモート センサーなどがあります。 

Bluetooth のスキャンを有効化する

Meraki クラウドはでは、ダッシュボードのマップとフロアプランからアクセス ポイントの物理的な配置を把握することによりクライアントの位置を推測します。地理的な位置の座標(緯度と経度)と X、Y の位置データの正確性は多数の要因に基づいており、ベストエフォートの推測と考える必要があります。AP の配置、環境の状態、クライアント デバイスの方向により、X、Y の推測は影響を受ける可能性があります。試験を行うことで、結果の精度を高めたり、データ ポイントに対して許容される不確実性の最大値を決定したりすることができます。

 

BLE デバイスの検出を有効とするには、アクセス ポイントで BLE の無線のスキャンを有効化します。 BLE のスキャンを有効化するには、[ワイヤレス(Wireless)] > [Bluetooth の設定(Bluetooth Settings)] > [スキャン(Scanning)] 設定ページの [スキャン(Scanning)] セクションで [スキャンを有効化(Scanning enabled)] を選択します。

 

Bluetooth API のデータ要素

名前
形式
説明
apMac string 探索中の AP の MAC アドレス
apTags [string] ダッシュボード内の AP に適用されるすべてのタグの JSON アレイ
apFloors [string] この AP が表示されるすべてのフロアプランの JSON アレイ
clientMac string デバイスの MAC
seenTime ISO 8601 日付文字列 UTC での探索時間。たとえば "1970-01-01T00:00:00Z""
seenEpoch integer UNIX エポック タイムからの探索時間(秒)
rssi integer AP によって表示されるデバイスの RSSI
location location デバイスの地理位置情報。地理位置情報を確認できない場合は null
lat decimal デバイスの緯度(赤道との角度 N)
lng decimal デバイスの経度(子午線との角度 N)
unc decimal メートル単位での不確実性
x [decimal] 各フロアプランの左隅からの x オフセット(メートル単位)の JSON アレイ
y [decimal] 各フロアプランの左隅からの y オフセット(メートル単位)の JSON アレイ

Sorry, no results matched your search criteria(s). Please try again.

Scanning API と BLE スキャンを有効にすると、アクセス ポイントから検出された Wi-Fi および Bluetooth デバイスの両方を 1 つのデータ フィード内で確認できるようになります。 Bluetooth 無線での探索を識別するため、BluetoothDevicesSeen のイベント タイプが使用されます。Bluetooth デバイス用の Scanning API で使用される JSON 形式は以下のとおりです。

 

HTTP POST の本文形式

{
   "version":"2.0",
   "secret":<string>,
   "type":"BluetoothDevicesSeen",
   "data":<event-specific data>
}

 

位置情報とプライバシー

ロケーション情報の収集と使用に関して不安を感じるユーザがいることを、Meraki は理解しています。こうした懸念に対処するため、Meraki ではプライバシー保護を念頭に置いた位置情報サービスを開発しています。収集したデータから一意に特定可能な要素を削除するためのセキュリティ メカニズムなどです。Meraki はまた、お客様とパートナーに、プライバシー対応機能を複数導入するようお勧めしています。 

 

Meraki はプローブ リクエスト、データ フレーム、Bluetooth ビーコン フレームを使用して、クライアントの位置情報を把握し、格納しています。位置情報データには未加工の MAC アドレスが含まれているため、Meraki では、データを不可逆の形式で匿名状態にするセキュリティメカニズムを複数導入しています。データがアップロードされると、Meraki クラウドは MAC アドレスを匿名状態にするか、そのアドレスのハッシュを作成して、MAC アドレスが特定されないようにします。Meraki クラウドでは、ハッシュ処理されたバージョンの MAC アドレスのみが格納されます。

 

このハッシュ関数を以下に示します。

hash(mac bytes, org secret) =

SHA1(mac bytes ++ org secret).takeRight(4)

 

ここで、

+ + は連結を意味します。

takeRight(4) は SHA1 の下位 4 桁の 4 バイトを返します。

org secret は顧客ごとのソルトです。

 

例:

クライアント MAC:11:22:33:44:55:66

組織シークレット:t3lrdd

 

SHA1(112233445566t3Irdd) の下位 4 桁の 4 バイト= 0x0e456406

 

SHA1 は広く知られている 1 方向の暗号化関数です。この方法で SHA-1 ハッシュを使用することが、現在の業界標準です。SHA1 のハッシュに加え、追加のセキュリティ レイヤを実現するために、Meraki のハッシュ関数では、ハッシュを 4 バイトにトランケートします。これにより、この関数の領域が範囲よりも大きくなるため、理論上は情報が失われることになります。つまり 6 バイトの MAC では可能性が(2^48)になりますが、4 バイトのハッシュでは可能性が(2^32)になるためです。これにより、4 バイトにハッシュ処理をされた各 MAC アドレスの組み合わせでは、65,000(org + MAC)が可能となります。つまり、ソルトを付加し、ハッシュ処理した MAC を Meraki 独自のアルゴリズムでトランケートすることにより、元のクライアント MAC アドレスを特定できる確率は十分に低くなり、数学的に不可能となります。

 

ハッシュ関数を使用することで、理論上の情報の損失が発生し、クライアントの元の MAC アドレスは復元できません。 

 

Cisco Meraki のハッシュ関数には、お客様の組織に固有のシークレットが含まれます。そのため、Cisco Meraki が世界中のお客様のネットワークでのクライアントの動作を把握することはできません。そしてもちろん、Cisco Meraki のユーザが別のユーザの組織のアナリティクスを確認したり、自身の Wi-Fi/BLE ネットワークから離脱した後に、残されたユーザの情報を確認したりすることもできません。

 

また、Cisco Meraki の Web サイトにはグローバルなオプトアウト機能が用意されています。この機能では、ユーザが自分のデバイスの MAC アドレスを送信することで、Meraki クラウドの内蔵のロケーション アナリティクス ビューや、Scanning API を介したリアルタイム エクスポートで自分の MAC アドレスが検出されることを防げます。Cisco Meraki では、Scanning API を使用する小売業者などに対して、このグローバル オプトアウトが利用できることを通知するように推奨しています。店舗の正面や建物の入り口など、ロケーション検出が行われる場所の目につき易いところで掲げるように勧めています。 

 

データ プライバシー

上記で概要を説明した Cisco Meraki の Scanning API では、指定されたサードパーティのサーバに未加工の MAC アドレスがエクスポートされます。シスコでは、以下のような複数のプライバシー保護メカニズムを実装しています。

 

仕組み上、顧客 ID の関連付けが行われない

Cisco Meraki では、MAC アドレスとお客様の ID を関連付ける方法は、直接提供されていません。これらのシステムは、お客様、パートナー、プロバイダーで別途構築し、ホストする必要があります。

 

仕組み上、顧客との連絡が行われない

Cisco Meraki では、API データを使用して顧客と連絡を取るような仕組みは一切提供されていません。リアルタイムのユーザ エンゲージメントには、Cisco Meraki のユーザにより、顧客と連絡を取るための独自のプラットフォームが構築・維持される必要があります。

 

推奨するベスト プラクティス

Cisco Meraki では、API に関するベスト プラクティスをいくつか推奨しています。以下に例を挙げます。

  • オプトイン:ID の収集を行う際は、そのことを明示的に明らかにすべきです。たとえば、ユーザの提供する情報が(カスタマー エンゲージメントの一貫として)デバイスの MAC アドレスと関連付けられる場合があることを、スプラッシュ ページやモバイルアプリケーションなどで通知できます。
  • オンプレミス通知:内蔵のロケーション アナリティクスの場合と同様に、Scanning API のデータが使用されるエリアでは、目につくところに通知を表示するべきです。
  • オプトアウト:オプトイン ポリシーだけでなく、Cisco Meraki のグローバル オプト アウト ポリシー(MAC アドレスのオプトアウトを許可する)も顧客に通知し、Cisco Meraki のオプトアウト ページにアクセスできる分かりやすい手段を用意すべきです。Cisco Meraki のグローバル オプトアウトは https://account.meraki.com/optout から設定できます。

トラブルシューティング

ここでの「エンドポイント」とは、Scanning API からの POST を受信するサーバのことを指します。設定によっては、Apache や Nginx などの Web エンジン、さらに Rails サービスなどのバックエンド アプリケーションも含まれる場合があります。

Scanning API のデータが受信されない

Scanning API のデータが到着しない場合、問題の種類は 2 つに分けられます。 エンドポイントがダッシュボードから入ってくる TCP 接続を認識している場合と、していない場合です。

ダッシュボードからの接続がない

エンドポイントでダッシュボードからの接続を確認できない場合、最初の手順はエンドポイントとダッシュボードの間に基本的なネットワーク接続が存在するのを確認することです。エンドポイントの上流に存在するすべてのファイアウォールのログを調べ、フィルタリングが行われていないことを確認します。ファイアウォールが存在しない場合や、ファイアウォールによる制約が比較的少ない場合は、任意の外部アドレスからエンドポイントに対して telnet が実行できるはずです。

以下で説明するように、エンドポイントの応答が遅延する場合は、短期間(15 ~ 20 分以上)のデータの欠落が発生する場合もあります。エンドポイントのログに応答の遅延やエラーが示されていない場合で、他のソースからエンドポイントへの接続が確認できる場合、かつトラフィックのフィルタリングが行われていない場合は、Cisco Meraki サポートにご連絡ください

ダッシュボードからの接続がある

ダッシュボードからの TCP 接続が確認されるが、Scanning API のデータが受信されない場合は、以下の問題についてご確認ください。

  • HTTPS に関する考慮事項

HTTPS を使用している場合、エンドポイントには、適正な公的証明機関によって署名された有効な証明書がなければなりません。証明書が一般に認められている CA によって署名されていない場合、有効期限が切れている場合、失効している場合、あるいはその他の理由で無効な場合には、POST を受信するためのセッションを確立することができません。

状況によっては、署名済みの証明書が有効であっても、ダッシュボードにとって未知の仲介 CA によって署名されている場合は、やはり認識されないことがあります。 こうした理由から、HTTPS を使用する場合には、完全な CA チェーンを含めることをお勧めします。

  • エンドポイントの応答時間が長すぎる

エンドポイントで POST への応答に非常に長い時間(500ms 以上)がかかる場合、そのエンドポイントの情報は送信されずにドロップされます。 そのためアプリケーションでは、受信する Scanning API のデータの処理とデータのルーティングを分けることをお勧めします。

  • エンドポイントからエラーが返される 

アプリケーションおよびサービスのログをチェックして、エンドポイント アプリケーションがエラーを報告していないかどうか確認してください。資料とトラブルシューティングに関する支援については、ご使用のエンドポイント アプリケーション/サービスのベンダーにお問い合わせください。

  • URL の検証に失敗する

URL の検証の際には、エンドポイントは本文に検証用の文字列のみを含め、200 OK の応答を返す必要があります。応答が 200 OK 以外である場合、または本文が検証用文字列と完全に一致しない場合、検証は失敗し、エンドポイントの URI をエントリとして保存することはできません。エンドポイントが正しく応答しているかどうかを確認するには、Google Chrome や Firefox などのブラウザを使用して POST URL に直接アクセスする方法や、curl を利用して GET リクエストを生成する方法があります。

不正な形式のデータ

クライアントがネットワークにアソシエーションを行った場合には一定の情報が含まれます。また、アソシエーションを行った場合にしか含まれない情報もあります。製造者、OS、SSID、IP アドレッシングなどです。位置の値や AP タグなどは、利用可能な場合にのみ含まれる情報です。 その他の情報は、常に含まれ、値が存在するはずです。値が存在しない場合は、Meraki サポートまでご連絡ください。