FAQ - Integracje - najczęściej zadawane pytania

Spis treści

Jaka integracja do marketingu (SalesManago/GetResponse/User.com) ma najwięcej możliwości/przesyła najwięcej danych?
Możliwości integracji z GetResponse - jakie dane przekazujemy do serwisu i jak można ich użyć?
GetResponse vs GetResponse MAX - różnice w integracji z Caterings
Możliwości integracji z SalesManago - jakie dane przekazujemy do serwisu i jak można ich użyć?
Czy zdarzenie CART w Salesmanago jest u nas “zamówieniem” czy “koszykiem”?
Możliwości integracji z User.com - jakie dane przekazujemy do serwisu i jak można ich użyć?
Która z integracji śledzi porzucone koszyki?
Która z integracji działa dwustronnie - tzn. jeśli klient odznaczy zgodę w Caterings przesyłane jest to integracji i w drugą stronę - jeśli klient wypisze się z listy poprzez np. maila z integracji przesyła się to do nas?
Jak dokładnie działa przycisk synchronizacji?
Użycie przycisku "Synchronizuj" w GetResponse.

1. Jaka integracja do marketingu (SalesManago/GetResponse/User.com) ma najwięcej możliwości/przesyła najwięcej danych?

User.com – Potęga twardych danych E-commerce i Subskrypcji

Ta integracja przesyła najwięcej "gotowych" metryk zakupowych i szczegółów dotyczących samego produktu (diety).

Gotowe metryki LTV/RFM: System automatycznie wylicza i przesyła do profilu klienta łączną wydaną kwotę (total_spent ) oraz datę ostatniego zakupu ( last_purchase )
Mikro-zdarzenia: Śledzi nie tylko koszyki i zakupy, ale też rezerwacje, odnowienia subskrypcji, a nawet edycje pojedynczych dni w zamówieniu (trackBag )
Unikalne flagi: Do zdarzeń dołącza bezcenne dla marketera informacje, czy jest to pierwsze zamówienie klienta (isFirst ) oraz czy jest to okres testowy (isTrial ).
Subskrypcje: Śledzi na bieżąco status aktywnej subskrypcji klienta.

SalesManago – Król automatycznego tagowania i obsługi "cyklu życia klienta"

Ta integracja jest świetna w zarządzaniu tym, na jakim etapie znajduje się klient, i łączy marketing z obsługą klienta (BOK).

Dynamiczne Tagi: System nie tylko dodaje tagi, ale też usuwa te nieaktualne. Użytkownik płynnie przechodzi między statusami (np. z STATUS_KLIENT na STATUS_NIEAKTYWNY lub STATUS_PROBA ), co pozwala na łatwe budowanie automatyzacji.
Rozmowy telefoniczne (BOK): Jako jedyny system odbiera zdarzenia o wykonanych połączeniach telefonicznych do klienta (np. wywiad dietetyczny), co pozwala wstrzymać agresywny e-mail marketing.
Korekty finansowe: Przy anulowaniu zamówienia potrafi wysłać zdarzenie z wartością ujemną, aby statystyki finansowe w panelu marketingowym idealnie zgadzały się z rzeczywistością.
Porzucone koszyki: Mapuje dokładnie format produktów (id diety, wariantu, kaloryczności), aby móc wyświetlać konkretne zdjęcia diet w mailach ratujących koszyk.

GetResponse – Podstawowa integracja

Przesyła bardzo solidną bazę danych, ale brakuje w niej zaawansowanych mechanizmów behawioralnych.

Co ma: Aktualizuje dane kontaktowe, zgody, stan Skarbonki, datę końca diety oraz przesyła zdarzenia o złożonych zamówieniach (kwota, kody rabatowe, kaloryczność).
Czego brakuje: Nie śledzi porzuconych koszyków (tylko zamówienia opłacone), subskrypcji, statusów klienta ani nie wylicza wartości LTV bezpośrednio na profilu.

