Ειδοποιήσεις web push: πώς λειτουργούν και πώς να τις αξιοποιήσετε σωστά

Οι ειδοποιήσεις web push είναι το μοναδικό κανάλι μάρκετινγκ όπου μία κακή σχεδιαστική απόφαση μπορεί να σας κλειδώσει μόνιμα έξω από έναν πελάτη. Ζητήστε άδεια σε λάθος στιγμή, ο επισκέπτης πατάει «Αποκλεισμός», και αυτός ο browser κλείνει για εσάς για πάντα. Καμία νέα προτροπή, καμία δεύτερη καμπάνια, κανένα email ανάκτησης. Αυτή η ασυμμετρία είναι ο λόγος που αξίζει να καταλάβετε τον μηχανισμό πριν γράψετε έστω ένα μήνυμα.

Τι είναι οι ειδοποιήσεις web push

Μια ειδοποίηση web push είναι ένα μήνυμα που στέλνεται από τον διακομιστή σας στον browser ενός συνδρομητή, εμφανίζεται από το κέντρο ειδοποιήσεων του λειτουργικού συστήματος και παραδίδεται ακόμη και όταν ο ιστότοπός σας είναι κλειστός. Αυτό το τελευταίο είναι όλο το νόημα: σε αντίθεση με ένα αναδυόμενο παράθυρο μέσα στη σελίδα, το web push φτάνει σε κάποιον που αυτή τη στιγμή δεν κοιτάζει τον ιστότοπό σας.

Χτίζεται από τρία API της πλατφόρμας του web που συνεργάζονται, και ο διαχωρισμός τους εξηγεί την περισσότερη συμπεριφορά του καναλιού: το Service Worker API, το Push API και το Notifications API.

Πώς λειτουργεί το web push στα ενδότερα

Ο service worker

Ένας service worker είναι ένας worker JavaScript που λειτουργεί ως διαμεσολαβητής ανάμεσα στη web εφαρμογή σας, τον browser και το δίκτυο. Τρέχει σε δικό του νήμα, δεν έχει πρόσβαση στο DOM και συνεχίζει να υπάρχει αφού κλείσει η σελίδα που τον καταχώρησε. Αυτή η επιμονή είναι που του επιτρέπει να λαμβάνει ένα μήνυμα push και να εμφανίζει μια ειδοποίηση όταν κανείς δεν έχει ανοιχτή την καρτέλα σας. Οι service workers τρέχουν μόνο σε ασφαλή περιβάλλοντα, δηλαδή σε HTTPS, με το http://localhost να αντιμετωπίζεται ως ασφαλές για ανάπτυξη.

Η συνδρομή: ένα endpoint και δύο κλειδιά

Μόλις ο service worker γίνει ενεργός, η σελίδα καλεί το registration.pushManager.subscribe(). Ο browser επικοινωνεί με την υπηρεσία push του κατασκευαστή του και επιστρέφει ένα PushSubscription που περιέχει:

• endpoint, ένα μοναδικό URL δυνατότητας στο οποίο η υπηρεσία push δέχεται μηνύματα
• keys.p256dh, ένα δημόσιο κλειδί Elliptic Curve Diffie-Hellman στην καμπύλη P-256
• keys.auth, ένα μυστικό ελέγχου ταυτότητας

Ο διακομιστής σας αποθηκεύει και τα τρία και αντιμετωπίζει το endpoint ως μυστικό, επειδή όποιος το κατέχει μπορεί να στείλει σε αυτόν τον συνδρομητή. Τα κλειδιά υπάρχουν επειδή τα payloads κρυπτογραφούνται από άκρο σε άκρο. Το RFC 8291 ορίζει πώς: μια ανταλλαγή ECDH στην P-256 εγκαθιδρύει ένα κοινό μυστικό, το HKDF παράγει κλειδιά από αυτό, και το payload σφραγίζεται με AES-128-GCM υπό την κωδικοποίηση περιεχομένου aes128gcm. Η υπηρεσία push αναμεταδίδει κρυπτογραφημένο κείμενο που δεν μπορεί να διαβάσει.

