Идентификация пользователей в Flutter SDK
Adapty создаёт внутренний ID профиля для каждого пользователя. Однако если у вас есть собственная система аутентификации, вы можете задать свой Customer User ID. Пользователей можно искать по Customer User ID в разделе Профили, а также использовать его в серверном API — он будет передаваться во все интеграции.
Передача пользовательского идентификатора при инициализации
Если у вас есть идентификатор пользователя на момент инициализации, просто передайте его в качестве параметра customerUserId в метод .activate():
try {
await Adapty().activate(
configuration: AdaptyConfiguration(apiKey: 'YOUR_API_KEY')
..withCustomerUserId(YOUR_CUSTOMER_USER_ID)
);
} catch (e) {
// handle the error
}
Хотите увидеть реальный пример интеграции Adapty SDK в мобильное приложение? Посмотрите наши примеры приложений — они демонстрируют полную настройку: отображение пейволов, совершение покупок и другие базовые функции.
Установка идентификатора пользователя после инициализации
Если при инициализации SDK у вас не было идентификатора пользователя, его можно задать в любой момент позже с помощью метода .identify(). Чаще всего этот метод используют после регистрации или авторизации — когда анонимный пользователь становится аутентифицированным.
try {
await Adapty().identify(customerUserId);
} on AdaptyError catch (adaptyError) {
// handle the error
} catch (e) {
}
Параметры запроса:
- Customer User ID (обязательный): строковый идентификатор пользователя.
Повторная отправка важных данных пользователя
В некоторых случаях, например когда пользователь снова входит в свой аккаунт, серверы Adapty уже располагают информацией об этом пользователе. В таких сценариях SDK автоматически переключится на работу с новым пользователем. Если вы передавали какие-либо данные анонимному пользователю — например, пользовательские атрибуты или атрибуцию из сторонних сетей — эти данные необходимо отправить повторно для идентифицированного пользователя.
Также важно помнить, что после идентификации пользователя нужно заново запросить все пейволы и продукты, поскольку данные нового пользователя могут отличаться.
Выход и вход
Вы можете выйти из аккаунта пользователя в любое время, вызвав метод .logout():
try {
await Adapty().logout();
} on AdaptyError catch (adaptyError) {
// handle the error
} catch (e) {
// handle unknown error
}
После этого можно авторизовать пользователя с помощью метода .identify().
Назначение appAccountToken (iOS)
appAccountToken — это UUID, который позволяет связывать транзакции App Store с вашим внутренним идентификатором пользователя.
StoreKit привязывает этот токен к каждой транзакции, поэтому ваш бэкенд может сопоставлять данные App Store с конкретными пользователями.
Используйте стабильный UUID, генерируемый один раз для каждого пользователя, и применяйте его для одного и того же аккаунта на всех устройствах. Это гарантирует, что покупки и уведомления App Store будут корректно привязаны к нужному пользователю. Токен можно задать двумя способами — при активации SDK или при идентификации пользователя.
Всегда передавайте appAccountToken вместе с customerUserId.
Если передать только токен, он не будет включён в транзакцию.
// Во время конфигурации:
try {
await Adapty().activate(
configuration: AdaptyConfiguration(apiKey: 'YOUR_API_KEY')
..withCustomerUserId(YOUR_CUSTOMER_USER_ID, iosAppAccountToken: "YOUR_APP_ACCOUNT_TOKEN")
);
} catch (e) {
// обработайте ошибку
}
// Или при идентификации пользователей
try {
await Adapty().identify(customerUserId, iosAppAccountToken: "YOUR_APP_ACCOUNT_TOKEN");
} on AdaptyError catch (adaptyError) {
// обработайте ошибку
} catch (e) {
}
Установка обфусцированных идентификаторов аккаунта (Android)
Google Play требует обфусцированные идентификаторы аккаунта для определённых сценариев использования — с целью защиты конфиденциальности и безопасности пользователей. Эти идентификаторы позволяют Google Play отслеживать покупки, сохраняя анонимность пользователей, что особенно важно для предотвращения мошенничества и аналитики.
Задавать эти идентификаторы может потребоваться, если приложение работает с чувствительными пользовательскими данными или если вы обязаны соблюдать определённые требования по защите персональных данных. Обфусцированные идентификаторы позволяют Google Play отслеживать покупки, не раскрывая реальные пользовательские данные.
// Во время настройки:
try {
await Adapty().activate(
configuration: AdaptyConfiguration(apiKey: 'YOUR_API_KEY')
..withCustomerUserId(YOUR_CUSTOMER_USER_ID, androidObfuscatedAccountId: "OBFUSCATED_ACCOUNT_ID")
);
} catch (e) {
// обработка ошибки
}
// Или при идентификации пользователей
try {
await Adapty().identify(customerUserId, androidObfuscatedAccountId: "OBFUSCATED_ACCOUNT_ID");
} on AdaptyError catch (adaptyError) {
// обработка ошибки
} catch (e) {
}
Определение пользователей на разных устройствах
При активации SDK он автоматически считывает существующие права пользователя из StoreKit (iOS) или Google Play Billing (Android) и синхронизирует их с бэкендом Adapty. Активная подписка появляется в профиле Adapty без вызова restorePurchases со стороны приложения.
Что не происходит автоматически — так это распознавание того, что профиль на новом устройстве принадлежит тому же пользователю, что и профиль на исходном устройстве. Adapty сопоставляет профили по Customer User ID, поэтому непрерывность идентификации зависит от того, что вы используете в качестве CUID.
Что Adapty может определить между устройствами
| Ваша настройка | Что Adapty определяет | Что нужно сделать |
|---|---|---|
Customer User ID = device_id (без входа в аккаунт) | Новое устройство получает другой CUID и, следовательно, другой профиль. Подписка синхронизируется с новым профилем через событие Access level updated, но subscription_started не срабатывает — новый профиль считается наследником исходной покупки. Аналитика, основанная на subscription_started, будет занижать количество возвращающихся пользователей. | Используйте стабильный идентификатор аккаунта в качестве Customer User ID, чтобы вернувшийся пользователь соответствовал существующему профилю на разных устройствах. |
| Customer User ID = стабильный идентификатор аккаунта (вход на каждом устройстве) | SDK автоматически синхронизирует подписку при activate(), а identify() сопоставляет существующий профиль по CUID. | Никаких дополнительных действий не требуется — и идентификация, и подписка разрешаются автоматически. |
| Наследник Apple Family Sharing | Член семьи получает подписку только через событие Access level updated — subscription_started не срабатывает. | Отслеживайте событие Access level updated. Полную матрицу событий см. в разделе Apple Family Sharing. |
| Один аккаунт Apple/Google, разные пользователи внутри приложения | Первый профиль, зафиксировавший покупку, становится родительским. Последующие профили видят подписку через цепочку наследования с одним событием Access level updated. | Требуйте входа в аккаунт, затем выберите режим совместного использования, подходящий для вашей модели. |
Восстановление покупок на новом устройстве
Добавьте кнопку «Восстановить покупки», инициируемую пользователем, на свой пейвол. Apple App Review (руководство 3.1.1) её требует, и она служит запасным вариантом на случай, если автоматическая синхронизация пропустит граничный случай. Кнопка должна вызывать restorePurchases в вашем SDK.
Программный вызов restorePurchases при первом запуске не нужен для обычного использования — SDK уже выполняет аналогичную операцию при activate(). Программные вызовы стоит использовать только для принудительной проверки чека, например при отладке отсутствующего доступа после завершения activate().