Werdykt: Jeśli marketing opiera się mocno na powracalności, subskrypcjach i analizie wartości koszyka (LTV) – User.com wygrywa ilością przekazywanych parametrów. Jeśli zespół woli budować lejki opierając się na tagach behawioralnych i łączyć to z działaniami Biura Obsługi Klienta – SalesManago ma lepsze "work-flow" do tego celu.

2. Możliwości integracji z GetResponse - jakie dane przekazujemy do serwisu i jak można ich użyć?

Integracja jest dość rozbudowana i opiera się na dwóch głównych filarach: synchronizacji danych kontaktowych (Custom Fields) oraz śledzeniu zdarzeń (Custom Events) na podstawie opłaconych zamówień.

A. Dane Klienta (Synchronizowane jako Custom Fields u kontaktu)

Przy każdej synchronizacji klienta (trackClient / syncClient ), system aktualizuje profil użytkownika w GetResponse o następujące dane:

Podstawowe: Adres e-mail, Imię.
Dane adresowe: Miasto, Kod pocztowy, Ulica, Numer budynku, Numer lokalu.
Dane demograficzne/kontaktowe: Płeć (Mężczyzna, Kobieta), Numer telefonu.
Zgody marketingowe: Osobne flagi (TRUE/FALSE) dla zgody na e-mail, SMS oraz kontakt telefoniczny.
Dane specyficzne dla cateringu:
- moneybox : Aktualny stan "skarbonki" (punkty/środki klienta)
- end_of_diet : Data ostatniej dostawy z aktywnej diety (bardzo ważny parametr!)

💡 Jak marketerzy mogą tego użyć?

Automatyzacja powrotów: Uruchomienie kampanii e-mail/SMS na 2-3 dni przed datą end_of_diet , zachęcającej do przedłużenia diety.
Segmentacja geolokalizacyjna: Wysyłanie promocji tylko do klientów z konkretnego miasta lub kodu pocztowego (np. darmowa dostawa w nowej strefie).
Wykorzystanie skarbonki: Kampanie przypominające typu "Masz 50 zł w Skarbonce, wykorzystaj je przy kolejnym zamówieniu!".
Zarządzanie zgodami: Gwarancja, że SMS-y i telefony trafiają tylko do osób z odpowiednią flagą (zachowanie zgodności z RODO).

B. Dane Zdarzeń Ecommerce (Custom Events)

Wysyłane tylko wtedy, gdy zamówienie otrzyma status opłaconego (isPaid() )

Zdarzenie: Złożenie zamówienia (Order) Przekazywane atrybuty to:

Data zamówienia.
Kwota wydana ze skarbonki (moneybox )
Ostateczna kwota zamówienia (po zniżkach i odjęciu środków ze skarbonki).
Zakupione produkty/dodatki (złączone nazwy, oddzielone znakiem /).
Użyty kod rabatowy.

Zdarzenie: Szczegóły zakupionej diety (Diet) Dla każdej diety w zamówieniu wysyłane jest osobne zdarzenie zawierające:

Kaloryczność (kcal )
Liczba dni (days )
Data startu (start ) i końca (end ) dostaw.
Nazwa diety, kod typu (type ) oraz wariant (variant )

💡 Jak marketerzy mogą tego użyć?

Cross-selling: Jeśli klient kupuje dietę "Sport" o wysokiej kaloryczności, można w mailu zaproponować mu dodatki białkowe lub napoje izotoniczne.
Ocena ROI kodów rabatowych: Sprawdzanie w GetResponse, które kody rabatowe generują klientów najdłużej utrzymujących dietę.
Nagradzanie lojalności: Segmentacja klientów, którzy w zdarzeniach mają łączną kwotę zamówień powyżej określonego progu.

3. GetResponse vs GetResponse MAX - różnice w integracji z Caterings

Z perspektywy samego "zakresu przesyłanych danych" w obrębie tego kodu nie ma żadnych różnic. Obie wersje (Zwykła i MAX) przesyłają dokładnie te same pola i zdarzenia.

GetResponse MAX to wyższy pakiet od standardowego, gdzie dostępne jest więcej funkcji.

Wiecej na temat GetReponse w wersji "Max" możesz przeczytać tutaj:

https://www.getresponse.pl/pomoc/co-to-jest-getresponse-max.html

