Сквозная аналитика без cookies: server-side tracking, first-party IDs и дедупликация лидов

Прошлой осенью ко мне пришёл Марат из Алматы — у него свой интернет-магазин спорттоваров. Открывает ноутбук, показывает отчёты Google Analytics: 3 тысячи посетителей за месяц. Прям неплохо. Потом открывает Яндекс.Метрику — там 2 400. Уже странно. Дальше заходим в его CRM — там вообще 180 лидов. Ладно, думаю, может конверсия такая. Смотрим продажи — 12 заказов. Всего двенадцать.

«Саша, — говорит он, — я понимаю, что люди не все покупают. Но куда деваются остальные 2 988 человек? Они что, просто заходят, смотрят и уходят? Я же на рекламу 500 тысяч тенге в месяц трачу!» Сидим, смотрим в эти цифры, и я честно не могу ему ничего внятного сказать. Потому что его Google Analytics, Яндекс.Метрика и CRM живут как три отдельных государства без дипломатических отношений.

С 2023 года ситуация только обострилась. Apple с Safari начали резать cookies ещё раньше, Firefox подхватил инициативу. А Google Chrome, который всегда был на стороне рекламщиков (ещё бы, у них же весь бизнес на рекламе), тоже начал потихоньку выкручивать краны. Плюс GDPR в Европе превратился в реальную угрозу — штрафы миллионные, не пошутишь. В Казахстане тоже законы о персданных начали реально применять, а не просто пылиться на полке.

Помните старую схему? Повесил пиксель Facebook, прикрутил код Google Analytics, настроил ретаргетинг — и вперёд. Работало как часы. Сейчас работает как часы, которые то идут, то встают, то вообще показывают рандомное время. Половину посетителей просто не видно. Атрибуция врёт. Ретаргетинг показывает рекламу тем, кто уже купил — потому что система их не узнала.

Вот только есть одна деталь: компании, которые вовремя перестроились, чувствуют себя прекрасно. Пока их конкуренты гадают, откуда пришёл клиент — у них полная картина. Пока другие пытаются в Excel свести данные из пяти разных систем — у них всё в одном месте. Это как разница между старым телефоном с кнопками и современным смартфоном.

Дальше я покажу, как собрать аналитику, которая не зависит от милости браузеров и блокировщиков рекламы. Будем говорить про серверный трекинг, собственные идентификаторы пользователей, объединение дублей в CRM и реальные кейсы из практики. Поехали разбираться.

Почему старая модель аналитики умирает (и что с этим делать)

Давайте на минуту вернёмся к тому, как вообще работала веб-аналитика последние 20 лет. Вы заходите на сайт — и там скрипт Google Analytics или Яндекс.Метрики записывает в ваш браузер маленький текстовый файл, cookie. В нём всего одна строчка — уникальный идентификатор, типа «пользователь_12345678».

Возвращаетесь на этот сайт через неделю — система читает cookie, видит тот же самый номер и радостно понимает: «О, это же тот парень, который смотрел беговые кроссовки в прошлый вторник!» Красиво, элегантно, работает безотказно. Вот только работало. В прошедшем времени.

Теперь смотрите, что происходит с этим же пользователем, если он зашёл через Safari с айфона. Браузер берёт и удаляет все сторонние cookies через неделю. А если человек пришёл по рекламной ссылке — вообще через сутки. Получается, неделю назад он был «пользователь_12345678», а сегодня система выдала ему новый номер «пользователь_87654321». Для вашей аналитики это два совершенно разных человека. Хотя физически это один и тот же Димас, который просто не мог определиться с цветом кроссовок.

И вот тут начинается веселье. Конверсия у вас в отчётах падает — потому что первый визит и покупка выглядят как действия разных людей. Атрибуция сыпется — вы не понимаете, какой канал реально привёл к покупке. А ретаргетинг вообще превращается в комедию: показываете рекламу человеку, который уже купил, потому что система его не узнала после очередного удаления cookies.

Знаю, что сейчас скажут многие: «Ну это же только Safari с его блокировками. У нас в основном Android и Chrome — там всё нормально». Окей, давайте посмотрим на реальность. Берём статистику по казахстанскому e-commerce за последние полгода: Safari — это 25-30% всего мобильного трафика. Каждый третий-четвёртый человек с телефона. И знаете, что самое обидное? Владельцы айфонов в среднем покупают дороже — средний чек выше на 20-30 процентов. Получается, вы теряете данные именно по самым платёжеспособным клиентам.

