---
title: "Как работают профили"
description: "Узнайте, как Adapty создаёт, отслеживает и связывает профили пользователей — включая анонимные профили, идентифицированных пользователей и отношения родитель/наследник."
---

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

## Создание профиля \{#profile-creation\}

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

**Без Customer User ID** профиль остаётся анонимным. Новый анонимный профиль создаётся каждый раз, когда:
- Пользователь переустанавливает приложение
- Пользователь выходит из вашего приложения (когда приложение вызывает `Adapty.logout()`)

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

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

1. Отслеживать пользователя при переустановках приложения и на нескольких устройствах.
2. Находить пользователей по их Customer User ID в разделе [**Profiles**](profiles-crm).
3. Использовать Customer User ID в [серверном API](getting-started-with-server-side-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 по [идентификации пользователей](identifying-users).

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

## Родительские профили и профили-наследники \{#parent-and-inheritor-profiles\}

Когда несколько профилей связаны с одной подпиской (через один и тот же Apple/Google ID), Adapty отслеживает их с помощью отношения родитель-наследник. Это происходит, когда пользователь переустанавливает приложение без идентификации или когда разные идентифицированные пользователи восстанавливают покупки на одном устройстве.

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

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

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

Родительский профиль содержит полную историю транзакций. Профили-наследники отображают только обновления уровня доступа и ссылку на родительский профиль в разделе **Access level**.

  <img src="/assets/shared/img/98d0dad-non-original_profile.webp"
  style={{
    border: '1px solid #727272',
    width: '700px',
    display: 'block',
    margin: '0 auto'
  }}
/>

## Общий доступ к платному контенту между аккаунтами пользователей \{#sharing-paid-access-between-user-accounts\}

:::link
Основная статья: [Общий доступ к платному контенту между аккаунтами пользователей](sharing-paid-access-between-user-accounts)
:::

Чтобы задать политику общего доступа к уровням доступа, на странице настроек [**General**](general) выберите подходящий вариант. Для [среды песочницы](test-purchases-in-sandbox) можно задать отдельную политику.

---
no_index: true
---

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

Идентифицированные пользователи (те, у кого задан [Customer User ID](identifying-users#set-customer-user-id-on-configuration)) могут совместно использовать один [уровень доступа](access-level), предоставленный Adapty, если их устройство привязано к одному и тому же Apple/Google ID. Это удобно, когда пользователь переустанавливает приложение и входит с другим email — он всё равно сохранит доступ к своей предыдущей покупке. При этом несколько идентифицированных пользователей могут иметь общий уровень доступа.

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

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

Идентифицированные пользователи могут сохранять доступ к [уровню доступа](access-level), предоставленному Adapty, даже если они входят с другим [Customer User ID](identifying-users#set-customer-user-id-on-configuration) или переустанавливают приложение, при условии что устройство привязано к одному и тому же Apple/Google ID.

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

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

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

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

**Отключено**

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

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

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

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

:::warning

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

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

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

### Какой вариант выбрать? \{#which-setting-should-i-choose\}

| Моё приложение...                                                    | Рекомендуемый вариант                                             |
| ------------------------------------------------------------ | ------------------------------------------------------------ |
| Не имеет системы входа и использует только анонимные идентификаторы профилей 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) \{#event-timestamps-with-future-dates-appleios\}

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

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

- **Причина**: Apple делает это, чтобы подписки продлевались автоматически до истечения срока действия, предотвращая перебои в обслуживании пользователей. Подробнее см. на форуме разработчиков Apple: [Server Notifications for Subscriptions](https://developer.apple.com/forums/tags/app-store-server-notifications).
- **Затронутые типы событий**: как правило, это продления подписок и конвертации из пробного периода в платный. Эти события могут иметь будущие временны́е метки, поскольку Apple уведомляет системы о них заблаговременно.
- **Другие типы событий**: дополнительные встроенные покупки и изменения тарифного плана подписки записываются с фактическими временны́ми метками, поскольку такие события нельзя предсказать заранее.
- **Влияние на аналитику и ленту событий**: эти события появятся в разделах **Analytics** и **Event Feed** только после того, как их временны́е метки наступят. События с будущими временны́ми метками не отображаются ни в одном из этих разделов.
- **Влияние на интеграции**: Adapty отправляет события в интеграции сразу после их получения. Если событие имеет будущую временну́ю метку, Adapty передаёт его в вашу интеграцию с этой будущей временно́й меткой без изменений.

## Дальнейшие шаги \{#next-steps\}

- Чтобы использовать дашборд Profiles для поиска и управления пользователями, см. [Profiles](profiles-crm).
- Чтобы настроить идентификацию пользователей в вашем приложении, см. гайд SDK по [идентификации пользователей](identifying-users).
- Чтобы настроить политику общего доступа, см. [Общий доступ к платному контенту между аккаунтами пользователей](sharing-paid-access-between-user-accounts).