Stripo Кейс

Stripo — конструктор email-листів, яким користуються понад 1 700 000 людей: від соло-маркетологів до маркетингових команд Adobe, Microsoft, Amazon, Airbnb і Spotify. За даними компанії, Stripo використовують 65% компаній зі списку Fortune 100. Drag-n-drop редактор дозволяє зібрати адаптивний лист без коду й вивантажити його у понад 90 поштових сервісів. Незалежні оцінки продукту – 4,8 на G2 і 4,9 на Capterra. (Усі показники в цьому розділі наведено станом на липень 2026.)

За цими цифрами – конкретна аналітична складність. Клієнти Stripo приходять надто різними шляхами: органічний пошук, платна реклама, партнерські інтеграції, прямі заходи. А канал, який приводить користувача на сайт вперше, і канал, який зрештою приводить того, хто потім платитиме місяцями, – часто не той самий. Поки ці шляхи не зведені в одну картину, питання "куди спрямувати маркетинговий бюджет" не має надійної відповіді. Саме з нього почалася наша співпраця.

Стандартна вебаналітика зазвичай зупиняється на реєстрації. Для freemium-продукту цього замало: реєстрація нічого не коштує, а цінність створюють ті організації, що переходять на платні тарифи й залишаються місяцями. Питання Stripo було не "який канал дає більше реєстрацій", а "який канал дає клієнтів, які платять і залишаються з нами надовго".

Відповісти на нього заважали дві речі.

Перша – розрив у даних. Поведінка на сайті жила в Google Analytics, а платежі, підписки й дохід – у внутрішній базі продукту. Поки ці два світи не з'єднані, неможливо простежити шлях від першого візиту до доходу, який він зрештою приніс.

Друга – модель атрибуції. Звичний "останній клік" віддає всю заслугу каналу, що закрив реєстрацію, і знецінює ті, що привели та "прогріли" користувача раніше. На такій картині легко переінвестувати в канал, який лише збирає врожай, і недофінансувати той, що його насправді вирощує.

Потрібна була наскрізна система, яка з'єднує трафік, реєстрації, підписки й дохід – і чесно показує внесок кожного каналу, а не лише останнього.

Ми побудували наскрізну систему з чотирьох шарів. Спершу – надійний збір даних через серверний GTM. Далі звели поведінку на сайті й дохід із продуктової бази в одне сховище BigQuery та розрахували атрибуцію одразу за чотирма моделями: перший і останній непрямий дотик та дві data-driven моделі. Над цими даними – звіт у Power BI, де видно шлях від візиту до першої оплати. А зверху – AI-асистент, що дозволяє команді питати ці дані звичайною мовою.

Далі — про кожен шар докладніше.

Спершу ми закрили розрив у даних. Поведінку на сайті зібрали через серверний GTM – надійніший і краще контрольований збір, ніж класичний браузерний. Ми власними силами звели в одне сховище в BigQuery веб-аналітику, рекламні кабінети та додаткові витрати. Паралельно розробники Stripo завантажили внутрішню продуктову базу з платежами й підписками. На цьому стику різних світів – поведінка на сайті, дані з рекламних систем плюс реальний дохід – і будується вся подальша аналітика.

Далі – атрибуція. Замість одного погляду, як це зазвичай буває при використанні атрибуції останнього кліку, ми оцінили роль кожного каналу за чотирма різними моделями, оскільки одним з головних запитів клієнта було оцінити справедливий вклад кожного каналу трафіку:

• First Click і Last Non-Direct — моделі на основі завчасно визначених правил розподілу цінності: заслугу отримує відповідно перший або останній значущий дотик.
• Shapley Value і Markov Chains — data-driven: коефіцієнти впливу каналів вираховуються з реальних ланцюжків каналів до конверсії, тому такі моделі адаптуються до особливостей конкретного проєкту й у процесі навчання самостійно оцінюють вплив кожного каналу на досягнення цільової дії.

Чому чотири, а не одна? Бо жодна модель не є "істиною". Такі моделі, як First Click і Last Non-Direct, прості й зрозумілі, але грубі: вони віддають усе першому або останньому дотику й не помічають каналів, які працювали посередині – тих, що підводять клієнта до рішення, але самі реєстрацію не "закривають". Data-driven моделі розподіляють заслугу чесніше, за реальним внеском кожного каналу, і виводять на світло саме ці недооцінені дотики. В той же час їхня особливість в тому, що для повноцінного навчання їм треба достатньо багато даних, інакше вони майже не будуть відрізнятись від простих моделей і додаткової користі не дадуть. Тому поняття однієї "правильної" моделі не існує. Корисно дивитись на дані одразу з кількох “точок зору”: тоді можна побачити, де певний канал цінний за будь-якою логікою, а де його вага помітна тільки за певних умов, наприклад, багато атрибутованих конверсій Meta Ads від першого дотику, але в той же час цей канал рідко закриває лід. Це надійніша основа для рішень про бюджет, ніж один класичний "останній клік".

