Keitaro на VPS нужен, чтобы связать источники трафика с лидами, которые собирают формы в WordPress. В результате ты получаешь понятную атрибуцию: какой клик привёл к заявке, какие кампании дают заявки, а какие — только посещения.
Рабочая схема выглядит так: пользователь кликает по трекерной ссылке Keitaro, на его стороне ставятся cookie/идентификаторы клика, затем он заполняет форму WordPress. При отправке формы WordPress делает серверный запрос (postback) в Keitaro, передавая идентификатор клика и данные лида.
Дальше Keitaro принимает conversion и отображает его в интерфейсе кампании.
Подготовка VPS и домена под Keitaro
Перед установкой важно привести сервер и домены к рабочему виду. Большинство проблем при запуске Keitaro — не в логике трекинга, а в доступности сайта, сертификатах и сетевых ограничениях.
Выбор VPS: ресурсы и система
Для старта не нужно «калибровать реактор». Keitaro и аналитика обычно комфортно работают на небольших мощностях, пока трафик не станет очень большим. Ориентируйся на типичный сценарий: один сервер под Keitaro, отдельный сервер или хостинг под WordPress.
По ОС чаще всего выбирают Ubuntu LTS. Если у тебя уже есть VPS под проект — используй то, что привычнее твоей команде, но оставь возможность обновлений и доступа по SSH.
Сеть, порты и firewall
Нужно открыть входящие порты только тем, что реально используется:
- 80/443 для HTTPS-доступа к интерфейсу и эндпоинтам Keitaro
- 22 для SSH (по возможности с ограничением по IP)
- остальные порты — только если они задействованы твоей схемой (обычно Keitaro прячут за reverse proxy)
На практике удобно поставить UFW и явно разрешить правила. Это снижает риск случайно «торчащих» сервисов.
Домен и SSL: минимальная рабочая настройка
Keitaro должен быть доступен по стабильному домену по HTTPS. Если у тебя ещё нет домена для трекера, делай отдельный поддомен, например:
- tracker.example.com
С SSL лучше не экспериментировать «вручную». Если VPS поддерживает автоматическую выдачу сертификата — используй её. После включения HTTPS проверь, что:
- интерфейс Keitaro открывается без предупреждений
- постбеки (запросы) уходят на HTTPS-адрес Keitaro и не ломаются на редиректах
Установка Keitaro на VPS
Keitaro можно поднять по разным сценариям. На практике чаще встречаются варианты с контейнерами и с установкой через инсталлятор. Смысл одинаков: ты получаешь работающий web-интерфейс, хранилище данных и доступность внешних эндпоинтов для постбеков.
Подготовка окружения
Сделай базовую подготовку:
- обнови пакеты
- установи Docker и docker-compose (если выбран контейнерный подход)
- выдели каталог для persistent volumes (чтобы данные не терялись при обновлениях)
Если у тебя в системе есть старые версии контейнеров или конфликтующие сервисы — разрули это до установки. Иначе отладка превратится в «где-то что-то занято».
Поднятие Keitaro и проверка доступности
После установки проверь три вещи:
- Web-интерфейс Keitaro открывается по URL.
- Сервер Keitaro может принимать входящие запросы с интернета на эндпоинт конверсий (postback).
- Система может отправлять исходящие запросы, если у тебя включены интеграции/проверки.
Полезный лайфхак: сделай тестовую страницу на WordPress или отдельный curl-запрос с твоей машины и убедись, что Keitaro отвечает так, как ожидаешь. Это быстрее, чем ждать первую «боевую» заявку.
Настройка базовой безопасности
Перед тем как запускать трафик:
- ограничь доступ к интерфейсу Keitaro по IP (если это возможно в твоей архитектуре)
- включи fail2ban или аналогичный подход для SSH
- проверь, что SSH работает по ключам, а не по паролю
- обновляй систему и контейнеры по расписанию
Если Keitaro доступен публично, безопасность интерфейса особенно важна. Трекер — это «мозг» связки, доступ к нему должен быть контролируемым.
Создание трекинга: кампании, источники и postback в Keitaro
Когда сервер готов, начинается настройка логики: откуда приходят клики и куда Keitaro должен получать conversion.
Создай кампанию и определись с параметрами атрибуции
В Keitaro создаётся кампания под конкретный источник (рекламный канал или связка). Обычно тебе нужно решить:
- какие параметры ты будешь использовать для атрибуции (например, subid, параметры кампании, идентификатор объявления)
- как Keitaro будет различать клики разных источников
Если у тебя несколько рекламных площадок, на старте лучше держать единый стандарт параметров. Иначе потом аналитика превращается в ручную уборку.
Настрой postback для лида
Keitaro должен получить данные о конверсии через postback URL, который ты забираешь из интерфейса Keitaro. Он обычно включает параметры, позволяющие привязать conversion к конкретному клику.
Важные принципы при настройке:
- постбек должен приходить один раз на одну реальную заявку
- в запросе должны быть идентификаторы, которые Keitaro сможет сопоставить с кликом
- тело запроса должно соответствовать формату, который ожидает Keitaro (часто это query-параметры или x-www-form-urlencoded)
Самый частый провал — отправить postback без идентификатора клика. В этом случае Keitaro либо не сможет корректно связать conversion, либо положит её в «никуда».
Подготовь поля лида для передачи
Обычно для контроля и сегментации нужны:
- email и/или телефон
- имя (если есть)
- страница или оффер
- сумма/тип услуги (если форма позволяет)
Данные лида лучше передавать вместе с conversion. Это ускоряет принятие решений и уменьшает ручную сверку с CRM.
Подключение Keitaro к страницам WordPress (скрипт и cookie)
Чтобы при отправке формы Keitaro мог связать заявку с кликом, на стороне браузера должны появиться идентификаторы. Чаще всего это достигается установкой скрипта трекинга Keitaro на страницы, куда попадают пользователи по трекерным ссылкам.
Размести JS-трекинг на странице формы
Смотри документацию Keitaro по установке JS и вставь трекинг на страницу WordPress, где пользователь видит форму. Цель простая: когда пользователь открыл страницу после клика, Keitaro должен «узнать» сессию и подготовить cookie/значения для дальнейшей передачи.
Практический вариант:
- если у тебя одна целевая страница — ставь скрипт на неё
- если их несколько — ставь скрипт на шаблон страницы с формой
Если используешь каскадные редиректы или много страниц между кликом и формой, трекинг лучше закрепить на всех ключевых шагах, чтобы идентификатор не потерялся.
Проверь, что cookie на стороне браузера реально появляются
После установки трекинга:
- открой страницу после перехода по трекерной ссылке
- проверь Storage/Cookies в браузере
- убедись, что на домене WordPress появились нужные значения Keitaro
Ошибки на этом этапе часто выглядят так: «postback в Keitaro приходит, но conversion не атрибутится». И причина — идентификатор клика в форме пустой или не соответствует формату.
Передача идентификатора клика в форму WordPress
Теперь главный мост между системами: при отправке формы WordPress должен отправить в backend (и дальше в Keitaro) то значение, которое Keitaro использует для привязки к клику.
Скрытое поле в форме: простой и надёжный подход
Оптимально добавить в форму скрытое поле, куда ты положишь идентификатор клика. Его можно заполнить:
- при загрузке страницы (с помощью JS, который читает cookie Keitaro)
- перед отправкой формы (если форма рендерится динамически)
Суть подхода: ты сохраняешь идентификатор клика в поле формы, а затем отправляешь вместе с остальными данными.
Пример логики без привязки к конкретному имени cookie:
- JS читает cookie, которые ставит Keitaro
- JS записывает значение в input name=»keitaroclickid»
- при submit формы это значение уходит в backend обработчик
Если у тебя форма строится через конструктор, скрытое поле добавляется через настройки поля или через шаблон. Если конструктор не даёт — можно сделать единый обработчик отправки, но тогда придётся подхватывать значение из cookie напрямую на клиенте.
Где именно брать идентификатор
Keitaro использует свой набор параметров и cookie. Поэтому правильнее работать так:
- посмотри в документации или в настройках трекера, какое значение используется для привязки конверсии
- выбери из него то, что нужно в postback (часто это клик-идентификатор или cookie-ссылка)
Если ты подставишь «не то» значение (например, параметр кампании вместо click id), Keitaro может принять запрос, но атрибуция будет неправильной.
Валидация на клиенте: чтобы не отправлять пустоту
Перед тем как вызывать postback или отдавать данные серверу, убедись, что hidden-поле заполнено. Минимальная проверка:
- если значение пустое — логируй в консоль и не отправляй lead в Keitaro (либо отправляй как «без атрибуции», но тогда теряется аналитика)
Такая защита особенно полезна при редиректах и кроссдоменных сценариях.
Отправка лида в Keitaro (postback) на стороне WordPress
Когда кликовые идентификаторы оказались в форме, остаётся сделать корректный серверный вызов в Keitaro при событии отправки.
Есть два рабочих подхода:
- WordPress вызывает Keitaro прямо с фронтенда (fetch на postback URL).
- WordPress принимает форму, затем серверно вызывает Keitaro (рекомендуется).
Второй подход обычно проще для отладки и меньше упирается в CORS, редиректы и ограничения браузера. Для нейтральной и «боевой» связки стоит делать серверный postback из WordPress.
Делай свой REST endpoint в WordPress
Создай эндпоинт, который будет принимать данные лида от формы и отправлять их в Keitaro. С точки зрения архитектуры ты получишь:
- единое место, куда приходят данные
- контроль формата запроса к Keitaro
- возможность добавлять недостающие поля (например, IP, user agent, utm)
Схема:
- форма отправляется обычным образом
- в обработчике формы или через webhook вызывается твой endpoint /wp-json/keitaro/v1/lead
- endpoint делает wpremotepost на postback URL Keitaro
Такой вариант также позволяет добавлять защиту, например секретный токен параметром.
Что отправлять в Keitaro вместе с постбеком
В postback обычно нужны:
- идентификатор клика (тот самый из hidden-поля)
- идентификатор кампании/оффера (если требуется)
- поля лида (email/телефон/имя)
- опционально: timestamp события или статус
Уточни формат в Keitaro: где именно ожидаются поля — в query-параметрах или в теле запроса. Если поле «не там», Keitaro может вернуть ошибку или записать conversion, но без нужных атрибутов.
Серверный запрос из WordPress: удобные настройки
В PHP обработчике (через wpremotepost):
- выставь разумный timeout
- обработай ответ Keitaro и залогируй ошибки
- не делай повторные запросы бесконечно (лучше ограничить ретраи)
Если запрос падает по сети, лучше вернуть форму пользователю с нормальным сообщением и параллельно залогировать, чем «зависать» на ожидании postback.
Как вызывать endpoint из разных типов форм
Здесь важен принцип, а не конкретный плагин:
- тебе нужно получить событие отправки формы
- на этом событии передать данные (хотя бы email/телефон + keitaroclickid) в твой REST endpoint
Если у тебя Contact Form 7, Gravity Forms, WPForms или Elementor Forms — у каждого свой способ хуков. Но суть одна: найти точку, где формируется итоговая запись, и там дернуть webhook/REST.
Лайфхак: если твой конструктор умеет «webhook on submit», подключай webhook напрямую на /wp-json/keitaro/v1/lead. Тогда не придётся лезть глубоко в код.
Тестирование связки: от клика до лида в Keitaro
Самый надёжный способ не упустить детали — тестовый прогон по шагам. Делай его перед включением рекламы.
Шаг 1: тестовый клик через трекерную ссылку
- открой в браузере инкогнито
- зайди по трекерной ссылке Keitaro
- убедись, что дошёл до страницы формы
После этого открой DevTools и проверь:
- cookie Keitaro появились на нужном домене
- hidden-поле заполнилось (или хотя бы JS-значение доступно)
Шаг 2: отправка формы с тестовыми данными
Введи тестовые email/телефон, отправь форму. Сразу проверь:
- отправилась ли форма на WordPress
- твой REST endpoint получил запрос
- endpoint попытался сделать postback в Keitaro
Если ты делаешь серверный postback, ошибки чаще всего будут в стороне WordPress (формат payload, timeout, неправильный URL Keitaro или SSL).
Шаг 3: проверка conversion в Keitaro
Перейди в Keitaro и посмотри:
- появилась ли conversion в нужной кампании
- присвоился ли клик (правильная атрибуция)
- корректно ли заполнены поля лида (email/телефон)
Если conversion появилась, но «не на тот клик», ищи проблему в идентификаторе клика: либо hidden-поле пустое, либо значение не соответствует ожидаемому формату.
Шаг 4: защита от дублей
На практике формы иногда отправляются дважды:
- пользователь нажал кнопку повторно
- плагин делает двойной submit
- браузер повторил запрос при проблемах сети
Чтобы это не ломало аналитику, добавь идемпотентность:
- перед отправкой postback проверь наличие уникального идентификатора лида (например, email + timestamp в разумном окне)
- или храни «last sent hash» на сервере в пределах сессии/периода
Это снижает ручную чистку результатов и делает отчёты стабильнее.
Типичные ошибки при связке Keitaro и форм WordPress
Ниже список проблем, которые встречаются чаще всего. Каждая сопровождается причиной и тем, что проверить в первую очередь.
Conversion приходит без атрибуции
Причины:
- hidden-поле не заполнено
- JS не успевает отработать до submit
- берётся не то cookie/значение
- идентификатор клика изменился из-за редиректа/кроссдоменности
Что проверить:
- значение в скрытом поле перед отправкой
- cookie в браузере
- как именно формируется postback payload
Keitaro не принимает postback или возвращает ошибки
Причины:
- неверный URL Keitaro (часто путают домен, порт или путь)
- проблема с SSL (сертификат на другом поддомене)
- firewall на VPS блокирует входящие запросы
- неверный формат параметров (поля отправлены не так, как ждёт Keitaro)
Что проверить:
- доступность URL Keitaro с внешней сети
- логи WordPress (где формируется postback)
- логи Keitaro или статус ответа на постбек
Дубликаты заявок в Keitaro
Причины:
- обработчик формы дергается дважды
- постбек делается и с фронтенда, и с бэкенда одновременно
- ретраи на стороне WordPress без ограничений
Что проверить:
- точку вызова endpoint (одна ли она)
- идемпотентность (есть ли уникальный ключ)
- отсутствие повторного submit
Заявка отправляется в WordPress, но не попадает в Keitaro
Причины:
- REST endpoint в WordPress недоступен (ошибка маршрута/URL)
- endpoint не принимает payload из формы (несовпадение полей)
- endpoint «падает» по PHP ошибке, но форма пользователя проходит
Что проверить:
- PHP error log
- response endpoint в браузере (если вызов делается клиентом)
- логи WordPress при отправке
Трекер работает, но отчёт не совпадает с реальными лид-данными
Причины:
- поля лида передаются не полностью (например, нет телефона)
- формат полей меняется (строка vs число)
- есть разница между временем отправки формы и временем получения postback
Что проверить:
- mapping полей: как именно названия полей сопоставлены в Keitaro
- единый формат email/телефона
- что конверсия считается на статусе «успешная отправка»
Эксплуатация: как держать связку Keitaro на VPS стабильной
После запуска важно не забыть про обслуживание. Связка трекер + WordPress будет жить дольше, чем желание сделать «только один раз».
Логи и мониторинг
Минимальный набор:
- логи Keitaro: по ошибкам постбеков и обработке конверсий
- логи WordPress: по вызовам твоего endpoint и ошибкам в wpremotepost
- мониторинг доступности домена и HTTPS (хотя бы внешним сервисом)
Если нет мониторинга, проблема обнаруживается только по «пустым отчётам». Это медленно.
Регулярные обновления и бэкапы
Делай бэкапы конфигурации и данных Keitaro согласно твоей схеме хранения. Если Keitaro в контейнерах — следи за volumes. Для WordPress бэкапируй:
- базу данных
- файлы темы/плагинов
- конфиги и кастомные endpoints
Обновления лучше делать по расписанию и в окно минимальной нагрузки. Перед обновлением трекера протестируй короткий сценарий: клик → форма → postback.
Ограничение доступа и контроль безопасности
Проверь, что:
- интерфейс Keitaro доступен только нужным пользователям (по IP или по логину/паролю)
- SSH не доступен по паролю
- секреты (токены endpoint, пароли базы) лежат не в открытом виде
Для endpoint на WordPress добавь секретный токен или подпись запроса. Это не «безопасность на века», но уже сильно снижает риск случайных запросов.
Чек-лист перед запуском рекламы
Чтобы запуск прошёл без «сюрпризов», пройди короткий список:
- Keitaro доступен по HTTPS по твоему tracker.example.com
- JS-трекинг стоит на странице формы в WordPress
- скрытое поле формы заполняется идентификатором клика
- WordPress отправляет postback в Keitaro из серверной части (REST endpoint или webhook)
- conversion в Keitaro появляется в нужной кампании и атрибутируется к клику
- ошибок в логах нет или они понятны и учтены
- дублей при повторной отправке формы не возникает
Если хотя бы один пункт не сходится, сначала разбирай причину на стороне передачи идентификатора клика и формата postback. Обычно именно там спрятано 80 процентов проблем.
Итог: как получить стабильные лиды из форм WordPress в Keitaro
Связка Keitaro на VPS и форм WordPress становится рабочей, когда сходятся три вещи: доступность трекера, корректная передача идентификатора клика и правильный postback именно в том формате, который ждёт Keitaro. Если сделать эти элементы единообразными и протестировать сценарий клик → форма → лид, дальше аналитика ведёт себя предсказуемо.
Собери связку как систему, а не как набор «разрозненных правок»: один стандарт параметров, один endpoint для лидов, одна проверка дублей. Тогда Keitaro начнёт показывать реальную картину по кампаниям, а не приблизительные догадки.