Webové push notifikace: jak fungují a jak je používat dobře

Webové push notifikace jsou jediný marketingový kanál, kde Vás jedno špatné návrhové rozhodnutí může natrvalo odříznout od zákazníka. Požádáte o povolení ve špatnou chvíli, návštěvník klikne na Blokovat a ten prohlížeč je pro Vás navždy uzavřený. Žádná opakovaná výzva, žádná druhá kampaň, žádný e-mail na získání zpět. Právě tato nesouměrnost je důvod, proč se vyplatí porozumět mechanismu dřív, než napíšete jedinou zprávu.

Co jsou webové push notifikace

Webová push notifikace je zpráva odeslaná z Vašeho serveru do prohlížeče odběratele, zobrazená v notifikačním centru operačního systému a doručená i tehdy, když je Váš web zavřený. Právě poslední část je celý smysl: na rozdíl od vyskakovacího okna na stránce zastihne webové push i někoho, kdo se zrovna na Váš web nedívá.

Je postavené ze tří webových platformních API, která spolupracují, a rozdělení mezi nimi vysvětluje většinu chování kanálu: Service Worker API, Push API a Notifications API.

Jak webové push funguje pod kapotou

Service worker

Service worker je JavaScriptový worker, který funguje jako proxy mezi Vaší webovou aplikací, prohlížečem a sítí. Běží ve vlastním vlákně, nemá přístup k DOM a existuje dál i poté, co se stránka, která ho zaregistrovala, zavře. Právě tato trvalost mu umožní přijmout push zprávu a zobrazit notifikaci, když nikdo nemá otevřenou Vaši záložku. Service workery běží jen v zabezpečených kontextech, což znamená HTTPS, přičemž http://localhost je pro vývoj považován za bezpečný.

Odběr: endpoint plus dva klíče

Jakmile je service worker aktivní, stránka zavolá registration.pushManager.subscribe(). Prohlížeč komunikuje s push službou svého výrobce a vrátí PushSubscription, které obsahuje:

• endpoint, unikátní capability URL, na které push služba přijímá zprávy
• keys.p256dh, veřejný klíč Elliptic Curve Diffie-Hellman na křivce P-256
• keys.auth, autentizační tajemství

Váš server všechny tři uloží a s endpointem zachází jako s tajemstvím, protože kdokoli, kdo ho má, může danému odběrateli posílat zprávy. Klíče existují proto, že payloady jsou šifrované od konce ke konci. RFC 8291 popisuje jak: výměna ECDH na P-256 vytvoří sdílené tajemství, HKDF z něj odvodí klíče a payload se zapečetí pomocí AES-128-GCM pod kódováním obsahu aes128gcm. Push služba přeposílá šifrovaný text, který nemůže přečíst.

Push služba

Push zprávy neposíláte přímo do zařízení. Posíláte je do push služby provozované výrobcem prohlížeče: endpointy Google FCM pro Chrome, Mozilla autopush pro Firefox, push služba Apple pro Safari. Protokol definuje RFC 8030, „Generic Event Delivery Using HTTP Push”. Váš server pošle POST na endpoint odběru a push služba vyřeší náročné části mobilního doručování: jedno energeticky úsporné spojení do zařízení, frontu při offline stavu a probuzení prohlížeče, když zpráva dorazí. To je také důvod, proč nelze doručení zaručit. Pokud je zařízení dost dlouho vypnuté, zprávy vyprší podle svého TTL a zahodí se.

VAPID: doložení, kdo odesílá

To, že je endpoint tajemstvím, je slabé zabezpečení. RFC 8292 přidává Voluntary Application Server Identification, tedy VAPID, aby push služba poznala, ze kterého aplikačního serveru zpráva přišla.

Jednou vygenerujete pár klíčů ECDSA na křivce NIST P-256. Veřejný klíč jde do applicationServerKey, když se prohlížeč přihlašuje k odběru, čímž odběr sváže s Vaším serverem. U každého pushe Váš server posílá JWT podepsaný odpovídajícím privátním klíčem pomocí ES256, nesoucí claim aud pro origin push služby, claim exp nejvýše 24 hodin dopředu a volitelně claim sub s kontaktními údaji. Push služba podpis ověří, takže ukradený endpoint sám o sobě už na spamování Vašich odběratelů nestačí.

Cesta doručení od začátku do konce

1. Stránka zaregistruje service worker a po udělení povolení zavolá subscribe() s Vaším veřejným klíčem VAPID.
2. Váš server uloží vrácený endpoint a klíče k záznamu odběratele.
3. Při odeslání Váš server zašifruje payload pomocí p256dh a auth, podepíše JWT pro VAPID a pošle POST na endpoint.
4. Push služba požadavek ověří a doručí zašifrovanou zprávu.
5. Prohlížeč probudí service worker událostí push, ten payload dešifruje a zavolá ServiceWorkerRegistration.showNotification().
6. Kliknutí spustí notificationclick v service workeru, kde otevřete cílovou URL.

