+375445023245
+375445023245Программная часть сайта — всё, что работает «под капотом»: база данных, программные модули, логика форм и корзины, интеграции с внешними сервисами и панель управления, через которую контентом можно заниматься без программиста. Для маркетолога это не отвлечённая техническая тема: именно в программной части живут события аналитики, работа форм, скорость загрузки и передача данных в рекламные кабинеты и CRM. Когда заявка не доходит до менеджера, когда счётчик показывает не то, что кабинет, когда после доработок сайта отваливаются конверсии — причина почти всегда здесь. Задача маркетолога — не программировать, а понимать устройство настолько, чтобы поставить задачу разработчику, проверить результат и не потерять данные при изменениях. Ниже — из чего состоит программная часть, что в ней должен контролировать маркетолог, чек-лист проверки перед запуском рекламы и порядок работы с подрядчиком.
Из чего состоит программная часть
Хранит товары, страницы, заказы, пользователей. Для маркетолога важна тем, что от её структуры зависит, можно ли выгрузить данные для анализа и товарный фид — и в каком виде.
Логика форм, корзины, личного кабинета, расчётов, фильтров. Здесь же живут ошибки, из-за которых заявка отправляется не туда или не отправляется вовсе.
Связь с CRM, платёжными системами, службами доставки, сервисами рассылок и коллтрекинга. Самое хрупкое место: интеграции ломаются молча, без предупреждений.
То, ради чего всё делается: возможность менять контент, цены и страницы без разработчика. Если для правки заголовка нужно писать программисту, программная часть сделана неудобно.
Порядок работ при создании обычно такой: проектирование базы данных, написание и интеграция модулей, тестирование. Маркетолог подключается не в конце, а на первом этапе — иначе окажется, что нужных полей и событий в системе просто нет.
Почему это важно маркетологу
Не ради технической эрудиции, а потому что от этого зависит, увидите ли вы результат своей работы в цифрах.
Маркетологу не нужно уметь программировать, но нужно уметь задать три вопроса разработчику: где срабатывает событие, куда уходит заявка и что сломается, если мы изменим эту страницу. Мы регулярно видим проекты, где реклама откручивается месяцами, а конверсии не считаются, потому что после доработки сайта отвалился счётчик. Никто не виноват: разработчик не знал, что это важно, маркетолог не проверил. Цена вопроса — весь бюджет за период.
Андрей Гусаров, основатель агентства GUSAROV
Что маркетолог должен контролировать
События настроены на все целевые действия и проверены; заявка доходит до менеджера и в CRM; в сделке есть поле «источник»; страницы открываются быстро и корректно на смартфоне; на страницах установлены счётчики аналитики и рекламные пиксели.
Как проверить: оставить тестовую заявку с телефона, посмотреть, пришла ли она и отразилась ли в аналитике как достижение цели.
Изменение шаблона, вёрстки или логики форм ломает события и разметку чаще всего. Проверка занимает десять минут, а обнаружение проблемы «само» — недели потерянных данных.
Что внести в регламент: после каждого релиза — тестовая заявка, проверка счётчиков и событий, проверка товарного фида, если он есть.
Тестовая заявка со смартфона и с компьютера, скорость загрузки ключевых страниц, работа интеграции с CRM, корректность выгрузок. Интеграции отваливаются молча: токен истёк, сервис обновил протокол, разработчик что-то поправил.
Тексты и заголовки страниц, метаданные, цены, добавление новых страниц и разделов, установка кодов аналитики. Если для этого нужна задача разработчику, работа маркетолога тормозится на недели — и это повод пересмотреть систему управления, а не терпеть.
Как ставить задачу разработчику
Чек-лист проверки сайта маркетологом
Тестовая заявка с компьютера и со смартфона; проверка, что письмо или сделка дошли; работа формы при ошибке заполнения; подтверждение для пользователя после отправки; обработка обращений в нерабочее время.
Счётчики установлены на всех страницах, включая страницу благодарности; цели настроены на ключевые действия; события срабатывают — проверяется в режиме реального времени; UTM-метки не теряются при переходах внутри сайта.
Проверка скорости ключевых страниц инструментами измерения; открытие сайта на реальном смартфоне, а не в эмуляторе; проверка оформления заказа целиком с телефона — именно там чаще всего обрывается путь.
Возможность править заголовки и описания страниц; корректные адреса страниц; отсутствие дублей; работа перенаправлений при изменении адресов. Что происходит, когда с этим не разобрались, — в материале об алиасах и склейке зеркал.
Действующий сертификат безопасности; сайт открывается по всем вариантам адреса и отдаёт перенаправление на основной; страницы доступны для роботов поисковых систем; регулярные резервные копии.
Возможность выгрузить заявки, заказы и клиентов в таблицу; корректная кодировка выгрузок; товарный фид собирается из того же источника, что и цены на сайте.
Контекст: сайт на [какая система], задача маркетинга — [что хотим получить: например, видеть в CRM источник каждой заявки и считать стоимость продажи по кампаниям]. Что уже настроено: [счётчики, пиксели, CRM, интеграции].
Задача:
1. Сформулируй задачу разработчику через результат, а не через способ реализации.
2. Опиши критерии приёмки: что именно я должен проверить и как понять, что задача выполнена.
3. Перечисли, что уже работает и не должно сломаться при выполнении этой задачи.
4. Назови риски и побочные эффекты, о которых стоит предупредить заранее.
5. Предложи вопросы, которые я должен задать разработчику до начала работ.
Ограничения: пиши простым языком, я не программист; не предлагай решений, требующих смены системы управления сайтом, если об этом не сказано; отметь, что можно проверить самостоятельно без доступа к коду.
Что должен знать маркетолог, а что нет
Как устроен путь данных: от действия на сайте до строки в CRM и до рекламного кабинета. Где живут события, что такое пиксель и диспетчер тегов, почему ломаются выгрузки, как изменения на сайте влияют на аналитику и поиск.
Базовое представление о структуре страницы и разметке — чтобы понимать, о чём говорит разработчик, и самостоятельно находить ошибку в инструментах браузера.
Уметь программировать, верстать и настраивать сервер. Это отдельные профессии, и попытка совмещать их заканчивается тем, что обе задачи делаются вполсилы. Где проходит граница ответственности — в материале об обязанностях интернет-маркетолога.
Они закрыли барьер «я не понимаю, что мне отвечает разработчик»: техническое объяснение можно расшифровать за минуту, а задачу сформулировать корректно. Но проверка результата остаётся за вами — модель не откроет ваш сайт и не оставит тестовую заявку.
Частые вопросы
Что такое программная часть сайта?
Всё, что работает под внешней оболочкой: база данных, программные модули, логика форм и корзины, интеграции с внешними сервисами и панель управления. Её создание идёт по порядку: проектирование базы данных, написание и интеграция модулей, тестирование. Результат — возможность управлять сайтом без участия программиста.
Зачем маркетологу разбираться в программной части?
Потому что в ней живут события аналитики, работа форм, скорость загрузки и передача данных в рекламные кабинеты и CRM. Когда заявка не доходит до менеджера или после доработок сайта пропадают конверсии, причина почти всегда там. Понимание нужно не для того, чтобы программировать, а чтобы поставить задачу, проверить результат и не потерять данные при изменениях.
Что проверять после доработок сайта?
Тестовую заявку с компьютера и со смартфона, работу счётчиков и событий, корректность товарного фида, если он есть. Изменение шаблона, вёрстки или логики форм ломает разметку чаще всего, и обнаруживается это обычно через недели потерянных данных. Проверку стоит внести в регламент работы с разработчиками.
Как правильно поставить задачу разработчику?
Через результат, а не через способ реализации: «нужно видеть в CRM источник заявки» вместо «добавьте скрытое поле». Заранее договоритесь о критерии приёмки — как именно вы проверите, что задача выполнена, — и перечислите, что уже работает и не должно сломаться.
Что должно быть доступно маркетологу без программиста?
Правка текстов и заголовков, метаданные страниц, цены, добавление новых страниц и разделов, установка кодов аналитики. Если для изменения заголовка нужна задача разработчику, работа тормозится на недели — это повод пересмотреть систему управления сайтом, а не мириться с ситуацией.
Нужно ли маркетологу уметь программировать?
Нет. Нужно понимать путь данных от действия на сайте до строки в CRM и рекламного кабинета: где срабатывают события, что такое пиксель и диспетчер тегов, как изменения на сайте влияют на аналитику и поиск. Вёрстка, программирование и настройка сервера — отдельные профессии.
Как часто проверять техническую часть сайта?
Раз в месяц плановая проверка — тестовая заявка с двух устройств, скорость ключевых страниц, работа интеграции с CRM и выгрузок. И обязательно после каждой доработки сайта. Интеграции отваливаются молча: истёк токен, сервис обновил протокол, разработчик что-то поправил.
Технические вопросы, с которыми маркетолог сталкивается чаще всего:
- Веб-аналитика для оптимизации сайта — события, цели и что смотреть в отчётах
- Посетитель сайта: визиты и уникальные посетители — почему цифры в разных системах не совпадают
- Кодировки: почему ломаются выгрузки и фиды — и как это чинить
- Алиасы, зеркала и перенаправления — техническая база, которую ломают при переездах
- Первый экран сайта — что влияет на конверсию, а что только кажется важным
- Брошенная корзина — где на самом деле теряются заказы
Техническая база для маркетолога без программирования — часть программы курса интернет-маркетинга EDUGUSAROV: аналитика и события, работа с данными и CRM, постановка задач подрядчикам, нейросети в каждом задании. Для поисковой части — курс по SEO. Практика на реальных проектах, проверка специалистами агентства GUSAROV. Первый урок бесплатно, возврат 100% в течение 7 дней.
Смотрите также другие термины в Wiki интернет-маркетолога и материалы раздела о разработке сайтов.
