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

В прошлом году один маркетолог из Алматы показал мне свои отчёты. В Google Analytics было 3 000 посетителей за месяц. В Яндекс.Метрике — 2 400. В CRM — 180 лидов. А продаж — всего 12. «Где теряются остальные?» — спрашивал он с отчаянием в голосе. И знаете, что самое грустное? Я не смог ему ответить. Потому что его системы аналитики жили в параллельных вселенных и понятия не имели друг о друге.

Это было в 2023 году. С тех пор всё стало только хуже. Safari блокирует сторонние cookies уже несколько лет. Firefox тоже. Google Chrome — последний бастион рекламщиков — начал отключать third-party cookies в 2024-м. А тут ещё GDPR в Европе, CCPA в Калифорнии, да и в Казахстане законодательство о персональных данных ужесточается.

Результат? Маркетологи по всему миру хватаются за головы. Старая добрая модель — повесил пиксель, отследил пользователя, показал ретаргетинг — больше не работает. Или работает, но с такими дырами, что половина данных просто теряется.

Но есть и хорошие новости. Те, кто вовремя перестроился на новую архитектуру аналитики, оказались в выигрыше. Пока конкуренты гадают на кофейной гуще — у тебя цифры. Пока у них данные расползаются по десяти системам — у тебя единая картина. Разница ощутимая.

В этой статье я расскажу, как построить сквозную аналитику, которая работает без сторонних cookies. Будет про server-side tracking, first-party IDs, дедупликацию лидов и много практических примеров. Готовы? Погнали.

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

Давайте разберёмся, как вообще работала традиционная веб-аналитика. Вы ставите на сайт код Google Analytics или Яндекс.Метрики. Этот код создаёт в браузере пользователя маленький файл — cookie. В нём записан уникальный идентификатор: что-то вроде «посетитель №12345678».

Когда человек возвращается на сайт, система читает этот cookie и понимает: «А, это тот самый №12345678, который заходил неделю назад, смотрел кроссовки и ушёл». Всё просто и элегантно. Проблема в том, что это работало, пока браузеры разрешали такие фокусы.

А теперь представьте: пользователь зашёл с Safari. Браузер автоматически удаляет cookies через 7 дней. Или даже через 24 часа, если пользователь пришёл по рекламной ссылке. То есть неделю назад он был «посетитель №12345678», а сегодня — уже «посетитель №87654321». Два разных человека в глазах аналитики, хотя это один и тот же клиент.

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

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

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

Так что делать? Строить новую архитектуру. И вот о ней мы сейчас поговорим подробно.

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

Традиционная аналитика работает так: браузер пользователя напрямую отправляет данные в Google или Яндекс. Скрипт на странице говорит: «Привет, Google! Тут пользователь №12345 посмотрел страницу товара». Google записывает это в свою базу, а вы потом смотрите в отчётах.

Проблема? Браузер может заблокировать эту отправку. Ad-blocker? Блокирует. Safari ITP? Ограничивает. Brave? Вообще не пропускает ничего по умолчанию. В итоге часть данных просто теряется по дороге.

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

Но это только половина истории. Настоящая магия server-side tracking в том, что на своём сервере вы можете обогащать данные. Например, добавлять информацию из CRM: этот пользователь уже покупал раньше, у него такой-то сегмент, такая-то история взаимодействий. И отправлять в Google уже полную картину, а не обрывочные клики.

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

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

Самый популярный инструмент для server-side tracking — Google Tag Manager Server-side. Это контейнер, который разворачивается на вашем сервере (или в облаке Google Cloud) и принимает события от браузера. Дальше эти события маршрутизируются куда нужно: в Google Analytics 4, в Facebook Conversions API, в вашу CRM.

Для тех, кто не хочет возиться с инфраструктурой, есть готовые решения: Stape.io, Tracedock, Piwik PRO. Они предоставляют серверную часть как сервис — вы просто подключаетесь и настраиваете правила.

Важный момент: server-side tracking требует отдельного домена или субдомена. Например, `tracking.yoursite.kz`. Этот домен должен быть first-party — то есть принадлежать вам, а не Google или Facebook. Тогда браузер будет относиться к нему как к части вашего сайта, а не как к стороннему трекеру.

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

Окей, server-side tracking решает проблему блокировки запросов. Но что делать с тем, что Safari удаляет cookies через 7 дней? Даже если данные доходят до сервера, пользователь всё равно «теряется» через неделю.

