Розробка рекомендаційної системи для персоналізації email-розсилок

Регулярна розсилка перестає працювати, коли всім надходить один і той самий лист. Ми розробляємо рекомендаційні системи, які підбирають зміст і момент надсилання під кожного отримувача. Впроваджуємо під ключ: від аналізу даних до правил підбору та регламентів, щоб відгук зростав, а ручна сегментація не з’їдала час команди.
Часті запитання

Чому персоналізація email-розсилок ламається на масштабі

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

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

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

Чим більша база, тим швидше розходиться розмітка й реальна поведінка — і тим менше сенсу в правилах вигляду «купував за останні 90 днів».

На обсязі ручне складання випуску перестає масштабуватися. Розмітити сотні тисяч профілів до кожного відправлення аналітик не може, тому розсилка скочується до однотипних листів за великими сегментами — «усім про розпродаж».

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

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

Що дає рекомендаційний підбір у розсилках

Рекомендаційний підбір змінює не лист цілком, а три точки всередині випуску: тему й перший екран, порядок товарних блоків і момент відправлення.

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

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

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

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

Складання й відправлення ведемо в Braze та аналогічних платформах з інтерфейсом підстановки динамічних блоків.

Персоналізація email-розсилок: підходи й обмеження

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

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

Що реально порівнюють

Підхід Коли підходить Обмеження
Правила та сегменти Стабільний каталог, короткий цикл ухвалення рішень, потрібен повний контроль над показом Ручний супровід, не враховує зміну смаку, усередині сегмента листи однакові
Підбір за історією покупок Багато повторних покупок, у контакту накопичена довга історія Новому клієнту нема чого рекомендувати; рідкісні категорії випадають із видачі
Ознаки товару й листа Широкий каталог, мало даних про клієнта, багато новинок Слабо вловлює особистий смак, потребує чистих карток і заповнених атрибутів
Гібридний підбір Потрібен баланс точності й покриття на всій базі Складніший в експлуатації: потрібні журналювання, контроль якості та зрозумілий шлях відкату

Частота контактів — окремий шар поверх будь-якого варіанта: він обмежує кількість листів на одного отримувача за період і розставляє пріоритет між розсилками. Без нього точний підбір просто прискорює відписки.

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

Як ми впроваджуємо підбір: етапи інженерної роботи

Починаємо з даних, а не з моделі. Підбір листів тримається на подіях: відкриття, переходи, покупки, відмови від підписки. Якщо історія коротка або події надходять урізнобіч, перша версія буде вгадувати.

Тому маршрут розбито на етапи, і кожен закінчується перевірюваним результатом, який можна прийняти або оспорити.

  1. Аудит даних. Розбираємо, які події збираються, скільки історії зберігається, у якої частки отримувачів є поведінковий профіль і де пропуски. Підсумок — перелік прогалин і рішення: що закриваємо збором, а що обходимо правилами.
  2. Карта подій. Зводимо дії до єдиної схеми: що вважаємо сигналом, за яке вікно, з якою вагою, як зіставляємо адресу й профіль. Розбіжності в назвах подій прибираємо на цьому кроці.
  3. Налаштування підбору. Модель навчається на узгодженій історії; для нових отримувачів задаємо холодний старт — блок за популярністю сегмента, поки поведінки не вистачає. Окремо обмежуємо частоту, щоб зростання відкриттів не оплачувалося відписками.
  4. Перевірка на групі. Частина потоку продовжує отримувати попередні листи, і ми порівнюємо відкриття, переходи, частку замовлень і відписки. Ефект має триматися на кількох розсилках, а не на одній вдалій.
  5. Регламент відкату. До вмикання фіксуємо поріг метрик і порядок дій у разі його перевищення: повернення на попередню схему за один прогін, без правок у коді.
  6. Запуск і передавання. Вмикаємо поступово — спершу на частку потоку, потім на весь. Передаємо документацію, доступи й навчання вашої команди.

Далі йде супровід: розбір метрик раз на два тижні та оновлення карти подій, коли з'являються нові канали або змінюється поведінка отримувачів.

Артефакти проєкту: правила підбору й регламенти

Робоча персоналізація — це не лише видача рекомендацій, а й набір документів, за якими її можна змінювати без нас.

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

  • Схема даних. Які події збираються, з яким складом полів і як пов'язані між собою профіль отримувача, історія відкриттів і переходів, каталог пропозицій. Без цієї схеми не можна ні перенавчити модель, ні підключити нове джерело.
  • Правила підбору. Як формується набір пропозицій для одного отримувача: які ознаки беруть участь, які обмежувачі стоять — виключення вже придбаного, списки заборонених категорій, вимоги до різноманітності видачі.
  • Політика частоти. Скільки листів на тиждень допустимо на одну адресу, за якими ознаками частота знижується і що відбувається, якщо отримувач перестав реагувати — щоб зростання персоналізації не перетворилося на зростання відписок.
  • Інструкція для маркетолога. Покроковий порядок запуску розсилки, розмітка кампанії, де дивитися видані рекомендації та що робити, якщо відгук знизився відносно попереднього періоду.
  • Регламент відкату. До якого попереднього набору правил повертатися, як вимкнути персоналізацію для частини аудиторії та за якими показниками ухвалюється рішення про відкат.
  • Карта моніторингу. Відстежувані метрики з порогами відхилення: частка відкриттів, переходи, частка відписок і скарг на спам, покриття аудиторії рекомендаціями.
  • Журнал версій. Історія змін правил з датою, автором і заміром результату до й після — щоб кожне втручання можна було пов'язати з ефектом і скасувати точково.

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

