De korte versie
Deze twee kanalen lijken op elkaar omdat ze allebei korte berichten in je product tonen, maar ze staan aan weerszijden van twee grenzen: bereik en toestemming. Webpush verlaat je site en komt op het apparaat terecht nadat de gebruiker de browser toestemming heeft gegeven. In-app berichten blijven binnen een actieve sessie en hebben geen aparte toestemming nodig. Behandel ze als twee tools, niet als één.
Hoe webpush werkt
Webpush leunt op drie onderdelen van de browser die samenwerken: een service worker (een script dat de browser op de achtergrond laat draaien), de Push API (die de browser abonneert op een pushdienst en berichten ontvangt) en de Notifications API (die de systeemmelding toont). De gebruiker moet expliciet op Toestaan klikken in de toestemmingsvraag van de browser; tot dat gebeurt, kun je niets versturen. Na de opt-in krijg je een abonnementsendpoint en encryptiesleutels, en je server verstuurt via de pushdienst van de browser, ook als het tabblad gesloten is. Omdat het bericht buiten je site aankomt, is webpush het kanaal in dit rijtje om mensen terug te halen: qua doel dichter bij sms of e-mail dan bij iets wat in je app leeft. De kanttekening: het is begrensd door wat browsers en besturingssystemen ondersteunen, en de gebruiker kan de toestemming op elk moment intrekken.
Het voorbehoud voor iOS
Op iPhone en iPad werkt webpush niet in een gewoon Safari-tabblad. Apple heeft webpush alleen toegevoegd voor webapps die de gebruiker op het beginscherm heeft gezet, vanaf Safari 16.4 (maart 2023). Het toestemmingsverzoek moet volgen op een directe tik, bijvoorbeeld op een knop Abonneren, en niet bij het laden van de pagina verschijnen. Op iOS bestaat je bereikbare publiek dus uit de gebruikers die je site als webapp hebben geïnstalleerd en daarna toestemming hebben gegeven. Houd rekening met dat gat in plaats van ervan uit te gaan dat het hetzelfde werkt als op desktop.
Hoe in-app berichten werken
In-app berichten verschijnen binnen een actieve sessie: een banner, modal, slide-out of tooltip die je product toont terwijl de gebruiker het gebruikt. Er is geen aparte opt-in, want de gebruiker zit al in je product; het bericht hoort bij de ervaring. De keerzijde is het bereik: in-app raakt alleen mensen die op dit moment aanwezig zijn. Het kan geen gebruiker terughalen die inactief is geworden, en iemand die is afgehaakt, ziet het nooit.
Wanneer gebruik je wat?
| Doel | Gebruik |
|---|---|
| Een inactieve gebruiker terughalen | Webpush (of e-mail / sms) |
| Een functie aankondigen aan actieve gebruikers | In-app banner of modal |
| Een nieuwe gebruiker door de inrichting loodsen | In-app tooltip of slide-out |
| Buiten de site melden dat er iets tijdgevoeligs gebeurt | Webpush |
| Midden in een taak aansporen tot een upgrade | In-app modal |
De eerlijke verdeling: in-app bedient de mensen die er al zijn, webpush gaat op zoek naar de mensen die zijn vertrokken. De meeste producten gebruiken allebei, afgestemd binnen een customer journey, zodat dezelfde persoon niet binnen enkele minuten een in-app duwtje en een pushmelding over hetzelfde krijgt. Bepalen welk kanaal welk bericht brengt, in welke volgorde en zonder overlap, is de stap van veel kanalen draaien naar ze als één geheel draaien: het onderwerp van multichannel vs. omnichannel. Losse tools zoals OneSignal of Novu zijn gespecialiseerd in het afleveren van pushmeldingen en notificaties; een engagementplatform brengt pushmeldingen en in-app berichten onder in dezelfde journeylogica als de rest van je kanalen.