Android 一意の識別子のベストプラクティス


Develop > Training > 一意の識別子のベスト プラクティス
とても良い資料でした。

ほとんどのアプリが広告やユーザー管理、ログのトラッキング等々の為にユーザーを識別するためのナニカを利用していると思います。
そのナニカをどーするか問題で開発側と営業・企画側とひと悶着あったりなかったりなプロダクトも多いでしょう。

Android だけでは無く、iOS や Web 含めどんなプロダクトでも同様なので
またナニカがあれば都度都度読み返したい資料でした。

ユースケースの内容が非常に良かったので以下、抜粋

一般的なユースケースと使用する識別子
このセクションでは、IMEI や SSAID などのハードウェア ID の代わりに、多くのユースケース使用する別の識別子について説明します。ユーザーはハードウェア ID をリセットできないことに加えて、ハードウェア ID の収集を限定的にしか制御できないため、ハードウェア ID の使用はお勧めしません。

ログアウトしたユーザー設定のトラッキング
このケースでは、サーバー側で端末ごとの状態を保存します。

推奨する識別子:インスタンス ID または GUID。

推奨する理由:

アプリの再インストール後も情報を維持することはお勧めしません。ユーザーは、アプリを再インストールすることにより、ユーザー設定をリセットしなければならない場合があるからです。

ログアウトしたユーザー行動のトラッキング
このケースでは、同じ端末の異なるアプリやセッションでのユーザーの行動に基づいて、ユーザーのプロファイルを作成します。

推奨する識別子:広告 ID。

推奨する理由:

Google Play デベロッパー コンテンツ ポリシーで規定されているように、ユーザーは広告 ID をリセットできるため、広告のユースケースでは、広告 ID を必ず使用する必要があります。

ログアウトしたユーザーまたは匿名のユーザー分析の生成
このケースでは、ログアウトしたユーザーまたは匿名のユーザーの使用統計情報や分析を評価します。

推奨する識別子:インスタンス ID。インスタンス ID が不十分な場合は、GUID を使用できます。

推奨する理由:

インスタンス ID または GUID は、これらの ID を作成したアプリに適用されるため、これらの ID を使用して複数のアプリでユーザーをトラッキングすることが防止されます。アプリのデータをクリアするか、アプリを再インストールすることにより、これらの ID を簡単にリセットできます。インスタンス ID と GUID は簡単に作成できます。

インスタンス ID の作成: String iid = InstanceID.getInstance(context).getId()
GUID 作成: String uniqueID = UUID.randomUUID().toString
収集しているデータが匿名であることをユーザーに通知している場合、識別子を PII に関連付けていないことや、識別子を PII とリンクされている可能性のあるその他の識別子に関連付けていないことを確認する必要があることに注意してください。

Google Analytics for Mobile Apps を使用することもできます。Google アナリティクスは、アプリ単位で分析するためのソリューションを提供します。

ログアウトしたユーザー コンバージョンのトラッキング
このケースでは、コンバージョンをトラッキングし、マーケティング戦略が成功したかどうかを判定します。

推奨する識別子:広告 ID。

推奨する理由:

これは広告関連のユースケースであり、さまざまなアプリで利用できる ID が必要であるため、広告 ID の使用が最も適切なソリューションになります。

複数のインストールの処理
このケースでは、同じユーザーの複数の端末にアプリがインストールされている場合に、アプリの正しいインスタンスを識別する必要があります。

推奨する識別子:インスタンス ID または GUID。

推奨する理由:

インスタンス ID は、この目的のために明示的に設計されています。インスタンス ID のスコープはこのアプリに制限されているため、インスタンス ID を使用して、さまざまなアプリでユーザーをトラッキングすることはできません。また、アプリを再インストールすると、インスタンス ID はリセットされます。まれに、インスタンス ID では不十分な場合は、GUID を使用することもできます。

不正防止:無料コンテンツ制限の適用および結託攻撃の検知
このケースでは、ユーザーが端末に表示できる無料コンテンツ(記事など)の数を制限します。

推奨する識別子:インスタンス ID または GUID。

推奨する理由:

GUID またはインスタンス ID を使用すると、ユーザーは、コンテンツの制限を超えるためにアプリを再インストールする必要があります。これは、ほとんどのユーザーにとって、十分な障壁になります。この対策では十分ではない場合、Android は、コンテンツへのアクセスを制限できる DRM API を提供します。

電話機能および携帯通信会社機能の管理
このケースでは、アプリで端末の電話機能とテキスト送信機能を操作します。

推奨する識別子:IMEI、IMSI、および Line1(Android 6.0(API レベル 23)以降では PHONE パーミッション グループが必要)。

推奨する理由:

電話および携帯通信会社に関連する機能にハードウェア ID が必要な場合、ハードウェア ID の使用が許容されます。たとえば、SIM ベースのユーザー アカウントで、携帯通信会社 / SIM スロットを切り替える場合や、IP(Line1 用)を介して SMS メッセージを配信する場合などです。ただし、Android 6.0 以降では、ランタイム パーミッションを使用する場合にのみ、これらの識別子を使用でき、ユーザーがこのパーミッションをオフに切り替えた場合は、アプリでこれらの例外を適切に処理する必要があることに注意してください。

不正使用の検知:ボットおよび DDoS 攻撃の特定
このケースでは、バックエンド サービスを攻撃する複数の疑似デバイスを検知します。

推奨する識別子:Safetynet API。

推奨する理由:

単独の識別子を使用した場合、端末が正規のものであるかどうかの判定が難しくなります。Safetynet API の SafetyNet.SafetyNetApi.attest(mGoogleApiClient, nonce) メソッドを使用して、リクエストを実行している端末が正規のものであるかどうかを判定することにより、正規の Android 端末(エミュレータ、または別の端末になりすましたコードではなく)からリクエストが送信されていることを確認できます。詳細については、Safetynet の API ドキュメントを参照してください。

不正使用の検知:盗まされた価値の高い認証情報の検知
このケースでは、盗まれた価値の高い認証情報を使用して、単一の端末が繰り返し使用されている(不正な支払いを行う目的などで)かどうかを検知します。

推奨する識別子:IMEI または IMSI(Android 6.0(API レベル 23)以降では PHONE パーミッション グループが必要)。

推奨する理由:

端末で盗まれた認証情報が使用されると、盗まれた価値の高い複数の認証情報(トークン化されたクレジット カードなど)が換金される可能性があります。こうしたシナリオでは、検知を避けるためにソフトウェア ID がリセットされる場合があるため、ハードウェア ID を使用することがあります。

 

 

 

 


コメントを残す

メールアドレスが公開されることはありません。