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.