Integracja WooCommerce, IdoSell, Shopify i własnego sklepu z Mailfly

Dlaczego sklepy internetowe potrzebują ujednoliconego strumienia zdarzeń e-commerce

Skuteczny e-mail marketing w handlu elektronicznym przestał polegać na wysyłaniu tego samego poniedziałkowego newslettera do wszystkich adresów zgromadzonych w bazie. Nowoczesny sklep internetowy musi reagować w czasie rzeczywistym na konkretne zachowania kupującego: obejrzenie karty produktu, dodanie wariantu rozmiarowego do koszyka, przejście do formularza dostawy, opłacenie zamówienia lub dokonanie zwrotu. Gdy dane te docierają do systemu wysyłkowego z kilkugodzinnym opóźnieniem albo w niekompletnym formacie, wiadomości automatyczne trafiają do klienta za późno i tracą swój potencjał sprzedażowy.

Największym wyzwaniem technicznym dla właścicieli sklepów oraz agencji obsługujących różne platformy jest odmienna struktura danych w każdym silniku sklepowym. WooCommerce operuje na hakach akcji PHP i tabelach WordPressa, IdoSell wykorzystuje rozbudowane struktury w swoim panelu administracyjnym, Shopify komunikuje się przez GraphQL i webhooki JSON, a dedykowane sklepy headless na Next.js posiadają własne modele koszyka. Budowanie osobnej logiki automatyzacji pod każdy z tych formatów prowadzi do chaosu i ciągłych błędów w szablonach wiadomości.

Mailfly rozwiązuje ten problem poprzez wprowadzenie ujednoliconego, kanonicznego modelu zdarzeń e-commerce, do którego tłumaczone są sygnały ze wszystkich podłączonych platform. Niezależnie od tego, czy sklep pracuje na WooCommerce, IdoSell, Shopify czy autorskim backendzie Node.js, do silnika reguł Mailfly trafia zawsze tak samo ustrukturyzowany obiekt zdarzenia. Dzięki temu marketer buduje scenariusz ratowania koszyka lub sekwencję po zakupie tylko raz, korzystając ze spójnych zmiennych produktowych, cenowych i walutowych.

• Jeden wspólny standard danych dla WooCommerce, IdoSell, Shopify oraz dedykowanych aplikacji storefrontowych Next.js i React.
• Przetwarzanie sygnałów zakupowych w czasie rzeczywistym umożliwiające reakcję w ciągu sekund od działania klienta w sklepie.
• Spójne zmienne w edytorze szablonów (`items`, `totalGross`, `currency`, `recoveryUrl`) niezależnie od używanego silnika sklepowego.
• Eliminacja kosztownego utrzymywania osobnych skryptów parsujących dla każdej integracji w portfolio firmy lub agencji.

Siedem kanonicznych zdarzeń sklepowych w architekturze Mailfly

Cała logika automatyzacji, segmentacji behawioralnej oraz atrybucji przychodu w Mailfly opiera się na siedmiu precyzyjnie zdefiniowanych typach zdarzeń: `product.viewed`, `cart.updated`, `checkout.started`, `order.paid`, `order.cancelled`, `order.refunded` oraz `consent.updated`. Taki podział pokrywa pełny cykl życia klienta w sklepie internetowym, począwszy od pierwszego zainteresowania asortymentem i wyrażenia zgody marketingowej, przez proces kompletowania koszyka i płatności, aż po obsługę posprzedażową i ewentualne korekty finansowe.

Zdarzenie `product.viewed` rejestruje wyświetlenie konkretnej karty towarowej wraz z jej identyfikatorem SKU, nazwą, kategorią, adresem URL zdjęcia oraz aktualną ceną brutto, co pozwala uruchamiać kampanie przypominające o przeglądanych produktach. Zdarzenia `cart.updated` oraz `checkout.started` przenoszą pełną zawartość koszyka wraz z bezpośrednim linkiem powrotu do zakupów `recoveryUrl`, stanowiąc wyzwalacz dla wieloetapowych sekwencji ratowania porzuconych koszyków. Z kolei `order.paid` natychmiast zatrzymuje sekwencje przypominające i uruchamia komunikację posprzedażową oraz naliczenie przychodu.

