Назви та мітки для базових елементів в eSputnik

Сценарії, повідомлення, групи та поля контактів — це базові елементи вашого акаунту eSputnik. Що більше об'єктів ви створюєте, то складніше в них орієнтуватися без спільних правил назв і міток.

Ця стаття буде корисна командам, які регулярно створюють сценарії, повідомлення, групи та поля контактів у eSputnik і хочуть підтримувати порядок в акаунті. У ній зібрано правила, які допоможуть узгодити назви й мітки для основних типів об'єктів, налаштувати зручну фільтрацію та уникнути помилок, що ускладнюють аналітику.

Про правила найменування кастомних подій та їхніх параметрів читайте за посиланням.

---

Чому це важливо

Узгоджені назви покращують аналітику. Назви повідомлень потрапляють до UTM-параметрів і відображаються безпосередньо в Google Analytics. Назва на кшталт AbandonedCart_S01 легко фільтрується за кампанією і порядком у серії, а назва new email copy створює шум, в якому важко розібратися через кілька місяців.

Команда працює за єдиною логікою. Якщо всі дотримуються однієї структури, не виникає питань: що охоплює та чи інша група, який сценарій активний і чи є повідомлення чернеткою або робочим шаблоном.

Послідовні назви й мітки допомагають уникати помилок у роботі з ШІ-агентами. Коли сценарії, групи, поля та мітки мають зрозумілу структуру, агентам легше правильно інтерпретувати об'єкти під час налаштування кампаній або аналізу.

---

Три інструменти для організації об'єктів

В eSputnik є три способи описати й упорядкувати об'єкти:

• Назва — основний спосіб одразу зрозуміти, що це за об'єкт. Вона відображається в списках, звітах і UTM-параметрах, тому має бути читабельною, послідовною і стабільною.
• Мітка — додаткова позначка для фільтрації та групування. Використовуйте мітки для того, що часто фільтруєте, але не хочете кодувати в кожній назві: тип відправки, етап життєвого циклу, статус, відповідальний.
• Опис — додатковий контекст у довільній формі. Використовуйте його, щоб пояснити логіку правила групи, гіпотезу A/B-тесту або будь-яку деталь, яка зробила б назву занадто довгою.

Якщо назва стає занадто довгою, частину інформації, ймовірно, краще винести в мітку або опис.

---

Базові принципи

Від загального до конкретного. Поля в назві завжди йдуть в одному порядку — від широкого контексту до конкретної деталі. Це дає змогу спискам природно групуватися за типом та етапом воронки.

Узгоджений словник скорочень. Використовуйте фіксований набір скорочень у межах команди. Для кодів країн і ринків дотримуйтесь ISO 3166 alpha-2 country codes, щоб значення на кшталт DE, PL та US були узгоджені в усіх системах і звітах. Кожне скорочення має бути зафіксоване у внутрішньому словнику. Пам'ятайте: назви бачать не лише маркетологи — вони відображаються у звітах для продажів і менеджменту, тому неочевидні скорочення, зрозумілі лише автору, ускладнюють роботу всій команді.

Назви описують роль, а не версію. Назва має пояснювати призначення об'єкта, а не відстежувати його історію редагувань. Зайві слова на кшталт _v2, _new або _copy накопичуються з часом і не несуть корисної інформації. Для відстеження змін використовуйте поле опису. Примітка: суфікси V1/V2 — це окреме правило виключно для варіантів A/B-тестів (детальніше в розділі Повідомлення нижче).

Не додавайте в назви тимчасові слова. new, copy, test та особисті маркери на кшталт anna_segment роблять назви неоднозначними. BF_Nov14_v2_copy нічого не скаже через півроку. Використовуйте структуровану назву, а контекст виносьте в опис.

Для масових розсилок вказуйте дату запуску, а для тригерних — порядковий номер у серії. Для разових відправок на кшталт BF2025_S01 додавання дати — BF2025_1114_S01 — допомагає прив'язати GA-трафік до конкретного дня через кілька місяців. Для тригерних повідомлень життєвого циклу важливий не момент відправки, а місце в серії: AbandonedCart_S01, AbandonedCart_S02. Дата тут не має сенсу — повідомлення надсилається безперервно.

Для різних об'єктів потрібен різний рівень деталізації в назві. Для сценаріїв і груп використовуйте зрозумілі бізнес-назви. Для повідомлень — коротші назви, які легко сканувати у списку. Для полів контактів — технічні назви в camelCase, бо вони також використовуються в API і персоналізації.

---

Що означають умовні позначення в назвах

У назвах нижче використовуються короткі умовні позначення:

• Stream — основний контекст назви: етап життєвого циклу, тип кампанії або серія повідомлень, наприклад Welcome, Reactivation, AbandonedCart, PostPurchase.
• Goal — ціль сценарію, якщо її потрібно уточнити в назві.
• Market — країна або ринок, якщо об'єкт справді відрізняється залежно від ринку.
• Seq — порядковий номер повідомлення в серії.
• Role — роль повідомлення в серії, наприклад Reminder, Offer, Urgency, LastCall.
• Variant — варіант A/B-тесту.

---

Сценарії

Назва сценарію має відповідати на питання: який це етап воронки і чого сценарій має досягти?

Патерн: [Stream]_[Goal (якщо потрібно)]_[Market (опційно)]

Примітка про локалізацію. eSputnik підтримує багатомовні повідомлення нативно, тому здебільшого не потрібно розділяти сценарії за мовою. Додавайте суфікс ринку лише тоді, коли сам сценарій відрізняється — наприклад, інша структура пропозиції, інші канали або правові вимоги для конкретного ринку.

Приклади:

Деякі типи кампаній самодостатні й не потребують суфікса Goal — AbandonedCart уже передбачає відновлення кошика. Додавайте Goal тоді, коли один Stream може слугувати різним цілям: Reactivation_WinbackDormant vs Reactivation_ReturnFromChurn.

---

Повідомлення

Назва повідомлення має показувати, до якої кампанії або серії воно належить, і його позицію або роль у ній — без потреби відкривати повідомлення. Канал уже визначається місцем повідомлення в системі. Тип відправки (тригерна або масова) позначається через мітки.

Для найменування повідомлень можна використовувати два підходи:

Порядкова нумерація

Підходить для коротких серій, де порядок фіксований.

Патерн: [Stream]_[Seq]_[Variant (опційно)]

Приклади: AbandonedCart_S01, AbandonedCart_S01_V1, BF2025_S01, Welcome_S02

Назви на основі ролі

Підходять для довших серій або коли кроки можуть змінюватися. У такому разі вставка або перестановка кроків не вимагають перейменування інших повідомлень.

Патерн: [Stream]_[Role]_[Variant (опційно)]

Приклади: AbandonedCart_Reminder, AbandonedCart_Urgency, AbandonedCart_LastCall, AbandonedCart_Reminder_V1

Щоб рольові назви залишалися послідовними, домовтеся в команді про короткий набір стабільних role-token'ів — наприклад, Reminder, Offer, Urgency, LastCall, FollowUp — і не використовуйте різні слова для однієї й тієї самої ролі.

Оберіть один підхід для кожної серії і дотримуйтеся його. Не змішуйте нумерацію і рольові назви в межах однієї серії.

Щоб розрізняти тригерні та масові повідомлення у відфільтрованих переглядах, використовуйте мітки type_triggered та type_broadcast.

Приклади — порядкова нумерація:

Приклади — назви на основі ролі:

Якщо ви використовуєте порядкові номери і потрібно вставити крок між S01 і S02, використовуйте S01b або плануйте проміжки з самого початку: S10, S20, S30 — щоб нові кроки вписувалися без порушення аналітики.

---

Групи

Назва групи має відповідати на питання: на якому етапі життєвого циклу перебувають ці контакти і яке визначальне правило їх об'єднує?

Патерн: [LifecycleStage]_[SegmentRule]

AOV (Average Order Value) — середній чек замовлення.

Приклади:

Уникайте розмитих термінів життєвого циклу, які використовуються в акаунті взаємозамінно. Визначте один раз, що означає кожен етап — наприклад, Active = здійснив замовлення впродовж останніх 30 днів — і послідовно дотримуйтеся цього визначення. Зафіксуйте його в описі групи.

---

Поля контактів

Поля контактів використовуються в персоналізації повідомлень, умовах фільтрації груп та API-інтеграціях. Погано назване поле призводить до помилок у всіх трьох випадках.

Правила:

• Використовуйте camelCase: перше слово з малої літери, наступні — з великої. Уникайте пробілів, підкреслень і спеціальних символів там, де це можливо.
• Називайте поле за даними, які воно зберігає, а не за джерелом або способом використання.
• Назва має бути достатньо конкретною, щоб поле було зрозумілим без документації.
• Не зберігайте непов'язані значення в одному полі (наприклад, не об'єднуйте рівень лояльності та дату його закінчення в один рядок).
• Не створюйте поле для однієї тимчасової кампанії. Поле контакту має представляти стабільний атрибут контакту, а не стан кампанії.

💡

Якщо кілька полів належать до одного домену, використовуйте спільний префікс. Це групує поля разом у списку і робить умови фільтрації легшими для читання:

loyaltyTier
loyaltyPoints
loyaltyJoinDate
loyaltyExpiryDate

