Gebruik pushmeldingen voor korte, tijdgevoelige berichten die iemand moeten bereiken die niet in je app zit, in-app berichten voor alles wat te maken heeft met wat de gebruiker op dat moment doet, en e-mail voor details, vastleggingen en mensen die de app niet meer openen. De drie kanalen concurreren niet met elkaar: push brengt mensen terug, in-app begeleidt ze zodra ze er zijn, en e-mail bevat alles wat bewaard of goed gelezen moet worden.
Push vs e-mail vs in-app: hoe verhouden de drie kanalen zich tot elkaar?
Elk kanaal wordt bepaald door waar het bericht verschijnt en wie het kan ontvangen. Al het andere volgt uit die twee feiten.
| Pushmelding | In-app bericht | ||
|---|---|---|---|
| Waar het verschijnt | Vergrendelscherm, banner en meldingencentrum, buiten de app | In de app, tijdens een sessie | De inbox van de gebruiker, buiten de app |
| Wie het kan ontvangen | Gebruikers die de app hebben geïnstalleerd en meldingen hebben toegestaan | Gebruikers die de app openen | Iedereen van wie je het e-mailadres hebt en die zich niet heeft afgemeld |
| Moet de app open zijn? | Nee | Ja | Nee |
| Moet de gebruiker eerst toestemming geven? | Ja, via een systeemprompt | Nee | Ze moeten je een adres geven en kunnen zich afmelden |
| Hoeveel je kunt zeggen | Een titel en een of twee regels | Van één zin tot een volledig scherm, met knoppen en afbeeldingen | Zoveel als je nodig hebt |
| Hoe lang het blijft staan | Tot het wordt weggeveegd of door nieuwere meldingen naar beneden wordt gedrukt | Tot de gebruiker het sluit, tenzij je een inbox bouwt | Tot de gebruiker het verwijdert of archiveert |
| Hoe storend het is | Hoog | Gemiddeld, de gebruiker is al actief | Laag, gelezen wanneer de gebruiker dat wil |
| Beste taak | De gebruiker terugbrengen voor iets wat nu gebeurt | Begeleiden, aankondigen of aansporen in context | Uitleggen, bevestigen, samenvatten, terugwinnen |
| Grootste risico | Gebruikers zetten meldingen uit | Nooit gezien door gebruikers die niet terugkomen | Blijft ongelezen of komt in de verkeerde map terecht |
Wat is het verschil tussen pushmeldingen en in-app meldingen?
Een pushmelding wordt afgeleverd door het besturingssysteem van de telefoon en verschijnt buiten je app. Een in-app melding wordt door je eigen app getoond en verschijnt alleen terwijl iemand de app gebruikt. Dat ene verschil bepaalt wie het bericht ziet, wanneer, en of diegene er eerst mee moest instemmen.
Waar elk van de twee verschijnt
Pushmeldingen worden via de afleverdiensten van Apple en Google naar het apparaat gestuurd, waar het systeem ze toont op het vergrendelscherm, als banner of in het meldingencentrum. Je app hoeft niet actief te zijn.
In-app meldingen zijn onderdeel van je interface. Firebase In-App Messaging, de tool van Google hiervoor, omschrijft de taak als het sturen van gerichte, contextuele berichten naar de actieve gebruikers van je app, en biedt ze aan als kaarten, banners, modals of afbeeldingen. Tooltips, schermvullende takeovers en een meldingeninbox in de app zijn veelvoorkomende varianten van hetzelfde idee.
Wie elk van de twee kan ontvangen
Push bereikt alleen mensen die ja hebben gezegd. Op iOS staat in de ontwikkelaarsdocumentatie van Apple dat je toestemming moet krijgen om meldingen te gebruiken, en dat het systeem de persoon een prompt toont de eerste keer dat je app erom vraagt en bij latere verzoeken niet opnieuw. Op Android staat in de documentatie van Google dat de meldingen van een app op Android 13 of hoger standaard uit staan totdat de gebruiker de toestemming geeft.
In-app berichten hebben geen systeemtoestemming nodig, omdat ze gewoon onderdeel van de app zijn. De beperking is een andere: een gebruiker die de app nooit opent, ziet ze nooit.
De twee doelgroepen overlappen dus, maar zijn niet hetzelfde. Push bereikt geïnstalleerde gebruikers die meldingen hebben toegestaan, of ze nu actief zijn of niet. In-app bereikt actieve gebruikers, of ze nu meldingen hebben toegestaan of niet.
Wat er gebeurt nadat het bericht is gezien
Een pushmelding raak je makkelijk kwijt. Eén veeg en hij is weg, en een vol meldingencentrum begraaft hem. Een in-app bericht kan net zo kortstondig zijn (een banner die verdwijnt) of het kan worden bewaard, als je een inbox of meldingenfeed bouwt waarin eerdere berichten beschikbaar blijven. Als de gebruiker de informatie volgende week misschien nodig heeft, is een push of een voorbijkomende banner op zichzelf niet genoeg.
Push vs in-app meldingen: wanneer gebruik je welke?
Gebruik push als de gebruiker weg is en het bericht niet kan wachten. Gebruik in-app als het bericht alleen zinvol is in de context van wat de gebruiker aan het doen is, of als het kan wachten tot het volgende bezoek.
Wanneer push de juiste keuze is
- Er gebeurt nu of heel binnenkort iets: een livesessie die begint, een bezorging die aankomt, een bod dat wordt overboden.
- Iemand anders heeft iets gedaan waar de gebruiker om geeft: een reactie, een vermelding, een vriend die zich aanmeldt.
- Een herinnering waar de gebruiker om heeft gevraagd: een training, een les, een tijd om medicijnen in te nemen.
- Een korte accountmelding, zoals een mislukte verlenging, met de details ook per e-mail.
Push is de verkeerde keuze voor alles wat lang is, alles wat niet tijdgebonden is, en algemene promotie. De richtlijnen van Apple over het beheren van meldingen zeggen dat je meldingen niet moet gebruiken voor marketing of promotionele content, tenzij mensen er uitdrukkelijk mee hebben ingestemd die te ontvangen, en dat je het niveau Time Sensitive moet bewaren voor gebeurtenissen die nu of binnen het uur plaatsvinden.
Wanneer in-app de juiste keuze is
- Onboardingstappen en tips die horen bij het scherm waarop de gebruiker zit.
- Een functie aankondigen op het moment dat die nuttig is.
- Upgradeprompts en paywalls, getoond wanneer de gebruiker een limiet bereikt.
- Enquêtes en verzoeken om feedback, direct na de ervaring waarnaar je vraagt.
- Uitnodigingen om door te verwijzen, op een moment dat de gebruiker blij is met de app.
In-app is de verkeerde keuze om mensen te bereiken die zijn afgehaakt, en voor alles waar de gebruiker buiten de app iets mee moet doen.
Pushmelding vs e-mail: wat moet je sturen?
Stuur een push als de waarde van het bericht in de timing zit. Stuur een e-mail als de waarde in de inhoud zit. Als een bericht morgen nutteloos is, is het een push. Als de gebruiker het over een maand misschien terug wil vinden, is het een e-mail.
Wat e-mail kan en push niet
- Het blijft bestaan. Bonnen, verlengingsmeldingen, wachtwoordresets en wijzigingen in je voorwaarden horen op een plek waar de gebruiker later kan zoeken.
- Het bevat details. Een changelog, een wekelijks voortgangsoverzicht of een stapsgewijze handleiding past niet in een melding.
- Het bereikt mensen zonder de app. Iemand die de app heeft verwijderd, van telefoon is gewisseld of nooit meldingen heeft toegestaan, is nog steeds per e-mail te bereiken.
- Het werkt op elk apparaat. De gebruiker kan het aan een bureau lezen en daar actie ondernemen.
Wat push kan en e-mail niet
- Het verschijnt binnen enkele ogenblikken op het vergrendelscherm, zonder dat de gebruiker iets hoeft te openen.
- Het opent de app met één tik op het juiste scherm.
- Het past bij één korte prompt, waar een e-mail zwaar zou aanvoelen.
Wat e-mail van jou vraagt
E-mail heeft zijn eigen toegangseisen. Mailboxproviders verwachten dat afzenders hun verzenddomein authenticeren: de richtlijnen voor e-mailafzenders van Google vragen alle afzenders om SPF of DKIM in te stellen, en vragen marketingberichten om afmelden met één klik te ondersteunen. Een e-mail die niet goed is ingesteld, bereikt de inbox misschien helemaal niet, en dat is voor e-mail het equivalent van een gebruiker die meldingen uitzet.
Berichten die beide verdienen
Een paar berichten zijn zowel urgent als gedetailleerd. Een mislukte betaling is het gebruikelijke voorbeeld: stuur een korte push zodat de gebruiker het vandaag weet, en een e-mail met het bedrag, de datum en de link om het op te lossen. De push alarmeert, de e-mail legt uit. Stuur niet in beide dezelfde tekst, want dan leest de gebruiker het twee keer en leert hij een van de twee over te slaan.
Hoe kies je een kanaal voor een specifiek bericht?
Stel drie vragen in deze volgorde, en stop bij de eerste die een antwoord geeft.
- Is het alleen zinvol in de app, op een bepaald moment? Gebruik in-app.
- Verliest het binnen enkele uren zijn waarde? Gebruik push, met in-app als terugvaloptie voor gebruikers die meldingen uit hebben staan.
- Heeft het details nodig, of wil de gebruiker het bewaren? Gebruik e-mail.
Als een bericht door geen van de drie komt, hoeft het misschien niet verstuurd te worden.
Zo pakt dat uit voor de berichten die de meeste apps versturen:
| Bericht | Eerste keuze | Voeg een tweede kanaal toe als |
|---|---|---|
| Iemand heeft op je gereageerd | Push | Toon het in-app als de gebruiker in een sessie zit |
| Proefperiode eindigt morgen | Push | Stuur dezelfde dag een e-mail met wat er daarna gebeurt |
| Aankoopbewijs | Bevestig het op het scherm direct na de aankoop | |
| Wachtwoordreset | Nooit, houd het op één plek | |
| Nieuwe functie | In-app | Mail gebruikers die de app de laatste tijd niet hebben geopend |
| Upgradeprompt | In-app | Zelden, een aanbod per e-mail voor gebruikers met een verlopen proefperiode |
| Wekelijks of maandelijks overzicht | Alleen een push als de gebruiker erom heeft gevraagd | |
| Feedbackenquête | In-app | E-mail voor langere onderzoeksenquêtes |
| Een afgehaakte gebruiker terugwinnen | Push als ze meldingen nog aan hebben staan | |
| Uitnodiging om een vriend door te verwijzen | In-app | E-mail als vervolg met hun link |
Hoe gebruik je e-mail, push en in-app samen zonder gebruikers te irriteren?
Bepaal per bericht de volgorde van de kanalen, verstuur eerst via het minst storende kanaal en schaal alleen op voor mensen die het nog niet hebben gezien. Alles overal tegelijk versturen is de snelste manier om de pushtoestemming kwijt te raken.
Trapsgewijs in plaats van alles tegelijk
Neem de lancering van een functie als uitgewerkt voorbeeld. Je zou:
- Een in-app aankondiging tonen aan iedereen die de app in de eerste week opent.
- Gebruikers die de app die week niet hebben geopend een e-mail sturen met de volledige uitleg.
- Alleen een push sturen naar gebruikers die geen van beide hebben gezien, en alleen als de functie iets is waarvoor ze je dankbaar zouden zijn.
Elke stap slaat de mensen over die de vorige stap al heeft bereikt. Hetzelfde patroon werkt andersom voor urgente berichten: eerst push, dan in-app bij de volgende sessie, dan e-mail als de zaak nog openstaat.
Vraag op een logisch moment om pushtoestemming
Omdat iOS zijn toestemmingsprompt één keer toont, is de timing van dat eerste verzoek belangrijker dan elke latere optimalisatie. Apple raadt aan het verzoek in context te doen, bijvoorbeeld nadat iemand zijn eerste taak heeft ingepland in een takenapp, zodat mensen kunnen zien waarvoor de meldingen dienen. Google geeft vergelijkbaar advies voor Android en stelt voor de prompt te laten volgen op een actie van de gebruiker, zoals op een belicoon tikken of een bestelling plaatsen.
Laat gebruikers per onderwerp kiezen, niet alles of niets
Als de enige schakelaar die een gebruiker heeft "alle meldingen uit" is, dan is dat de schakelaar die hij gaat gebruiken. Geef ze categorieën. Op Android is dit ingebouwd: met meldingskanalen kunnen gebruikers de instellingen wijzigen voor elk type melding dat je app verstuurt, en zodra een kanaal is aangemaakt, heeft de gebruiker het gedrag ervan in handen. Op iOS vraagt Apple apps die informatieve of marketingmeldingen versturen om in de app een instellingenscherm aan te bieden waar mensen hun keuze kunnen wijzigen. Doe hetzelfde voor e-mail, met aparte opties voor productnieuws, overzichten en aanbiedingen.
Welk kanaal werkt het best voor verwijzingsuitnodigingen en affiliate-updates?
Uitnodigingen om door te verwijzen werken het best in-app, en updates voor affiliates of partners werken het best per e-mail, omdat de twee doelgroepen zich op verschillende plekken bevinden.
Een gebruiker deelt je app het waarschijnlijkst direct nadat die iets voor hem heeft gedaan: een reeks voltooid, een doel bereikt, een project afgerond. Dat moment bestaat alleen in de app, dus daar hoort de uitnodiging thuis, met een deelknop die het deelmenu van de telefoon opent. We hebben een aparte post over gebruikers omzetten in affiliates met in-app referrals. Als je het scherm liever niet zelf bouwt, bevatten de in-app referrals van Insert Affiliate een kant-en-klaar Refer a friend-scherm dat elke gebruiker een eigen code en link geeft, met de knoppen Copy en Share. Er staat een overzicht op de pagina over het referralprogramma voor mobiele apps.
Affiliates en creators zijn anders. Ze leven niet in je app, en wat ze nodig hebben (een nieuw aanbod, een wijziging in de commissie, hun resultaten van de maand) zijn details waar ze later op terug willen komen. Dat is de taak van e-mail, idealiter ondersteund door een inbox waarin ze kunnen inloggen. Zo werkt affiliate messaging in Insert Affiliate: een direct bericht of een broadcast naar alle affiliates wordt verstuurd als e-mailmelding en verschijnt ook in het onderdeel Messages in het dashboard van de affiliate. Affiliates kunnen zich afmelden voor broadcast-e-mails en toch directe berichten blijven ontvangen, wat hetzelfde principe "kies per onderwerp" is als hierboven beschreven. Verder lezen: affiliatecommunicatie op één plek houden.
Veelgestelde vragen
Zijn in-app meldingen hetzelfde als pushmeldingen?
Nee. Een pushmelding wordt afgeleverd door het besturingssysteem en verschijnt buiten de app, op het vergrendelscherm of in het meldingencentrum. Een in-app melding wordt door de app zelf getoond en is alleen te zien terwijl de app open is. Ze worden vaak door dezelfde gebeurtenis geactiveerd, waarbij de app de ene of de andere kiest, afhankelijk van of de gebruiker op dat moment in een sessie zit.
Hebben in-app meldingen toestemming van de gebruiker nodig?
Er is geen systeemtoestemming nodig, omdat in-app berichten onderdeel zijn van je eigen interface. Push is anders: iOS vereist dat de gebruiker meldingen toestaat, en op Android 13 of hoger staan meldingen standaard uit totdat de gebruiker de toestemming geeft.
Is push beter dan e-mail?
Geen van beide is in het algemeen beter. Push is beter voor korte berichten waarvan de waarde afhangt van de timing, en het kan de app met één tik openen. E-mail is beter voor details, voor alles wat de gebruiker moet bewaren, en voor mensen die de app niet meer hebben of meldingen hebben uitgezet.
Welk kanaal moet ik gebruiken om inactieve gebruikers opnieuw te betrekken?
Begin met e-mail, omdat dat niet afhangt van of de app is geïnstalleerd of meldingen zijn toegestaan. Push kan werken voor gebruikers die meldingen nog aan hebben staan, zolang het bericht een echte reden biedt om terug te komen. In-app berichten helpen hier niet, omdat inactieve gebruikers ze niet zien.
Wat moet ik doen voor gebruikers die pushmeldingen hebben uitgezet?
Gebruik in-app en e-mail als terugvalopties. Toon het bericht in-app bij hun volgende sessie, en stuur een e-mail als het niet zo lang kan wachten. Als push hen duidelijk zou helpen, leg dan op een relevant moment in de app het voordeel uit en verwijs ze naar de instellingen van hun apparaat, omdat iOS de systeemprompt geen tweede keer toont.
Je volgende stap
Maak een lijst van elk bericht dat je app vandaag verstuurt, en haal ze allemaal door de drie vragen hierboven. Verplaats eerst pushberichten die eigenlijk in-app berichten zouden moeten zijn, en voeg daarna voorkeuren per categorie toe, zodat gebruikers het volume lager kunnen zetten zonder je helemaal uit te schakelen.