Równie istotną rolę pełnią zdarzenia korygujące `order.cancelled` oraz `order.refunded`, które dbają o czystość analityki finansowej i zatrzymują wysyłkę próśb o wystawienie opinii dla zamówień anulowanych lub zwróconych. Ostatnie zdarzenie, czyli `consent.updated`, synchronizuje w czasie rzeczywistym zmiany statusu zgód na komunikację e-mailową dokonane w koncie klienta w sklepie lub w okienku zapisu podczas finalizacji zamówienia. Każdy pakiet zawiera znacznik czasu ISO 8601, identyfikator sklepu oraz unikalny klucz zdarzenia.

• Pełny zestaw 7 zdarzeń: `product.viewed`, `cart.updated`, `checkout.started`, `order.paid`, `order.cancelled`, `order.refunded`, `consent.updated`.
• Przekazywanie kompletnej tablicy pozycji koszyka i zamówienia wraz ze zdjęciami, wariantami, ilościami oraz cenami jednostkowymi.
• Automatyczna korekta raportów przychodowych po odebraniu sygnału `order.cancelled` lub `order.refunded` ze sklepu.
• Natychmiastowa aktualizacja statusu subskrypcji po odebraniu zdarzenia `consent.updated` z formularza koszyka lub profilu klienta.

Natywna wtyczka WordPress i WooCommerce Mailfly Connect 0.3.5

Dla sklepów działających na najpopularniejszym w Polsce otwartym silniku e-commerce powstała dedykowana, lekka wtyczka WordPress oraz WooCommerce o nazwie Mailfly Connect w wersji `0.3.5`. W przeciwieństwie do przeładowanych modułów marketingowych, które spowalniają czas generowania strony TTFB poprzez ładowanie ciężkich skryptów na każdej podstronie, Mailfly Connect działa w oparciu o asynchroniczną kolejkę Action Scheduler oraz bezpośrednie haki serwerowe WooCommerce.

Wtyczka obsługuje pełną synchronizację katalogu produktowego wraz z produktami prostymi oraz wariantowymi (`variable products` i `product_variation`), przekazując do Mailfly dokładne atrybuty koloru, rozmiaru, stanu magazynowego, ceny regularnej oraz ceny promocyjnej. Podczas składania zamówienia moduł przechwytuje dane koszyka już w momencie wpisania adresu e-mail w formularzu zamówienia WooCommerce (zarówno w klasycznym shortcode, jak i w nowym Checkout Blocks), dzięki czemu sklep może odzyskiwać koszyki porzucone przed kliknięciem przycisku płatności.

Dodatkowo Mailfly Connect `0.3.5` automatycznie osadza w formularzu zamówienia pole wyboru zgody na newsletter zgodne z wymogami RODO oraz dyrektywy Omnibus, zapisując dokładny czas, adres IP oraz treść zaakceptowanego oświadczenia. Konfiguracja w panelu WordPress sprowadza się do wklejenia klucza API przestrzeni roboczej oraz sekretu podpisu wygenerowanego w Mailfly, a wbudowany ekran diagnostyczny pozwala jednym kliknięciem przetestować połączenie i zweryfikować status ostatnio wysłanych pakietów.

• Dedykowana wtyczka Mailfly Connect `0.3.5` zoptymalizowana pod kątem zerowego narzutu na szybkość ładowania sklepu WooCommerce.
• Pełna obsługa produktów prostych i wariantowych wraz z synchronizacją zdjęć, stanów magazynowych, kodów SKU oraz kategorii.
• Przechwytywanie porzuconych koszyków na etapie formularza zamówienia oraz generowanie jednoklikowego linku odtwarzającego koszyk.
• Asynchroniczna wysyłka zdarzeń w tle z mechanizmem automatycznego ponawiania prób w przypadku chwilowej niedostępności sieci.

Integracja IdoSell przez API Admin v8 Webhooks i obsługa strefy Europe/Warsaw

Polskie sklepy o dużym wolumenie sprzedaży bardzo często wybierają platformę SaaS IdoSell, która posiada własną, specyficzną architekturę komunikacji zewnętrznej. Mailfly oferuje natywny konektor dla IdoSell wykorzystujący standard `API Admin v8` oraz mechanizm powiadomień `Webhooks`, uwierzytelniany bezpiecznym tokenem w nagłówku `Authorization: Bearer` lub dedykowanym kluczem `X-API-KEY`. Dzięki temu każde utworzenie zamówienia, zmiana statusu płatności, anulowanie transakcji czy rejestracja nowego konta klienta trafia natychmiast do odpowiedniej przestrzeni roboczej.

