Как работают профили

Каждый пользователь вашего приложения получает профиль Adapty, в котором отслеживаются его покупки, события и состояние подписки. Понимание того, как профили создаются и связываются, поможет вам избежать ошибок интеграции, фрагментации данных и правильно интерпретировать данные в разделе Профили.

Создание профиля

Adapty автоматически создаёт профиль при первом запуске приложения пользователем.

Без Customer User ID профиль анонимный. Новый анонимный профиль создаётся каждый раз, когда:

Пользователь переустанавливает приложение
Пользователь выходит из вашего приложения (когда приложение вызывает Adapty.logout())

Покупки привязываются к установке приложения, а не к постоянной идентификации пользователя.

С Customer User ID профиль сохраняется между переустановками и на разных устройствах. Customer User ID позволяет:

Отслеживать пользователя при переустановке приложения и на нескольких устройствах.
Находить пользователей по их customer user ID в разделе Profiles.
Использовать customer user ID в серверном API.
Adapty передаёт customer user ID во все интеграции.

Поведение профиля с customer user ID зависит от того, когда вы его устанавливаете:

При активации SDK: Adapty использует существующий профиль с этим customer user ID (для вернувшихся пользователей) или создаёт новый профиль (для новых пользователей).
После активации SDK: Adapty создаёт анонимный профиль при активации. Когда вы впоследствии идентифицируете пользователя, Adapty привязывает customer user ID к анонимному профилю (для новых пользователей) или переключается на существующий профиль с этим ID (для вернувшихся пользователей).

Какой подход выбрать:

Customer user ID доступен при запуске приложения (например, сохранён из предыдущей сессии) — передайте его в activate() при инициализации SDK.
Пользователи входят в систему после запуска приложения — вызовите identify() после аутентификации. Adapty привяжет ID к текущему профилю (если ID новый) или переключится на существующий профиль (если ID уже есть).
Пользователи могут совершать покупки до входа в систему — вызовите identify() после входа. Если customer user ID уже существует в Adapty, получите профиль после этого, чтобы синхронизировать текущий уровень доступа. Подробнее о реализации — в гайде SDK по идентификации пользователей.

Если вернувшийся пользователь ранее использовал приложение без customer user ID, анонимные профили не объединяются автоматически при идентификации во время активации SDK. Чтобы сохранить полную историю для таких пользователей, вызывайте identify() после входа в систему.

Родительские и дочерние профили

Когда одна и та же подписка в сторе привязана к нескольким профилям Adapty, Adapty выстраивает из них цепочку: один родительский профиль и один или несколько дочерних профилей, которые получают доступ от той же покупки.

Это происходит в следующих случаях:

Совместный доступ к платным возможностям между аккаунтами включён, и пользователь входит на устройстве, где покупка была совершена из другого профиля.
Пользователь переустанавливает приложение без customer_user_id, и новый профиль подхватывает покупку из предыдущей установки.
Разные идентифицированные пользователи восстанавливают покупки на одном устройстве.
Приложение переходит между Apple Team ID, и новое приложение подхватывает покупки, сделанные в рамках старого Team ID.

Как выбирается родительский профиль. Родительский профиль — это первый профиль, зафиксировавший покупку, который определяется порядком поступления чеков покупок в Adapty, а не порядком создания профилей. Например: вы установили приложение и ничего не купили, затем переустановили и оформили подписку. Второй профиль становится родительским, поскольку именно он совершил покупку. Первый профиль становится наследником и получает доступ через общий доступ.

Как распределяются события:

Транзакционные события (покупки, продления, отмены, проблемы с оплатой, льготные периоды, возвраты): отображаются только в родительском профиле, совершившем покупку. Все продления и обновления подписки продолжают отображаться в этом профиле.
События access_level_updated: отображаются в обоих профилях — родительском и профиле-наследнике — при каждом изменении состояния уровня доступа. Это позволяет всем связанным профилям быть в курсе актуального статуса доступа. В родительском профиле отображается полная история транзакций. Дочерние профили показывают только обновления уровня доступа и ссылку на родительский профиль в разделе Access level.

Отслеживание одной и той же подписки в нескольких профилях. У каждого унаследованного профиля есть свой profile_id, поэтому profile_id не является стабильным идентификатором в цепочке. Чтобы идентифицировать одну и ту же подписку в нескольких профилях — например, при сверке событий вебхука или сопоставлении профилей дашборда с одним базовым пользователем — используйте идентификатор на стороне стора.

Поле	Применение
`store_original_transaction_id`	Идентификация цепочки подписки в разных профилях. Уникально для каждой подписки Apple.
`profiles_sharing_access_level` (поле вебхука)	Все профили, которым в данный момент предоставлен уровень доступа по подписке, если включено совместное использование.
`profile_id`	Не подходит для отслеживания между профилями — у каждого наследника свой.

Основная статья: Общий доступ к платному контенту между аккаунтами пользователей

Чтобы задать политику общего доступа к уровням доступа, на странице настроек General выберите подходящий вариант. Для среды песочницы можно задать отдельную политику.

Включено (по умолчанию)

Идентифицированные пользователи (те, у кого задан Customer User ID) могут совместно использовать один уровень доступа, предоставленный Adapty, если их устройство привязано к одному и тому же Apple/Google ID. Это удобно, когда пользователь переустанавливает приложение и входит с другим email — он всё равно сохранит доступ к своей предыдущей покупке. При этом несколько идентифицированных пользователей могут иметь общий уровень доступа.

