Notificări web push: cum funcționează și cum le folosești bine

Notificările web push sunt singurul canal de marketing în care o singură decizie proastă de design te poate bloca definitiv din calea unui client. Ceri permisiunea în momentul greșit, vizitatorul apasă Block, iar browserul acela îți este închis pentru totdeauna. Fără o a doua solicitare, fără o altă campanie, fără un e-mail de recuperare. Această asimetrie este motivul pentru care merită să înțelegi mecanismul înainte să scrii primul mesaj.

Ce sunt notificările web push

O notificare web push este un mesaj trimis de serverul tău către browserul unui abonat, afișat de centrul de notificări al sistemului de operare și livrat chiar și când site-ul tău este închis. Ultima parte este esența: spre deosebire de un popup din pagină, web push ajunge la cineva care nu se uită în acest moment la site-ul tău.

Este construit din trei API-uri ale platformei web care lucrează împreună, iar împărțirea dintre ele explică cea mai mare parte a comportamentului canalului: Service Worker API, Push API și Notifications API.

Cum funcționează web push în profunzime

Service worker-ul

Un service worker este un worker JavaScript care se comportă ca un proxy între aplicația ta web, browser și rețea. Rulează pe propriul fir de execuție, nu are acces la DOM și continuă să existe după ce pagina care l-a înregistrat se închide. Această persistență îi permite să primească un mesaj push și să afișeze o notificare atunci când nimeni nu are fila ta deschisă. Service worker-ele rulează doar în contexte securizate, adică HTTPS, iar http://localhost este tratat ca securizat pentru dezvoltare.

Abonamentul: un endpoint plus două chei

Odată ce un service worker este activ, pagina apelează registration.pushManager.subscribe(). Browserul vorbește cu serviciul push al furnizorului său și returnează un PushSubscription care conține:

• endpoint, un URL unic de capabilitate pe care serviciul push acceptă mesaje
• keys.p256dh, o cheie publică Elliptic Curve Diffie-Hellman pe curba P-256
• keys.auth, un secret de autentificare

Serverul tău stochează toate trei și tratează endpoint-ul ca pe un secret, pentru că oricine îl deține poate trimite acelui abonat. Cheile există pentru că payload-urile sunt criptate cap la cap. RFC 8291 specifică modul: un schimb ECDH pe P-256 stabilește un secret comun, HKDF derivă chei din el, iar payload-ul este sigilat cu AES-128-GCM sub codificarea de conținut aes128gcm. Serviciul push transmite un text cifrat pe care nu îl poate citi.

Serviciul push

Nu trimiți mesajele push direct către un dispozitiv. Le trimiți către un serviciu push administrat de furnizorul browserului: endpoint-urile FCM ale Google pentru Chrome, autopush de la Mozilla pentru Firefox, serviciul push Apple pentru Safari. RFC 8030, „Generic Event Delivery Using HTTP Push”, definește protocolul. Serverul tău face POST către endpoint-ul abonamentului, iar serviciul push se ocupă de părțile grele ale livrării pe mobil: o singură conexiune eficientă energetic către dispozitiv, punerea în coadă cât timp este offline, trezirea browserului la sosirea unui mesaj. Tot de aceea livrarea nu poate fi garantată. Dacă dispozitivul este oprit suficient de mult, mesajele expiră conform TTL-ului lor și sunt aruncate.

VAPID: dovada cine trimite

Faptul că endpoint-ul este secret înseamnă o securitate subțire. RFC 8292 adaugă Voluntary Application Server Identification, adică VAPID, ca un serviciu push să poată spune de la ce server de aplicație a venit un mesaj.

Generezi o singură dată o pereche de chei ECDSA pe curba NIST P-256. Cheia publică ajunge în applicationServerKey atunci când browserul se abonează, legând abonamentul de serverul tău. La fiecare push, serverul tău trimite un JWT semnat cu cheia privată corespunzătoare folosind ES256, purtând o revendicare aud pentru origin-ul serviciului push, o revendicare exp de cel mult 24 de ore și, opțional, o revendicare sub cu date de contact. Serviciul push verifică semnătura, deci un endpoint furat nu mai este singur suficient ca să îți spameze abonații.

Traseul livrării, de la un capăt la altul

1. Pagina înregistrează un service worker și, după acordarea permisiunii, apelează subscribe() cu cheia ta publică VAPID.
2. Serverul tău stochează endpoint-ul și cheile returnate în dreptul înregistrării abonatului.
3. Pentru trimitere, serverul tău criptează payload-ul cu p256dh și auth, semnează un JWT VAPID și face POST către endpoint.
4. Serviciul push autentifică cererea și livrează mesajul criptat.
5. Browserul trezește service worker-ul cu un eveniment push, care decriptează payload-ul și apelează ServiceWorkerRegistration.showNotification().
6. Un clic declanșează notificationclick în service worker, de unde deschizi URL-ul de destinație.