Kluczowym detalem technicznym, na którym wykłada się wiele zagranicznych systemów integrowanych z IdoSell, jest prawidłowa interpretacja znaczników czasu. Panel IdoSell w wielu obiektach przekazuje daty zdarzeń i modyfikacji zamówień w lokalnej strefie czasowej `Europe/Warsaw` bez jawnego offsetu UTC w ciągu znaków, co przy zmianie czasu z zimowego CET (`+01:00`) na letni CEST (`+02:00`) potrafi przesunąć zegar automatyzacji o godzinę lub dwie. Parser IdoSell w Mailfly rozpoznaje strefę `Europe/Warsaw` i bezbłędnie konwertuje wszystkie daty do kanonicznego formatu UTC.

Konektor IdoSell pobiera również szczegółowe informacje o zamówionych pozycjach, kosztach dostawy, wybranych punktach odbioru oraz zastosowanych rabatach, mapując wewnętrzne statusy zamówień IdoSell na kanoniczne zdarzenia `order.paid`, `order.cancelled` oraz `order.refunded`. Właściciel sklepu nie musi pisać własnych skryptów pośredniczących na zewnętrznym serwerze ani płacić za drogie integratory pokroju Zapier czy Make rozliczane od każdego pojedynczego wywołania.

Natywne konektory dla WooCommerce, IdoSell, Shopify oraz własnych aplikacji webowych udostępnia narzędzie email odbierające zdarzenia koszykowe i zakupowe w czasie rzeczywistym.

• Bezpośrednia integracja z IdoSell `API Admin v8` oraz obsługa natywnych webhooków zamówień, klientów i statusów płatności.
• Uwierzytelnianie komunikacji za pomocą standardu `Bearer` oraz weryfikacja autentyczności pakietów przychodzących z serwerów IdoSell.
• Poprawna obsługa strefy czasowej `Europe/Warsaw` uwzględniająca czas zimowy i letni przy wyliczaniu opóźnień automatyzacji.
• Pełne mapowanie wielowalutowych zamówień IdoSell używanych w sprzedaży cross-border na rynki czeski, niemiecki czy rumuński.

Integracja Shopify przez OAuth 2.0, GraphQL Admin API i szyfrowanie AES-256-GCM

Sklepy działające na platformie Shopify oraz Shopify Plus korzystają z nowoczesnego procesu autoryzacji opartego na protokole `OAuth 2.0` oraz zapytaniach do `GraphQL Admin API`. Po wskazaniu domeny sklepu `*.myshopify.com` w panelu Mailfly właściciel zostaje przekierowany do ekranu zatwierdzenia uprawnień o minimalnym wymaganym zakresie (`read_products`, `read_orders`, `read_customers`, `read_checkouts`). Po pomyślnej wymianie kodu autoryzacyjnego na trwały token dostępowy system automatycznie rejestruje zestaw wymaganych subskrypcji webhooków.

Uzyskany token dostępowy Shopify oraz sekret wykorzystywany do sprawdzania nagłówka `X-Shopify-Hmac-Sha256` nigdy nie są zapisywane w bazie danych otwartym tekstem. Przed wykonaniem zapytania `INSERT` do tabeli integracji serwer Mailfly szyfruje poświadczenia algorytmem `AES-256-GCM` z uwierzytelnionym szyfrowaniem i unikalnym kluczem przestrzeni roboczej. Nawet w przypadku próby nieautoryzowanego odczytu zrzutu bazy danych klucze dostępowe do sklepu Shopify pozostają całkowicie bezużyteczne bez klucza głównego trzymanego w bezpiecznym środowisku wykonawczym.

