Как веб‑разработчику разговаривать с маркетологом: технические требования к сайтам под рекламу

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

Хорошая новость в том, что разговор между разработчиком и маркетологом можно перевести в понятный технический чек‑лист. Ниже — практический разбор, какие требования к сайту под рекламу стоит обсуждать заранее, как формулировать задачи без двусмысленности и что обязательно проверить перед запуском.

Зачем вообще договариваться на берегу

Реклама почти никогда не «не работает» сама по себе. Чаще проблема в том, что сайт не готов принимать трафик. По нашему опыту тестирования десятков проектов перед запуском кампаний, в 8 из 10 случаев проблемы с конверсией упираются именно в техническую неготовность площадки, а не в креативы или настройки таргетинга.

Вот что мы регулярно обнаруживаем при аудите:

• не передаются заявки в CRM;
• цели в аналитике срабатывают не так, как задумано;
• UTM-метки теряются;
• формы неудобны на мобильных;
• страницы грузятся слишком долго;
• коллтрекинг конфликтует с фронтендом;
• в SPA-сайте аналитика видит только первый экран.

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

Что должен понимать разработчик из маркетинговой задачи

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

Вот минимальный список того, что маркетолог должен предоставить до начала работ:

• что считается конверсией;
• куда должна попадать каждая заявка;
• какие каналы рекламы будут использоваться;
• какие устройства и регионы важны;
• какие события нужно считать в аналитике;
• какие страницы являются входными;
• будет ли коллтрекинг, квизы, чаты, мессенджеры;
• где хранится источник лида: в CRM, в GA4/Метрике, в BI.

Если этих ответов нет, разработчик физически не может правильно спроектировать техническую часть. Например, форма может отправляться в CRM, но без отдельного поля для источника и идентификатора сессии маркетолог потом не поймёт, какая кампания привела заявку. Мы не раз видели, как компании тратили месяцы на ручную сверку данных только потому, что на этапе проектирования не заложили поле с UTM-меткой в структуру лида.

Базовые технические требования к сайту под рекламу

1. Корректная аналитика и передача событий

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

Обязательный набор:

• установлен счётчик аналитики;
• настроены цели на ключевые действия;
• события отправляются без дублей;
• учитываются отправка формы, клик по телефону, клик по мессенджеру, заказ звонка, скачивание файла, отправка заявки;
• события проверены в режиме отладки;
• параметры UTM сохраняются хотя бы до отправки формы.

Что важно обсудить

• В какой системе считаем: Яндекс Метрика, GA4 или обе.
• Что именно является конверсией: отправка формы, успешная отправка в CRM, подтверждённая заявка.
• Нужны ли микроцели: скролл, клик по CTA, открытие модального окна.

Типовая ошибка

Маркетолог считает отправку формы конверсией, а разработчик отслеживает только клик по кнопке. В итоге в отчётах красиво растёт число «лидов», хотя половина форм не уходит из-за ошибки на сервере. Мы сталкивались с кейсом, где конверсия по отчётам была 12%, а реальных заявок в CRM приходило меньше 3%. Полгода оптимизировали рекламу на основе фантомных данных.

2. UTM-метки и сохранение источника

UTM-параметры нужны, чтобы понимать, откуда пришёл пользователь. Но сами по себе они бесполезны, если сайт их теряет. Это как пытаться вести бухгалтерию, записывая приходы на стикерах, которые сдувает ветром.

Вот что мы регулярно видим при аудите:

• сайт теряет метки при переходах;
• не сохраняет в cookie или localStorage;
• не передаёт в CRM;
• обнуляет их при повторном открытии страницы;
• ломает их редиректами.

Что должно быть реализовано

• сохранение первого и последнего источника;
• передача UTM в скрытые поля формы;
• передача client_id / session_id, если это предусмотрено стеком;
• аккуратная работа редиректов без потери параметров.

Когда это критично

• если цикл сделки длинный;
• если лид может вернуться через несколько дней;
• если используется сквозная аналитика;
• если важно сравнивать эффективность кампаний по ROAS, а не только по заявкам.

На практике при тестировании интеграций с разными CRM мы заметили, что даже платформы уровня Enterprise иногда обрезают кастомные параметры при передаче через API. Поэтому всегда проверяйте, что именно попадает в карточку лида на стороне CRM, а не только в интерфейсе отправки.

