Отслеживание и сбор данных является одной из ключевых составляющих успеха бизнеса в интернете. В этой статье я расскажу о том, как происходит отслеживание, какие методы бывают, их преимущества и недостатки, а также поделюсь своим опытом использования нового способа отслеживания - server-side tracking  - в Fintech индустрии. Я постаралась рассказать об этом простыми словами и понятно структурировать информацию (мне в свое время не хватало именно таких статей для погружения в тему), и очень надеюсь, что эта статья будет для вас полезной. 

Итак, начнем. 

Выделяют два основных вида отслеживания потока транзакций: client-side tracking и server-side tracking. 

Кто тут клиент, а кто тут сервер?

Для начала, давайте разберемся, что такое “клиент” и “сервер”, т.к. отсутствие понимания этих терминов часто приводит к путанице.

Допустим, вы решили посетить вебсайт. То, что реально произойдет в этом случае - ваш браузер загрузит для вас копии страниц и покажет их вам. Для этого ваш браузер, подобно клиенту в ресторане, сделает запрос на получение определенных страниц, а центральный компьютер отправит - “сервирует” - эти данные для браузера. Таким образом, ваш браузер выступит в роли клиента, а центральный компьютер, обладающий данными - страницами вебсайта - сервером. Помимо веб-браузера, клиентами могут быть, например, ваше мобильное устройство или приложение. 

А как тут участвуют идентификационные теги? 

Дело в том, что помимо копий страниц, ваш браузер или приложение зачастую загружает идентификаторы - кусочки кода, которые запоминают ваш браузер (например, файлы cookies)  или устройство и собирают информацию о посещенных страницах, времени посещения, и т.д. Эти данные затем используются аналитиками данных или маркетологами для решения бизнес-задач. 

Так, понятно, а что за методы сбора данных? Как они работают? 

Таких методов два - client-side tracking и server-side tracking. 

Client-side tracking, или сбор данных на стороне клиента является традиционным, более часто используемым методом. При таком методе добавление тега происходит как в примере выше - с помощью идентификатора в браузере или в приложении. Т.е. действие происходит на “клиентской” стороне - что и обусловило такое название. Информация отправляется напрямую из браузера пользователя или его мобильного устройства и поступает далее на сервер аналитического сервиса (например, это может быть нередко используемые Google Analytics для вебсайтов или Google Analytics for Firebase - для приложений). Взаимодействие клиента и аналитического сервиса происходит без посредников.

В качестве сноски замечу, что несмотря на то, что именно этот способ традиционно использовался для трекинга в качестве основного, в последнее время он вызывает все больше сомнений в бизнес- и технологических кругах из-за вопросов конфиденциальности и приватности данных. Дело в том, что client-side tracking опирается на использование third-party cookies, то есть на использование кусочков кода, созданного “третьей стороной” - напрямую не относящейся к вебсайту, который посещает пользователь (например, cookie, созданная рекламодателем, размещающимся на этом вебсайте). У самого вебсайта будет в этом случае крайне лимитированная информация и контроль над функционированием таких cookie. В результате, у пользователей могут возникать опасения, кто и как использует эти данные, собранные об их поведении онлайн. Этот аспект постепенно начинает регулироваться; так, согласно регламенту о защите данных в Европе (GDPR) вебсайты не могут больше использовать third-party cookies без согласия пользователя. В сфере мобильных приложений сами технологические компании делают шаги по изменению ландшафта трекинга из-за возросшего запроса на конфиденциальность данных. Например, взбудоражившая диджитал-сферу ликвидация включенного по умолчанию IDFA (Identifier for Advertisers) трекинга компанией Apple была подобным шагом. 

Server-side tracking (aka server-to-server, S2S), или сбор данных на стороне сервера. В этом случае отслеживание происходит не “на клиенте” - прямо в браузере или мобильном устройстве -  а на сервере. При такой схеме, веб-контейнер сохраняется, однако он будет значительно компактнее (а значит,  быстрее) и нацелен на сбор данных по интересующему событию (а не на выполнение множества скриптов разных систем - аналитики, third-party и т.д.). В этом случае third-party cookies не используются вовсе, то есть сбор данных осуществляется только первой стороной. При этом добавляется звено-посредник - облачный сервер. Этот облачный сервер принадлежит (точнее, арендуется) владельцу сайта/приложения.  Именно туда и направляется полученный запрос от клиента и данные по нему. Далее в облачном сервере происходит обработка данных и их перенаправление в конечные точки сбора. При этом степень управления и контроля над облачным сервером очень высока. Например, владелец облачного сервера определяет, какие именно данные и в каком виде будут доступны серверам третьей стороны.

А зачем нам усложнять процесс сбора данных звеном-посредником? 

Появление дополнительного звена в сборе данных - облачного сервера - нацелено на то, чтобы решить ряд сложностей, сопряженных с привычным, client-side tracking методом. В частности, наличие облачного сервера решает вопросы скорости загрузки страниц, контроля и приватности данных , а также блокировщиков рекламы, которые снижают точность собираемых данных. 

Получается, у server-side tracking есть значительные преимущества? А есть ли недостатки?

Как это часто бывает, каждый из альтернативных способов имеет свои преимущества и недостатки. Я постаралась свести их воедино в понятную таблицу (подчеркнуты преимущества).

На последнем пункте имеет смысл остановиться отдельно. Он зачастую опускается при перечислении основных преимуществ и недостатков способов трекинга, однако, на мой взгляд, может оказывать существенное влияние на ваши бизнес-процессы, например улучшить эффективность вашей рекламы. 

Что за CRM данные и чем они могут быть полезны при трекинге?

Некоторые отслеживаемые события, которые имеют большое значение как для аналитики, так и непосредственно для настройки эффективных рекламных кампаний, происходят вне среды браузера или приложения пользователя. 

Например, продолжительное время я сотрудничала с компаниями в сфере Fintech, и такими событиями для них являлись подтвержденный перевод или подтвержденный депозит (в отличие от неподтвержденного депозита, событие по которому происходило в приложении). Эти данные были доступны в CRM системе, и добавление их в систему аналитики предоставляет возможность анализа более “полезных”, более коррелирующих с прибылью данных. Кроме того, их непосредственное добавление в рекламный аккаунт в качестве цели, могут повысить эффективность работы этих кампаний (т.к. алгоритм в качестве цели будет ориентироваться на более “полезное” для бизнеса событие). Собственно, эти предположения оправдались. Эффективность рекламных кампаний по ROI возрастала на 10-20%. 

Так какой способ лучше выбирать? Выводы

Ответ на этот вопрос зависит от того, какими возможностями вы располагаете и какие данные и для каких целей собираете. Если для вас в приоритете сэкономить время (как на внедрение, так и на тестирование, отладку и устранение ошибок) и деньги, то выбирайте client-side tracking. Именно этот способ является привычным и стандартным при отслеживании. Если у же есть потребность в дополнительной точности данных,  их конфиденциальности, передаче событий из CRM, и у вас есть возможность направить ресурсы разработчиков на подобный проект - server-side tracking может стать хорошей альтернативой.