Komunikacja z `GraphQL Admin API` pozwala na bardzo szybkie pobranie pełnego katalogu produktów wraz z kolekcjami, metapolami (`metafields`) oraz cenami w różnych walutach z modułu Shopify Markets. Jednocześnie strumień webhooków (`checkouts/create`, `checkouts/update`, `orders/paid`, `orders/cancelled`, `refunds/create`, `customers/update`) dostarcza do Mailfly zdarzenia w ułamku sekundy od akcji użytkownika w sklepie, zapewniając natychmiastowe wyzwalanie scenariuszy marketingowych.

• Bezpieczna autoryzacja sklepu Shopify w standardzie `OAuth 2.0` z zasadą minimalnych niezbędnych uprawnień odczytu danych.
• Wydajna synchronizacja katalogu, wariantów i kolekcji przez `GraphQL Admin API` z poszanowaniem limitów zapytań Shopify.
• Szyfrowanie tokenów dostępowych oraz sekretów webhooków algorytmem `AES-256-GCM` na poziomie bazy danych.
• Kryptograficzna weryfikacja każdego przychodzącego pakietu z Shopify za pomocą nagłówka `X-Shopify-Hmac-Sha256`.

Dedykowany konektor Next.js i React oparty o serwerowy Route Handler i podpis HMAC SHA-256

Coraz więcej szybko rosnących marek e-commerce oraz platform B2B rezygnuje z gotowych szablonów na rzecz architektury headless i własnego storefrontu zbudowanego w Next.js (App Router) oraz React. W takich wdrożeniach wysyłanie zdarzeń bezpośrednio z przeglądarki klienta do zewnętrznego API marketingowego jest poważnym błędem architektonicznym: przeglądarkowe blokery reklam (AdBlock, uBlock Origin, Brave Shield) wycinają nawet 30% ruchu, a jawny klucz API w kodzie JavaScript pozwala złośliwym botom na zatruwanie bazy fałszywymi koszykami.

Mailfly udostępnia wzorcową architekturę integracji dla Next.js oraz aplikacji Node.js opartą o serwerowy `Route Handler` (na przykład `/api/mailfly/events`), który przyjmuje akcje z komponentów React we własnej domenie pierwszej strony (`first-party`) i przekazuje je z serwera do API Mailfly. Taki przepływ całkowicie omija blokery skryptów śledzących w przeglądarkach oraz gwarantuje, że klucz prywatny przestrzeni roboczej nigdy nie opuszcza zmiennych środowiskowych serwera produkcyjnego.

Każde żądanie wysyłane z backendu Next.js do Mailfly jest zabezpieczone podpisem kryptograficznym `HMAC SHA-256` liczonym z dokładnego ciągu znaków `timestamp.rawBody`, gdzie `timestamp` to aktualny czas uniksowy w sekundach, a `rawBody` to niezmodyfikowana treść JSON żądania. Serwer Mailfly sprawdza najpierw, czy znacznik czasu nie odbiega od zegara serwerowego o więcej niż 300 sekund (ochrona przed atakami typu `replay attack`), a następnie porównuje wyliczony skrót kryptograficzny w stałym czasie wykonania (`timingSafeEqual`).

• Architektura `first-party` przez serwerowy `Route Handler` w Next.js odporna na blokery reklam i filtry prywatności w przeglądarkach.
• Podpis kryptograficzny `HMAC SHA-256` budowany według schematu `timestamp.rawBody` gwarantujący integralność i autentyczność danych.
• Okno tolerancji czasowej 300 sekund chroniące punkt końcowy API przed powtórnym odtworzeniem przechwyconych żądań sieciowych.
• Pełne typowanie TypeScript dla wszystkich siedmiu kanonicznych zdarzeń e-commerce ułatwiające pracę zespołom deweloperskim.

Trwała deduplikacja po eventId w tabeli commerce_events i odporność na ponowienia

Sieć internetowa oraz rozproszone systemy kolejkowania webhooków w platformach sklepowych działają w modelu dostarczania co najmniej jednokrotnego (`at-least-once delivery`). Oznacza to, że gdy Shopify, IdoSell lub WooCommerce wyśle powiadomienie o porzuconym koszyku albo opłaconym zamówieniu i z powodu chwilowego przeciążenia łącza nie otrzyma potwierdzenia `200 OK` w ciągu kilku sekund, ponowi wysyłkę tego samego pakietu. Bez solidnej deduplikacji ponowiony webhook uruchomiłby drugą identyczną sekwencję maili albo podwójnie naliczył przychód w raportach.