De ce este modelul de permisiune atât de strict

Uită-te la ce oferă un abonament: un proces de fundal care rulează fără ca site-ul tău să fie deschis, plus posibilitatea de a desena pe suprafața de notificări a sistemului de operare. De aceea browserele îl protejează cu o permisiune explicită, per origin, acordată de utilizator, iar majoritatea cer ca solicitarea să urmeze un gest real al utilizatorului.

O a doua restricție surprinde lumea. Chrome și Edge cer userVisibleOnly: true la abonare, adică o promisiune că fiecare push va produce o notificare vizibilă utilizatorului, deci push-urile silențioase de fundal nu sunt o utilizare acceptată a acestui API. Firefox aplică și el o cotă pentru mesajele push care nu generează o notificare.

Suport în browsere și platforme

Conform MDN, Push API este Baseline larg disponibil din martie 2023, ceea ce înseamnă că funcționează în versiunile curente de Chrome, Edge, Firefox și Safari pe desktop și în Chrome și Firefox pentru Android. Două avertismente contează mai mult decât titlul.

Întâi, Notifications API nu este disponibil uniform. MDN îl marchează ca având disponibilitate limitată, pentru că, pe majoritatea browserelor mobile, constructorul Notification() aruncă un TypeError. Pentru orice trebuie să funcționeze pe telefoane, folosește notificări persistente prin ServiceWorkerRegistration.showNotification(), adică exact calea prin service worker pe care ești oricum.

Al doilea, opțiunile notificărilor sunt implementate inegal. Butoanele de acțiune, insignele, imaginile și requireInteraction variază între browsere și sisteme de operare, așa că proiectează notificări care se citesc corect chiar și doar cu un titlu, un corp și o pictogramă.

Cerința pentru iOS și iPadOS

Această restricție decide dacă web push este viabil pentru un public preponderent mobil și este formulată greșit aproape peste tot.

Apple a adăugat Web Push în iOS și iPadOS 16.4, iar acesta funcționează doar pentru aplicațiile web adăugate pe ecranul principal. Cum a spus WebKit, „adăugăm suport pentru Web Push în aplicațiile web de pe ecranul principal” și „o aplicație web adăugată pe ecranul principal poate cere permisiunea de a primi notificări push”. Utilizatorul o adaugă prin meniul Share și opțiunea „Add to Home Screen”, iar permisiunea trebuie apoi cerută ca răspuns la o interacțiune directă, de exemplu atingerea unui buton de abonare.

Un site deschis într-o filă Safari obișnuită pe iPhone nu poate crea un abonament push. Aceasta este o barieră reală: ceri un pas de instalare înainte să poți măcar cere permisiunea. Pe macOS este mai simplu, pentru că Safari 16.1 pe macOS Ventura a adăugat Web Push conform standardelor pentru site-uri obișnuite, fără pas de instalare.

Un exemplu minimal de abonare

Acesta este întregul flux din partea clientului. Locul lui este într-un handler de clic, nu la încărcarea paginii.

async function subscribeToPush(vapidPublicKey) {
  // Push și service worker-ele cer un context securizat (HTTPS).
  if (!("serviceWorker" in navigator) || !("PushManager" in window)) return null;

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

  // Trebuie apelat dintr-un gest al utilizatorului și o singură dată per utilizator.
  const permission = await Notification.requestPermission();
  if (permission !== "granted") return null;

  const subscription = await registration.pushManager.subscribe({
    userVisibleOnly: true,
    applicationServerKey: vapidPublicKey, // cheie publică P-256 codificată base64url
  });

  // Persistă endpoint-ul și cheile pe server; tratează endpoint-ul ca pe un secret.
  await fetch("/api/push/subscribe", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(subscription),
  });

  return subscription;
}

În sw.js tratezi evenimentul push, apelezi self.registration.showNotification(title, options) și tratezi notificationclick ca să deschizi URL-ul de destinație.

Experiența permisiunii: unde eșuează majoritatea programelor

Nu cere niciodată la încărcarea paginii

Lighthouse are un audit dedicat pentru asta: „dacă pagina ta cere permisiunea de a trimite notificări la încărcare, este posibil ca acele notificări să nu fie relevante pentru utilizatorii tăi sau pentru nevoile lor”. Recomandarea lui este să oferi un tip specific de notificare și să ceri permisiunea abia după ce utilizatorul optează pentru acel tip. Safari 12.1 și alte browsere au mers mai departe, cerând interacțiune cu pagina înainte ca solicitarea să poată fi făcută.

Folosește o pre-solicitare blândă