Над цими даними ми зібрали звіт у Power BI, яким команда користується майже щодня. Його завдання – показати ефективність маркетингу: як залучення перетворюється на нових платних клієнтів і які канали дають цей результат.

Воронка залучення з конверсіями. Від візиту → до реєстрації → до створення першого шаблону → до першої оплати. На кожному кроці видно кількість і конверсію в наступний, тож одразу зрозуміло, де саме відсіюються користувачі на шляху до оплати.

Фокус на залученні та новому доході. Ключові показники звіту – нові підписки й новий дохід; окремо рахується дохід від клієнтів, які повернулися після скасування підписки. Це прямо відповідає на головне питання: які канали приводять не просто реєстрації, а платних клієнтів.

Економіка каналів. У розрізі кожного каналу – вартість залучення (CAC і CPA), окупність маркетингових інвестицій (ROAS), прогнозна цінність клієнта (LTV) і співвідношення LTV/CAC. У витрати закладені і рекламні, і нерекламні, як наслідок, окупність відображає реальну картину, а не її половину.

Порівняння періодів. Кожен важливий показник стоїть поруч зі значенням попереднього періоду, а кольорове кодування підсвічує суттєві зміни, тож відхилення помітно одразу, без вчитування в таблиці.

Перемикач моделі атрибуції. Одним кліком показники перераховуються за First Click, Last Non-Direct, Shapley або Markov. Маркетолог дивиться на канал очима "останнього кліку", а потім – очима data-driven моделі, і бачить, чи тримається цінність каналу, чи це ілюзія однієї методики. Саме заради цього ми й будували чотири моделі, а не одну.

Фільтри за джерелом, каналом і країною дозволяють спуститися із загальної картини до конкретного сегмента.

Це потужний інструмент – втім, як і будь-який дашборд, він відповідає лише на ті питання, що закладені в нього наперед. А реальні питання бізнесу не завжди вписуються в готові розрізи. Саме тут логічним продовженням є AI-асистент.

Останній шар системи – асистент на базі Claude, під'єднаний до того самого сховища в BigQuery. Ми не просто відкрили йому доступ до даних, а спорядили тим контекстом, який штатний аналітик накопичує роками:

• точні визначення показників – як саме рахуються MRR, дохід, відтік, конверсії, CAC, LTV, ROAS, атрибуція;
• підводні камені даних – де легко отримати задвоєння, які дати брати для доходу, а які для відтоку, чим дохід відрізняється від MRR, коли аналіз має бути когортним, а не помісячним;
• робочий метод – спершу уточнити намір і сформулювати гіпотезу, тоді порахувати, перевірити себе за чек-листом типових помилок, розкласти результат на причини й запропонувати наступні дії.

Тобто асистент отримав не лише дані, а й спосіб правильно їх читати.

Звіт показує наперед визначені розрізи. Асистент працює там, де питання виникає вперше і готового розрізу для нього немає. Наприклад:

• «які кампанії приводять організації, що згодом переходять на вищий тариф, а не просто реєструються»;
• «порівняй цінність клієнтів з органіки та платної реклами за перші пів року співпраці»;
• «у яких країнах найбільший дохід від повернених клієнтів цього кварталу».

Кожну таку відповідь асистент обчислює із самих таблиць, без жодного SQL з боку команди. Уточнення ставляться в тому ж діалозі – "а тепер розбий це за місяцями", – і картина деталізується крок за кроком.

Асистент не лише дістає цифри, а й працює з ними: ранжує, сегментує, зіставляє періоди, шукає закономірності, оцінює ризик. Тому його застосування не обмежується довідковими запитами – наскільки далеко воно заходить, показує наступний розділ.

При цьому асистент рахує за тими самими визначеннями, що закладені у звіт, тож його відповіді збігаються з цифрами в Power BI і піддаються перевірці: за потреби він показує, з яких даних і за якою логікою отримано результат. І в цьому головна відмінність від чату, просто під'єднаного до сирих, необроблених таблиць: йому довелося б самому вгадувати бізнес-контекст і як коректно поєднати десятки незнайомих полів. А саме такі здогадки й породжують правдоподібні, але хибні відповіді. Наш асистент працює на вже впорядкованих даних із погодженими визначеннями, завдяки цьому вгадувати йому не треба – відповідь спирається на факт, а не на припущення.