А Chrome, говорите, нормально работает? Был нормальный. Google тоже начал зажимать краны со сторонними cookies — правда, делает это медленно и аккуратно, потому что у них вся рекламная империя на этом стоит. Но направление движения понятно: ещё год-два, и cookie-based аналитика станет музейным экспонатом, как те самые Flash-баннеры, которые когда-то были везде.

Поэтому дальше поговорим о том, как строить аналитику, которая будет работать и без cookies. Причём работать даже лучше, чем старая.

Server-side tracking: когда данные идут через ваш сервер

Обычная схема трекинга выглядит так: человек открывает вашу страницу, у него в браузере запускается JavaScript-код, и этот код отправляет данные напрямую в Google Analytics. Типа: «Эй, Гугл, тут пользователь №12345 посмотрел карточку товара за 50 тысяч тенге». Google записывает инфу в свою базу, вы потом смотрите красивые графики в отчётах.

Загвоздка в том, что современные браузеры и блокировщики рекламы научились перехватывать эти запросы. Safari с его Intelligent Tracking Prevention режет всё подряд. Браузер Brave вообще по умолчанию не пропускает трекеры. Даже обычный AdBlock Plus блокирует запросы к analytics.google.com. В результате значительная часть ваших данных просто испаряется в процессе передачи.

Server-side tracking переворачивает эту схему. Браузер отправляет данные не куда-то в Google, а на ваш собственный сервер. А уже ваш сервер, как посредник, отправляет эти данные дальше — в Google Analytics, Facebook, Яндекс.Метрику, в вашу CRM, куда захотите. Для браузера это выглядит как обычная работа сайта, обычный запрос к вашему домену. Ничего подозрительного, блокировать нечего.

Но это только первый уровень. Настоящая магия серверного трекинга начинается дальше: на своём сервере вы можете обогащать данные перед отправкой. Допустим, в браузере сработало событие «добавил товар в корзину». Ваш сервер получает это событие, лезет в CRM, смотрит: а, этот email уже есть в базе, это постоянный клиент, покупал три раза, средний чек 80 тысяч, последний заказ был месяц назад. И всю эту информацию можно добавить к событию перед отправкой в Google. Теперь в аналитике вы видите не просто «кто-то добавил товар в корзину», а «вернулся постоянный клиент, который обычно много тратит».

Плюс контроль над данными. Когда весь трафик идёт через ваш сервер, вы точно знаете, что и куда отправляется. Можете вырезать чувствительные персональные данные, фильтровать информацию по согласию пользователя, соблюдать все эти GDPR и казахстанские законы о персданных. Это не просто удобство — это реальная защита от штрафов и проблем с законом.

Как технически устроен серверный трекинг

Самое популярное решение сейчас — Google Tag Manager Server-side, сокращённо GTM SS. Это контейнер, который вы разворачиваете на своём сервере или в облаке (например, Google Cloud Platform). Браузеры отправляют события на этот контейнер, а он уже решает, куда их дальше направить: в Google Analytics 4, Facebook Conversions API, Яндекс.Метрику, напрямую в вашу CRM — настраивается всё через визуальный интерфейс, как обычный GTM.

Если возиться с серверами не хочется (а это нормально, не все же DevOps-инженеры), есть готовые SaaS-решения: Stape.io, Tracedock, Piwik PRO. Они предоставляют серверную инфраструктуру, вы просто подключаетесь и настраиваете правила. Цены начинаются от 20-30 долларов в месяц, что для многих компаний — копейки по сравнению с рекламным бюджетом.

Важная деталь: для серверного трекинга нужен отдельный субдомен вашего сайта. Типа tracking.yoursite.kz или analytics.yoursite.kz. Принципиально, чтобы это был first-party домен — то есть ваш собственный, а не какой-то стандартный от Google. Тогда браузер воспринимает его как часть вашего сайта, а не как сторонний трекер, и не блокирует запросы.

First-party IDs: ваш собственный идентификатор клиента

Ладно, с серверным трекингом разобрались — он решает проблему блокировки запросов. Но остаётся вторая проблема: Safari всё равно удаляет cookies через неделю, даже первопартийные. То есть если человек приходит на ваш сайт раз в две недели — для системы это каждый раз новый посетитель. Как быть?

Тут в игру вступают first-party IDs — ваши собственные идентификаторы пользователей. Суть простая: вы перестаёте полагаться на cookies от Google или Facebook и создаёте свою систему идентификации. При первом заходе на сайт ваш сервер генерирует уникальный номер для этого посетителя и записывает его в cookie. Но не в какой-то там сторонний google.com cookie, а в first-party cookie вашего собственного домена.

