Web push известия: как работят и как да ги използвате добре

Web push известията са единственият маркетингов канал, при който едно лошо проектно решение може да Ви заключи завинаги извън достъпа до даден клиент. Поискайте разрешение в грешния момент, посетителят натиска Block и този браузър е затворен за Вас завинаги. Без повторна подкана, без втора кампания, без имейл за връщане. Точно тази асиметрия прави механизма достоен за разбиране, преди да напишете и едно съобщение.

Какво представляват web push известията

Web push известието е съобщение, изпратено от Вашия сървър към браузъра на абонат, показано от центъра за известия на операционната система и доставено дори когато сайтът Ви е затворен. Последната част е целият смисъл: за разлика от изскачащ прозорец на страницата, web push достига човек, който в момента не гледа Вашия уебсайт.

Изграден е от три уеб платформени API, работещи заедно, а разделението между тях обяснява по-голямата част от поведението на канала: Service Worker API, Push API и Notifications API.

Как работи web push отвътре

Service worker-ът

Service worker е JavaScript worker, който действа като посредник между Вашето уеб приложение, браузъра и мрежата. Работи в собствена нишка, няма достъп до DOM и продължава да съществува, след като страницата, която го е регистрирала, се затвори. Точно тази устойчивост му позволява да получи push съобщение и да покаже известие, когато никой няма отворен Ваш таб. Service workers работят само в сигурни контексти, което означава HTTPS, като http://localhost се третира като сигурен за разработка.

Абонаментът: endpoint плюс два ключа

Щом service worker-ът е активен, страницата извиква registration.pushManager.subscribe(). Браузърът се свързва с push услугата на своя доставчик и връща PushSubscription, съдържащ:

• endpoint, уникален URL с права, на който push услугата приема съобщения
• keys.p256dh, публичен ключ Elliptic Curve Diffie-Hellman на кривата P-256
• keys.auth, тайна за автентикация

Вашият сървър съхранява и трите и третира endpoint-а като тайна, защото всеки, който го притежава, може да изпраща до този абонат. Ключовете съществуват, защото payload-ите са криптирани от край до край. RFC 8291 указва как: ECDH обмен на P-256 установява споделена тайна, HKDF извежда ключове от нея, а payload-ът се запечатва с AES-128-GCM под съдържателното кодиране aes128gcm. Push услугата препредава шифротекст, който не може да прочете.

Push услугата

Не изпращате push съобщения директно към устройство. Изпращате ги към push услуга, поддържана от доставчика на браузъра: FCM endpoint-ите на Google за Chrome, autopush на Mozilla за Firefox, push услугата на Apple за Safari. RFC 8030, „Generic Event Delivery Using HTTP Push“, дефинира протокола. Вашият сървър прави POST към endpoint-а на абонамента, а push услугата поема трудните части на мобилната доставка: една енергийно ефективна връзка към устройството, поставяне на опашка, докато е офлайн, събуждане на браузъра при пристигане на съобщение. Точно затова доставката не може да бъде гарантирана. Ако устройството е изключено достатъчно дълго, съобщенията изтичат според своя TTL и се отхвърлят.

VAPID: доказване кой изпраща

Това, че endpoint-ът е тайна, е слаба сигурност. RFC 8292 добавя Voluntary Application Server Identification, или VAPID, за да може push услугата да разпознае от кой сървър на приложението идва съобщението.

Генерирате еднократно ECDSA двойка ключове на кривата NIST P-256. Публичният ключ отива в applicationServerKey, когато браузърът се абонира, което обвързва абонамента с Вашия сървър. За всяко изпращане Вашият сървър изпраща JWT, подписан със съответстващия частен ключ чрез ES256, носещ aud клейм за origin-а на push услугата, exp клейм не по-далеч от 24 часа и по избор sub клейм с данни за контакт. Push услугата проверява подписа, така че откраднат endpoint сам по себе си вече не е достатъчен, за да спами Вашите абонати.

Пътят на доставката, от край до край

1. Страницата регистрира service worker и, след като разрешението е дадено, извиква subscribe() с Вашия публичен VAPID ключ.
2. Вашият сървър съхранява върнатия endpoint и ключове към записа на абоната.
3. За изпращане Вашият сървър криптира payload-а с p256dh и auth, подписва VAPID JWT и прави POST към endpoint-а.
4. Push услугата автентикира заявката и доставя криптираното съобщение.
5. Браузърът събужда service worker-а със събитие push, което декриптира payload-а и извиква ServiceWorkerRegistration.showNotification().
6. Кликването задейства notificationclick в service worker-а, където отваряте целевия URL.

