Отслеживание и сбор данных является одной из ключевых составляющих успеха бизнеса в интернете. В этой статье я расскажу о том, как происходит отслеживание, какие методы бывают, их преимущества и недостатки, а также поделюсь своим опытом использования нового способа отслеживания - 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 есть значительные преимущества? А есть ли недостатки?
Как это часто бывает, каждый из альтернативных способов имеет свои преимущества и недостатки. Я постаралась свести их воедино в понятную таблицу (подчеркнуты преимущества).
Аспекты | Client-side | Server-side |
Простота внедрения | Прост во внедрении. Зачастую существуют уже готовые фрагменты кода, которые можно скопировать и внедрить. | Потребуется дополнительное время разработчиков на установку и запуск облачного сервера |
Тестирование и отладка | Проще тестировать | Нет привычных инструментов отладки |
Стоимость | Как правило, дешевле, т.к. не нужно платить за облачный сервер | Как правило, дороже |
Безопасность/Защита данных | Лимитированный контроль за тем, какие данные собираются | Более защищенный; высокая степень контроля над экземпляром сервера и передачей данных третьим сторонам |
Приватность/комплайенс | Не отвечает современным запросам на приватность данных | Соблюдаются требования приватности; поскольку server-side tracking - это сбор данных первой стороной, (а сбор данных третьей стороной не происходит), он соответствует различным регламентам по защите персональных данных, например, GDPR |
Скорость загрузки страниц | Скорость загрузки страниц снижается, особенно если используются теги нескольких аналитических систем (они увеличивают нагрузку на браузер/мобильное устройство) | Быстрее; конечные пользователи получают улучшенную производительность за счет снижения нагрузки тегов, выполняемых в браузере/устройстве пользователя. |
Точность данных | Блокировщики рекламы, различные браузерные ограничения и удаление пользователями cookie негативно влияют на точность сбора данных | Поскольку все запросы обрабатываются на стороне сервера, а не на стороне браузера, блокировщики рекламы, ITP никак не влияют на точность данных |
CRM/offline данные | Нельзя добавить (ввиду прямого взаимодействия конечных систем и браузера/мобильного устройства) | Можно добавить релевантные CRM данные, например по событиям, произошедшим уже оффлайн - за пределами сайта или приложения |
На последнем пункте имеет смысл остановиться отдельно. Он зачастую опускается при перечислении основных преимуществ и недостатков способов трекинга, однако, на мой взгляд, может оказывать существенное влияние на ваши бизнес-процессы, например улучшить эффективность вашей рекламы.
Что за CRM данные и чем они могут быть полезны при трекинге?
Некоторые отслеживаемые события, которые имеют большое значение как для аналитики, так и непосредственно для настройки эффективных рекламных кампаний, происходят вне среды браузера или приложения пользователя.
Например, продолжительное время я сотрудничала с компаниями в сфере Fintech, и такими событиями для них являлись подтвержденный перевод или подтвержденный депозит (в отличие от неподтвержденного депозита, событие по которому происходило в приложении). Эти данные были доступны в CRM системе, и добавление их в систему аналитики предоставляет возможность анализа более “полезных”, более коррелирующих с прибылью данных. Кроме того, их непосредственное добавление в рекламный аккаунт в качестве цели, могут повысить эффективность работы этих кампаний (т.к. алгоритм в качестве цели будет ориентироваться на более “полезное” для бизнеса событие). Собственно, эти предположения оправдались. Эффективность рекламных кампаний по ROI возрастала на 10-20%.
Так какой способ лучше выбирать? Выводы
Ответ на этот вопрос зависит от того, какими возможностями вы располагаете и какие данные и для каких целей собираете. Если для вас в приоритете сэкономить время (как на внедрение, так и на тестирование, отладку и устранение ошибок) и деньги, то выбирайте client-side tracking. Именно этот способ является привычным и стандартным при отслеживании. Если у же есть потребность в дополнительной точности данных, их конфиденциальности, передаче событий из CRM, и у вас есть возможность направить ресурсы разработчиков на подобный проект - server-side tracking может стать хорошей альтернативой.
