Skip to content

アバターIDの紐づけ方

ゲストユーザの作成や着せ替えアプリとの接続を完了して得られたアバターIDは、自社アプリのユーザと紐づけて保持しておく必要があります。このページでは、自社アプリがRDBMSを利用している想定で、紐づけ方の指針を示します。

推奨されるデータ設計

特別な理由がない限り、次のようなデータスキーマを利用することを推奨しています。

データ項目 制約 値のサンプル
自社アプリのユーザID ユニーク制約あり A
アバターID long ユニーク制約なし 123
ゲストユーザフラグ bool true

アバターIDはゲストユーザから正規ユーザにアップグレードする際に変更されます。ゲストユーザかどうかを判別する手段にAvatar APIを利用することもできますが、ここではサーバ間通信によるレイテンシを回避するためにRDBMSにゲストユーザフラグを持たせています。

ユースケース例

ユーザが自社アプリを開始した時に、ゲストユーザのアバターID(123)を作成します。

自社アプリのユーザID アバターID ゲストユーザフラグ
A 123 true

ユーザが着せ替えアプリとの接続を完了(=アップグレード)すると、正規ユーザのアバターID(456)が発行されるのでRDBMSのアバターIDを更新します。

自社アプリのユーザID アバターID ゲストユーザフラグ
A 456 false

以降は、ユーザAによるアップグレード操作が行われないように制限します。

アバターIDが重複するケース

同一のユーザが新たに自社アプリを開始し、ゲストユーザのアバターID(789)を作成します。ここで、ユーザAとBはシステム上は別ユーザですが、実態は一人のユーザが利用している状態です。

自社アプリのユーザID アバターID ゲストユーザフラグ
A 456 false
B 789 true

ユーザがユーザBとして着せ替えアプリとの接続を完了し、ゲストユーザ(789)から正規ユーザ(456)へアップグレードします。

自社アプリのユーザID アバターID ゲストユーザフラグ
A 456 false
B 456 false

ユーザAとBでアバターIDが重複しますが、同一ユーザによる同じアバターであるため、許容することを推奨します。

アバターIDの重複を許容しないデータ設計

前述のとおりアバターIDの重複を許容することを推奨しますが、何らかしらの理由で許容できない場合、アバターIDのデータ項目に対してユニーク制約を付けることが可能です。

データ項目 制約 値のサンプル
自社アプリのユーザID ユニーク制約あり A
アバターID long ユニーク制約あり 123
ゲストユーザフラグ bool true

合わせて、アプリの1ユーザのアップグレード回数上限を1に設定します。

Info

アバターIDの重複を許容したくないケースの一つに、何度もインストール・アンインストールを繰り返すユーザへの対策が挙げられます。過度な繰り返し操作を回避したいだけであれば、1ユーザの1アプリに対するアップグレード回数制限を利用できます。

ユースケース例

自社アプリ側で次のようにゲストユーザを作成します。

自社アプリのユーザID アバターID ゲストユーザフラグ
A 123 true
B 789 true

ユーザAを正規ユーザ(456)へアップグレードします。

自社アプリのユーザID アバターID ゲストユーザフラグ
A 456 false
B 789 true

ユーザBを正規ユーザ(456)へアップグレードしようとしても、ユニーク制約によりエラーとなります。

注意点

上記の例では、ユーザAとBは同一ユーザと考えられるため、自社アプリ側でユーザAに切り替える手段を提供する必要があります。通常は、ログイン機能を使ってユーザBからAに切り替えれるようにします。