Кратко для занятых: Команда приложения Moonly (топ-3 по астрологии в США, 10 млн установок) провела 85 A/B-тестов пейволлов за год через Adapty с нулевым числом релизов приложения, управляя выручкой более $1 млн. Главные драйверы роста: замена месячного тарифа на недельный по той же цене ($9), внедрение задержки крестика (fake hard paywall), увеличение онбординга с 8 до 26 экранов и автоматизация подведения итогов тестов с помощью AI-агента, объединяющего данные Adapty, PostHog и Stripe.

Блок саммари

🎯 О чём этот конспект: Практическое руководство по построению системы непрерывного A/B-тестирования пейволлов и онбордингов в мобильном приложении без привлечения мобильных разработчиков и прохождения ревью в App Store / Google Play. В материале разбираются реальные механики ценообразования, психологические якоря, сегментация по странам на основе внутренней конверсии (а не ВВП), внедрение веб-платежей на iOS в обход комиссии Apple и связка аналитики с AI-агентами.

👤 Кому будет полезно:

• Фаундерам и инди-хакерам (vibe coders), разрабатывающим мобильные сервисы и мобильные SaaS.
• Growth-инженерам, маркетологам и продакт-менеджерам мобильных продуктов.
• Аналитикам, выстраивающим пайплайн монетизации и проверки продуктовых гипотез.

✨ Что получите: Готовый фреймворк запуска 80+ экспериментов в год без релизов, алгоритм внедрения высококонверсионных механик монетизации (от hard paywall таймеров до кастомных онбордингов под креативы) и промпт для AI-агента, оценивающего статистическую значимость теста по базам данных.

1. Инфраструктура Zero-Release: запуск 80+ тестов пейволлов в год через Adapty

Контекст: Классический подход к изменению цен и экранов оплаты требует ручной вёрстки разработчиками, сборки билда, прохождения модерации App Store/Google Play и ожидания, пока пользователи обновят приложение. Стоимость одного такого теста на часах мобильной разработки составляет сотни долларов, а цикл проверки гипотезы растягивается на недели. Серверное управление пейволлами через специализированные платформы (Adapty) исключает мобильную разработку из контура: новые экраны, ценовые сетки и условия создаются в конструкторе и доставляются пользователям динамически. По данным индустриальных отчётов, приложения с регулярным пайплайном тестирования растут в среднем на 74% по показателю MRR. В Moonly при 85 тестах в год win rate составляет 30–40% (против среднерыночных 10–20%) именно благодаря системному накоплению базы знаний по каждому проверенному элементу.

Тайминг: [00:11], [00:33], [01:46]

Выгода:

• 0 релизов приложения для запуска тестов.
• Экономия десятков тысяч долларов на часах разработки.
• Рост темпа тестирования гипотез в 4–5 раз.

Как применить:

• Шаг 1: Интеграция SDK Adapty — Adapty SDK] — Установите SDK в проект (pod 'Adapty' для iOS или Flutter/React Native плагин). Настройте плейсменты (например, onboarding_paywall, internal_paywall), чтобы интерфейс загружал конфигурацию с бэкенда платформы.
• Шаг 2: Создание пейволлов через визуальный конструктор — Adapty Paywall Builder] — Соберите базовые шаблоны пейволлов, разделив слои: фон, заголовок, фичи, плашки тарифов, кнопки действий, дисклеймеры. Все текстовые поля и цены привяжите к динамическим переменным.
• Шаг 3: Настройка сплит-теста — Adapty Dashboard] — В интерфейсе Adapty добавьте аудиторию (например, New Users, US, Tier 1) и разделите трафик 50/50 между контрольным и экспериментальным экранами. Запустите тест без выпуска новой версии приложения в магазины.

Результат: Полная независимость маркетинговой и продуктовой команды от релизных циклов: запуск эксперимента занимает минуты вместо дней.

2. Архитектурный сдвиг тарифов: замена месяца на неделю при сохранении чека

