Автоматизация сбора CSS-путей для отслеживания кликов

В современных реалиях privacy-first (приоритет приватности) аналитики, когда браузеры агрессивно ограничивают сторонние файлы cookie, точность передачи данных через серверную передачу событий становится критической. Чтобы не полагаться на нестабильные идентификаторы, настраиваем кастомную переменную CSS-пути в Google Tag Manager для всех кликабельных элементов.

— Выберите тип переменной «Пользовательский JavaScript» в интерфейсе Google Tag Manager.
— Добавьте функцию, которая на вход принимает триггер клика и через метод `getPath` строит цепочку селекторов до корневого элемента.
— Пропишите исключения для динамических идентификаторов, чтобы путь не ломался при обновлении верстки фронтенда.
— Присвойте результат функции переменной, которую будете передавать в качестве параметра события (event parameter) в систему аналитики.
— Протестируйте корректность передачи пути в режиме предварительного просмотра (Preview Mode) на разных типах устройств — от десктопа до мобильных браузеров.
— Внедрите полученный CSS-путь в качестве основного атрибута для построения воронки внутри CDP-платформы, чтобы отвязаться от примитивных «клик по кнопке» в пользу конкретных путей пользователя.

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

— @CDProomRu

Как за неделю собрать минимальную CDP-схему для B2B-воронки

Если CDP пока нет, не начинайте с платформы. Начните с карты данных и одного сценария, который даст пользу маркетингу и продажам уже сейчас. Для Marketing ops в 2026 это важнее «идеальной» архитектуры: RevOps требует общих данных, а не отдельного отчёта от каждого отдела.

План на 5 шагов:

— Выберите один use case. Не «вся аналитика», а один путь: лид пришёл с вебинара → попал в CRM → получил письмо → дошёл до демо. Цель должна быть измеримой: больше встреч, выше конверсия в SQL, короче цикл сделки.

— Выпишите 10–15 обязательных полей. Оставьте только то, что реально влияет на запуск сценариев: email, company, должность, источник, дата первого касания, статус в CRM, согласие на коммуникации, продуктовый интерес. Всё остальное — потом.

— Назначьте один идентификатор склейки. Обычно это email, но для B2B лучше иметь правило: email как основной ключ, company + domain как запасной. Без этого вы не соберёте единый профиль клиента.

— Опишите 3 потока данных: сайт → трекинг-система, CRM → CDP, рассылки → CDP. Важно не «все события», а только те, что нужны для сегментации и триггеров: просмотр ключевой страницы, регистрация, ответ на письмо, создание сделки.

— Соберите один сегмент и один триггер. Например: все, кто был на странице цены, но не оставил заявку за 7 дней. Для них — передать список в рекламу и запустить письмо через sales-координатора или маркетинг-автоматизацию.

После этого проверьте 4 вещи:
— нет ли дублей профилей;
— все ли источники приходят с одинаковыми названиями полей;
— можно ли объяснить, откуда взялась каждая запись;
— видит ли этот сегмент sales без ручной выгрузки.

Если ответ «да» хотя бы по трём пунктам, у вас уже не «проект про CDP», а рабочий контур данных. Дальше масштабируйте не количество интеграций, а количество сценариев с измеримым эффектом на выручку.

— @CDProomRu

Identity resolution: зачем CDP «сшивает» клиентов

Identity resolution — это процесс связывания действий одного человека из разных источников в единую клиентскую запись. Проще: сайт, мобильное приложение, CRM, колл-центр и офлайн-покупка могут видеть одного и того же человека под разными идентификаторами, а CDP собирает их в один профиль.

Важно не путать identity resolution с дедупликацией. Дедупликация убирает дубли записей в базе. Identity resolution решает более сложную задачу: понять, что user_id, email, телефон, cookie и device_id относятся к одному клиенту, даже если данные пришли в разное время и с разной точностью.

**Типичные ошибки:**
— считать, что один email всегда = один человек: общий адрес в B2B ломает логику;
— склеивать профили только по жёстким ключам и терять большую часть анонимного поведения;
— объединять слишком агрессивно и смешивать разных людей в один профиль;
— не хранить историю связей: без неё невозможно объяснить, почему система приняла решение.

Пример: пользователь посмотрел товар на сайте без логина, затем оставил email в форме заявки, потом купил через мобильное приложение. CDP сначала создаёт анонимный профиль, потом связывает его с известным контактом и переносит всю историю касаний в один customer profile. Это база для нормальной сегментации, персонализации и измерения retention-эффекта.

— @CDProomRu

ЕЮ Иванов продолжает кошмарить АффПапу, конторку, которая накинула говна на вентилятор этим летом. Тогда в AffPapa не знали, с каким говном идут бодаться, поэтому заслуженно проиграли. 😏

На этот раз ЕЮ зарегал товарный знак AffPapa — совсем скоро имя компании будет официально принадлежать ему. Чтобы убедиться в трушности мува, переходим по ссыл-Очке и вводим серийный номер: 2026793242. Там видим, что заявка на регистрацию подана лично Евгением Юрьичем.

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

В арбитраже денег нет 💵

Архитектура доверия в эпоху RevOps

В 2026 году классическая воронка, где маркетинг лишь «отгружает» лиды (потенциальных клиентов) продажам, окончательно превратилась в архаизм. В условиях, когда поиск переходит на рельсы ответов от искусственного интеллекта, а стоимость привлечения растет, фокус смещается на Revenue Operations (выстраивание сквозных процессов выручки). В этой системе CDP (платформа клиентских данных) перестает быть просто хранилищем профилей, становясь единым источником истины для маркетинга, отдела продаж и службы заботы о клиентах.

Главная ошибка, которую я наблюдаю при внедрении CDP в крупных компаниях — попытка собрать «озеро данных» ради самого факта сбора. Технический директор или Marketing Ops (операционный маркетолог) часто тонут в интеграциях, забывая про Data Governance (управление качеством и доступностью данных). В результате мы получаем чистую систему, которая не дает ответа на вопрос: «Что именно удержит клиента, чей средний чек упал на 7%?».

Моя практика показывает, что при попытке объединить данные из CRM, сайта и службы поддержки, 40% атрибутов оказываются «шумом». Это бесполезные события, которые только замедляют работу моделей машинного обучения.

Вот три принципа, на которых должна строиться работа с данными сегодня:

— Приоритет событий, влияющих на LTV (пожизненную ценность клиента). Если действие пользователя не коррелирует с повторной покупкой, оно не должно занимать место в целевом сегменте.
— Атрибуция на основе моделирования маркетингового микса (MMM) вместо опоры на последний клик. Когда пользователь переходит через AI-обзор, старые методы трекинга слепнут. Вы должны видеть вклад каждого канала в выручку, а не только в клик.
— Единый идентификатор пользователя, который живет не только в браузере. В условиях privacy-first (приоритета приватности) архитектура должна опираться на First-party data (данные, собранные самой компанией напрямую).

Инвестируйте ресурсы не в количество коннекторов, а в очистку потоков данных. В эпоху, когда клиенты стали рациональнее, побеждает не тот, у кого больше данных, а тот, кто быстрее превращает их в персонализированный сервис, исключающий трение на пути к покупке. Если ваша CDP не помогает Customer Success (службе поддержки клиентов) предсказать отток до того, как клиент решил уйти, вы построили дорогую библиотеку, а не инструмент для роста выручки.

— @CDProomRu