Kto z kim się komunikuje w tym modelu

W klasycznej konfiguracji przeglądarka użytkownika łączy się bezpośrednio z serwerami wszystkich dostawców, których tagi zainstalowałeś. Analityka, system reklamowy, narzędzie do nagrywania sesji, czat, mapy ciepła — każdy dostaje własne żądanie i każdy widzi adres IP, nagłówki przeglądarki i to, co przekazał mu tag.

W modelu serwerowym przeglądarka wysyła dane w jedno miejsce: pod adres w Twojej domenie, za którym stoi kontener działający na Twoim serwerze. Dopiero ten kontener decyduje, co i do kogo pojechać ma dalej.

Cała różnica sprowadza się do jednego zdania: pojawia się miejsce, w którym możesz podjąć decyzję. W przeglądarce takiego miejsca nie ma — tag dostawcy wysyła to, co ma zaprogramowane, i nie pytasz go o pozwolenie.

Warto od razu obniżyć oczekiwania w jednej kwestii. Fakt, że dane przechodzą przez Twój serwer, nie znaczy, że dostawcy dostają mniej. Domyślna konfiguracja przekazuje dalej praktycznie to samo, co wysłałby tag w przeglądarce. Ograniczenie zakresu to praca, którą trzeba wykonać osobno.

Co da się odciąć przed wysłaniem dalej

To najciekawszy praktycznie fragment i jednocześnie ten, o którym najrzadziej się mówi, bo wymaga pracy w kontenerze, a nie zaznaczenia opcji.

• Adres IP — możesz nie przekazywać go dalej albo przekazać w formie skróconej. Miejsce, w którym pierwotny adres jest widoczny, ogranicza się wtedy do Twojego serwera.

• Parametry adresu URL — to najczęstsze źródło wycieków danych, jakie widzę. Adresy e-mail w linkach z newslettera, tokeny z systemu, numery zamówień, treść zapytania z wyszukiwarki na stronie. W kontenerze serwerowym można wyciąć wszystko poza listą parametrów, które są potrzebne.

• Dane z formularzy i warstwy danych — jeśli developer przekazuje do warstwy danych więcej, niż powinien, kontener serwerowy jest ostatnim miejscem, w którym da się to zatrzymać przed wysłaniem na zewnątrz.

• Adres strony odsyłającej i szczegóły przeglądarki — bywają nadmiarowe dla celu pomiaru, a razem tworzą dość precyzyjny odcisk urządzenia.

Robię to zawsze w tej samej kolejności: najpierw spisuję, jakie dane są potrzebne do konkretnych raportów i decyzji, potem odcinam wszystko poza tą listą. Odwrotna kolejność — wysyłamy wszystko i zobaczymy, co się przyda — jest właśnie tym, przed czym przepisy o minimalizacji danych mają chronić.

Pliki cookie i ograniczenia przeglądarek

Drugi obszar, w którym model serwerowy zmienia sytuację, dotyczy identyfikatorów.

Przeglądarki traktują inaczej pliki cookie zapisane przez skrypt działający w przeglądarce i te ustawione w nagłówku odpowiedzi z serwera. Pierwsze mają w części przeglądarek skrócony czas życia, drugie podlegają łagodniejszym zasadom i mogą być dodatkowo oznaczone jako niedostępne dla skryptów.

Dla pomiaru to znaczy stabilniejsze rozpoznawanie powracającego użytkownika. Dla prywatności — rzecz mniej oczywistą i wartą powiedzenia wprost: trwalszy identyfikator to więcej danych o tej samej osobie, nie mniej. Dlatego uważam, że wydłużanie życia identyfikatora wymaga uczciwej informacji w polityce prywatności i sensownego okresu ważności, a nie maksymalnego dopuszczalnego.

Jest tu jeszcze jedna pułapka. Rozwiązania, w których własna subdomena jest tylko przekierowaniem do infrastruktury zewnętrznego dostawcy, przeglądarki potrafią rozpoznać i potraktować jak obejście. Kontener na własnej infrastrukturze to inna sytuacja niż wskazanie subdomeny na cudzy serwer, choć w opisach marketingowych oba bywają nazywane tak samo.