Здесь вступают в игру first-party IDs — собственные идентификаторы, которые вы создаёте и контролируете сами. Идея простая: вместо того чтобы полагаться на cookie от Google или Facebook, вы генерируете свой уникальный ID для каждого посетителя и храните его в первопартийном cookie вашего домена.

В чём разница? Third-party cookie — это когда домен `google.com` записывает файл в браузер пользователя, находящегося на сайте `yoursite.kz`. Браузеры это блокируют. First-party cookie — когда домен `yoursite.kz` записывает файл для своего же сайта. Это разрешено и работает даже в Safari.

Технически это выглядит так: при первом визите ваш сервер генерирует уникальный UUID (например, `fp_user_abc123xyz`) и записывает его в cookie с флагом HttpOnly и SameSite=Lax. Этот cookie отправляется с каждым запросом к вашему серверу. Сервер видит идентификатор и понимает: «А, это тот же посетитель, что был вчера».

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

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

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

Допустим, Асель из Алматы увидела вашу рекламу в Instagram на телефоне. Перешла на сайт, посмотрела товар, ушла. Ваш сервер создал для неё first-party ID и записал в cookie.

Через три дня Асель вспомнила про ваш сайт и зашла напрямую — уже с ноутбука. Новое устройство, новый браузер. Пока это «другой» посетитель в глазах системы.

Но вот Асель решила купить и ввела свой email при оформлении заказа. В этот момент два ID (телефонный и ноутбучный) связались через email. CRM понимает: это один и тот же человек. Теперь вся история — от первого клика по рекламе до покупки — видна в одном профиле.

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

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

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

Знаете, что я чаще всего вижу в CRM-системах клиентов? Дубли. Много-много дублей. Один и тот же человек записан три раза: сначала как «Иван», потом как «Иван Петров», потом как «Ваня П.». Три разных карточки, три разных истории взаимодействий. Хаос.

Почему так происходит? Потому что данные приходят из разных источников. Форма на сайте создаёт один контакт. Звонок на call tracking — другой. Сообщение в WhatsApp — третий. И если у вас нет умной дедупликации, каждый источник создаёт новую запись.

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

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

Современные системы используют несколько уровней сопоставления (matching):

• Точное совпадение: телефон +7 777 123 4567 = +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-адрес + похожий user-agent + заказ на один адрес доставки — вероятно, это один клиент

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

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

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

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

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

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

В эпоху cookies-based аналитики популярной была модель last-click — конверсия присваивается последнему каналу перед покупкой. Просто, понятно, но обманчиво. Потому что первое касание (реклама) полностью игнорируется, хотя без него клиент бы вообще не узнал о вас.

Когда cookies перестали работать нормально, проблема обострилась. Путь клиента стал разрываться на куски. Одно касание отслеживается, другое — нет. Last-click превратился в «last-tracked-click», что далеко не одно и то же.

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

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

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

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

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

Теория — это хорошо, но давайте перейдём к практике. Вот конкретный план, как перейти на privacy-first аналитику. Я разбил его на этапы, чтобы можно было двигаться постепенно, а не пытаться перевернуть всё за один день.

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

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

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

За время работы с казахстанскими компаниями я насмотрелся на разные способы «выстрелить себе в ногу» при настройке аналитики. Вот самые частые ошибки — и как их не допустить.

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

Давайте от теории перейдём к цифрам. Вот реальные результаты компаний, которые внедрили описанную архитектуру сквозной аналитики.

Но цифры — это ещё не всё. Главное изменение — качественное. Когда маркетинг и продажи смотрят на одни и те же данные, исчезают вечные споры «мы привели лиды, это вы не закрыли» vs «вы привели мусор, а не лиды». Все видят полную картину: откуда пришёл клиент, как двигался по воронке, почему купил или не купил.

Это меняет культуру принятия решений. Вместо «мне кажется, Instagram работает лучше» — «данные показывают, что Instagram приводит много лидов, но конверсия в продажу в 3 раза ниже, чем у Google». Факты вместо ощущений.

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

Когда cookies начали блокироваться, многие маркетологи впали в панику. «Аналитика умирает! Как мы теперь будем работать?!» Прошло несколько лет, и стало понятно: аналитика не умерла — она эволюционировала.

Да, старые методы больше не работают. Но новые — работают лучше. Server-side tracking + first-party IDs + CRM как единый источник правды — это более надёжная, более точная, более приватная система, чем то, что было раньше.

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

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

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

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

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