Несмотря на то что уровень доступа является общим, все прошлые и будущие транзакции записываются как события в исходный Customer User ID — для корректной аналитики и сохранения полной истории транзакций, включая пробные периоды, покупки подписок, продления и прочее, привязанные к одному профилю.

Передача доступа новому пользователю

Идентифицированные пользователи могут сохранять доступ к уровню доступа, предоставленному Adapty, даже если они входят с другим Customer User ID или переустанавливают приложение, при условии что устройство привязано к одному и тому же Apple/Google ID.

В отличие от предыдущего варианта, Adapty переносит покупку между идентифицированными пользователями. Это гарантирует доступ к купленному контенту, но только одному пользователю одновременно. Например, если UserA купил подписку, а UserB вошёл на том же устройстве и восстановил транзакции, UserB получит доступ к подписке, а у UserA он будет отозван.

Если один из пользователей (новый или старый) не идентифицирован, уровень доступа по-прежнему будет общим для этих профилей в Adapty.

Несмотря на то что уровень доступа передаётся, все прошлые и будущие транзакции записываются как события в исходный Customer User ID — для корректной аналитики и сохранения полной истории транзакций, включая пробные периоды, покупки подписок, продления и прочее, привязанные к одному профилю.

После переключения на Transfer access to new user уровни доступа не будут немедленно перенесены между профилями. Процесс переноса для каждого конкретного уровня доступа запускается только при получении Adapty события от стора: продление подписки, восстановление или при валидации транзакции.

Отключено

Первый идентифицированный профиль пользователя, получивший уровень доступа, сохраняет его навсегда. Это лучший вариант, если бизнес-логика вашего приложения требует привязки покупок к единственному Customer User ID.

Обратите внимание, что уровни доступа по-прежнему остаются общими для анонимных пользователей.

Вы можете «отвязать» покупку, удалив профиль владельца. После удаления уровень доступа становится доступен первому профилю пользователя, который его запросит, — анонимному или идентифицированному.

Отключение совместного доступа влияет только на новых пользователей. Подписки, уже общие между пользователями, продолжат оставаться таковыми даже после отключения этого параметра.

Apple и Google требуют, чтобы встроенные покупки были общими или передавались между пользователями, поскольку они опираются на Apple/Google ID для привязки покупки. Без совместного доступа восстановление покупок может не работать при последующих переустановках.

Отключение совместного доступа может помешать пользователям восстановить доступ после входа в аккаунт.

Рекомендуем отключать совместный доступ только в том случае, если пользователи обязаны войти в аккаунт до совершения покупки. В противном случае идентифицированный пользователь может купить подписку, войти в другой аккаунт и навсегда потерять доступ.

Какой вариант выбрать?

Моё приложение…	Рекомендуемый вариант
Не имеет системы входа и использует только анонимные идентификаторы профилей Adapty.	Используйте вариант по умолчанию, так как уровни доступа всегда являются общими для анонимных идентификаторов профилей во всех трёх вариантах.
Имеет необязательную систему входа и позволяет пользователям совершать покупки до создания аккаунта.	Выберите Transfer access to new user, чтобы пользователи, совершившие покупку без аккаунта, могли восстановить транзакции позднее.
Требует создания аккаунта перед покупкой, но допускает привязку покупок к нескольким Customer User ID.	Выберите Transfer access to new user, чтобы доступ был только у одного Customer User ID одновременно, при этом пользователи могут входить с другим Customer User ID, не теряя оплаченный доступ.
Требует создания аккаунта перед покупкой и строго привязывает покупки к единственному Customer User ID.	Выберите Disabled, чтобы транзакции никогда не передавались между аккаунтами.

Временны́е метки событий с датами в будущем (Apple/iOS)

Это поведение характерно только для Apple App Store. Система уведомлений Google Play не отправляет события заранее.

Временны́е метки событий в профилях и интеграциях могут показывать даты в будущем, потому что Apple отправляет события о продлении подписки заранее.

Почему это происходит: Apple делает это, чтобы подписки автоматически обновлялись до истечения срока, не прерывая сервис для пользователей. Подробнее — на форуме разработчиков Apple: Server Notifications for Subscriptions.
Затронутые типы событий: Как правило, это касается продлений подписок и конверсий из пробного периода в платный. У таких событий могут быть будущие временные метки, поскольку Apple уведомляет системы заранее.
Другие типы событий: Дополнительные встроенные покупки и изменения тарифного плана подписки записываются с фактическими временными метками, так как эти события невозможно предсказать заранее.
Влияние на Analytics и Event Feed: Такие события появятся в Analytics и Event Feed только после того, как наступит их временная метка. События с будущими временными метками не отображаются ни в одном из этих разделов.
Влияние на интеграции: Adapty отправляет события в интеграции сразу после их получения. Если у события будущая временная метка, Adapty передаёт его в вашу интеграцию с этой временной меткой без изменений.

Дальнейшие шаги

Чтобы использовать дашборд Profiles для поиска и управления пользователями, см. Profiles.
Чтобы настроить идентификацию пользователей в вашем приложении, см. гайд SDK по идентификации пользователей.
Чтобы настроить политику общего доступа, см. Общий доступ к платному контенту между аккаунтами пользователей.