W Mailfly każde zdarzenie przychodzące ze sklepu musi posiadać deterministyczny identyfikator `eventId` (przekazany w nagłówku lub wyliczony z identyfikatora obiektu, typu zdarzenia i znacznika wersji w źródłowym sklepie). Zanim silnik reguł wykona jakąkolwiek akcję, system próbuje zapisać wiersz w tabeli `commerce_events` w bazie PostgreSQL 16, która posiada unikalny indeks złożony obejmujący `workspace_id` oraz `event_id`.

Dzięki konstrukcji `INSERT INTO commerce_events ... ON CONFLICT (workspace_id, event_id) DO NOTHING` deduplikacja odbywa się atomowo na poziomie transakcji bazodanowej, a nie w ulotnej pamięci podręcznej, która mogłaby zniknąć przy restarcie procesu. Jeżeli ten sam pakiet dotrze do serwera drugi, trzeci lub dziesiąty raz, baza danych natychmiast rozpoznaje duplikat, zwraca sklepowi status `200 OK` potwierdzający przyjęcie wiadomości i pomija ponowne uruchamianie wyzwalaczy automatyzacji.

• Trwały zapis każdego odebranego sygnału w tabeli `commerce_events` z unikalnym ograniczeniem na parę `(workspace_id, event_id)`.
• Atomowa ochrona przed duplikatami na poziomie silnika PostgreSQL 16 działająca niezawodnie przy równoległych żądaniach HTTP.
• Eliminacja ryzyka podwójnego wysłania maila transakcyjnego lub podwójnego zliczenia wartości zamówienia przy ponowieniach webhooków.
• Pełna historia surowych ładunków JSON (`payload`) dostępna w podglądzie diagnostycznym do szybkiego debugowania integracji.

Atomowe zatrzymywanie sekwencji ratowania koszyka w chwili opłacenia zamówienia

Nic nie psuje wizerunku profesjonalnego sklepu internetowego bardziej niż wysłanie klientowi wiadomości „Twój koszyk wciąż na Ciebie czeka, dokończ zamówienie z rabatem 5%” trzy godziny po tym, jak ten sam klient zapłacił już pełną kwotę BLIK-iem lub kartą płatniczą. Takie sytuacje zdarzają się nagminnie w systemach, które sprawdzają warunek zakupu tylko w momencie pierwotnego wejścia kontaktu do ścieżki automatyzacji, a potem bezwładnie odliczają czas w kolejce opóźnień.

W Mailfly scenariusz porzuconego koszyka oraz porzuconego procesu płatności (`checkout.started`) jest powiązany z atomowym mechanizmem anulowania aktywnych przebiegów w chwili odebrania zdarzenia `order.paid`. Gdy tylko ze sklepu spłynie potwierdzenie opłacenia zamówienia, procesor zdarzeń w jednej transakcji wyszukuje wszystkie oczekujące kroki automatyzacji ratunkowych przypisane do danego kontaktu lub identyfikatora koszyka i zmienia ich status na `cancelled_by_conversion`.

Dodatkowo, tuż przed fizycznym wygenerowaniem wiadomości i przekazaniem jej do transportu Amazon SES po upływie zaplanowanego opóźnienia (na przykład po 2 godzinach lub po 24 godzinach), worker wysyłkowy wykonuje jeszcze jedno ostateczne sprawdzenie stanu w bazie danych. Jeżeli w ułamku sekundy poprzedzającym wysyłkę odnotowano płatność, wycofanie zgody `consent.updated` lub ręczny wypis odbiorcy, wysyłka zostaje natychmiast zablokowana. Klient otrzymuje wyłącznie właściwe potwierdzenie zakupu oraz podziękowanie.

• Natychmiastowe wygaszenie wszystkich oczekujących kroków ratowania koszyka w momencie zarejestrowania zdarzenia `order.paid`.
• Podwójna weryfikacja warunków wykluczających: w chwili nadejścia webhooka oraz bezpośrednio przed przekazaniem maila do Amazon SES.
• Ochrona marży sklepu przed niepotrzebnym rozdawaniem kodów rabatowych osobom, które sfinalizowały już transakcję w pełnej cenie.
• Czytelny status `cancelled_by_conversion` w logach automatyzacji pokazujący marketerowi, ile koszyków domknęło się przed kolejnym krokiem.

