アバターIDの紐づけ方¶
ゲストユーザの作成や着せ替えアプリとの接続を完了して得られたアバターIDは、自社アプリのユーザと紐づけて保持しておく必要があります。このページでは、自社アプリがRDBMSを利用している想定で、紐づけ方の指針を示します。
Info
Guest API 経由で作成されたユーザを「ゲストユーザ」、Avatar Play の着せ替えアプリと接続したユーザを「連携済みユーザ」と呼んでいます。
データ設計¶
次のようなデータスキーマを利用することを推奨しています。
| データ項目 | 型 | 制約 | 値のサンプル |
|---|---|---|---|
| 自社アプリのユーザID | ユニーク制約あり | A | |
| アバターID | long | ユニーク制約なし | 123 |
アバターIDはゲストユーザから連携済みユーザにアップグレードする際に変更されます。
ユースケース例¶
ユーザが自社アプリを開始した時に、ゲストユーザのアバターID(123)を作成します。
| 自社アプリのユーザID | アバターID | ユーザのステータス |
|---|---|---|
| A | 123 | ゲストユーザ |
ユーザが着せ替えアプリとの接続を完了(=アップグレード)すると、連携済みユーザのアバターID(456)が発行されるのでRDBMSのアバターIDを更新します。
| 自社アプリのユーザID | アバターID | ユーザのステータス |
|---|---|---|
| A | 456 | 連携済みユーザ |
アップグレード以外の手段でアバターIDが切り替わることを防ぐためには、連携済みユーザの場合はアバターIDの更新を拒否するよう実装します。ユーザのステータスは、Avatar API から取得できます。
アバターIDが重複するケース¶
同一のユーザが新たに自社アプリを開始し、ゲストユーザユーザのアバターID(789)を作成します。ここで、ユーザAとBはシステム上は別ユーザですが、実態は一人のユーザが利用している状態です。
| 自社アプリのユーザID | アバターID | ユーザのステータス |
|---|---|---|
| A | 456 | 連携済みユーザ |
| B | 789 | ゲストユーザ |
ユーザがユーザBとして着せ替えアプリとの接続を完了し、ゲストユーザ(789)から連携済みユーザ(456)へアップグレードします。
| 自社アプリのユーザID | アバターID | ユーザのステータス |
|---|---|---|
| A | 456 | 連携済みユーザ |
| B | 456 | 連携済みユーザ |
ユーザAとBでアバターIDが重複しますが、同一ユーザによる同じアバターであるため、許容することを推奨します。
アバターIDの重複を許容しないデータ設計¶
前述のとおりアバターIDの重複を許容することを推奨しますが、何らかしらの理由で許容できない場合、アバターIDのデータ項目に対してユニーク制約を付けることが可能です。
| データ項目 | 型 | 制約 | 値のサンプル |
|---|---|---|---|
| 自社アプリのユーザID | ユニーク制約あり | A | |
| アバターID | long | ユニーク制約あり | 123 |
合わせて、コンソールの「アプリ > 各アプリの設定 > 変更」から、1ユーザのアップグレード回数制限を1に設定します。
Info
アバターIDの重複を許容したくないケースの一つに、何度もインストール・アンインストールを繰り返すユーザへの対策が挙げられます。過度な繰り返し操作を回避したいだけであれば、1ユーザの1アプリに対するアップグレード回数制限を利用できます。
ユースケース例¶
自社アプリ側で次のようにゲストユーザを作成します。
| 自社アプリのユーザID | アバターID | ユーザのステータス |
|---|---|---|
| A | 123 | ゲストユーザ |
| B | 789 | ゲストユーザ |
ユーザAを連携済みユーザ(456)へアップグレードします。
| 自社アプリのユーザID | アバターID | ユーザのステータス |
|---|---|---|
| A | 456 | 連携済みユーザ |
| B | 789 | ゲストユーザ |
ユーザBを連携済みユーザ(456)へアップグレードしようとしても、ユニーク制約(または Avatar Play 側のアップグレード回数制限)によりエラーとなります。
注意点¶
上記の例では、ユーザAとBは同一ユーザと考えられるため、自社アプリ側でユーザAに切り替える手段を提供する必要があります。通常は、ログイン機能を使ってユーザBからAに切り替えれるようにします。