デジタルサービスの多くはWebサイト以外にモバイルアプリでもサービスも提供しています。継続的・反復的にサービスを利用してもらうためには検索から入るWebサイトよりも手元に常駐するアプリの方が優位である事は明らかです。同じようなサービス・アプリが乱立する中、より良いユーザー体験（UX）を提供する方が競争優位にもなります。同様のサービスであればWebサイトをただぶらさげただけでユーザー評価が星１つのアプリより、ネイティブで実装されより良いユーザー体験を提供する星4つ以上のアプリが選ばれるでしょう。
New Relic Mobileを導入すると全てのユーザーから起動回数、クラッシュ情報をはじめ通信レスポンスやエラーなど様々な情報を多角的に観測できます。多くのアプリではユーザー登録やデバイス登録により個別のユーザーを特定しサービスを提供しているでしょう。B2Bアプリでは企業IDなどを利用してテナントをわけているかもしれません。それらの情報が特定できれば、例えば特定テナントにおいて問題が発生していないか、個別ユーザーからのクレームの根本原因がシステムのどこにあるのか、調査や解析が楽になります。
この記事ではそういったユーザー識別情報をNew Relicに送る方法と、解析の一歩目をご紹介します。
New Relic MobileのEvent情報
New Relic Mobileのエージェントを導入すると様々なEventが作成されます。通信結果を確認できるMobileRequestやMobileRequestError、クラッシュ情報を確認するMobileCrashなどです。
それらの情報にはエージェントによりsessionIdが振られており1回の起動に対するユーザーの様々な行動を把握できるようになっています。
しかし例えば致命的なサーバーエラーが発生していた際、影響のあったユーザーの一覧を作ろうとするのはその時間帯のサーバー側のログやログイン履歴など多方面から調べる必要が出るのでsessionIdだけでは特定は困難です。
そこでアプリ自体がログイン処理などを通して把握しているユーザーを特定できる情報を（ハッシュ化された値、IDなど個人情報に配慮した上で）New RelicにsessionIdと紐づけて登録し、迅速に調査ができます。
Mobile SDKからユーザー情報を登録する
Mobile SDKの提供するsetUserIdを利用すると簡単にユーザー情報を属性として登録できます。
例えばswiftで書かれたiOSアプリの場合
let UserId = "404842369"
NewRelic.setUserId(UserId)とすればそのセッションに紐づく全てのイベントをUserIdで検索できるようになります。
※実際は起動時plistなどに保持したユーザー情報や、ログイン処理の際に値を登録してください
setUserID自体はいつ行っても構いません。行った時点で過去にさかのぼりCustom Eventsを含む同一セッションで登録された様々なイベントを横断で検索できるようになります。
Mobile UIで利用する
Mobile Requestなど、属性でグループ化できる画面で実際に選択してみましょう。
ユーザーIDごとでリクエスト時間などのメトリクスが分類できるようになります。
NRQLでユーザー情報からイベントを検索する
それでは実際にNew Relic上から前述のユーザーがどういった通信をしたか、どういったBreadcrumbsを残したか横断的に確認してみましょう。
上記のセッション例ではコード上"Exception Menu"をタップしたタイミングでsetUserIdを実施しています。
タイムスタンプを見ると、さかのぼってユーザーが何をしたのか観測できることが確認できます。
Dashboard上でフィルタとして利用する
最新のアクセス時間順のユーザー一覧を作り、それらのユーザーの通信レスポンス、URL一覧をフィルタするDashboardを作ってみます。
Widgetの一つ目で [Facet Linking]を[Filter the current dashboard]をオンにし、UserIdでのダッシュボード全体フィルタリングを有効にします。
このダッシュボードでユーザーIDの右側・フィルタリングボタンをクリックすると通信一覧のテーブルが更新され、特定のユーザーに絞った情報を表示できます。
Dashboard上でフィルタ結果として利用する
今度は逆に、特定の通信失敗URLから影響を受けたユーザー一覧を作成してみます。
これでリクエストエラーのURL一覧から、その通信を実施したユーザー一覧を抽出できるようになりました。
通信エラーのURLを切り口として影響ユーザーを分析する、というのは活用の一端に過ぎません。
関連記事にあるBreadcrumbsやその他自在に追加できるデータを横断的に見られれば、サーバーサイドだけ見ていては気付けない本当のユーザー体験の観測に利用できること、そして仮に体験の問題がサーバーサイドにある場合には分散トレーシングにより問題のシステム側根本原因にたどり着けるようになります。
また、この記事でご紹介したsetUserIdでは"UserId"という名前の属性で情報を登録していますが、ユーザー名以外に役立つ補助情報がある場合、setCustomAttribute APIを使えば複数の属性情報をセッションに付与できます。
活用次第で様々な課題解決に役立つsetUserIdを是非ご利用ください。
本ブログに掲載されている見解は著者に所属するものであり、必ずしも New Relic 株式会社の公式見解であるわけではありません。また、本ブログには、外部サイトにアクセスするリンクが含まれる場合があります。それらリンク先の内容について、New Relic がいかなる保証も提供することはありません。
