Назви та мітки для сценаріїв, повідомлень, груп та полей контактів

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

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

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

---

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

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

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

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

---

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

eSputnik надає три способи описати та впорядкувати об'єкти. Кожен виконує свою роль:

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

Опис — довільні нотатки. Використовуйте опис для пояснення логіки правила групи, гіпотези A/B-тесту або будь-якого контексту, який зробив би назву занадто довгою.

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

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

---

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

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

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

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

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

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

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

---

Сценарії

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

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

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

Приклади:

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

---

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

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

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

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

Приклади:

Порядкові номери vs. назви на основі ролі. Порядкова нумерація добре працює для коротких серій. Для довших drip-кампаній часто краще масштабуються назви на основі ролі — AbandonedCart_Reminder, AbandonedCart_Urgency, AbandonedCart_LastCall — бо вставка або перестановка кроків не вимагає перейменування. Якщо ви вже використовуєте порядкові номери і потрібно вставити крок між S01 і S02, використовуйте S01b або плануйте проміжки з самого початку (S10, S20, S30), щоб нові кроки вписувалися без порушення історичної аналітики.

---

Групи

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

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

Приклади:

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

---

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

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

Правила:

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

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

loyaltyTier
loyaltyPoints
loyaltyJoinDate
loyaltyExpiryDate

---

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

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

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

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

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

Обидва типи підпорядковані однаковій логіці найменування. Використовуйте мітки для:

• Типу відправки (тригерна або масова)
• Етапу lifecycle (для фільтрації між об'єктами)
• A/B-експерименту
• Статусу об'єкта
• Відповідального або команди

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

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

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

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

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

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

---

Усе разом

Ось як конвенції працюють у межах одного lifecycle-потоку:

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

---

Довідник найменування

Довідник міток

---

Підтримка конвенції

• Призначте відповідального. Одна-дві людини (Marketing Ops або CRM lead) мають переглядати нові об'єкти та стежити за дотриманням конвенції.
• Документуйте скорочення. Кожне скорочення, яке використовує команда — lc_, ab_, type_ — має бути зафіксоване у внутрішньому словнику найменування, щоб нові члени команди могли швидко увійти в курс.
• Виправляйте по дорозі. Редагуючи старий об'єкт, який не відповідає конвенції, перейменуйте його в рамках тієї самої задачі.
• Якщо ви впроваджуєте конвенції в наявному акаунті — не перейменовуйте все одразу. Починайте з нових об'єктів і перейменовуйте старі в міру роботи з ними. Поступове впровадження стійкіше, ніж одноразова кампанія, яку рідко вдається завершити.
• Архівуйте, а не видаляйте. Коли об'єкт застаріває, додайте status_deprecated — він залишиться доступним для довідки, але зникне з активних відфільтрованих переглядів.

---

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