W kwestii konfiuracji samej integracji, w przypadku wersji "Max" wymagany jest dodatkowy krok.

Więcej na ten temat dowiesz się w tym artykule poniżej:

Kliknij TUTAJ, aby przejść do instrukcji konfiguracji integracji z GetResponse / Getresposne MAX

4. Możliwości integracji z SalesManago - jakie dane przekazujemy do serwisu i jak można ich użyć?

Poniżej znajdziesz listę zdarzeń (mechanizmów), które obsługuje ta integracja:

1. Dane Klienta (Profil i Tagi)

Oprócz standardowych danych (imię, adres, telefon, język, środki w "Skarbonce"), system automatycznie zarządza tagami (dodaje nowe i usuwa nieaktualne)

Jakie Tagi i statusy wysyłamy?

Status cyklu życia: Klient dostaje status PROSPECT (założył konto, brak opłaconych zamówień) lub CUSTOMER .
Typy klientów (Tagi): * STATUS_KONTO (samo konto),
- STATUS_KLIENT (aktywna dieta),
- STATUS_PROBA (zamówienie testowe),
- STATUS_NIEAKTYWNY (kiedyś kupował, ale teraz nie ma aktywnej diety).
Funkcje dodatkowe: Flagi informujące, czy klient korzysta z opcji "Wybór Menu" (WYBOR_MENU_AKTYWNY_PLATNY ).
Subskrypcje: Informacja, czy klient ma obecnie aktywną płatność odnawialną/subskrypcję, czy miał ją w przeszłości.
Zgody i Daty: Data startu i końca aktywnej diety (zapisane jako słowniki) oraz w pełni omapowane zgody na E-mail/SMS/Telefon.
Lokalizacja: Tag z nazwą miasta (np. WARSZAWA).

💡 Jak marketerzy mogą tego użyć?

Ratyzowanie "Zbiegów": Automatyzacja wysyłająca maila "Tęsknimy!" od razu, gdy klientowi znika tag STATUS_KLIENT , a pojawia się STATUS_NIEAKTYWNY .
Upselling: Wysyłanie kampanii do osób bez tagu "Wybór Menu" z komunikatem: "Czy wiesz, że możesz sam wybierać swoje posiłki?".
Konwersja z zamówień testowych: Osoby z tagiemSTATUS_PROBA mogą otrzymać zniżkę na pełne, 30-dniowe zamówienie od razu po zakończeniu testu.

2. Śledzenie Zdarzeń (Carts, Orders, Calls)

SalesManago otrzymuje bardzo precyzyjne dane o każdym kroku klienta w formacie dostosowanym pod silnik rekomendacji produktowych (Product Feed).

Jakie parametry są przypięte do zdarzeń (Koszyk, Zakup, Anulowanie)?

Wartość koszyka (po zniżkach).
ID produktów w formacie: DIET_id_wariant_kalorycznosc , ADDON_id (dodatki) oraz DISH_id (pojedyncze dania).
Data pierwszej i ostatniej dostawy.
Sumaryczna liczba dni diety.
Dokładne nazwy diet, wariantów i kaloryczności przypisane do specjalnych pól szczegółów (od "detail1 " do "detail8 ").

💡 Jak marketerzy mogą tego użyć?

Dynamiczne ratowanie koszyków: Z racji przesyłania konkretnych ID produktów zgodnych z formatem SalesManago, można wysłać maila, w którym automatycznie zaciągnie się zdjęcie i nazwa dokładnie tej diety, którą klient porzucił w koszyku.

3. Śledzenie Koszyków (Track Basket) Kod śledzi koszyk klienta (trackBasket ). Jeśli klient zacznie składać zamówienie, ale go nie opłaci, tworzony jest event cartEventId .

Jak to użyć w marketingu: Uruchomienie automatyzacji: "Hej, zapomniałeś o swojej diecie! Dokończ zamówienie w ciągu 2 godzin, a dostaniesz X% zniżki".

4. Rozbudowane śledzenie statusów Zamówień (Track Order) W GetResponse widzieliśmy tylko wysyłanie opłaconych zamówień. SalesManago śledzi pełen cykl życia zamówienia:

