Устаревший механизм не отображается как тип продукта на странице настроек дохода, поэтому определить, используется ли устаревший механизм, только по интерфейсу невозможно. Используйте следующие методы вместе:

• Сначала просканируйте сырые данные. Найдите события af_purchase с event_source: SDK и is_receipt_validated: true. Это возможные кандидаты, но вызовы logEvent могут создавать похожие события, поэтому само по себе это не является окончательным подтверждением.
• Подтвердите это в коде SDK. Если ваше приложение вызывает validateAndLogInAppPurchase с устаревшей сигнатурой, значит, оно использует устаревший механизм. Устаревшая сигнатура включает:
  • Android: лицензионный ключ, данные в формате JSON, цена, валюта
  • iOS: идентификатор продукта, цена, валюта, идентификатор транзакции
• Свяжитесь со своим CSM. Он может подтвердить, какие из ваших приложений все еще работают на устаревшей версии.

Устаревший серверный сервис валидации чеков прекращает работу. Начиная с этого дня:

• При любом вызове устаревшего метода validateAndLogInAppPurchase ответ о результатах проверки не возвращается независимо от версии SDK.
• События af_purchase, прошедшие валидацию и зарегистрированные этим методом, больше не фиксируются в AppsFlyer.
• Дэшборды, сырые данные и партнерские постбэки больше не получают данные о покупках из устаревшего метода.

Чтобы продолжить сбор валидированных покупок, перейдите на один из поддерживаемых альтернативных вариантов до 7 сентября 2026 года.

Нет. Оба продукта работают параллельно до 7 сентября 2026 года. Включение новой валидации чека в AppsFlyer не влияет на версии приложения, которые по-прежнему обращаются к устаревшему методу. Они продолжат работать как раньше до даты прекращения поддержки.

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

Да Оба продукта используют один и тот же метод SDK validateAndLogInAppPurchase (v2), поэтому переход с валидации чека на ROI360 Store Revenue не требует изменения SDK или релиза приложения. Чтобы перейти, измените Тип продукта на странице Настойки выручки и выполните дополнительную настройку ROI360 (уведомления сервера App Store для iOS, RTDN Google Play для Android). См. Переход с валидации чека на ROI360 Store Revenue.

Если вам нужны дополнительные возможности — автоматическое обнаружение покупок, отслеживание всего жизненного цикла подписки (включая продления, переходы на другой тариф и существующих подписчиков), а также обработка изменений стоимости подписки, — интегрируйте компонент SDK Коннектор покупок. Для этого потребуется обновить приложение, но это необязательно. Ручная проверка с помощью validateAndLogInAppPurchase (v2) работает в ROI360 Store Revenue и без этого компонента.

Да. Вы можете отправлять события покупок в приложении с помощью стандартного API logEvent. Но тогда вы не получите:

• Валидацию чека в магазинах приложений, которая отфильтровывает мошеннические покупки
• Метка af_validated в событиях: имеет значение true, когда AppsFlyer успешно проверяет покупку в магазине, и false, когда проверка не проходит. Без валидации эта метка отсутствует.
• Точные постбэки о выручке вашим партнерам по UA. Без валидации любой переданный вами af_revenue записывается и отправляется в сети как есть — без подтверждения того, что покупка действительно произошла

По этим причинам AppsFlyer рекомендует использовать валидацию чека или ROI360 Store Revenue, а не полностью пропускать валидацию.

Это зависит от того, какой продукт вы используете:

• Валидация чека: обратный вызов SDK возвращает код ошибки. Ваше приложение должно обработать сбой и внедрить собственную логику повторных попыток.
• ROI360 Store Revenue: AppsFlyer автоматически повторяет валидацию, как только сервис магазина восстанавливается, и заново генерирует все пропущенные события за период сбоя.

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

Если вам нужна чистая выручка, используйте ROI360 Store Revenue. Он фиксирует и валовой, и чистый доход (валовой за вычетом комиссий магазина и налогов).

Если вы по-прежнему передаете значение af_revenue, оно сохраняется в событии внутри объекта custom_data. Дэшборды и партнерские постбэки используют валовое значение из ответа магазина, а не ваше пользовательское значение.

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

Устаревший метод создавал одно событие af_purchase для всех типов транзакций. В новой валидации чека используются разные названия событий:

• Разовая покупка: af_purchase
• Начало пробного периода: af_ars_trial_started
• Начало подписки: af_ars_subscription_started
• Покупка в песочнице: af_purchase_sandbox_sdk
• Подписка или пробный период в песочнице: af_ars_sandbox_sdk

Полный набор событий жизненного цикла подписки (продления, отмены, возвраты средств, переход на новую версию) доступен только в ROI360 Store Revenue. Полный список событий см. в статье О валидации чека.

Новая валидация чека по-прежнему возвращает результат валидации в callback SDK, и вы можете использовать его для управления доступом к купленному контенту. В результате проверка становится точнее, поскольку используются новейшие механизмы валидации Apple App Store и Google Play, поэтому данным, получаемым через обратный вызов, можно доверять в большей степени.

Для нового метода validateAndLogInAppPurchase обязателен параметр Тип покупки. Укажите значение разовая или подписка в зависимости от типа транзакции.

В вашем приложении интегрирован новый метод validateAndLogInAppPurchase (v2), но продукт не настроен в дэшборде AppsFlyer. Откройте Настройки> ROI360 > Настройки дохода > Покупки& подписки, выберите валидация чека или ROI360 и выполните шаги настройки.

af_purchase регистрируется только для транзакций в продуктивной среде. Транзакции в песочнице регистрируются как af_purchase_sandbox_sdk. Чтобы создать реальное событие af_purchase, проведите тестирование в рабочей среде (не через TestFlight на iOS и не с помощью лицензированного тестировщика на Android).