Jeg møtte først pushvarsler da jeg utviklet mobilapplikasjoner. Senere ble det samme prinsippet utvidet til nettet: En besøkende tillater meldinger, og nettleseren kan vise dem selv når nettstedet ikke er åpent akkurat da.
Det er teknisk interessant. Fra et markedsføringsperspektiv er et annet spørsmål viktigere: Har vi noe så nyttig og tidskritisk at vi har rett til å avbryte noen på grunn av det? Hvis ikke, trenger vi ikke en ny kanal.
Hva web-push faktisk er
En webapplikasjon bruker vanligvis varslingstillatelse, en service worker og nettleserens push-tjeneste. Et abonnement er knyttet til en bestemt nettleser og enhet, ikke automatisk til en person i CRM-systemet. MDN Push API beskriver det tekniske grunnlaget og service workerens rolle.
Det får en praktisk konsekvens: Antallet abonnementer er ikke det samme som antallet kunder. Én person kan ha flere enheter, installere nettleseren på nytt eller når som helst trekke tilbake tillatelsen. Uten en innlogget konto og en gjennomtenkt kobling vet du som regel ikke hvem som eier enheten. Jeg ville ikke forsøkt å skjule denne usikkerheten med en overdrevent presis persona.
Be bare om tillatelse når det finnes en kontekst
Det dårligste alternativet er systemforespørselen med én gang noen kommer til et nettsted. Personen vet ennå ikke hva du tilbyr, og nettleseren ber om en langsiktig tillatelse. Hvis personen velger å blokkere den, får du ofte ikke en ny sjanse uten at vedkommende manuelt endrer innstillingene.
Derfor forklarer jeg først en konkret fordel: Varsel om endring i ordrestatus, en ledig time, starten på en sending eller at et overvåket produkt er tilbake. Først etter en bevisst brukerhandling åpner jeg nettleserens faktiske forespørsel. Dokumentasjonen for Notifications API på MDN anbefaler på samme måte å knytte forespørselen til en brukerhandling.
Når push gir mening
- Status og tilgjengelighet: En ordre, reservasjon, avtale eller et produkt har blitt endret.
- Tidskritisk innhold: En sending starter, en auksjon avsluttes eller et arrangement personen selv har valgt, har funnet sted.
- Et tilbakevendende arbeidsverktøy: Brukeren forventer driftsvarsler som en del av tjenesten.
- Bevisst oppfølging: Personen har aktivt slått på et bestemt tema, ikke vage «nyheter».
Jo nærmere meldingen er knyttet til atferd brukeren uttrykkelig har satt opp, desto enklere er det å rettferdiggjøre avbrytelsen. En generell rabatt for alle er en svakere grunn enn et varsel noen selv har bedt om.
Når jeg ville valgt e-post
E-post egner seg bedre til en lengre forklaring, et dokument, en oppsummering og kommunikasjon som noen kan håndtere senere. Push har liten plass, forsvinner raskt og bør ikke føre videre til en side der brukeren må lete etter betydningen av meldingen på nytt.
Hvis en virksomhet ikke klarer å håndtere relevante e-poster, vil en annen kanal ofte bare mangedoble problemet. Jeg ville først fått databasen, tilbudet og prosessen på plass ved hjelp av artikkelen om e-postmarkedsføring. Deretter ville jeg valgt verktøy ut fra et konkret scenario, ikke ut fra antallet ikoner i prislisten.
Hva hver melding må inneholde
- en tydelig grunn til at den kom akkurat nå;
- en gjenkjennelig avsender;
- en kortfattet melding uten falsk hastverk;
- en målside som følger meldingen nøyaktig;
- mulighet til å justere temaer eller avslutte abonnementet;
- en frekvensgrense og stilleperiode basert på brukerens situasjon.
Jeg ville ikke sendt den samme meldingen samtidig via push, e-post, SMS og chat bare fordi integrasjonen finnes. Orkestrering betyr å velge riktig kanal, ikke å bruke alle.
Slik måler du push
Levering og klikk er driftsindikatorer. Forretningsverdi oppstår først med neste steg: å fullføre en reservasjon, gå tilbake til appen, kjøpe et overvåket produkt eller redusere antallet henvendelser til kundestøtten.
Jeg følger også med på negative signaler: tilbakekalt tillatelse, avmeldinger fra temaer, rask retur uten handling og klager. En høy klikkfrekvens kan skyldes aggressiv formulering samtidig som kanalen ødelegges på lang sikt.
Jeg merker lenker med konsekvente UTM-parametere, men tar høyde for at deler av målingen begrenses av nettleseren, samtykket og enhetens livssyklus. Nøyaktighet i dashbordet er ikke en grunn til å samle inn mer data uten at det gir personen en fordel.
En liten pilot i stedet for en lansering på hele nettstedet
- Jeg velger ett enkelt hendelsesscenario med tydelig verdi.
- Jeg beskriver hvem som kan slå på abonnementet, og på hvilket tidspunkt.
- Jeg setter en frekvensgrense, utløpstid for meldingen og en mulighet til å slå den av.
- Jeg tester ulike nettlesere, enheter og situasjonen uten tillatelse.
- Jeg måler den fullførte oppgaven så vel som negative reaksjoner.
- Etter flere runder avgjør jeg om kanalen skal utvides, justeres eller slås av.
Min konklusjon
Pushvarsler er ikke et billigere nyhetsbrev. De er korte, begrunnede avbrytelser. De fungerer godt for en hendelse personen selv har valgt, og som vedkommende trenger å vite om i tide. De fungerer dårlig som enda en flate for generell markedsføring.
Hvis du vil avgjøre om push hører hjemme i hele kundereisen, kan du starte med en gjennomgang av markedsføringssystemet ditt. Du kan beskrive den konkrete situasjonen din gjennom kontakt.