Η υπηρεσία push

Δεν στέλνετε μηνύματα push απευθείας σε μια συσκευή. Τα στέλνετε σε μια υπηρεσία push που λειτουργεί ο κατασκευαστής του browser: τα endpoints FCM της Google για το Chrome, το autopush της Mozilla για τον Firefox, την υπηρεσία push της Apple για το Safari. Το RFC 8030, «Generic Event Delivery Using HTTP Push», ορίζει το πρωτόκολλο. Ο διακομιστής σας κάνει POST στο endpoint της συνδρομής, και η υπηρεσία push αναλαμβάνει τα δύσκολα μέρη της παράδοσης σε κινητά: μία σύνδεση με χαμηλή κατανάλωση μπαταρίας προς τη συσκευή, ουρά αναμονής όσο είναι εκτός σύνδεσης, αφύπνιση του browser όταν φτάνει μήνυμα. Γι’ αυτό και η παράδοση δεν μπορεί να είναι εγγυημένη. Αν η συσκευή μείνει κλειστή αρκετά, τα μηνύματα λήγουν σύμφωνα με το TTL τους και απορρίπτονται.

VAPID: αποδεικνύοντας ποιος στέλνει

Το ότι το endpoint είναι μυστικό αποτελεί ισχνή ασφάλεια. Το RFC 8292 προσθέτει το Voluntary Application Server Identification, δηλαδή το VAPID, ώστε μια υπηρεσία push να μπορεί να διακρίνει από ποιον διακομιστή εφαρμογής ήρθε ένα μήνυμα.

Δημιουργείτε μία φορά ένα ζεύγος κλειδιών ECDSA στην καμπύλη NIST P-256. Το δημόσιο κλειδί μπαίνει στο applicationServerKey όταν ο browser εγγράφεται, δένοντας τη συνδρομή με τον διακομιστή σας. Για κάθε μήνυμα push, ο διακομιστής σας στέλνει ένα JWT υπογεγραμμένο με το αντίστοιχο ιδιωτικό κλειδί με ES256, το οποίο φέρει μια αξίωση aud για την προέλευση της υπηρεσίας push, μια αξίωση exp το πολύ 24 ώρες μπροστά, και προαιρετικά μια αξίωση sub με στοιχεία επικοινωνίας. Η υπηρεσία push επαληθεύει την υπογραφή, οπότε ένα κλεμμένο endpoint από μόνο του δεν αρκεί πια για να γεμίσει με ανεπιθύμητα μηνύματα τους συνδρομητές σας.

Η διαδρομή παράδοσης, από άκρο σε άκρο

1. Η σελίδα καταχωρεί έναν service worker και, αφού δοθεί η άδεια, καλεί το subscribe() με το δημόσιο κλειδί VAPID σας.
2. Ο διακομιστής σας αποθηκεύει το endpoint και τα κλειδιά που επιστράφηκαν στην εγγραφή του συνδρομητή.
3. Για την αποστολή, ο διακομιστής σας κρυπτογραφεί το payload με τα p256dh και auth, υπογράφει ένα JWT VAPID και κάνει POST στο endpoint.
4. Η υπηρεσία push αυθεντικοποιεί το αίτημα και παραδίδει το κρυπτογραφημένο μήνυμα.
5. Ο browser ξυπνά τον service worker με ένα συμβάν push, το οποίο αποκρυπτογραφεί το payload και καλεί το ServiceWorkerRegistration.showNotification().
6. Ένα κλικ πυροδοτεί το notificationclick μέσα στον service worker, όπου ανοίγετε το URL προορισμού.

Γιατί το μοντέλο αδειοδότησης είναι τόσο αυστηρό