Асистент не замінює ні звіт, ні аналітика – вони працюють у парі. Часто найважче питання – придумати, що спитати: перед користувачем порожнє поле вводу в чаті. Тут допомагає звіт: маркетолог відкриває його, задає період, дивиться на ключові показники – і звідти виникають глибші питання (чому цей канал просів, куди перерозподілити бюджет). Звіт показує, де щось відбувається; асистент – чому і що з цим робити. Регулярні показники лишаються у звіті, аналітик бере складніше, а коло людей, які самостійно доходять до відповіді, ширшає.

Щоб оцінити межі цього шару, ми перевірили його на складному прикладі – прогнозуванні відтоку.

Ми дали асистенту навмисно складну задачу – спрогнозувати, хто з активних клієнтів найімовірніше піде наступного місяця.

Асистент працював лише з фінансовими даними: історією підписок, платежів і доходу. Поведінкових даних про використання продукту (частота входів, активність у редакторі) у сховищі не було, оскільки ми орієнтувались на маркетинг-аналітику. Показово, що асистент від початку сам попередив: без продуктових метрик прогноз буде слабким. Задача свідомо ставилася на обмежених даних – саме щоб побачити, що інструмент дасть у типовій, а не ідеальній ситуації.

Для цієї задачі ми перевикористовували вже створену модель даних і не впроваджували Machine Learning – усе вклалося у два повідомлення до асистента, які ви бачили на скріншотах вище. Ідея була в тому, щоб перевірити, що інструмент дає "з коробки", без окремого проєкту з машинного навчання.

Асистент сам звузив коло до організацій, у яких наступного місяця мав бути черговий платіж, і оцінив кожну за набором фінансових сигналів: нещодавній перехід на дешевший тариф, спад доходу за останні місяці, повернення після попереднього скасування, короткий строк співпраці, помісячна оплата замість річної і т.д.

За сумою цих сигналів він виставив кожній організації рівень ризику й сформував пріоритезований список для команди Customer Success.

Це не був приклад "на папері": ми зберегли прогноз і через місяць звірили його з тим, що сталося насправді.

Результат насправді неоднозначний, що було очікуваним. Асистент заздалегідь указав близько половини всіх клієнтів, які згодом дійсно пішли. Список при цьому не ідеальний: у ньому приблизно кожен п'ятий згодом справді пішов – помітно частіше, ніж якби брати клієнтів навмання, але це означає й чимало хибних тривог.

Формально загальна точність склала близько 71%, проте для рідкісних подій, на кшталт відтоку, сама по собі "точність" оманлива: модель, що просто каже "ніхто не піде", теж матиме високу точність. Коректніші орієнтири тут – дві частки: скільки з тих, хто пішов, асистент спіймав заздалегідь, і скільки в списку ризику виявилися справжніми. Ми не ставили за мету підготувати production-модель за всіма канонами data science. Ми вирішили продемонструвати те, що інструмент здатний зробити з даними клієнта за лічені хвилини.

Чим це корисно бізнесу. Утримати клієнта, який подає сигнали про відхід, майже завжди дешевше, ніж залучити нового на його місце. Але щоб втрутитися вчасно, треба знати, до кого йти – до того, як він піде, а не після. Саме це й дає прогноз: за лічені хвилини команда отримує ранжований список організацій, з якими варто попрацювати цього місяця, поки в них ще відкритий цикл оплати. Помітити заздалегідь половину тих, хто реально пішов, – це шанс зберегти дохід, а не побачити втрату вже у звіті постфактум.

Модель даних для наскрізної аналітики стала корисною НЕ тільки для побудови звіту. Той самий фундамент, що дає щоденні відповіді про канали й бюджет, дозволяє й проактивні сценарії – як цей прогноз відтоку. Одна впорядкована база даних окупається багато разів, а відтік – лише один приклад того, що стає можливим, коли дані готові. Причому це вихідна точка, а не стеля: з підключенням поведінкових даних точність такого прогнозу можна помітно підвищити.

Почавшись у 2025 році, наша співпраця продовжується: звітом команда користується щодня, а ми регулярно беремо нові аналітичні задачі та підтримуємо проєкт. На сьогодні у Stripo є цілісна система, у якій кожен шар спирається на попередній:

• єдине сховище, де рекламні системи та поведінка на сайті з'єднана з реальним доходом із продуктової бази;
• атрибуція за чотирма моделями, що зважує кожен канал за фактичним вкладом, а не лише за останнім кліком;
• звіт у Power BI з воронкою залучення (візит → перша оплата) та економікою каналів – CAC, CPA, ROAS, LTV, новий і повернений дохід;
• AI-асистент, який відповідає на нестандартні питання звичайною мовою й за перевірними визначеннями – аж до проактивних сценаріїв на кшталт прогнозу відтоку.

Але головне – не перелік складових цієї системи, а те, як змінилася щоденна робота команди. Детальніше про це “розкаже” відгук від клієнта далі.