STATUS_WAITING_FOR_PAYMENT (Oczekuje na płatność) - tworzy event koszyka/zamówienia.
STATUS_PAID (Opłacone) - tworzy event purchaseEventId.
STATUS_CANCELED (Anulowane) - tworzy event anulowania (cancellationEventId ), a co więcej, potrafi wysłać zdarzenie "korygujące" z ujemną wartością (value *= -1 ), aby statystyki przychodów w panelu SalesManago się zgadzały!

Jak to użyć w marketingu: Można wyłapywać klientów, którym odrzuciło płatność (status oczekujący długo się nie zmienia) i wysyłać im link do ponowienia płatności Blikiem/PayU.

5. Dwukierunkowa komunikacja (Webhooki)

(Należy najpierw poprawnie uzupełnić Webhooki w SM <->CATERINGS)

Plik zawiera metodę handleWebhook . Oznacza to, że SalesManago potrafi aktywnie "pukać" do systemu Caterings i aktualizować dane klienta w bazie (rozpoznając go po UUID, e-mailu lub telefonie).

Jak to użyć w marketingu: Jeśli klient wypisze się z newslettera (wypisze się ze zgód) klikając link w mailu wysłanym z SalesManago, SalesManago wyśle webhooka do Caterings, a system odznaczy zgodę w panelu klienta. Zapewnia to 100% synchronizację danych.

6. INNY TRYB -> Zgodność z Cookiebot Integracja sprawdza, czy klient zaakceptował ciasteczka marketingowe przez narzędzie Cookiebot (isCookiebotTermsAccepted ). To bardzo ważny punkt dla działu prawnego (RODO).

5. Czy zdarzenie CART w Salesmanago jest “zamówieniem” czy “koszykiem”?

1. Zdarzenie CART jako fizyczny KOSZYK (Basket)

Kiedy klient kompletuje swoją dietę na stronie, wybiera dodatki, dobiera kaloryczność, ale jeszcze nie sfinalizował zamówienia (nie przeszedł do kasy/podsumowania), system operuje na obiekcie Koszyka (Basket):

Uruchamiana jest metoda trackBasket .
Fabryka Event::fromBasket generuje zdarzenie o typie EVENT_CART .
SalesManago otrzymuje informacje o produktach, datach dostaw itp., a system zapisuje ID tego zdarzenia w specjalnym polu śledzenia koszyka (salesManagoCartEventId ).

2. Zdarzenie CART jako ZAMÓWIENIE OCZEKUJĄCE (Order o statusie WAITING_FOR_PAYMENT )

Gdy klient kliknie "Zamawiam i płacę", system tworzy pełnoprawne Zamówienie (Order). Niestety, czasem klient w tym momencie zamknie okno bramki płatności (np. PayU/Przelewy24) lub wygaśnie mu sesja BLIK. Powstaje wtedy zamówienie o statusie Oczekujące na płatność (STATUS_WAITING_FOR_PAYMENT).

Uruchamiana jest metoda trackWaitingForPaymentOrder .
System mapuje status oczekujący dokładnie na to samo zdarzenie: EVENT_CART (wynika to wprost z instrukcji match w pliku Event.php ).
Co ciekawe, system jest sprytny: jeśli zamówienie oczekujące ma wciąż podpięty oryginalny "Koszyk", to aktualizuje ten sam cartEventId w SalesManago, płynnie łącząc koszyk z porzuconym zamówieniem.

6. Możliwości integracji z User.com - jakie dane przekazujemy do serwisu i jak można ich użyć?

1. Dane Klienta (Profil Użytkownika)

Jakie dane przesyłamy?

Dane podstawowe i demograficzne: Imię, nazwisko, firma, email, telefon, płeć, miasto, język przeglądarki, strefa czasowa.
Wartość klienta (LTV / RFM):
- score (Skarbonka) – aktualna liczba punktów/środków do wykorzystania.
- total_spent – łączna, historyczna kwota wydana przez klienta we wszystkich zamówieniach (po zniżkach).
- last_purchase – data ostatniego zakupu.
Kody rabatowe: Aktywny kod referencyjny klienta oraz informacja, czy zniżka jest procentowa, czy kwotowa.
Zgody marketingowe: Pełna synchronizacja zgód (Email, SMS, Telefon). Z poprzednich plików wiemy też, że działa to w dwie strony – jeśli klient wypisze się w User.com, system odznaczy zgodę w Caterings.

