Server-Side GTM jak ATOM

S?ucha?em jaki? czas temu podcast z serii Technical Marketing Handbook od Simo Ahavy, którego go?ciem by? Adam Halbardier z zespo?u produktowego Google Tag Managera. W czasie rozmowy pojawi? si? w?tek transparentno?ci danych obs?ugiwanych przez kontener Server-Side.

Pomy?la?em sobie, ?e technologia serwowania tagów po stronie serwera jest jak energia j?drowa. Z jednej strony jest to wielkie udogodnienie dla ludzko?ci w postaci taniej energii, a drugiej strony ogromne zagro?enie – jak bomba atomowa.

Jedna technologia, dwa oblicza.

Uwaga: Temat dotyczy ca?ej technologii serwowania tagów (skryptów) po stronie serwera – nie tylko Google Tag Managera.

Jak jest zasadnicza ró?nica mi?dzy Server-Side a Client-Side Tag Management?

Do tej pory nasze kontenery dzia?y w 100% po stronie przegl?darki (Client-Side). Oznacza to, ?e wszelkie skrypty serwowane z poziomu takiego kontenera nawi?zywa?y kontakt i/lub wysy?a?y informacje bezpo?rednio do klientów końcowych np. Google Analytics, Google Ads, Facebook itp. Ka?dy narz?dzie wdro?one za pomoc? takiego kontenera nawi?zuje oddzieln? interakcj?, przez co zu?ywa moc obliczeniow? naszej przegl?darki (komputera).

Mimo ?e najcz??ciej takie skrypty s? asynchroniczne tzn. brak ich wywo?ania nie skutkuje wstrzymaniem pozosta?ego ?ledzenia, to i tak ich procesowanie zajmuje pami?? naszego urz?dzenia. Mniej pami?ci, to wolniejszy czas wczytywania strony, a w szczególno?ci tre?ci dla u?ytkownika. Ma to szczególnie du?e znaczenie przy wolniejszym po??czeniu internetowym.

Technologia server-side zmienia podej?cie i zamiast wielu ??dań do ró?nych klientów końcowych, z naszego urz?dzenia wychodzi jedno ??danie – do naszego serwera. W ramach tego ??dania przekazywane s? wszystkie informacje, które nast?pnie parsowane s? w kontenerze Server-Side. Stamt?d wysy?ane s? do poszczególnych klientów końcowych. Dzi?ki temu ?ci??ar” obs?ugi wielu klientów końcowych spoczywa na naszym serwerze. Im wi?cej klientów końcowych obs?ugujemy, tym znaczenie przy?pieszenie strony z wykorzystaniem server-side jest wi?ksze. Oczywi?cie przy?pieszamy czas ?adowania serwisu kosztem obs?ugi serwera, który b?dziemy musieli ponie?? po naszej stronie. Natomiast czego si? nie robi dla U?ytkownika ??

Czy przy?pieszenie czasu ?adowania strony to jedyna zaleta?

Nie.

W dobie privacy-first measurement budowanie rozwi?zań, które komunikuj? si? tylko ?z naszymi” zasobami jest szczególnie istotne tzw. privacy-centric measurement. Fakt, ?e przegl?darka nawi?zuje komunikacj? tylko z serwerem, który nale?y do nas jest równie? nie bez znaczenia w przypadku adblocków i rozwi?zań, które blokuj? tzw. third-party data. Z punktu widzenia ciasteczek mo?emy tworzy? równie? ciasteczka serwerowe, które maj? znaczenie w wybranych (na dzień dzisiejszy) przegl?darkach. Generalnie – s? bardziej trwa?e i traktowane jako mniej niebezpieczne.

Kolejnym argumentem z punktu widzenia privcy jest kontrola nad danymi, które przekazujemy do klientów końcowych. W przypadku kontenera Client-Side i tagów wdro?onych za jego pomoc? nie mamy kontroli, co tak naprawd? wdro?one skrypty pobieraj? z przegl?darki i przekazuj? dalej. Je?eli wszystkie informacje trafiaj? najpierw do nas na serwer, to mo?emy ?oczy?ci?” je naszym w?asnym kluczem i dopiero wówczas przekaza? klientom końcowym. Mamy pe?n? kontrol? nad tym.

Gdzie jest w takim razie wspomniane zagro?enie?

Czytaj?c powy?sze argumenty zastanawiasz si? pewnie, gdzie jest druga strona medalu. Server-Side na ?ród?o taniej energii – samo dobro.

Otó? problem le?y w?a?nie w temacie privacy i fakcie, co tak naprawd? jest przekazywane dalej klientom końcowym. Co do zasady w?a?ciciel kontenera powinien by? zgodny z zasadami GDPR i nie przekazywa? informacji personalnie identyfikowalnych (PII) stronom trzecim.

Jak? mamy pewno??? Niestety ?adnej.

Kto? powie – jest polityka prywatno?ci. Zgadzam si?, ale kto mi zagwarantuje, ?e to, co jest napisane w polityce prywatno?ci ma miejsce w rzeczywisto?ci.

Od tego s? urz?dy! No dobrze, ale jaki urz?d ma sprawdzi? co tak naprawd? wychodzi z serwera na nasz temat? Abstrahuj?c od kompetencji technologicznych w administracji państwowej. Ja sam jako analityk internetowy nie jestem w stanie tego stwierdzi?.

W przypadku Client-Side mia?em mo?liwo?? podpatrzenia co dok?adnie przekazywane jest do poszczególnych końcowych – korzystaj?c chocia?by z zak?adki Network w konsoli przegl?darki.

W przypadku, w którym dane wysy?ane s? z naszego serwera, czyli poza urz?dzeniem u?ytkownika, to u?ytkownik ten nie widzi, co tak naprawd? wychodzi. Mo?e zobaczy? jedynie nawi?zanie komunikacji przegl?darki z naszym serwerem. Natomiast nie wie, co dzieje si? na samym serwerze – czy te dane nie s? jako? wzbogacane.

Wszystko bazuje tak troch? na zaufaniu. Podobnie jak dzisiaj (abstrahuj?c od sytuacji politycznej) – nie mamy pewno?ci, ?e nie znajdzie si? jaka? nieobliczalna osoba i nie wykorzysta technologii j?dorowej przeciwko innemu narodowi, a skutki takiego dzia?ania pozostawiam Twojej wyobra?ni.

Przyznam szczerze, ?e sam zbagatelizowa?em temat po przes?uchaniu podcastu. Dopiero w momencie, kiedy otworzy?em dyskusj? na naszej grupie AnalyticsLab (zapraszam do do??czenia) otworzy?y mi si? oczy. Dlatego dziel? si? tym tutaj.

Daj zna? w komentarzu, co my?lisz na ten temat? Czy realne jest zagro?enie bomby atomowej w temacie #measurement? Czy Tobie jako u?ytkownikowi ?wiadomemu w ogóle istnieje potrzeba sprawdzania danych jakie wysy?a strona na Twój temat do trzecich ?róde? danych?