Собственный продукт · Квиз-воронка с подпиской
Квиз-воронка на пять языков, от первого клика до подписки
Потребительский продукт, который я запустил с партнёрами: платный трафик заходит в квиз из девятнадцати экранов и выходит оплаченной подпиской. Всё, что между ними, спроектировано и написано мной под конверсию: движок квиза, пейволл, оплата, генерация отчёта, три слоя аналитики и пять языковых версий. Бренд и выручка остаются у партнёров, инженерия показана целиком.
- Квиз-воронка
- Подписка
- Серверные события
- 5 языков
- PostgreSQL
Вход
Полная посадочная для органики, короткий пре-лендер для рекламы.
Сессия с первого клика
Каждый ответ сразу на сервере, вместе с кампанией и устройством.
Квиз, 19 экранов
От лёгких вопросов в один тап к дате рождения и личным данным.
Частичное раскрытие
Настоящая сводка, размытое изображение, четыре тизера. Платный текст остаётся на сервере.
Пейволл, три тарифа
Символический вход на неделю, выделенный средний тариф, без таймера.
Триальная неделя
Четыре порции ценности за семь дней. Причина не отменять подписку.
- Роль
- Сооснователь. Продукт, архитектура и вся разработка. Команду под проект, включая трафик, собирал я.
- Период
- Запущен в 2024, работает до сих пор
- Продукт
- Персональный отчёт из текста и изображения, который продаётся через квиз и оплачивается подпиской.
- Платформа
- Собственный веб-стек: предсобранные страницы, PostgreSQL, платёжный провайдер и пиксели за подменяемыми интерфейсами.
- Языки
- Английский, испанский, немецкий, румынский, польский. У каждого языка свой адрес.
- Состояние
- В продакшене целиком: воронка, оплата, генерация отчёта, порционная выдача, аналитика и локализация. Принимает платный трафик на пяти рынках.
- Что не раскрываю
- Бренд, нишу и выручку: они принадлежат партнёрам. Архитектуру и решения показываю полностью. Экраны, цифры и живую воронку показываю на созвоне.
Почему воронка устроена именно так
Изображение продаёт вход, текстовый отчёт даёт ценность, подписка с недельным входом собирает деньги.
Эту связку я не придумывал за столом. Перед разработкой я разобрал двух работающих конкурентов поэкранно и посмотрел около десятка продуктов через библиотеку рекламы Meta. Картина сложилась быстро. Изображение даёт дешёвый клик, потому что создаёт конкретный визуальный вопрос, на который хочется получить ответ.
Продавать одно изображение разовым платежом невыгодно: один платёж без повторов и самая капризная для эквайринга категория. Голая подписка тоже не держится, потому что вторую неделю нечем оправдать. Рабочая середина оказалась такой: изображение открывает дверь, платит человек за подписку, а ценность первой недели выдаётся порциями. Эти порции делают работу, которую обычно делает мобильное приложение.
Три роли в одной связке
- Крючок
- Изображение: дешёвый клик и конкретное обещание
- Продукт
- Персональный текстовый отчёт из трёх разделов
- Касса
- Подписка с символической первой неделей и порционной выдачей
Путь пользователя
Каждый экран стоит на своём месте не случайно. Ниже то, что видит человек от клика по объявлению до момента, когда достаёт карту.
Две точки входа
Органика и модерация площадок заходят на полную посадочную. Реклама ведёт на короткий пре-лендер: первый экран, доказательство, кнопка. Так делает сильнейший из разобранных конкурентов, и это правильно: рекламному трафику не нужен длинный лендинг, ему нужен первый вопрос.
Сессия рождается на первом клике
Не на шаге с почтой и не в конце. Идентификатор живёт в адресе и в куке, каждый ответ уходит на сервер в момент выбора. Брошенная воронка не теряется: я вижу, что человек ответил на семь вопросов и ушёл на восьмом, с какой кампании пришёл и с какого устройства. У конкурентов состояние квиза лежит только в браузере, и таких данных у них не существует.
Девятнадцать экранов, двенадцать вопросов
В счётчик прогресса попадают только вопросы. Порядок выстроен как лестница: два нейтральных вопроса крупными карточками в один тап, экран доверия, предпочтения, дата рождения как точка вложения, боль, проекция будущего. Личные данные я прошу только после четырёх лёгких «да».
Пауза перед оффером
Между последним ответом и результатом стоит загрузка с тремя полосами прогресса, и каждая подписана реальным этапом расчёта. Это не украшение: пауза создаёт ожидание, в которое затем попадает результат.
Момент результата
Вместо глухой заглушки человек видит настоящий заголовок с его данными, настоящую сводку, размытое изображение и четыре карточки-тизера. Платный текст на клиент не отдаётся вообще, а набросок под размытием намеренно недорисован. Снять CSS-фильтр в инструментах разработчика можно, увидеть при этом нечего. У обоих конкурентов платный текст достаётся из DOM за десять секунд.
Итог этой части: воронка знает о каждом человеке больше, чем он о ней, а платный контент не существует нигде, кроме сервера.
Пейволл и триальная неделя
Три тарифа, выделен средний. Каждый элемент здесь работает на конверсию, а риск чарджбэков закрыт инструментами на стороне платёжного провайдера.
Тарифы
Вход
Символическая цена за семь дней
Перечёркнутая полная цена
Неделя
ВыделенСредняя цена, основной выбор
Перечёркнутая полная цена
Месяц
Лучшая цена за единицу
Перечёркнутая полная цена
Якорь, средний тариф и гарантия
Перечёркнутая полная цена задаёт якорь, средний тариф выделен и становится выбором по умолчанию, гарантия возврата снимает последнее возражение. Условие автопродления стоит над кнопкой коротко и рядом с гарантией: так его требуют площадки и провайдер, и в такой подаче оно не тормозит покупку.
Срочность настоящая, а не таймер
Фальшивого обратного отсчёта нет. Срочность здесь настоящая и оплачиваемая: очередь на генерацию и ускорение за доплату. Это конвертит лучше таймера и не вызывает вопросов у модерации.
Апселл в пике желания
Отчёт готовится двадцать минут. За небольшую доплату очередь сокращается до трёх. Себестоимость нулевая, а покупают охотно: человек только что заплатил, желание на пике, и он хочет результат сейчас.
Неделя порциями
В первый день приходит изображение, во второй, третий и пятый остальные разделы отчёта, каждый письмом и отдельной страницей. Это и есть замена приложению: у человека есть причина не отменять подписку на третий день.
Что здесь работает на конверсию
Инженерия в этом кейсе обслуживает продажу. Ниже приёмы, которые двигают человека от объявления к оплате и дальше ко второй неделе, и почему каждый из них стоит на своём месте.
- 01
Первый вопрос вместо лендинга
Рекламный трафик попадает на пре-лендер и через один экран уже отвечает. Чем короче путь от клика до первого действия, тем дешевле каждый следующий шаг.
- 02
Два лёгких «да» в начале
Первые вопросы нейтральные, крупными карточками, в один тап. Человек включается в диалог до того, как от него что-то потребовали.
- 03
Дата рождения как точка вложения
К этому шагу человек уже ответил на несколько вопросов и вложился. После точки вложения квиз бросают заметно реже, поэтому боль и личные данные идут только после неё.
- 04
Пауза, которая продаёт результат
Загрузка с подписанными этапами расчёта превращает ожидание в ценность: человек видит, что для него что-то считают, и результат воспринимается дороже.
- 05
Разрыв любопытства
Частичное раскрытие с настоящим заголовком, настоящей сводкой и размытым изображением. Ответ уже почти виден, и это сильнее любого обещания на лендинге.
- 06
Символическая цена входа
Решение о первом платеже маленькое, поэтому его принимают быстро. Дальше работают подписка и порционная выдача.
- 07
Якорь, средний тариф, гарантия
Три тарифа с выделенным средним и перечёркнутой полной ценой направляют выбор, гарантия снимает последнее сомнение.
- 08
Настоящая срочность
Не таймер, а очередь на генерацию с платным ускорением. Срочность, за которую человек готов доплатить, конвертит и приносит деньги одновременно.
- 09
Вторая неделя как отдельная продажа
Порционная выдача даёт причину не отменять подписку. Удержание здесь и есть конверсия второго платежа.
- 10
Аналитика по шагам как инструмент продаж
Когда видно, на каком из девятнадцати экранов течёт воронка, чинится именно он: креатив, вопрос или оффер. Восстановленные брошенные сессии показывают, где именно.
Оплата и эквайринг
Платёжный слой спрятан за интерфейсом, провайдера можно заменить без правок в воронке. И главное: клиент никогда не решает, сколько он платит.
Цена считается на сервере
Сумма и состав заказа всегда вычисляются на сервере из идентификатора оффера. Из браузера приходит только этот идентификатор. Любая цена, пришедшая от клиента, игнорируется по определению.
Поток оплаты
Инвойс создаётся у провайдера, дальше редирект или встроенная форма. Результат возвращается вебхуком с проверкой подписи, статус я дополнительно сверяю отдельным запросом, а повторную доставку вебхука обрабатываю идемпотентно. Полные данные карты через наш периметр не проходят.
Эквайринг под высокорисковую категорию
Категория высокорисковая, поэтому эквайринг был согласован параллельно с разработкой, и в запасе есть второй провайдер. На стороне провайдера включены системы снижения чарджбэков, а платёжный контур готов целиком: оплата, автопродление, возвраты по гарантии и отмена подписки в один клик.
Генерация отчёта
Задача ставится в очередь в момент оплаты, а не по нажатию кнопки. Из одного набора ответов запускаются три параллельные задачи.
Текст
Языковая модель получает не сырые ответы, а структурированный профиль: производные поля из даты рождения, названные качества, тип связи, названную трудность. На выходе три фиксированных раздела, всегда одной формы.
Изображение
Графическая модель получает описание внешности, собранное из ответов и производных полей. Результат проходит постобработку под единый визуальный стиль, чтобы два отчёта не выглядели как два разных продукта.
Сборка
Текст и изображение складываются в письмо и в персональную страницу, и та же сборка кормит порционную выдачу на неделе.
Потолок времени задан явно. Если генерация не уложилась, человек получает то, что готово, а недостающая часть досылается. Форма ответа зафиксирована, поэтому модель можно заменить без единой правки в интерфейсе.
Три слоя аналитики
Рекламные площадки, блокировщики и Safari теряют события. Я исхожу из этого и не опираюсь ни на один слой в отдельности: у каждого своя роль, и они не зависят друг от друга.
Первичный, свой
Каждое событие ложится в собственную базу с идентификатором сессии, шагом, индексом шага, временем и полной атрибуцией: все пять utm-меток, реферер, вариант лендинга, вариант квиза, язык, тип устройства. Этот слой не зависит ни от блокировщиков, ни от площадок, и именно по нему считается юнит-экономика.
Браузерные пиксели
Провайдеры стоят за общим интерфейсом, идентификаторы живут в переменных окружения, в коде не зашит ни один. Провайдер без идентификатора не загружается и в сеть не ходит.
Серверные события
Meta Conversions API и TikTok Events API. Событие уходит с сервера в момент, когда факт записан в базу, а не когда сработал браузер.
Площадки
- Meta PixelОсновная закупка
- TikTok PixelВторой канал
- Google Ads / GA4Ремаркетинг и сквозная аналитика
- PostHogПродуктовая аналитика, воронка по шагам, записи сессий
Дедупликация обязательна: браузерное и серверное событие несут один event_id, и площадка склеивает их в одно. Без этого конверсии считаются дважды, а кампании обучаются на завышенных числах.
Серверный слой закрывает дыру блокировщиков и iOS, но главное в другом: он передаёт события, которых в браузере не бывает вовсе. Подтверждённая оплата приходит вебхуком от провайдера, а не со страницы, и площадка узнаёт о ней ровно тогда, когда о ней узнаю я.
Событие на каждом из девятнадцати экранов даёт воронку по шагам, а не одну цифру конверсии. Проседает первый переход: проблема в крючке и креативе. Второй: вопросы стали личными слишком рано. Предпоследний: проблема в оффере, а не в квизе. Эти случаи важно различать, потому что без такой аналитики чаще всего чинят не то.
Карта событий
| Шаг воронки | Своё событие | Стандартное событие Meta |
|---|---|---|
| Показ лендинга | landing_view | PageView |
| Старт квиза | quiz_started | ViewContent |
| Каждый шаг | step_view | кастомное |
| Ответ | quiz_answered | кастомное |
| Возврат назад | step_back | кастомное |
| Завершение квиза | quiz_completed | кастомное |
| Почта | email_submitted | Lead |
| Показ пейволла | buybox_view | ViewContent |
| Начало оплаты | checkout_started | InitiateCheckout |
| Оплата | payment_success | Purchase |
| Подписка | subscription_created | Subscribe |
Движок квиза
В коде нет ни одной строки контента. Движок переиспользуемый, оффер это конфигурация, и второй продукт на том же движке не требует переписывать схему.
Контент живёт в JSON
Тексты, вопросы, варианты, изображения, ветвления и юридические документы. Правка формулировки не требует ни сборки, ни деплоя.
Экраны через реестр
Тип шага выбирает компонент через реестр. Новый тип экрана это один компонент и одна строка в реестре.
Ответы с пространствами имён
Общие поля и поля конкретного оффера разделены заранее. Второй оффер добавляется рядом, а не поверх.
Дерево ответов собирает сервер
Оно пересобирается из таблицы ответов, а не принимается снимком от клиента. Испорченный или подделанный снимок из браузера не может повредить состояние.
Персонализация без кода
Три декларативных механизма. Зеркала подставляют прошлый ответ в текст. Ветвление меняет содержимое экрана, не меняя индекс шага, поэтому прямые ссылки не ломаются, а аналитика не расходится. Наборы вариантов подставляют разные списки ответов в зависимости от прошлого выбора.
Пять языков как система
Английский, испанский, немецкий, румынский и польский: двадцать пять предсобранных страниц. Локализация здесь не файл перевода, а часть архитектуры.
Один язык, один адрес
Язык всегда в URL. На этапе рендера ничего не угадывается.
Определение по приоритету
Явный выбор в куке, затем Accept-Language, затем гео, затем английский. Заголовок браузера стоит выше геолокации сознательно: IP говорит, где находится устройство, а не на каком языке человек читает.
Платный трафик минует определение
Испанская кампания ведёт на /es, немецкая на /de. Точность стопроцентная, задержки нет, а модерация видит язык, совпадающий с языком объявления.
Явный адрес не перенаправляется никогда
Все редиректы временные: постоянный кешируется браузером и запирает человека в одном языке навсегда.
Переведено всё, а не только видимое
Ветки зеркал, тексты согласия, подписи полей, alt изображений, мета-описания. Названия месяцев берутся из системной локали, числа приведены к локальным форматам, а падежи славянских языков решены отдельными формами для разных позиций в предложении.
Юридический слой и хранилище
Согласие как факт в базе
На первом шаге квиза стоит обязательная галочка: пока она не отмечена, варианты ответа не реагируют. Факт согласия пишется в базу с идентификатором сессии, временем и атрибуцией. В споре с эквайером это прямой ответ на вопрос, кто, когда и откуда соглашался.
Условия и политика из конфигурации
Оба документа рендерятся из конфигурации, реквизиты подставляются из одного места. Политика честно описывает автоматическую генерацию текста и изображения, отсутствие уникальности результата, срок хранения, права субъекта данных, кнопку отмены и автопродление. Конкуренты это игнорируют. В Европе это уже не мелочь.
Один интерфейс к базе
Ни один обработчик маршрута не пишет SQL, всё общение с базой идёт через один интерфейс. Реализации подменяемы: локальная и продакшен-PostgreSQL выбираются строкой подключения. Схема создаётся при первом запросе, миграции запускать не нужно.
Разведка перед стройкой
Прежде чем писать код, я разобрал двух работающих конкурентов экран за экраном и проанализировал около десятка продуктов через библиотеку рекламы Meta: активные креативы, даты запуска, гео, домены назначения.
Разведка дала больше, чем структуру воронки. Два бренда оказались одним оператором: побайтово совпадающие условия, одно юрлицо, один стек. Третий рекламируется под названиями страниц, не совпадающими с брендом, и по имени бренда в библиотеке не находится вовсе. А их технические слабости стали моим списком того, что делать нельзя.
Что я сознательно не повторил
- Состояние квиза только в браузере
- Вопросы зашиты в бандл
- Платный текст в DOM под размытием
- Пиксели без согласия
- Ожидание без объяснения
Что я измеряю
Аналитика построена вокруг семи переходов. Каждый из них отвечает на свой вопрос, и именно поэтому проблему в воронке видно за минуты, а не за неделю.
| Переход | О чём говорит |
|---|---|
| Лендинг → первый ответ | Крючок и креатив |
| Первый ответ → дата рождения | Не слишком ли рано вопросы стали личными |
| Дата рождения → конец квиза | Лестница эскалации |
| Конец квиза → почта | Доверие в момент запроса данных |
| Почта → пейволл | Сила частичного раскрытия |
| Пейволл → начало оплаты | Оффер: главная метрика продукта |
| Оплата → отмена в первые 7 дней | Доставка ценности на неделе |
Цифры по этим переходам, как и выручка, остаются у партнёров. На звонке разберу воронку по шагам.
Что этот кейс показывает
Платформа другая, чем в работах на Shopify. Мышление то же, и здесь оно проходит весь путь: от разведки и оффера до кассы и удержания.
Квиз-воронка целиком в одних руках
От пре-лендера и порядка вопросов до частичного раскрытия и пейволла.
Коммерческая модель, а не только вёрстка
Тарифы, триальная неделя, апселл и причины за каждым решением спроектированы мной, а не получены в брифе.
Трекинг без слепых зон
Первичные события, браузерные пиксели и серверные события с дедупликацией, по шагам, до оплаты включительно.
Пять рынков из одной кодовой базы
Адреса, определение языка, маршрутизация рекламы и грамматика решены системно.
Команда, собранная под задачу
Трафик и сопутствующие роли я нанимал и вёл сам. Разработка целиком моя.
На Shopify та же воронка собирается из квиз-секции или приложения, Selling Plans для подписки, Web Pixel для событий чекаута и того же серверного слоя за ними. Платформа меняет детали. Мышление не меняется.
Стек
Фронтенд
- Pre-rendered pages, one URL per language
- Config-driven quiz engine
- Component registry per screen type
Данные
- PostgreSQL
- Single storage interface
- Server-side session and answer tree
Платежи
- Provider behind an interface
- Signed webhooks
- Idempotent order handling
Аналитика
- First-party event store
- Meta Pixel + Conversions API
- TikTok Pixel + Events API
- GA4 and Google Ads
- PostHog
Генерация
- Language model for the report
- Image model for the visual
- Queue with a time ceiling
Владение
Продуктовые решения принимались вместе с партнёрами. Архитектура, дизайн воронки, движок, аналитика, локализация и весь код мои, как и разведка перед стартом.
Предыдущий кейс
Boxwood Coffee
Адаптация Prestige для обжарщика спешиалти-кофе: понимать, что не нужно переделывать.
Передайте витрину и считайте вопрос закрытым.
Пришлите задачу и цель. Дальше разберусь в коде, доведу работу до релиза и проверю сам.
Начать разговор