Защо моделът на разрешенията е толкова строг

Погледнете какво дава един абонамент: фонов процес, който работи, без сайтът Ви да е отворен, плюс възможност да се рисува върху повърхността за известия на операционната система. Затова браузърите го заключват зад изрично разрешение, дадено от потребителя за всеки origin, а повечето изискват заявката да следва истински жест от потребителя.

Второ ограничение изненадва хората. Chrome и Edge изискват userVisibleOnly: true при абониране, обещание, че всяко изпращане ще произведе видимо за потребителя известие, така че тихите фонови изпращания не са поддържана употреба на API. Firefox също прилага квота към push съобщения, които не пораждат известие.

Поддръжка в браузъри и платформи

Според MDN Push API е Baseline широко достъпен от март 2023 г., което означава, че работи в текущите версии на Chrome, Edge, Firefox и Safari на настолни устройства и в Chrome и Firefox за Android. Две уговорки имат по-голямо значение от заглавието.

Първо, Notifications API не е равномерно достъпен. MDN го отбелязва като с ограничена достъпност, защото конструкторът Notification() хвърля TypeError в повечето мобилни браузъри. За всичко, което трябва да работи на телефони, използвайте постоянни известия чрез ServiceWorkerRegistration.showNotification(), което така или иначе е пътят през service worker.

Второ, опциите за известия са неравномерно имплементирани. Бутоните за действие, значките, изображенията и requireInteraction варират между браузърите и операционните системи, затова проектирайте известия, които се четат правилно и само със заглавие, текст и икона.

Изискването при iOS и iPadOS

Тази уговорка решава дали web push е приложим за аудитория с преобладаващо мобилни устройства и почти навсякъде е изложена погрешно.

Apple добави Web Push в iOS и iPadOS 16.4 и той работи само за уеб приложения, които са били добавени към началния екран. Както казва WebKit, „добавяме поддръжка на Web Push за уеб приложения на началния екран“ и „уеб приложение, което е било добавено към началния екран, може да поиска разрешение да получава push известия“. Потребителят го добавя през менюто Share и „Add to Home Screen“, а разрешението след това трябва да се поиска в отговор на пряко действие на потребителя, например натискане на бутон за абониране.

Сайт, отворен в обикновен таб на Safari на iPhone, не може да създаде push абонамент. Това е реална бариера: искате стъпка по инсталиране, преди изобщо да можете да поискате разрешение. На macOS е по-лесно, защото Safari 16.1 на macOS Ventura добави стандартизиран Web Push за обикновени уебсайтове без стъпка по инсталиране.

Минимален пример за абонамент

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

async function subscribeToPush(vapidPublicKey) {
  // Push и service workers изискват сигурен контекст (HTTPS).
  if (!("serviceWorker" in navigator) || !("PushManager" in window)) return null;

  const registration = await navigator.serviceWorker.register("/sw.js");

  // Трябва да се извика от жест на потребителя и само веднъж за потребител.
  const permission = await Notification.requestPermission();
  if (permission !== "granted") return null;

  const subscription = await registration.pushManager.subscribe({
    userVisibleOnly: true,
    applicationServerKey: vapidPublicKey, // публичен P-256 ключ, кодиран в base64url
  });

  // Запазете endpoint + ключовете на сървъра; третирайте endpoint-а като тайна.
  await fetch("/api/push/subscribe", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(subscription),
  });

  return subscription;
}

Вътре в sw.js обработвате събитието push, извиквате self.registration.showNotification(title, options) и обработвате notificationclick, за да отворите целевия URL.

UX на разрешенията: където се провалят повечето програми

Никога не питайте при зареждане на страницата

Lighthouse има специална проверка за това: „ако страницата Ви иска разрешение да изпраща известия при зареждане, тези известия може да не са релевантни за потребителите Ви или за техните нужди“. Препоръката е да предложите конкретен тип известия и да поискате разрешение едва след като потребителят се е записал за този тип. Safari 12.1 и други браузъри отидоха по-далеч, изисквайки взаимодействие със страницата, преди изобщо да може да се направи заявка.

Използвайте мека предварителна подкана