Контекст: Большинство приложений выстраивают стандартную сетку: неделя/месяц/год. При этом месячный тариф часто снижает общий LTV, так как пользователи покупают его на 1–2 месяца для пробы, а годовой тариф кажется слишком дорогим обязательством. Moonly провели контринтуитивный эксперимент: заменили месячную подписку за $9 на недельную подписку за те же самые $9. Поведение пользователей показало, что они сравнивают тарифы не с абсолютной ценностью времени, а внутри предложенной витрины (неделя vs год vs пожизненный доступ). Конверсия в покупку осталась прежней, но LTV недельного тарифа вырос до уровня годовой подписки за счёт регулярных еженедельных списаний.

Тайминг: [02:12], [02:46]

Выгода:

• Увеличение LTV самого дешёвого тарифа до уровня годовой подписки.
• Получение эффекта «13-й зарплаты» в год: в году 52 недели, что даёт больше платёжных циклов по сравнению с календарными 12 месяцами.
• От 10% до 50% прироста суммарной выручки продукта.

Как применить:

• Шаг 1: Подготовка недельного SKU — App Store Connect / Google Play Console] — Заведите новый ин-апп продукт с еженедельным биллингом и установите цену, равную вашему старому месячному тарифу (например, $8.99 или $9.99).
• Шаг 2: Настройка якорной сетки тарифов — Adapty Products] — Разместите недельный тариф рядом с годовым. На годовой тариф добавьте пересчёт цены в неделю со скидкой (например, «$39.99/год — всего $0.77/неделя»), визуально выделяя годовой план как экономию 80%.
• Шаг 3: Тестирование восприятия — Adapty A/B Test] — Разделите когорту: Вариант A ($9/месяц + $40/год) против Варианта B ($9/неделя + $40/год). Отслеживайте не только моментальную конверсию, но и отток (churn) через 4–6 недель.

Результат: Уравнивание LTV короткого тарифа с длинным при стабильной конверсии на витрине.

3. Механика «Fake Hard Paywall»: задержка кнопки закрытия (Close Delay)

Контекст: Классический Hard Paywall (экран без возможности закрытия до оплаты) максимизирует выручку с онбординга, но вызывает всплеск негатива и отток пользователей, пришедших за бесплатной частью функционала. Soft Paywall (крестик доступен сразу) позволяет пользователям проскакивать экран оплаты, снижая импульсивные покупки. Компромиссное решение — динамическая задержка появления кнопки закрытия экрана (Close Button Delay) на несколько секунд. В тестах Moonly увеличение задержки крестика снизило доходимость пользователей внутрь приложения на 20–30%, однако общая выручка не упала, а выросла. Отсеялись пользователи, которые никогда бы ничего не купили внутри, в то время как сомневающаяся платежеспособная аудитория приняла решение об оплате.

Тайминг: [02:51], [03:43], [06:33]

Выгода:

• Рост общей выручки с онбординг-пейволла без каннибализации покупок внутри приложения.
• 60–80% суммарного дохода продукта извлекается до перехода пользователя на главный экран.

Как применить:

• Шаг 1: Конфигурация задержки в UI — Swift / React Native / Flutter] — Скройте крестик (opacity: 0 или display: none) при первичном рендере пейволла. Запустите таймер, получающий значение миллисекунд из конфига.
• Шаг 2: Настройка таймера показа — Реализуйте плавное появление кнопки закрытия через анимацию по истечении задержки (оптимально: от 3 до 5 секунд).

// Пример логики задержки кнопки закрытия на React Native
import React, { useState, useEffect } from 'react';
import { View, TouchableOpacity, Text, Animated } from 'react-native';
 
export const TimedPaywallCloseButton = ({ delayMs = 3000, onClose }: { delayMs: number; onClose: () => void }) => {
  const [visible, setVisible] = useState(false);
  const fadeAnim = new Animated.Value(0);
 
  useEffect(() => {
    const timer = setTimeout(() => {
      setVisible(true);
      Animated.timing(fadeAnim, {
        toValue: 1,
        duration: 400,
        useNativeDriver: true,
      }).start();
    }, delayMs);
 
    return () => clearTimeout(timer);
  }, [delayMs]);
 
  if (!visible) return null;
 
  return (
    <Animated.View style={{ opacity: fadeAnim, position: 'absolute', top: 48, right: 16 }}>
      <TouchableOpacity onPress={onClose} hitSlop={{ top: 12, bottom: 12, left: 12, right: 12 }}>
        <Text style={{ color: '#8E8E93', fontSize: 16 }}>✕</Text>
      </TouchableOpacity>
    </Animated.View>
  );
};

