React Native SDKでユーザーを識別する
Adaptyはすべてのユーザーに対して内部プロファイルIDを作成します。ただし、独自の認証システムがある場合は、Customer User IDを設定してください。ProfilesセクションでCustomer User IDからユーザーを検索したり、サーバーサイドAPIで使用したりできます。このIDはすべての連携先にも送信されます。
設定時にCustomer User IDを設定する
設定時にユーザーIDが取得できる場合は、.activate()メソッドのcustomerUserIdパラメーターとして渡すだけです。
adapty.activate("PUBLIC_SDK_KEY", {
customerUserId: "YOUR_USER_ID"
});
Adapty SDK がモバイルアプリにどのように統合されているか、実際の例を見てみませんか?ペイウォールの表示、購入処理、その他の基本機能を含む完全なセットアップを実演しているサンプルアプリをご覧ください。
設定後にCustomer User IDを設定する
SDKの設定時にユーザーIDが取得できない場合は、後から.identify()メソッドを使っていつでも設定できます。最も一般的なユースケースは、ユーザーが匿名ユーザーから認証済みユーザーに切り替わる、登録後や認証後です。
try {
await adapty.identify("YOUR_USER_ID");
// successfully identified
} catch (error) {
// handle the error
}
リクエストパラメーター:
- Customer User ID(必須): 文字列のユーザー識別子。
重要なユーザーデータの再送信
ユーザーがアカウントに再度ログインした場合など、Adaptyのサーバーがそのユーザーの情報をすでに保持しているケースがあります。そのような場合、Adapty SDKは自動的に新しいユーザーとして動作を切り替えます。カスタム属性やサードパーティネットワークからのアトリビューションなど、匿名ユーザーに対して設定していたデータがあれば、識別済みユーザーに対して再度送信する必要があります。
また、新しいユーザーのデータが異なる可能性があるため、ユーザーを識別した後はすべてのペイウォールとプロダクトを再取得することも重要です。
ログアウトとログイン
.logout()メソッドを呼び出すことで、いつでもユーザーをログアウトできます。
try {
await adapty.logout();
// successful logout
} catch (error) {
// handle the error
}
その後、.identify()メソッドを使ってユーザーをログインさせることができます。
appAccountTokenを割り当てる(iOS)
appAccountTokenは、App Storeのトランザクションを内部のユーザーIDに紐付けるためのUUIDです。
StoreKitはすべてのトランザクションにこのトークンを関連付けるため、バックエンドでApp Storeのデータとユーザーを照合できます。
ユーザーごとに生成した安定したUUIDを使用し、同じアカウントでは複数のデバイス間で同じものを再利用してください。 これにより、購入とApp Storeの通知が正しく紐付けられます。
トークンは2つの方法で設定できます。SDKのアクティベーション時、またはユーザーの識別時です。
appAccountTokenは必ずcustomerUserIdと一緒に渡す必要があります。
トークンのみを渡した場合、トランザクションに含まれません。
// During configuration:
adapty.activate("PUBLIC_SDK_KEY", {
customerUserId: "YOUR_USER_ID",
ios: { appAccountToken: "YOUR_APP_ACCOUNT_TOKEN" },
});
// Or when identifying users
try {
await adapty.identify("YOUR_USER_ID", {
ios: {appAccountToken: 'YOUR_APP_ACCOUNT_TOKEN'}
});
// successfully identified
} catch (error) {
// handle the error
}
難読化アカウントIDを設定する(Android)
Google Playでは、ユーザーのプライバシーとセキュリティを強化するために、特定のユースケースで難読化アカウントIDが必要です。これらのIDは、ユーザー情報を匿名のまま購入をGoogle Playが識別するのに役立ちます。不正防止や分析において特に重要です。
アプリが機密性の高いユーザーデータを扱う場合や、特定のプライバシー規制への準拠が求められる場合に、これらのIDを設定する必要があります。難読化されたIDを使うことで、実際のユーザー識別子を公開せずにGoogle Playが購入を追跡できます。
// During configuration:
adapty.activate("PUBLIC_SDK_KEY", {
customerUserId: "YOUR_USER_ID",
android: { obfuscatedAccountId: 'YOUR_OBFUSCATED_ACCOUNT_ID' }
});
// Or when identifying users
try {
await adapty.identify("YOUR_USER_ID", {
android: { obfuscatedAccountId: 'YOUR_OBFUSCATED_ACCOUNT_ID' }
});
// successfully identified
} catch (error) {
// handle the error
}
複数デバイス間でユーザーを検出する
SDKが有効化されると、StoreKit(iOS)またはGoogle Play Billing(Android)からユーザーの既存のエンタイトルメントを自動的に読み取り、Adaptyバックエンドと同期します。有効なサブスクリプションは、アプリがrestorePurchasesを呼び出すことなく、Adaptyプロファイルに表示されます。
自動では行われないのは、新しいデバイスのプロファイルが元のデバイスと同じユーザーのものであることの認識です。AdaptyはCustomer User IDでプロファイルを照合するため、同一性の継続性はCUIDとして何を使用するかによって異なります。
デバイス間でAdaptyが検出できること
| あなたの設定 | Adaptyが検出すること | 必要な対応 |
|---|---|---|
Customer User ID = device_id(アプリのログインなし) | 新しいデバイスは異なるCUIDを取得するため、異なるプロファイルが作成されます。サブスクリプションはAccess level updatedイベントを通じて新しいプロファイルに同期されますが、subscription_startedは発火しません。新しいプロファイルは元の購入の継承者として扱われます。subscription_startedに基づくアナリティクスは、リターニングユーザーをカウント不足します。 | リターニングユーザーが既存のプロファイルをデバイス間で照合できるよう、安定したアカウントIDをCustomer User IDとして使用してください。 |
| Customer User ID = 安定したアカウントID(すべてのデバイスでログイン) | SDKはactivate()でサブスクリプションを自動同期し、identify()がCUIDで既存のプロファイルを照合します。 | 追加の設定は不要です。IDとサブスクリプションの両方が自動的に解決されます。 |
| Apple Family Sharing の継承者 | ファミリーメンバーはAccess level updatedイベントのみを通じてサブスクリプションを受け取ります。subscription_startedは発火しません。 | Access level updatedをリッスンしてください。完全なイベントマトリクスはApple Family Sharingを参照してください。 |
| 同じApple/Googleアカウント、異なるアプリ内ユーザー | 最初に購入を記録したプロファイルが親になります。その後のプロファイルは継承者チェーンを通じてサブスクリプションを確認し、Access level updatedイベントが1回発生します。 | ログインを必須にし、あなたのモデルに合った共有モードを選択してください。 |
新しいデバイスでの購入の復元
ペイウォールにユーザーが操作できる「購入を復元」ボタンを設置してください。Apple App Review(ガイドライン3.1.1)で必須とされており、自動同期がエッジケースを見逃した場合のフォールバックとして機能します。このボタンはSDKのrestorePurchasesを呼び出す必要があります。
初回起動時にプログラムでrestorePurchasesを呼び出すことは、通常の使用では必要ありません。SDKはすでにactivate()で同等の処理を実行しています。プログラムによる呼び出しは、activate()完了後にアクセスが欠落している場合のデバッグなど、強制的に新しいレシートチェックを行う場合にのみ使用してください。