Чому підписка на сайті втрачає листи: розбір інтеграції Unisender
Форма підписки на сайті виглядає робочою: поле, кнопка, повідомлення «дякуємо, ви підписані». Заявка при цьому може не йти нікуди — обробник складає адресу в локальну таблицю або надсилає лист на скриньку менеджера, а в сервіс розсилок не потрапляє нічого.
Через місяць з'ясовується, що половина зібраної бази лежить у файлі, який ніхто не розбирав, і ці люди не отримали жодного листа.
Другий типовий збій — втрата статусів подвійного підтвердження підписки. Людина отримує лист, натискає кнопку, але відповідь сервісу не зберігається: у базі вона залишається непідтвердженою, і запити на підтвердження йдуть знову і знову.
Одержувач сприймає це як спам і скаржиться — скарги та відписки напряму б'ють по доставлюваності листів для всієї бази, а не лише для однієї адреси.
Третій — крива обробка помилок. Якщо сервіс віддав відмову або відповів із затримкою, обробник не повторює запит і не пише збій у журнал, а просто втрачає адресу.
Повторне надсилання форми додає ту саму людину вдруге, листи йдуть на адреси, які ніхто не підтверджував, — і частина бази йде у відписки з нашої вини.
Втрата підписників майже не видна в інтерфейсі: там усе «успішно», поки не порівняєш кількість заявок із сайту з кількістю нових адрес у сервісі.
Інтеграція Unisender має закривати саме ці розриви — заявка доходить і отримує статус, повторний запит не дублює адресу, а збій видно в журналі, а не в чужій поштовій скриньці.
Що змінюється після налаштування: доставлюваність, швидкість, відписки
Поки контакти потрапляють у базу вивантаженням файлом раз на добу, людина, яка підписалася ввечері, отримує вітальний лист наступного дня — і частина адрес на той момент уже не пам'ятає, де залишила згоду.
Після зв'язки сайту з Unisender контакт іде в базу в момент надсилання форми, разом зі статусом підписки: підтверджено, очікує підтвердження, відписано.
Лист надходить протягом хвилини, поки інтерес свіжий, а статуси синхронізуються в обидва боки — відписка на сайті гасить розсилку, відписка в листі видна на сайті.
Частка підтверджених адрес зростає завдяки подвійному підтвердженню: адреса потрапляє в активну базу лише після переходу за посиланням із листа. Так відсіюються помилки друку, чужі та службові адреси, а розсилка йде тим, хто справді чекає листів.
Зниження відписок і скарг на спам — наслідок того самого порядку. Відписка в один клік одразу змінює статус і на сайті, і в базі розсилки, тому шукати кнопку «це спам» немає потреби: листи відписаним не йдуть, а поштові фільтри бачать, що механіка відписки працює. Частка потраплянь у «Вхідні» зростає разом із відгуком.
Ефект вимірюється чотирма числами: час від надсилання форми до першого листа, частка підтверджених адрес, частка відписок і частота скарг. Звіряти їх варто раз на місяць: якщо підтверджених стало менше, форма або текст листа перестали пояснювати, навіщо підписуватися.
Способи підключення: готова форма, скрипт, обмін даними
Способи підключення різняться не «рівнем складності», а тим, де живе джерело даних про підписника. В одному випадку адреса збирається прямо на сторінці, в іншому — надходить із сервера разом із замовленням або реєстрацією, у третьому — йде назад, коли людина відписалася. Від цього залежать вимоги до сайту та обмеження, які проявляться пізніше.
На практиці способи не замінюють, а комбінують: один приймає адреси, другий синхронізує статуси. У таблиці — чотири варіанти, коли кожен доречний і що він не вміє.
| Спосіб | Коли підходить | Обмеження |
|---|---|---|
| Вбудована форма підписки | Лендінг, блог, сторінка акції: прийом адрес без доопрацювання сайту | Поля та оформлення задані шаблоном; зв'язок із замовленням налаштовується окремо |
| Скрипт підписки | Кілька точок на сайті, спливаюче вікно, форма всередині матеріалу | Перевірки йдуть у браузері: якщо сторонні скрипти блокуються, форма не з'явиться |
| Програмний інтерфейс обміну даними | Підписка як частина реєстрації, замовлення, вивантаження з облікової системи | Потрібна серверна обробка відповідей і повторів: при збої контакт втрачається |
| Подієві повідомлення | Зворотна синхронізація: відписки, скарги, недоставлені листи | Потрібен приймач подій і захист від повторної обробки |
Частіше обирають комбінацію: форма або скрипт на вітрині, обмін даними — для особистого кабінету й облікової системи.
Під час підключення до Unisender ми фіксуємо, який процес закриває кожен канал, і збираємо мінімальну конфігурацію: список не дублюється, відписки доходять до сайту.
Етапи впровадження інтеграції Unisender: від аудиту до передачі
Порядок тут не формальність: якщо спочатку налаштувати розсилку, а потім розбиратися з джерелами контактів, відписки та дублікати спливають уже після перших надсилань — і репутація домену зіпсована.
Тому етапи впровадження інтеграції Unisender проходимо від аудиту до передачі, фіксуючи перевірюваний результат на кожному кроці.
-
Аудит підписних форм і поточної схеми. Дивимося, звідки надходять контакти, у який список пишуться, чи є підтвердження підписки, як обробляються відписки та повторні реєстрації тих самих адрес.
-
Схема потоків даних. Малюємо карту: поле форми → власне поле → список, сегмент або тег → сценарій. Тут же правила дедуплікації за адресою та нормалізації значень, щоб людина не опинилася в базі тричі.
-
Налаштування зв'язки. Створюємо списки, сегменти, теги, власні поля й шаблони, видаємо ключі доступу, підключаємо події із сайту: реєстрація, замовлення, покинутий кошик.
-
Перевірка сценаріїв розсилки. Проганяємо ланцюжки на тестових контактах — вітальний лист, серія прогріву, повідомлення про замовлення. Окремо дивимося відписку, повторну підписку та поведінку при недоступності сервісу: події мають піти в чергу, а не загубитися.
-
Звірка даних. Переконуємося, що відписка на сайті знімає контакт з розсилки, а зміна статусу в сервісі відображається в базі сайту.
-
Передача доступів. Віддаємо облікові записи та ключі, схему потоків, регламент додавання нових форм і сценаріїв, порядок розбору помилок.
Конфігурація, схеми та регламенти: що залишається у замовника
Здача інтеграції — це не лише працюючі сценарії, а й набір артефактів, за якими ваша команда зможе змінювати розсилки без нас. Нижче — те, що залишається на руках після запуску інтеграції сервісу розсилок із сайтом.
- Карта сценаріїв. Усі ланцюжки на одній схемі: подія на сайті, умова, затримка, лист, наступний крок. Видно, де сценарії перетинаються, а де конфліктують за ту саму аудиторію.
- Шаблони листів. Вітальний, тригерні, реактиваційний і службові — з темою, версткою та списком змінних. Позначено, які блоки редактор змінює вільно, а які зав'язані на дані сайту.
- Налаштування полів підписника. Які поля обов'язкові та службові, як вони називаються на сайті й у сервісі, правила нормалізації телефону та пошти при дублях і порожніх значеннях.
- Політики доступу. Ролі в сервісі: хто бачить списки, хто править шаблони, хто лише вивантажує статистику. Окремо — права програмних ключів і порядок їх заміни.
- Інструкції для редактора розсилок. Покрокове складання листа, перевірка змінних, тестове надсилання на свою групу, порядок публікації та відкату невдалої версії.
- Регламент синхронізації та відписок. Частота обміну, поведінка при недоступності сайту, повтор подій із черги, облік скарг і відмов досилання.
Кожен артефакт перевіряємо на живому сценарії: підписка, розгалуження, надсилання, відписка. Усе залишається у вашому репозиторії та в сервісі розсилок — змінювати сценарії й тексти можна без нашої участі.
Кейс: як зросла база підтверджених підписок
В інтернет-магазині підписка трималася на ручному експорті контактів: менеджер раз на тиждень вивантажував заявки з адмінки, чистив список очима та заливав файл у сервіс розсилок.
На момент розбору завдання до третини адрес дублювалися — клієнт приходив через форму, чат і офлайн-касу, — а листи йшли й на адреси без підтвердження, через що домен втрачав репутацію.
Ми підключили сайт до Unisender напряму: форма підписки пише контакт у потрібний список у момент надсилання, з джерелом і датою, і одразу вмикає підтвердження адреси.
Дедуплікація відбувається за нормалізованою адресою під час кожного запису, вітальний тригерний ланцюжок стартує після підтвердження, а відписки синхронно повертаються на сайт, щоб повторно не підписати людину.
Метрики до та після
| Показник | До інтеграції | Після |
|---|---|---|
| Частка підтверджених адрес | 41% | 88% |
| Дублі в базі | близько 30% | менше 1% |
| Затримка між підпискою та першим листом | 3–7 днів | хвилини |
| Ручні операції з базою | 4–6 годин на тиждень | не потрібні |
| Відписки після вітальної серії | 9% | 3% |
Ручних операцій з базою не залишилося, а в кожного контакту є джерело та дата — сегментацію за інтересами можна будувати без вивантажень.
Такий кейс інтеграції розсилок дає зростання бази підписників не за рахунок обсягу, а за рахунок якості: писати можна частіше й безпечніше для репутації домену.
Чим транзакційні листи відрізняються від масових розсилок?
Транзакційний лист — реакція на дію людини: підтвердження замовлення, чек, відновлення доступу, код входу. Його не можна відкласти — одержувач чекає лист тієї ж секунди й без нього не завершить сценарій.
Масова розсилка живе інакше: її можна розтягнути за годинами, розвести за сегментами та надіслати в момент, коли аудиторія активна.
Звідси й розділення потоків листів. У загальному потоці код підтвердження стає в чергу за кампанією на сотні тисяч адрес, і клієнт отримує його через сорок хвилин.
Пріоритет доставки вирішується окремими підключеннями та окремими чергами: транзакція йде негайно, масова розсилка — фоном, з обмеженням швидкості надсилання.
Вимоги до шаблонів теж різняться. У транзакційному важлива точна підстановка змінних — номер замовлення, склад кошика, одноразове посилання — та однакова верстка в усіх поштових клієнтах.
У масовому шаблон несе бренд і набори блоків під сегменти, а персоналізація обмежується іменем і парою полів.
Обробка помилок надсилання — головна відмінність. Відмова адреси в транзакційному потоці означає, що людина не отримала чек або не змогла увійти: потрібні повторні спроби з наростаючою паузою, журнал відмов і сигнал у підтримку.
У масовій розсилці жорстка відмова — привід позначити адресу неактивною та виключити з майбутніх надсилань, а не повторювати надсилання безкінечно.
І репутація домену: змішувати потоки з різною часткою скарг ризиковано. Сплеск скарг на рекламну кампанію потягне за собою доставлюваність чеків і кодів. У Unisender це розділяється на рівні підключень і лімітів — кожен потік зі своєю статистикою та своїми реакціями на помилки.
Часті технічні питання: синхронізація, дублі, збої
Під час інтеграції форми підписки із зовнішнім сервісом розсилок команда впирається в ті самі місця: дублі контактів, поведінку форми в момент недоступності зовнішнього сервісу та підтвердження згоди користувача.
Це не налаштування в інтерфейсі, а рішення на рівні схеми даних і обробників — тому розбираємо їх до старту, а не після першої скарги на розсилку.
Нижче — відповіді на технічні сумніви, які найчастіше надходять від інженерних команд: як вважається збіг контактів під час злиття баз підписників, що бачить користувач під час збою на боці сервісу та чим підтверджується згода на обробку даних.
Як уникнути дублів контактів під час злиття баз підписників?
Збіг вважаємо за нормалізованою адресою: наводимо до нижнього регістру, відкидаємо крапки та аліаси виду «плюс-тег». Адреса стає ключем зіставлення, інші поля зливаються за правилом пріоритету — свіже значення перекриває старе, конфлікти пишуться в лог із джерелом.
Дублі не видаляються мовчки: злиття фіксується, щоб атрибути не загубилися під час наступної синхронізації.
Що відбувається з формою, якщо зовнішній сервіс недоступний?
Форма не кидає запит у порожнечу й не віддає користувачеві помилку. Дані пишуться в локальну таблицю підписок і ставляться в чергу на надсилання; повторні спроби йдуть з наростаючою паузою, а стан контакту синхронізується, коли сервіс відповідає. Користувач бачить підтвердження одразу, а підписка доїжджає до зовнішнього сервісу без його участі.
Як підтверджується повторна підписка після відписки?
Статус контакту ведемо окремим полем, а не видаленням запису, — тому історія відписок і повторних підписок зберігається.
Повторна підписка знімає позначку відмови, але не воскрешає старі сегменти: контакт потрапляє лише в ті розсилки, де він підписаний зараз, і проходить підтвердження за листом.
Як зберігається згода на обробку даних?
Згоду фіксуємо в себе: час, текст версії, джерело форми та сторінку, з якої надійшов запит. Позначка в сервісі розсилок цього не замінює — вона живе там і зникає разом із контактом. Доказ залишається на нашому боці та вивантажується на запит.
Обговоримо завдання: що потрібно для оцінки та плану робіт
Оцінка інтеграції залежить не від обсягу розсилок, а від того, скільки точок на сайті породжують події та наскільки передбачуваним є поточний стан бази контактів. Нижче — вступні дані щодо проєкту, яких достатньо, щоб порахувати обсяг робіт і повернутися з планом впровадження. Якщо чогось немає під рукою, почнемо з того, що є, решту уточнимо під час розбору.
- Точки підписки: форми у футері та на посадкових сторінках, спливаюче вікно, крок реєстрації, оформлення замовлення — і що саме фіксується як згода.
- Сценарії тригерів: яка подія запускає лист, через скільки хвилин після неї, що відбувається при повторному спрацюванні та як сценарій зупиняється.
- Доступи: акаунт Unisender з правами на створення сценаріїв і ключ API, адмінка сайту, зона домену для налаштування підпису листів.
- Платформа сайту та її обмеження: як віддаються події, чи є черга для відкладених надсилань, як сайт переживає пікове навантаження.
- Стан бази: поля контактів, теги й сегменти, дублікати, історія підписок і відписок, частка неробочих адрес.
- Зовнішні системи: CRM, склад, платежі — що з них слугує джерелом істини, а що лише доповнює сегменти.
- Вимоги до зберігання персональних даних і строку, на який береться згода на розсилку.
Цього набору достатньо для оцінки робіт і підготовки до старту. Спірні місця розберемо на короткому дзвінку, решту уточнимо в листуванні. Опишіть завдання — повернемося з оцінкою термінів і планом впровадження за етапами.
