Як ми створили власний email-сервіс і збільшили дохід з email-маркетингу на 30 %

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

Привіт усім, я — Маріанна Онопрієнко. Я працюю в українській продуктовій IT-компанії appflame вже понад сім років. Маю технічну освіту — закінчила «Компʼютерну інженерію» в КПІ. Спочатку планувала стати розробницею, але після першої роботи зрозуміла, що аналітика — це моє, а потім взагалі вирішила рухатися в менеджмент.

Останні два роки я працюю на позиції Head of Retention на одному з продуктів компанії appflame — Mailkeeper. Це наш власний email-сервіс, який ми запустили у 2019 році для підвищення Retention (утримання) користувачів на продуктах компанії.

Я брала участь у запуску Mailkeeper від ідеї до його реалізації. За цей час я виросла в компанії з Data Analyst до Head of Retention і зібрала команду, у якій наразі працює 17 експертів: розробників, продактів, аналітиків, тестувальників та email-маркетологів.

Сьогодні я хочу поділитися нашим досвідом і розповісти, як ми створили власний email-сервіс, і чому зупинилися саме на цьому рішенні, а не вирішили користуватися наявними сервісами на ринку. Розповім, який шлях ми пройшли за шість років: з якими викликами стикалися, які переваги отримали завдяки власному email-сервісу, а які проблеми поки що не вдалося повністю розвʼязати.

Зокрема розповім, як ми адаптувалися до нових правил для email-розсилок від Google у 2024 році. У статті також будуть практичні поради для маркетинг-менеджерів, продактів і власників бізнесів, які працюють із Retention або шукають способи підсилити свій email-маркетинг.

Чому нас не влаштовували email-сервіси, які були доступні на ринку

Ми працюємо з продуктами, котрі розвиваються на Tier-1 ринках, мають десятки мільйонів користувачів і працюють із різними монетизаційними моделями. Для них важливо не тільки залучати нових користувачів, а й утримувати тих, хто вже в продукті.

Один із ключових інструментів для підвищення Retention — це email-маркетинг, і моя команда відповідає за цей напрям. Ми постійно нарощуємо експертизу в email-маркетингу, тестуємо різні гіпотези, знаходимо робочі рішення тощо. Але щоби розсилки працювали ще ефективніше, нам потрібна надійна система для відправки email-ів. Це допоможе забезпечувати стабільну і швидку доставку та підтримувати гарну поштову репутацію відправника.

Чому ми не хотіли використовувати зручні сервіси типу Mailchimp замість того, щоби створювати щось своє? Сторонні сервіси надто обмежені за своїм функціоналом. Вони більше підходять для невеликих бізнесів із невеликими обʼємами розсилок і не можуть покрити тих вимог, які нам потрібні. Ті продукти, з якими ми працюємо, доволі великі — тільки продукти appflame мають понад 60 млн користувачів (Hily — 36 млн, Taimi — 27 млн та аудиторія AdConnect), а нещодавно ми почали працювати ще й із зовнішніми клієнтами та їхніми продуктами.

Щоби якісно працювати над Retention користувачів кожного продукту, нам потрібно мати в email-сервісі багато складних логік, бути гнучкими й не обмежувати себе у функціоналі.

Що було не так із нашим попереднім email-сервісом або Як ми втратили 60 % користувачів після одного з експериментів

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

  • Цей сервіс був «зашитий» у продукт. Продуктові та email-логіки перепліталися, а будь-яка зміна могла викликати непередбачувані наслідки.
  • Ми не могли додавати складних рішень, бо наші поточні запити стали набагато складніші, ніж ті, які були закладені в сервіс на старті.
  • Ми не до кінця розуміли, як працює кожна частина сервісу, тому було страшно додавати нові фічі без розуміння всіх можливих наслідків.
  • Провести навіть один A/B тест займало багато часу — процес був технічно складним.
  • Усі зміни доводилося робити руками розробників, навіть для того, щоб додати простий шаблон. Це сповільнювало роботу, бо все залежало від технічних ресурсів.

Критичним моментом став експеримент, у якому ми свідомо надсилали листи нашим користувачам із нових тестових доменів без стандартного прогріву, навмисно погіршуючи логіку відправки. Ми «ламали» процес, щоб знайти межу між нормальною доставкою та потраплянням у спам і краще зрозуміти, як працюють антиспам-фільтри. Для поштових сервісів це виглядало так, ніби новий домен раптом почав масово надсилати листи незнайомим людям (хоч це не так, адже ці люди самі підписалися на нашу розсилку) — а це ознака спаму.

16-17 травня, Київ. Квитки тут!👇

Спамхаус швидко це помітив і заніс усі тестові домени в blacklist. Google теж оперативно відреагував, і проблема вийшла за межі експерименту. Наша попередня система не дозволяла локалізовувати експерименти, тому основні домени теж потрапили під удар.

У результаті ми втратили понад 60 % користувачів (їм перестали надходити листи від нас) і нам знадобилося пів року, щоби повністю відновитися і стабілізувати відправки.

