Аналітика нотифікацій: доставка, прочитання і реакція - це три різні сигнали

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

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

Насправді доставка, прочитання і реакція відповідають на три різні питання:

• чи дійшла нотифікація до користувача;
• чи побачив він її;
• чи зробив щось після цього.

Сигнал доставки належить до технічного рівня.

Він може означати, що повідомлення:

• успішно записане в базу;
• передане через WebSocket;
• відправлене через push-провайдера;
• прийняте зовнішнім транспортом.

Але навіть успішна доставка нічого не доводить про те, чи користувач звернув на нотифікацію увагу.

Прочитання вже ближче до поведінки користувача, але й тут важливо правильно визначити момент.

Чи вважаємо нотифікацію прочитаною, коли відкрилася панель? Коли елемент потрапив у видиму частину списку? Коли користувач натиснув на конкретну нотифікацію?

Це продуктове рішення, і його треба визначити до того, як починати рахувати частку прочитаних нотифікацій.

Третій рівень - дія після прочитання.

Це може бути:

• перехід за посиланням;
• відкриття сутності, про яку повідомляла нотифікація;
• підтвердження або відхилення;
• відповідь;
• інша бізнесова дія.

Саме тут починається відповідь на питання, чи була нотифікація корисною для користувача або для процесу.

Такий перелік статусів припускає, що нотифікація проходить одну лінійну послідовність.

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

Тому часові мітки або окремі події часто краще описують реальність, ніж один "найвищий" статус.

Базові часові мітки дають достатньо інформації для більшості корисних питань:

• скільки нотифікацій реально доставляється;
• скільки з них читають;
• скільки часу проходить до прочитання;
• які типи нотифікацій частіше ігнорують.

Дії після нотифікації варто зберігати лише тоді, коли для них є чітке продуктове значення.

Велика кількість delivered notifications сама по собі майже нічого не говорить про якість системи.

Так само "90% read" може виглядати чудово, але бути мало корисним, якщо всі нотифікації автоматично позначаються прочитаними при відкритті панелі.

Показник стає малокорисним, коли він:

• гарно росте;
• легко показується на панелі аналітики;
• але не допомагає прийняти рішення або покращити продукт.

Замість "що ще можна порахувати?" корисніше спочатку визначити, яке рішення має підтримати аналітика.

Наприклад:

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

Після цього значно простіше зрозуміти, які події треба зберігати.

Якщо поняття "прочитано" зміниться між версіями продукту, історичні дані перестануть бути прямо порівнюваними.

Тому визначення події - це частина аналітичного контракту, а не просто деталь реалізації.

Слово "reaction" звучить зручно, але різні нотифікації мають різну ціль.

Для однієї це перехід до повідомлення. Для іншої - підтвердження операції. Для третьої - відкриття документа.

Тому краще зберігати конкретну дію або пов’язувати нотифікацію з бізнесовою подією, ніж просто ставити reacted = true.

Якщо в системі вже є достовірна подія "order_approved" або "message_replied", не обов’язково створювати ще одну копію тієї самої дії лише в таблиці аналітики нотифікацій.

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

Так аналітика не стає другим джерелом правди про те, що відбулося в продукті.

Якщо одна нотифікація може прийти у застосунку, через email або push-сповіщення, канал іноді корисно зберігати окремо.

Але лише тоді, коли команда реально порівнюватиме ефективність каналів або налаштовуватиме їхню поведінку.

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

Така модель дає змогу аналізувати нотифікації без того, щоб перетворювати їх на центр усієї продуктової аналітики.

Нотифікаційна система відповідає за власні факти, а бізнесовий модуль - за реальну дію користувача.

Доставка показує, що спрацював транспорт. Прочитання показує, що користувач побачив нотифікацію. Реакція або бізнесова дія показує, що сталося після цього.

Ці сигнали пов’язані, але не взаємозамінні.

Зберігати варто не все, що можна порахувати, а те, що допомагає відповісти на конкретне продуктове питання або прийняти рішення.