コンテンツにスキップ

アバター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に切り替えれるようにします。


最終更新日: 2021-02-24