💡 Jak marketerzy mogą tego użyć?

Segmentacja VIP (RFM): Automatyczne wysyłanie ekskluzywnych ofert do klientów, których total_spent przekroczył np. 5000 zł.
Kampanie Win-back: Wyłapanie osób, których last_purchase był dawniej niż 30 dni temu, ale mają sporo środków w score (Skarbonce) – idealny pretekst do kontaktu ("Wykorzystaj swoje 40 zł, zanim przepadną!").
Programy poleceń: Wysyłanie maili z aktywnym kodem rabatowym klienta, zachęcających do zaproszenia znajomych.

2. Śledzenie Zdarzeń i Produktów (Diety)

Integracja dzieli produkty na "Simple" (ogólny widok diety) i "Variant" (konkretne zamówienie klienta z datami).

A. Zdarzenia ogólne (Simple Factory) Gdy użytkownik np. ogląda diety lub dodaje je do koszyka, system wysyła dane ogólne:

Zdjęcie diety, Kaloryczność, Cena, Link do strony diety.
Unikalne ID w formacie: DIET_id_wariant_kalorycznosc .

B. Zdarzenia szczegółowe klienta (Variant Factory) Gdy dochodzi do głębszych interakcji (Rezerwacja, Opłacenie, Odnowienie subskrypcji, Modyfikacja konkretnego dnia w torbie), system wysyła spersonalizowany produkt z unikalnym ID (DIET_id_wariant_kalorycznosc_idKlienta ). Wtedy do User.com trafiają duże ilości danych:

Szczegóły logistyczne: Data pierwszej (start ) i ostatniej (end ) dostawy, liczba dni zamówienia, liczba posiłków w ciągu dnia.
Statusy sprzedażowe: Czy to jest pierwsze zamówienie klienta (isFirst ), czy jest to zamówienie testowe (isTrial ).
Subskrypcje: Czy dieta odnawia się automatycznie (subscription_active ) i kiedy nastąpiła ostatnia zmiana statusu.
Aktywność: Flaga active (która zmienia się na false, jeśli klient anuluje zamówienie).

💡 Jak marketerzy mogą tego użyć?

Precyzyjny Onboarding (First Order): Osoby z flagą isFirst = true mogą dostać zupełnie inną komunikację powitalną (np. instrukcję jak odgrzewać posiłki) niż weterani.
Konwersja z okresu próbnego (Trial): Jeśli event ma flagę isTrial = true , marketer może ustawić automatyzację na 1 dzień przed datą end (koniec dostaw) z ofertą: "Jak smakował okres próbny? Zamów pełną dietę z rabatem 10%".
Utrzymanie Subskrybentów: Monitorowanie eventów "Odnowienie subskrypcji". Jeśli status subscription_active zmieni się z true na false (klient anulował podpiętą kartę), natychmiast wychodzi mail ratunkowy z pytaniem o powód i ewentualną zniżką na powrót.
Cross-selling oparty na posiłkach: Jeśli z daily_meals wynika, że klient zamawia tylko 3 posiłki (zamiast 5), można zaproponować mu dokupienie przekąsek lub zup w trakcie trwania diety.

7. Która z integracji śledzi porzucone koszyki?

W skrócie: Żadna integracja sama z siebie tego nie robi, do tego celu wymagane są dodatkowe kroki konfiguracyjne po stronie integrowanego systemu

System Caterings, w kontekście konfiguracji integracji (kod backendowy) to tylko "posłaniec". Kod nie wie, co to jest "porzucony koszyk" – on po prostu informuje zewnętrzny system: "Hej, ten klient właśnie utworzył koszyk o takiej wartości i z takimi produktami".