Proč je model povolení tak přísný

Podívejte se, co odběr uděluje: proces na pozadí, který běží, aniž by byl Váš web otevřený, plus možnost kreslit na notifikační plochu operačního systému. Prohlížeče to proto podmiňují výslovným povolením uděleným uživatelem pro každý origin zvlášť a většina vyžaduje, aby žádost následovala po skutečném gestu uživatele.

Druhé omezení lidi překvapuje. Chrome a Edge vyžadují při subscribe hodnotu userVisibleOnly: true, tedy příslib, že každý push vyprodukuje uživateli viditelnou notifikaci, takže tiché pushe na pozadí nejsou podporovaným využitím API. Firefox navíc uplatňuje kvótu na push zprávy, které notifikaci negenerují.

Podpora v prohlížečích a na platformách

Podle MDN je Push API v rámci Baseline široce dostupné od března 2023, což znamená, že funguje napříč aktuálními verzemi Chrome, Edge, Firefoxu a Safari na desktopu a v Chrome a Firefoxu pro Android. Dvě výhrady jsou důležitější než ten titulek.

Zaprvé, Notifications API není dostupné rovnoměrně. MDN ho označuje jako omezeně dostupné, protože konstruktor Notification() vyhazuje na většině mobilních prohlížečů TypeError. Pro cokoli, co musí fungovat na telefonech, používejte místo toho trvalé notifikace přes ServiceWorkerRegistration.showNotification(), což je stejně ta cesta přes service worker, na které už jste.

Zadruhé, možnosti notifikací jsou implementované nerovnoměrně. Akční tlačítka, odznaky, obrázky a requireInteraction se liší napříč prohlížeči a operačními systémy, takže navrhujte notifikace tak, aby se daly správně přečíst i jen s titulkem, textem a ikonou.

Požadavek iOS a iPadOS

Tato výhrada rozhoduje, jestli je webové push použitelné pro publikum silně na mobilech, a téměř všude je uváděna špatně.

Apple přidal Web Push v iOS a iPadOS 16.4 a funguje jen u webových aplikací, které byly přidány na plochu. Jak to napsal WebKit, „we are adding support for Web Push to Home Screen web apps” a „a web app that has been added to the Home Screen can request permission to receive push notifications”. Uživatel ji přidá přes nabídku Sdílet a „Přidat na plochu” a o povolení je pak nutné požádat v reakci na přímou akci uživatele, například po klepnutí na tlačítko odběru.

Web otevřený v běžné záložce Safari na iPhonu push odběr vytvořit nemůže. To je reálná překážka: žádáte o instalační krok dřív, než se vůbec můžete zeptat na povolení. Na macOS je to snazší, protože Safari 16.1 na macOS Ventura přidalo standardizované Web Push pro běžné weby bez instalačního kroku.

Minimální příklad odběru

Toto je celý tok na straně klienta. Patří do obsluhy kliknutí, ne do načtení stránky.

async function subscribeToPush(vapidPublicKey) {
  // Push a service workery vyžadují zabezpečený kontext (HTTPS).
  if (!("serviceWorker" in navigator) || !("PushManager" in window)) return null;

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

  // Musí být voláno z gesta uživatele a jen jednou na uživatele.
  const permission = await Notification.requestPermission();
  if (permission !== "granted") return null;

  const subscription = await registration.pushManager.subscribe({
    userVisibleOnly: true,
    applicationServerKey: vapidPublicKey, // veřejný klíč P-256 v kódování base64url
  });

  // Endpoint a klíče uložte na serveru; endpoint berte jako tajemství.
  await fetch("/api/push/subscribe", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(subscription),
  });

  return subscription;
}

Uvnitř sw.js obsloužíte událost push, zavoláte self.registration.showNotification(title, options) a obsloužíte notificationclick, abyste otevřeli cílovou URL.

UX žádosti o povolení: kde většina programů selhává

Nikdy se neptejte při načtení stránky

Lighthouse má na to vlastní audit: „if your page asks for permission to send notifications on page load, those notifications may not be relevant to your users or their needs”. Jeho doporučení zní nabídnout konkrétní typ notifikace a o povolení požádat až poté, co se uživatel k tomuto typu přihlásí. Safari 12.1 a další prohlížeče šly dál a vyžadují interakci se stránkou dřív, než lze žádost vůbec podat.

Použijte měkkou předběžnou výzvu