Arată mai întâi propria ta invitație din pagină. Ea numește propunerea de valoare, poate fi închisă fără cost permanent și doar un clic pe ea declanșează solicitarea reală a browserului. Cineva care îți ignoră astăzi solicitarea blândă poate fi întrebat din nou luna viitoare. Cineva care apasă Block, nu. Două reguli o fac să funcționeze: descrie ce vei trimite de fapt, nu „primești noutăți”, și nu provoca niciodată un clic din greșeală, pentru că o acceptare accidentală produce o dezabonare imediată.

Cere în context

Recomandarea Chrome este să „îi lași pe utilizatori să ia inițiativa și să activeze notificările în ritmul lor”, plasând comutatoare discret în suprafețele de interfață existente, și să eviți „afișarea de solicitări sau suprapuneri fără context ori imediat după ce un utilizator ajunge pe site”.

Momentele care funcționează în comerț sunt precise: un control de tip „anunță-mă când revine în stoc” pe un produs epuizat, o pagină de confirmare a comenzii care oferă actualizări despre livrare, un comutator de urmărire a prețului pe un produs vizitat frecvent. Permisiunea este schimbată pe un beneficiu numit, nu recoltată.

Un refuz este practic definitiv

Când cineva blochează notificările, browserul păstrează acea decizie pentru origin-ul tău. Apelurile ulterioare la Notification.requestPermission() se rezolvă cu valoarea denied stocată, fără să afișeze nimic, motiv pentru care chiar exemplul din MDN verifică Notification.permission înainte să apeleze vreodată requestPermission(). Anularea unui blocaj înseamnă săpat prin setările site-ului, ceea ce practic nimeni nu face.

Ce fac browserele când greșești

Consecințele nu se mai rezumă la o rată mică de acceptare.

• Chrome înscrie automat origin-urile cu rate de acceptare foarte mici într-o interfață de permisiune mai discretă, separat pe tip de dispozitiv, suprimând solicitarea pentru toată lumea.
• Chrome limitează rata site-urilor care combină volum mare de push cu implicare mică, returnând HTTP 429. Escaladarea durează o zi, apoi șapte, apoi paisprezece și se resetează abia după 42 de zile consecutive fără deranj.
• Chrome revocă acum automat permisiunea de notificare pentru site-urile cu care utilizatorul nu a interacționat recent, acolo unde există „o implicare foarte scăzută a utilizatorului și un volum mare de notificări trimise”. Justificarea Google este brutală: „Mai puțin de 1% dintre toate notificările primesc vreo interacțiune din partea utilizatorilor.”

Poți pierde abonați pe care i-ai câștigat deja, doar trimițând prost.

Web push comparat cu e-mailul și SMS-ul

Diferența de proprietate care schimbă strategia

Un abonament push este un URL de capabilitate legat de un singur profil de browser de pe un singur dispozitiv. Nu este o persoană. Același client care folosește Chrome pe laptop și Firefox pe telefon înseamnă două abonamente fără legătură între ele, iar tu nu poți ști că este același om decât dacă se identifică singur.

Nici portabil nu este. Poți exporta o listă de e-mail și o poți încărca mâine în altă platformă. Nu poți muta abonamente push între furnizori, pentru că cheile și legătura VAPID au fost create pentru o anumită cheie de server de aplicație.

Deci tratează web push ca pe un accelerator pentru un canal deținut, niciodată ca pe un înlocuitor. Folosește momentul push ca să câștigi o adresă de e-mail sau un număr de telefon, nu invers. Ghidul complet de automatizare de marketing acoperă cablarea mai multor canale într-o singură călătorie.

Cazuri de utilizare care funcționează cu adevărat

Canalul răsplătește mesajele sensibile la timp, relevante personal și pe care le poți duce la capăt cu o singură atingere.

• Abandonarea coșului. Un push în decurs de o oră, întărit mai târziu de un e-mail. Ghidul de e-mail pentru coșul abandonat acoperă secvențierea.
• Alerte de revenire în stoc. Cazul cel mai puternic, pentru că utilizatorul a cerut explicit să fie anunțat.
• Scăderi de preț la produse urmărite. Aceeași logică, relevanță aleasă de utilizator.
• Starea livrării și a comenzii. Intenție mare de deschidere, risc mic de reclamații.
• Noutăți urgente într-un subiect abonat. Știri, rezultate, ferestre de disponibilitate.

Ce eșuează este la fel de clar: difuzările generice de tip „am publicat un articol nou”, ofertele zilnice nediferențiate, orice are nevoie de mai mult de un titlu și un rând, campaniile de reactivare trimise abonaților care au ignorat ultimele douăzeci de notificări și conținutul tranzacțional care are nevoie de o evidență durabilă.

Frecvență, momentul trimiterii și segmentare

Începe conservator: una până la trei notificări per abonat pe săptămână, crescând doar dacă ratele de dezabonare și de clic se mențin. Oboseala apare mai repede decât la e-mail, pentru că amuțirea costă o singură atingere pe o notificare pe care sistemul de operare a afișat-o deja.

