Co się stanie, gdy na milion adresów, na które wyślemy mailing reklamowy, połowa będzie już dawno nieaktywna? Zmarnujemy połowę czasu w jego wysyłanie, ale przede wszystkim open rate takiego mailingu będzie o połowę niższy. Jak takiemu marnotrawstwu zapobiec?
Konsekwencją wysłania maila na nieprawidłowy adres (np. skrzynka zapełniona lub zlikwidowana po odejściu pracownika, domena wygasła itp.) jest otrzymanie zwrotki - czyli maila, który w treści będzie miał opis błędu, który wystąpił.
Zwrotki takie można wykorzystać do poprawy wyników przyszłych mailingów
Konstruując grupy odbiorców do kolejnych mailingów, można bowiem usuwać z nich te adresy, dla których poprzednio okazało się, iż np. domena odbiorcy wygasła.
Niestety obróbka takich zwrotek na większą skalę jest dość nietrywialna z uwagi na 5 głównych utrudnień:
- istnieje przynajmniej kilkadziesiąt różnych typów problemów, które należy obsłużyć - można je generalnie podzielić na dwie grupy: problemy tymczasowe, które można zignorować, oraz problemy stałe (np. firma się zamknęła i domena już nie istnieje), w przypadku których adres odbiorcy można usunąć z bazy
- samą zwrotkę możemy dostać od razu, albo po kilku godzinach, albo choćby po tygodniu od wysłania maila - zależnie od typu problemu - dlatego też przegląd zwrotek należy robić cyklicznie i niekoniecznie w kontekście konkretnego mailingu (dużo sensowniej jest robić to globalnie np. 3-4x dziennie)
- w niektórych sytuacjach serwer wysyła kilka zwrotek "tymczasowych", aby w końcu wysłać jedną "ostateczną"
- różne serwery poczty dla tych samych funkcjonalnie sytuacji stosują całkiem różne komunikaty błędów, a niektóre dodatkowo stosują w takich komunikatach html i formatowanie - aby to wszystko rozpoznać, należy użyć kilkuset wyrażeń regularnych
- powyżej pewnej ilości maili w jednym folderze, skrzynka IMAP zaczyna działać coraz wolniej (zwrotki trzeba więc przetwarzać w miarę na bieżąco i przenosić do kolejnych podfolderów)
Z powodu tych utrudnień, bardzo ciężko sensownie operować bezpośrednio na zwrotkach jako takich.
Jak to robimy w LegalnyMailing.pl?
Rozwiązanie, jakie stworzyliśmy swego czasu w potrzeby serwisu LegalnyMailing.pl, w języku PHP z użyciem:
- rozszerzenia php-imap, pozwalającego na dostęp do skrzynki IMAP i iteracyjne przetwarzanie maili
- frameworka Klim Framework, dostarczającego uniwersalny interfejs do komunikacji z bazami danych, w tym wrapper do w/w rozszerzenia php-imap, pozwalający na iterowanie po folderze IMAP w podobny sposób, jak po wyniku zapytania bazodanowego
- biblioteki MIME Parser autorstwa Manuela Lemosa, służącej do dekodowania nagłówków przetwarzanych zwrotek
rozwiązanie to działa następująco:
- przetwarza kolejno zwrotki z folderu głównego skrzynki IMAP (lub wskazanego folderu), generując plik CSV zawierający 3 pola: datę zwrotki, adres mailowy, którego ona dotyczy, oraz komunikat błędu (całość w jednej linii)
- pliki CSV są kopiowane z serwera poczty na serwer, na którym odbywa się dalsza obróbka danych
- w kolejnym etapie pliki CSV są następnie przepisywane na zapytania INSERT i importowane do bazy danych MySQL
- klasyfikator zwrotek w języku SQL dzięki ponad 220 klauzul LIKE z różnymi wzorcami komunikatów dopasowuje adekwatny typ błędu:
- odbiorca nie istnieje (konto zostało zlikwidowane)
- domena wygasła
- tymczasowy problem z konfiguracją jakiegoś elementu po stronie odbiorcy
- błąd tymczasowy, ale mail był kolejkowany zbyt długo i próba jego doręczenia została zakończona
- przekroczona quota na skrzynce odbiorcy
- wykryto spam
- adres jest "unroutable" mimo iż domena istnieje (tutaj sposób obsługi zależy od ustawień DNS, należy sprawdzić manualnie)
- na końcu ze wszystkich otrzymanych dotychczas zwrotek permanentnych generowany jest plik tekstowy z listą adresów, które w dalszych procesach obróbki danych do kolejnych mailingów, należy każdorazowo odsiewać z baz adresowych
Integracja z dotychczasowymi rozwiązaniami
Całość opisanego rozwiązania może współpracować z dowolną aplikacją do obsługi mailingów (np. AkoMail). Przykładowe polecenie, które spina Twój dotychczasowy proces przygotowywania baz z powyższym plikiem:
cat in.txt |grep -vixFf blacklist.txt >out.txt
gdzie:
- in.txt i out.txt to konstruowana lista adresów (pliki można podmienić na potoki bezpośrednio między procesami realizującymi kolejne etapy większego procesu, a powyższe rozwiązanie wpiąć na dowolnym etapie)
- blacklist.txt to wspomniany wyżej plik tekstowy z finalną listą adresów do odfiltrowania
Zakup rozwiązania
Rozwiązanie sprzedawane jest w postaci kompletu skryptów (Bash, PHP, SQL), podzielonego na dwie główne części - tak aby część pierwsza (zamiana zwrotek na CSV) mogła działać bezpośrednio na serwerze IMAP, a części kolejne bezpośrednio na serwerze, na którym prowadzona jest obróbka baz adresowych. Podział taki jest najbardziej optymalny ze względu na brak dodatkowych narzutów czasowych na komunikację sieciową ze zdalnym serwerem IMAP.
Wymagania techniczne:
- serwer poczty - Courier IMAP, dostęp ssh, działający pełny linuxowy userland, a nie tylko busybox, zainstalowany PHP z modułem php-imap (albo dostęp root)
- serwer roboczy - dowolny Debian/Ubuntu posiadający jeszcze działające wsparcie i możliwość instalowania nowych pakietów, dostęp root lub zainstalowana baza danych MySQL/Percona oraz PHP w dowolnej wersji
Cena:
- komplet skryptów w postaci as-is - 3000 zł netto
- dodatkowa usługa wdrożenia całości (na infrastrukturze spełniającej w/w wymogi) - 120 zł/h netto, minimum 2000 zł netto