В чём принципиальная разница? Third-party cookie — это когда сайт yoursite.kz даёт команду браузеру записать cookie от имени домена google.com. Браузеры это прекрасно видят и говорят: «Хм, какая-то подозрительная штука, блокируем». А first-party cookie — это когда yoursite.kz записывает cookie на своё собственное имя. Браузер думает: «Ну это же обычная работа сайта, ничего криминального». И пропускает.

Технически всё выглядит примерно так: человек первый раз зашёл на ваш сайт. Сервер генерирует для него случайный уникальный идентификатор (UUID), что-то типа fp_user_abc123xyz, и записывает его в cookie с правильными флагами — HttpOnly, SameSite=Lax, Secure. Дальше этот cookie автоматически передаётся при каждом запросе к вашему сайту. Сервер видит знакомый ID и понимает: «О, это тот чувак, который вчера смотрел кроссовки за 35 тысяч».

Но настоящая магия начинается в тот момент, когда анонимный посетитель оставляет свои контакты — email, телефон, или вообще регистрируется. В этот момент происходит связывание: ваш анонимный first-party ID связывается с реальным человеком в CRM. И всё, дальше вы можете узнавать его на любом устройстве после логина. Зашёл с телефона — узнали. Через неделю пришёл с рабочего ноутбука — тоже узнали. Всё работает.

Это называется identity resolution или identity stitching — склеивание идентичностей. Один физический человек = одна запись в системе, независимо от того, сколько у него девайсов и браузеров. Без этой штуки сквозная аналитика просто невозможна.

Практический пример: как это работает в e-commerce

Давайте на конкретном примере. Есть у меня знакомая Асель из Алматы. Она листает Instagram в метро по дороге домой, видит вашу рекламу кроссовок. Кликает, попадает на сайт, пролистала пару карточек товаров, посмотрела, прикинула — и закрыла. Времени не было разбираться. Ваш сервер в этот момент создал для неё first-party ID, допустим fp_mobile_xyz123, и записал в cookie на телефоне.

Проходит три дня. Асель сидит дома вечером за ноутбуком, вспомнила про те кроссовки. Набрала название вашего магазина в Google, зашла на сайт. Это уже другое устройство, другой браузер, другой IP. Для системы аналитики пока что это «другой» посетитель. Сервер выдал ей новый ID — fp_desktop_abc789.

Но вот Асель решилась. Выбрала кроссовки, положила в корзину, начала оформлять заказ. Ввела свой email: asel.k@mail.ru. Бум. В этот момент система в CRM проверяет: а есть ли уже такой email? Есть — это тот самый посетитель с телефона три дня назад. Система связывает два ID через email и понимает: это один и тот же человек. Теперь вся цепочка — от клика по рекламе в Instagram до покупки на ноутбуке — сшита в один профиль клиента.

Без first-party ID и интеграции с CRM вы бы видели совсем другую картину: «Кто-то с айфона кликнул на рекламу и ушёл, конверсии нет» плюс «Кто-то с ноутбука пришёл через поиск и купил». Атрибуция полностью сломана. Instagram выглядит как слив бюджета, хотя на самом деле именно он привёл клиента.

О том, как правильно структурировать данные о клиентах и интегрировать их с CRM, мы подробно писали в статье Сквозная аналитика в CRM: UTM, источники, модели атрибуции.

Дедупликация лидов: один клиент — одна запись

Открою вам секрет: когда я захожу в CRM клиента первый раз, я всегда ищу одно — дубли. И находил их пока в 100% случаев. Один и тот же Иван Петров записан в базе три раза. Первая карточка — «Иван», потому что он так представился по телефону. Вторая — «Иван Петров», из заявки на сайте. Третья — «Ваня П.», потому что так подписался в WhatsApp. Три карточки, три истории касаний, три версии реальности. Полный бардак.

Откуда это берётся? Да просто данные летят из разных мест. Человек заполнил форму на сайте — создалась карточка. Потом позвонил, call tracking создал ещё одну. Написал в WhatsApp — и там менеджер завёл третью. Каждый канал живёт своей жизнью и создаёт своих контактов. Без умной системы дедупликации так и будет плодиться зоопарк дублей.

Для сквозной аналитики это убийца. Вы физически не можете посчитать, сколько раз человек взаимодействовал с компанией. Не можете понять, какой канал его привёл, а какой довёл до сделки. Не видите полную картину пути клиента — потому что она размазана по трём разным карточкам, которые система считает тремя разными людьми.

Как работает правильная дедупликация

Умные системы используют несколько уровней сопоставления данных. Вот как это выглядит на практике:

