YourTrend — платформа email, SMS і push-розсилок

01Огляд проєкту

YourTrend — це платформа надсилання повідомлень для бізнесу: транзакційні й маркетингові email, SMS і web push з одного API. Слоган продукту звучить як обіцянка — «Email your customers actually receive», «листи, які ваші клієнти справді отримують». За цією обіцянкою стоїть цілком конкретна інженерія: кожен підключений домен підписується DKIM, записи SPF і DMARC генеруються автоматично, надсилання йде з виділеного IP, а відписки, скарги й недоставки платформа обробляє сама, без участі відправника.

Ідея виросла зі спостереження, знайомого кожному, хто запускав онлайн-продукти: надіслати лист із застосунку просто, а от домогтися, щоб він стабільно потрапляв у «Вхідні», — окрема професія. Поштові провайдери рік за роком посилюють вимоги до автентифікації та репутації відправника, і «просто SMTP» без DKIM, SPF і DMARC дедалі частіше означає теку «Спам» або мовчазну відмову. Паралельно бізнес обростає зоопарком сервісів: один — для транзакційної пошти, другий — для маркетингових розсилок, третій — для SMS, четвертий — для push. У кожного свій API, свої контакти, своя статистика — і жодної цілісної картини.

YourTrend збирає все це в одну платформу: SMTP-релей і чистий HTTP API для надсилання, кампанії та автоматизації для маркетингу, SMS і web push на тій самій контактній базі, єдиний inbox для вхідної пошти з усіх доменів і zero-access шифрований ящик для приватного листування. Ми спроєктували й побудували продукт цілком — від конвеєра доставки й моделі подій до кабінету, документації та тримовної посадкової (EN/UK/RU).

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

02Контекст і завдання

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

• Спам замість inbox. Без коректних DKIM, SPF і DMARC навіть чесні транзакційні листи йдуть у спам або відхиляються. Налаштувати ці записи правильно з першого разу — завдання, на якому спотикаються й досвідчені команди.
• Репутація спільних IP. На shared-інфраструктурі ваша доставлюваність залежить від сусідів: чужа агресивна розсилка псує репутацію IP всім, хто його ділить.
• Дублі під час ретраїв. Мережа моргнула, застосунок повторив запит — користувач отримав два однакові чеки. Без ідемпотентності на боці API це неминуче.
• Розірвані канали. Email в одному сервісі, SMS у другому, push у третьому: контакти й сегменти не збігаються, а «єдина картина клієнта» існує лише в презентаціях.
• Ручна гігієна списків. Недоставки (bounce) і скарги треба відловлювати й виключати з майбутніх надсилань. Вручну цього не робить майже ніхто — і репутація тихо деградує з кожною розсилкою.
• Вхідна пошта врозтіч. У бізнесу з кількома доменами відповіді клієнтів розкидані по скриньках і вкладках, а відповісти саме з тієї адреси, куди написали, — окремий квест.

Завдання формулювалося так: побудувати платформу, в якій доставлюваність — не результат копіткого налаштування, а властивість за замовчуванням. Розробник підключає домен, публікує згенеровані DNS-записи й надсилає; все інше — підпис, репутацію, suppression-листи, відписки — платформа бере на себе.

Окремий пласт — вимоги до самого конвеєра. Транзакційний лист про скидання пароля має піти за секунди й не має права загубитися; маркетингова кампанія на тисячі адрес не повинна заважати транзакційному потоку; і щодо кожного повідомлення відправник має бачити, що з ним сталося: прийнято, доставлено, відкрито, відхилено, скарга. Усе це — з двома рівноправними способами інтеграції: старим добрим SMTP для наявних застосунків і чистим HTTP API для нових.

03Цілі проєкту

Із завдання виросли конкретні продуктові та інженерні цілі, які ми тримали у фокусі на всіх етапах:

• Доставлюваність за замовчуванням. DKIM-підпис кожного домену, автоматична генерація SPF і DMARC, виділений IP надсилання, автоматичні suppression-листи й відписка в один клік.
• Два входи — один конвеєр. SMTP-релей для застосунків, які вже вміють надсилати пошту, і REST API для всього іншого. Всередині — той самий пайплайн з тими самими гарантіями.
• Ідемпотентність і батчинг. Повторний запит не породжує другого листа; масові надсилання йдуть пачками, а не тисячами одиночних викликів.
• Три канали на одній базі. Email, SMS і web push працюють з одними й тими самими контактами та сегментами — без експорту CSV між сервісами.
• Спостережуваність. Кожна подія — доставка, відкриття, клік, недоставка, скарга — видно в кабінеті й стримиться у вебхуки відправника.
• Вхідна пошта — в одному місці. Єдиний inbox по всіх доменах з відповіддю з точної адреси отримання, плюс zero-access шифрований ящик для приватного листування.

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

