Te pliki cookie są niezbędne do prawidłowego działania strony. Umożliwiają podstawowe funkcje, takie jak bezpieczeństwo, koszyk i dostęp do konta. Nie można wyłączyć tych plików cookie.
Te pliki cookie umożliwiają rozszerzone funkcje i personalizację, takie jak zapamiętywanie preferencji językowych lub regionu. Jeśli nie zezwolisz na te pliki cookie, niektóre funkcje mogą nie działać prawidłowo.
Te pliki cookie pomagają nam zrozumieć, jak odwiedzający korzystają ze strony, zbierając i raportując informacje anonimowo. Pomaga nam to ulepszać naszą stronę.
Te pliki cookie służą do wyświetlania reklam dopasowanych do Twoich zainteresowań. Pomagają również mierzyć skuteczność kampanii reklamowych.
Integracja Criteo OneTag łączy ścieżkę zakupową, katalog produktów i opłacone zamówienia Twojego sklepu PrestaShop z Criteo. Instalacja i jeden identyfikator partnera uruchamiają podstawowe połączenie z kontem reklamowym.
Criteo obsługuje dynamiczne reklamy produktów i remarketing, wykorzystując katalog oraz zachowanie kupujących do tworzenia grup odbiorców i przypisywania przychodu. Reklama jest rozliczana osobno na warunkach Twojej umowy z Criteo, niezależnie od zakupu modułu.
Osobno włączasz etapy zakupowe, prowadzisz plik produktowy ze zgodnymi identyfikatorami i wybierasz dopasowanie klientów. Bezpośrednia wysyłka przekazuje opłacone zamówienia niezależnie od przeglądarki; nieudane próby czekają na ponowienie lub ręczne wznowienie. Zgoda marketingowa i wykluczenie pracowników regulują zbieranie danych, a ochrona przed duplikacją wskazuje jedną odpowiedzialną integrację.
Aktualne ceny, zapasy i identyfikatory pozostają zgodne między oglądanymi produktami a artykułami prezentowanymi w reklamach dynamicznych.
Criteo OneTag Integration łączy zainteresowanie produktami, aktywność w koszyku i przychód z opłaconych zamówień z Criteo. Standardowe śledzenie zaczyna się od jednego identyfikatora konta, a plik produktowy, osobne etapy ścieżki, ustawienia prywatności, dodatkowe reguły i bezpośrednia wysyłka zakupów zapewniają rozbudowane ustawienia.
Moduł utrzymuje zgodność katalogu, zachowania w sklepie i danych zakupu, a następnie pokazuje gotowość każdego elementu połączenia oraz wynik wysyłki sprzedaży.
Moduł rejestruje stronę główną, listy kategorii, wyniki wyszukiwania, strony produktów, koszyk i rozpoczęcie składania zamówienia, potwierdzone dodania oraz zakupy. Aktywność produktu zawiera identyfikator, aktualną cenę, dostępność i ścieżkę kategorii. Listy zawierają widoczne produkty, a zakup referencję, walutę, produkty, ceny i ilości.
Synchronizowany plik produktowy korzysta z tych samych identyfikatorów produktów co zdarzenia sklepu i opłacone zamówienia. Publikuje nazwy, aktualne ceny, stany, zdjęcia i adresy produktów, odświeża je według harmonogramu i zgłasza rozbieżności przed przekazaniem do Criteo. Produkt oglądany w sklepie pozostaje dzięki temu tym samym produktem w reklamie dynamicznej.
Dodanie trafia do Criteo dopiero po potwierdzeniu dodatniego zwiększenia ilości w koszyku. Usunięcie, zmniejszenie ilości, nieudane żądanie i powtórzone powiadomienia sklepu nie stają się nowym sygnałem zakupowym. Zdarzenie zawiera raz produkt oraz ilość faktycznie dodaną.
Ta sama zasada dotyczy sprzedaży. Do bezpośredniej wysyłki trafia wyłącznie opłacone zamówienie, a płatność odroczona wysyła zamówienie przy zmianie statusu na opłacone. Stała tożsamość zakupu zapobiega zamianie jednego zamówienia w kilka przez natychmiastowe zdarzenie sklepu, późniejszą zmianę statusu i powtórzone przetwarzanie.
Bezpośrednia wysyłka zapisuje opłacone zamówienie w sklepie przed próbą przekazania. Tymczasowa odmowa Criteo albo problem z połączeniem pozostawia zakup w kolejce, zamiast tworzyć cichą lukę w raportach kampanii. Kolejne próby odbywają się w rosnących odstępach, a udana wysyłka zamyka ten sam unikalny zapis.
Panel administracyjny pokazuje liczbę oczekujących, wysyłanych, dostarczonych i nieudanych wpisów razem z tożsamością ostatnich zakupów, liczbą prób, stanem odpowiedzi i błędem. Wpis, który osiągnął limit prób, wraca do przetwarzania po ręcznym ponowieniu, a jego wcześniejsza historia błędów pozostaje dostępna do diagnozy.
Każdy standardowy etap ścieżki włączasz osobno. Po zainstalowaniu MPR Cookies Revolution albo MPR Cookie Banner decyzja marketingowa sklepu steruje uruchomieniem Criteo, a zalogowani pracownicy pozostają poza danymi reklamowymi. Dopasowanie klienta jest opcjonalne, a numer klienta i adres e-mail są przekształcane przed wysłaniem przez przeglądarkę lub bezpośrednio ze sklepu.
Dodatkowe reguły łączą obsługiwane działania Criteo z wybranym kliknięciem, fragmentem adresu, stroną sklepu, stroną dostarczaną przez inny moduł albo nazwanym działaniem. Ich wartości są sprawdzane, a pola osobowe usuwane. Gdy inna współpracująca integracja obsługuje już to samo konto Criteo, ten moduł pozostaje nieaktywny i wskazuje właściciela, zamiast zgłaszać każde działanie dwa razy.
Kreator prowadzi krok po kroku od Partner ID przez zgodę i plik produktowy do opcjonalnego bezpośredniego przesyłania danych o zakupach. Wyjaśnia każdy wymóg, zapisuje postęp i sprawdza prawdziwą ścieżkę sklepu od listy i strony produktu przez potwierdzone dodanie, koszyk i opłacone zamówienie. Wynik porównuje wysłany identyfikator produktu z identyfikatorem w pliku produktowym.
Sekcja gotowości osobno przedstawia identyfikator konta, standardowe zdarzenia, ochronę zgody, dodatkowe reguły, aktualność pliku, ustawienia zakupu i stan kolejki. Próba wysyłki do Criteo, ostatnie wyniki i konkretne błędy zamykają wdrożenie. Szybki start przechodzi więc w konfigurację, której działanie pozostaje widoczne po zmianach wyglądu, zgody lub procesu składania zamówienia.
Pierwsza opinia o tym produkcie może pomóc innym w zakupach.
Zainstaluj Criteo OneTag w swoim sklepie PrestaShop i wysyłaj do Criteo zdarzenia e-commerce potrzebne do retargetingu, rekomendacji produktów, reklam produktowych i pomiaru konwersji. Moduł dodaje śledzenie OneTag w przeglądarce przez hooki PrestaShop i może opcjonalnie kolejkować serwerowe zdarzenia zakupu dla Criteo Retail Media.
Tak. Moduł ma opcjonalny server-side Criteo Retail Media purchase tracking. Aby go używać, tracking zakupów musi być włączony, a ustawienia server-side muszą być skonfigurowane: Criteo partner ID, S2S_ENABLED, region eu lub us, desktopowe i mobilne API page IDs oraz limit partii. Domyślny server-side batch limit to 20, z walidacją ograniczoną do zakresu od 1 do 100.
Gdy PrestaShop odpala actionValidateOrder, hook kolejkuje konwersję trackTransaction dla providera criteo_retailmedia i natychmiast przetwarza małą partię, ale sam nie sprawdza statusu zamówienia ani statusu płatności. Ścieżka kolejki działa, gdy tracking modułu może działać, tracking zakupów jest włączony, konfiguracja server-side jest prawidłowa i obecny jest załadowany obiekt Order. Jeśli wymagasz semantyki tylko dla opłaconych zamówień, musi to być zagwarantowane przez kontekst walidacji zamówienia albo dodane jako jawna kontrola statusu.
Zadanie cron o nazwie send_criteo_retailmedia_conversions jest także zarejestrowane do przetwarzania kolejkowanych konwersji co 300 sekund. Żądanie serwerowe jest wysyłane do endpointu Retail Media Criteo dla skonfigurowanego regionu, takiego jak d.eu.criteo.com lub d.us.criteo.com, z transaction ID, item, price, quantity, currency, danymi odwiedzającego/klienta i page ID. Opcjonalne ustawienie S2S_SEND_IP_UA kontroluje, czy dane IP i user-agent są dołączane. Ta kolejka server-side jest osobna od przeglądarkowego zdarzenia trackTransaction na stronie potwierdzenia zamówienia, więc nieudane wysyłki serwerowe można ponawiać bez polegania na sesji przeglądarki klienta.
Funkcja server-side jest instalowana ze wspólną tabelą kolejki konwersji i rejestracją cron. Domyślnie jest wyłączona: S2S_ENABLED=0, S2S_REGION=eu, desktop page ID trackTransactionApiDesktop, mobile page ID trackTransactionApiMobile, S2S_SEND_IP_UA=1 i S2S_BATCH_LIMIT=20. Partner ID musi być numeryczny i mieć od 4 do 20 cyfr, region musi być eu albo us, a page IDs mogą zawierać litery, cyfry, podkreślenie, dwukropek i myślnik.
Przy walidacji zamówienia moduł najpierw sprawdza wysokopoziomowe guardy trackingu: Criteo musi być aktywne, tracking zakupów musi być włączony, zgoda musi pozwalać na tracking, gdy guard zgody jest włączony, a ustawienia server-side muszą przejść walidację. Jeśli którakolwiek z tych kontroli się nie powiedzie, żadne zdarzenie serwerowe nie jest kolejkowane.
Payload purchase jest budowany z danych pozycji zamówienia. Item IDs, prices i quantities są łączone znakami pipe dla zapytania Criteo Retail Media. Jeśli nie da się zmapować żadnych item IDs, moduł wysyła fallback item=None, price=0.00 i quantity=1 zamiast pustego wymaganego pola. Wartość environment jest wybierana z user agenta jako desktop d, mobile m lub tablet t, a to środowisko wybiera desktopowy lub mobilny page ID.
Controller administracyjny udostępnia też narzędzia operacyjne dla tej kolejki: może pokazać liczby pending/sending/sent/failed, wysłać API probe i przenieść nieudane server-side events Criteo z powrotem do pending do ponowienia.
Required server-side setup:
ENABLED=1
PARTNER_ID=12345
TRACK_PURCHASE=1
S2S_ENABLED=1
S2S_REGION=eu or us
S2S_DESKTOP_PAGE_ID=trackTransactionApiDesktop
S2S_MOBILE_PAGE_ID=trackTransactionApiMobileTak, sprzedawcy mogą definiować własne reguły triggerów dla obsługiwanych zdarzeń Criteo. Konfiguracja PrestaShop przyjmuje zwalidowane reguły JSON z triggerami kliknięcia, URL, kontrolera lub zdarzenia DOM, a potem normalizuje nazwy do słownika OneTag Criteo.
Criteo OneTag można dodać do PrestaShop przez skonfigurowanie numerycznego Criteo Partner ID i włączenie śledzenia w przeglądarce. Moduł buduje wtedy zdarzenia OneTag w nagłówku dla obsługiwanych stron e-commerce i pozostaje nieaktywny, gdy Partner ID brakuje albo jest błędny.
Tak, gdy SEND_CUSTOMER_IDENTIFIERS jest włączone. Moduł buduje osobne zdarzenia klienta Criteo obok zwykłych zdarzeń page lub purchase. Nigdy nie wysyła zwykłego emaila w tych zdarzeniach klienta; zamienia email na małe litery, przycina go, a następnie hashuje SHA-256. ID klienta jest też hashowane z prefiksem customer:.
[{"event":"setCustomerId","id":"sha256(customer:123)"},{"event":"setEmail","email":"sha256(alice@example.com)"}]Powyższe wartości są placeholderami pokazującymi tylko strukturę. W rzeczywistym wyjściu storefront pola hash zawierają 64-znakowe heksadecymalne stringi SHA-256. Zdarzenia są całkowicie pomijane, gdy identyfikatory klientów są wyłączone albo gdy nie można załadować prawidłowego klienta z bieżącego kontekstu lub zamówienia.
Ustawienie jest domyślnie wyłączone, więc sprzedawca musi je świadomie włączyć, zanim te zdarzenia zostaną utworzone. Dla zwykłych zdarzeń page moduł używa bieżącego klienta PrestaShop z kontekstu storefront. Dla zdarzeń purchase na potwierdzeniu zamówienia może załadować klienta z id_customer zamówienia. W obu ścieżkach źródło sprawdza, czy istnieje prawidłowy obiekt klienta, zanim doda którekolwiek zdarzenie identyfikatora.
Szablony przeglądarkowe umieszczają te zdarzenia identyfikatora w uniwersalnej kolejce razem z setAccount i setSiteType, przed wypchnięciem zdarzenia page, basket lub purchase do window.criteo_q. Moduł nie wysyła imienia klienta, telefonu, adresu pocztowego ani surowego ID klienta PrestaShop w tych przeglądarkowych zdarzeniach klienta.
Dla server-side purchase tracking ta sama flaga opt-in może też dodać hashowany email do zapytania Retail Media, gdy klient zamówienia ma adres email. Ta ścieżka server-side nadal zależy od normalnych guardów trackingu: moduł musi być aktywny, zgoda musi pozwalać na tracking, gdy jest włączona, tracking zakupów musi być włączony, a ustawienia server-side Criteo muszą być prawidłowe.
Tak, może respektować zgodę cookies, gdy RESPECT_CONSENT jest włączone, co jest domyślne dla modułu. Moduł najpierw sprawdza mprcookiesrevolution, parsując cookie mprcr_consent i szukając marketing:1. Jeśli tego cookie brakuje, wraca do wartości DEFAULT_CONSENT modułu mprcookiesrevolution.
Jeśli Cookies Revolution nie jest aktywne, sprawdza mprcookiebanner. Wartość cookie mprcookie_consent=granted pozwala na Criteo; każda inna obecna wartość je blokuje. Jeśli cookie bannera jest nieobecne, moduł używa DEFAULT_CONSENT modułu mprcookiebanner.
Jeśli żaden obsługiwany moduł zgody MPR nie jest zainstalowany ani aktywny, hasMarketingConsent() zwraca allowed, więc Criteo nie jest blokowane samą zgodą. Dla ścisłej konfiguracji consent-first pozostaw Respect marketing consent włączone i uruchom jeden z obsługiwanych modułów zgody MPR. Client-side consent gate jest włączony tylko wtedy, gdy Respect marketing consent jest włączone i aktywny jest mprcookiesrevolution albo mprcookiebanner.
Kontrola zgody jest częścią canTrack(), które jest używane przed zdarzeniami nagłówka, zdarzeniami purchase na potwierdzeniu zamówienia i kolejkowaniem server-side purchase. Gdy więc server-side consent check blokuje tracking, moduł nie buduje normalnych zdarzeń przeglądarkowych i nie kolejkuje konwersji server-side z actionValidateOrder.
Szablon przeglądarkowy zawiera też client-side consent check, gdy gate zgody jest aktywny. Może wywołać window.MPRCR.isGranted('marketing'), gdy Cookies Revolution udostępnia ten helper, albo odczytać bezpośrednio te same cookies mprcr_consent i mprcookie_consent. Jeśli ta kontrola JavaScript zwróci false, zatrzymuje się przed wypchnięciem zdarzeń Criteo do window.criteo_q.
RESPECT_CONSENT=0: consent check is bypassed
RESPECT_CONSENT=1 + mprcr_consent contains marketing:1: allowed
RESPECT_CONSENT=1 + mprcookie_consent=granted: allowed
RESPECT_CONSENT=1 + no supported MPR consent module: allowed by this moduleZgoda nie jest jedynym guardem trackingu. Tracking przeglądarkowy nadal wymaga także ENABLED=1 i prawidłowego numerycznego Criteo Partner ID, a przeglądanie przez pracowników może być wykluczone, gdy EXCLUDE_EMPLOYEES jest włączone.
Moduł mapuje strony storefront PrestaShop i hooki na zdarzenia Criteo OneTag, z osobnymi ustawieniami dla każdego standardowego zdarzenia.
| Zdarzenie | Gdzie się uruchamia | Uwagi |
|---|---|---|
viewHome | Strona główna z displayHeader | Kontrolowane przez ustawienie trackingu strony głównej. |
viewItem | Strona produktu z displayHeader | Używa bieżącego kontekstu produktu. |
viewCategory | Strona kategorii/listingu z displayHeader | Używa kontekstu kategorii/listingu i widocznych danych produktów, gdy są dostępne. |
viewSearchResult | Strona wyników wyszukiwania z displayHeader | Zawiera kontekst wyszukiwania i pasujące dane produktów, gdy są dostępne. |
viewBasket | Koszyk albo strona checkoutu z displayHeader | Używa bieżących pozycji koszyka. |
addToCart | JavaScript front-office w szablonie header | Przechwytywane z aktualizacji koszyka i interakcji add-to-cart. |
trackTransaction | Potwierdzenie zamówienia z displayOrderConfirmation | Używa referencji zamówienia, waluty i kupionych pozycji. |
custom | Skonfigurowane reguły kliknięcia, URL, kontrolera albo zdarzenia DOM | Działa tylko wtedy, gdy tracking custom-event jest włączony i reguły pasują. |
Wszystkie zdarzenia przeglądarkowe nadal zależą od aktywnego modułu, skonfigurowanego Criteo partner ID, przejścia przez kontrole trackingu/zgody modułu i włączenia właściwego przełącznika per zdarzenie.
Moduły, które nasz zespół naprawdę łączy z tym i dokładnie dlaczego każdy pasuje do tego samego zestawu.
Gdy działa Criteo OneTag, Twój sklep wysyła do Criteo sygnały zakupowe na potrzeby retargetingu, zainteresowania produktem i raportowania zakupów w przepływach strony głównej, produktu, kategorii, wyszukiwania, koszyka, dodania do koszyka i transakcji. Criteo działa w oparciu o Twój katalog produktów, więc jego skuteczność w dużej mierze zależy od jakości i struktury stojących za nim danych produktowych, które integracja utrzymuje we własnym synchronizowanym feedzie.
Smart Google Merchant Feed Manager to osobny moduł, który generuje i kształtuje dane produktowe dla Google Merchant Center, z oddzielnymi profilami feedów dla rynków, języków, walut, krajów docelowych i trybów synchronizacji, oraz może publikować chronione linki do feedów XML. Daje Ci zdyscyplinowaną, świadomą kontrolę nad tym, jak dane katalogu są strukturyzowane dla platform zakupowych, zamiast polegać na doraźnych eksportach.
Używane razem pozwalają utrzymywać uporządkowane, dobrze ukształtowane dane produktowe wspierające Twoją obecność w Shopping, podczas gdy Criteo zajmuje się retargetingiem, dwa uzupełniające się narzędzia, które oba zależą od czystych informacji katalogowych. Korzyścią jest płatny marketing produktowy oparty na danych, którymi zarządzasz celowo: Twój feed pozostaje uporządkowany i dopasowany do rynku, Criteo utrzymuje własny feed i sygnały zakupowe, a katalog stojący u podstaw obu jest czymś, co kontrolujesz, a nie zostawiasz przypadkowi.
Gdy działa Criteo OneTag, Twój sklep wysyła do Criteo sygnały retargetingu i zakupów w głównych przepływach witryny, od strony głównej i produktu po koszyk i transakcję. To własny widok atrybucji Criteo, przydatny do optymalizacji kanału, ale opisuje Criteo wyłącznie w jego własnych kategoriach i nie daje Ci neutralnego miejsca raportowania, aby uczciwie porównać go z pozostałymi źródłami ruchu.
Google Analytics GA4 to osobny moduł, który wysyła aktywność e-commerce do Twojej usługi GA4 po zweryfikowaniu identyfikatora pomiaru, obejmując wyświetlenia produktów, aktywność koszyka, rozpoczęcia realizacji zamówienia, zakupy, wyszukiwania, logowania i tworzenie kont. Zapewnia raportowanie niezależne od kanału w całym sklepie, umieszczając Criteo w tych samych lejkach i widoku przychodów co każde inne źródło.
Używany obok Criteo OneTag, GA4 zachowuje widok konwersji Criteo do dostrajania kampanii, jednocześnie pokazując, jak wypada on na tle wszystkiego innego. Korzyścią jest wielokanałowy kontekst dla wydatków na retargeting: optymalizujesz Criteo na podstawie danych platformy, ale budżet przydzielasz na podstawie neutralnego raportu, więc kanał, który wygląda dobrze w izolacji, jest zawsze ważony względem jego rzeczywistego wkładu w sklep.
Sklep korzystający z Criteo OneTag wysyła sygnały zakupowe na potrzeby retargetingu i zwykle zarządza też innymi tagami marketingowymi. Ręczne koordynowanie ich w motywie jest kłopotliwe i podatne na awarie, a OneTag obsługuje wyłącznie własną platformę, więc szerszy zbiór pikseli i fragmentów analityki nie ma wspólnej, świadomej zdarzeń struktury, która utrzymywałaby go w spójności w miarę rozrastania się i zmian stacku.
Google Tag Manager to osobny moduł, który dodaje Twój kontener GTM i zasila go zdarzeniami e-commerce w formacie GA4 pochodzącymi z rzeczywistych zachowań zakupowych, dając otaczającym tagom marketingowym i analitycznym spójną warstwę dostarczania. Skonfiguruj wspólny kontener GTM dla innych tagów i pozostaw Criteo dedykowanemu modułowi, dzięki czemu Twój dedykowany tag Criteo pozostaje dokładnie taki, jak został skonfigurowany.
Uruchomienie obu pozostawia OneTag Criteo nienaruszony, podczas gdy GTM porządkuje szerszy krajobraz tagów. Korzyścią jest czystsza, łatwiejsza w konserwacji konfiguracja: Twój pomiar Criteo pozostaje niezależny i niezawodny, inne tagi żyją w uporządkowanej strukturze, a przyszłe zmiany znacznie rzadziej psują istniejące śledzenie, więc Twój wysiłek idzie w wyniki, a nie w utrzymywanie fragmentów kodu.
Ponieważ Criteo OneTag ładuje śledzenie w przeglądarce i może wysyłać zakupy z serwera, stosuje zgodę marketingową do obu ścieżek przesyłania, gdy decyzją zarządza obsługiwany menedżer zgód. Cookies Revolution zapewnia tę warstwę decyzyjną i zapisuje wybory klienta.
Cookies Revolution to osobny menedżer zgód, który zbiera i egzekwuje wybory dotyczące plików cookie niezbędnych, funkcjonalnych, analitycznych i marketingowych. Blokuje pasujące skrypty zewnętrzne i wbudowane przed wyrażeniem zgody, a po jej udzieleniu ponownie aktywuje te dozwolone i rejestruje każdą decyzję.
Używany obok Criteo OneTag, wstrzymuje skrypty marketingowe, dopóki kupujący nie wyrazi zgody, i prowadzi rejestr tych wyborów, dzięki czemu Twój retargeting Criteo opiera się na fundamencie szanującym zgodę. Korzyścią jest śledzenie, którego możesz bronić: nadal mierzysz kupujących, którzy się zgadzają, możesz udowodnić, jak zebrano zgodę, a zgodność pozostaje osobną, łatwą do zarządzania warstwą, a nie czymś załatanym wokół Twojego tagu retargetingowego.
30 dni na zwrot
Moduły Plug & Play
Wsparcie na pierwszym miejscu
Moduł tworzy i rozwija David Miller z mypresta.rocks. David Miller pracuje z PrestaShop od 2013 roku, a firma prowadząca ten sklep jest zarejestrowana od 3 grudnia 2018 roku. Każdy moduł w tym katalogu to nasza własna praca, więc Twoje pytania do wsparcia trafiają do ludzi, którzy napisali kod. Historia zmian na tej stronie pokazuje każdą aktualizację z datą.
