W skrócie
Zbudowaliśmy serwis do e-mail marketingu, który dostarcza 100M+ wiadomości miesięcznie, przechowuje 40M+ danych osobowych użytkowników i udostępnia analitykę dla każdej zrealizowanej kampanii.
Platforma do realizacji spersonalizowanych kampanii reklamowych na skrzynki pocztowe
W latach 2019-2020 zbudowaliśmy szereg aplikacji webowych dla naszego klienta – EngageData. W tym artykule przedstawię jeden z tych serwisów: narzędzie do masowego dostarczania wiadomości e-mail na skrzynki pocztowe.
W momencie rozpoczęcia współpracy nasz klient już wykorzystywał do tego celu zewnętrzny system. Wówczas nazywał się on Redlink, a po rebrandingu jest dziś znany jako MessageFlow.
EngageData dążyło do własnego systemu, by nie być zależnym od zewnętrznego dostawcy. W efekcie tych starań mieliśmy zbudować nowy system i zapewnić bezbolesne przejście z Redlinka na własne rozwiązanie – EngageMail.
Czym jest e-mail marketing
Wyobraź sobie, że jesteś, powiedzmy, McDonaldem, BMW bądź sprzedajesz wycieczki turystyczne. Wraz z twoim działem marketingowym poszukujecie nowych kanałów docierania do użytkowników. Z tym zapytaniem zwracacie się do jednego z domów mediowych i dostajecie propozycję: dostarczenie kampanii marketingowej na skrzynki e-mail.
Za symboliczny początek e-mail marketingu uznaje się rok 1978, kiedy Gary Thuerk z firmy Digital Equipment Corporation wysłał pierwszą masową wiadomość promocyjną do około 400 osób w sieci ARPANET. Reklamował komputery DEC. Zaowocowało to sprzedażą rzędu kilkunastu milionów dolarów.
Od pomysłu do realizacji marketingu kanałem e-mail prowadzi długa ścieżka. Na pewno będzie potrzebna strona docelowa z reklamowanym produktem bądź usługą, na którą użytkownik zostanie skierowany w przypadku zainteresowania i chęci zapoznania się z ofertą bardziej szczegółowo. Należy z działem marketingu popracować nad tytułem takiej wiadomości, stworzyć grafikę, uwzględnić kwestie prawne, dobrać grupę docelową itd.
W efekcie końcowym użytkownik dostanie wiadomość e-mail, co przy odpowiedniej skali przekłada się na dobrej jakości leady oraz zwiększenie sprzedaży.
Wyzwania biznesowe
Pod kątem biznesowym należy odpowiedzieć na pytania:
- Gdzie pozyskać bazę danych użytkowników?
- Jak zapobiec blokowaniu adresów IP, z których jest realizowana kampania?
Dlaczego kwestia dostarczalności znalazła się wśród pytań biznesowych? Na pierwszy rzut oka to stricte techniczna sprawa. Zagadnienie jest dość skomplikowane i obszerne. W ramach polskiego rynku, kiedy chcemy dostarczać miliony wiadomości e-mail na godzinę, nie ma opcji, by rozstrzygnąć to na poziomie stricte technicznym.
Wspomniałem o polskim rynku. Otóż jest on dość specyficzny i ma swoje osobliwości. Historycznie tak się złożyło, że mamy kilka portali newsowych umożliwiających zakładanie skrzynek pocztowych: WP, Onet oraz Interia. Posiadają one programy partnerskie, w ramach których można się umówić na dostarczenie określonej liczby wiadomości e-mail z własnej infrastruktury do skrzynek konkretnego operatora.
WP wycofało się z tego rodzaju współpracy w styczniu 2025 roku. Istnieją natomiast alternatywne sposoby dostarczania wiadomości do skrzynek tej platformy.
Właśnie z tego powodu zaliczam dostarczalność do kwestii biznesowych w kontekście mass mailingu – wymagana jest pewność dotarcia planowanej kampanii marketingowej, a przy dużej skali da się to załatwić tylko na poziomie odpowiednich umów między podmiotami.
Co do pozyskania bazy danych użytkowników: ma to być legalnie pozyskany zbiór, m.in. zawierający zgody RODO. Nasz klient posiada własne bazy danych, a użytkownicy zbudowanej przez nas platformy mają możliwość wgrania własnego zbioru kontaktów. Jak te kontakty są pozyskiwane, ile to zajmie czasu, gdzie można je wypożyczyć czy zakupić w razie zainteresowania – to już kwestie know-how każdej firmy z branży e-mail marketingowej.
Wyzwania techniczne
Dostarczenie wiadomości e-mail nie jest rocket science samo w sobie. Protokoły przesyłania danych są dobrze ustandaryzowane i ściśle opisane. Według stanu na rok 2026 każdego dnia wysyłanych i odbieranych jest ponad 300 miliardów wiadomości e-mail.
Wyzwania pojawiają się jednak przy próbie tzw. mass mailingu. Najprawdopodobniej taka wysyłka zostanie zbanowana na poziomie infrastruktury odbiorcy – zahaczyłem o ten temat wyżej.
Przy ponowieniu zablokowanej kampanii po stronie odbiorcy prawdopodobnie nasza własna infrastruktura zostanie zablokowana. Operatorzy centrów danych pilnie strzegą sposobów wykorzystania swojej infrastruktury.
Oto lista potencjalnych problemów po stronie technicznej przy próbie zorganizowania mass mailingu:
- Z której infrastruktury skorzystać?
- Jak zaprojektować platformę z myślą o skalowalności?
- Które części przyszłego systemu można zapożyczyć z Open Source, a które należy zbudować od zera?
Nie jest to pełna lista. Stanowi natomiast dobry punkt wyjściowy, by zrozumieć złożoność całego przedsięwzięcia. Klient potrzebował narzędzia, które zastąpi dotychczasowe rozwiązanie oraz zostanie zbudowane w technologiach znanych zespołowi developerskiemu, aby móc je w przyszłości rozwijać, skalować oraz wprowadzać szybkie poprawki, gdyby wydarzyła się awaria.
Specyfikacja
Została podjęta decyzja, że w jak najkrótszym czasie jako Koncewicz Software House mieliśmy zaprojektować, zbudować i dostarczyć narzędzie, które miało zastąpić Redlink.
Oto lista funkcjonalności, które należało zaimplementować:
- Lista kontaktów użytkowników.
- Podział kontaktów na grupy.
- Tworzenie kampanii marketingowej na wskazaną grupę.
To mocne uogólnienie. Każda z tych funkcjonalności zawierała swoje podrzędne właściwości, takie jak import/export kontaktów, mechanizm wypisywania, możliwość zakładania osobnych baz danych, serwery wysyłkowe oparte na Postfiksie, REST API, uwierzytelnianie tokenem, dwuskładnikowa autentykacja itd.
Rozwinę te tematy poniżej, podczas omówienia każdego z tych punktów osobno.
Infrastruktura
Nie chcieliśmy własnej infrastruktury – nie zamierzaliśmy zajmować się zakupem sprzętu na własność ani kolokacją. Specyfika projektu nie nakładała rygorystycznych ograniczeń w tym zakresie.
Infrastrukturą powinni zajmować się wyspecjalizowani w tym inżynierowie. Zarządzanie nią jest na tyle skomplikowane i kosztowne, że przy projektach o tej skali własny sprzęt rzadko się zwraca. Rozpisaliśmy to szczegółowo, razem z porównaniem czterech modeli infrastruktury, w tekście o wyborze infrastruktury w branży e-mail marketingu.
Podczas analizy wymagań dotyczących dostawcy usług chmurowych wybór padł na OVH oraz DigitalOcean.
OVH posiada serwerownie ulokowane w Polsce, pozwala na łatwy zakup i konfigurowanie dodatkowych adresów IP (do ruchu w obie strony) oraz ma w ofercie serwery dedykowane. W naszym przypadku potrzebowaliśmy dużego serwera, który podzieliliśmy na mniejsze i wykorzystaliśmy bezpośrednio do wysyłania wiadomości e-mail.
DigitalOcean został wybrany do umieszczenia panelu budowanej aplikacji (zarządzanie kontaktami, planowanie kampanii, API do zewnętrznych integracji) oraz do przechowywania wszystkich gromadzonych danych. DigitalOcean świetnie sprawdza się w tego rodzaju aplikacjach: jest prosty, minimalistyczny, stabilny, daje narzędzia monitoringu, a zasoby łatwo się skalują.
Skalowalność
Biznes oczekiwał elastyczności od przyszłego systemu. Należało w krótkim czasie zbudować pierwszą wersję systemu obarczoną najmniejszymi kosztami utrzymania. Z biegiem rozwoju projektu należało przewidzieć możliwość zwiększania zasobów.
Wizja ta była słuszna, lecz nie było możliwości oszacowania, w którym momencie nastąpi ten wzrost i czy będzie liniowy, czy wykładniczy. Nie wiedzieliśmy, ile kontaktów będziemy posiadać w bazie danych na przestrzeni następnego roku, dwóch, pięciu czy dziesięciu lat. Nie wiedzieliśmy, ile wiadomości e-mail należy dostarczyć w określonej jednostce czasu ani w którym momencie nastąpi ten wzrost – i czy nastąpi w ogóle.
Brak dokładnych informacji o obciążeniu nakłada dość rygorystyczne wymagania na architekturę aplikacji. Jednocześnie powinniśmy uniknąć przedwczesnej optymalizacji, która potrafi zaszkodzić projektowi mocniej niż niedoszacowanie złożoności przedsięwzięcia. Jeszcze na etapie budowania MVP powinniśmy założyć optymalny kierunek rozwoju projektu, który uwzględni podstawowe scenariusze, a jednocześnie pozwoli nam uniknąć pułapki over-engineeringu.
Architektura
Aplikacja została podzielona na dwa odrębne obszary:
- Panel. Zawiera kontakty użytkowników, grupy, odpowiada za planowanie kampanii, udostępnia statystyki itd.
- Courier. Osobny mikroserwis, który odpowiada za dostarczanie wiadomości e-mail przez protokół SMTP.
Panel występuje w pojedynczym egzemplarzu. Natomiast Courier jest wielokrotnie zduplikowany w celu zwiększenia przepustowości.
Panel został oparty na relacyjnej bazie danych. Elastyczność w kontekście skalowalności została zrealizowana w dwóch płaszczyznach: na poziomie struktury bazy danych oraz możliwości dokładania dowolnej liczby mikroserwisów Courier.
Courier został upubliczniony w Open Source pod nazwą Postvel.
Specyfiką e-mail marketingu jest podział zbiorów danych na odrębne, tzw. bazy danych. Każdy z tych zbiorów może pochodzić z odrębnego źródła, posiadać specyficzne atrybuty (np. imię, nazwisko, płeć użytkownika) oraz różnić się liczbą kontaktów (od dziesiątek tysięcy do milionów).
Biorąc pod uwagę, że reszta danych – grupy, kampanie, statystyki – bazuje na konkretnym źródle danych użytkowników, a same zbiory danych mają spersonalizowaną nazwę czy pochodzenie, wykorzystaliśmy ten fakt, by osadzić każdy z nich w osobnej fizycznej bazie danych.
Działa to następująco. Podczas wgrywania nowego zbioru danych administrator serwisu tworzy nową bazę danych, wskazując jej nazwę. Dla administratora to tylko wypełnienie pojedynczego pola. Wtedy po stronie backendowej tworzy się nowa fizyczna baza danych – z dziesiątkami tabel i indeksów.
Można by każdy nowy zbiór danych wgrywać do jednej bazy danych, oznaczając w osobnej kolumnie właściciela zbioru. Wymagałoby to znacznie wydajniejszej infrastruktury, a do tego pojawiłby się problem z natychmiastowym usuwaniem danych – przebudowanie indeksów przy nagłym usunięciu setek tysięcy rekordów nie jest trywialnym zadaniem. Posiadanie osobnej fizycznej bazy danych dla każdego ze zbiorów rozwiązuje te problemy.
Milion wiadomości na godzinę
Załóżmy, że dzisiejszego dnia jesteśmy w stanie dostarczyć 10 tys. wiadomości e-mail na godzinę. Jak szybko potrafimy zwiększyć tę liczbę do ponad jednego miliona? Jeśli wymagania biznesowe znów ulegną zmianie, czy potrafimy szybko i małym kosztem obciąć nieużywaną infrastrukturę?
Bezpośrednim dostarczaniem wiadomości zajmuje się odrębny mikroserwis – Courier. Na poziomie Panelu utworzyliśmy osobną tabelę, która przechowuje listę wszystkich instancji (wirtualnych serwerów) z odpaloną kopią mikroserwisu Courier. Wystarczy odpalić dodatkowe instancje i przepustowość automatycznie wzrasta.
Każdy egzemplarz mikroserwisu Courier ma przypisany jeden wychodzący adres IP i potrafi sprawnie działać na serwerze o zasobach 1 CPU i 2 GB RAM.
Oczywiście przepustowość to nie stricte kwestia techniczna. Główną rolę odgrywają tu umowy z odpowiednimi podmiotami (wspominałem o tym wyżej), umożliwiające dostarczanie z odpowiednią prędkością, oraz know-how zgromadzone przez naszego klienta. Mimo to od zespołu Koncewicz Software House było wymagane zbudowanie odpowiedniej infrastruktury z optymalnymi kosztami utrzymania i możliwością skalowania.
Równoległość
Paradoks, ale dokładanie kolejnych serwerów SMTP nie jest wystarczającym warunkiem zwiększenia przepustowości. Każdy z tych serwerów z osobna nie dostarczy miliona wiadomości na godzinę. Maksymalnie – 100 tysięcy.
Kampanie marketingowe są realizowane na konkretną grupę użytkowników. Załóżmy, że jest to grupa o konkretnych zainteresowaniach użytkowników, która zawiera 250 tys. kontaktów. Jak zrealizować kampanię marketingową na tę ćwierć miliona kontaktów, by równomiernie obciążyć całą naszą infrastrukturę serwerów SMTP? Bo to jedyna ścieżka osiągnięcia przysłowiowego miliona dostarczonych wiadomości na godzinę.
Wprowadziliśmy tzw. mechanizm chunkowania kampanii. W systemie mamy na sztywno wpisane, ile kontaktów ma zawierać jeden taki chunk. Załóżmy, że to 10 tys. Podczas tworzenia nowej kampanii marketingowej (na konkretny zbiór danych) powstają jej chunki, do każdego z których zostaje przypisane nie więcej niż przysłowiowe 10 tys. kontaktów. Jeśli mamy kampanię na 250 tys. kontaktów, to daje nam to 25 chunków.
Każdy chunk jest traktowany jako osobna mini-kampania, należąca do jednej rodzicielskiej. Podejście to daje możliwość osiągnięcia wysokiej prędkości dostarczania, bo teraz chunki już nie zależą jeden od drugiego, mają przypisany do siebie osobny serwer SMTP, przez co osiągamy pożądaną równoległość.
Podsumowanie
W ramach tego projektu zbudowaliśmy szereg innych serwisów, takich jak EngageIndex, EngageClick czy wspomniany wyżej Courier. To tematy na odrębne artykuły. W ramach EngageMail udało nam się zaprojektować, zbudować i wdrożyć centralny system, na którym opiera się reszta.
EngageMail to centralny system, który umożliwia naszemu klientowi zarządzanie całym procesem w kontekście e-mail marketingu. Zarządzanie przepustowością, zbiorami danych, statystykami, soft- i hard-bounce'ami – wszystko w jednym miejscu.
Zewnętrzni partnerzy naszego klienta komunikują się z API tego serwisu. EngageMail stał się jedynym źródłem prawdy w skomplikowanych procesach tego obszaru biznesu naszego klienta. Z poziomu tego panelu nasz klient decyduje, kto będzie miał dostęp do których konkretnie zasobów, i podejmuje decyzje o odebraniu tych dostępów.
Jesteśmy niesamowicie podekscytowani, że podjęliśmy się tego wyzwania wiele lat temu i nadal utrzymujemy system. Klient ma pewność, że ten obszar jego biznesu jest pod opieką. Zresztą jego kontrahenci zawsze mogą liczyć na nasze wsparcie w procesach integracyjnych bądź w sytuacjach niespodziewanych.