Momentul trimiterii este în același timp un avantaj și un pericol. Push-ul ajunge imediat, deci un mesaj trimis la 02:00 ajunge la 02:00. Stochează sau deduce fusul orar al abonatului la momentul abonării și ține trimiterile într-o fereastră definită.

Segmentarea este limitată de ce știi despre un abonament, nu despre o persoană, așa că dimensiunile utilizabile sunt comportamentale: pagini vizitate, produse urmărite, starea coșului, cât de recent a cumpărat, platforma. Ghidul de segmentare a clienților intră mai în detaliu.

Cum măsori web push

Contează patru metrici, iar ele nu se pot măsura toate la fel.

• Livrare. Dacă serviciul push a acceptat cererea. Un 201 înseamnă acceptat, nu livrat. Un 404 sau 410 înseamnă că abonamentul este mort.
• Afișare. Dacă notificarea a fost arătată. Afli asta doar dacă service worker-ul raportează înapoi când se rezolvă showNotification().
• Rata de clic. Clicuri împărțite la afișări. Acesta este numărul care merită optimizat.
• Rata de dezabonare. Dezabonări și revocări de permisiune per trimitere. Urmărește-o mai atent decât rata de clic, pentru că este indicatorul avansat al morții canalului.

Capcane de atribuire

Atribuirea pentru push se măgulește singură. Notificarea ajunge pe un dispozitiv pe care abonatul îl ține deja în mână, deci își asumă adesea meritul pentru o sesiune care oricum urma să se întâmple. Rulează grupuri de control în loc să presupui incrementalitate. Afișările sunt subnumărate în timp ce fiecare clic este înregistrat, deci o rată de clic calculată raportat la trimiteri exagerează performanța. Iar pentru că un abonament este un browser, nu o persoană, un push apăsat pe telefon care se termină cu o achiziție pe desktop arată ca două evenimente fără legătură. Ghidul de metrici pentru e-mail marketing acoperă igiena măsurării pe toate canalele.

Consimțământ, GDPR și dezabonare

Solicitarea de permisiune din browser este o barieră tehnică. Nu este automat un temei juridic complet pentru marketing.

Acolo unde faci marketing către persoane din UE sau din Regatul Unit, tratează push-ul așa cum tratezi e-mailul. Explică ce vei trimite înainte să apară solicitarea, ca acordul să fie informat și specific. Înregistrează când și unde a fost creat abonamentul și nu împacheta niciodată consimțământul pentru push într-o acțiune fără legătură. Dacă legi abonamentele de clienți identificați, acele date intră în obligațiile tale privind datele cu caracter personal, inclusiv cererile de ștergere.

Igiena dezabonării contează la fel de mult. Oferă un control de preferințe în site, ca oamenii să poată reduce frecvența în loc să blocheze, apelează PushSubscription.unsubscribe() și șterge înregistrarea pe server când o fac, iar la un 404 sau 410 elimină abonamentele. Îndrumarea MDN este scurtă și corectă: utilizatorilor ar trebui să li se ofere „o modalitate simplă de a renunța la a mai primi altele în viitor”.

Unde se potrivește web push într-o stivă de canale

Web push este un al treilea canal bun și un prim canal prost: rapid, gratuit la margine și fără egal pentru alerte critice ca timp, dar legat de dispozitiv, neexportabil și la un clic distanță de pierdere definitivă.

Asta face din orchestrare adevărata problemă. Ce mesaj merge pe ce canal, cum suprimi e-mailul când push-ul a convertit deja și cum păstrezi o singură imagine a clientului peste suprafețe care identifică oamenii diferit. Brevo oferă push web și mobil alături de e-mail și SMS, iar Tajo stă peste Brevo pentru a coordona această logică între canale pentru magazinele Shopify. Pentru partea de SMS, vezi ghidul de automatizare SMS.

Concluzii principale

• Web push înseamnă trei API-uri care cooperează: un service worker pentru execuție în fundal, Push API pentru abonare și transport, Notifications API pentru afișare. Un abonament este un endpoint plus o cheie p256dh și un secret auth, payload-urile sunt criptate cap la cap, iar VAPID dovedește cine trimite.
• Push este Baseline larg disponibil din martie 2023, dar pe iOS și iPadOS funcționează doar pentru aplicațiile web adăugate pe ecranul principal.
• Nu cere niciodată permisiunea la încărcarea paginii. Folosește o pre-solicitare blândă, cere în context și ține minte că un blocaj este permanent pentru acel origin.
• Chrome impune acum solicitări mai discrete, limite de rată și revocare automată a permisiunii, deci trimiterile proaste te costă abonați pe care îi ai deja.
• Un abonament este un browser, nu o persoană, și nu poate fi exportat. Construiește întâi lista de e-mail și folosește push-ul ca să o accelerezi.