Налаштування цілі в Astrina — це не те саме, що ввімкнути повний моніторинг. Ціль менша. Вона позначає одну умову успіху для одного робочого процесу, наприклад заповнену форму, підтверджений крок оформлення замовлення або внутрішню перевірку QA. Якщо ви шукаєте, як налаштувати цілі Astrina, почніть із того, щоб сприймати кожну ціль як один чітко вимірюваний фініш, особливо коли мова йде про Astrina цілі для checkout і QA.
Такий вузький підхід важливий, бо одна ціль має відповідати на одне запитання. Чи надіслав користувач форму? Чи сторінка дійшла до стану «дякуємо»? Чи тестовий сценарій завершив останній крок? Обирайте одну відповідь, а не три. Чіткі визначення економлять час пізніше, особливо коли колега відкриває результат після релізу в п’ятницю по обіді.
1. Визначте, що має означати “ціль” у вашому обліковому записі Astrina
Починайте з бізнес-сенсу, а не з кнопки. Ціль може означати конверсію, етап, завершену дію або внутрішню перевірку QA. Ці чотири випадки виглядають схоже на папері, але на практиці поводяться по-різному. Конверсія зазвичай важлива для доходу. Етап може бути проміжним станом. Перевірка QA може бути важливою лише для продукт-команди.
Один завантажений екран — це не ціль. Один успішний API-відгук теж не завжди ціль. Питання в тому, чи доводить дія, що робочий процес досяг потрібного стану. Якщо вашій службі підтримки треба знати, що платіжний крок завершено, ціль має сказати це прямо. Якщо вашій QA-команді потрібно знати, що після входу відкрився модальний вікно, це вже інша ціль.
Тримайте визначення вузьким. Ціль на кшталт “користувач завершив онбординг” звучить акуратно, але може приховати три різні стани: створення акаунта, підтвердження електронної пошти та заповнення профілю. Розділіть їх, якщо кожен збій важливий окремо. Дві маленькі цілі читати легше, ніж одну розмиту.
2. Оберіть одну конкретну дію користувача, яку перетворите на ціль
Оберіть одну дію і тримайтеся її. Надсилання форми — хороший приклад. Так само як натискання фінальної кнопки “Підтвердити”, перехід на сторінку успіху або поява видимого стану на сторінці після оформлення замовлення. Дія має бути такою, яку Astrina може визначити без здогадок про наміри користувача.
Не об’єднуйте дії. “Користувач зареєструвався і підтвердив email” звучить ефективно, але змішує дві події й створює плутанину, коли відбувається лише одна частина. Ціль має або чітко провалитися, або чітко спрацювати. Без проміжних варіантів. Якщо робочий процес має п’ять кроків, оберіть той, який доводить успіх саме для цієї цілі, а решту відкиньте.
Тут допомагають конкретні приклади. Ціль для checkout може бути “сторінка оплати показує підтверджене замовлення”. Ціль для контентного процесу може бути “кнопка публікації змінює статус на live”. Ціль для support-процесу може бути “форма тікета показує повідомлення подяки”. У кожної є одна дія, один результат і одна причина існування.
3. Прив’яжіть ціль до точного тригера, який може розпізнати Astrina
Коли дія зрозуміла, прив’яжіть її до сигналу, який Astrina може виміряти. Це може бути умова URL, зміна DOM, збіг тексту або інша подія, яку підтримує продукт. Тригер має бути достатньо конкретним, щоб вказувати на один результат, а не на цілу сім’ю схожих результатів. Якщо вам потрібна опорна точка для поточних назв елементів керування або доступних полів, перевірте ендпоінти, автентифікацію та квоти і зіставте їх із живими екранами продукту, перш ніж запускати ціль.
Використовуйте саме те, що змінюється, коли ціль виконано. Сторінка подяки часто має окремий URL. Стан успішного checkout може змінити напис на кнопці або показати номер замовлення. Перевірка QA може відкрити конкретний елемент DOM. Не покладайтеся на широкий шаблон, якщо існує вузький, бо широкі шаблони занадто часто ловлять не той результат.
Саме тут дисципліна в назвах приносить користь. Якщо Astrina просить селектор, зробіть його читабельним. Якщо інтерфейс просить назву події, назвіть її за реальною дією, а не за внутрішнім жартом команди з 2022 року. Один зрозумілий тригер кращий за чотири кмітливі.
4. Визначте межі успіху та провалу
Ціль має розпізнавати справжнє завершення й ігнорувати майже-успіхи. Звучить просто, поки в гру не входять повторні спроби, редиректи та часткові завантаження. Форма може надіслатися двічі. Checkout може на мить показати повідомлення успіху, а потім видати помилку. Сторінка може показати правильний текст до повного завантаження даних. Ваша ціль має ігнорувати ці хибні спрацьовування.
Поставте межу успіху навколо фінального доказу завершення. Якщо робочий процес закінчується на сторінці статусу, вимагайте стан сторінки, який з’являється лише після завершення. Якщо він завершується зміною DOM, вимагайте зміну, яка з’являється лише після фінального кроку. Якщо він завершується URL, будьте точними щодо умови. Невеликі прогалини створюють погані результати. Погані результати марнують час на перевірки.
Межі провалу не менш важливі. Ціль не має спрацьовувати на частковому прогресі, кнопках повторної спроби чи заглушках. Якщо в checkout є “Зберегти на потім” і “Купити зараз”, зараховуватися має лише один із варіантів. Якщо у формі є “наступний крок” і “відправити”, зараховуватися має лише один. Чим чистіша межа, тим менше сюрпризів у звіті.
5. Налаштуйте назву, мітки та відповідального за ціль
Назвіть ціль так, щоб інша людина могла зрозуміти її за п’ять секунд. “Сторінка успіху checkout” краще, ніж “Goal 7”. “Форма підтримки надіслана — staging” краще, ніж “Контактна форма”. Команда з шістьма цілями ще може жити з нечіткими назвами; команда з шістдесятьма — ні. Зберігайте послідовний шаблон для всього акаунта.
Мітки допомагають, коли цілі групують за релізом, середовищем або відділом. Один тег може позначати staging. Інший — production. Третій — продуктову область, наприклад billing або onboarding. Йдеться не про декор. Йдеться про те, щоб фільтрація була очевидною, коли комусь потрібен набір цілей для рев’ю релізу або передачі роботи.
Останній елемент — відповідальність. Одна людина, одна команда або одна спільна черга мають відповідати за зміни. Якщо ніхто не володіє ціллю, ніхто не помічає, коли зміна інтерфейсу її ламає. Якщо відповідальність нечітка, запишіть це поруч із ціллю або в командному runbook. Коротка примітка — менше суперечок.
6. Перевірте ціль на одному реальному сценарії
Спершу протестуйте ціль на одному відомому успішному сценарії. Використайте реальний випадок, який має спрацювати, а не синтетичний крайній кейс. Потім перевірте один відомий невдалий сценарій, який має не спрацювати. Така пара скаже вам більше, ніж дюжина здогадок. Якщо ціль проходить обидва тести, тригер занадто широкий. Якщо не проходить жодного, тригер занадто вузький або вказує не на той сигнал.
Наприклад, ціль для checkout має спрацювати, коли замовлення справді завершено, і не спрацювати, коли користувач покидає кошик посередині. Ціль для реєстрації має спрацювати, коли з’являється крок підтвердження, і не спрацювати, коли користувач зупиняється після введення email. Тримайте тест маленьким. Не потрібно повторювати весь процес налаштування моніторингу лише для перевірки однієї цілі.
Якщо результат виглядає дивно, перевірте, чи прив’язана ціль до правильної дії або правильного середовища. Ціль для staging, що працює на production-даних, може дати дуже заплутані докази. Ця помилка трапляється частіше, ніж команди готові визнати. Її можна уникнути.
7. Перегляньте результат цілі та вирішіть, що змінити
Після тесту перегляньте записаний результат так само уважно, як ви б дивилися на звіт для клієнта. Чи може стейкхолдер прочитати його без перекладу? Чи показує результат правильний стан успіху? Чи вказує він точний тригер, а не розмите pass/fail? Якщо результат важко читати, ціль ще не готова.
Змініть тригер, якщо ціль занадто широка. Посильте межі, якщо проходять часткові результати. Перейменуйте ціль, якщо назва не збігається з робочим процесом, який справді завершився. У деяких випадках проблема не в тригері, а у формулюванні. Ціль із назвою “signup” може потребувати назви “створення акаунта”, якщо це справжній фініш.
Ось одна практична звичка: переглядайте ціль разом із людиною, яка її не створювала. Якщо вона може правильно пояснити її однією фразою, ціль, імовірно, хороша. Якщо ні — ціль, мабуть, приховує забагато деталей або використовує сигнал, який розуміє лише автор.
8. Підтримуйте ціль у актуальному стані, коли продукт змінюється
Цілі швидко застарівають, коли продукт змінюється, а ніхто їх не перевіряє. Оновлення інтерфейсу може пересунути кнопку. Зміна воронки може перейменувати крок. Новий потік може зробити старий застарілим. Перевіряйте кожну ціль після таких змін, а не через шість місяців. Найшвидше ламається та ціль, яка прив’язана до сторінки, якої вже не існує.
Запровадьте просту звичку перевірки навколо релізів. Після редизайну підтвердьте, що стан успіху все ще існує. Після зміни checkout перевірте, що сторінка підтвердження все ще несе той самий сигнал. Після нового онбординг-потоку переконайтеся, що стара ціль усе ще актуальна або вже виведена з експлуатації. Невеликі перевірки запобігають великим непорозумінням.
Якщо вам також потрібна допомога з інтерпретацією сповіщень у цих перевірках, гайд про що робити, коли astrina alerts допоможе відрізнити зламану ціль від зламаного шляху сповіщення. Це заощаджує час під час вікна релізу.
Команди, які ведуть документацію, можуть піти ще далі й додати до цілі коротку внутрішню нотатку. Вкажіть тригер, відповідального та дату останньої перевірки. Три поля. Цього достатньо. Якщо ціль переходить до іншої людини, наступній не має знадобитися зустріч, щоб зрозуміти, чому вона існує.
Практичні приклади хорошої цілі Astrina
Хороша ціль має одну дію, один сигнал і одного відповідального. Команда checkout може визначити ціль навколо стану підтвердженого замовлення після оплати. Маркетингова команда може визначити ціль навколо заповненої форми ліда. QA-команда може визначити ціль навколо модального вікна, яке з’являється лише після ввімкнення feature flag. Кожен приклад використовує один вимірюваний результат.
Ось тест: якщо прибрати одне речення з визначення й ціль стане розмитою, визначення, ймовірно, було занадто бідним. Якщо додати ще три умови й ціль стане важче читати, визначення, ймовірно, було занадто перевантаженим. Правильна ціль зазвичай — найпростіша з тих, що все ще ловить потрібний результат.
| Тип цілі | Приклад тригера | Чого уникати |
|---|---|---|
| Конверсія | URL успіху після оплати | Сторінка кошика, чернетка подяки, екран повторної спроби |
| Етап | Крок профілю завершено | Будь-яка сторінка з кнопкою “далі” |
| Перевірка QA | Елемент з’являється після входу | Індикатор завантаження, частковий рендер |
Якщо ви все ще вирішуєте, як ціль вписується в ширший робочий процес, стаття про astrina для нетехнічних власників сайтів пропонує корисний спосіб думати про просту відповідальність і чіткі перевірки. Така перспектива особливо зручна, коли ціль підтримує не та людина, яка створювала сторінку.
Поширені помилки, яких варто уникати
Перша помилка — змусити одну ціль виконувати дві роботи. Ціль, що відстежує і реєстрацію, і оплату, може провалюватися з причин, які не мають стосунку до справжньої проблеми. Друга помилка — використовувати тригер, який з’являється занадто рано. Повідомлення “успіх”, яке завантажується до завершення фінальної дії, — це пастка. Третя помилка — залишити поле відповідального порожнім і сподіватися, що команда сама все пам’ятатиме. Команди рідко так роблять.
Ще одна помилка — називати ціль за абстрактною бізнес-ідеєю, а не за видимим результатом. “Утримання” — це не ціль. “Сторінка продовження підтверджує підписку” — це ціль. Різниця здається малою, але саме вона вирішує, чи зрозуміє наступний читач тест, чи відкриє тред у Slack із запитанням, що сталося.
І нарешті, не дозволяйте одній старій цілі залишатися недоторканою після двох змін продукту. Ціль, яка відповідала UI в березні, може бути хибною вже в червні. Якщо робочий процес змінився, ціль має змінитися теж. Без драми.
Залишайте визначення цілі достатньо коротким, щоб воно витримало зміни
Корисне визначення цілі часто вміщується в одному реченні та одній примітці про відповідального. Така межа змушує бути чіткими. Вона також пришвидшує перевірки, коли колега дивиться в акаунт перед релізом. Ціль має сказати, як виглядає успіх, де він з’являється і хто за нього відповідає. Усе інше, можливо, належить до документації, а не до самої цілі.
Якщо вам потрібно повернутися до продуктових поверхонь, які живлять ціль, порівняйте поточний робочий процес із деталями live-перевірки та, за потреби, з продуктною документацією про як перевірити, чи сайт поводиться очікувано також на мобільних пристроях. Ціль, прив’язана до стану лише для мобільних, може зламатися, якщо ніхто не помітить зміну макета.
Ось у чому справжня робота над тим, як налаштовувати цілі Astrina: одна дія, один сигнал, один відповідальний, а потім тест, який доводить, що ціль і досі означає те, що команда вважає її значенням.
