Дебатът „сървърна страна срещу клиентска страна“ от години е една от онези теми, където отговорът е искрено „зависи“, а всички мразят това. Ето разбираемата версия, без търговски приказки, включително честна таблица, която можете да изпратите на вашия CTO.
Какво всъщност представляват те
Проследяването от страна на клиента работи в браузъра на посетителя. Изпълнява се малък скрипт, който чете какво се случва (преглед на страница, кликване, дълбочина на превъртане) и изпраща тази информация директно до точка за събиране. Проследяването от страна на сървъра работи на вашата инфраструктура. Браузърът изпраща минимални данни до вашия сървър (или лек edge worker), който след това решава какво да препрати и къде.
Нито едно от двете не е по природа по-„приятелско към поверителността“ или по-„точно“ от другото. И двете могат да бъдат такива, в зависимост от конфигурацията. Различното е къде е контролната точка — и колко от истината достига до вас.
Таблицата с честни компромиси
| Измерение | От страна на клиента | От страна на сървъра |
|---|---|---|
| Усилие за инсталиране | Ниско — поставяне на фрагмент | По-високо — услуга и малък маршрутизиращ слой |
| Устойчивост на блокиращи реклами | Слабо — скриптът се блокира при източника | Силно — first-party крайна точка на вашия собствен домейн |
| Загуба на данни в съвременните браузъри | Значителна (Safari ITP, блокери, предотвратяване на проследяване) | Малка — вие сте собственик на повърхността |
| Скорост (латентност) при зареждане | Добавя една заявка от трета страна | Не добавя нищо, ако колекторът е кеширан на edge |
| Контрол върху това, което напуска вашата инфраструктура | Каквото реши скриптът на доставчика | Каквото решите вие |
| Лесно отстраняване на грешки | Мрежов раздел на DevTools | Сървърни логове — различно умение, но по-пълно |
| Разходи при мащабиране | Ниски, докато нивата на доставчика не се увеличат | Малка сметка за edge / функция, която наистина виждате |
| B2B идентификация на компанията | Работи, но е уязвима | Идеално съвпадение — сървърът може да преобразува IP → компания частно |
Последният ред е този, който B2B екипите трябва да разгледат най-дълго. Идентификацията от страна на клиента зависи от скрипт, който блокира или неутрализира нарастващ дял от посетителите. От страна на сървъра логиката за идентификация се поставя на вашата собствена инфраструктура, където не може да бъде тихо деактивирана от актуализация на браузъра.
Къде се вписва идентификацията на компанията
Идентификацията на компанията е естествена задача за сървърната страна. Браузърът трябва само да направи много малка заявка към first-party крайна точка на вашия собствен домейн. Тази крайна точка работи на edge (обикновено <20 ms в Европа), извършва частно преобразуването на IP към компания и не изпраща нищо обратно, което разкрива какво се е случило от страна на клиента. Потребителското изживяване не се променя. Пейзажът на блокерите се заобикаля. Порталът за данни остава в границите, които вие управлявате.
Това не е трик. Това е логично следствие от преместването на въпроса „кой е този посетител“ от клиента към услуга, която вие управлявате. Нищо не се променя в поведението на сърфиране на посетителя; променя се способността ви да виждате отговора.
Какво не е сървърната страна
Проследяването от страна на сървъра не е начин за заобикаляне на съгласието. Ако дадена дейност по обработка изисква съгласие, то остава такова, независимо къде работи кодът. Това, което сървърната страна променя, е количеството загуба на данни и контрола — не правното основание.
Бележка относно производителността
Хората често се страхуват, че „проследяването“ забавя страницата. В съвременните настройки това е страх от миналото. Добре изграден зареждач е само няколко килобайта, зарежда се отложено и се активира едва след като страницата стане интерактивна; добре изградена сървърна крайна точка отговаря за няколко милисекунди от най-близкия edge. Нито едно от двете няма да влоши вашите Core Web Vitals. Това, което ги влошава, е мениджърът на тагове с четиринадесет скрипта от трети страни, които никой не е проверявал от три години. По-малко, по-добре контролирани пътища за данни почти винаги са по-бързи.
Кога клиентската страна все още печели
Клиентската страна не е грешна. За по-малко критични анализи, при които приемате загуба на данни поради блокери (извадки от използване на продукта, UX събития в приложението, прости тестове на целеви страници), клиентската страна е по-бърза за внедряване и по-евтина за използване. Въпросът не е, че единият подход е универсално по-добър; въпросът е, че ако работата ви зависи от данните — B2B тръбопроводът е добър пример за това — пътят от страна на сървъра е по-устойчив и по-честен относно това, което прави.
Правилният въпрос не е „кой е най-добрият?“ Той е „за кое решение служат тези данни и колко загуба на данни може да понесе това решение?“ За въпроса „кой ни посети тази седмица“ — в идеалния случай без загуба. Отговорът на архитектурата следва от това.
Published by
lead.box Team
Още статии
Вижте lead.box върху собствения си трафик
Започнете безплатно — без карта, без задължително обаждане от продажби. Или си запазете 20-минутна демонстрация, ако предпочитате обиколка с водач.