Първо покажете собствена покана в страницата. Тя назовава ползата, може да бъде отхвърлена без постоянна цена и само клик върху нея задейства истинската подкана на браузъра. Някой, който игнорира Вашата мека подкана днес, може да бъде попитан отново следващия месец. Някой, който натисне Block, не може. Две правила я правят работеща: опишете какво реално ще изпращате, вместо „получавайте новини“, и никога не инженирайте погрешен клик, защото случайно приемане води до незабавно отписване.

Питайте в контекст

Собствената препоръка на Chrome е да „оставите потребителите си да поемат инициативата и да включат известията със свое темпо“, като поставяте превключватели дискретно в съществуващите интерфейсни повърхности, и да избягвате „показване на подкани и/или наслагвания без контекст или веднага след като потребителят попадне на сайта“.

Моментите, които работят в търговията, са конкретни: контрола „уведоми ме, когато има наличност“ при изчерпан продукт, страница за потвърждение на поръчка, предлагаща обновления за доставката, превключвател за следене на цената при често разглеждан продукт. Разрешението се разменя за назована полза, вместо да се събира на едро.

Отказът е практически необратим

Когато някой блокира известията, браузърът запазва това решение за Вашия origin. По-късните извиквания на Notification.requestPermission() се разрешават до запазената стойност denied, без да показват нищо, което е причината собственият пример на MDN да проверява Notification.permission, преди изобщо да извика requestPermission(). Отмяната на блокирането означава ровене в настройките на сайта, което на практика никой не прави.

Какво правят браузърите, когато сгрешите

Последиците вече не са само нисък процент на записване.

• Chrome автоматично включва origins с много ниски проценти на приемане в по-тих интерфейс за разрешения, отделно по тип устройство, потискайки подканата за всички.
• Chrome ограничава сайтове, които съчетават висок push обем с ниска ангажираност, връщайки HTTP 429. Ескалацията върви един ден, после седем, после четиринадесет, като се нулира едва след 42 последователни дни без смущаващо поведение.
• Chrome вече автоматично отнема разрешението за известия на сайтове, с които потребителят не е взаимодействал наскоро, там където има „много ниска ангажираност на потребителите и голям обем изпращани известия“. Обосновката на Google е категорична: „По-малко от 1% от всички известия получават каквото и да е взаимодействие от потребителите.“

Можете да загубите абонати, които вече сте спечелили, просто като изпращате зле.

Web push в сравнение с имейл и SMS

Разликата в собствеността, която променя стратегията

Push абонаментът е URL с права, обвързан с един браузърен профил на едно устройство. Той не е човек. Един и същ клиент, който използва Chrome на лаптоп и Firefox на телефон, е два несвързани абонамента и не можете да знаете, че са един и същи човек, освен ако сам не се идентифицира.

Той също така не е преносим. Можете да експортирате имейл списък и да го заредите в друга платформа утре. Не можете да местите push абонаменти между доставчици, защото ключовете и VAPID обвързването са създадени срещу конкретен ключ на сървъра на приложението.

Затова третирайте web push като ускорител на притежаван канал, никога като заместител. Използвайте push момента, за да спечелите имейл адрес или телефонен номер, а не обратното. Пълното ръководство за маркетингова автоматизация покрива свързването на няколко канала в едно пътуване.

Случаи на употреба, които наистина работят

Каналът възнаграждава съобщения, които са чувствителни към времето, лично релевантни и изпълними с едно докосване.

• Изоставена количка. Push в рамките на час, подсилен с имейл по-късно. Ръководството за имейли при изоставена количка покрива последователността.
• Известия за възстановена наличност. Най-силният случай, защото потребителят изрично е поискал да бъде уведомен.
• Спад в цената на следени артикули. Същата логика, самоизбрана релевантност.
• Статус на доставка и поръчка. Високо намерение за отваряне, нисък риск от оплаквания.
• Спешни новини по абонирана тема. Новини, резултати, прозорци на наличност.

Какво се проваля е също толкова ясно: общи излъчвания „публикувахме нова статия“, недиференцирани ежедневни оферти, всичко, което изисква повече от заглавие и един ред, повторни залпове към абонати, които са игнорирали последните двадесет известия, и транзакционно съдържание, което се нуждае от траен запис.

Честота, време и сегментация

Започнете консервативно: едно до три известия на абонат седмично, като разширявате само ако процентите на отписване и кликване се задържат. Умората се появява по-бързо, отколкото при имейла, защото заглушаването струва едно докосване върху известие, което операционната система вече е извела.