Cały proces (tzw. "śledzenie porzuconego koszyka" i reakcja na niego) dzieje się wyłącznie w regułach automatyzacji po stronie platformy marketingowej.

Aby marketer mógł taką automatyzację skonfigurować, integracja musi mu dostarczyć odpowiednie dane...

... I tutaj pojawiają się spore różnice między dostępnymi integracjami:

Kto dostarcza dane do śledzenia koszyków?

1. SalesManago – TAK Integracja wysyła zdarzenie CART.

👉 Jak to działa w praktyce (Automatyzacja): Marketer wchodzi do panelu SalesManago i ustawia regułę:

JEŚLI pojawi się zdarzenie zewnętrzne CART, ODCZEKAJ 2 godziny, a następnie SPRAWDŹ czy w tym czasie pojawiło się zdarzenie PURCHASE . Jeśli nie, wyślij email ratunkowy z dynamicznymi obrazkami produktów (których ID przesłaliśmy w evencie).

2. User.com – TAK Integracja wysyła zdarzenie trackCheckout

👉 Jak to działa w praktyce (Automatyzacja):

Podobnie jak w SalesManago, Marketer w panelu User.com "nasłuchuje" zdarzenia checkout. Jeśli nie nastąpi po nim zdarzenie purchase , uruchamia ścieżkę z powiadomieniem (np. pop-up na stronie przy próbie wyjścia lub e-mail).

3. GetResponse – NIE, na podstawie dostarczonego wcześniej kodu (api/src/Integration/Bridge/GetResponse/GetResponse.php ) system w ogóle nie wysyła danych o koszykach.

👉 W kodzie znajduje się sztywny warunek: if ($order->getStatus()->isPaid()) { ... }

👉 Co to oznacza: GetResponse dowiaduje się o kliencie i zamówieniu dopiero w momenci, w którym zamówienie zostaje opłacone. W związku z tym, z technicznego punktu widzenia, przy obecnym kształcie integracji nie da się skonfigurować procesu "ratowania koszyków" w GetResponse, ponieważ system jest ślepy na wszystko, co dzieje się przed dokonaniem płatności.

8. Która z integracji działa dwustronnie - tzn. jeśli klient odznaczy zgodę w Caterings przesyłane jest to integracji i w drugą stronę - jeśli klient wypisze się z listy poprzez np. maila z integracji przesyła się to do nas?

Taka "dwustronna" intagracja dostępna jest przy systemach:

👉 SalesManago

👉 UserCom

Integracje (SalesManago oraz User.com) działają w pełni dwustronnie w kwestii zgód marketingowych. W obu przypadkach system Caterings jest przygotowany na to, aby nie tylko wysyłać status zgód do narzędzia marketingowego, ale również odbierać sygnał o wypisaniu się klienta (opt-out) i odznaczać te zgody w bazie danych.

1. SalesManago

Z Caterings do SalesManago: W pliku Contact.php (fabryka klienta) istnieje warunek if ($synchronizeConsents ). Jeśli jest spełniony, system buduje tablicę consentDetails i precyzyjnie określa pola consentAccept (zgoda) oraz optOut brak zgody/wypisanie) dla e-maila, SMS i telefonu.
Z SalesManago do Caterings: Służy do tego mechanizm Webhooków. W głównym pliku integracji SalesManago.php znajduje się metoda handleWebhook(WebhookCall $webhookCall) . Kiedy klient kliknie "Wypisz mnie" w mailu z SalesManago, SM uderza pod specjalny adres URL w Caterings. System rozpoznaje klienta po UUID, e-mailu lub telefonie, a następnie przekazuje dane do webhookConsumer , który aktualizuje jego profil w Waszej bazie.

2. User.com

Z Caterings do User.com: W pliku ClientFactory.php podczas każdej synchronizacji klienta do payloadu dorzucane są twarde parametry: email_consent , sms_consent oraz phone_consent z wartością true/false .
Z User.com do Caterings: W głównym pliku UserCom.php istnieje dedykowana do tego metoda o nazwie clientSyncMarketingTerms(Client $client, array $extraData) . Jeśli klient zaktualizuje swoje preferencje bezpośrednio w systemie User.com (lub wypisze się z maila), User.com uderza do Waszego systemu i przekazuje tablicę $extraData . Metoda ta wyłapuje klucze email_consent , sms_consent , phone_consent , nadpisuje je bezpośrednio na profilu klienta i zapisuje zmiany w bazie danych($this->entityManager->flush()) .