• Шаг 3: Сегментация по регионам — Ограничьте задержку крестика только для стран с высоким чеком (Tier 1: США, Канада, Великобритания). В развивающихся странах или Восточной Европе увеличение задержки приводит к дропу выручки — там крестик должен быть доступен быстрее.

Результат: Максимизация покупок на этапе онбординга среди пользователей с высокой готовностью платить.

4. Онбординг-воронка: переход от 8 к 26 слайдам с квизами и персонализацией

Контекст: Среди продуктовых команд укоренился миф о том, что каждый лишний экран онбординга неизбежно снижает доходимость до пейволла. Исторически Moonly использовали короткий флоу из 8 слайдов с перечислением фичей (медитации, таро, календарь). При переходе на длинный квиз-онбординг из 26 слайдов доходимость не упала, а конверсия в подписку существенно выросла. Причина в эффекте самовыражения и инвестиции внимания: когда пользователь отвечает на вопросы о своих проблемах (поиск партнера, стресс, самопознание), следующий экран транслирует те же функции продукта, но строго под его Jobs-to-be-Done (JTBD). Дополнительно работает сквозная персонализация: рекламный креатив (например, Таро) связывается с кастомными скриншотами в сторе, специальным онбордингом и пейволлом под данную тематику.

Тайминг: [05:40], [06:24], [08:44]

Выгода:

• Рост конверсии пейволла за счёт точного попадания в потребность пользователя.
• Возможность закупать трафик по более широким когортам за счёт кастомных сквозных воронок.
• Мужская аудитория увеличена с 20% до 35% благодаря переключению визуального ряда при выборе мужского пола в квизе.

Как применить:

• Шаг 1: Разделение фиче-ориентированного флоу на JTBD-вопросы — Замените слайды «У нас есть календарь» на квиз: «Какая сфера жизни требует баланса прямо сейчас? (Отношения / Финансы / Ментальное здоровье)».
• Шаг 2: Реализация динамических экранов ценности — На шаге 24–25 онбординга сгенерируйте персональный план: выведите имя пользователя, дату его рождения и собранные из квиза цели с анимацией «Анализируем данные...».
• Шаг 3: Персонализация оффера на пейволле — Заголовок и иконку главного экрана пейволла меняйте в зависимости от выбранного пола и главной боли.

// Концепт передачи параметров квиза в конфигурацию пейволла Adapty
const quizAnswers = {
  gender: 'male',
  primaryGoal: 'stress_relief',
  leadSource: 'tiktok_tarot_campaign'
};
 
// Сегментация для Adapty
await adapty.updateProfile({
  gender: quizAnswers.gender,
  customAttributes: {
    userGoal: quizAnswers.primaryGoal,
    campaignSource: quizAnswers.leadSource
  }
});
 
// На бэкенде Adapty пейволл автоматически отдает заголовок под stress_relief

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

5. Внешние платежи через Stripe на iOS для рынка США

Контекст: После судебного разбирательства Epic Games против Apple разработчики в США получили право встраивать альтернативные методы оплаты в приложениях для iOS без уплаты 30% комиссии Apple на внешние транзакции. Главная проблема ин-апп подписок на iOS: около 70% пользователей отменяют автопродление в первые несколько минут после покупки через стандартные настройки Apple ID. Moonly протестировали предложение скидки при переходе на внешнюю оплату картой через Stripe: годовой тариф в приложении стоит $40, а по ссылке на Stripe — $30–35. Пользователь мотивирован скидкой ввести данные карты. При этом ломается автоматический паттерн моментальной отмены подписки в настройках iPhone (так как подписка оформлена вне экосистемы Apple), что привело к росту LTV в 1.5 раза.

Тайминг: [07:11], [07:31], [08:11]

Выгода:

• Рост LTV пользователей на 50% за счёт снижения моментальных отмен.
• 0% комиссии Apple с альтернативных платежей на рынке США.
• Прямой контакт с платёжными данными пользователя через Stripe.

Как применить:

• Шаг 1: Валидация правил Apple для StoreKit External Link — Ознакомьтесь с StoreKit External Purchase Link Entitlement для рынка США. Подайте заявку в Apple Developer Program на получение разрешения на внешний платёж.
• Шаг 2: Внедрение альтернативной кнопки в пейволл — Разместите два варианта покупки: основная нативная кнопка («Купить за $39.99/год») и текстовая ссылка под ней («Специальная цена $29.99 при оплате банковской картой»).
• Шаг 3: Обработка вебхуков Stripe в Adapty — Adapty Stripe Integration] — Подключите Stripe к Adapty, передавая customer_id и user_id приложения. Adapty автоматически объединит профиль веб-пользователя с ин-апп сессией и откроет доступ к премиум-функциям.

[Архитектура склейки оплат]
iOS App (User ID: 10482) 
   │
   ├─► Клик на Stripe Web Pay ──► Открытие Safari с сессией Checkout
   │                                  │
   │                                  ▼
   │                             Stripe Process Payment
   │                                  │
   │                                  ▼
   │                             Webhook в Adapty API
   │                                  │
   └◄─ Polling / WebSocket ───────────┘
       (Премиум активирован мгновенно в приложении)

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

6. Что не работает: дробление пейволлов под конкретные фичи мульти-приложений

Контекст: Moonly содержит множество модулей: астрологические карты, расклады Таро, фазы Луны, аудиопрактики. Логичной гипотезой казался запуск контекстных пейволлов: если у пользователя закончились лимиты в Таро — показывать пейволл с картами Таро; если он перешел в медитации — показывать экран про медитации. Эксперимент показал отрицательные результаты. Пользователи начали считать, что в приложении нет общей подписки, а каждая функция продается отдельно (особенно на фоне наличия в продукте разовых отчетов — One-Time Mastery Reports). В результате пользователи запутывались и отказывались от покупки.

Тайминг: [09:15], [09:44], [09:82]

Выгода:

• Предотвращение падения конверсии из-за размытия ценности подписки.
• Экономия ресурсов команды на отрисовку десятков узкоспециализированных экранов.

Как применить:

• Шаг 1: Фокус на All-in-One ценности — При возникновении пейволла внутри приложения в любой точке контакта транслируйте концепцию «Единого ключа ко всем практикам», а не изолированной фичи.
• Шаг 2: Использование контекстного акцента вместо изоляции — Если пейволл вызван из раздела Таро, визуальный акцент (верхняя иконка или первый пункт) можно отдать Таро, но в списке фичей обязательно указывать: «+ Полный доступ к натальным картам, календарю и медитациям».
• Шаг 3: Чёткое разграничение подписок и аддонов — Никогда не смешивайте покупку подписки и покупку разовых отчетов (One-Time Purchases) на одном экране без явного визуального разделения.

Результат: Сохранение прозрачности монетизации и устранение когнитивного барьера «мне навязывают микроплатежи за каждый шаг».

7. Сегментация стран по внутренней конверсии, а не по ВВП

Контекст: Традиционное деление рынков на Tier 1, Tier 2, Tier 3 по уровню ВВП на душу населения часто приводит к потере выручки. В ряде стран с невысоким номинальным ВВП (Филиппины, Индонезия, Бали) приложение на английском языке скачивают экспаты, фаундеры и удаленные специалисты из Европы и США, готовые платить стандартные чеки западных рынков. Напротив, в Бразилии при среднем общем уровне жизни существует платежеспособный средний класс с высокой культурой цифровых покупок, сопоставимый с рынками Бенилюкса. Moonly выработали подход: страны сортируются по тирам исключительно на основе фактической конверсии внутри приложения. Если конверсия ниже бенчмарка — цены снижаются для захвата объема; если выше — поднимаются.

Тайминг: [11:56], [12:38], [12:54]

Выгода:

• Рост выигрышных тестов (win rate) за счёт точечной калибровки покупательской способности.
• Увеличение выручки на развивающихся рынках до 20% при снижении цены (эластичность спроса).
• Извлечение максимального чека на рынках с высокой экспат-концентрацией.

Как применить:

• Шаг 1: Расчёт фактической конверсии по Geo — Выгрузите из базы аналитики когорты за последние 90 дней и посчитайте CR = (Первые покупки / Установки) по каждой стране.
• Шаг 2: Кластеризация на основе отклонения от целевого бенчмарка — Создайте три группы:
  • Group High-CR: Конверсия выше целевой на 15%+ — повысить цены на 10–25%.
  • Group Normal: Конверсия в пределах нормы — тестировать форматы и заголовки.
  • Group Low-CR: Конверсия ниже целевой — протестировать снижение цен на 20–40% или замену годового тарифа на дешевый недельный план.
• Шаг 3: Настройка гео-таргетинга в Adapty — Создайте аудитории по кодам стран и привяжите к ним индивидуальные каталоги ин-апп продуктов.

Результат: Устранение искажений макроэкономической статистики и монетизация реального сегмента аудитории в каждом регионе.

8. Автоматизация анализа A/B-тестов через связку PostHog, Adapty и AI-агентов

Контекст: При запуске до 100 тестов в год ручная оценка результатов превращается в узкое горлышко: аналитику нужно выгрузить события из системы продуктовой аналитики (PostHog), сопоставить с платежами в Adapty и Stripe, рассчитать статистическую значимость, проверить retention когорт и исключить влияние внутренних покупок аддонов. Moonly автоматизировали этот процесс: в чат с AI-агентом отправляется название теста или скриншот. Агент по API забирает данные контрольной и тестовой групп из PostHog, склеивает транзакции по внутреннему user_id, считает p-value, проверяет достаточность выборки и выдает аргументированный вердикт (Rollout / Collect More Data / Drop).

Тайминг: [13:07], [13:46], [14:42]

Выгода:

• Снижение времени анализа теста с нескольких часов до 1 минуты.
• Исключение человеческого фактора (когда автор гипотезы пытается преждевременно признать её успешной).
• Автоматический учет пост-покупочного поведения (LTV, допродажи отчетов, отток).

Как применить:

• Шаг 1: Настройка связки данных — Передавайте единый distinct_id пользователя во все сервисы: adapty.identify(userId), posthog.identify(userId), метаданные в Stripe (metadata: { app_user_id: userId }).
• Шаг 2: Реализация скрипта / инструмента для AI-агента — Настройте агентную функцию (например, в Claude / OpenAI Assistants / n8n), которая принимает имя сплит-теста, делает запрос к PostHog SQL / Adapty API и агрегирует метрики.
• Шаг 3: Использование системного промпта для оценки статзначимости — Загрузите строгий промпт для вынесения продуктового вердикта.

Ты — ведущий мобильный дата-сайентист и специалист по монетизации приложений.
Твоя задача — объективно оценить результаты A/B-теста монетизации и вынести вердикт.
 
Главная метрика (North Star): ARPU / ARPPU (Выручка на пользователя / платящего).
Вторичные метрики: Конверсия в триал/покупку, Retention Day 7/30, LTV прогноз.
 
Входные данные:
- Название теста: {test_name}
- Вариант A (Control): Пользователей: {n_A}, Покупок: {conversions_A}, Выручка: ${rev_A}
- Вариант B (Variant): Пользователей: {n_B}, Покупок: {conversions_B}, Выручка: ${rev_B}
 
Правила:
1. Вычисли двухвыборочный z-критерий для разницы пропорций (конверсий) и t-критерий / bootstrap для выручки на пользователя.
2. Проверь минимальный порог: не менее 100 покупок на каждый вариант и не менее 7 дней длительности теста (для сглаживания сезонности).
3. Доверительный интервал: 95% (p-value < 0.05).
4. Оцени, не был ли рост сиюминутной выручки вызван падением ретеншна или отказами от аддонов.
 
Формат ответа:
1. Краткое резюме (Выборка, Дельта ARPU, Дельта CR).
2. Статистическая значимость (p-value, доверительный интервал).
3. Риски (отток, сезонные аномалии).
4. Финальный вердикт СТРОГО один из трех: [ROLLOUT TO 100%] / [KEEP RUNNING - NEED MORE DATA] / [DISCARD].

Результат: Беспристрастный пайплайн принятия решений на основе сухих цифр с минимальными трудозатратами аналитиков.

9. Гигиена A/B-тестирования: чек-лист правил для исключения шума