Nejprve zobrazte vlastní pozvánku přímo na stránce. Pojmenuje přínos, dá se zavřít bez trvalé ztráty a skutečnou výzvu prohlížeče spustí až kliknutí na ni. Toho, kdo Vaši měkkou výzvu dnes ignoruje, se můžete zeptat znovu za měsíc. Toho, kdo klikne na Blokovat, ne. Fungovat to bude, když dodržíte dvě pravidla: popište, co skutečně budete posílat, místo „získávejte novinky”, a nikdy nekonstruujte omylem provedené kliknutí, protože nechtěné přijetí vede k okamžitému odhlášení.

Ptejte se v kontextu

Vlastní doporučení Chromu je „let your users take the initiative and turn on notifications at their own pace”, tedy umístit přepínače nenápadně do existujících částí rozhraní, a vyhnout se „showing prompts and/or overlays without context or immediately after a user lands on the site”.

Momenty, které v e-commerce fungují, jsou konkrétní: ovládací prvek „dejte mi vědět, až bude zpět skladem” u vyprodaného produktu, stránka potvrzení objednávky nabízející informace o doručení, přepínač hlídání ceny u často prohlíženého produktu. Povolení se směňuje za pojmenovaný přínos, místo aby se sklízelo.

Odmítnutí je fakticky trvalé

Když někdo notifikace zablokuje, prohlížeč toto rozhodnutí pro Váš origin uloží. Pozdější volání Notification.requestPermission() se vyhodnotí na uloženou hodnotu denied, aniž by cokoli zobrazila, a proto vlastní příklad na MDN kontroluje Notification.permission dřív, než vůbec zavolá requestPermission(). Zrušit blokování znamená hrabat se v nastavení webu, což prakticky nikdo nedělá.

Co prohlížeče udělají, když to zkazíte

Následkem už není jen nízká míra opt-inu.

• Chrome automaticky zařazuje originy s velmi nízkou mírou přijetí do tiššího rozhraní pro povolení, odděleně podle typu zařízení, čímž výzvu potlačí pro všechny.
• Chrome uplatňuje limity vůči webům, které kombinují vysoký objem pushů s nízkým zapojením, a vrací HTTP 429. Eskalace běží jeden den, pak sedm, pak čtrnáct a resetuje se až po 42 po sobě jdoucích dnech bez rušivého chování.
• Chrome nyní automaticky odebírá povolení notifikací webům, se kterými uživatel v poslední době neinteragoval, tam, kde je „very low user engagement and a high volume of notifications being sent”. Zdůvodnění od Google je nemilosrdné: „Less than 1% of all notifications receive any interaction from users.”

Odběratele, které jste už získali, můžete ztratit prostě tím, že posíláte špatně.

Webové push ve srovnání s e-mailem a SMS

Rozdíl ve vlastnictví, který mění strategii

Push odběr je capability URL svázaná s jedním profilem prohlížeče na jednom zařízení. Není to osoba. Tentýž zákazník používající Chrome na notebooku a Firefox na telefonu jsou dva nesouvisející odběry a nemůžete vědět, že jde o stejného člověka, dokud se sám neidentifikuje.

Není to ani přenositelné. E-mailový seznam můžete exportovat a zítra nahrát do jiné platformy. Push odběry mezi dodavateli přesunout nelze, protože klíče i vazba VAPID vznikly vůči konkrétnímu klíči aplikačního serveru.

Berte tedy webové push jako urychlovač vlastněného kanálu, nikdy jako náhradu. Použijte push moment k získání e-mailové adresy nebo telefonního čísla, ne naopak. Kompletní průvodce marketingovou automatizací popisuje, jak zapojit několik kanálů do jedné cesty.

Případy použití, které skutečně fungují

Kanál odměňuje zprávy, které jsou časově citlivé, osobně relevantní a proveditelné jedním klepnutím.

• Opuštěný košík. Push do hodiny, později podpořený e-mailem. Průvodce e-maily o opuštěném košíku popisuje řazení.
• Upozornění na naskladnění. Nejsilnější případ, protože uživatel výslovně požádal, aby mu to bylo řečeno.
• Snížení ceny u hlídaných položek. Stejná logika, relevance zvolená samotným uživatelem.
• Stav doručení a objednávky. Vysoký zájem otevřít, nízké riziko stížnosti.
• Aktuality v odebíraném tématu. Zprávy, výsledky, časová okna dostupnosti.

Co selhává, je stejně jasné: obecné rozesílky typu „vydali jsme nový článek”, nerozlišené denní slevy, cokoli, co potřebuje víc než titulek a jeden řádek, reaktivační vlny na odběratele, kteří ignorovali posledních dvacet notifikací, a transakční obsah, který potřebuje trvalý záznam.

Frekvence, načasování a segmentace

Začněte konzervativně: jedna až tři notifikace na odběratele týdně, s rozšířením jen tehdy, pokud míra odhlášení a prokliků vydrží. Únava se projeví rychleji než u e-mailu, protože ztlumení stojí jedno klepnutí na notifikaci, kterou už operační systém zobrazil.

