Zeno

Контекст работы

О проекте

Zeno — приложение для контроля экранного времени, которое помогает пользователям сокращать импульсивное использование отвлекающих приложений и осознаннее управлять временем на телефоне.

Проблема

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

Задача

Определить основные точки потерь и их причины, а затем перестроить onboarding & paywall воронку так, чтобы сильнее раскрывать ценность продукта, повышать готовность пользователя продолжать путь и улучшить конверсию в подписку.

Анализ продукта

Исходные показатели

Сначала я зафиксировал baseline одной входящей когорты, чтобы понять исходную эффективность воронки и дальше оценивать изменения относительно единой точки отсчёта.

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

Аудит текущей воронки

Я разобрал существующий onboarding от первого экрана до пейволла по шести направлениям CRO-фреймворка: структуре воронки, коммуникации ценности, персонализации, моменту показа пейволла, цене и предложению, UX и дизайну пейволла. Такой разбор позволил оценить не отдельные экраны, а логику всего пути и точки, где пользовательский контекст, ценность продукта и монетизация переставали работать как единая система.

Воронка начиналась с функций продукта до формирования личного контекста, собранные данные почти не использовались дальше, а перед монетизацией накапливались rating request, permission-шаги и дополнительные настройки. В итоге ценность Zeno раскрывалась слабее, чем росло трение по мере движения к пейволлу.

Анализ воронки

После аудита я сопоставил найденные проблемы с поведением пользователей в PostHog. Пошаговая воронка показала, где именно накапливались основные потери: заметный отток начинался ещё в середине onboarding и усиливался ближе к permission-этапам и монетизации.

Данные помогли отделить визуальные и UX-наблюдения от действительно значимых точек потерь. В приоритет попали участки, где высокий drop-off совпадал с уже найденными проблемами в структуре сценария, коммуникации ценности и последовательности действий перед пейволлом.

Анализ рынка

Анализ конкурентов

После анализа собственной воронки я изучил ключевые приложения в категории Screen Time Control, чтобы понять, как рынок решает те же задачи: формирует пользовательский контекст, объясняет ценность ограничения экранного времени, запрашивает системные разрешения и подводит к подписке.

Я сравнивал повторяющиеся продуктовые паттерны в структуре onboarding, персонализации, permission-flow, trial и paywall. Это помогло отделить особенности конкретных продуктов от подходов, которые системно используются в категории, и определить решения, релевантные проблемам Zeno.

Анализ отзывов

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

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

Гипотеза

Анализ показал, что основные потери формировались не в одной точке, а на нескольких связанных этапах: в начале не хватало личной релевантности, собранные данные почти не использовались, а перед подпиской накапливалось трение. Поэтому локальной оптимизации отдельных экранов было недостаточно — требовалось перестроить логику пути целиком.

Архитектура новой воронки

Я перестроил onboarding вокруг пяти последовательных задач: сначала сформировать личный контекст, затем показать реальное поведение, усилить мотивацию, укрепить доверие и только после этого перейти к монетизации.

1. 01

   Контекст пользователя

   • Приветствие
   • Цель
   • Сложности
   • Оценка экранного времени
2. 02

   Анализ поведения

   • Доступ к Screen Time
   • Фактическое экранное время
3. 03

   Мотивация

   • Долгосрочные последствия
   • Возвращённое время
   • Механика Zeno
4. 04

   Доверие

   • Социальное подтверждение
   • Персонализация Zeno
5. 05

   Монетизация

   • Условия пробного периода
   • Напоминание
   • Пейволл

Редизайн

Контекст пользователя

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

Анализ текущего поведения

Я встроил Screen Time permission в понятный обмен ценностью: пользователь сначала понимает, зачем нужен доступ, а сразу после него получает фактические данные о своём использовании телефона. Это снижает ощущение технического барьера и переводит сценарий от субъективной оценки к реальной.

Формирование мотивации

Фактический Screen Time я перевёл в последствия, которые проще почувствовать: сколько времени пользователь может потерять на длинной дистанции и сколько потенциально можно вернуть. Сразу после этого показал core-механику Zeno, чтобы связать проблему не с абстрактным обещанием, а с конкретным способом её решения.

Доверие к решению

После объяснения механики я добавил два уровня подтверждения: social proof снижает сомнения в эффективности продукта, а персонализация связывает решение с уже собранными целями, Screen Time и поведением пользователя. Так Zeno воспринимается не как универсальный сценарий, а как решение, адаптированное под конкретного человека.

Монетизация

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

Эксперимент

Для проверки гипотезы я сравнил существующую воронку с полностью переработанным вариантом. Новый onboarding тестировался как единый Test Variant, поэтому результат отражает совокупный эффект всей логики воронки, а не влияние отдельных экранов.

Основной метрикой выбрал D30 ARPU — после появления 3-дневного trial более ранние окна хуже отражают итоговую монетизацию. Дополнительно отслеживал Completion Rate, Install → Paid, а внутри новой модели — Install → Trial и Trial → Paid.

Результаты

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

Рост Completion Rate подтвердил, что новая структура лучше удерживает пользователей до монетизации, а увеличение Install → Paid и D30 ARPU показало, что эффект сохранился и на уровне бизнес-метрик.