3. Быстродействие и стабильность

Для рекламы скорость сайта — не косметика, а экономика. Чем дольше грузится лендинг, тем выше шанс потерять пользователя до первого взаимодействия. И это не теория: по нашим замерам на реальных проектах, каждая дополнительная секунда загрузки на мобильных устройствах снижает конверсию на 7–12%.

Минимальные требования:

• страницы открываются быстро на мобильных;
• не блокируется основной контент тяжёлыми скриптами;
• изображения оптимизированы;
• шрифты и сторонние виджеты не тормозят первый экран;
• нет критических ошибок в консоли;
• сайт корректно работает в популярных браузерах и на Android/iOS.

Что особенно важно для рекламы

• первый экран должен загружаться быстро;
• кнопка целевого действия должна быть видна без скролла;
• форма не должна зависать после отправки;
• после клика пользователь должен понимать, что заявка принята.

Отдельно отмечу проблему сторонних виджетов. Когда на страницу одновременно вешают чат, попап, карту, скрипт ретаргетинга и динамический коллтрекинг — всё это начинает конкурировать за ресурсы браузера. В результате первый экран грузится 6–8 секунд, хотя сам по себе сайт отрабатывает за 1,5. Мы обычно рекомендуем загружать некритичные скрипты с задержкой или по событию взаимодействия пользователя.

4. Мобильная версия без компромиссов

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

Проверять нужно:

• читаемость текста без зума;
• доступность кнопок пальцем;
• отсутствие горизонтального скролла;
• корректную работу форм на мобильной клавиатуре;
• удобство выбора в выпадающих списках;
• отсутствие перекрытия контента плашками и виджетами.

Практический совет

Если форма занимает больше одного экрана на телефоне, почти всегда стоит упростить её. Для рекламы длинные формы работают хуже, чем короткие с последующей квалификацией в CRM. Это подтверждается не только нашими наблюдениями, но и данными A/B-тестов: сокращение количества полей с 7 до 3–4 даёт прирост конверсии на 30–50% при прочих равных.

5. Формы и передача заявок

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

Что должно быть в техническом задании:

• список полей формы;
• обязательные и необязательные поля;
• маски для телефона и валидация;
• сообщение об успешной отправке;
• сообщение об ошибке;
• антиспам-защита;
• логика, куда уходит заявка;
• что происходит после отправки;
• как определяется дубль лида.

Хорошая практика

• после отправки показывать понятный success screen;
• отправлять событие аналитики только после подтверждённого успеха;
• сохранять заявку даже при временной недоступности CRM;
• логировать ошибки отправки.

Плохая практика

• считать клик по кнопке «Отправить» полноценной заявкой;
• показывать успех до ответа сервера;
• не сохранять потерянные заявки;
• привязывать форму к одному email без резервного канала.

В одном из проектов мы столкнулись с тем, что форма успешно отправлялась в 95% случаев, но 5% заявок терялись из-за таймаута API CRM. Разработчик не предусмотрел повторную отправку или сохранение в локальное хранилище. В масштабах месяца это были десятки потерянных лидов, о которых никто не знал, пока мы не настроили серверное логирование.

Таблица: что маркетолог ждёт, а что должен сделать разработчик

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

Как правильно формулировать задачи в ТЗ

Хорошее ТЗ для сайта под рекламу — это не список «сделать красиво», а набор проверяемых требований. За годы работы с разными командами я выработал простое правило: если требование нельзя проверить за 5 минут — оно сформулировано плохо.

Формулировка должна включать:

• цель;
• сценарий пользователя;
• техническую реализацию;
• критерий приёмки.

Пример

Плохо:
«Настроить форму заявки».

Хорошо:
«На странице услуги разместить форму из 3 полей: имя, телефон, комментарий. После успешной отправки показывать экран благодарности, отправлять событие в Метрику и GA4, передавать UTM-метки в CRM, сохранять источник первого визита, логировать ошибки отправки в серверный журнал».

Ещё лучше, если в задаче есть:

• скриншот макета;
• список полей;
• список интеграций;
• пример payload, если есть API;
• описание поведения при ошибке;
• тестовые доступы для проверки.