04Що ми зробили

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

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

Важливо, що чотири опори не існують порізно. Конвеєр надсилання живить аналітику, аналітика — suppression-листи, контактна база — всі три канали, а єдиний inbox замикає коло, повертаючи в платформу відповіді отримувачів. Інтегратор працює не з набором сервісів, а з однією системою, де в кожного повідомлення спільний життєвий цикл: прийнято → підготовлено → підписано → доставлено → подія.

05Архітектура рішення

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

• Приймання — SMTP-релей (mail.yourtrend.online: автентифікація, STARTTLS) і HTTP API: валідація, перевірка відправника, ідемпотентність.
• Конвеєр обробки — черги: рендер шаблонів, персоналізація, звірка адресатів із suppression-листами, DKIM-підпис.
• Доставка — надсилання з виділеного IP, керування з'єднаннями з приймальними серверами, ретраї в разі тимчасових відмов.
• Подієвий контур — доставки, недоставки, скарги, відкриття та кліки збираються в єдиний потік; кабінет і вебхуки читають одне джерело.
• Вхідний контур — приймання пошти на домени користувача, єдиний inbox, відповідь з точної адреси; окремим треком — zero-access ящик.
• Контактний граф — email-адреси, телефони й push-підписки живуть на одному контакті; сегменти спільні для всіх каналів.

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

Ролі рознесено й на рівні адрес: посадкова з документацією, кабінет, вебмейл і SMTP-релей живуть кожен на своєму хості зі своїми політиками доступу й кешування — публічний сайт не ділить оточення з інтерфейсами, де користувач працює з поштою. За DNS, TLS і захист периметра відповідає Cloudflare; інтеграція з ним же дозволяє опублікувати DNS-записи домену однією командою просто з онбордингу.

06Як лист доходить до адресата

З погляду інтегратора шлях повідомлення укладається в п'ять кроків, і більшість із них відбувається без його участі:

• 1. Приймання. Застосунок віддає лист — SMTP-запитом на релей або POST-запитом в API. Медіанний час приймання по API — менше двох секунд: запит валідується, дедуплікується за ключем ідемпотентності й стає в чергу.
• 2. Підготовка. Конвеєр рендерить шаблон, підставляє дані отримувача й звіряє адресу із suppression-листом: тим, хто відписався чи поскаржився, лист не піде.
• 3. Підпис. Лист підписується DKIM-ключем домену відправника; SPF і DMARC уже опубліковані в DNS з моменту підключення домену. Для приймального сервера лист криптографічно прив'язаний до домену.
• 4. Доставка. Надсилання йде з виділеного IP; тимчасові відмови — greylisting, перевантаження отримувача — обробляються ретраями з наростальними інтервалами.
• 5. Події. Прийнято, доставлено, відхилено, відкрито, клік, скарга — кожна подія фіксується, з'являється в кабінеті й стримиться у вебхуки відправника.

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

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

07Ключові можливості

Розберімо те, що робить YourTrend не «надсилалкою листів», а комунікаційною платформою продакшн-рівня.

Транзакційні листи

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

SMTP-релей і HTTP API

Наявному застосунку не треба переписуватися під новий API: досить змінити SMTP-хост на релей платформи й указати облікові дані — все, що застосунок уже вміє надсилати, поїде через конвеєр YourTrend з підписом та аналітикою. Нові інтеграції зручніше будувати на REST: JSON-запит, передбачувані відповіді, машиночитані помилки. Довкола API — дружність до екосистем: Laravel, Node.js, Python, WordPress, Zapier і React перелічені серед готових шляхів інтеграції.

Ідемпотентність і батчинг

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

SMS

Коли лист — не той канал (код підтвердження, термінове сповіщення про доставку), з тієї самої контактної бази йде SMS: транзакційні й маркетингові повідомлення, ті самі сегменти, той самий подієвий контур. Не треба вести другу базу телефонів в окремому сервісі.

Web push

Браузерні сповіщення повертають користувачів на сайт: підписка суворо opt-in, аудиторія сегментується, доставка миттєва. Для продуктів без мобільного застосунку це найкоротший шлях до «пуша» — без сторів, SDK і релізних циклів.

Аналітика й вебхуки

