- Patryk Marek
- Baza wiedzy
- 0 polubienia
- 135 wyświetlenia
- 0 komentarze
- feed produktowy, Meta, Pixel, warianty produktów
Jeżeli zdarzenia z PrestaShop nie pasują do produktów w katalogu Meta, porównaj pełny identyfikator oferty z wartością wysyłaną w content_ids. Liczą się prefiks, separator i numer kombinacji. Dla integracji identyfikatory 812, ps_812-41 i ps_812_41 oznaczają różne ciągi, choć człowiek może skojarzyć je z tą samą kartą produktu.

Ten poradnik pomaga sprawdzić współpracę feedu produktowego i Pixela. Przykłady są demonstracyjne, bez danych klientów. Nie są zrzutem z konta reklamowego ani potwierdzeniem wyników kampanii.
Katalog, Pixel i Conversions API wykonują różne zadania
Katalog zawiera oferty: identyfikatory, nazwy, zdjęcia, ceny i dostępność. Feed jest jednym ze sposobów dostarczenia tych danych. Pixel przesyła zdarzenia z przeglądarki, np. obejrzenie produktu lub dodanie do koszyka. Conversions API pozwala przesyłać zdarzenia ze strony serwera.
Poprawnie pobrany katalog nie dowodzi, że zdarzenia odwołują się do właściwych ofert. Obecność zdarzenia zakupu nie dowodzi natomiast, że każdy produkt z tego zakupu ma dopasowanie w katalogu. Najpierw określ, którą część połączenia diagnozujesz.
Sprawdź też, czy oglądasz właściwy katalog i właściwe źródło zdarzeń. Przy kilku sklepach, starym Pixelu lub testowym feedzie można porównywać technicznie poprawne dane pochodzące z różnych konfiguracji.
Przykład: jeden produkt, dwie kombinacje
Przyjmijmy produkt o ID 812 i kombinacje 41 oraz 42. Feed eksportuje warianty jako osobne oferty z prefiksem ps_ i myślnikiem. Dla pierwszej kombinacji identyfikator wynosi więc ps_812-41.
| Miejsce | Kombinacja 41 | Kombinacja 42 | Co porównujesz |
|---|---|---|---|
| PrestaShop | Produkt 812, kombinacja 41. | Produkt 812, kombinacja 42. | Tożsamość produktu i wybranego wariantu. |
Feed: g:id | ps_812-41 | ps_812-42 | Identyfikator konkretnej oferty w katalogu. |
Zdarzenie: content_ids | ["ps_812-41"] | ["ps_812-42"] | Czy wskazuje ofertę odpowiadającą działaniu użytkownika. |
| Grupa w przykładowym feedzie | 812 | 812 | Wspólną grupę wariantów; nie zastępuje ona automatycznie ID oferty. |
Najprostsza kontrola polega na skopiowaniu wartości z przetworzonej oferty i zdarzenia do dwóch wierszy. Porównaj je znak po znaku. Nie usuwaj „zbędnego” prefiksu, zanim ustalisz, do czego odwołują się pozostałe integracje.
Co sprawdzono w modułach PrestaDev?
W kodzie Facebook Pixel Pro 1.4.5 dostępny jest wybór sposobu budowy ID i opcjonalnego prefiksu. Jedna ze ścieżek tworzy ID produktu połączone z ID kombinacji myślnikiem, inna używa podkreślenia. Istnieją również tryby oparte na innych polach. To konfiguracja, którą trzeba porównać z faktycznym eksportem, a nie wybierać wyłącznie po nazwie.
Sprawdzony kod feedu Meta 2.9.2 przy eksporcie kombinacji zapisuje g:id w postaci prefiks + ID produktu + myślnik + ID kombinacji. Dla tego ustawienia wariant ps_812_41 wysyłany przez Pixel nie będzie identyczny z ps_812-41 w feedzie. W tej ścieżce feed zapisuje wspólne g:item_group_id jako ID produktu bez prefiksu.
To potwierdzenie sposobu budowania danych w wymienionych wersjach kodu, nie dowód dopasowania na konkretnym koncie Meta. Po zmianie ustawień nadal trzeba sprawdzić wygenerowany plik, import katalogu i rzeczywiste zdarzenie.
content_ids i content_type muszą być spójne
content_ids zawiera identyfikatory związane ze zdarzeniem. content_type określa sposób odniesienia do produktów lub ich grup. Nie należy zamieniać product na product_group tylko po to, by zniknął komunikat: zmienia to znaczenie identyfikatorów, do których zdarzenie się odwołuje.
W omawianym przykładzie wybieramy konkretną ofertę wariantu i content_type: "product". Uproszczony zestaw danych dla obejrzenia wariantu wygląda tak:
{
"content_ids": ["ps_812-41"],
"content_type": "product",
"value": 129.00,
"currency": "PLN"
}
To fragment danych przykładowego zdarzenia, a nie kompletny kod wdrożenia ani żądanie do API. Typy pól content_ids, content_type, value i currency można sprawdzić w oficjalnym SDK Meta — CustomData. W diagnostyce konkretnego konta sprawdź również aktualne komunikaty Menedżera zdarzeń.
Po zmianie wariantu wykonaj nową próbę
Poprawne ID przy pierwszym otwarciu strony nie wystarcza. Motyw może zmieniać wariant bez przeładowania dokumentu. Integracja zdarzeń powinna użyć danych odpowiadających aktualnemu działaniu, zamiast pozostać przy kombinacji domyślnej.
- Wybierz produkt z przynajmniej dwiema kombinacjami obecnymi w feedzie.
- Zapisz ich pełne identyfikatory z pliku i z katalogu po imporcie.
- Otwórz produkt w kontrolowanej sesji testowej, z właściwymi ustawieniami zgód.
- Sprawdź dane zdarzenia dotyczącego pierwszego wariantu.
- Zmień kombinację i dodaj wybrany wariant do koszyka.
- Porównaj ID, ilość, wartość i walutę zdarzenia z aktualnym koszykiem.
- Sprawdź, czy tej samej akcji nie wysyła dodatkowo druga instalacja Pixela, np. przez inny moduł lub menedżer tagów.
Nie interpretuj braku zdarzenia jako błędu katalogu, zanim sprawdzisz zgody, blokowanie skryptów i konfigurację źródła zdarzeń. Przesyłanie danych przez serwer również wymaga właściwej konfiguracji prywatności; CAPI nie powinno być traktowane jako sposób obchodzenia decyzji użytkownika.
Wartość i waluta to osobna kontrola
Identyczne ID nie potwierdza poprawnej kwoty. Dla zdarzenia produktu sprawdź cenę wybranej kombinacji, a dla zakupu uzgodnioną definicję wartości całego zamówienia. Nie porównuj jednej sztuki z sumą koszyka ani kwoty netto z brutto bez ustalenia, jak działa wdrożenie.
Waluta musi odpowiadać przesłanej wartości. Przy sklepie wielowalutowym wykonaj osobną próbę po jej zmianie. Jeżeli dane pochodzą z zamówienia, porównuj z zapisanym zamówieniem, a nie z aktualną ceną katalogową odczytaną później.
Dopasowanie produktu a deduplikacja zakupu
Deduplikacja rozpoznaje dwie kopie tego samego zdarzenia przesłane z przeglądarki i serwera. Nie służy do łączenia wariantów produktu. W oficjalnym SDK Meta opisano, że dla odpowiadających sobie zdarzeń przeglądarkowe eventID ma zgadzać się z serwerowym event_id, a w procesie wykorzystywana jest również nazwa zdarzenia. Źródło: Meta — opis Event i setEventId.
| Identyfikator | Przykład demonstracyjny | Co ma rozpoznawać |
|---|---|---|
content_ids | ["ps_812-41"] | Produkt lub wariant związany z akcją. |
eventID / event_id | purchase_demo_1001 | Jedno konkretne zdarzenie zakupu przesłane dwoma kanałami. |
Stałe event_id równe ID produktu byłoby niewłaściwym pomysłem dla różnych zakupów tego produktu. Z kolei zgodne identyfikatory zdarzenia nie naprawią błędnego content_ids. Sprawdzaj te dwie rzeczy oddzielnie. Jeżeli analizujesz także GA4, wykorzystaj istniejący poradnik o pomiarze zakupów.
Od czego zacząć poprawę integracji?
Wybierz jeden produkt i zachowaj trzy dane: ID w sklepie, ID zaimportowane do katalogu i ID ze zdarzenia. Ustal format, zmień właściwe ustawienie, odśwież potrzebne źródło i ponów próbę. Nie zmieniaj jednocześnie prefiksu, separatora, sposobu eksportu wariantów i kilku instalacji Pixela — utrudni to ustalenie, która korekta rozwiązała problem.
Sprawdź zgodność formatu ID w obu integracjach: Facebook Pixel Pro oraz feed produktów XML dla Meta. Ich konfiguracja powinna wynikać z tego samego modelu katalogu. Poprawne dopasowanie jest elementem jakości danych, nie gwarancją rentowności reklam.
Weryfikacja merytoryczna: 13 września 2026. Sprawdzono kod Facebook Pixel Pro 1.4.5, feedu Meta 2.9.2 oraz publiczne definicje w oficjalnym SDK Meta. Nie wykonywano publikacji ani testowego zakupu na koncie reklamowym klienta.
Komentarze (0)