- Чому сайт — це ланцюг рішень людини
- Блоки під продажі: що це насправді
- Згода на cookie: чому «Прийняти все» вже не працює
- Серверні конверсії: щоб реклама бачила справжні продажі
- Звичайний сайт і сайт на NEO: різниця в одній таблиці
- Що змінюється для власника з першого дня
- Коротко
- Питання, які ставлять найчастіше
Сайт зробили. Красивий, з анімаціями, дизайнер пишається. Запустили рекламу — і тиша. Кабінет Google Ads показує кліки, аналітика показує відвідувачів, а заявок немає або їх удвічі менше, ніж прийшло насправді, бо половину форм ніхто не порахував. Власник робить висновок «реклама не працює», хоча не працює сайт: він побудований як вітрина, і шляху до покупки в ньому немає.
Я бачу це з 2008 року в різних декораціях. Технології змінюються, помилка та сама: сайт проєктують від картинки, тоді як починати треба з рішення, яке має ухвалити людина. Ще й додалися нові умови гри — вимоги до згоди на файли cookie, блокувальники реклами, які «зʼїдають» дані про конверсії, і асистенти на базі штучного інтелекту, які читають сайти замість людей. Звичайний шаблон із конструктора цього не враховує, і дірки доводиться латати після запуску, коли гроші вже витрачено.
NEO я збирав як відповідь на цю помилку: платформа, де сайт від початку є ланцюгом блоків під продаж, згода на cookie і серверна передача конверсій вбудовані від першого дня, без докручування після запуску. У цій статті — навіщо кожна з трьох речей потрібна саме вам і що змінюється, коли вони є з першого дня.
Чому сайт — це ланцюг рішень людини
Людина приходить на сайт на певній сходинці обізнаності. Вона може лише відчувати проблему, може знати, що рішення існують, може вже порівнювати вас із кимось або бути готовою платити. Бен Гант описав це як драбину, і головний його висновок простий: сторінка працює, коли зустрічає людину на її сходинці й піднімає на одну вище. Не на три — на одну.
З цього випливає вимога до конструкції: кожен екран сторінки має або довести перевагу, або зняти сумнів, або повести далі. Екран, який не робить жодного з трьох, — зайвий, яким би гарним він не був. Дизайн у цій логіці — не мета, а спосіб зробити рішення легким.
Коли сайт будується у звичайному конструкторі, дизайнер отримує вільне полотно і заповнює його за смаком. Коли сайт будується з блоків, кожен з яких має призначення в ланцюгу, полотно вже структуроване: спочатку обіцянка, потім факти, потім зняття страхів, потім умови, потім крок. Помилитися складніше.
Блоки під продажі: що це насправді
У NEO кілька десятків типів блоків, і кожен відповідає на одне питання людини на конкретній сходинці. Ось як це виглядає на практиці, без назв із адмінки:
- Перший екран відповідає на «куди я потрапив і чи це для мене» за три секунди: результат, умова, для кого, одна кнопка.
- Блок фактів і переваг відповідає на «чому вам вірити» — цифрами, документами, строками, а не прикметниками.
- Порівняння «без нас / з нами» закриває страхи. Ліворуч — що реально відбувається, коли задачу вирішують самі; праворуч — що робите ви. Без третіх сторін і без залякування.
- Кроки процесу відповідають на «а що буде після того, як я натисну кнопку». Невідомість — головний гальмівний фактор, і його знімає простий перелік з датами і відповідальними.
- Умови й документи — для тих, хто вже майже вирішив і хоче побачити оплату, гарантії, договір.
- Питання і відповіді — місце для всіх заперечень, які не помістилися вище, і водночас сторінка стає зрозумілішою для пошуку й асистентів.
- Пропозиція з таймером або лімітом — коли є справжній дедлайн: набір, партія, акція. Справжній, бо фальшивий таймер люди розпізнають і йдуть.
- Форма і сторінка «дякуємо» — не кінець, а наступна сходинка: що буде далі, коли чекати відповіді, що подивитися поки що.
Одне правило, яке я застосовую на кожній сторінці: один тип блоку — один раз. Два блоки фактів поспіль — це один розмитий блок. Конкретику розкладають по різних типах: умови — в умови, кроки — у кроки, страхи — у порівняння. Сторінка від цього читається як розмова.
І ще одне: блоки багатомовні від народження. Той самий ланцюг можна показати українською, англійською, німецькою, польською з правильними адресами сторінок і посиланнями між мовними версіями — це важливо для тих, хто продає за кордон, і болісно докручується постфактум.
Згода на cookie: чому «Прийняти все» вже не працює
Банер про cookie багато хто сприймає як формальність: поставили, щоб не чіпляли. Але за ним стоять дві реальні речі — закон і дані.
Закон — це GDPR для відвідувачів з Європи і подібні вимоги в інших країнах: аналітичні й рекламні файли можна ставити лише після згоди, відмова має бути такою ж простою, як згода, а сам факт згоди треба вміти показати. Банер, у якого є лише кнопка «Прийняти», формально нікого не захищає.
Дані — це Consent Mode v2 від Google. Це механізм, за яким ваші теги отримують сигнал: дозволила людина аналітику й рекламу чи ні. Без коректно налаштованого режиму згоди Google обмежує роботу персоналізованої реклами і вимірювання для аудиторії з Європейської економічної зони. Іншими словами, банер без Consent Mode — це рекламний бюджет, який частково працює наосліп.
У NEO банер, режим згоди, журнал згод і сторінка, де людина може змінити своє рішення, — одна вбудована система. Аналітика й пікселі запускаються лише після дозволу, кожна згода записується, і коли приходить запит «покажіть, на що я погоджувався», є що показати. Це та частина роботи, яку ніхто не любить робити руками, і саме тому її майже завжди роблять погано.
Серверні конверсії: щоб реклама бачила справжні продажі
Класичний піксель живе в браузері відвідувача. І в цьому його слабкість: блокувальники реклами його не запускають, браузери обмежують строк життя його cookie, людина без згоди його вимкнула, а повільний сайт не встиг його завантажити до кліку. Результат — рекламний кабінет бачить частину конверсій і оптимізується на неповних даних. Ви платите за кліки, а алгоритм навчається на половині реальності.
Серверна передача вирішує це інакше: подію про заявку сайт надсилає в рекламні системи зі свого сервера — у Google Analytics 4 через Measurement Protocol, у Meta через Conversions API, у Google Ads як розширені конверсії, у TikTok, LinkedIn і Microsoft через їхні серверні інтерфейси. Браузерний піксель може лишатися як дубль, а щоб подія не рахувалася двічі, обидва канали передають однаковий ідентифікатор події.
Що це дає на практиці: рекламні алгоритми отримують повніші дані і краще знаходять схожих людей; ви бачите реальну вартість заявки; дані з форми, які людина вже вам дала, збагачують подію так, як браузерний піксель не вміє. І все це працює в межах отриманої згоди — серверна передача не обходить закон, вона обходить технічні втрати.
У NEO цей контур — вбудований модуль: параметри трафіку зберігаються від першого візиту до заявки, події йдуть на сервери рекламних систем, а в адмінці є перевірка, чи дійшла тестова подія до кожної платформи. Індикатор показує факт, а не намір — це принцип, за яким я перевіряю всі свої системи.
Звичайний сайт і сайт на NEO: різниця в одній таблиці
| Що | Сайт із конструктора або шаблону | Сайт на NEO |
|---|---|---|
| Структура сторінки | Вільне полотно, збирається за смаком | Ланцюг блоків за сходинками обізнаності |
| Згода на cookie | Банер-заглушка або плагін без журналу | Consent Mode v2, журнал згод, сторінка зміни рішення |
| Передача конверсій | Браузерні пікселі | Сервер плюс браузер із дедуплікацією |
| Мови | Дублювання сторінок вручну | Одна структура, кілька мов, правильні звʼязки між версіями |
| Пошук і асистенти | Що дає шаблон | Карта сайту, структуровані дані, файл для мовних моделей |
| Спам у формах | Капча або нічого | Перевірка домену, пастки, правила в адмінці |
| Запити «мої дані» | Вручну поштою | Окрема сторінка й процес обробки запитів |
Це не означає, що на конструкторі неможливо зробити добре. Можливо — якщо докрутити кожен рядок таблиці окремо, плагінами й руками, і потім підтримувати це після кожного оновлення. Питання лише в тому, чи це ваша робота.
Що змінюється для власника з першого дня
Найбільша різниця не технічна, а управлінська. Коли структура задана блоками, ви наповнюєте сайт замість проєктувати його щоразу. Бриф, тексти, картинки — і сторінка складається за зрозумілою логікою; переставити блок або додати мову — справа адмінки, без нового ТЗ для студії. Саме тому базовий сайт на NEO я збираю за тиждень: від брифу до запуску реклами, з налаштованою згодою і серверними конверсіями. Як це відбувається — на сторінці «Сайт на NEO за тиждень».
Друга різниця відчувається не в день запуску, а коли пішла реклама: кабінети бачать заявки, ви бачите, звідки вони, і рішення про бюджет ухвалюються на цифрах. Що саме вбудовано в платформу і як вона ліцензується — на сторінці платформи NEO.
Коротко
- Сайт — це ланцюг рішень людини; кожен блок або доводить перевагу, або знімає сумнів, або веде далі.
- Блоки під продажі задають структуру, у якій помилитися складніше: обіцянка → факти → страхи → умови → крок.
- Один тип блоку — один раз на сторінку; конкретика розкладається по різних блоках.
- Банер cookie без Consent Mode v2 і журналу згод не захищає юридично і залишає рекламу без даних.
- Браузерні пікселі втрачають частину конверсій; серверна передача з дедуплікацією повертає рекламі повну картину.
- Багатомовність, структуровані дані, антиспам і обробка запитів на дані мають бути в основі платформи, без плагінів.
- Коли база вбудована, власник наповнює сайт і не проєктує його заново для кожної зміни.
Питання, які ставлять найчастіше
Чи можна перенести на NEO наявний сайт?
Так, і зазвичай це радше переосмислення, ніж копіювання: тексти й картинки переїжджають, а структуру сторінок перебирають за ланцюгом блоків. Часто саме на цьому етапі стає видно, чому старий сайт не продавав.
Чи потрібен програміст для роботи з блоками?
Ні. Блоки збираються в адмінці з полів: заголовок, текст, картинка, кнопка. Програміст потрібен лише для нестандартних інтеграцій.
Чи серверні конверсії — це обхід згоди на cookie?
Ні. Події надсилаються в межах дозволу, який дала людина. Сервер вирішує технічні втрати — блокувальники, обмеження браузерів, — а не юридичні.
Чи можна використовувати NEO на кількох сайтах?
Умови ліцензії описано на сторінці платформи; там же — що входить у підтримку й оновлення.