Відкриття, кліки, недоставки й скарги видно в дашборді — і паралельно стримляться у вебхуки. Кабінет зручний людині, вебхуки — коду: поверх подій можна будувати свою логіку (наприклад, позначати адреси з hard bounce у власній CRM), не опитуючи API в циклі.

08Доставлюваність як інженерна задача

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

• DKIM для кожного домену. Кожен підключений домен отримує ключ, і кожен лист підписується: приймальний сервер криптографічно перевіряє, що лист справді від вашого домену й не був змінений дорогою.
• SPF і DMARC — згенеровані за вас. Платформа не відправляє користувача читати RFC: готові записи можна скопіювати в DNS як є — або опублікувати однією командою через інтеграцію з Cloudflare.
• Виділений IP надсилання. Репутація не ділиться з чужими розсилками: ваші листи йдуть з адреси, історію якої формуєте тільки ви.
• Відписка в один клік (RFC 8058). List-Unsubscribe з one-click: отримувач відписується кнопкою поштового клієнта, не відкриваючи сайт. Це вимога великих провайдерів до масових відправників — і найкращий спосіб перетворити потенційну скаргу на тиху відписку.
• Автоматичний suppression. Hard bounce, скарга, відписка — адреса автоматично потрапляє в suppression-лист і виключається з майбутніх надсилань. Списки чистяться самі, репутація не деградує.

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

09Безпека й zero-access пошта

Платформа, через яку йде чужа транзакційна пошта, зобов'язана бути акуратною з доступами. Надсилання через SMTP-релей вимагає автентифікації й захищене STARTTLS; доступ до API — за ключами відправника; весь трафік — лише по TLS. Відписка в один клік і автоматичний suppression працюють і як механізм безпеки: вони не дають перетворити платформу на джерело небажаної пошти, а опублікована анти-спам політика закріплює це правилами, які захищають і отримувачів, і репутацію сумлінних відправників.

Окрема частина продукту — zero-access шифрований ящик. Це пошта для приватного листування, влаштована за принципом наскрізного шифрування: вміст шифрується на боці користувача, і сервер зберігає лише шифротекст. «Zero-access» тут буквально: платформа не має технічної можливості прочитати ці листи — немає ключів, нічого видати на запит і нічого втратити в разі компрометації.

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

10Кампанії та автоматизації

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

Автоматизації знімають рутину «листа за подією»: welcome-серія після реєстрації, drip-ланцюжок після покупки, наздоганяльне повідомлення після паузи. Ланцюжки збираються без коду: подія → повідомлення → інтервал → наступне повідомлення. Раз налаштована автоматизація працює сама, а кожен її лист проходить через той самий конвеєр з підписом, suppression та аналітикою, що й усе інше.

Суттєво, що маркетинговий контур не ізольований від транзакційного: контакти й події спільні. Якщо адреса відписалася чи дала hard bounce, кампанії враховують це негайно; якщо кампанія привела користувача до покупки, транзакційний чек піде тому самому контакту через ту саму платформу. Для бізнесу це означає одну базу й одну історію комунікацій замість експорту CSV між трьома сервісами.

11Єдиний inbox

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

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

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

12Developer experience та інтеграції

Ми проєктували YourTrend з позиції розробника, якому треба «підключити пошту й забути». Звідси — три кроки до продакшену: додати домен і опублікувати згенеровані SPF, DKIM і DMARC (копіпастом або однією командою через Cloudflare), підключитися — SMTP-релей або HTTP API — і надсилати. Старт безкоштовний; масштаб — у міру зростання.

Інтеграція дружня до будь-якого стека: Laravel, Node.js, Python, WordPress, Zapier і React — серед перелічених шляхів підключення. У legacy-застосунків уже є SMTP-клієнт, у нових — HTTP; в обох випадках шлях до першого листа вимірюється хвилинами, а не спринтом. Документація, API reference і статус-сторінка публічні — інтегруватися можна без жодного дзвінка.

Перевірено в бою — на нас самих. Контактна форма й транзакційна пошта ostohlo.com ідуть через SMTP-релей mail.yourtrend.online — з автентифікацією та STARTTLS. Платформа возить продакшн-пошту всієї екосистеми студії: кожен лист, який ми надсилаємо клієнтам, проходить через той самий конвеєр, що й пошта будь-якого користувача YourTrend. Це найкраща форма контролю якості: якби конвеєр губив листи, першими це помітили б ми самі — на власних заявках.

13Технологічний стек та інфраструктура

Під YourTrend зібрано окреме середовище, в якому уживаються вебінтерфейси, API та фонові процеси доставки — з різними профілями навантаження, але спільною моделлю даних.

