Files
interblue.pl/ga.txt
2026-03-15 23:31:17 +01:00

106 lines
4.0 KiB
Plaintext

Diagnoza modułu pdgoogleanalytycs4pro (GA4) - podsumowanie
Data: 2026-03-15
1) Główny powód pojawiania się ścieżki /admin658c34/index.php/sell/orders/
Moduł pobiera referer z tabeli ps_connections i zapisuje go do pola http_referer,
a następnie wysyła go do GA4 jako parametr affiliation.
Kluczowe miejsca w kodzie:
- Pobranie referera:
modules/pdgoogleanalytycs4pro/pdgoogleanalytycs4pro.php:92
modules/pdgoogleanalytycs4pro/pdgoogleanalytycs4pro.php:100
- Wysyłka affiliation w purchase (server-side, Measurement Protocol):
modules/pdgoogleanalytycs4pro/pdgoogleanalytycs4pro.php:1876
modules/pdgoogleanalytycs4pro/pdgoogleanalytycs4pro.php:1924
- Wysyłka affiliation w purchase (front, JS):
modules/pdgoogleanalytycs4pro/views/templates/hook/displayOrderConfirmation.tpl:24
Wniosek:
To nie jest losowa ścieżka. Moduł sam przekazuje referer do eventu. Jeżeli referer
w kontekście jest z panelu admina, to w danych GA4 pojawia się URL BO.
2) Odpowiedź na pytanie o tryb "Wyślij na stronie potwierdzenia zamówienia"
Przy tej opcji (PD_GA4P_TRANSACTION_SEND_TYPE = 1) purchase powinien iść z frontu,
z hooka displayOrderConfirmation.
Miejsca:
- Warunek trybu 1:
modules/pdgoogleanalytycs4pro/pdgoogleanalytycs4pro.php:1638
- Event purchase w szablonie:
modules/pdgoogleanalytycs4pro/views/templates/hook/displayOrderConfirmation.tpl:23
Tryb 2 (na zmianie statusu) wysyła purchase server-side:
- Warunek trybu 2:
modules/pdgoogleanalytycs4pro/pdgoogleanalytycs4pro.php:1845
Dlatego ścieżka adminowa najczęściej wskazuje na ścieżkę server-side (status change)
lub niespójność konfiguracji kontekstu sklepu.
3) Dodatkowe nieprawidłowości znalezione w module
3.1) Literówka klucza Smarty dla Google Ads conversion label
- Przypisywany klucz:
modules/pdgoogleanalytycs4pro/pdgoogleanalytycs4pro.php:1713
(pd_google_analytics_id_label)
- Oczekiwany w template:
modules/pdgoogleanalytycs4pro/views/templates/hook/displayOrderConfirmation.tpl:56
(pd_google_analytics_id_aw_label)
Skutek: możliwe problemy z parametrem send_to dla konwersji Ads.
3.2) Błędny operator bitowy zamiast logicznego
- modules/pdgoogleanalytycs4pro/controllers/front/ajax.php:233
- modules/pdgoogleanalytycs4pro/controllers/front/ajax.php:305
Jest: ($cart_rules & is_array($cart_rules))
Powinno być: ($cart_rules && is_array($cart_rules))
3.3) Błąd mapowania kategorii w displayFooter.tpl
- modules/pdgoogleanalytycs4pro/views/templates/hook/displayFooter.tpl:40
- modules/pdgoogleanalytycs4pro/views/templates/hook/displayFooter.tpl:41
item_category4 i item_category5 pobierają content_category3 zamiast 4 i 5.
3.4) Fallback, który może odpalić order confirmation poza standardowym hookiem
- modules/pdgoogleanalytycs4pro/pdgoogleanalytycs4pro.php:1587
Kod próbuje wywołać hookDisplayOrderConfirmation z hookDisplayFooter, gdy
order_confirmation_exec == false. To może utrudniać analizę momentu odpalenia eventu.
4) Co to oznacza praktycznie dla problemu backend URL
Najbardziej prawdopodobne:
- event purchase/refund jest wysyłany w ścieżce, gdzie referer pochodzi z kontekstu admina,
a moduł bez filtracji przepina to do affiliation.
Nawet przy trybie 1 moduł szeroko używa http_referer w eventach, więc referer może być
nieadekwatny do źródła transakcji.
5) Proponowane poprawki (bezpieczny zakres)
1. Nie używać http_referer jako affiliation (ustawić stałą wartość, np. nazwę sklepu,
albo puste).
2. Naprawić literówkę klucza:
pd_google_analytics_id_label -> pd_google_analytics_id_aw_label.
3. Poprawić operator:
& -> && w ajax.php.
4. Poprawić category4/category5 w displayFooter.tpl.
Opcjonalnie:
5. Dodać filtr, który odrzuca URL-e admina w affiliation.
6. Ograniczyć pobieranie referera tylko do front-office.
6) Uwaga operacyjna
Nie udało się potwierdzić wartości konfiguracji bezpośrednio w DB z tego środowiska,
bo lokalnie brak połączenia do serwera MySQL. Dlatego nie mogłem tutaj sprawdzić,
czy PD_GA4P_TRANSACTION_SEND_TYPE ma inną wartość per shop / multistore.