Времето е едновременно предимство и опасност. Push пристига незабавно, така че съобщение, изпратено в 02:00, пристига в 02:00. Съхранявайте или извеждайте часовата зона на абоната при абониране и задържайте изпращанията в дефиниран прозорец.

Сегментацията е ограничена от това, което знаете за абонамента, а не за човека, така че работещите измерения са поведенчески: разгледани страници, следени продукти, състояние на количката, скорошност на покупката, платформа. Ръководството за сегментация на клиенти навлиза по-дълбоко.

Измерване на web push

Значение имат четири показателя и те не се измерват по един и същ начин.

• Доставка. Дали push услугата е приела заявката. 201 означава приета, не доставена. 404 или 410 означава, че абонаментът е мъртъв.
• Показване. Дали известието е било показано. Знаете го само ако service worker-ът докладва обратно, когато showNotification() се разреши.
• Процент на кликване. Кликове, разделени на показвания. Това е числото, което си струва да оптимизирате.
• Процент на отписване. Отписвания и отнети разрешения на изпращане. Следете го по-внимателно от CTR, защото е водещият индикатор за смъртта на канала.

Капани при атрибуцията

Push атрибуцията се ласкае сама. Известието пристига на устройство, което абонатът вече държи, така че често си приписва сесия, която е щяла да се случи и без него. Пускайте задържани контролни групи, вместо да предполагате допълнителен ефект. Показванията се отчитат непълно, докато всеки клик се записва, така че CTR, изчислен спрямо изпращанията, надценява представянето. И тъй като абонаментът е браузър, а не човек, push, кликнат на телефон, който завършва с покупка на настолен компютър, изглежда като две несвързани събития. Ръководството за показателите в имейл маркетинга покрива хигиената на измерването през каналите.

Съгласие, GDPR и отписване

Подканата за разрешение в браузъра е техническа бариера. Тя не е автоматично пълно правно основание за маркетинг.

Когато рекламирате на хора в ЕС или Обединеното кралство, третирайте push така, както третирате имейла. Обяснете какво ще изпращате, преди да се появи подканата, за да е съгласието информирано и конкретно. Записвайте кога и къде е създаден абонаментът и никога не свързвайте съгласието за push с несвързано действие. Ако обвързвате абонаментите с идентифицирани клиенти, тези данни попадат във Вашите задължения за лични данни, включително заявките за изтриване.

Хигиената при отписването има също толкова значение. Предложете контрола за предпочитания в сайта, за да могат хората да намалят честотата, вместо да блокират, извиквайте PushSubscription.unsubscribe() и изтривайте записа на сървъра, когато го направят, и премахвайте абонаментите при 404 или 410. Насоката на MDN е кратка и вярна: на потребителите трябва да бъде „предложен лесен начин да се откажат от получаването на още в бъдеще“.

Къде се вписва web push в стека от канали

Web push е добър трети канал и лош първи: бърз, безплатен на маржа и ненадминат за критични по време известия, но обвързан с устройство, неекспортируем и на един клик от постоянна загуба.

Това прави оркестрацията истинският проблем. Кое съобщение по кой канал да тръгне, как да потиснете имейла, когато push вече е конвертирал, и как да поддържате единен изглед на клиента през повърхности, които идентифицират хората различно. Brevo предлага web и мобилни push известия наред с имейл и SMS, а Tajo стои върху Brevo, за да координира тази логика между каналите за магазини в Shopify. За SMS страната вижте ръководството за SMS автоматизация.

Основни изводи

• Web push е три API, работещи заедно: service worker за изпълнение във фонов режим, Push API за абонамент и транспорт, Notifications API за показване. Абонаментът е endpoint плюс ключ p256dh и тайна auth, payload-ите са криптирани от край до край, а VAPID доказва изпращача.
• Push е Baseline широко достъпен от март 2023 г., но на iOS и iPadOS работи само за уеб приложения, добавени към началния екран.
• Никога не искайте разрешение при зареждане на страницата. Използвайте мека предварителна подкана, питайте в контекст и помнете, че блокирането е постоянно за този origin.
• Chrome вече налага по-тихи подкани, лимити на заявките и автоматично отнемане на разрешения, така че лошото изпращане Ви струва абонати, които вече имате.
• Абонаментът е браузър, а не човек, и не може да бъде експортиран. Изградете първо имейл списъка и използвайте push, за да го ускорите.