• Бекенд — PHP 8.3: API, кабінет, конвеєр обробки й подієвий контур в одному передбачуваному оточенні.
• Поштовий шар — SMTP-релей з автентифікацією та STARTTLS, DKIM-підпис, черги з ретраями, автоматичні suppression-листи.
• Канали — SMS-шлюз і web push поверх тієї самої контактної моделі; єдиний inbox і вебмейл для вхідної пошти.
• Інфраструктура — Cloudflare (DNS, TLS, захист периметра) з інтеграцією для публікації DNS-записів однією командою; виділений IP для надсилання.

Несуча конструкція всієї платформи — черги. Вони розв'язують приймання й доставку: API відповідає за частки секунди, бо не чекає на приймальний сервер; транзакційний потік не стоїть за кампанією; ретраї — природна частина моделі, а не латка поверх неї. Вибір PHP 8.3 прагматичний: зріла, швидка платформа, на якій зручно тримати і API, й інтерфейси, і фонові процеси в одному стеку. Cloudflare закриває периметр і DNS — і заразом дає ту саму інтеграцію «однією командою», яка перетворює найстрашніший для новачка етап, налаштування DNS, на формальність.

14Дизайн і UX

Інфраструктурний продукт продає впевненість, тому посадкова YourTrend пояснює цінність за секунди: «Email your customers actually receive», три кроки до старту й чесні цифри — цільовий аптайм 99,9% і медіанне приймання по API менше двох секунд. Продукт тримовний — EN, UK і RU: інтерфейси, документація та посадкові написані кожною мовою, а не прогнані через перекладач.

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

Найважливіша UX-ділянка — онбординг домену. Зазвичай це момент, де новачок тоне в TXT-записах; YourTrend генерує записи й показує їх готовими до копіювання, а з Cloudflare публікує однією командою. Ми ставилися до цього екрана так само, як до платіжного checkout у фінтех-проєктах: це місце, де користувач або доходить до цінності, або йде. Кожна деталь — від формулювань до порядку кроків — працює на те, щоб перший успішно доставлений лист стався якомога раніше.

15Як ми працювали

Проєкт вели послідовними етапами з демонстрацією результату на кожному кроці:

• Дослідження. Розібрали вимоги поштових провайдерів до автентифікації та масових відправників (DKIM, SPF, DMARC, RFC 8058), сценарії транзакційного й маркетингового надсилання, канали SMS і push.
• Архітектура. Спроєктували конвеєр, модель подій, контактний граф і контракти: формати API, семантику ідемпотентності, схему suppression-листів.
• Ядро. Зібрали приймання (SMTP-релей і API), черги, DKIM-підпис, доставку з виділеного IP, подієвий контур і кабінет.
• Канали й inbox. Додали SMS, web push, єдиний inbox з вебмейлом і zero-access шифрований ящик.
• Запуск. Розгорнули інфраструктуру за Cloudflare, оформили посадкову, документацію та статус-сторінку трьома мовами — і перевели пошту власної екосистеми на платформу.

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

16Результат

Вийшла не «ще одна розсилалка», а комунікаційна платформа повного циклу: від DNS-записів до аналітики, від чека до кампанії, від SMS до шифрованого ящика.

• Домен підключається за хвилини: SPF, DKIM і DMARC генеруються автоматично й публікуються копіпастом або однією командою через Cloudflare.
• Транзакційна й маркетингова пошта, SMS і push живуть на одній контактній базі з однією аналітикою.
• Події кожного повідомлення видно в кабінеті й стримляться у вебхуки — інтегратор будує свою логіку поверх, не опитуючи API.
• Платформа обслуговує продакшн-пошту екосистеми студії: контактна форма й транзакційні листи ostohlo.com ідуть через її SMTP-релей.

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

17Висновки

YourTrend — кейс про те, що доставлюваність — це архітектура, а не удача. Все, що вирішує долю листа — підпис, DNS-записи, репутація IP, гігієна списків, відписки, — давно відоме й описане в стандартах; питання лише в тому, чи виконується це за замовчуванням, чи залишене користувачеві «на потім». Ми обрали перше — і саме це відрізняє платформу від інструкції з налаштування.

Для нас це був проєкт на стику протоколів, інфраструктури та продукту: SMTP і DNS, черги й моделі подій, маркетингові сценарії та криптографія zero-access ящика. Якщо вам потрібен сервіс з API, конвеєром обробки й високими вимогами до надійності — від платіжного шлюзу до комунікаційної платформи — ми вміємо доводити таке до запуску.

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