Przyrostowa kolejka atrybucji przychodu i łączenie zamówień z kampaniami

Właściciel sklepu internetowego oraz agencja performance muszą dokładnie wiedzieć, które kampanie newsletterowe i które kroki automatyzacji generują realne pieniądze, a które jedynie nabijają puste kliknięcia. Obliczanie atrybucji w locie podczas otwierania zakładki z raportami przy milionach zdarzeń sklepowych powoduje ogromne obciążenie bazy danych i długie czasy ładowania wykresów. Z kolei przeliczanie wyników raz na dobę w nocy sprawia, że w trakcie gorących akcji promocyjnych marketer pracuje po omacku.

Mailfly wykorzystuje przyrostową kolejkę atrybucji przychodu, która przetwarza każde nowe zdarzenie `order.paid`, `order.cancelled` oraz `order.refunded` w ciągu kilku sekund od jego zapisania w tabeli `commerce_events`. Silnik atrybucji analizuje historię interakcji kupującego z wiadomościami e-mail w zdefiniowanym oknie czasowym, sprawdzając w pierwszej kolejności bezpośrednie kliknięcia w linki z kampanii lub automatyzacji (`last-touch click`), a w drugiej kolejności potwierdzone otwarcia wiadomości zgodnie z ustawieniami przestrzeni roboczej.

Po znalezieniu właściwego punktu styku system zapisuje powiązanie w tabeli atrybucji i przyrostowo aktualizuje zagregowane liczniki przychodu, liczby zamówień oraz średniej wartości koszyka dla konkretnej kampanii, wariantu testu A/B oraz pojedynczego kroku scenariusza. Jeżeli trzy dni później sklep przyśle zdarzenie `order.refunded` dla zwróconego towaru, kolejka atrybucji automatycznie pomniejszy wykazany wynik odpowiedniej kampanii o dokładną kwotę zwrotu w walucie zamówienia.

Po zsynchronizowaniu katalogu produktów oraz zgód marketingowych możesz uruchomić zarówno automatyzacje, jak i masowe wysyłanie maili do segmentów klientów o najwyższej wartości koszyka.

• Przyrostowe przeliczanie atrybucji w tle aktualizujące wyniki finansowe kampanii i automatyzacji niemal w czasie rzeczywistym.
• Priorytet dla twardych kliknięć prowadzących do sesji zakupowej z zachowaniem pełnej rozliczalności do konkretnego numeru zamówienia.
• Automatyczne odejmowanie kwot ze zdarzeń `order.cancelled` oraz `order.refunded` zapobiegające zawyżaniu raportowanego ROAS.
• Obsługa wielu walut jednocześnie z przypisaniem każdej transakcji do właściwego koszyka walutowego (`PLN`, `EUR`, `USD`, `GBP`).

Synchronizacja katalogu produktów, wariantów i dynamicznych bloków rekomendacji

Wiadomości e-mail osiągają najwyższą konwersję wtedy, gdy prezentują odbiorcy dokładne zdjęcia, aktualne nazwy oraz prawdziwe ceny produktów, którymi przed chwilą interesował się w sklepie. Ręczne wycinanie zdjęć w programie graficznym i wpisywanie cen do szablonu HTML przed każdą wysyłką jest czasochłonne i obarczone ryzykiem wstawienia nieaktualnej kwoty lub linku prowadzącego do wyprzedanego wariantu rozmiarowego.

Konektory e-commerce w Mailfly utrzymują w bazie danych zsynchronizowany katalog produktów i wariantów dla każdej przestrzeni roboczej klienta. Podczas edycji kreacji marketer może jednym kliknięciem wstawić blok produktowy, wyszukać towar po nazwie lub kodzie SKU i automatycznie zaciągnąć jego główne zdjęcie w wysokiej rozdzielczości, tytuł, cenę brutto, cenę sprzed promocji oraz bezpośredni adres URL karty produktu wraz z parametrami śledzącymi UTM.