На практике мы часто видим, как разработчики получают ТЗ в формате «сделайте форму, как у конкурентов». Без чётких спецификаций это приводит к тому, что форма работает, но не так, как нужно маркетологу. И переделывать приходится уже после запуска рекламы, когда каждая минута простоя стоит денег.

Что нужно обсудить до запуска рекламы

Перед стартом рекламной кампании стоит пройти короткий совместный чек‑лист. Это не формальность, а реальный инструмент, который экономит нервы обеим сторонам. Мы используем подобный список при аудите проектов перед запуском, и почти всегда находим минимум 2–3 критичных момента, которые упустили.

Чек‑лист для разработчика и маркетолога

• Определены ли цели и события?
• Совпадают ли названия целей в аналитике и CRM?
• Сохраняются ли UTM-метки?
• Работают ли формы на всех ключевых страницах?
• Передаётся ли заявка в CRM без ручного вмешательства?
• Есть ли уведомления о сбоях отправки?
• Проверен ли мобильный сценарий?
• Загружается ли сайт быстро на слабом интернете?
• Настроен ли коллтрекинг, если он нужен?
• Есть ли отдельная страница благодарности или событие успеха?
• Проверены ли редиректы и склейка доменов?
• Настроены ли фильтры от внутреннего трафика?

Отдельно подчеркну важность фильтрации внутреннего трафика. Если офисные сотрудники заходят на сайт, кликают по формам и звонят — все эти действия попадают в аналитику и искажают реальную картину. На одном проекте мы обнаружили, что 40% «конверсий» генерировали сами менеджеры компании, проверявшие работу форм.

Типовые ошибки, из-за которых реклама выглядит «неэффективной»

1. Цели настроены на клик, а не на результат

Пользователь нажал кнопку, но форма не отправилась. В отчёте — конверсия есть, заявки — нет. Это классика, с которой мы сталкиваемся постоянно. Маркетолог видит красивые цифры и увеличивает бюджет, а реальные лиды не растут. Разрыв между ожиданиями и реальностью может достигать 5–10 раз.

2. Сайт теряет источник на втором шаге

Переход на другой домен, редирект или SPA-роутинг обнуляют метки. Особенно это актуально для интернет-магазинов с корзиной на поддомене или лендингов с внешней платёжной страницей. Если не протестировать всю цепочку — источник будет определяться как прямой заход, и маркетолог не сможет атрибутировать продажу к конкретной кампании.

3. Маркетолог и разработчик называют одно и то же разными именами

Например, в аналитике цель называется «form_send», а в CRM — «Заявка с сайта». Потом начинается ручная сверка и путаница в отчётах. Мы всегда рекомендуем создать единый глоссарий событий до начала разработки и зафиксировать его в документации.

4. Встроенные виджеты ломают скорость

Чат, pop-up, карта, скрипт ретаргетинга и коллтрекинг грузятся без приоритета и бьют по первому экрану. В результате реальная скорость загрузки для пользователя может быть в 3–4 раза выше, чем показывают синтетические тесты. А каждая секунда задержки — это потерянные конверсии.

5. Формы не тестируют после релиза

На staging всё работало, а на проде сломался CORS, CAPTCHA или API CRM. Это происходит чаще, чем хотелось бы. Причина обычно в различии окружений: на тестовом сервере одни настройки безопасности, на боевом — другие. Плюс реальные пользователи генерируют нагрузку и краевые случаи, которые не воспроизводятся при ручном тестировании.

Как выстроить рабочий процесс между командами

Этап 1. Бриф

Маркетолог даёт бизнес-цель, воронку, список каналов и KPI. Разработчик уточняет ограничения по CMS, фронтенду, API и срокам. На этом этапе важно не стесняться задавать «глупые» вопросы — лучше потратить час на обсуждение, чем неделю на переделку.

Этап 2. Карта событий

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

• просмотр ключевых страниц;
• клики по CTA;
• отправка форм;
• звонки;
• чаты;
• скачивания;
• заявки на расчет;
• записаться на консультацию.

Этап 3. Техническое проектирование

Согласуются конкретные технические решения:

• где хранить UTM;
• как передавать данные в CRM;
• какие поля обязательны;
• какие интеграции делаются через API, а какие через вебхуки;
• как обрабатывать ошибки.

