Inxmail dla TYPO3

Inxmail to platforma newslettera enterprise, która natywnie integruje się z redakcjami TYPO3

Firmy z ponad 50.000 odbiorców newslettera, ścisłymi wymaganiami zgodności i istniejącym serwisem TYPO3 stają przed konkretną decyzją: Mailchimp z przetwarzaniem danych w USA i ryzykiem RODO, czy europejskie rozwiązanie integrujące się bezpośrednio z istniejącą infrastrukturą treści. Inxmail Professional to to rozwiązanie. Serwery w Niemczech, certyfikowane przetwarzanie danych i rozszerzenie TYPO3, które steruje listami subskrybentów, szablonami i kampaniami bezpośrednio z CMS. Dla polskich firm oznacza to zgodność z RODO i przetwarzanie danych na terenie UE, zgodne z wymaganiami UODO.

Rozszerzenie TYPO3 synchronizuje zapisy dwukierunkowo: nowi subskrybenci z formularzy TYPO3 automatycznie lądują w listach Inxmail, a wypisania w Inxmail są odzwierciedlane z powrotem do TYPO3. Dla zespołów marketingu oznacza to: jedno źródło danych, żadnych ręcznych eksportów, żadnego ryzyka przestarzałych list. W praktyce eliminuje to najczęstszy błąd przy wysyłce newslettera: wysyłkę do przestarzałej listy odbiorców zawierającej już wypisane kontakty.

Typowe scenariusze zastosowań obejmują B2B newsletter, maile transakcyjne i komunikację wydarzeń

Głównym scenariuszem jest klasyczny newsletter B2B dla firm z 10.000 do 500.000 odbiorców. Redakcja pielęgnuje treści w TYPO3, rozszerzenie automatycznie przenosi teasery i linki do szablonów Inxmail. Osoby odpowiedzialne za marketing segmentują odbiorców według branży, regionu lub zainteresowań i wysyłają warianty docelowe dla grup. Współczynniki otwarć i dane kliknięć wracają przez API do backendu TYPO3, dzięki czemu redakcja widzi wydajność poszczególnych artykułów.

Drugi scenariusz: maile transakcyjne wyzwalane przez akcje użytkownika na stronie. Potwierdzenie rejestracji, link do pobrania lub potwierdzenie zamówienia nie są wysyłane przez lokalny serwer pocztowy, lecz przez infrastrukturę Inxmail z gwarantowaną dostarczalnością. SPF, DKIM i DMARC są w Inxmail skonfigurowane z góry, co znacznie poprawia dostarczalność w porównaniu do standardowego PHP-Mailera.

Trzeci scenariusz: komunikacja wydarzeń dla firm regularnie organizujących targi, webinary lub konferencje. Zaproszenia, przypomnienia i follow-up są konfigurowane jako kampanie oparte na triggerach w Inxmail i wyzwalane przez zdarzenia w TYPO3, na przykład przez rejestrację w formularzu powermail. Logika triggerów pozwala też na bardziej złożone sekwencje: zaproszenie cztery tygodnie wcześniej, przypomnienie tydzień wcześniej, potwierdzenie uczestnictwa dzień przed i prośba o feedback dwa dni po.

Architektura techniczna łączy formularze TYPO3 frontendowe z REST-API Inxmail

Rozszerzenie wykorzystuje REST-API Inxmail do komunikacji między TYPO3 a Inxmail Professional. W rdzeniu integracja składa się z trzech modułów: usługi Subscriber-Sync, modułu Template-Sync i triggera kampanii.

Subscriber-Sync działa przez zadanie Scheduler, które w konfigurowalnych interwałach (typowo: co 5 do 15 minut) uzgadnia nowe zapisy, zmiany i wypisania między TYPO3 a Inxmail. Kierunek synchronizacji jest konfigurowalny: jednokierunkowy (TYPO3 do Inxmail) lub dwukierunkowy. Przy synchronizacji dwukierunkowej konflikty są rozwiązywane przez znaczniki czasu, gdzie zwycięża nowszy rekord.

