Як розрахувати рівень скарг у email-розсилках

Коли потрібен рівень скарг, а не кількість скарг

Кількість скарг показує, скільки людей натиснули «повідомити про спам». Рівень скарг показує, як ця цифра поводиться відносно обсягу. Це не одне й те саме, і саме тому рівень скарг email корисніший для порівнянь.

Якщо одна кампанія надіслала 10 000 повідомлень і отримала 20 скарг, а інша — 500 і 6 скарг, то за сирою кількістю гіршою виглядає перша. Рівень змінює картину. Саме тому розрахунок рівня скарг на електронні листи важливий в аудитах доставлюваності, особливо коли потрібно порівнювати кампанії, списки або місяці з дуже різними обсягами відправлень.

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

Один застережний момент: низька кількість скарг ще не означає, що проблем немає. Дві скарги на відправку в 200 листів — це зовсім інший сигнал, ніж дві скарги на 20 000. Перший випадок може вимагати паузи.

Кількість скарг відповідає на запитання «скільки». Рівень відповідає на запитання «наскільки, відносно обсягу».

Визначте точне вікно вимірювання

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

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

Звітність за днем кампанії — інша справа. Якщо кампанія розгортається у дві хвилі о 9:00 та 15:00, треба вказати, чи охоплює вікно весь день, чи лише кожну хвилю окремо. Інакше ті самі скарги можуть бути пораховані двічі в одному графіку команди й один раз в іншому.

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

Запишіть це вікно. Серйозно. «Звіт за березень» — надто розпливчасто.

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

Оберіть знаменник: надіслано, доставлено чи доставлено мінус відхилені

Знаменник змінює рівень. Це не дрібниця. Це змінює зміст числа.

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

Оберіть один знаменник і дотримуйтеся його. Внутрішня звітність ламається в момент, коли одна панель використовує «надіслано», а інша — «доставлено». Формально обидві формули виглядають правильно, і саме в цьому проблема.

Практичне правило таке: якщо ви порівнюєте поведінку скарг після доставки, використовуйте «доставлено». Якщо ви порівнюєте операційний обсяг у системі надсилання, використовуйте «надіслано». Потім позначайте метрику зі знаменником у заголовку графіка, а не лише в примітці.

Для аудитів важливіша послідовність, ніж елегантність. Команда може змиритися з трохи незграбним визначенням. Але не зможе працювати з числом, яке змінює сенс від звіту до звіту.

Достатньо одного речення: оберіть один раз.

Застосуйте формулу в таблиці або дашборді

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

Наприклад, якщо скарги в комірці B2, а доставлений обсяг у C2, формула буде =B2/C2. Якщо команда хоче бачити відсоток, множте на 100 на рівні відображення, а не на рівні даних. Так сире значення залишиться доступним для подальших перевірок.

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

Слідкуйте за порожніми комірками та текстовими значеннями. Порожній знаменник не повинен мовчки ставати нулем. Таблиця, яка повертає «#DIV/0!», дратує, але це краще, ніж хибний нуль.

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

Ось акуратний робочий процес:

• Завантажте загальну кількість скарг.
• Завантажте обраний обсяг електронних листів.
• Переконайтеся, що обидва показники охоплюють одне й те саме вікно.
• Поділіть загальну кількість скарг на обсяг листів.
• Збережіть назву формули у звіті.

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

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

Одна кампанія — це просто. Три кампанії з різними обсягами відправки — ні. Постає питання: усереднювати рівні чи спочатку підсумувати дані?

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

Чому усереднення вводить в оману? Бо 2% для 100 повідомлень і 0,2% для 10 000 повідомлень не повинні мати однакову вагу. Більша відправка важить більше. Просте усереднення ставить їх на один рівень, а це неправильно.

Використовуйте сумування, коли кампанії належать до однієї групи звітності, одного вендора або одного періоду аудиту. Використовуйте окремі рівні, коли кампанії обслуговують різні аудиторії, наприклад транзакційні та промо-листи. Ці два типи листування рідко мають бути в одній метриці без позначок.

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

Коротка ремарка: середні значення чарівні й часто хибні.

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

Обробляйте крайові випадки, що спотворюють результат

Маленькі відправки швидко спотворюють рівні. Одна скарга на 50 листів — це 2%, і це звучить драматично, бо так і є. Та сама одна скарга на 50 000 листів майже не рухає показник. Обидва сигнали реальні. Вони просто означають різні речі.

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

Частково доставлена пошта — ще одна пастка. Якщо було надіслано 8 000, а доставлено лише 7 200, знаменник має точно відповідати обраному визначенню. Змішування «надіслано» та «доставлено» в одному аудиті — це шлях до тихого спотворення результату.

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

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

Звернення до підтримки також можуть плутати картину. Лист клієнта до підтримки про спам — це не завжди формальна скарга в системі поштового провайдера. Саме тому скарги на спам у розсилці та тикети підтримки слід тримати окремо, якщо ваша методологія звітності прямо не об’єднує їх.

Для суміжної роботи з гігієною списків варто прочитати посібник про управління списком придушення email · YourTrend, коли обробка скарг і правила придушення перетинаються. Рівень скарг без подальшої роботи з придушенням — це лише половина історії.

Позначте результат для внутрішньої звітності

Хороший звіт точно каже, що це за число. Не майже. Саме точно.

Позначте результат трьома елементами: формулою, вікном і знаменником. Наприклад: «Рівень скарг = скарги / доставлені листи, виміряно для вікна кампанії 2026-03-01». Одна така фраза дає читачеві достатньо, щоб безпечно порівнювати показник.

Якщо ви виключали певні відправки, скажіть про це. До виключень можуть належати внутрішні тестові листи, seed-списки або регіони поза межами аудиту. Якщо не зазначити це, число виглядатиме чистішим, ніж є насправді.

Використовуйте ту саму назву в кожній презентації, дашборді та CSV-експорті. Щойно команда бачить «рівень скарг» в одному файлі й «рівень спаму» в іншому, починається плутанина. Команда може мати на увазі одне й те саме, але назва цього не доводить.

Внутрішня звітність також виграє від рядка з визначенням під графіком. Робіть його коротким. Одного речення достатньо, якщо воно містить знаменник і період. Довші примітки після першого тижня зазвичай ігнорують.

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

Тут проста дисципліна: спочатку позначте, потім діліться. Число без позначки провокує трактування, яке може виявитись неправильним через один знаменник або один день.

Перевірте число на адекватність перед тим, як ділитися ним

Перед тим як надсилати звіт, перевірте підсумки. Кількість скарг має збігатися з журналом подій або експортом платформи. Знаменник має відповідати тому самому вікну. Якщо ці два поля не збігаються, рівень ще не готовий.

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

Далі перевірте дублікати. Однієї повторної події скарги достатньо, щоб спотворити маленьку відправку. Хороший аудит включає ID повідомлень, часові мітки та назви кампаній, навіть якщо фінальний звіт показує лише одне число.

Потім перевірте математику. Перерахуйтe один рядок вручну. Це займає 30 секунд і ловить багато помилок. Невідповідність тут зазвичай вказує на неправильний фільтр або випадкове об’єднання.

Особливо уважно слідкуйте за розбіжностями знаменника. Метрика «скарги / надіслано» і метрика «скарги / доставлено» можуть стояти поруч і звучати однаково, але означати різні речі. Саме так приймають погані рішення на основі красивих графіків.

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

І остання перевірка: переконайтеся, що назва файлу, заголовок графіка і текст у тілі звіту використовують один і той самий знаменник. Якщо на слайді написано «доставлено», а в нотатках — «надіслано», виправте це до того, як хтось перешле PDF далі.