W scenariuszach automatycznych, takich jak ratowanie koszyka (`cart.updated`, `checkout.started`) czy podziękowanie za zakup (`order.paid`), szablon wiadomości dynamicznie iteruje po tablicy pozycji przekazanych w ładunku zdarzenia. System renderuje dla każdego wiersza koszyka dokładną miniaturkę wybranego wariantu kolorystycznego, zamówioną liczbę sztuk oraz podsumowanie kwotowe. Ponadto stan magazynowy zsynchronizowany ze sklepem pozwala zablokować wysyłkę rekomendacji cross-sell dla produktów, których zapas w magazynie spadł do zera.

• Automatyczne zaciąganie zdjęć, tytułów, cen promocyjnych i linków produktowych bezpośrednio do edytora kreacji Mailfly.
• Dynamiczne renderowanie wielopozycyjnych koszyków zakupowych z uwzględnieniem wybranego rozmiaru, koloru oraz liczby sztuk.
• Kontrola dostępności magazynowej zapobiegająca promowaniu w mailach automatycznych towarów całkowicie wyprzedanych.
• Spójne formatowanie cen i symboli walut dopasowane do języka oraz rynku docelowego obsługiwanego sklepu internetowego.

Bezpieczna synchronizacja zgód marketingowych RODO i Omnibus między sklepem a bazą

W handlu elektronicznym klient może wyrazić lub wycofać zgodę na otrzymywanie komunikacji marketingowej w kilku różnych miejscach: w okienku pop-up na stronie głównej, w stopce sklepu, w formularzu koszyka podczas składania zamówienia albo w zakładce ustawień swojego konta po zalogowaniu. Brak dwukierunkowej, natychmiastowej synchronizacji tych oświadczeń pomiędzy silnikiem sklepowym a systemem wysyłkowym prowadzi do wysyłania reklam osobom, które już zrezygnowały z subskrypcji w panelu sklepu.

Zdarzenie `consent.updated` w Mailfly zostało stworzone po to, aby każda zmiana statusu zgody w WooCommerce, IdoSell, Shopify czy aplikacji Next.js była natychmiast odzwierciedlana w rekordzie kontaktu oraz w dzienniku zgód. Pakiet przesyłany ze sklepu zawiera nowy stan zgody (`granted` lub `revoked`), źródło formularza (na przykład `checkout_checkbox` lub `account_settings`), dokładny znacznik czasu oraz opcjonalny skrót treści regulaminu lub klauzuli informacyjnej widocznej dla użytkownika w chwili kliknięcia.

Jeżeli klient odznaczy zgodę marketingową w swoim profilu w sklepie internetowym, wysłane zdarzenie `consent.updated` ze statusem `revoked` natychmiast dopisuje adres do tabeli wykluczeń `suppression_entries` danej przestrzeni roboczej i zatrzymuje wszystkie aktywne ścieżki marketingowe. Równocześnie wiadomości czysto transakcyjne wynikające z realizacji umowy sprzedaży, jeśli są obsługiwane przez wydzielony strumień, zachowują pełną rozliczalność prawną w historii kontaktu.

• Natychmiastowa synchronizacja wycofania zgody ze sklepu do tabeli `suppression_entries` blokująca dalsze wysyłki promocyjne.
• Rejestrowanie pełnego dowodu zgody RODO obejmującego datę, godzinę, źródło zapisu oraz identyfikator wersji klauzuli.
• Obsługa modelu Double Opt-In dla zapisów z formularzy na stronie przy jednoczesnym rozpoznawaniu zweryfikowanych kupujących.
• Bezpieczne oddzielenie zgód na komunikację e-mailową od zgód na inne kanały kontaktu przekazywanych z silnika sklepowego.

Diagnostyka webhooków, logi błędów i testowanie ładunków JSON w panelu Mailfly

Nawet najlepiej zaprojektowana integracja może napotkać problemy podczas prac wdrożeniowych po stronie sklepu: programista zmieni strukturę obiektu w niestandardowym motywie, serwer hostingowy klienta zablokuje ruch wychodzący na firewallu albo wygaśnie token dostępowy po zmianie hasła administratora w IdoSell. W systemach pozbawionych przejrzystych narzędzi diagnostycznych wykrycie takiej awarii następuje dopiero po kilku tygodniach, gdy właściciel sklepu zauważa spadek przychodów z automatyzacji do zera.