Δείτε τι παραχωρεί μια συνδρομή: μια διεργασία παρασκηνίου που τρέχει χωρίς να είναι ανοιχτός ο ιστότοπός σας, συν τη δυνατότητα να σχεδιάζει πάνω στην επιφάνεια ειδοποιήσεων του λειτουργικού συστήματος. Οι browsers λοιπόν το προστατεύουν πίσω από μια ρητή άδεια, ανά προέλευση, δοσμένη από τον χρήστη, και οι περισσότεροι απαιτούν το αίτημα να ακολουθεί γνήσια ενέργεια του χρήστη.

Ένας δεύτερος περιορισμός εκπλήσσει τους ανθρώπους. Το Chrome και ο Edge απαιτούν userVisibleOnly: true κατά την εγγραφή, δηλαδή μια υπόσχεση ότι κάθε μήνυμα push θα παράγει ειδοποίηση ορατή στον χρήστη, οπότε τα σιωπηλά μηνύματα παρασκηνίου δεν αποτελούν υποστηριζόμενη χρήση του API. Ο Firefox εφαρμόζει επίσης ποσόστωση σε μηνύματα push που δεν παράγουν ειδοποίηση.

Υποστήριξη από browsers και πλατφόρμες

Σύμφωνα με το MDN, το Push API είναι Baseline ευρέως διαθέσιμο από τον Μάρτιο του 2023, δηλαδή λειτουργεί στις τρέχουσες εκδόσεις των Chrome, Edge, Firefox και Safari σε υπολογιστές, καθώς και στα Chrome και Firefox για Android. Δύο επιφυλάξεις μετρούν περισσότερο από τον τίτλο.

Πρώτον, το Notifications API δεν είναι ομοιόμορφα διαθέσιμο. Το MDN το επισημαίνει ως περιορισμένης διαθεσιμότητας επειδή ο κατασκευαστής Notification() πετάει TypeError στους περισσότερους browsers κινητών. Για οτιδήποτε πρέπει να δουλεύει σε τηλέφωνα, χρησιμοποιήστε μόνιμες ειδοποιήσεις μέσω του ServiceWorkerRegistration.showNotification(), που είναι ούτως ή άλλως η διαδρομή του service worker στην οποία βρίσκεστε.

Δεύτερον, οι επιλογές ειδοποιήσεων υλοποιούνται άνισα. Τα κουμπιά ενεργειών, τα σήματα, οι εικόνες και το requireInteraction διαφέρουν μεταξύ browsers και λειτουργικών συστημάτων, οπότε σχεδιάστε ειδοποιήσεις που διαβάζονται σωστά ακόμη και μόνο με τίτλο, σώμα και εικονίδιο.

Η απαίτηση για iOS και iPadOS

Αυτή η επιφύλαξη κρίνει αν το web push είναι βιώσιμο για κοινό με βαρύ κινητό, και διατυπώνεται λανθασμένα σχεδόν παντού.

Η Apple πρόσθεσε το Web Push στα iOS και iPadOS 16.4, και λειτουργεί μόνο για web apps που έχουν προστεθεί στην αρχική οθόνη. Όπως το έθεσε η WebKit, «we are adding support for Web Push to Home Screen web apps» και «a web app that has been added to the Home Screen can request permission to receive push notifications». Ο χρήστης την προσθέτει από το μενού κοινής χρήσης και την επιλογή «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 προορισμού.

Εμπειρία αδειοδότησης: εκεί που αποτυγχάνουν τα περισσότερα προγράμματα

Μη ρωτάτε ποτέ κατά τη φόρτωση της σελίδας

Το Lighthouse έχει ειδικό έλεγχο γι’ αυτό: «if your page asks for permission to send notifications on page load, those notifications may not be relevant to your users or their needs». Η σύστασή του είναι να προσφέρετε έναν συγκεκριμένο τύπο ειδοποίησης και να ζητάτε άδεια μόνο αφού ο χρήστης επιλέξει αυτόν τον τύπο. Το Safari 12.1 και άλλοι browsers πήγαν παραπέρα, απαιτώντας αλληλεπίδραση με τη σελίδα πριν καν γίνει δυνατό ένα αίτημα.