---

Використання міток

Мітки — це додаткові позначки, які ви застосовуєте до повідомлень, сценаріїв, груп і звітів. Вони дають змогу фільтрувати та впорядковувати об'єкти в акаунті, не роблячи назви довшими.

Поля контактів знаходяться поза системою міток — для них назва є єдиним інструментом організації.

eSputnik має два типи міток:

• Мітки комунікацій — застосовуються до повідомлень, сценаріїв і звітів.
• Мітки груп — застосовуються виключно до груп.

Обидва типи називають за однаковими правилами.

Що виносити в мітки, а що залишати в назві

Патерн найменування міток

Дотримуйтесь формату category_value, щоб мітки легко сканувалися:

Уникайте міток на кшталт active, test або promo без префікса категорії — у міру зростання списку вони стають неоднозначними.

Використовуйте owner_, коли за об'єкт відповідає одна конкретна людина, і team_, коли йдеться про команду або спільну зону відповідальності.

Якщо потрібно позначити тимчасовий тестовий об'єкт, використовуйте status_draft або status_test, а не слово test у назві. Після завершення тестування видаляйте тимчасові об'єкти. Якщо об'єкт потрібно зберегти для довідки, позначте його міткою status_deprecated.

Позначення застарілих об'єктів

Коли сценарій, повідомлення або група замінюються, додайте мітку status_deprecated до старого об'єкта. Це зберігає його доступність для перегляду, але виключає з активних відфільтрованих переглядів при фільтрації за status_active.

---

Усе разом

Ось як ці правила працюють на прикладі одного сценарію:

Назва показує, що це за об'єкт і де він у воронці. Мітки потрібні для фільтрації за командою, відстеження тестів і позначення статусу.

---

Поширені помилки

---

Як впровадити правила в акаунті

Якщо ви починаєте з нуля:

1. Домовтеся в команді про мову назв (рекомендовано латиниця) і зафіксуйте базові скорочення у внутрішньому словнику.
2. Визначте етапи життєвого циклу для груп: що означає Active, AtRisk, Churned саме у вашому акаунті.
3. Призначте відповідального за підтримку правил (Marketing Ops або CRM lead).
4. Створюйте нові об'єкти за патернами з цієї статті з першого дня.

Якщо в акаунті вже є об'єкти:

1. Не перейменовуйте все одразу — це порушить поточну аналітику і не буде завершено.
2. Починайте з нових об'єктів: створюйте їх за новими правилами.
3. Старі об'єкти перейменовуйте поступово — коли редагуєте або перевіряєте їх у межах звичайних задач.
4. Застарілі об'єкти позначайте міткою status_deprecated, а не видаляйте одразу.

---

Як перевірити результат

Після впровадження пройдіться по списках сценаріїв, повідомлень, груп і полів контактів у відповідних розділах акаунту, а також перевірте фільтри за мітками там, де команда працює з відправками й звітами. Після цього звірте результат за цим списком:

✅ назви сценаріїв відповідають патерну Stream[_Goal][_Market];

✅ назви повідомлень відповідають одному з двох патернів: Stream_Seq[_Variant] або Stream_Role[_Variant];

✅ для однієї серії використовується один підхід до назв: або порядкова нумерація, або рольові назви;

✅ назви груп відповідають патерну LifecycleStage_SegmentRule;

✅ поля контактів записані в camelCase, без версій і тимчасових суфіксів;

✅ тип відправки позначено мітками type_triggered / type_broadcast;

✅ застарілі об'єкти мають мітку status_deprecated;

✅ усі скорочення зафіксовані у внутрішньому словнику;

✅ визначення етапів життєвого циклу зафіксовані в описах відповідних груп.

---

Шпаргалка з назв

Шпаргалка з міток

---

Підтримка правил

• Призначте відповідального. Одна-дві людини переглядають нові об'єкти та стежать за дотриманням правил.
• Ведіть спільний словник. Зафіксуйте всі узгоджені скорочення, визначення етапів життєвого циклу і допустимі значення Stream у спільному документі команди, доступному всім, хто створює або редагує об'єкти в акаунті. Відповідальний оновлює словник, коли з'являються нові сценарії, патерни назв або категорії міток.
• Виправляйте по дорозі. Редагуючи старий об'єкт, перейменуйте його в межах тієї самої задачі.
• Не видаляйте застарілі об'єкти одразу. Коли об'єкт застаріває, додайте status_deprecated — він залишиться доступним для довідки.

---

Пов'язані статті

• Додавання міток
• Робота з групами
• Найменування користувацьких подій
• Багатомовні повідомлення
• Відстеження ефективності розсилок у Google Analytics