Цей чек-лист аудиту персоналізації сайту призначений для двох ситуацій: ви збираєтеся почати персоналізацію і хочете знати, чи готові, або вже персоналізуєте і підозрюєте, що це мало що дає. У ньому 42 перевірки в семи групах, кожна з умовою проходження, яку можна перевірити самостійно. Скопіюйте таблиці в електронну таблицю або завантажте шаблон у форматі CSV.
Це не загальний аудит конверсії. Якщо у вас зламані відстеження чи форми, спершу пройдіть чекліст CRO-аудиту: персоналізація сторінки, конверсії якої ви не можете виміряти, лише додає змінних до проблеми, якої ви не бачите.
Як користуватися цим чек-листом аудиту персоналізації
- Перевіряйте живий досвід, а не план. Подивіться, що відвідувачі бачать сьогодні на сторінках, які вже мають персоналізацію або скоро матимуть.
- Позначте кожну перевірку як «Пройдено», «Не пройдено» або «Невідомо». «Невідомо» в оцінці зараховується як «Не пройдено». Якщо ніхто не може відповісти, ніхто за це не відповідає.
- Фіксуйте докази для кожного «Не пройдено»: скриншот, звіт, результат тесту.
- Оцінюйте кожну групу за аркушем наприкінці й спершу виправляйте групу з найнижчою оцінкою в порядку переліку. Групи впорядковано за залежностями: контент без даних неможливо таргетувати, а результатам без вимірювання не можна довіряти.
1. Дані (7 перевірок)
| # | Перевірка | Умова проходження | Статус |
|---|---|---|---|
| 1.1 | Рівень ідентифікації відомий | Ви можете назвати, яка частка сесій на ключових сторінках за останні 30 днів зіставлена з компанією | |
| 1.2 | Якість зіставлення перевірено | Вибірку з 50 зіставлених візитів перевірено вручну, а рівень помилок зафіксовано | |
| 1.3 | Фірмографічні дані доступні під час рендерингу | Галузь і кількість працівників доступні до рендерингу сторінки, а не через кілька секунд після нього | |
| 1.4 | Одна галузева таксономія | Усі галузеві мітки з усіх інструментів зводяться до одного переліку (наприклад, NAICS) у підтримуваній таблиці | |
| 1.5 | Статус у CRM придатний до використання | Сайт може відрізнити відкриту можливість і наявного клієнта від нового потенційного клієнта | |
| 1.6 | Збережені поведінкові сигнали | Кількість візитів і перегляди ключових сторінок (ціни, продукт, кейси) доступні для кожного відвідувача | |
| 1.7 | Актуальність даних відома | Ви знаєте, як часто оновлюються фірмографічні дані та дані CRM, що використовуються в правилах |
2. Сегменти (6 перевірок)
| # | Перевірка | Умова проходження | Статус |
|---|---|---|---|
| 2.1 | Сегменти визначаються доходом | Кожен сегмент обґрунтовано даними виграних угод, а не вподобаннями (див. шаблон профілю ідеального клієнта) | |
| 2.2 | Сегменти взаємовиключні | Правила перевіряються у фіксованому порядку, і відвідувач може потрапити лише в один сегмент у межах набору правил | |
| 2.3 | Розмір сегмента виміряно | Кількість ідентифікованих сесій на місяць для кожного сегмента відома, і кожному активному сегменту їх вистачає для вимірювання | |
| 2.4 | Клієнти обробляються окремо | Наявні клієнти мають власне правило й ніколи не бачать CTA для залучення на кшталт «замовити демо» | |
| 2.5 | Кількість сегментів обмежена | Кількість активних сегментів не перевищує той обсяг, для якого ви можете створювати контент і вимірювати результати (зазвичай від 3 до 6) | |
| 2.6 | Визначення записано | Кожен сегмент має записане правило, відповідального й дату створення в одному спільному документі |
3. Контент (6 перевірок)
| # | Перевірка | Умова проходження | Статус |
|---|---|---|---|
| 3.1 | Контент-набір для кожного сегмента готовий | Для кожного активного сегмента написано заголовок, докази, кейс і CTA | |
| 3.2 | Докази дозволені | Для кожного логотипа та цитати у варіанті є письмовий дозвіл | |
| 3.3 | Твердження правдиві для кожного сегмента | Мітки на кшталт «Найпопулярніший» або «Нам довіряє X» правдиві для сегмента, який їх бачить | |
| 3.4 | Адреси переходу відповідають підписам | Кожен персоналізований CTA веде на сторінку, що дає обіцяне в підписі | |
| 3.5 | Типова версія підтримується | Стандартну (неперсоналізовану) версію перевіряють так само ретельно, як і варіанти | |
| 3.6 | Контент актуальний | Жоден варіант не згадує стару назву продукту, минулий захід чи застарілий кейс |
4. QA досвіду (7 перевірок)
| # | Перевірка | Умова проходження | Статус |
|---|---|---|---|
| 4.1 | Без мерехтіння | За звичайного з'єднання контент за замовчуванням помітно не блимає перед появою варіанта | |
| 4.2 | Без зсуву макета | Заміна варіантів не зсуває контент; CLS на персоналізованих сторінках залишається в діапазоні «добре» (web.dev, CLS) | |
| 4.3 | Резервна версія рендериться повністю | Якщо скрипт персоналізації заблоковано, сторінка показує повну типову версію без порожніх блоків | |
| 4.4 | Тайм-аут задано | Якщо запит даних повільний, стандартна версія показується після фіксованого тайм-ауту, а не чекає | |
| 4.5 | Перевірено на мобільних | Кожен варіант перевірено на телефоні; довші заголовки й підписи не переносяться і не обрізаються некоректно | |
| 4.6 | Кожен сегмент примусово відкрито й зафіксовано на скриншоті | Запис QA показує варіант кожного сегмента на кожній персоналізованій сторінці | |
| 4.7 | SEO не страждає | Пошукові системи бачать контент за замовчуванням; жоден варіант не змінює title, canonical чи індексований текст лише для ботів |
5. Вимірювання (6 перевірок)
| # | Перевірка | Умова проходження | Статус |
|---|---|---|---|
| 5.1 | Контрольна група є | Частина кожного сегмента бачить стандартну версію (розподіл за відвідувачами), щоб можна було виміряти приріст | |
| 5.2 | Основну метрику узгоджено | Кожна персоналізація має одну основну метрику, пов'язану з пайплайном (демо, прийняті відділом продажу, кваліфіковані реєстрації) | |
| 5.3 | Результати за кожним сегментом | Коефіцієнти конверсії показано за сегментами і варіантами, а не зведено | |
| 5.4 | Запланований розмір вибірки | Для кожного тесту до запуску було розраховано розмір вибірки за допомогою калькулятора A/B-тестів | |
| 5.5 | Неідентифіковані виключено з аналізу | Відвідувачі, яких не вдалося сегментувати, виключаються з розрахунку приросту | |
| 5.6 | Пов'язано з пайплайном | Ліди з персоналізованих сесій можна простежити до можливостей у CRM |
6. Управління (5 перевірок)
| # | Перевірка | Умова проходження | Статус |
|---|---|---|---|
| 6.1 | Відповідального призначено | Одна людина відповідає за програму персоналізації та затверджує нові правила | |
| 6.2 | Є перелік правил | Список усіх активних правил зі сторінкою, сегментом, датою старту й поточним результатом | |
| 6.3 | Частота перегляду | Активні правила переглядаються щонайменше щокварталу; правила без вимірюваного ефекту виводяться з ужитку | |
| 6.4 | Процес змін | Нові варіанти проходять той самий QA, що й реліз сайту | |
| 6.5 | Відділ продажів у курсі | Відділ продажів знає, які сегменти бачать які повідомлення, тож дзвінки не суперечать сайту |
7. Конфіденційність (5 перевірок)
| # | Перевірка | Умова проходження | Статус |
|---|---|---|---|
| 7.1 | Згоду дотримано | Скрипти, що зберігають або зчитують необов'язкові дані на пристрої, запускаються лише після згоди там, де цього вимагає закон (в ЄС — правила ePrivacy: Directive 2002/58/EC) | |
| 7.2 | Правову підставу задокументовано | Ваші записи називають правову підставу GDPR для кожного використання персональних даних у персоналізації (Регламент (ЄС) 2016/679) | |
| 7.3 | Повідомлення про конфіденційність оновлено | Політика конфіденційності описує персоналізацію сайту й залучених постачальників | |
| 7.4 | Жодних висновків щодо чутливих даних | Жодне правило не націлюється на ознаки здоров'я, політичних чи релігійних поглядів або подібні чутливі характеристики й не розкриває їх | |
| 7.5 | Жодних текстів на кшталт «ми знаємо, хто ви» | Варіанти ніколи не називають відвідувача чи його компанію так, щоб це нагадувало стеження |
Це чек-лист, а не юридична консультація. Наш пост про B2B-персоналізацію та захист даних розглядає тему глибше; конкретні питання уточнюйте з юристом.
Оцінювальна таблиця
Оцініть кожну групу як кількість пройдених перевірок, поділену на загальну кількість. «Невідомо» зараховується як непройдена.
| Оцінка групи | Значення | Що робити |
|---|---|---|
| 80% або більше | Готово | Підтримуйте; шукайте наступний сегмент або сторінку |
| Від 50% до 79% | Прогалини | Виправте невдалі перевірки в цій групі, перш ніж додавати нову персоналізацію, що від неї залежить |
| Нижче 50% | Не готовий | Призупиніть розширення; спершу виправте цю групу, починаючи з найпершої в списку |
Дві обов’язкові умови переважають бали. Якщо пункт 4.3 (запасний варіант) не пройдено, виправте його насамперед, бо зламаний стандартний варіант впливає на кожного неідентифікованого відвідувача. Якщо не пройдено 5.1 (контрольна група), ви не можете заявляти жодного результату персоналізації, хоч би що показував дашборд.
Ілюстративний приклад
Ілюстративний приклад, не реальна компанія. Команда B2B-компанії з розробки ПЗ шість місяців використовує галузеву персоналізацію на головній сторінці. Їхній аудит:
| Група | Пройдено | Оцінка | Ключовий недолік |
|---|---|---|---|
| 1. Дані | 5 із 7 | 71% | 1.2: ніхто не перевіряв якість зіставлення |
| 2. Сегменти | 4 з 6 | 67% | 2.4: клієнти бачать «замовити демо» |
| 3. Контент | 4 з 6 | 67% | 3.2: два логотипи без дозволу |
| 4. Перевірка якості досвіду | 5 із 7 | 71% | 4.1: помітне мерехтіння на мобільних |
| 5. Вимірювання | 2 з 6 | 33% | 5.1: немає контрольної групи |
| 6. Управління | 3 з 5 | 60% | 6.3: жодне правило ніколи не виводили з використання |
| 7. Приватність | 4 з 5 | 80% | 7.3: політика не згадує персоналізацію |
Команда вважала, що програма працює, бо конверсія головної сторінки зросла після запуску. Без контрольної групи вони не можуть відокремити це від сезонності чи кампанії. Їхній наступний місяць: прибрати два логотипи без дозволу (виправлення того ж дня), додати правило для клієнтів, а потім перезапустити з контрольною групою 50% для кожного сегмента й заздалегідь розрахованими розмірами вибірки. Якщо вам потрібна структура для перезапуску, її описує шаблон плейбука персоналізації.
Поширені запитання
Що таке аудит персоналізації сайту?
Це структурована перевірка того, чи може ваш сайт надійно показувати різний контент різним сегментам відвідувачів і чи дає це вимірювані результати. Вона охоплює дані для сегментації відвідувачів, самі сегменти, контент для кожного сегмента, технічну якість, як-от мерехтіння та резервні варіанти, вимірювання, управління та конфіденційність.
Як часто проводити аудит персоналізації сайту?
Пройдіть увесь чекліст перед запуском персоналізації, а потім двічі на рік. Переглядайте групу Experience QA після кожного релізу сайту чи зміни шаблону, бо мерехтіння та зламані резервні варіанти зазвичай з'являються непомітно, коли змінюється структура сторінки. Переглядайте вимірювання щоразу, коли правило пропрацювало повний тестовий цикл.
Яка найпоширеніша проблема, що виявляється під час аудиту персоналізації?
На нашу думку, найбільше шкодить відсутність контрольних груп, бо через неї жоден заявлений результат неможливо довести. Команди порівнюють конверсію до і після запуску та приписують персоналізації зміни, спричинені сезонністю, кампаніями чи змінами у відстеженні. Натомість призначте частку кожного сегмента до стандартного варіанта й порівнюйте дві групи.
Чи впливає персоналізація сайту на SEO?
Не повинна, якщо пошукові системи бачать той самий контент за замовчуванням, що й неідентифіковані відвідувачі, а варіанти змінюють лише блоки на сторінці для ідентифікованих сегментів. Проблеми починаються, коли title, canonical чи індексований текст відрізняються для ботів, що може виглядати як клоакінг. Тримайте персоналізацію на стороні клієнта чи edge на рівні контентних блоків і не чіпайте метадані.