Χρησιμοποιήστε ήπια προ-προτροπή

Δείξτε πρώτα τη δική σας πρόσκληση μέσα στη σελίδα. Ονομάζει την πρόταση αξίας, μπορεί να απορριφθεί χωρίς μόνιμο κόστος, και μόνο ένα κλικ πάνω της πυροδοτεί την πραγματική προτροπή του browser. Κάποιος που αγνοεί σήμερα την ήπια προτροπή σας μπορεί να ερωτηθεί ξανά τον επόμενο μήνα. Κάποιος που πατάει «Αποκλεισμός» δεν μπορεί. Δύο κανόνες το κάνουν να δουλέψει: περιγράψτε τι θα στέλνετε πραγματικά αντί για «λάβετε ενημερώσεις», και μη στήνετε ποτέ ένα κατά λάθος κλικ, γιατί μια τυχαία αποδοχή παράγει άμεση διαγραφή.

Ρωτήστε μέσα στο κατάλληλο πλαίσιο

Η σύσταση του ίδιου του Chrome είναι να «let your users take the initiative and turn on notifications at their own pace», τοποθετώντας διακόπτες διακριτικά μέσα σε υπάρχουσες επιφάνειες της διεπαφής, και να αποφεύγετε το «showing prompts and/or overlays without context or immediately after a user lands on the site».

Οι στιγμές που δουλεύουν στο εμπόριο είναι συγκεκριμένες: ένα χειριστήριο «ειδοποιήστε με όταν επιστρέψει σε απόθεμα» σε εξαντλημένο προϊόν, μια σελίδα επιβεβαίωσης παραγγελίας που προσφέρει ενημερώσεις παράδοσης, ένας διακόπτης παρακολούθησης τιμής σε προϊόν που το βλέπουν συχνά. Η άδεια ανταλλάσσεται με ένα κατονομασμένο όφελος αντί να συλλέγεται αδιάκριτα.

Μια άρνηση είναι ουσιαστικά μόνιμη

Όταν κάποιος μπλοκάρει τις ειδοποιήσεις, ο browser αποθηκεύει αυτή την απόφαση για την προέλευσή σας. Μεταγενέστερες κλήσεις στο Notification.requestPermission() επιλύονται στην αποθηκευμένη τιμή denied χωρίς να εμφανίσουν τίποτα, γι’ αυτό και το ίδιο το παράδειγμα του MDN ελέγχει το Notification.permission πριν καλέσει ποτέ το requestPermission(). Η αναίρεση ενός αποκλεισμού σημαίνει ψάξιμο στις ρυθμίσεις ιστότοπου, κάτι που ουσιαστικά δεν κάνει κανείς.

Τι κάνουν οι browsers όταν το κάνετε λάθος

Οι συνέπειες δεν είναι πια απλώς ένα χαμηλό ποσοστό αποδοχής.

• Το Chrome εντάσσει αυτόματα τις προελεύσεις με πολύ χαμηλά ποσοστά αποδοχής σε μια πιο ήσυχη διεπαφή αδειοδότησης, ξεχωριστά ανά τύπο συσκευής, καταστέλλοντας την προτροπή για όλους.
• Το Chrome εφαρμόζει όρια ρυθμού σε ιστότοπους που συνδυάζουν μεγάλο όγκο push με χαμηλή εμπλοκή, επιστρέφοντας HTTP 429. Η κλιμάκωση διαρκεί μία ημέρα, μετά επτά, μετά δεκατέσσερις, και μηδενίζεται μόνο μετά από 42 συνεχόμενες ημέρες χωρίς όχληση.
• Το Chrome πλέον ανακαλεί αυτόματα την άδεια ειδοποιήσεων για ιστότοπους με τους οποίους ο χρήστης δεν έχει αλληλεπιδράσει πρόσφατα, όπου υπάρχει «very low user engagement and a high volume of notifications being sent». Η αιτιολόγηση της Google είναι ωμή: «Less than 1% of all notifications receive any interaction from users».