• Точное совпадение: если телефон +7 777 123 4567 уже есть в базе — всё, это тот же человек, не создаём новую карточку
• Нормализация: «8 777 123 45 67» и «+7 (777) 123-45-67» — это один номер, просто записан по-разному. Система должна привести к единому формату
• Нечёткое совпадение (fuzzy matching): «Иван Петров» и «Иван Петрофф» — очень похоже, возможно опечатка. Или «ivan.petrov@gmail.com» и «i.petrov@gmail.com» — скорее всего, один человек
• Косвенные признаки: одинаковый IP + похожий браузер + заказ на один и тот же адрес доставки — с большой вероятностью это один клиент

Критически важный момент: дедупликация должна работать в реальном времени, а не задним числом. Новый лид прилетел — система сразу проверяет базу: «А нет ли уже такого?» Если нашла совпадение — дополняет существующую карточку новой информацией. Если не нашла — только тогда создаёт новую. Это называется match-on-ingest или realtime deduplication. Иначе база быстро превращается в помойку дублей, которую потом хрен почистишь.

Когда дедупликация работает как надо, вы получаете Golden Record — «золотую запись» клиента. Это единственная правильная версия информации о человеке, собранная из всех возможных источников. Клиент мог кликнуть по рекламе в понедельник, позвонить во вторник, написать в WhatsApp в среду, заполнить форму на сайте в четверг — всё это лежит в одной карточке, с полной хронологией. Вся правда о человеке в одном месте.

И вот тогда сквозная аналитика начинает показывать реальную картину. Открываешь карточку клиента и видишь: пришёл из Google Ads 15 марта, оставил заявку на сайте, менеджер Алия звонила ему три раза, потом была долгая переписка в WhatsApp, прислали коммерческое в Telegram, 5 апреля он пришёл в офис и подписал договор на 500 тысяч тенге. Вся цепочка на одном экране, каждое касание учтено. Вот это и есть настоящая сквозная аналитика.

Подробнее о том, как построить единый профиль клиента и управлять качеством данных, читайте в статье Качество данных в CRM: как построить единый источник правды.

Модели атрибуции в мире без cookies: что выбрать

Атрибуция — это по сути ответ на вопрос «кто молодец?». Какой канал привёл клиента к покупке? На словах вроде просто, а на практике всё запутано. Потому что люди редко приходят, смотрят и сразу покупают. Обычно человек увидел вашу рекламу в Instagram, потом загуглил название компании, потом через неделю вспомнил и зашёл напрямую из закладок. Вот скажите, кому из этих трёх каналов засчитать конверсию?

Раньше, в эпоху рабочих cookies, большинство компаний использовали модель last-click — конверсия присваивается последнему каналу перед покупкой. Просто, понятно, не нужно заморачиваться. Но обманчиво до невозможности. Потому что если человек пришёл по прямой ссылке из закладок — конверсия пойдёт в «direct». А то, что изначально он узнал о вас из рекламы за 5 тысяч тенге — полностью проигнорируется.

Когда cookies начали сыпаться, проблема стала ещё хуже. Путь клиента начал разрываться на куски. Одно касание отслеживается, другое теряется, третье приписывается не тому. Last-click превратился в last-tracked-click — не последний реальный клик, а последний, который система смогла поймать. Это примерно как оценивать работу футбольной команды только по последней передаче перед голом, игнорируя всё, что было до этого.

В мире без cookies лучше всего работает связка: first-party data + server-side tracking + CRM как центр атрибуции. Когда все данные стекаются в вашу CRM и связываются в единый профиль клиента, вы можете строить атрибуцию на своих собственных данных. Не нужно верить на слово Google или Facebook — у вас есть полная картина.

Смотрите, как это работает: клиент первый раз пришёл через Google Ads (UTM-метки сохранились в CRM), через два дня получил письмо из email-рассылки и кликнул (система зафиксировала), ещё через три дня позвонил (call tracking передал источник в CRM), потом была встреча в офисе, и в итоге он купил. CRM видит всю цепочку от начала до конца. Вы сами выбираете модель атрибуции и смотрите честную картину — сколько на каждом этапе заработал каждый канал.

Практический совет для малого и среднего бизнеса в Казахстане: начинайте с U-shape атрибуции. Она даёт разумный баланс — 40% засчитывается первому касанию (это про привлечение), 40% последнему (это про закрытие), и 20% размазывается по всем промежуточным. Когда накопите больше данных и конверсий (хотя бы 300-500 в месяц) — можно включать data-driven модели, где машинное обучение само определяет веса каналов.

О том, как интегрировать данные рекламных систем с CRM и считать реальный ROI каналов, мы писали в статье CRM + Google Ads: реальный ROI рекламы.

Как внедрить: пошаговый план для бизнеса в Казахстане

