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

• графиков Adapty с отчётами сторов
• графиков Adapty с графиками сторонних сервисов
• разных графиков внутри Adapty

Алгоритм устранения расхождений

Большинство расхождений между Adapty и другими платформами — ожидаемы и нормальны. Они возникают потому, что разные источники обрабатывают одни и те же данные по-разному.

В других случаях они указывают на проблему в конфигурации Adapty.

Если вы подозреваете, что данные различаются от платформы к платформе, лучший способ разобраться — экспортировать необработанные данные и сравнить файлы.

• Даже в сторах случаются проблемы с обработкой и отображением данных. Для наиболее точного сравнения используйте необработанные данные о транзакциях из сторов.
• При сравнении Adapty с другой аналитической платформой опирайтесь на отчёты о транзакциях из сторов как на источник истины.
• Расхождения проще выявлять на небольших объёмах данных. Сравнивайте ограниченные выборки — возьмите конкретный продукт и один день.
• Определите, в чём причина расхождения: в ценах или в количестве событий. Проблемы с ценами решаются через обновление продукта. Проблемы с событиями могут указывать на неполадки на стороне сервера.
• Следите за входящими событиями в ленте событий — там можно заметить неожиданное поведение.

После того как вы определите, где данные расходятся, изучите следующие распространённые причины:

Проблемы с серверными уведомлениями и RTDN

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

Настройте серверную интеграцию как можно скорее (App Store | Play Store) и подождите, пока сторы установят соединение.

Вы можете вручную загрузить недостающие данные из App Store Connect в Adapty.

Отсутствующие данные

Пользователи с устаревшими версиями приложения

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

Проблемы с интеграциями

Некоторые интеграции Adapty (например, Adjust или AppsFlyer) требуют дополнительного кода в приложении. Если вы настроили дашборд Adapty, но не обновили приложение, необходимые данные не появятся в Adapty.

Отсутствие исторических данных

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

Задержки данных

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

• При первой интеграции Adapty данные могут появиться не сразу.
• При подключении интеграции со сторонней платформой синхронизация данных может занять некоторое время.
• После того как Adapty получает данные из стора, их обработка и отображение на странице Analytics занимает ещё 15–30 минут.
• Обмен данными между Adapty и сторонними сервисами не всегда происходит мгновенно из-за множества переменных.
• Расчёт некоторых продвинутых метрик (например, прогнозов для когорт) требует достаточного объёма данных. Adapty выполняет эти расчёты только после накопления необходимого количества данных.

Метрики, которые меняются со временем

Когортные метрики группируют пользователей по действию — установке, просмотру пейвола, старту пробного периода или первому платежу — и продолжают отслеживать их поведение в дальнейшем. Так работают конверсии, когорты, удержание и LTV; в таблице сравнения метрик указано, какие метрики изменяются со временем, а какие нет. Пользователь, установивший приложение в марте и оформивший подписку в июле, увеличит мартовский показатель «Установка → оплата» именно в июле.

Сравнение двухлетнего месяца с прошлым месяцем — это сравнение устоявшегося числа с предварительным. Вместо этого читайте каждый период спустя одинаковое время с момента его начала.

Install to trial стабилизируется за несколько дней, тогда как Install to paid и Trial to paid продолжают расти месяцами. В разделе Compare months in your reports объясняется, сколько нужно ждать перед сравнением.

Время и календарь

Даты и часовые пояса

Одна из самых распространённых причин расхождений в данных — разные настройки часового пояса.

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

Вы можете изменить настройку часового пояса для каждого приложения.

Фискальный календарь Apple

Apple использует собственный финансовый календарь для определения периодов продаж и дат выплат.

Каждый «месяц» в этом календаре состоит из 4 или 5 недель и может включать дни из соседних календарных месяцев. Выплаты, как правило, производятся через 30–45 дней после окончания периода продаж.

Например, период продаж «январь 2026» начинается 28 декабря 2025 года — за 4 дня до начала календарного месяца. Ориентировочная дата выплаты за этот период — 5 марта.

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

Даты транзакций

Некоторые сервисы (например, AppsFlyer) могут применять правила когорт при отображении транзакций и относить их к дате установки приложения, а не к дате самой транзакции.

Расчёт выручки

Комиссии и налоги

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

Некоторые сторы и сторонние платформы могут не поддерживать отображение валовой выручки или автоматически вычитать налоги. Если вы видите расхождение между двумя графиками выручки, убедитесь, что сравнение корректно.

Отмены и возвраты

Разные платформы по-разному отображают данные о возвратах. Adapty учитывает возвраты как отрицательную выручку. Если пользователь оформил подписку, а на следующий день запросил возврат, оба события отразятся в графиках Adapty — каждое в свой день. Другие платформы могут вычитать сумму возврата из исходной транзакции.

Покупки в песочнице

Лента событий отображает покупки, сделанные sandbox-аккаунтами. Графики аналитики — нет. Однако если импортированные исторические данные содержат покупки из песочницы, Adapty не сможет их распознать, и графики будут отражать исторические покупки из песочницы.

Установки и загрузки

Сторы (особенно Apple App Store) могут отслеживать загрузки напрямую. Их статистика может включать случаи, когда приложение было установлено, но так и не запущено.

Adapty может зарегистрировать установку только тогда, когда пользователь запускает приложение, независимо от вашего определения установки.

Страна и стор

Для точной отчётности Adapty может определять страну пользователя по IP-адресу. Сторы всегда привязывают загрузки и покупки к конкретному магазину приложений.

Если вам нужно чётко разграничить эти два подхода, вы можете создать новый сегмент пользователей с атрибутом Country by store account и фильтровать аналитику по сегменту.

Ценообразование продукта

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

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

