Двигун у нас є.
Час добудувати кокпіт.

Навіщо бізнесу: повертає виручку, яку ми вже втратили — найдешевший спосіб підняти LTV.

Метрика: 5–10% реактивації lapsed-користувачів; revenue recovered/міс із win-back оферів.

Керування promotional та win-back оферами Apple/Google з дашборду; оркестрація win-back через push / web / email для вже відписаних.

Три вектори (розділяємо):
① Retention у момент скасування — модалка при відписці в App Store. ✓ зроблено цього кварталу (Retention Messaging).
② In-app manage — зміна / скасування підписки в апці з контр-офером. Перетинається з Customer Center.
③ Win-back для повністю lapsed — промо-офер тим, хто вже зовсім скасував; за наявності логіна — email-кампанія.

Частина вже працює: вектор ① живий, версіонування цін є в Subscription Server, FCM-токени — в Attribution Server. Задача — додати керування оферами + вектори ②–③. Чому вгорі Next: найдешевша фіча, що повертає виручку напряму й спирається на готове.

Навіщо бізнесу: правильний пейвол правильному сегменту = вищий trial→paid без зміни продукту.

Метрика: 100% placements кероване з Cockpit (зараз ad-hoc через когорти Amplitude); вимірюваний lift trial→paid на сегментах.

Правил-based аудиторії (країна, платформа, lifecycle, кастомні атрибути) + іменовані placements у застосунку, керовані з Cockpit.

Як реалізувати: движок правил поверх атрибутів юзера (вони вже стікаються в Subscription / Attribution Server) + іменовані placements, що SDK резолвить у конкретний пейвол. Інтегрується з конструктором пейволів — вирішує, який пейвол бачить кожен сегмент.

Чому: формалізує те, що зараз ми робимо ad-hoc через когорти Amplitude, і вирішує, який пейвол бачить кожен юзер.

Навіщо бізнесу: систематичні A/B по всій воронці = постійний приріст конверсії, а не разові вгадування.

Метрика: ≥3–5 паралельних пейвол/онбординг-тестів на місяць без інженера; час ідея → live-тест <1 день.

A/B пейволів та онбордингу в Cockpit з per-variant метриками по всій воронці (перегляд → тріал → платний → renewal → LTV).

Примітив уже є: Retention Messaging ганяє зважені A/B-варіанти із симулятором на екранах скасування. Тут узагальнюємо це на пейволи й онбординг. Залежить від рішення по движку аналітики/експериментів (Amplitude vs PostHog / Statsig / GrowthBook).

Навіщо бізнесу: кращий онбординг тягне install→trial — верх воронки, що множиться на все нижче.

Метрика: install→trial (активація) +5–10%; онбординг редагується без релізу в сторі.

No-code конструктор онбординг-потоків, з'єднаний з пейволами; відповіді наповнюють атрибути для таргетингу.

Як реалізувати: перевикористовує той самий рендер-движок, що й AI-конструктор пейволів (тому йде після нього). Додаємо логіку кроків / розгалужень і запис відповідей в атрибути юзера, що живлять сегменти.

Чому: онбординг тягне install-to-trial; перевикористовує той самий движок рендеру, що й AI-конструктор пейволів.

Навіщо бізнесу: вчасні повідомлення на trial-end / billing-issue = менше churn без зовнішнього CRM.

Метрика: −10–20% churn на trial-end та billing-issue; recovered trials щомісяця через lifecycle-меседжинг.

Вбудовані push + in-app повідомлення за подіями підписки (тріал закінчується, churn, billing issue) без окремого CRM-стеку.

Фундамент уже частково є: у Cockpit працює движок Retention Messaging (matchers, пріоритети, зважені A/B-варіанти, симулятор, prod/sandbox) для екранів скасування Apple. Ми вже емітимо події (вебхуки) і тримаємо FCM-токени в Attribution Server. Задача — узагальнити цей движок на всі lifecycle-тригери та канали, тож це менше, ніж greenfield.

Навіщо бізнесу: метрики під рукою в Cockpit = швидші рішення без черги до аналітиків і Tableau.

Метрика: базові дашборди доступні просто в Cockpit (без походів у Tableau); час «потрібна метрика → графік» — менше кліків.

Базова аналітика прямо в Cockpit: список метрик у нашому UI, з вибором апки, без переходу в зовнішній інструмент.

Два варіанти: ① найпростіший — iframe Tableau всередині Cockpit; ② цікавіший — лишити Tableau як аналітичний движок, а візуалізацію будувати свою (свої чарти з Databricks у стилі Cockpit), бо UX Tableau слабкий (довгі завантаження, повний ре-рендер). Зараз Tableau — лише рендер-база, агрегації вже на Databricks.

Чому в Next: лід просить базову аналітику прямо в Cockpit; залежить від рішення по движку (Tableau / Amplitude / PostHog).