Важливо, що email-маркетинг тоді приносив нам до 20% доходу, то ж у нас були серйозні проблеми. Наступні пів року були справжніми американськими гірками. Показники то зростали, то різко падали. Ми постійно експериментували, вносили зміни та шукали рішення.

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

Як відбувалася розробка нового email-сервісу

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

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

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

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

Проблем із порозумінням із технічною командою не було (маю надію). Технічна освіта і спілкування зі спільнотою в університеті пішли на користь. Ми зібрали сильну команду, де кожен із нас пропонував свої ідеї, а не просто робили по ТЗ.

Які цілі перед собою ставили

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

Мінімальний рівень успіху був — не погіршити показники, а вже наступним етапом ми націлювалися на покращення результатів, вимірюючи їх через окупність трафіку завдяки email-маркетингу та email ARPU (дохід на користувача з email-маркетингу).

Таймлайн проєкту

1. У вересні 2019 року ми почали розробку нової системи й перенесли логіку та базу даних зі старої системи. Частина команди була зібрана: ми найняли трьох PHP-розробників і QA-інженера.

До речі, більшість цих людей досі працюють із нами на проєкті, включно зі всією командою розробки. А наш тодішній QA зараз займає позицію Senior Product Manager і очолює email-напрямок.

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

Будь-яка помилка могла привести до просадок* — листи йшли б у спам або промо. Але ми проаналізували критичні елементи старої системи, відтворили ключові логіки відправки та оптимізували їх під нову систему. Завдяки цьому при розсилках із нової системи ми не знизилися в показниках.

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

*Чому в email-маркетингу можуть траплятися просадки? Це може статися через зміни в алгоритмах поштових сервісів, технічні проблеми, зміни поведінки користувачів або навіть невеликі правки в контенті. Наприклад, суперемодзі можуть здаватися крутим елементом, який привертає увагу користувачів до email-у та покращує взаємодію з ними. Але Google може сприйняти їх як ознаку рекламної розсилки та кинути лист у теки із промоакціями або відмітити як спам. У результаті менше людей побачать і відкриють лист, що знизить кліки та, відповідно, дохід.

2. У лютому 2020 року ми повноцінно запустили сервіс. Почали активно налаштовувати тестування, додавати необхідні логіки, багато працювали з контентом. Велика частина часу пішла на перевірку, чи все працює правильно.

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

3. У жовтні 2020 року ми зрозуміли, що система працює стабільно й дає хороші результати.

Ми зробили систему стабільнішою та диверсифікували ризики. Якщо зараз в нас і трапляються просадки, вони не впливають на результат так сильно, як раніше.

У результаті Mailkeeper забезпечив усе необхідне, щоб диверсифікувати ризики та зробити показники більш стабільними, а також вдалося підвищити дохід з email-маркетингу до 30%. Тому в якийсь момент співпраця з підрядником стала невигідна й ми відмовилися від стороннього сервісу.

Ми враховували і план Б на випадок, якщо нова система не спрацює. Це була наша стара система або інші зовнішні підрядники, з якими ми могли працювати паралельно, якщо показники почнуть падати. Уся робота була спланована так, щоб у разі проблем ми могли відкотитися назад.

Що вдалося зробити та як працює система

Сам по собі Mailkeeper — це лише інструмент, і він не дасть результату, якщо не знати, як використовувати його максимально ефективно.

Як уже згадувала, на початку тестування нового сервісу ми не отримали крутих показників. Після кількох місяців експериментів і додавання логік ми переробили його фокус. Зараз ми маємо інструмент для нашої email-маркетинг команди, яка продумує логіки, працює з контентом, додає шаблони, проводить A/B тести, шукає шляхи для покращення та оптимізує процеси на кожному етапі.

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

Коротко розповім про те, як працює система.

  • Незалежно від того, через який email-провайдер йде відправка, уся логіка, налаштування, контент та керування email-кампаніями ведеться через Mailkeeper.

Одна з головних проблем email-маркетингу — це оновлення поштових алгоритмів, котрі негативно впливають на поштову репутацію відправника (домену або IP).

Раніше наша інфраструктура була залежна від одного email-провайдера, і будь-яка проблема могла просадити показники на 50 % і більше. У новій системі ми розширили інфраструктуру, щоби диверсифікувати ризики. Окрім можливості працювати одразу з великою кількістю доменів/SMTP-серверів* та своїм email-сервісом, ми підключили кілька MTA** і провайдерів, через які проходять наші відправки.

Також додали функцію автоматичного перемикання між MTA, щоб у разі погіршень (наприклад, якщо IP-адреса потрапила в blacklist) максимально мінімізувати втрати.

Уже у 2024 році ми додали Amazon SES і запустили ще ряд MTA, що дозволяє бути більш гнучкими. Завдяки цьому підходу зараз при просадках у нас можуть знизитися показники не більше, ніж на 10–15 %.

*SMTP (Simple Mail Transfer Protocol) — протокол для відправки email-листів.
**MTA (Mail Transfer Agent) — сервер, який надсилає email-листи, використовуючи протокол SMTP.

  • Email-сервіс працює незалежно від продукту.

