Streszczenie
Marketing automation jest tak dobry, jak dane, które dostaje ze sklepu. Gdy sklep przekazuje zdarzenia z opóźnieniem, dubluje je, pomija zakup albo opisuje produkty zbyt ubogo, nawet dobrze zaprojektowany scenariusz wyśle wiadomość w złym momencie i do niewłaściwej osoby. Zainstalowanie modułu lub wtyczki jest początkiem integracji, a nie gwarancją jakości danych. Zanim zbudujesz scenariusze, sprawdź, jakie zdarzenia wysyła sklep, jak system rozpoznaje klientów i czy zgody marketingowe są synchronizowane, a potem przetestuj całą ścieżkę zakupową.
Sklep uruchamia scenariusz porzuconego koszyka. W edytorze wszystko się zgadza: wyzwalacz, opóźnienie, treść wiadomości, warunek wyjścia. Po tygodniu okazuje się, że część osób, które kupiły, nadal dostaje przypomnienia. W wiadomościach brakuje produktów. Ten sam klient występuje w bazie w dwóch profilach, a zdarzenia z niektórych zamówień w ogóle nie docierają do platformy. Marketer zaczyna „naprawiać” automatyzację: zmienia opóźnienia, dopisuje warunki, przepisuje treści.
Problem nie leży w scenariuszu. Zaczyna się wcześniej, w danych, które sklep przekazuje platformie, albo w sposobie, w jaki to robi. Ten tekst nie tłumaczy, czym jest marketing automation i jak go wdrożyć, bo to jest już opisane na tym blogu. Dotyczy tego, co musi działać pod spodem w sklepie na PrestaShop lub WooCommerce, żeby scenariusze mogły działać poprawnie.
Marketing automation zaczyna się wcześniej niż w narzędziu
Platforma marketing automation nie widzi sklepu. Widzi tylko to, co sklep jej przekaże: kto coś zrobił, co dokładnie zrobił i kiedy. Każdy scenariusz składa się z wyzwalacza, warunków i akcji, a wszystkie trzy elementy korzystają z tych danych. Wyzwalacz wymaga zdarzenia, warunek wymaga informacji o kliencie lub zamówieniu, a akcja wymaga treści, którą da się uzupełnić o produkty, ceny i imię.
Dlatego podłączenie narzędzia do sklepu nie jest tym samym co przygotowanie sklepu. Moduł, wtyczka, skrypt śledzący czy klucz API uruchamiają przepływ danych, ale nie mówią nic o tym, czy dane są kompletne, aktualne i jednoznaczne. Wdrożenia potrafią zatrzymać się właśnie tutaj: integracja „działa”, bo w platformie pojawiają się kontakty, a problemy wychodzą dopiero wtedy, gdy scenariusz trafia do prawdziwych klientów.
Jakich danych naprawdę potrzebuje marketing automation?
Platforma pracuje na trzech warstwach informacji i warto je rozdzielać, bo każda może zawieść osobno.
Dane o kliencie opisują, kim jest osoba. To identyfikator klienta, adres e-mail, status, historia zakupów, ich łączna wartość i zgody komunikacyjne. Pozwalają ustalić, czy w ogóle możemy do kogoś napisać i jaką ma historię ze sklepem.
Zdarzenia opisują, co ta osoba zrobiła: obejrzała produkt, dodała go do koszyka, usunęła z koszyka, rozpoczęła checkout, kupiła, zwróciła zamówienie albo założyła konto. Na zdarzeniach opiera się większość wyzwalaczy i warunków wyjścia.
Dane kontekstowe opisują szczegóły zdarzenia: konkretny produkt, kategorię, cenę, ilość, wartość koszyka, walutę, status zamówienia. Bez nich zdarzenie jest pustą etykietą. Wiadomo, że coś się stało, ale nie wiadomo co.
Ten podział ma znaczenie praktyczne. Sam profil klienta bez zdarzeń to lista adresów. Same zdarzenia, których nie da się przypisać do osoby, to statystyka ruchu. Dopiero wszystkie trzy warstwy razem dają materiał do segmentacji i personalizacji.
To są przykłady, a nie specyfikacja. Które z tych informacji faktycznie przekazuje dana integracja, zależy od jej wersji i konfiguracji sklepu. Trzeba to sprawdzić w dokumentacji i w samych danych, zamiast zakładać.
Zdarzenie to coś więcej niż informacja, że klient był w sklepie
Ta sama wiedza o kliencie może mieć trzy poziomy. System może wiedzieć, że użytkownik był w sklepie, i to wystarcza najwyżej do statystyki. Może wiedzieć, że oglądał produkt, i to już daje punkt zaczepienia. Najwięcej daje informacja, że oglądał konkretny produkt z określonej kategorii, dodał go do koszyka i nie dokonał zakupu. Z takiego opisu da się zbudować segment, wysłać wiadomość z właściwym produktem i wyłączyć klienta ze scenariusza w chwili zakupu.
Przy dodaniu do koszyka platforma powinna więc dostać informację, jaki to produkt, ile kosztuje i w jakiej ilości, a później także to, czy zamówienie z tym produktem zostało zrealizowane. Jakość tego opisu zależy od budowy sklepu. Jeśli na przykład te same buty w różnych rozmiarach mają być rozróżniane w danych, trzeba to uwzględnić w identyfikatorach produktów przekazywanych do platformy. To decyzja o strukturze katalogu, którą podejmuje się w sklepie, długo przed pierwszą wiadomością.
Najtrudniejszy moment: połączenie anonimowego użytkownika z klientem
Większość wizyt zaczyna się anonimowo. Platforma widzi identyfikator zapisany w przeglądarce, ale nie wie, kim jest ta osoba. Rozpoznanie następuje dopiero wtedy, gdy ktoś się zaloguje, założy konto, zapisze do newslettera albo poda adres e-mail w koszyku. Od tego, w którym punkcie ścieżki to się dzieje, zależy, ilu użytkowników scenariusz w ogóle będzie w stanie zidentyfikować. Positive User opisuje to ograniczenie w artykule o scenariuszach automatyzacji e-commerce: przypomnienie o koszyku nie dotrze do anonimowych odwiedzających.
Marketer nie musi znać mechaniki, ale powinien umieć odpowiedzieć na kilka pytań. W którym momencie anonimowy użytkownik staje się rozpoznanym kontaktem? Po czym system go identyfikuje: po adresie e-mail, po identyfikatorze klienta, a może po obu? Co dzieje się z wcześniejszą aktywnością po zalogowaniu i po zakupie, czy trafia na ten sam profil? Czy ten sam klient może powstać w bazie dwa razy, raz jako gość, raz jako zarejestrowany? I co się dzieje, gdy ktoś ogląda ofertę na telefonie, a kupuje na laptopie?
Skutek braku odpowiedzi jest jeden. Jeżeli system nie wie, że dwa zestawy danych należą do tej samej osoby, segmentacja i personalizacja działają na niepełnym obrazie klienta. Klient z koszykiem na telefonie i zamówieniem na laptopie może dostać przypomnienie o czymś, co już kupił.
Zgody marketingowe też są danymi
Zgodę łatwo potraktować jak sprawę formalną, ale w systemie to taka sama dana jak adres e-mail. Powinna być zapisana, przekazana i aktualizowana. Sprawdzić trzeba kilka rzeczy: czy zapis do newslettera i zgoda zaznaczona w checkoucie trafiają do platformy, czy wycofanie zgody wraca do sklepu, czy zgody na różne kanały są rozróżniane, jeśli wymaga tego prawo lub polityka firmy, i czy kolejne zamówienie nie nadpisze wycofanej zgody starą wartością. Ostatni przypadek jest zdradliwy, bo wynika wyłącznie z kierunku synchronizacji, a nie z tego, że ktoś popełnił błąd w konfiguracji.
Zakres wymaganych zgód i ich forma to pytanie do prawnika, nie do integratora. Zadaniem technologii jest to, żeby decyzja klienta była widoczna wszędzie, gdzie zapada decyzja o wysyłce.
Scenariusz jako test danych
Porzucony koszyk, komunikacja po zakupie czy cross-sell nie są tu tematem, ale dobrze pokazują, co dane muszą umożliwić. Każdy scenariusz można potraktować jak test.
Przypomnienie o koszyku potrzebuje czterech rzeczy: informacji o powstaniu lub zmianie koszyka, rozpoznanego klienta (jeśli da się go zidentyfikować), zawartości koszyka i wiarygodnej informacji o sfinalizowaniu zakupu, która zatrzyma wysyłkę. Wiadomość po zakupie wymaga pewności, że zamówienie zostało naprawdę złożone, a nie tylko rozpoczęte. Cross-sell potrzebuje wiedzy o tym, co klient faktycznie kupił, a nie tylko co włożył do koszyka. We wszystkich trzech przypadkach scenariusz jest skutkiem danych. Jeśli nie potrafisz wskazać, skąd w sklepie pochodzi informacja potrzebna do któregoś z tych punktów, budowanie scenariusza jest przedwczesne.
Gotowa integracja to początek, nie koniec wdrożenia
Gotowe moduły i wtyczki są dobrym punktem wyjścia i nie ma powodu ich unikać. W praktyce zdarzają się trzy sytuacje.
W pierwszej gotowa integracja pokrywa potrzeby sklepu. Proces zakupowy jest standardowy, metody płatności popularne, a modyfikacji niewiele. Wdrożenie to wtedy głównie konfiguracja i testy, a dokładanie developmentu byłoby przesadą.
W drugiej integracja wystarcza, ale wymaga dostosowania. Chodzi na przykład o zmapowanie statusów zamówień, ustalenie, w którym momencie zdarzenie ma być zliczane, uzupełnienie danych produktowych albo wybór sposobu przekazywania zdarzeń, na przykład przez moduł lub przez Google Tag Managera. Nawet w jednym sklepie bywa więcej niż jedna droga, a wybór wpływa na to, które dane i kiedy trafiają do platformy.
W trzeciej model biznesowy lub niestandardowe procesy wymagają dodatkowej integracji albo pracy developerskiej. Dotyczy to na przykład rozbudowanego checkoutu, zamówień B2B z własnym obiegiem akceptacji czy zamówień przyjmowanych poza stroną sklepu.
Żadna z tych sytuacji nie jest lepsza od pozostałych. Trzeba ustalić, w której jest dany sklep, a da się to zrobić dopiero po sprawdzeniu danych, nie po przeczytaniu opisu wtyczki. Przy wdrożeniach i rozwoju sklepów PrestaShop punktem wyjścia jest zwykle odwzorowanie ścieżki zakupowej i listy zachowań klientów, które biznes chce wykorzystać. Dopiero potem wybiera się sposób integracji.
Co najczęściej psuje automatyzację po stronie sklepu
Poniższe problemy mają wspólną cechę: żadnego z nich nie widać w edytorze scenariuszy. Wszystkie wynikają z tego, co dzieje się w sklepie.
Podwójne zdarzenia. Jedno działanie klienta zostaje zgłoszone dwa razy, na przykład gdy ten sam zakup raportuje i moduł, i osobny tag w Google Tag Managerze, albo gdy klient odświeża stronę podziękowania. Dla platformy to dwa zakupy. Scenariusz może więc zareagować dwukrotnie, a statystyki będą zawyżone.
Zakup, który nie dociera albo dociera w złym momencie. Platforma widzi koszyk, ale nie dostaje poprawnej informacji o zakupie. Często wynika to z tego, kiedy sklep uznaje zamówienie za złożone. Według dokumentacji WooCommerce zamówienie zaczyna jako oczekujące na płatność, a przy opóźnionych metodach płatności, takich jak polecenie zapłaty SEPA, może przejść przez status wstrzymania, zanim trafi do realizacji. PrestaShop pozwala edytować statusy i tworzyć własne, z ustawieniem, czy oznaczają zamówienie jako zatwierdzone lub opłacone. Jeśli integracja nie odzwierciedla tego tak, jak przyjął sklep, klient, który zapłacił, może dostać przypomnienie o koszyku, a ten, który jeszcze nie zapłacił, podziękowanie.
Niepełne dane produktowe. Platforma wie, że powstał koszyk, ale nie dostaje nazwy produktu, ceny, zdjęcia, adresu strony ani wariantu. Przypomnienie bez produktów niewiele przypomina, a segmentacja po kategoriach jest niemożliwa, bo kategorii nie ma w zdarzeniu. Personalizacja kończy się na imieniu.
Różne identyfikatory. Sklep rozpoznaje klienta po numerze, CRM po adresie e-mail, a narzędzie marketing automation po jeszcze innym kluczu. Gdy któryś klucz się zmieni albo jeden z systemów go nie zna, powstają duplikaty albo profile z kawałkiem historii. Ta sama osoba bywa wtedy jednocześnie „nowa” i „stała”.
Dane wysyłane z opóźnieniem. Platforma może przetwarzać zdarzenia od razu, ale jeśli sklep przekazuje je zbiorczo, na przykład zadaniem uruchamianym co jakiś czas, sygnał dociera, gdy intencja klienta już wygasła. Jest też gorsza wersja: klient w międzyczasie kupił, a scenariusz jeszcze o tym nie wie.
Customowy checkout. Standardowa integracja zakłada standardowy proces zamówienia. Gdy sklep ma własne kroki albo moduły zmieniające koszyk i kasę, część zdarzeń może w ogóle nie powstawać. WooCommerce opisuje to przy blokowym koszyku i kasie: rozszerzenia, które dodają własne elementy w tych miejscach, zwykle wymagają dodatkowej pracy integracyjnej, a zgodność z blokami jest oznaczana na stronie każdego rozszerzenia. To dobry przykład na to, że instalacja wtyczki nie zawsze kończy wdrożenie. Sklep po zmianie kasy wygląda i działa poprawnie, a dane po cichu przestają płynąć.
Zanim uruchomisz scenariusz, przejdź całą ścieżkę klienta
Zanim scenariusz trafi do całej bazy, warto przejść ścieżkę klienta od początku do końca, tak jak zrobiłby to prawdziwy kupujący:
- wejście na stronę produktu,
- dodanie produktu do koszyka,
- rozpoczęcie checkoutu,
- zakup,
- sprawdzenie, jakie dane trafiły do platformy,
- sprawdzenie, czy zakup zatrzymał scenariusz.
Sam fakt, że mail przyszedł, niczego nie dowodzi. Trzeba ustalić, dlaczego został wysłany, na podstawie jakich danych, czy kontakt został poprawnie zakwalifikowany i które zdarzenie zatrzymało scenariusz. Wartościowa jest ścieżka powtórzona w kilku wariantach: jako gość i jako zalogowany klient, z płatnością natychmiastową i opóźnioną, na telefonie i na komputerze, z wycofaniem zgody po drodze. Na początek wystarczy przejść sklep jako klient i sprawdzić w panelu platformy, czy pojawia się profil odwiedzającego i zdarzenia produktowe, a potem porównać je z tym, co widać w zamówieniu w sklepie.
Test trzeba powtarzać. Zmiana checkoutu, nowy moduł płatności czy aktualizacja motywu mogą zmienić sposób, w jaki sklep wysyła zdarzenia, choć nikt nie dotykał samej integracji. Dlatego w procesie wdrożenia marketing automation sprawdzenie poprawności zbierania danych jest etapem poprzedzającym projektowanie scenariuszy, a po większych zmianach w sklepie ścieżka wraca do przeglądu.
Marketing i development muszą uzgodnić język
Marketer mówi: „chcemy automatyzację dla klientów zainteresowanych kategorią X”. Developer musi przełożyć to na dane. Co znaczy „zainteresowany”? Jedno wyświetlenie produktu z tej kategorii? Trzy wizyty? Dodanie produktu do koszyka? Wcześniejszy zakup? I w jakim okresie: wczoraj, w ostatnim tygodniu, w ostatnich 90 dniach? Każda odpowiedź prowadzi do innego zdarzenia, innych danych i innego segmentu, a bez uzgodnienia każda ze stron założy coś innego.
To samo dotyczy pojęć, które wydają się oczywiste. „Zakup” to złożenie zamówienia czy potwierdzona płatność? „Porzucony koszyk” liczy się po ilu minutach i czy dotyczy też klienta, którego nie udało się rozpoznać? Kto jest „aktywnym klientem”?
Automatyzacja zaczyna się więc często nie od konfiguracji scenariusza, lecz od precyzyjnego zdefiniowania zachowania, które ma być mierzone. Pomaga krótka lista ustaleń: jak nazywa się zdarzenie, w którym momencie jest wysyłane, jakie dane mu towarzyszą i kto odpowiada za jego poprawność. Najpierw określa się scenariusz biznesowy, a dopiero potem decyduje, jakie zdarzenia są do niego potrzebne, nie odwrotnie.
PrestaShop i WooCommerce: inne wdrożenie, te same zasady
Obie platformy da się dobrze przygotować pod marketing automation i żadna nie ma tu z góry przypisanej przewagi. Różni je to, gdzie szukać i co konfigurować, a nie to, czego potrzeba.
W WooCommerce warto sprawdzić statusy zamówień, bo decydują o tym, kiedy zamówienie jest oczekujące, wstrzymane albo w realizacji, oraz to, czy kasa działa w wersji klasycznej, czy blokowej, bo od tego zależy, które rozszerzenia mogą reagować na zdarzenia. W PrestaShop statusy zamówień można edytować i rozszerzać o własne, z ustawieniem, czy oznaczają zamówienie jako zatwierdzone, opłacone lub wysłane, więc to sklep decyduje, który status odpowiada zakupowi. Dla definicji zakupu ma to takie samo znaczenie.
Zasady są wspólne. Zdarzenia muszą być kompletne, klient rozpoznawany, zgody zsynchronizowane, a integracja przetestowana na realnej ścieżce zakupowej. Oficjalna dokumentacja platformy i aktualna dokumentacja wybranej integracji są lepszym punktem wyjścia niż opinie o tym, która z nich „lepiej nadaje się” do marketing automation.
Test gotowości sklepu na marketing automation
Poniższe pytania da się zadać zespołowi w jedno popołudnie. Odpowiedź „nie wiem” też jest odpowiedzią.
- Czy platforma dostaje informację o zakupie zaraz po jego dokonaniu i czy wiemy, który status zamówienia uznajemy za zakup?
- Czy wie, jakie produkty są w koszyku, wraz z ceną i ilością?
- Czy zakup zatrzymuje klienta w scenariuszu porzuconego koszyka?
- Czy po zalogowaniu lub zakupie wcześniejsze zachowania użytkownika łączą się z jego profilem?
- Czy ten sam klient może powstać w bazie więcej niż raz?
- Czy wycofanie zgody wraca do sklepu i czy kolejne zamówienie jej nie nadpisze?
- Czy umiemy sprawdzić, jakie dokładnie dane są wysyłane przy konkretnym zdarzeniu?
- Czy integracja została przetestowana na realnej ścieżce zakupowej, także z płatnością opóźnioną i na telefonie?
- Czy po zmianie checkoutu, płatności albo wdrożeniu nowego modułu testujemy zdarzenia ponownie?
Jeśli kilka odpowiedzi brzmi „nie wiem”, przed kolejnym scenariuszem potrzebny jest audyt danych. Jeśli większość brzmi „tak”, scenariusze można budować z dużo większą pewnością.
Jak wygląda to w Positive User
W Positive User dane ze sklepu stają się profilem klienta, segmentami i scenariuszami, więc wszystko, co opisano wyżej, przekłada się wprost na to, co da się zbudować.
Platforma ma integracje ze sklepami, w tym z PrestaShop i WooCommerce. W przypadku PrestaShop opis integracji wskazuje na śledzenie interakcji z produktami, odzyskiwanie porzuconych koszyków, wiadomości po zakupie i budowanie profili klientów. Kreator ścieżek działa na danych sklepu i korzysta z nich w warunkach oraz warunkach wyjścia, na przykład po to, żeby po zakupie przełączyć klienta na ścieżkę po-zakupową.
Po stronie platformy platforma danych klienta łączy dane o zachowaniu, historii zakupów i zaangażowaniu w jednym profilu, oferuje automatyczną deduplikację kontaktów i zarządzanie zgodami. Segmenty aktualizują się wraz ze zmianą zachowań klientów. Im pełniejsze zdarzenia i dokładniejsze rozpoznanie klienta, tym precyzyjniej platforma może zdecydować, kto i kiedy dostanie wiadomość. Opis integracji nie zastępuje jednak testu ścieżki klienta, dlatego warto go przejść bez względu na wybraną integrację.
FAQ
Technologia i automatyzacja muszą być projektowane razem
Marketing nie wykorzysta danych, których technologia nie dostarcza. Technologia nie powinna zbierać danych, nie wiedząc, do czego biznes zamierza ich użyć. Zwykle każda ze stron zaczyna od własnego końca: marketer od scenariusza, developer od integracji. Spotykają się dopiero wtedy, gdy coś przestaje działać.
Najlepszego scenariusza nie naprawi się copywritingiem, jeśli system podejmuje decyzje na podstawie złych danych. Projektowanie automatyzacji nie zaczyna się więc w edytorze scenariuszy. Zaczyna się od wspólnej odpowiedzi na dwa pytania: jakie zachowanie klienta chcemy rozpoznawać i co ma zrobić system, gdy do niego dojdzie?
Sprawdź dane, zanim uruchomisz automatyzację
Jeśli Twój sklep jest już połączony z narzędziem marketing automation, zacznij od testu ścieżki klienta z tego artykułu. Jeśli dopiero planujesz wdrożenie, załóż bezpłatne konto w Positive User i zobacz, jak dane ze sklepu układają się w profil klienta.
Gdy test pokaże luki w danych albo sklep wymaga dostosowania, zespół Woohoo pomoże zaplanować audyt danych i prace techniczne po stronie PrestaShop lub WooCommerce.