Načasování je zároveň výhoda i riziko. Push dorazí okamžitě, takže zpráva odeslaná ve 02:00 dorazí ve 02:00. Uložte nebo odvoďte časové pásmo odběratele při přihlášení k odběru a odesílání držte v definovaném okně.

Segmentace je omezená tím, co víte o odběru, ne o osobě, takže použitelné dimenze jsou behaviorální: zobrazené stránky, hlídané produkty, stav košíku, doba od nákupu, platforma. Průvodce segmentací zákazníků jde do větší hloubky.

Měření webového push

Záleží na čtyřech metrikách a ne všechny se měří stejně.

• Doručení. Jestli push služba požadavek přijala. 201 znamená přijato, ne doručeno. 404 nebo 410 znamená, že odběr je mrtvý.
• Zobrazení. Jestli byla notifikace zobrazena. Víte to jen tehdy, pokud service worker hlásí zpět, když se showNotification() dokončí.
• Míra prokliku. Kliknutí dělená zobrazeními. Tohle je číslo, které se vyplatí optimalizovat.
• Míra odhlášení. Odhlášení a odebrání povolení na jedno odeslání. Sledujte ji pozorněji než míru prokliku, protože je to předstihový ukazatel smrti kanálu.

Úskalí atribuce

Atribuce push si lichotí. Notifikace dorazí na zařízení, které odběratel už drží v ruce, takže si často připíše zásluhu za relaci, která by proběhla tak jako tak. Používejte kontrolní skupiny místo předpokladu inkrementality. Zobrazení se podpočítávají, zatímco každé kliknutí je zaznamenáno, takže míra prokliku počítaná z odeslání výkon nadhodnocuje. A protože odběr je prohlížeč, ne osoba, vypadá push kliknutý na telefonu a končící nákupem na desktopu jako dvě nesouvisející události. Průvodce metrikami e-mailového marketingu se věnuje hygieně měření napříč kanály.

Souhlas, GDPR a odhlášení

Výzva k povolení v prohlížeči je technická brána. Není automaticky úplným právním základem pro marketing.

Pokud cílíte marketing na lidi v EU nebo Velké Británii, zacházejte s push stejně jako s e-mailem. Vysvětlete, co budete posílat, ještě než se výzva objeví, aby byl souhlas informovaný a konkrétní. Zaznamenejte, kdy a kde odběr vznikl, a nikdy nespojujte souhlas s push s nesouvisející akcí. Pokud odběry vážete na identifikované zákazníky, spadají tato data do Vašich povinností k osobním údajům, včetně žádostí o výmaz.

Stejně důležitá je hygiena odhlášení. Nabídněte ovládání předvoleb přímo na webu, aby lidé mohli snížit frekvenci místo blokování, při odhlášení zavolejte PushSubscription.unsubscribe() a smažte záznam na serveru a odběry čistěte při odpovědi 404 nebo 410. Doporučení MDN je krátké a správné: uživatelům by měla být „offered an easy way to opt out of getting more in the future”.

Kam webové push patří ve skladbě kanálů

Webové push je dobrý třetí kanál a špatný první: rychlý, na okraji zdarma a bezkonkurenční pro časově kritická upozornění, ale vázaný na zařízení, neexportovatelný a jedno kliknutí od trvalé ztráty.

Skutečným problémem se tak stává orchestrace. Která zpráva půjde kterým kanálem, jak potlačíte e-mail, když už push konvertoval, a jak udržíte jeden pohled na zákazníka napříč plochami, které lidi identifikují různě. Brevo nabízí webové i mobilní push vedle e-mailu a SMS a Tajo sedí nad Brevo a koordinuje tuto logiku napříč kanály pro obchody na Shopify. Ke straně SMS se podívejte do průvodce automatizací SMS.

Klíčové poznatky

• Webové push jsou tři spolupracující API: service worker pro běh na pozadí, Push API pro odběr a přenos, Notifications API pro zobrazení. Odběr je endpoint plus klíč p256dh a tajemství auth, payloady jsou šifrované od konce ke konci a VAPID dokládá odesílatele.
• Push je v rámci Baseline široce dostupné od března 2023, ale na iOS a iPadOS funguje jen u webových aplikací přidaných na plochu.
• Nikdy nežádejte o povolení při načtení stránky. Použijte měkkou předběžnou výzvu, ptejte se v kontextu a pamatujte, že blokování je pro daný origin trvalé.
• Chrome nyní vynucuje tišší výzvy, limity a automatické odebírání povolení, takže špatné odesílání Vás stojí odběratele, které už máte.
• Odběr je prohlížeč, ne osoba, a nedá se exportovat. Nejdřív budujte e-mailový seznam a push používejte k jeho zrychlení.