Moduł Template-Sync przenosi obszary stron TYPO3 jako treści newslettera. Redaktorzy oznaczają elementy treści w backendzie TYPO3 jako “Newsletter-ready”, a rozszerzenie renderuje te elementy w szablonie HTML kompatybilnym z Inxmail. Oszczędza to podwójnej pielęgnacji treści strony i treści newslettera.

Autentykacja odbywa się przez klucze API konfigurowane w Extension Manager TYPO3. Wszystkie wywołania API idą przez HTTPS, a rozszerzenie loguje każdą operację synchronizacji w dedykowanej tabeli logów, co jest istotne dla audytów zgodności. Dane logu zawierają znaczniki czasu, liczbę zsynchronizowanych rekordów, błędy i ostrzeżenia, dzięki czemu podczas audytu można wykazać, kiedy i jakie dane zostały przeniesione.

Częste problemy dotyczą konfliktów sync, renderowania szablonów i limitów API

Dominującym tematem supportu jest konflikt synchronizacji przy sync dwukierunkowym. Gdy subskrybent jest jednocześnie zmieniany zarówno w TYPO3, jak i w Inxmail, mogą wystąpić niespójności danych. Rozwiązanie: jasno zdefiniować kierunek sync. W 90% przypadków TYPO3 jest wiodącym źródłem danych podstawowych, a Inxmail jest wiodącym źródłem danych zaangażowania (otwarcia, kliknięcia, bounces).

Drugi problem: różnice w renderowaniu HTML między frontendem TYPO3 a klientem e-mail. Element treści, który na stronie wyświetla się poprawnie, w Outlooku lub Gmailu może wyglądać inaczej. Rozszerzenie tłumaczy wprawdzie HTML TYPO3 na inline-CSS dla kompatybilności e-mail, ale złożone układy z Flexbox lub Grid muszą być uproszczone dla klientów e-mail. Zalecamy testowanie szablonów newslettera osobno, idealnie narzędziem takim jak Litmus lub Email on Acid.

Trzeci problem: limity API przy dużych operacjach sync. Kto synchronizuje 100.000 subskrybentów jednocześnie, może osiągnąć limit API Inxmail. Rozwiązanie: batch-based sync z konfigurowalną wielkością paczki (zalecane: 500 rekordów na wywołanie API) i wykładnicze backoff przy odpowiedziach rate-limit.

TYPO3 v12 jest wspierane przez oficjalne rozszerzenie, v13 wymaga weryfikacji

Inxmail aktywnie pielęgnuje rozszerzenie TYPO3, ponieważ rynek TYPO3 jest istotnym kanałem sprzedaży Inxmail Professional. Aktualna wersja obsługuje TYPO3 v11 i v12. Przy upgrade z v10 na v12 trzeba przede wszystkim dostosować konfiguracje zadań Scheduler, ponieważ TYPO3 v12 zmienił API Schedulera. Autentykacja API i Subscriber-Sync pozostają stabilne.

Dla TYPO3 v13 jeszcze nie ma oficjalnego wydania. Firmy planujące upgrade na v13 powinny wcześnie skonsultować dostępność z Inxmail, ponieważ integracje newslettera enterprise należą do najbardziej krytycznych zależności przy upgrade CMS. Jako rozwiązanie przejściowe integracja może być zrealizowana przez własną warstwę Middleware, która bezpośrednio odwołuje się do API Inxmail bez używania rozszerzenia. Gosign wdrożył to rozwiązanie dla klientów, którzy chcieli migrować na v13 zanim oficjalne rozszerzenie było dostępne. Własna warstwa jest też tańsza w utrzymaniu, ponieważ odwołuje się tylko do faktycznie używanych endpointów API i nie wlecze nieużywanych funkcji.