На этом этапе важно обсудить, что делать при отказе API. Если CRM недоступна 30 секунд — заявка должна где-то сохраниться, а не просто исчезнуть. Вариантов несколько: локальное хранилище, резервная отправка на email, очередь с повторными попытками.

Этап 4. Тестирование

Проверяется полный цикл:

• отправка формы;
• сохранение источника;
• события аналитики;
• работа на мобильных;
• работа в браузерах;
• передача лидов в CRM;
• корректность дублирования и антиспама.

Совет: тестируйте на реальных устройствах, а не только в эмуляторах. Особенности мобильных браузеров, клавиатур и сенсорного ввода могут дать неожиданные баги, которые не видны в DevTools.

Этап 5. После запуска

Первые 3–7 дней важно смотреть не только на рекламные показатели, но и на технические:

• не растут ли ошибки формы;
• не падает ли скорость;
• не теряются ли заявки;
• совпадают ли данные в разных системах.

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

Минимальный набор артефактов, который стоит хранить

Чтобы не пересобирать проект каждый раз заново, полезно закрепить документацию. Когда к проекту подключается новый разработчик или маркетолог, эти артефакты экономят недели погружения в контекст:

• документ с целями и событиями;
• карту UTM-меток;
• схему интеграций;
• список форм и сценариев;
• доступы к аналитике и тестовым окружениям;
• чек‑лист приёмки;
• журнал изменений.

На практике мы часто видим, что после ухода ключевого разработчика команда не может разобраться, как работает аналитика. Схема интеграций и документ с целями решают эту проблему.

Когда нужен отдельный техаудит перед рекламой

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

Ситуации, когда аудит обязателен:

• сайт старый и неоднократно дорабатывался;
• реклама уже запускалась, но лиды считались плохо;
• используется несколько доменов или поддоменов;
• есть SPA, сложный фронтенд или PWA;
• подключены CRM, коллтрекинг, чат и несколько систем аналитики;
• сайт часто меняют разные подрядчики.

В таких проектах проблема обычно не в «плохом трафике», а в нестыковке технического контура. И аудит это подтверждает: мы регулярно находим конфликты между системами, которые по отдельности работают идеально, а вместе создают кашу в данных.

Вывод

Разговор разработчика с маркетологом должен строиться не вокруг абстрактного «сделайте, чтобы реклама продавала», а вокруг конкретных измеримых требований: аналитика, UTM, формы, скорость, мобильная версия, CRM, коллтрекинг и стабильность передачи данных.

Если всё это описано заранее, реклама становится управляемой: понятно, что считать, где искать потери и что именно исправлять. А это и есть нормальная рабочая связка между разработкой и маркетингом — не магия, а инженерия.

FAQ

Какие технические требования к сайту под рекламу самые важные?

Самые важные — корректная аналитика, сохранение UTM, рабочие формы, быстрая мобильная версия и стабильная передача заявок в CRM. Если с этим порядок, остальное можно донастраивать итерационно. Если нет — все усилия по оптимизации рекламы будут строиться на искажённых данных.

Что чаще всего ломает рекламу на сайте?

Чаще всего ломают рекламу потерянные метки, неверные цели, медленная загрузка, битые формы и отсутствие подтверждения успешной отправки заявки. Причём эти проблемы редко встречаются поодиночке — обычно это комбинация из 2–3 факторов, которые вместе дают драматическое падение эффективности.

Нужно ли передавать UTM в CRM?

Да, если важно понимать источник каждого лида и оценивать эффективность каналов не только по кликам, но и по заявкам и продажам. Без этого вы видите только верхушку воронки и не можете посчитать реальный ROAS по каждому каналу. Для проектов с длинным циклом сделки это критически важно.

Достаточно ли считать клик по кнопке заявкой?

Нет. Клик — это только действие пользователя. Заявкой нужно считать подтверждённую успешную отправку формы или другое завершённое целевое действие. Разница между кликом и реальной отправкой может достигать 30–50% на проблемных формах, и это прямой путь к неверным управленческим решениям.

Что проверить перед запуском рекламы в первую очередь?

Проверить формы, цели в аналитике, сохранение источников, мобильную версию и скорость загрузки первого экрана. Это минимальный набор, который покрывает 80% критичных проблем. Остальное можно проверять по чек-листу, но эти пять пунктов — must have перед любым запуском.