Μπορείτε να χάσετε συνδρομητές που ήδη κερδίσατε, απλώς και μόνο επειδή στέλνετε άσχημα.

Το web push σε σύγκριση με email και SMS

Η διαφορά κατοχής που αλλάζει τη στρατηγική

Μια συνδρομή push είναι ένα URL δυνατότητας δεμένο σε ένα προφίλ browser σε μία συσκευή. Δεν είναι πρόσωπο. Ο ίδιος πελάτης που χρησιμοποιεί Chrome σε φορητό και Firefox σε τηλέφωνο είναι δύο άσχετες συνδρομές, και δεν μπορείτε να ξέρετε ότι είναι ο ίδιος άνθρωπος αν δεν ταυτοποιηθεί ο ίδιος.

Δεν είναι επίσης φορητή. Μπορείτε να εξαγάγετε μια λίστα email και να τη φορτώσετε αύριο σε άλλη πλατφόρμα. Δεν μπορείτε να μετακινήσετε συνδρομές push ανάμεσα σε παρόχους, επειδή τα κλειδιά και η σύνδεση VAPID δημιουργήθηκαν έναντι συγκεκριμένου κλειδιού διακομιστή εφαρμογής.

Αντιμετωπίστε λοιπόν το web push ως επιταχυντή πάνω σε ένα κανάλι που σας ανήκει, ποτέ ως αντικαταστάτη. Χρησιμοποιήστε τη στιγμή του push για να κερδίσετε μια διεύθυνση email ή έναν αριθμό τηλεφώνου, και όχι το αντίστροφο. Ο πλήρης οδηγός αυτοματοποίησης μάρκετινγκ καλύπτει τη σύνδεση πολλών καναλιών σε ένα ταξίδι.

Περιπτώσεις χρήσης που πραγματικά δουλεύουν

Το κανάλι ανταμείβει μηνύματα που είναι χρονικά ευαίσθητα, προσωπικά συναφή και εκτελέσιμα με ένα άγγιγμα.

• Εγκατάλειψη καλαθιού. Ένα push μέσα σε μία ώρα, ενισχυμένο από ένα email αργότερα. Ο οδηγός για email εγκαταλελειμμένου καλαθιού καλύπτει την αλληλουχία.
• Ειδοποιήσεις επιστροφής σε απόθεμα. Η ισχυρότερη περίπτωση, γιατί ο χρήστης ζήτησε ρητά να ενημερωθεί.
• Πτώσεις τιμών σε προϊόντα που παρακολουθεί. Ίδια λογική, συνάφεια που επιλέγεται από τον ίδιο.
• Κατάσταση παράδοσης και παραγγελίας. Υψηλή πρόθεση ανοίγματος, χαμηλός κίνδυνος παραπόνων.
• Έκτακτες ενημερώσεις σε θέμα που παρακολουθεί. Ειδήσεις, αποτελέσματα, παράθυρα διαθεσιμότητας.

Το τι αποτυγχάνει είναι εξίσου σαφές: γενικές μαζικές ανακοινώσεις τύπου «δημοσιεύσαμε νέο άρθρο», αδιαφοροποίητες καθημερινές προσφορές, οτιδήποτε χρειάζεται περισσότερα από έναν τίτλο και μία γραμμή, μηνύματα επανενεργοποίησης προς συνδρομητές που αγνόησαν τις τελευταίες είκοσι ειδοποιήσεις, και transactional περιεχόμενο που χρειάζεται μόνιμο αρχείο.

Συχνότητα, χρονισμός και τμηματοποίηση