Кейс: як зріс відгук регулярної розсилки

Що було до впровадження

Мережа магазинів товарів для дому надсилала регулярну розсилку за розкладом: маркетолог вивантажував сегменти, вручну відбирав товари й правив добірки під кожен випуск.

На випуск ішло шість-вісім годин роботи, до 70% позицій у листі замінювалися руками — правила сегментації не враховували історію покупок, давність візиту й залишок на складі.

Відгук тримався близько 2,3% переходів, частка відписок — 0,8% на випуск: одним і тим самим людям приходили одні й ті самі блоки.

Що змінили

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

Окремо налаштували частотні обмеження й правила «охолодження» картки, щоб товар не повторювався у двох випусках підряд.

Що стало після

Відгук на лист зріс до 5,4% переходів, частка відписок знизилася до 0,4%. Складання випуску займає близько 35 хвилин, а частка ручних правок у підборі пропозицій знизилася з 70% до 15% — маркетолог перевіряє видачу й знімає окремі позиції.

Контур віддає журнал щодо кожного випуску, тому динаміка відгуку видна за сегментами, а не лише за всією базою.

Чим відрізняється модель ранжування від правил сегментації

Правила сегментації — детермінована функція від профілю: якщо статус активний і покупка старша за два місяці, показуємо категорію X.

Модель ранжування навчається на історії взаємодій і оцінює ймовірність відгуку для пари «отримувач — контент», сортуючи блоки листа за цією оцінкою. Різниця принципова: правила задають межі, модель — порядок усередині меж.

Правила пояснюються одним рядком і дешевші в підтримці, тому їх залишають на частоті відправлень, стоп-листах і обов'язкових блоках.

Модель виграє там, де важливі спільні ознаки, які не виписуються руками: давність останнього кліку, час доби, пристрій, категорія минулого перегляду. Чим більше подій на отримувача, тим помітніший розрив у відгуку.

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

Тому правила тримаємо страхувальним шаром на перші кампанії нового отримувача й переводимо його на модель після накопичення достатньої кількості подій.

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

Перенавчання й петля зворотного зв'язку: модель рекомендує те, що частіше показували, і перестає перевіряти нове, а сезонний сплеск закріплюється як норма.

Лікується часткою трафіку на перевірку нового, розбиттям за часом, а не випадковим, і моніторингом дрейфу на відкладеному періоді. Робоча схема — гібрид: правила обмежують простір, модель ранжує всередині нього.

Часті технічні питання щодо впровадження підбору

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

Що робити, якщо історії за клієнтом майже немає?

Холодний старт закриваємо гібридною видачею: поки подій менше за поріг, працюють правила за сегментом і товарні зв'язки із загальної статистики, а в міру накопичення вага зміщується до персональної моделі.

Тригерні сценарії — покинутий кошик, повторний візит, реакція на минулий лист — дають сигнал раніше, ніж набереться історія.

Який обсяг історії подій потрібен для старту?

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

Як убезпечити персональні дані?

У модель ідуть обезличені ідентифікатори й події, а не адреси та імена; відповідність лежить окремо, доступ — за ролями, вивантаження записуються в журнал. Терміни зберігання й згоди фіксуємо в політиці: при відкликанні згоди профіль видаляється разом з ознаками.

Як перевірити якість до повного запуску?

Тримаємо відкладену вибірку й порівнюємо персоналізовану видачу з базовою за відкриттями, переходами й відмовами від підписки. Увімкнення йде за часткою трафіку — від кількох відсотків із поступовим розширенням, відкат робиться одним перемиканням ваги.

Обговорімо задачу: які дані потрібні для старту

Оцінка обсягу для персоналізації розсилок залежить від того, який сигнал уже є в даних і як швидко видача має повертатися у відправлення. Щоб не рахувати «на око», достатньо зібрати мінімальний набір вхідних — зазвичай це один дзвінок і доступ до переліченого нижче.

  • Історія взаємодій за листами за кілька місяців: відправлення, відкриття, перехід, відписка. За нею видно, чи вистачає даних для ранжування або частину сегментів доведеться об'єднувати.
  • Каталог пропозицій: що рекомендуємо, з ознаками для зіставлення й правилами, що і коли показувати не можна.
  • Доступ до даних: підключення до сховища з правами лише на читання або тестовий контур з обезличеною копією. На бойових адресах розсилок не працюємо.
  • Точки інтеграції: куди повертати видачу — у поточну платформу розсилок за її програмним інтерфейсом, у чергу або файлом за розкладом, і як часто вона перераховується.
  • Цілі за метриками: базова частка відкриттів і переходів, значущий приріст і горизонт, на якому фіксуємо результат.
  • Обмеження за даними: які ознаки використовувати не можна, терміни зберігання історії, вимоги до обезличення.
  • Контакт і поточний обсяг: відповідальний з вашого боку, кількість листів на тиждень і сегментів, порядок погодження релізів.

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

Напрямки AI-розробки

Останні роботи

  • Розробка сайту компанії B2B ADVANCE
    Розробка сайту компанії B2B ADVANCE
    1543
  • Розробка веб-додатків для компанії FEEDME
    Розробка веб-додатків для компанії FEEDME
    1394
  • Розробка веб-сайту для компанії БЕЛФІНГРУП
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    1081
  • Розробка інтернет магазину для компанії FURNORO
    Розробка інтернет магазину для компанії FURNORO
    1369
  • Розробка логотипу компанії B2B Advance
    Розробка логотипу компанії B2B Advance
    816
  • Розробка веб-додатків для компанії Enviok
    Розробка веб-додатків для компанії Enviok
    1142