9. Jak dokładnie działa przycisk synchronizacji?

(W żadnej integracji nie kasujemy danych automatycznie, dane są tylko przesyłane do INTEGRACJI)

1. SalesManago (Metoda upsert)

Z kodu Core/SalesManago.php jasno wynika, że system korzysta z wbudowanej w API SalesManago metody: $this->getContactService()->upsert(...)

Jak to działa przy synchronizacji?

System pakuje obecne dane klienta (imię, adres, telefon, zgody).
Przelicza jego Tagi (statusy).
Wysyła paczkę danych. SalesManago sprawdza e-mail: jeśli klienta nie ma, to go tworzy. Jeśli jest – nadpisuje mu dane.
Ciekawostka (Tagi): Podczas synchronizacji system wysyła dwie listy tagów: tags (te, które klient ma mieć teraz) oraz removeTags (te, które należy mu zdjąć, bo np. z PROSPECT stał się CUSTOMER ). Usuwane są więc tylko nieaktualne "etykiety", a nie sam kontakt.

2. User.com (Endpoint update_or_create)

W pliku Core/UserCom.php widnieje bardzo wymowny adres, pod który wysyłane są dane: api/public/users/update_or_create/

Jak to działa przy synchronizacji?

System przelicza na nowo wszystkie wartości koszyka (np. aktualny total_spent , score ze skarbonki, datę last_purchase ).
Wysyła cały "świeży" pakiet pod powyższy adres.
User.com po swojej stronie przyjmuje ten pakiet, znajduje użytkownika po ID lub e-mailu i po prostu podmienia mu wartości w polach niestandardowych.

3. GetResponse (Warunkowe Update/Create)

W pliku Bridge/GetResponse.php oraz Core/GetResponse.php mechanizm jest nieco bardziej "ręczny", ale efekt jest ten sam.

Jak to działa przy synchronizacji?

Najpierw system sprawdza, czy zna ID kontaktu w GetResponse. Jeśli nie, wykonuje zapytanie resolveContactId , by sprawdzić, czy taki e-mail już u nich figuruje.
Następnie wykonuje warunek: $execContactOperation = !empty($contactId) ? new UpdateContact(...) : new CreateContact(...)
Jeśli klient istnieje, wywoływana jest funkcja UpdateContact oraz aktualizowane są pola niestandardowe (upsertCustomFields - np. nowa data końca diety, zaktualizowany stan skarbonki).

10. Użycie przycisku Synchronizuj w GetResponse.

Co dokładnie robi przycisk "Synchronizuj" (metoda trackClient):

Kiedy klikasz przycisk, system wywołuje metodę przypisaną do samego klienta (w kodzie GetResponse jest to trackClient połączone z syncClient ).

(Użycie przycisku nie "triggeruje" eventów, triggeruje samych klientów)

Jakie działania wykonuje ten proces:

Pobiera aktualne dane przypisane do profilu: e-mail, imię, zgody marketingowe, miasto, adres.
Pobiera aktualny stan powiązany z kontem: wartość skarbonki (moneybox) oraz wyliczoną datę końca aktywnej diety (end_of_diet).
Wysyła to jako żądanie aktualizacji pól niestandardowych (Custom Fields) do GetResponse.

W tym procesie kod w ogóle nie dotyka zdarzeń (Events). Metoda $api->createEvent() nie jest tutaj wywoływana.

Dodatkowe wsparcie

Jeśli potrzebujesz dowiedzieć się więcej na temat kodów dostępnych w systemie Caterings integracji lub potrzebujesz dodatkowego wsparcia, zapraszamy do kontaktu z naszym zespołem Customer Support.

Skontaktujesz się z nami poprzez czat dostępny po zalogowaniu się do systemu lub email -support@caterings.pl