Czego server-side nie naprawia

Ta sekcja jest najważniejsza i dlatego omawiam ją z klientem, zanim policzymy koszt wdrożenia.

Nie zastępuje zgody. Jeśli użytkownik nie zgodził się na pomiar, nie wolno go mierzyć niezależnie od tego, przez jaki serwer dane przechodzą. Kontener serwerowy nie jest sposobem na ominięcie bannera i traktowanie go w ten sposób jest po prostu naruszeniem.

Nie zmienia tego, kto ostatecznie dostaje dane. Jeśli z kontenera wysyłasz zdarzenia do systemu reklamowego i narzędzia analitycznego, oba dostają swoje dane. Przekazanie do dostawcy z siedzibą poza Europejskim Obszarem Gospodarczym pozostaje przekazaniem, ze wszystkimi konsekwencjami, o których orzekały organy w Austrii i Francji. Można ograniczyć zakres, nie można zmienić adresata.

Nie zwalnia z obowiązków administratora. Wręcz odwrotnie: przejmujesz na siebie serwer, na którym przez chwilę leżą pełne dane. Trzeba więc zadbać o dostęp, logi i to, żeby przypadkiem nie zapisywać tam więcej, niż wysyłasz dalej. Widziałem konfiguracje, w których włączone na czas debugowania szczegółowe logowanie żądań zostało tam na miesiące.

Nie naprawia złego pomiaru. Jeśli konwersje liczą się podwójnie, po przejściu na serwer będą liczyć się podwójnie stabilniej.

Warunki, które trzeba znać przed decyzją

Kilka rzeczy ustalam z klientem, zanim cokolwiek zaczniemy konfigurować, bo późniejsza zmiana zdania jest droga.

Po pierwsze region, w którym stoi serwer. Jeśli argumentem za wdrożeniem jest ochrona danych, uruchomienie kontenera w Europie jest naturalnym wyborem i warto to zapisać w dokumentacji.

Po drugie właściciel infrastruktury. Kontener stojący u agencji oznacza, że przy zmianie agencji pomiar przestaje działać albo trzeba go przenosić w pośpiechu. Zawsze zalecam, żeby projekt należał do klienta, a agencja miała dostęp.

Po trzecie kompetencje na dyżurze. Kiedy przestaje działać tag w przeglądarce, tracisz część danych. Kiedy przestaje działać kontener serwerowy, tracisz wszystkie — i dowiesz się o tym z raportu, a nie z alertu, jeśli nikt takiego alertu nie ustawił.

Po czwarte — i to warto policzyć na spokojnie — czy skala ruchu i wartość decyzji podejmowanych na tych danych uzasadniają stały koszt utrzymania. To pytanie o proporcje, nie o technologię.

Dla kogo to jest, a dla kogo to przerost formy

Uważam, że wdrożenie ma sens w trzech sytuacjach. Pierwsza: firma ma realny problem z jakością danych, mierzalny i opisany, a nie przeczucie, że „coś nam ginie”. Druga: dane wyciekają do dostawców w sposób, który trzeba odciąć — parametry z danymi osobowymi w adresach, nadmiarowe skrypty zewnętrzne. Trzecia: firma prowadzi świadomą politykę minimalizacji danych i chce mieć jedno miejsce, w którym te decyzje są zapisane.

W małym sklepie z kilkoma zamówieniami dziennie i jednym narzędziem analitycznym to inwestycja, która nie zwróci się w niczym poza poczuciem nowoczesności. W takim przypadku uczciwie mówię, że więcej dadzą trzy godziny na poprawienie zgód, wycięcie zbędnych skryptów zewnętrznych i uporządkowanie zdarzeń.

Na koniec kalendarzowa uwaga. Google zapowiedział 16 marca wyłączenie starszej wersji Analytics, więc w tym roku i tak wiele firm przebuduje sobie pomiar. Jeśli taka przebudowa Cię czeka, jest to najlepszy moment, żeby zadać pytanie o architekturę — dużo lepszy niż migracja tagów jeden do jednego, a potem drugie wdrożenie za rok.