Ξεκινήστε συντηρητικά: μία έως τρεις ειδοποιήσεις ανά συνδρομητή την εβδομάδα, με επέκταση μόνο αν κρατήσουν τα ποσοστά διαγραφής και κλικ. Η κόπωση εμφανίζεται ταχύτερα από ό,τι στο email, γιατί η σίγαση κοστίζει ένα άγγιγμα πάνω σε μια ειδοποίηση που το λειτουργικό σύστημα ήδη εμφάνισε.

Ο χρονισμός είναι ταυτόχρονα πλεονέκτημα και κίνδυνος. Το push φτάνει αμέσως, οπότε ένα μήνυμα που στάλθηκε στις 02:00 φτάνει στις 02:00. Αποθηκεύστε ή συμπεράνετε τη ζώνη ώρας του συνδρομητή τη στιγμή της εγγραφής και κρατήστε τις αποστολές μέσα σε ορισμένο παράθυρο.

Η τμηματοποίηση περιορίζεται από όσα γνωρίζετε για μια συνδρομή και όχι για ένα πρόσωπο, οπότε οι εφαρμόσιμες διαστάσεις είναι συμπεριφορικές: σελίδες που είδε, προϊόντα που παρακολουθεί, κατάσταση καλαθιού, πρόσφατη αγορά, πλατφόρμα. Ο οδηγός τμηματοποίησης πελατών εμβαθύνει περισσότερο.

Μετρώντας το web push

Τέσσερις μετρικές μετρούν, και δεν μετριούνται όλες με τον ίδιο τρόπο.

• Παράδοση. Αν η υπηρεσία push δέχτηκε το αίτημα. Ένα 201 σημαίνει αποδεκτό, όχι παραδομένο. Ένα 404 ή 410 σημαίνει ότι η συνδρομή είναι νεκρή.
• Εμφάνιση. Αν η ειδοποίηση εμφανίστηκε. Το ξέρετε μόνο αν ο service worker αναφέρει πίσω όταν επιλύεται το showNotification().
• Ποσοστό κλικ. Κλικ διά εμφανίσεις. Αυτός είναι ο αριθμός που αξίζει να βελτιστοποιήσετε.
• Ποσοστό διαγραφής. Διαγραφές και ανακλήσεις άδειας ανά αποστολή. Παρακολουθήστε το πιο στενά από το ποσοστό κλικ, γιατί είναι ο πρώιμος δείκτης του θανάτου του καναλιού.

Παγίδες απόδοσης αποτελεσμάτων

Η απόδοση αποτελεσμάτων στο push κολακεύει τον εαυτό της. Η ειδοποίηση φτάνει σε μια συσκευή που ο συνδρομητής ήδη κρατά, οπότε συχνά παίρνει τα εύσημα για μια επίσκεψη που θα γινόταν έτσι κι αλλιώς. Τρέξτε ομάδες ελέγχου αντί να υποθέτετε προσαύξηση. Οι εμφανίσεις υποεκτιμώνται ενώ κάθε κλικ καταγράφεται, οπότε ένα ποσοστό κλικ υπολογισμένο πάνω στις αποστολές υπερεκτιμά την απόδοση. Και επειδή μια συνδρομή είναι ένας browser και όχι ένα πρόσωπο, ένα push που πατήθηκε σε τηλέφωνο και κατέληξε σε αγορά από υπολογιστή μοιάζει με δύο άσχετα συμβάντα. Ο οδηγός μετρικών email marketing καλύπτει την υγιεινή των μετρήσεων σε όλα τα κανάλια.

Συγκατάθεση, GDPR και διαγραφή

Η προτροπή άδειας του browser είναι τεχνική πύλη. Δεν αποτελεί αυτόματα πλήρη νομική βάση για μάρκετινγκ.

