Як я спроєктував би сценарій активації мерчантів

Фреймворк 01

Запитання, які я ставлю, перш ніж щось будувати.

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

Перший результат роботи старшого оператора — не ланцюжок. Це список того, про що бриф промовчав:

• —Що саме означає «активований»? Перше отримане замовлення? Перше доставлене? Перше замовлення з повтором протягом 14 днів? Визначення задає метрику успіху — помилитеся з ним, і святкуватимете замовлення, за якими ніхто не повернеться.
• —Де вони застрягають? Перш ніж писати текст, витягніть воронку: підписалися → меню опубліковане → платежі підключені → перше замовлення → повторне. Найбільший відвал — єдиний етап, заради якого варто робити кампанію. Решта — шум.
• —Скільки варте перше замовлення? Середній чек × take-rate × ймовірність повтору, мінус вартість отримати це замовлення через сценарій. Якщо врятований мерчант вартий менше, ніж канал, яким ви його рятуєте, правильна відповідь — нічого не надсилати.
• —Що бачить платформа і як швидко? Подія «меню опубліковано» в реальному часі — чи нічний batch? Затримка даних вирішує, сценарій реагує на подію чи просто йде за розкладом. Це питання вбиває більше хороших схем, ніж будь-яке інше.
• —Хто активується без нас? Частина мерчантів отримує замовлення першого ж дня без жодної допомоги. Якщо засипати їх онбординговими листами, ви витратите гроші, щоб дратувати тих, хто й так конвертував, — і припишете їхні замовлення своєму впливу. Саме від цього захищає holdout.

Фреймворк 02

Шар даних — незалежний від платформи за задумом.

Сценарію активації мерчанта потрібні три типи даних, зшиті за одним merchant ID: атрибути профілю (країна, вертикаль, дата реєстрації), стан налаштування (меню опубліковане, платежі підключені, години роботи задані) і поведінка (замовлення, сесії, тікети підтримки). Архітектура лишається незалежною від платформи: сховище чи CDP тримає зведений запис мерчанта; інструмент комунікацій — Braze, Customer.io, Iterable, in-house — лише споживає події й атрибути. Мозок — це lifecycle-логіка, а не відправник: змініть інструмент, залиште логіку.

На кожному стеку, з яким я працював, пайплайн має ту саму форму:

Єдиний атрибут, який справді окупається, — `stalled_stage`: перший крок налаштування, який мерчант ще не завершив. Він перетворює розмитий список «неактивних» на чітку чергу: цій групі треба допомогти з меню, тій — нагадати про банківські реквізити. Увесь сценарій розгалужується від цього одного похідного поля.

Фреймворк 03

Тригер за тригером — розгалужуйте за блокером, а не за календарем.

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

Пʼять гілок — у кожної є причина бути:

Одна дисципліна, яка відрізняє сеньйорів від джуніорів: fallback-контент. Кожному динамічному блоку — імені мерчанта, місту, найпопулярнішій позиції, сумі економії — потрібне значення за замовчуванням, яке нормально читається, коли даних немає. «Hi {{first_name | default: 'there'}}» — це різниця між теплим нагадуванням і «Hi ,» у 4 000 поштових скриньках. Я спершу пишу fallback, потім персоналізовану версію. Порожній стан — і є справжній дизайн.

Фреймворк 04 · ядро

Колонка holdout. Активація, а не відкриття.

Holdout — це випадкова частина новопідключених мерчантів — скажімо, 10%, — яку навмисно прибирають з усього активаційного сценарію. Вони не отримують нічого. Усі інші проходять повну послідовність. Різниця між двома групами, виміряна результатами, які впливають на P&L, — єдина чесна міра того, що сценарій справді спричинив. Відкриття й кліки цього не покажуть: мерчант, який замовив би й так, теж відкриває лист.

Тому рахунок ведеться не за «відкриттями» і не за «CTR». Є пʼять результатів: сценарій проти holdout:

• —Швидкість до першого замовлення. Медіана днів від реєстрації до першого замовлення. Головний показник: сценарій, який активує тих самих мерчантів раніше, приносить реальні гроші — GMV заходить швидше.
• —Рівень активації. Частка нових реєстрацій, які роблять перше замовлення протягом 30 днів: сценарій проти holdout. Різниця — це інкрементальна активація. Не сирий показник, який підмальовують мерчанти, що замовили б і без вас.
• —Обсяг і вартість замовлень. Кількість замовлень на активованого мерчанта і розмір чека за перші 30 днів. Сценарій, який активує мерчантів, а вони роблять одне замовлення й зникають, — це перемога у звіті, не в бізнесі.
• —Прибуток, а не GMV. Інкрементальний GMV × take-rate, мінус вартість каналу й будь-які витрати на інсентиви. Акція з безкоштовною доставкою може підняти активацію й піти в мінус. Саме holdout дає це побачити.
• —90-денний відтік і частка повторних замовлень. Чесна метрика довгої гри. Активований мерчант досі торгує через три місяці? Перше замовлення — проксі; утримання — вердикт.

Подивіться, чого тут немає: відкриттів, кліків, доставлюваності заради доставлюваності. Це діагностика, не результат — я дивлюся на них, щоб полагодити зламану розсилку (одного разу довів доставлюваність платформи з ~84% до 95%+, виправивши дефект; це була сантехніка, не доказ). Доказ — holdout. Без нього звіт про активацію — здогад у костюмі графіка.