Ладно, с теорией закончили. Теперь самое интересное — как это всё реально запустить. Я разбил процесс на пять этапов, чтобы можно было двигаться постепенно, кусочками, а не пытаться за один день перевернуть всю инфраструктуру. Потому что попытки сделать всё сразу обычно заканчиваются тем, что не работает ничего.

Важная вещь: не гонитесь за идеальностью с первого раза. Лучше запустить базовую рабочую версию за 2-3 недели и дальше по ходу улучшать, чем полгода строить «идеальную систему», которая к моменту запуска уже устареет морально. Я это видел много раз: компании годами планируют, готовятся, согласовывают, а в итоге так ничего и не запускают. Потому что «ещё не готово».

Ещё один совет из практики: начните с одного канала. Например, возьмите Google Ads — настройте для него полную сквозную аналитику от клика до денег в кассе. Убедитесь, что всё работает, цифры сходятся, отчёты показывают правду. И только потом расширяйте на Facebook, Яндекс.Директ, контекстную рекламу myTarget и всё остальное. Так вы быстрее получите первые результаты и поймёте, какие грабли обойти на следующих каналах.

Типичные ошибки при внедрении (и как их избежать)

За несколько лет работы с компаниями в Казахстане я насмотрелся на все возможные способы выстрелить себе в ногу при настройке аналитики. Причём ошибки повторяются из проекта в проект, как будто есть какой-то секретный чек-лист «как всё сломать». Вот топ-6 граблей, на которые наступают чаще всего.

Что получает бизнес: конкретные результаты

Хватит теории. Давайте посмотрим на реальные цифры. Вот что происходит с компаниями, которые внедрили всю эту конструкцию с серверным трекингом, first-party ID и дедупликацией в CRM. Данные собраны по нашим проектам за последний год.

Но цифры — это ещё не главное. Самое ценное изменение — качественное, в культуре компании. Когда маркетинг и продажи смотрят на одни и те же данные в одной системе, исчезают те самые вечные междоусобные войны. Помните классику? «Мы привели лиды, это вы их не закрыли!» — «Да вы привели полный мусор, а не лиды!» Теперь все видят единую картину: откуда пришёл клиент, как он двигался по воронке, на каком этапе застрял, почему купил или почему слился.

Меняется сам подход к принятию решений. Раньше было так: «Мне кажется, Instagram работает лучше, давайте туда больше денег». Теперь: «Смотрите данные — Instagram приводит много лидов, 180 за месяц, но конверсия в продажу всего 2%. А Google Ads приводит 60 лидов, зато конверсия 15%. С учётом среднего чека понятно, куда направлять бюджет». Факты вместо ощущений. Данные вместо политики.

Заключение: privacy-first — это не угроза, а возможность

Помню, как в 2020-м, когда Safari начал резать cookies по-серьёзному, в чатах маркетологов была настоящая паника. «Всё, приехали! Аналитика умерла! Как теперь работать вообще?!» Люди реально думали, что это конец эпохи. Прошло несколько лет, и стало ясно: аналитика не умерла. Она просто выросла, как Pokemon эволюционирует в более сильную форму.

Старые методы действительно больше не работают — с этим не поспоришь. Но новые работают объективно лучше. Серверный трекинг, свои идентификаторы, CRM как центр вселенной — это более надёжная, более точная и, что иронично, более приватная система, чем старая cookie-мешанина. Где раньше было десять систем с разными версиями правды, теперь одна система с полной картиной.

Компании, которые вовремя перестроились, сейчас в шоколаде. Они видят полный путь клиента от первого клика до последней копейки в кассе. Конкуренты видят обрывки и пытаются склеить их в Excel. Они принимают решения на основе реальных данных. Конкуренты гадают на кофейной гуще и надеются на лучшее. Они готовы к тому моменту, когда Google окончательно отключит third-party cookies. Конкуренты будут в этот момент бегать в панике и искать, кто виноват.

Если вы ещё не начали переход на privacy-first аналитику — вот прямо сейчас самое время. Не потому что завтра всё рухнет (хотя Chrome постепенно режет cookies уже сейчас). А потому что чем раньше начнёте, тем больше исторических данных накопите в новой системе. А данные о клиентах — это нефть цифровой экономики. У кого больше качественных данных, тот и выигрывает.

Начните с простого. Проведите аудит того, что есть сейчас — посчитайте, сколько процентов данных улетает в никуда. Внедрите first-party ID на сайте. Интегрируйте его с CRM. Постройте первый отчёт «канал → лиды → сделки → деньги». Поверьте, вы охренеете от того, насколько яснее станет видна настоящая картина вашего бизнеса.

Часто задаваемые вопросы

Читайте также