Заказчик платит SEO-специалисту абонентскую плату, получает таблицу позиций в Яндексе и Google, видит визиты из органического поиска, но не понимает, какие обращения можно включить в счёт. Переход от абонентской платы к оплате за лиды требует не новой формулы в договоре, а доказуемой цепочки от запроса до статуса в CRM.
5 признаков, что переход к CPL или CPA пока не работает
- Позиция есть, но для лида нет first_source и landing_page_url.
- Форма передаёт контакт без единого lead_id.
- Входящий звонок записан, но коллтрекинг не показывает organic search.
- Повторное обращение не отделено от нового контакта.
- Отдел продаж меняет contact_status без даты среза и причины.
Почему позиции не заменяют оплачиваемый лид?
Позиция в Яндексе или Google показывает место страницы в поисковой выдаче, визит — факт перехода, а конверсия — целевое действие; принятый лид требует источника, контакта, профиля и статуса, а закрытая сделка ещё и этапа в CRM.
Абонентская плата оплачивает согласованный объём работ за период. CPL считает принятый лид, а CPA — закрытую сделку, связанную с исходным обращением. Поэтому одна строка с позицией не подтверждает ни заявку, ни продажу.
Сценарий выглядит так: SEO-специалист показывает рост видимости, клиент видит визит, но карточка не содержит organic search. Итог — показатель полезен для контроля поискового спроса, однако в реестр биллинга его не включают.
| Объект | Что показывает | Почему этого недостаточно |
|---|---|---|
| Позиция | Место URL в выдаче | Не содержит контакт и статус |
| Органический трафик | Переход из поиска | Не равен обращению |
| Конверсия | Событие формы или звонка | Может быть спамом или дублем |
| Принятый лид | Профильный уникальный контакт | Требует критериев приёмки |
| Закрытая сделка | Продажа в CRM | Требует funnel_stage и связи с lead_id |
Как определить принятый лид для CPL?
Принятый лид для CPL — это обращение по профильному продукту и согласованному региону с рабочим контактом, подтверждённым organic search, единичным lead_id и допустимым contact_status.
Сначала заказчик и SEO-специалист фиксируют профиль. В строке указывают продукт, регион, форму обращения или входящий звонок. Затем аналитик проверяет first_source, дату, URL и уникальность. Спам, технический вызов, пустой номер, внепрофильный запрос и повтор без нового события не проходят приёмку.
Статус должен быть однозначным. Например, «новый» может считаться принятым, если контакт прошёл автоматическую проверку; «спам», «дубль» и «нецелевой» исключают запись. Список статусов закрепляют до расчёта, а не после просмотра реестра.
- Профиль: продукт и регион совпадают с согласованным перечнем.
- Контакт: номер или почта проходят рабочую проверку без публикации персональных данных.
- Источник: first_source указывает organic search, а URL связан с обращением.
- Уникальность: lead_id не повторяет принятую запись за период сверки.
- Статус: contact_status входит в согласованный список приёмки.
- Исключение: спам, дубль и технический вызов вынесены отдельно.
- Плохо: «Оплачиваются все заявки с сайта».
- Хорошо: «В CPL включают запись с профильным продуктом, согласованным регионом, рабочим контактом, first_source = organic search, неповторяющимся lead_id и статусом из списка приёмки».
- Плохо: «Звонки считаются лидами».
- Хорошо: «Входящий звонок включают после проверки коллтрекинга, URL, источника, длительности по согласованному правилу и статуса контакта».
Как связать поисковый путь с CRM и продажей?
Связь поискового запроса с CRM строят по цепочке query_cluster → landing_page_url → форма или входящий звонок → lead_id → first_source → contact_status или funnel_stage.
SEO-специалист связывает поисковый запрос с кластером, а кластер — с URL посадочной страницы. Аналитик передаёт URL и first_source в форму; коллтрекинг сохраняет те же параметры для звонка. CRM-система получает единый lead_id, по которому отдел продаж меняет статус контакта и этап воронки.
Если URL потерялся на редиректе, CRM увидит обращение, но не докажет органическую атрибуцию. Если lead_id создаётся дважды, один человек попадёт в счёт несколько раз. Разработчик проверяет передачу событий, а заказчик утверждает, какие поля обязательны.
| Поле / параметр | Что содержит | Что подтверждает |
|---|---|---|
| query_cluster | Группа связанных поисковых запросов | Связь спроса с посадочной страницей |
| landing_page_url | Первый URL входа | Страницу, с которой начался путь |
| first_source | Первичный канал | Органический поиск, а не последний источник |
| lead_id | Единый идентификатор | Связь формы, звонка и CRM-карточки |
| contact_status | Статус контакта | Приёмку, исключение или спор |
| funnel_stage | Этап воронки | Продвижение обращения к закрытой сделке |
Как проверить готовность проекта к CPL или CPA?
Проект готов к CPL или CPA, если формы, звонки, CRM-карточки, источники, статусы и сделки сходятся в одну выгрузку без необъяснимых пропусков.
Аналитик берёт период сверки и дату среза, затем сопоставляет журнал формы с CRM. Для звонков он добавляет данные коллтрекинга. Отдел продаж подтверждает contact_status и funnel_stage. CPA применяют только там, где закрытая сделка связана с исходным lead_id, а не просто отмечена в CRM вручную.
Пропуск source не превращают в спор о доверии. Его заносят в реестр спорных записей, указывают причину и решение. Повторные обращения проверяют по правилу уникальности: новый lead_id не всегда означает нового клиента, если CRM объединяет карточки.
- Сопоставить число записей формы и CRM-карточек по lead_id.
- Сравнить звонки коллтрекинга с входящими событиями и first_source.
- Найти записи без landing_page_url, query_cluster или статуса.
- Проверить, что funnel_stage «закрыта» связан с исходным обращением.
- Отдельно отметить дубликат, спам, технический вызов и внепрофильный контакт.
- Зафиксировать дату среза и период сверки в файле приёмки.
Как перейти от абонентской платы к оплате за лиды?
Переход от абонентской платы к оплате за лиды проходит через шесть этапов: выгрузка истории, выбор объекта, фиксация полей, согласование статусов, разбор спорных записей и утверждение реестра биллинга.
01. Выгрузить историю
SEO-специалист собирает позиции, органический трафик, формы, звонки и CRM-карточки за согласованный период. В историю не включают персональные данные: для сверки достаточно идентификаторов, дат, URL, источника и статусов.
02. Выбрать объект расчёта
Заказчик фиксирует: CPL считает принятый лид, CPA — закрытую сделку. Нельзя смешивать эти объекты в одной строке и менять границу оплаты после получения реестра.
03. Зафиксировать поля
Аналитик описывает query_cluster, landing_page_url, first_source, lead_id, contact_status и funnel_stage. Разработчик отмечает, где каждое поле создаётся и передаётся.
04. Согласовать статусы
Отдел продаж и заказчик утверждают список принятых, исключённых и спорных записей. Одно слово статуса должно иметь одно действие в биллинге.
05. Обработать споры
Спорная запись получает причину: нет источника, повтор, технический вызов, спам, внепрофильный контакт или пропуск CRM. После проверки её относят в принятую, исключённую или отложенную группу.
06. Утвердить реестр
Аналитик собирает реестр биллинга, SEO-специалист проверяет связь с поисковыми страницами, отдел продаж — статусы, заказчик — итоговый состав. Файл утверждают с датой среза и периодом сверки.
| Этап | Артефакт | Критерий приёмки |
|---|---|---|
| История | Выгрузка источников и обращений | Есть период и дата среза |
| Объект | Правило CPL или CPA | Оплата привязана к одному типу записи |
| Поля | Схема CRM-полей | lead_id связывает путь и карточку |
| Статусы | Список contact_status | Есть принятые и исключённые значения |
| Споры | Реестр спорных записей | У каждой строки есть причина и решение |
| Биллинг | Итоговый реестр | Заказчик утвердил состав без персональных данных |
Зачем нужен технический аудит данных перед CPL?
Технический аудит данных перед CPL проверяет, доходят ли поисковый источник, URL и события до CRM; он не заменяет критерии лида и не доказывает продажу.
Разработчик проверяет индексацию посадочных страниц, дубли URL, метатеги, заголовки и внутреннюю перелинковку. SEO-специалист сопоставляет query_cluster с доступным URL. Аналитик проверяет события формы и звонка, а также передачу first_source и lead_id.
Сценарий с разрывом виден по журналу: страница индексируется, пользователь отправляет форму, но CRM получает пустой источник. Такая строка не становится CPL автоматически. Её выносят в спор до исправления передачи и отдельной проверки данных.
- Проверить статус индексации URL посадочной страницы.
- Найти дубли URL и проверить редиректы.
- Сопоставить метатеги и заголовки с query_cluster.
- Проверить внутреннюю перелинковку до целевой страницы.
- Сверить события формы, входящего звонка и создание lead_id.
- Убедиться, что first_source доходит до CRM без подмены последним каналом.
Как согласовать реестр биллинга?
Реестр биллинга должен показывать проверяемый путь каждой строки: дату, lead_id, источник, URL, статус, объект расчёта и решение по приёмке без персональных данных.
SEO-специалист сверяет поисковый кластер и посадочную страницу. Аналитик собирает поля и дату среза. Разработчик объясняет технический вызов или пропуск события. Отдел продаж подтверждает статус контакта и этап воронки. Заказчик принимает состав и фиксирует правило уникальности.
Повторное обращение получает прежний lead_id, если правило уникальности связывает его с уже принятой записью. Новый идентификатор не отменяет проверку: менеджер сравнивает источник, контактный ключ в защищённой CRM и время события, а в общий файл выводит только обезличенный результат.
| Поле строки | Пример содержания | Проверка |
|---|---|---|
| Дата среза | Дата формирования файла | Совпадает с периодом сверки |
| lead_id | Идентификатор записи | Не дублирует принятую строку |
| Источник и URL | organic search и landing_page_url | Связаны с кластером |
| Статус | contact_status и funnel_stage | Есть решение по CPL или CPA |
| Исключение | Причина спорной записи | Не включена в оплачиваемый итог |
- Плохо: «Спорные заявки решить отдельно».
- Хорошо: «Каждой спорной записи присвоить причину, ответственного, дату проверки и решение: принять, исключить или перенести».
- Плохо: «Продажа считается по CRM».
- Хорошо: «CPA включают при contact_status и funnel_stage закрытой сделки, если карточка связана с исходным lead_id и first_source = organic search».
Что спрашивают о звонках, CPL, CPA и повторах?
Ответы зависят от заранее записанных полей: источник, URL, lead_id, статус и этап воронки определяют, попадёт ли обращение в реестр.
01. Можно ли считать любой входящий звонок лидом?
Нет. Аналитик включает звонок в CPL после проверки коллтрекинга, organic search, посадочного URL, уникальности и допустимого contact_status.
02. Чем CPL отличается от CPA?
CPL считает SEO-специалисту принятый лид, а CPA — закрытую сделку с funnel_stage и связью с исходным lead_id.
03. Что делать со спорной записью?
Аналитик переносит её в реестр спорных записей, указывает причину и не включает в биллинг до решения заказчика.
04. Достаточно ли позиции в Яндексе или Google?
Нет. Позиция показывает видимость URL, но не подтверждает контакт, органическую атрибуцию, уникальность или продажу.
05. Что даёт технический аудит данных?
Разработчик и аналитик находят разрывы в индексации, URL, событиях и передаче источника; аудит не превращает визит в принятый лид.
06. Как обработать повторное обращение?
Менеджер сверяет правило уникальности и связывает повтор с прежним lead_id, если новый контакт не отвечает условиям отдельного лида.
Сайт не видно в поиске? Продвинуть сайт в ТОП Яндекс быстро.
Нужен современный сайт или лендинг? Заказать создание сайта.
«Я специалист полного цикла в веб-разработке и интернет-маркетинге: самостоятельно выполняю все работы — от сбора семантического ядра, проектирования и разработки сайта (включая серверную инфраструктуру) до SEO-оптимизации, контекстной рекламы и комплексного продвижения — без внешних подрядчиков. При этом мой 17-летний опыт и отсутствие посредников дают вам колоссальную экономию бюджета.»