Mailfly udostępnia w każdej przestrzeni roboczej rozbudowany monitor integracji oraz dziennik webhooków przychodzących. Operator widzi na żywo listę ostatnich wywołań HTTP wraz z kodem odpowiedzi (`200 OK`, `400 Bad Request`, `401 Unauthorized`, `422 Unprocessable Entity`), czasem przetwarzania w milisekundach, statusem weryfikacji podpisu kryptograficznego HMAC oraz dokładnym wskazaniem, które pole w przesłanym obiekcie JSON nie przeszło walidacji schematu.

Ponadto w panelu znajduje się wbudowany symulator zdarzeń e-commerce, który pozwala przetestować cały przepływ od odbioru pakietu `cart.updated` lub `order.paid` aż po wyrenderowanie szablonu z danymi testowego zamówienia bez konieczności wykonywania prawdziwych płatności na żywym sklepie. Jeżeli połączenie z WooCommerce, IdoSell lub Shopify przestanie przesyłać oczekiwane sygnały przez określony czas, system wyświetla wyraźne ostrzeżenie na głównym pulpicie konta oraz w Centrum agencyjnym.

• Podgląd na żywo surowych nagłówków HTTP, statusów weryfikacji podpisu HMAC oraz treści JSON ostatnich zdarzeń ze sklepu.
• Szczegółowe komunikaty walidatora wskazujące dokładną ścieżkę brakującego lub błędnie sformatowanego pola w pakiecie danych.
• Wbudowany generator zdarzeń testowych pozwalający sprawdzić działanie scenariuszy ratowania koszyka przed startem produkcyjnym.
• Automatyczne alerty o przerwaniu strumienia zdarzeń ze sklepu chroniące przed cichym wyłączeniem automatyzacji sprzedażowych.

Gotowe scenariusze automatyzacji uruchamiane po podpięciu sklepu do Mailfly

Podłączenie sklepu internetowego za pomocą natywnego konektora otwiera dostęp do zestawu sprawdzonych scenariuszy automatyzacji, które zaczynają generować powtarzalny przychód od pierwszego dnia po aktywacji. Zamiast budować skomplikowane drzewa decyzyjne od pustej kartki, marketer wybiera w bibliotece Mailfly gotowe schematy zoptymalizowane pod kątem siedmiu kanonicznych zdarzeń e-commerce i dostosowuje jedynie czas opóźnienia oraz warstwę wizualną kreacji.

Pierwszym filarem jest dwuetapowa lub trzyetapowa sekwencja ratowania porzuconego koszyka wyzwalana przez `checkout.started` lub `cart.updated`: pierwsza wiadomość wysłana po godzinie służy jako pomocne przypomnienie ze zdjęciami produktów i bezpośrednim linkiem powrotu do koszyka, natomiast druga wiadomość po 24 godzinach może zawierać dodatkowy argument sprzedażowy lub indywidualny kod rabatowy. Drugim filarem jest sekwencja po pierwszym zakupie (`order.paid`), która buduje zaufanie do marki, przekazuje instrukcję użytkowania produktu i po odpowiednim czasie proponuje zakup towarów uzupełniających.

Trzecim elementem jest automatyzacja typu `browse abandonment` oparta na zdarzeniu `product.viewed` dla zalogowanych lub rozpoznanych subskrybentów, którzy kilkukrotnie oglądali ten sam produkt z wysokiej półki cenowej, ale nie dodali go jeszcze do koszyka. Wszystkie te scenariusze korzystają z omówionego wcześniej atomowego wygaszania po zakupie, trwałej deduplikacji w `commerce_events` oraz przyrostowej atrybucji przychodu, tworząc spójną maszynę sprzedażową dla sklepu każdej wielkości.

• Wieloetapowe ratowanie porzuconych koszyków z dynamiczną listą produktów i bezpośrednim linkiem `recoveryUrl`.
• Sekwencje posprzedażowe, cross-sell oraz przypomnienia o uzupełnieniu zapasów wyzwalane zdarzeniem `order.paid`.
• Scenariusze przypominające o oglądanych produktach (`product.viewed`) z automatycznym wykluczeniem osób, które dokonały zakupu.
• Pełny pomiar wygenerowanej sprzedaży i liczby odzyskanych zamówień widoczny bezpośrednio przy każdym kroku automatyzacji.