Конфликты атрибуции

Adapty может использовать только один источник атрибуции для каждой транзакции. Впоследствии эти данные нельзя переопределить.

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

Различия в терминологии

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

Adapty	App Store Connect	Google Play Console
Gross revenue	Sales	Gross Revenue
Proceeds after store commission	N/A	N/A
Proceeds after store commission and taxes	Proceeds	Earnings
ARPPU	Proceeds per paying user	ARPPU

Определения других метрик также могут различаться:

• Подписки:
  • Adapty не учитывает новые триалы как подписки. Новая подписка всегда начинается с финансовой транзакции.
  • Другие платформы, например Google Play Console, могут считать каждый триал новой подпиской — даже до совершения первого платежа.
• Удержание:
  • Adapty измеряет удержание на основе количества продлений подписки.
  • App Store Connect считает пользователя удержанным, если он открыл приложение в указанный день. Пользователь без подписки засчитывается, а подписчик, не открывший приложение в этот день, — нет.
  • Метрика «Retained Installers» в Google Play Console измеряет удержание по количеству дней, в течение которых приложение остаётся установленным на устройстве пользователя. Пользователи, не открывающие приложение, учитываются в этой метрике.

Несоответствие метрик и событий

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

Метрика «Новые подписки» и событие subscription_started

Метрика Новые подписки и событие subscription_started в интеграциях считают разные вещи. Ожидайте, что значение метрики «Новые подписки» будет превышать количество событий subscription_started.

Чем отличаются	Метрика New subscriptions	Событие subscription_started
Что отображает	Сколько подписок началось за период	Факт начала платной подписки в момент события
Для чего	Отслеживать, сколько новых плательщиков вы получили	Фиксировать покупку в аналитике, MMP или собственном бэкенде
Тайминг	Считает транзакции по дате покупки в вашем часовом поясе для отчётов	Отправляется в момент покупки
Конверсия из триала	Учитывается	Не отправляется — Adapty вместо этого отправляет trial_converted
Отозванные транзакции	Исключаются после отзыва Adapty	Уже отправлено и не отзывается
Профили, которые SDK не идентифицировал	Их покупки учитываются	Отсутствуют в Event Feed

Метрика «Активные подписки» и событие subscription_active

Метрика Активные подписки и событие subscription_active из интеграционных событий отличаются не только тем, что они считают, но и своим назначением.

Чем отличается	Метрика активных подписок	Событие subscription_active
Что отражает	Сколько подписок активны в конце каждого периода	Что подписка пережила первые дни
Для чего	Отслеживать размер и рост базы подписчиков	Передавать в MMP для ставок за пользователей, которые остаются
Время	Пересчитывается в конце каждого периода	Отправляется через заданное количество дней после начала подписки — от 1 до 90
Повторяется	Да, каждый период	Нет — Adapty проверяет один раз и больше не смотрит
Конверсия из пробного периода	Учитывается после того, как пробный период переходит в платный	Не отправляется — таймер запускается только при subscription_started, а конверсия отправляет trial_converted
Отменённые продления	Исключены	Отправляется, пока у пользователя есть доступ
Возвраты	Удаляются, в том числе ретроактивно из прошлых дат	Не отправляется, если возврат пришёл раньше; не отзывается, если пришёл позже
Доступность	Рассчитывается всегда	Отправляется только в тех интеграциях, где вы это включили

Метрика «Активные триалы» и событие trial_active

Метрика «Активные триалы» и интеграционное событие trial_active различаются не только тем, что именно они считают, но и своим назначением.

Что отличает	Метрика активных триалов	Событие trial_active
Что отслеживает	Сколько бесплатных триалов ещё не истекло	Что триал пережил первые дни
Для чего	Видеть, сколько триалов запущено	Оптимизировать ставки MMP для пользователей, остающихся на триале
Тайминг	Пересчитывается в конце каждого периода	Отправляется через заданное количество дней после начала триала — от 1 до 90
Повторяется	Да, каждый период	Нет — Adapty проверяет один раз и больше не возвращается
Конверсии триала	Учитываются до конверсии, затем исключаются в следующем периоде	Не отправляется для триала, который уже сконвертировался
Доступность	Всегда рассчитывается	Отправляется только интеграциями, где вы её включили

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

Отфильтрованная сумма превышает нефильтрованную

При применении фильтра Period добавление фильтра по продукту или группировка по продукту меняет смысл периода. Без продукта Activation считает первый платёж в цепочке подписок. С продуктом — первый платёж для каждого продукта в этой цепочке, поэтому пользователь, сменивший продукт, вносит вклад в Activation за каждый из них. Ни один из режимов не считает транзакцию дважды — они просто считают разные совокупности.

Какой из них использовать — зависит от вопроса: все продукты без группировки отвечает на вопрос «сколько новых плательщиков мы привлекли», представление с фильтрацией по продукту — «сколько пользователей впервые начали использовать этот продукт». Если убрать фильтр Period, оба значения совпадут с общим итогом без фильтров.

Конверсия просмотров пейвола упала

Если ваше приложение использует Flow Builder, показатели Paywall view -> Trial и Paywall view -> Paid стали ниже, чем раньше, причём это видно по всей истории.

Экран флоу, показанный пользователю, теперь засчитывается как просмотр пейвола. Просмотры экранов флоу раньше учитывались только в метриках флоу, поэтому обе ставки делили покупки на количество просмотров пейвола, которое не включало ни один экран флоу. Значения, которые вы видите теперь, — правильные; прежние были завышены.

Каждый пользователь учитывается один раз за дату — сколько бы экранов флоу он ни прошёл и независимо от того, видел ли он также пейвол, созданный в Paywall Builder.