Otwierasz sklep. Szybko. Ktoś od technikaliów mówi, że cache działa. Odpalasz kampanię, płacisz za kliknięcia i zakładasz, że klient dostaje tę samą szybką stronę.
Niekoniecznie. Wystarczy końcówka adresu dodana przez reklamę.
To jeden z tych szczegółów, które siedzą na styku marketingu i utrzymania sklepu. Osoba od reklam poprawnie oznacza ruch. Osoba od serwera poprawnie sprawdza stronę główną. A rzeczywisty adres, pod który trafia klient, potrafi zachowywać się zupełnie inaczej.
Ten sam produkt, różne adresy
Cache to gotowa kopia strony. Zamiast za każdym razem uruchamiać WordPressa, pytać bazę i składać stronę produktu od nowa, serwer może oddać to, co już przygotował.
Tyle że link z newslettera wygląda na przykład tak:
/produkt/kubek/?utm_source=newsletter&utm_medium=email
A link z reklamy może mieć dopisany gclid albo fbclid, czyli identyfikator kliknięcia. Klient nadal ogląda ten sam kubek. Dla mechanizmu cache dodatkowe parametry mogą jednak oznaczać:
- „Pomiń gotową kopię”. Każde wejście z kampanii uruchamia generowanie strony od początku.
- „Zapisz osobną kopię dla tego adresu”. Przy identyfikatorze unikalnym dla kliknięcia powstają kopie, z których kolejny klient prawdopodobnie nie skorzysta.
To zależy od konfiguracji. Jeśli wszystkie warstwy cache już ignorują właściwe parametry, problemu nie ma. Sama obecność wtyczki do cache jeszcze tego nie potwierdza.
Najdroższy ruch może dostawać najwolniejszą wersję sklepu
Przy kilku wejściach różnica może przejść niezauważona. Po wysyłce newslettera albo zwiększeniu budżetu kampanii serwer dostaje naraz dużo pracy, której mógłby uniknąć.
Biznesowo wygląda to kiepsko: płacisz za sprowadzenie klienta, a potem każesz mu czekać na zbudowanie strony, którą sklep już ma gotową. Rośnie obciążenie, może wydłużyć się oczekiwanie, część osób może odpaść jeszcze przed obejrzeniem oferty.
Łatwo wtedy zacząć od zmiany hostingu albo szukać winy w reklamie. Tymczasem warto najpierw sprawdzić, czy poprawnie i świadomie korzystasz z mechanizmów cache przy obsłudze ruchu z kampanii.
Co robi z tym Cloudflare?
Cloudflare stoi przed serwerem sklepu. Reguła typu Transform Rule może usunąć wybrane parametry marketingowe z żądania, zanim trafi ono dalej. Dla serwera link z newslettera staje się zwykłym /produkt/kubek/.
Mechanika jest prosta: etykieta kampanii przestaje rozróżniać kopie tej samej strony. Przy odpowiedniej konfiguracji cache kolejne wejścia mogą korzystać ze wspólnej, gotowej odpowiedzi.
To nie włącza automatycznie cache całego sklepu. Koszyk, checkout i treści zależne od użytkownika nadal potrzebują swoich zasad. Reguła usuwa jedną z przeszkód w obsłudze stron, które można bezpiecznie podawać z cache.
A skąd analityka będzie wiedzieć, że klient przyszedł z reklamy?
Oryginalny adres zostaje w przeglądarce klienta. Cloudflare zmienia żądanie przesyłane dalej, bez przekierowania użytkownika na nowy URL. Tak działa URL Rewrite opisany w dokumentacji Cloudflare.
Analityka, która odczytuje parametry w przeglądarce, nadal ma do nich dostęp. Trzeba jednak sprawdzić własne wdrożenie: jeśli serwer wykorzystuje parametr do przypisania prowizji partnerowi, zmiany oferty albo pomiaru kampanii, usunięcie go zmieni działanie tej funkcji. Dlatego czyścimy uzgodnioną listę parametrów, a nie wszystko po znaku zapytania.
Co sprawdzić przed następną kampanią
Poproś osobę opiekującą się sklepem o porównanie tej samej strony produktu bez parametrów i z rzeczywistą końcówką linku reklamowego. Dla niezalogowanego klienta, przy kolejnych wejściach. Czy obie wersje trafiają w cache? Czy czas odpowiedzi jest podobny? Po zmianie trzeba też potwierdzić, że źródło wizyty nadal zapisuje się poprawnie.
Gotową regułę i szczegóły wdrożenia opisałem po angielsku na Shift64: jak usunąć parametry UTM i identyfikatory kliknięć za pomocą Cloudflare Transform Rule.
Przed zwiększeniem budżetu reklamowego sprawdź sklep pod adresem, pod który naprawdę wysyłasz klientów. Te kilka znaków po znaku zapytania potrafi zrobić różnicę.
