Звіт з SEO показує зростання показів і переходів. Звіт з сайту показує відвідування сторінок. Звіт відділу продажів показує угоди за місяць. Три звіти лежать на одному столі, і жоден з них не відповідає на питання власника: скільки грошей загубилося дорогою від пошукового запиту до оплати. Бюджет на видимість витрачено, а зв’язок між ним і виручкою зібрати нема з чого.
Комерційний маршрут складається з семи ділянок: пошуковий попит → видимість → перехід → сторінка → цільова дія → обробка звернення → продаж. Ця стаття розбирає саме цей маршрут; права на сайт, доступи та присутність бренду в AI-відповідях залишаються за її межами і мають окремі матеріали.
На кожній ділянці є свої дані і свій відповідальний, і втрата на будь-якій з них змінює економіку всього каналу, навіть коли попередні ділянки виглядають добре. Завдання статті: показати, як перевірити маршрут по ділянках, які дані для цього потрібні і як вибрати наступний пріоритет за економічним впливом.
Комерційний результат формується по всьому маршруту
Маршрут клієнта проходить через чотири зони відповідальності. Залучення належить маркетингу: попит, видимість, перехід. Взаємодія належить продукту і розробці: сторінка, сценарій, форма або кошик. Передача звернення належить аналітиці та інтеграціям: подія на сайті стає записом у CRM. Обробка належить продажам: контакт, кваліфікація, угода.
Кожен відділ бачить свою зону і звітує в її межах. Маркетинг рахує переходи, розробка рахує помилки, продажі рахують угоди. Звіт кожного відділу закінчується на кордоні його відповідальності, тому економіка ланцюжка в жодному звіті не видна, і зібрати її має аналітика для бізнесу як окрема функція поза межами будь-якого відділу.
Зв’язати ділянки дозволяє єдиний ідентифікатор, який проходить увесь шлях: джерело переходу, сторінка входу, звернення і результат угоди записуються в одну картку. Технічно це означає, що параметри джерела і сторінки передаються з сайту в CRM разом із заявкою, а статус угоди повертається в аналітику. Мінімальний набір даних для такої зв’язки описано в матеріалі про те, з чого починається наскрізна аналітика. Тут достатньо зафіксувати правило: якщо ідентифікатор обривається на будь-якій ділянці, далі починаються припущення.
Керівник виходить із цього розділу з картою маршруту: чотири зони і власник даних кожної ділянки. Без такої карти наступні кроки перетворюються на суперечку відділів.
Пошукова видимість створює початок маршруту
Попит має відповідати пріоритетам бізнесу
Пошуковий попит неоднорідний. Частина запитів веде до маржинальних категорій, частина до товарів з нульовою націнкою, частина до регіонів, куди компанія не доставляє. Повідомлення «органічний трафік зріс» нічого не каже про те, яка частка цього зростання припала на пріоритетні категорії.
Перевірка проста і виконується на даних Search Console у зіставленні з маржинальністю категорій з облікової системи: частка показів і переходів по пріоритетних категоріях порівнюється з їхньою часткою у маржі. Якщо видимість зростає в категоріях, які приносять, умовно, 5 % маржі, канал працює на звіт, тоді як прибуток лишається без змін. Сезонність і географія перевіряються тим самим способом.
Окремо розділяються брендові і небрендові запити, а також комерційний намір і інформаційний інтерес. Запит «купити котел 24 кВт» і запит «як вибрати котел» ведуть різних людей на різні сторінки з різними очікуваннями. Змішування їх в одному показнику «трафік» ховає реальну картину попиту. Ще одне джерело початку маршруту — AI-відповіді з посиланнями на сайт: присутність бізнесу в AI-пошуку розібрана окремо, а перехід із такої відповіді далі проходить ті самі ділянки карти.
Сторінка входу визначає якість переходу
Перехід приносить гроші лише тоді, коли сторінка входу відповідає наміру запиту і дозволяє зробити наступний крок. Категорія, картка товару, сторінка послуги, регіональна та інформаційна сторінки виконують різні функції. Перехід з комерційного запиту на інформаційну статтю без шляху до каталогу закінчується читанням і виходом.
Друга умова: актуальність комерційних даних. Ціна, наявність, умови доставки та оплати, термін виконання і кнопка наступної дії мають відповідати дійсності на момент переходу. Сторінка з торішньою ціною або відсутнім товаром отримує перехід і втрачає його за кілька секунд, і в звіті з SEO ця втрата виглядає як успішний візит.
Керівник перевіряє два факти: чи веде видимість до пріоритетної пропозиції бізнесу і чи можна на сторінці входу зробити наступний крок. Обидва факти перевіряються вибіркою з десяти найбільш відвідуваних сторінок входу.
Технічна основа забезпечує клієнтський сценарій
Доступність сторінки
Технічний стан сайту проявляється для клієнта через кілька спостережуваних речей: сторінка відкривається за прийнятний час на мобільному пристрої, елементи не зміщуються під час завантаження, ціна і контакти видимі без додаткових дій, редиректи ведуть на потрібну сторінку. Кожне порушення має ціну в перерваних сценаріях, і ця ціна вимірюється в даних: помилки в журналі, сесії з виходом на першій секунді, різниця конверсії між пристроями. Метрики швидкості та їх зв’язок із поведінкою користувача розібрано в статті про Core Web Vitals, а технічний аудит сайту входить у технічне SEO.
Навігація та пошук
Для магазину клієнтський сценарій проходить через категорії, фільтри, внутрішній пошук, варіанти товару і наявність. Фільтр, який повертає нуль результатів, або внутрішній пошук, який видає товари з чужої категорії, зупиняють сценарій до кошика. Дані внутрішнього пошуку окремо цінні: запити без результатів показують попит, який сайт отримав і залишив без відповіді.
Для сервісного сайту сценарій інший: від сторінки послуги та умов до доказів компетенції і форми звернення. Розрив між описом послуги і доказами, або форма, до якої немає шляху зі сторінки послуги, дають той самий ефект.
Форми та оформлення
Останній крок сценарію найдорожчий, бо до нього дійшов клієнт, який уже вирішив діяти. Форми, кошик, реєстрація, способи оплати, вартість доставки і підтвердження прийнятої дії перевіряються окремо і регулярно. Кожен реліз може змінити поведінку форми, тому історія релізів входить у набір даних для діагностики.
Зовнішнє дослідження дає орієнтир масштабу. За даними Baymard Institute на вересень 2025 року, середній документований показник покинутих кошиків за 50 дослідженнями становить 70,22 %. Це середнє по різних ринках, переважно США та ЄС, і воно описує галузь загалом. Для конкретного магазину значення має власний показник по сегментах, а серед причин відмови Baymard називає додаткові витрати на етапі оформлення, повільну доставку, недовіру до сайту при введенні даних картки, обов’язкову реєстрацію та задовгий процес оформлення.
Саме з таких сценаріїв складається перелік того, що перевіряється до обговорення зростання трафіку. Збільшувати потік у сценарій, який не завершується, означає збільшувати втрати.
Конверсія показує якість завершеного сценарію
Слово «конверсія» в компанії часто означає одне число: частку відвідувачів, які зробили замовлення. Це число приховує більше, ніж показує. Заявка, дзвінок, замовлення, оплата і повторна купівля — окремі цілі з окремими сценаріями. У кожної є свій показник, і збіг цих показників у середньому по сайту нічого не гарантує.
Формула одна: конверсія дорівнює кількості завершених цільових дій, поділеній на кількість сесій або користувачів за період. Вона має сенс лише з трьома уточненнями: яка саме ціль, який сегмент і який період. Конверсія в замовлення з мобільних пристроїв у категорії «котли» за серпень і конверсія в дзвінок з десктопа по всьому сайту за рік — два різні числа, і порівнювати їх між собою не можна.
Термінологія аналітики теж вимагає точності. У Google Analytics 4 цільові дії називаються ключовими подіями, а термін «конверсія» в інтерфейсі Google стосується Google Ads і в стандартних звітах GA4 не показується. У цій статті «конверсія» означає бізнес-показник, частку завершених сценаріїв; при описі налаштувань аналітики використовується «ключова подія».
Дві перевірки визначають, чи можна довіряти показнику. Перша: коректність подій. Подія «замовлення» має спрацьовувати один раз на одне замовлення, після підтвердження, і не спрацьовувати на оновлення сторінки. Друга: якість результату. Скасування, повернення, дублі і нецільові звернення віднімаються від валового числа. Умовно: магазин з конверсією 2 % і поверненнями 30 % заробляє менше за магазин з конверсією 1,5 % і поверненнями 5 %. Тому керівник оцінює якість конкретного сценарію і сегмента; середнього числа по сайту для рішення недостатньо.
Обробка звернення завершує вимірювання
Передача даних до CRM
Заявка з сайту приносить у CRM контакт клієнта. Разом із контактом мають прийти джерело переходу, сторінка входу, продукт або послуга, кампанія, а далі в картці угоди мають з’явитися статус і результат. Кожне поле, яке не передалося, обриває зв’язок між маршрутом і грошима. Джерело без сторінки не дозволяє оцінити сторінку; сторінка без результату угоди не дозволяє оцінити її економіку. Порядок робіт описано в матеріалі про те, що врахувати до старту, коли планується інтеграція сайту з CRM.
Швидкість і якість обробки
Далі маршрут переходить у руки менеджерів, і дані змінюють природу. Час першого контакту, втрачені звернення, дублі, зміна відповідального і причина відмови — це показники обробки, які записуються в CRM. Причина відмови заслуговує окремого поля з фіксованим переліком значень: «дорого», «не відповіли», «немає в наявності», «нецільове звернення». Без цього поля відділ продажів і маркетинг звинувачують один одного без доказів.
Зв’язок із продажем
Зв’язок звернення з виручкою має межі точності, і ці межі варто визнати. Модель атрибуції визначає, якому каналу зарахувати угоду, і в GA4 таких моделей три: на основі даних, останній клік по платних і органічних каналах, останній клік по платних каналах Google. Прямі візити отримують атрибуцію лише тоді, коли весь шлях до ключової події складається з прямих візитів; переатрибуція можлива до семи днів після події. Інші системи аналітики мають власні моделі. Точність зв’язку з виручкою обмежена обраною моделлю і повнотою переданих даних; абсолютної точності не існує, і стаття, яка її обіцяє, вводить в оману.
Межа відповідальності тут проходить чітко: сайт відповідає за звернення з повними даними, а далі якість вимірюється показниками CRM.
Карта втрат для керівника
Усі ділянки маршруту зводяться в один інструмент. Кожна причина в ньому записана як гіпотеза: вона стає фактом лише після перевірки, зазначеної в останній колонці.
| Ділянка | Сигнал | Дані | Ймовірна причина | Власник | Рішення | Як перевірити |
|---|---|---|---|---|---|---|
| Попит | Низька частка пріоритетних категорій у показах | Search Console + маржинальність категорій | Карта попиту не відповідає пріоритетам бізнесу | Маркетинг / комерція | Переглянути карту попиту | Порівняти частку показів і частку маржі по категоріях |
| Видимість | Покази є, переходів мало | Search Console: CTR по сторінках і запитах | Сніпет або сторінка не відповідають запиту | Маркетинг / SEO | Узгодити сторінку із запитом | Вибірка 20 запитів з найбільшим розривом показів і кліків |
| Перехід | Перехід є, сесія завершується одразу | GA4: сесії з виходом, час до першої взаємодії, пристрій | Сторінка повільна або відкривається з помилкою | Розробка | Усунути підтверджену технічну причину | Журнал помилок, тест на мобільному, порівняння по пристроях |
| Сторінка входу | Перехід є, дія не починається | GA4 + записи сесій + UX-тест | Сторінка не відповідає наміру або ключові дані неактуальні | Продукт / розробка | Перевірити сценарій сторінки | Сесії, тест на 5 користувачах, перевірка ціни та наявності |
| Форма / кошик | Початок без завершення | Події + журнал помилок форм | Помилка або зайвий крок у сценарії | Розробка | Усунути підтверджену причину | Журнал помилок за період, повторний тест після релізу |
| CRM | Джерело або продукт втрачається | CRM + журнал інтеграції | Поля не передаються або перезаписуються | Sales Ops / розробка | Відновити передачу даних | Вибірка 20 звернень: звірити поля сайт → CRM |
| Обробка | Довгий час першого контакту, дублі | CRM: час реакції, статуси, відповідальні | Немає правила розподілу або контролю строків | Продажі | Встановити норматив і контроль | Розподіл часу реакції за тиждень по менеджерах |
| Продаж | Багато відмов після звернення | Причини відмови в CRM | Якість ліда або якість обробки | Продажі + маркетинг | Розділити якість ліда і обробки | Причини відмови за сегментами джерела і сторінки |
Заповнена карта стає основою спільного беклогу SEO, розробки, аналітики та продажів. Кожен рядок з підтвердженою причиною перетворюється на задачу з власником, а рядки без даних перетворюються на задачу «зібрати дані».
Пріоритет визначає економічний вплив
Після перевірки в карті залишається кілька підтверджених проблем, і на всі одразу ресурсу немає. Порядок визначають п’ять критеріїв.
Перший: обсяг залученого попиту або сторінок. Помилка на десяти картках товару і помилка на всіх картках категорії мають різну вагу. Другий: вплив на цільову дію і частота помилки. Помилка, яка зупиняє оформлення в кожному п’ятому випадку, важить більше за косметичний дефект. Третій: вартість реалізації. Четвертий: впевненість у причині, підтверджена даними. П’ятий: строк отримання сигналу після зміни. Виправлення форми покаже результат за тиждень, зміна структури категорій — за квартал.
Умовний приклад. Магазин має дві підтверджені проблеми: у категорії, яка дає 12 % загальної маржі, фільтр повертає порожній результат для третини комбінацій, а на головній сторінці банер перекриває логотип у шапці на старих мобільних пристроях. Перша проблема менш помітна, але зачіпає комерційно значущу категорію, зупиняє сценарій до кошика і виправляється за два дні. Друга помітна кожному, але стосується 3 % сесій і не зупиняє сценарій. Пріоритет отримує перша.
Оцінка пріоритету впорядковує роботу; вона залишається оцінкою і точного прогнозу прибутку не дає. Команда обирає наступний крок за економічним впливом і доказовістю, а результат перевіряє на даних після впровадження.
SEO і розробка працюють в одному циклі
Заповнена карта втрат є точкою входу в робочий цикл: дані → причина → рішення → розробка → перевірка → наступний пріоритет. Аналітика показує ділянку, де обривається сценарій. Причина перевіряється на журналах, сесіях і тестах. Рішення проєктується як зміна сайту, реалізується розробкою і перевіряється на тих самих даних, що показали проблему. Далі карта оновлюється, і наступний рядок стає задачею.
У моделі Inward Labs технічне SEO та розробка — одна виробнича лінія: аналіз, реалізація і перевірка узгодженого обсягу належать одній команді, тому рішення з аналітики переходить у код без втрати змісту на передачі між підрядниками. Компанія отримує звіт про те, який рядок карти закрито, якими даними це підтверджено і який рядок береться далі. Щоб напрацювання циклу зберігалися після зміни команди, компанія має контролювати сайт як актив бізнесу: права, доступи і документацію розібрано в окремій статті.
Що зробити керівнику
- Призначити власника даних для кожного з восьми рядків карти втрат — це сім ділянок маршруту, де обробка звернення розділена на передачу даних і роботу продажів. Відповідальний: керівник компанії. Дані: карта з цієї статті. Строк: тиждень.
- Перевірити передачу полів «джерело, сторінка, продукт, кампанія» з сайту в CRM на вибірці з двадцяти звернень. Відповідальний: Sales Ops разом із розробкою. Строк: два тижні.
- Ввести в CRM поле «причина відмови» з фіксованим переліком значень і розділити відмови на якість ліда та якість обробки. Відповідальний: керівник продажів. Строк: місяць.
- Зібрати підтверджені проблеми в єдиний беклог і впорядкувати їх за п’ятьма критеріями пріоритету, як це передбачає підхід Inward Labs до спільного циклу SEO й розробки. Відповідальні: маркетинг, розробка, аналітика, продажі спільно. Строк: після заповнення карти.
ПЕРЕВІРИТИ ШЛЯХ ВІД ПОШУКУ ДО ПРОДАЖУ
Inward Labs визначить точки втрати, перевірить дані та сформує пріоритети для спільного циклу SEO й розробки.