Це дозволило нам уникати конфліктів між змінами в продукті та email-ах, швидко тестувати гіпотези, оперативно вносити зміни та краще розуміти, як вони впливають на результати. Відповідно зменшити кількість просадок через потрапляння в спам і отримувати високі показники.

Крім того, ми одразу заклали принцип, що систему на бекенді треба будувати по частинах, а не зліпити все в один великий «комок». Це дозволило позбутися залежностей всередині системи.

  • Ми зробили систему гнучкою та швидкою в роботі.

У роботі з поштою постійно потрібно проводити різні тести. Чим швидше й доступніше цей процес, тим ефективніше буде наша робота загалом.

Ми зробили так, щоби через інтерфейс системи можна було самостійно налаштувати будь-яку логіку, запускати A/B тести, змінювати контент, додавати новий, тестувати різні частини листа — наприклад, хедер, from name тощо, не чекаючи, поки розробники знайдуть на це час.

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

  • Система дозволяє мінімізувати втрати при проблемах із поштовою репутацією.

Ми врахували всі критичні вимоги поштових сервісів: правильну конфігурацію відправок, налаштування підписки та відписки тощо.

Щоби email-и стабільно потрапляли в інбокс, а не в спам, ми налаштовуємо систему так, щоби поштові сервіси довіряли нашим розсилкам. Для цього використовуємо SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) і DMARC (Domain-based Message Authentication, Reporting & Conformance) — протоколи, які підтверджують, що ми справді є відправниками email-ів, а також слідкуємо за виконанням вимог усіх поштовиків.

Звісно, просадки все ще є, бо Google та інші поштові сервіси постійно оновлюють правила і працюють над репутацією. Але й ми навчилися балансувати між досвідом користувача та вимогами поштових систем. Тепер просадки не призводять до великих обвалів, як це було раніше, коли ми могли втратити до 60 % нових користувачів.

  • Ми заклали можливість роботи з різними продуктами.

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

На сьогодні сервіс має все необхідне. І навіть якщо продуктам терміново щось потрібно, наша команда може це оперативно додати.

Які є недоліки в сервісі

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

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

Один із челенджів для нової системи — кейс з апдейтом Google у 2024 році

У лютому 2024 року Google анонсував масштабні зміни, котрі впливали на роботу email-систем — вони налякали всіх. Щоб уникнути проблем із доставкою та потраплянням у спам, нашою задачею було перевірити всі наші email-розсилки та інфраструктуру, яка забезпечує їхню доставку (домени, IP-адреси, логіку відправки листів тощо) та переконатися, що вони відповідають новим вимогам Google.

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

Але одна частина апдейту додала складнощів. Це був пункт про зниження спамрейту (відсоток скарг відносно кількості відправок), якому Google раніше не приділяв великої уваги.

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

Висновки

Кажуть, що email-маркетинг вмирає, але це не так. У нього є конкуренти — соцмережі, месенджери, push-сповіщення, але жоден із них не здатен замінити email-и за глибиною комунікації та довгостроковим впливом.

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

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

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

А ще я дуже дякую моїй команді, без якої весь цей шлях був би неможливий.

Якщо у вас залишилися запитання, поради або хочете обговорити наше рішення або email-маркетинг загалом — пишіть у коментарях або мені в LinkedIn, буду рада поспілкуватися. На звʼязку!

👍ПодобаєтьсяСподобалось15
До обраногоВ обраному5
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Дякую, що поділилася інсайтами 💜

оооо, нарешті якась історія про ентерпрайз, а не про «наша продуктова команда пів року билась з дуже складним викликом який колір заголовку вибрати на 3 екнарі онбордингу і як це вплине на конверсію, ми розробили 100 АБ тестів щоб перевірити цей сценарій і далі наші висновки на 10 сторінок».

Чудово підсумовані ключові моменти та цінний досвід команди 🔥

resend з кращою документацією та меньшими цінами

Дивлячись для яких цілей

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

В цілому в цій статті не розкриті всі можливість Mailkeeper, тому можливо висновки передчасні, якщо цікаво, можемо подискутувати на цю тему )

Дякую за корисний інсайт!
Дуже цінний і цікавий досвід

Дуже цікаво, змістовно, корисна стаття 👏👏👏

Дуже цікава та ґрунтовна стаття! Особливо сподобалося, як ти відкрито говориш про виклики, з якими стикається сервіс, і показуєш реальний процес адаптації до змін. Розбір кейсу з оновленням Google у 2024 році — дуже цінний, адже багато хто ще не до кінця розуміє його вплив на email-маркетинг.
Також сподобалося, що ти не просто описуєш проблему, а й ділишся продуманими рішеннями, які дозволили зберегти ефективність без втрати ключових показників. Видно, що підхід до масштабування та оптимізації в тебе стратегічний, а не просто «гасіння пожеж».

Дуже круто все описали ;) Та і загалом ти і команду великі таланти і молодці.

Підписатись на коментарі