Όπου απευθύνεστε σε ανθρώπους στην ΕΕ ή στο Ηνωμένο Βασίλειο, αντιμετωπίστε το push όπως το email. Εξηγήστε τι θα στέλνετε πριν εμφανιστεί η προτροπή, ώστε η συγκατάθεση να είναι ενημερωμένη και συγκεκριμένη. Καταγράψτε πότε και πού δημιουργήθηκε η συνδρομή, και μη συνδυάζετε ποτέ τη συγκατάθεση για push με μια άσχετη ενέργεια. Αν συνδέετε συνδρομές με ταυτοποιημένους πελάτες, αυτά τα δεδομένα εμπίπτουν στις υποχρεώσεις σας για προσωπικά δεδομένα, συμπεριλαμβανομένων των αιτημάτων διαγραφής.

Η υγιεινή της διαγραφής μετράει εξίσου. Προσφέρετε ένα χειριστήριο προτιμήσεων μέσα στον ιστότοπο, ώστε οι άνθρωποι να μειώνουν τη συχνότητα αντί να μπλοκάρουν, καλέστε το PushSubscription.unsubscribe() και διαγράψτε την εγγραφή στον διακομιστή όταν το κάνουν, και εκκαθαρίστε συνδρομές σε 404 ή 410. Η οδηγία του MDN είναι σύντομη και σωστή: οι χρήστες πρέπει να έχουν «offered an easy way to opt out of getting more in the future».

Πού ταιριάζει το web push σε ένα σύνολο καναλιών

Το web push είναι καλό τρίτο κανάλι και κακό πρώτο: γρήγορο, δωρεάν στο περιθώριο και ασυναγώνιστο για ειδοποιήσεις κρίσιμου χρόνου, αλλά δεμένο σε συσκευή, μη εξαγώγιμο και ένα κλικ μακριά από μόνιμη απώλεια.

Αυτό κάνει την ενορχήστρωση το πραγματικό πρόβλημα. Ποιο μήνυμα πάει σε ποιο κανάλι, πώς καταστέλλετε το email όταν το push ήδη μετέτρεψε, και πώς κρατάτε μία ενιαία εικόνα του πελάτη σε επιφάνειες που ταυτοποιούν τους ανθρώπους διαφορετικά. Το Brevo προσφέρει web και mobile push μαζί με email και SMS, ενώ το Tajo κάθεται πάνω από το Brevo και συντονίζει αυτή τη λογική ανάμεσα στα κανάλια για καταστήματα Shopify. Για την πλευρά του SMS, δείτε τον οδηγό αυτοματοποίησης SMS.

Βασικά συμπεράσματα

• Το web push είναι τρία API που συνεργάζονται: ένας service worker για εκτέλεση στο παρασκήνιο, το Push API για συνδρομή και μεταφορά, το Notifications API για την εμφάνιση. Μια συνδρομή είναι ένα endpoint συν ένα κλειδί p256dh και ένα μυστικό auth, τα payloads κρυπτογραφούνται από άκρο σε άκρο, και το VAPID αποδεικνύει τον αποστολέα.
• Το push είναι Baseline ευρέως διαθέσιμο από τον Μάρτιο του 2023, αλλά στα iOS και iPadOS λειτουργεί μόνο για web apps που προστέθηκαν στην αρχική οθόνη.
• Μη ζητάτε ποτέ άδεια κατά τη φόρτωση της σελίδας. Χρησιμοποιήστε ήπια προ-προτροπή, ρωτήστε μέσα σε πλαίσιο, και θυμηθείτε ότι ένας αποκλεισμός είναι μόνιμος για αυτή την προέλευση.
• Το Chrome επιβάλλει πλέον πιο ήσυχες προτροπές, όρια ρυθμού και αυτόματη ανάκληση άδειας, οπότε η κακή αποστολή σας κοστίζει συνδρομητές που ήδη έχετε.
• Μια συνδρομή είναι ένας browser, όχι ένα πρόσωπο, και δεν μπορεί να εξαχθεί. Χτίστε πρώτα τη λίστα email και χρησιμοποιήστε το push για να την επιταχύνετε.