---
title: "Устранение расхождений в данных"
description: "Найдите причину расхождений в данных"
---

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

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

## Алгоритм устранения неполадок \{#troubleshooting-algorithm\}

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

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

Если вы подозреваете, что данные отличаются от платформы к платформе, лучший способ разобраться — [экспортировать сырые данные](export-analytics-api-requests) и **сравнить файлы**.

* Даже у сторов могут возникать проблемы с обработкой и представлением данных. Для наиболее точного сравнения используйте **сырые данные о транзакциях** из сторов.
* При сравнении Adapty с другой аналитической платформой используйте отчёты о транзакциях из сторов как источник истины и точку сравнения.
* Проще выявлять расхождения на ограниченном наборе данных. Сравнивайте небольшие объёмы — сосредоточьтесь на конкретном продукте и одном дне.
* Определите, связано ли расхождение с **ценообразованием** или **количеством событий**. Проблемы с ценами можно исправить через [обновление продукта](#product-pricing). Проблемы с событиями могут указывать на [проблемы на стороне сервера](#issues-with-server-notifications-and-rtdn).
* Просматривайте [ленту событий](event-feed), чтобы отслеживать входящие события — возможно, вы заметите неожиданное поведение.

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

## Проблемы с серверными уведомлениями и RTDN \{#issues-with-server-notifications-and-rtdn\}

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

Настройте server-to-server соединение как можно скорее ([App Store](enable-app-store-server-notifications) | [Play Store](enable-real-time-developer-notifications-rtdn)) и [подождите](#data-delays), пока сторы установят соединение.

Вы можете [вручную загрузить](importing-historical-data-to-adapty) отсутствующие данные App Store Connect в Adapty.

## Отсутствующие данные \{#missing-data\}

### Пользователи с устаревшими версиями приложения \{#users-with-out-of-date-app-versions\}

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

### Проблемы с интеграциями \{#integration-issues\}

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

### Отсутствие исторических данных \{#missing-historical-data\}

Adapty не имеет доступа к историческим данным вашего приложения, если вы не [импортировали](importing-historical-data-to-adapty) их вручную. Если [временной диапазон](controls-filters-grouping-compare-proceeds#time-ranges) графика начинается раньше момента интеграции Adapty, а исторические данные не были импортированы, его значения будут отличаться от других источников.

## Задержки данных \{#data-delays\}

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

* При первой интеграции Adapty данные могут появиться не сразу.
* При включении интеграции со сторонней платформой может потребоваться некоторое время для полной синхронизации данных.
* После того как Adapty получает данные от стора, требуется ещё **15–30 минут** для их обработки и отображения на странице аналитики.
* Обмен данными между Adapty и сторонними сервисами **не всегда происходит мгновенно** из-за множества переменных.
* Вычисления некоторых продвинутых метрик (например, [прогнозов для когорт](predicted-ltv-and-revenue)) требуют определённого объёма данных. Adapty выполняет эти расчёты только после накопления достаточного количества данных.

## Время и календарь \{#time-and-calendar\}

#### Даты и временны́е зоны \{#dates-and-timezones\}

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

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

Вы можете [изменить настройку временно́й зоны](general#3-reporting-timezone) для каждого приложения.

#### Финансовый календарь Apple \{#the-apple-fiscal-calendar\}

Apple использует собственный [учётный календарь](https://adapty.io/apple-fiscal-calendar/) для определения периодов продаж и дат выплат.

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

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

Не сравнивайте данные из отчётов о выплатах Apple с календарными месяцами. Вместо этого выберите [произвольный диапазон дат](controls-filters-grouping-compare-proceeds#time-ranges), соответствующий нужному периоду продаж.

#### Даты транзакций \{#transaction-dates\}

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

## Расчёт выручки \{#revenue-calculation\}

### Комиссии и налоги \{#fees-and-taxes\}

В зависимости от [настройки](controls-filters-grouping-compare-proceeds#store-commission-and-taxes) графики Adapty могут отображать **валовую выручку**, **выручку после комиссии стора** или **выручку после комиссии стора и налогов**.

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

### Отмены и возвраты \{#cancellations-and-refunds\}

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

## Покупки в песочнице \{#sandbox-purchases\}

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

## Установки и загрузки \{#installs-and-downloads\}

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

Adapty может зарегистрировать установку только тогда, когда пользователь запускает приложение, независимо от вашего [определения установки](general#4-installs-definition-for-analytics).

## Страна и стор \{#country-and-store\}

Для точной отчётности Adapty [может определять](controls-filters-grouping-compare-proceeds#filtering-and-grouping) страну пользователя по IP-адресу. Сторы всегда привязывают загрузки и покупки к конкретному магазину приложений.

Если вам нужно чётко разграничить эти два подхода, вы можете [создать новый сегмент пользователей](segments) с атрибутом `Country by store account` и [фильтровать аналитику по сегменту](controls-filters-grouping-compare-proceeds#filtering-and-grouping).

## Ценообразование продукта \{#product-pricing\}

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

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

## Конфликты атрибуции \{#attribution-conflicts\}

Adapty может использовать [только один источник атрибуции](attribution-integration#prevent-data-issues) для каждой транзакции. Впоследствии эти данные нельзя переопределить.

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

## Различия в терминологии \{#differences-in-terminology\}

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

| 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 не учитывает новые триалы как подписки. [Новая подписка](reactivated-subscriptions) всегда начинается с финансовой транзакции.
        - Другие платформы, например Google Play Console, могут **считать каждый триал новой подпиской**, даже до первого платежа.
- **Удержание**:
        - Adapty измеряет удержание на основе количества продлений подписки.
        - App Store Connect считает пользователя удержанным, если он открыл приложение в указанный день. Пользователь без подписки засчитывается, а подписчик, не открывший приложение в этот день, — нет.
        - Метрика «Retained Installers» в Google Play Console измеряет удержание по количеству дней, в течение которых приложение остаётся установленным на устройстве пользователя. Пользователи, не открывавшие приложение, учитываются в этой метрике.