WP: webhooks Яндекс.Метрики и GA4 для событий и сегментов в CRM и Ads
Вы наверняка знаете это ощущение: ночь, пустая кухня, кружка остывающего чая, а в голове шумит не вытяжка, а цифры. Заявок много, звонки капают, в CRM вроде движуха, а метрика и GA4 смотрят на вас стеклянным взглядом. Маркетинг поддерживает кострами, но огонь горит как то неровно, то вспыхнет, то угаснет, а понять, какой канал тащит и кого именно надо догреть, мешает одно слово — разрозненность. Я однажды так поймал себя на попытке вручную склеить визит в Метрике с номером заказа в CRM, потом еще криво загрузил CRM сегмент в Яндекс.Аудитории и получил ту самую ошибку валидации заголовка в файле CRM сегмента, после чего решил, хватит, давайте нормально. И вот с тех пор мой путь такой: WordPress шлет webhooks, Make.com собирает, чистит и разносим в GA4, Метрику и обратно в рекламу, чтобы сегменты CRM оживали и работали, как часы. Звучит взрослого, но по факту это обычная домашняя электрика — аккуратно разведенные провода, предохранители на местах и подсветка там, где ночью вечно спотыкаешься.
Секрет в том, что сайт на WP умеет говорить вовремя. Любая форма на сайте — от Contact Form 7 до Gravity Forms — может скинуть webhook в сценарий на Make.com, а дальше уже автоматика, без кода и бессонных ночей. События GA4 уходят по Measurement Protocol с сервера, где мы аккуратно прикручиваем client_id из куки, а иногда и user_id из CRM, Метрике отдаем либо офлайн конверсии, либо цель через серверный трекер, а данные о клиентах — в сегмент CRM Яндекс.Аудитории. Потом эти сегменты используют в Яндекс.Директ, а иногда и в VK Рекламе, и вся эта кухня позволяет собирать сегмент на основе CRM в один клик, причем с обновлением по расписанию, без менеджеров с флешкой CSV. А дальше начинаются вполне осязаемые вещи: ставки корректируются под тех, кто реально платит, холодных не мучаем, горячих догреваем, и расходы перестают прыгать, как ценник на такси после ливня.
Зачем вообще webhooks из WordPress и почему не хватит одного счетчика
Потому что события GA4, оформленные прямо с клиента, врут, а серверные честнее. Не из злого умысла, а из реальности — браузеры режут куки, люди блокируют скрипты, а интернет у всех иногда спотыкается. Когда WordPress после отправки формы или оплаты заказа отправляет webhook в Make, мы подхватываем событие моментально, обогащаем данными из CRM — метки кампаний, тип клиента, маржу, регион — и отправляем это в GA4 и Яндекс.Метрику сервером, без сюрпризов. Так рождаются события ga4 с нормальными параметрами, которые легко анализировать: revenue, order_id, lead_status, а не просто «кто то что то кликнул». Параллельно пишем в Google Sheets для удобной пикировки, шлем уведомление в Telegram менеджеру и, если надо, обновляем сегменты CRM, чтобы реклама увидела вчерашних покупателей и не пыталась продать им второй раз то же самое. Вроде мелочь, но когда таких мелочей сотни в день, в конце месяца это выглядит как приличный бонус к прибыли, и нервы в коробке не рассыпались.
На стороне WP это делается без шаманства. Поймали отправку формы, скинули чистый JSON в webhook, добавили пару крошек — user_agent, client_id из _ga, referral, согласие на обработку — и дальше всё в сценарии Make. Если сайт на WooCommerce, то webhooks есть штатно на создание заказа и изменение его статуса, а это значит, что серверные события уходят в момент оплаты, а не «когда нибудь потом». В РФ хватает CRM на любой вкус — Битрикс24, amoCRM, RetailCRM — каждая из них отдает контакт по ID, сделку по заказу, статус, и это клад для аналитики. Встраивая это в единый поток, вы реально начинаете видеть картинку: от визита до дохода, от звонка до повторной покупки, без гадания на кофейной гуще. Я люблю, когда данные перестают спорить между собой и, честно говоря, когда ночью можно наконец выспаться.
GA4 серверные события без боли и мистики
У GA4 есть Measurement Protocol для событий с сервера, и да, он живой и рабочий. В Make формируем запрос с api_secret и measurement_id, забираем client_id из куки _ga, которая прилетает в webhook вместе с формой, а если в CRM есть user_id — добавляем, чтобы сшивка стала крепче. События называем по делу — purchase, generate_lead, add_payment_info — и передаем параметры по человечески: currency, value, order_id, utm_source, utm_campaign, city, margin. Еще хорошо добавить engagement_time_msec и timestamp_micros, чтобы GA4 поняла, когда именно это случилось, а не кинула все в одну минуту. Для тестов удобно гонять в отдельный debugview, а потом уже выпускать на боевые проекты, чтобы не краснеть от дублей. Тут важно научиться в дедупликацию: если событие ушло с клиента и с сервера — добавьте event_id и включите правила, чтобы GA4 поняла, что это одно и то же. После этого отчеты перестают плыть, и вы видите реальный доход, а не виртуальную валюту из мира «кажется, сработало».
Яндекс.Метрика, цели и офлайн конверсии
С Метрикой тоже все работает, просто термины немного другие. Если у вас оформленные цели и ecommerce, можно отправлять серверные попадания и достижения целей, а для связки с Яндекс.Директ есть офлайн конверсии — отдали order_id, цену, время и нужные метки, и реклама стала умнее. Прелесть в том, что события привязываются к визиту, если корректно передан client_id Яндекса или связка по клику из Директа, и тогда корма для алгоритмов становится качественнее. При этом не обязательно городить велосипед, Метрика имеет готовые интеграции с CRM уровня Битрикс24, но через Make.com вы контролируете каждую мельчайшую деталь и не зависите от одного поставщика. По опыту, после включения офлайн конверсий и нормального фида в Метрику компании видят снижение себестоимости заявки и продаж, потому что модель начинает оптимизироваться под людей, которые действительно заплатили, а не только заполнили форму. А уж когда в CRM закрыли сделку, можно отдать Метрике маржу — и тут все превращается из спорта в бизнес.
Сегменты CRM для рекламы: от базы к результату
Самое вкусное начинается, когда вы берете базу, где у вас и покупатели, и отказники, и VIP, и те, кто пообещал вернуться весной, и превращаете это в сегмент на основе данных CRM. В Яндекс.Аудиториях это называется сегмент на основе CRM или просто CRM сегменты, которые потом подключаются в Яндекс.Директ для корректировок ставок, ретаргетинга и похожих аудиторий. Поток такой: Make по расписанию делает выгрузку из CRM, нормализует номера телефонов и email, складывает в CSV, кидает через API в Яндекс.Аудитории, ждет готовности сегмента и автоматически обновляет его. Если надо, делаем разные условия создания сегмента на основе CRM — отдельный сегмент crm Яндекс Аудитории для LTV больше 30 тысяч и другой для тех, кто брал рассрочку и еще не дозрел. А еще бывает сегмент на основе данных CRM Яндекс для оставивших контакты, но не дошедших до оплаты, который отлично заходит в связке с медийкой. После запуска таких штук реклама начинает работать как вежливый продавец: не лезет к тем, кто уже купил, подсказывает тем, кто сомневается, и прилично общается с теми, кто точно не ваш клиент, экономя бюджет и нервы.
И тут нас поджидает одна очень земная ловушка — ошибка валидации заголовка в файле CRM сегмента. Я пару раз на это попадался и каждый раз ругался на себя, потому что причина банальна. Яндекс.Аудитории хотят четкие названия колонок и аккуратную кодировку: в заголовке должны быть поля вроде email и phone, без заглавных букв, пробелов и вариаций в духе телефон, мобилка или E mail, файл в кодировке UTF 8 без BOM, разделитель запятая, а телефоны в формате +7XXXXXXXXXX, без пробелов и лишних символов. Emails приводим к нижнему регистру, очищаем от мусора и дублей, если хешируете — согласуйте алгоритм, но чаще проще грузить нормализованные значения. Еще баг дает лишняя пустая колонка или служебный индекс из CRM — его надо удалить, иначе валидация падает, и вы сидите и не понимаете, что случилось. По опыту, если сделать один раз подготовку и хранить шаблон с правильными заголовками, дальше это рутина, которую спокойно забирает на себя Make, а люди занимаются задачами для людей, а не ковыряют CSV ночью.
Практика в духе «сделал и дышу»: схема на Make
Сценарий, который люблю показывать ученикам, выглядит просто, почти скучно, и в этом его сила. Входной webhook от WP с полями формы или статусом заказа, дальше модуль к CRM за enriched данными — статус лида, сумма, источник, менеджер, потом ветка в GA4 Measurement Protocol со всеми параметрами, ветка в Метрику для целей или офлайн конверсий, файл CSV в буфере и отправка в Яндекс.Аудитории для обновления сегмента на основе CRM, финальным штрихом — сообщение в Telegram и запись в Google Sheets. Расписание запуска для сегментов ставим ночное, чтобы не висеть в очереди, а события шлем онлайн. Этот скромный конвейер покрывает 80 процентов бытовых задач, и даже если у вас пять проектов на одном WP, ничего не мешает развести их по разным сценариям, чтобы не путаться. Особенно приятно видеть, как через неделю исчезают разговаривающие сами с собой отчеты и остается одна внятная картинка, где каждое событие и каждый сегмент CRM понимают, зачем они здесь.
Случай из жизни: аренда авто и падение себестоимости
Компания по аренде авто пришла с понятной болью: звонков много, броней мало, экспериментов в рекламе еще больше, а понять, что продает, мешает вечная путаница с каналами. Сделали спокойную связку: WP отправляет webhooks при заявке и оплате, Make собирает, цепляет юзер айди, сшивает с CRM, шлет в GA4 и Метрику, а в Яндекс.Аудитории собирает два сегмента на основе данных CRM — оплатившие и те, кто прокатился один раз. В Яндекс.Директ настроили корректировки ставок и ретаргет по отказникам на мягчайших креативах, добавили исключение для тех, кто оплатил. Через три недели себестоимость целевого лида упала на 17 процентов, а доля повторных поездок выросла ощутимо, так как предложение на вторую поездку догоняло вовремя и на той площадке, где клиент реально сидит. Если честно, истории с чудесами я не люблю, но это не чудо, это нормальная работа данных, когда они наконец встречаются друг с другом и не ссорятся.
WordPress детали, которые спасают от судорог
Если вы на WP, мелочей нет, есть полезные привычки. Кладите client_id в скрытые поля форм — из _ga его можно достать коротким скриптом и передать в webhook, это плюс к сшивке. Для WooCommerce удобно ловить изменение статуса заказа и отправлять оплату как отдельное событие, чтобы не путать лид и покупку. Включите логирование в Make и на сайте — однажды это спасет вас от охоты на привидения, когда в отчете дубликаты, а виноват автоповтор запроса на стороне хостинга. Следите за часовыми поясами — GA4 любит точность времени, Метрика тоже, а сервер иногда живет в своём UTC. И не забывайте про согласие на обработку данных, это не формальность, его удобнее хранить в CRM и прокидывать в события флагом, чтобы не отправлять лишнего. Когда эти вещи стоят на месте, все остальное вращается гладко, и webhooks из WP становятся просто трубой, которая честно несет воду туда, где ее ждут.
Когда пора автоматизировать и куда идти учиться
Есть простой маркер: если вы руками выгружаете списки из CRM, грузите их в аудитории и потом еще бегаете проверять, дошло ли, значит вы все уже переросли и пора передать это роботу. Если раз в неделю ловите себя на словах «потом доделаю GA4 события» — тоже пора. У меня для этого есть короткий путь: мы учим собирать такие связки за считанные вечера, без погружения в программирование, но с пониманием, что куда течет и почему. Хотите научиться автоматизации рабочих процессов с помощью сервиса make.com и нейросетей ? Подпишитесь на наш Telegram-канал, там регулярно разбираем кейсы и выкладываем аккуратные разборы. Если хотите сразу в практику — вот программа Обучение по make.com, а если времени мало, а задач много — берите готовые Блюпринты по make.com, подключите свой WP, Метрику, GA4 и CRM, и пусть автоматика сделает свою часть работы. Регистрация на сам сервис тут, со скидками лояльности и бонусами экосистемы — Make.com, и не бойтесь интерфейса, через полчаса там все как дома.
Типичные ловушки и как из них выбираться без истерик
Дубликаты событий происходят чаще всего из за повторной отправки формы или автоповтора запроса веб сервера, поэтому ставим уникальные event_id и делаем идемпотентность в Make — если пришел order_id, который уже записан, не отправляем второй раз. Непойманные UTM метки убивают аналитику — подхватывайте их на клиенте и храните в CRM, а потом прокидывайте в серверные события, иначе источники превращаются в «прямые заходы». Ошибка валидации CRM файла в Яндекс.Аудиториях лечится названиями колонок и кодировкой, я уже говорил, но повторюсь — это десять минут на шаблон, экономит часы и нервы. Для GA4 будьте осторожны с пользовательскими параметрами — объявляйте их заранее в интерфейсе, иначе они теряются в неизвестности, и потом выглядит, будто вы ничего не передавали. И наконец, не доверяйте одному месту правды — храните слепки в Google Sheets или базе, иногда даже простая таблица спасает спор между аналитикой и CRM. Это не паранойя, это взрослый подход, после которого ставки начинают работать, а менеджеры перестают писать «а у меня другое».
FAQ
Можно ли настроить события GA4 и Метрики только на стороне сайта без Make
Можно, но вы лишитесь стабильности серверных событий и автоматического обновления CRM сегментов. Клиентские события режутся блокировщиками и не умеют в глубокую логику, тогда как сценарий в Make.com дополняет событие данными из CRM и отправляет его в аналитику даже если скрипт на странице не сработал. Это вопрос не моды, а качества данных и возможности вшить бизнес параметры в аналитику, без которых отчеты пустеют.
Как избежать ошибки валидации заголовка в файле CRM сегмента
Дайте колонкам ровно те имена, которые ждут аудитории — email и phone, без пробелов и заглавных, поставьте UTF 8 без BOM, разделитель запятая, телефоны в формате +7XXXXXXXXXX, email в нижнем регистре. Уберите служебные поля из CRM, пустые колонки и строки заголовков в середине файла. Если сомневаетесь — сначала загрузите маленький образец, проверьте, что сегмент создался, и только после этого автоматизируйте ежедневное обновление.
Что такое сегмент на основе CRM и где его использовать
Это аудитория, собранная из ваших контактов в CRM — телефоны и email клиентов, статусы сделок, категории лояльности. В Яндекс.Аудиториях такой сегмент подключается в Яндекс.Директ, на него можно делать корректировки ставок, исключения и похожие аудитории. Делают отдельные сегменты CRM под VIP, под отказников, под тех, кто давно не покупал, и это дает управляемость, которой не добиться только контекстными условиями.
Как привязать событие к конкретному визиту
Передавайте идентификаторы. В GA4 это client_id из _ga и по возможности user_id. В Метрике используйте clientID, а если событие связано с Яндекс.Директ, не забывайте параметры для офлайн конверсий, чтобы привязка к клику сохранилась. Вебхук из WP должен нести эти значения, Make их подхватывает и передает дальше вместе со временем события, тогда сшивка получается надежной.
Нужен ли программист, чтобы собрать такую схему
Нет, базовый стек делается без кода: WP отправляет webhooks, Make.com обрабатывает, GA4 и Метрика принимают серверные события через свои API. Если хотите пройти путь быстрее и без граблей, переходите на Обучение по make.com или забирайте готовые Блюпринты по make.com, там все шаблоны, ключи и тонкие настройки уже на месте.
