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

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

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

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

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

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

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

1. Отслеживать пользователя при переустановке приложения и на нескольких устройствах.
2. Находить пользователей по их customer user ID в разделе Profiles.
3. Использовать customer user ID в серверном API.
4. 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 по идентификации пользователей.

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

Когда одна и та же подписка в сторе привязана к нескольким профилям 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	Не подходит для отслеживания между профилями — у каждого наследника свой.

Транзакции без профилей

Некоторые транзакции в Adapty не привязаны ни к одному профилю — они отображаются в аналитике и экспортах, но не попадают в список профилей. Это происходит, когда серверные (S2S) уведомления стора приходят от пользователей, чьи аккаунты никогда не подключались к вашему приложению через SDK Adapty. Известные источники:

• S2S-уведомления App Store (включая события возврата средств)
• S2S-уведомления Google Play
• Вебхук-события Stripe и Paddle

Эти транзакции:

• Отображаются в аналитических графиках (учитываются в общих метриках)
• Отображаются в экспортах (S3, GCS, BigQuery) с profile_id, равным null
• Не отображаются в списке профилей — привязать их не к чему

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

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

Чтобы задать политику общего доступа к уровням доступа, на странице настроек 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.

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

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

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

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

Моё приложение…	Вариант
Не имеет системы входа и использует только анонимные идентификаторы профилей 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 по идентификации пользователей.
• Чтобы настроить политику общего доступа, см. Общий доступ к платному контенту между аккаунтами пользователей.