Контекст: При тестировании микроэлементов (тексты, плашки скидок, замена фона), которые приносят от 3% до 5% прироста, критически важно отличать статистический шум от реального эффекта. Без соблюдения строгой методологии команды часто «находят» ложные корреляции из-за неравномерного распределения трафика, сезонности дней недели или попыток подглядывать в результаты в первые 48 часов после запуска.

Тайминг: [16:10], [16:48], [17:31]

Выгода:

• Защита от деградации монетизации из-за раскатки ложноположительных тестов.
• Предсказуемая сходимость экспериментов.

Как применить:

• Правило 1: Регулярные A/A-тесты — Периодически запускайте тесты с двумя абсолютно одинаковыми контрольными вариантами. Если между ними возникает «значимая» разница — инфраструктура распределения трафика работает некорректно.
• Правило 2: Запрет на подглядывание (No Peeking) — Никогда не останавливайте тест в первые 3–4 дня. Минимальное окно теста — 7 полных суток для выравнивания паттернов поведения аудитории в будни и выходные.
• Правило 3: Порог в 100 конверсий — Эксперимент не может считаться завершенным, пока в каждом из вариантов не наберется как минимум 100 целевых действий (оплат), вне зависимости от общего количества показов экрана.
• Правило 4: Ориентация на ARPU, а не на CR — Принимайте решения по выручке на пользователя (ARPU). Снижение конверсии на 10% при росте среднего чека на 40% дает чистый плюс в деньгах.

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

FAQ

В: Почему замена месячной подписки на недельную по той же цене ($9) не обрушила конверсию? О: Пользователь на экране покупки сравнивает доступные опции между собой, а не проводит аудит стоимости единицы времени. Недельный тариф за $9 на фоне годового за $40 или $50 воспринимается как дешевая возможность попробовать функционал прямо сейчас, что сохраняет импульсивную покупку.

В: С какого момента стоит начинать тесты с задержкой кнопки закрытия (Close Delay)? О: Эксперименты с задержкой кнопки крестика стоит внедрять, когда у вас уже стабильно закупается трафик на рынках Tier 1 (США, Канада). Начните с задержки в 2–3 секунды и обязательно замеряйте как конверсию онбординга, так и конверсию внутренних покупок, чтобы убедиться в отсутствии каннибализации дохода.

В: Не наказывает ли Apple за предложение оплаты через Stripe? О: Начиная с выполнения судебного решения по иску Epic Games, для разработчиков под рынок США действует специальный механизм StoreKit External Purchase Link. Apple разрешает размещать ссылки на внешние платежи со скидками, однако требует использования специального entitlement и корректной технической реализации перехода.

В: Почему 26 экранов онбординга работают лучше 8 экранов? О: Длинный онбординг меняет парадигму взаимодействия: вместо пассивного просмотра каталога функций пользователь отвечает на вопросы о себе. Это создает эффект привязанности (IKEA effect) и позволяет сформировать персонализированную ценность продукта к моменту показа пейволла.

В: Что делать, если трафика мало и 100 покупок на вариант набираются слишком долго? О: В условиях дефицита трафика тестируйте только «тяжелые» рычаги (изменение цены в 1.5–2 раза, хард vs софт пейволл, замена триала на прямую подписку), где эффект превышает 20–30%. Тесты мелких формулировок и цветов кнопок (дающие 3–5%) на малом объеме трафика проводить не имеет смысла, так как они утонут в шуме.

Ресурсы и ссылки

• Adapty — Платформа управления мобильными подписками, пейволлами и A/B-тестами без релизов приложения — https://adapty.io
• PostHog — Платформа продуктовой аналитики с открытым исходным кодом для трекинга событий и когорт — https://posthog.com
• Stripe — Платёжный шлюз для обработки внешних транзакций по банковским картам — https://stripe.com
• Moonly — Мобильное приложение по астрологии и осознанности, упомянутое как кейс-стади — https://moonly.app

Конспект создан на основе видео «Как вырастить выручку пейвола на 50% с помощью сплит-тестов» канала Adapty. Все права на оригинальный материал принадлежат авторам. Источник: https://www.youtube.com/watch?v=f1ecU8upSHo