Jeg stødte første gang på pushnotifikationer, da jeg udviklede mobilapplikationer. Senere blev det samme princip udvidet til nettet: En besøgende tillader beskeder, og browseren kan vise dem, selv når personen ikke har webstedet åbent i øjeblikket.
Teknisk er det interessant. Fra et marketingsynspunkt er et andet spørgsmål vigtigere: Har vi noget så nyttigt og tidsfølsomt, at vi har ret til at afbryde nogen for det? Hvis ikke, har vi ikke brug for endnu en kanal.
Hvad web-push faktisk er
En webapplikation arbejder typisk med notifikationstilladelse, en service worker og browserens push-tjeneste. Et abonnement er knyttet til en bestemt browser og enhed, ikke automatisk til en person i CRM-systemet. MDN Push API beskriver det tekniske grundlag og service workerens rolle.
Det har en praktisk konsekvens: Antallet af abonnementer er ikke det samme som antallet af kunder. Én person kan have flere enheder, geninstallere sin browser eller til enhver tid trække sit samtykke tilbage. Uden en login-konto og omhyggelig sammenkædning ved du som regel ikke, hvem der ejer en enhed. Jeg ville ikke forsøge at skjule denne usikkerhed med en alt for præcis persona.
Bed kun om tilladelse med en forklaring
Den dårligste mulighed er systemprompten, straks man ankommer til et websted. Personen ved endnu ikke, hvad du tilbyder, og browseren beder om en langsigtet tilladelse. Hvis personen vælger at blokere den, får du ofte ikke en ny chance, uden at vedkommende manuelt ændrer indstillingerne.
Derfor forklarer jeg først en konkret fordel: en notifikation om ændring i ordrestatus, en ledig tid, starten på en udsendelse eller at et overvåget produkt er tilbage. Først efter en bevidst brugerhandling åbner jeg browserens egentlige anmodning. Dokumentationen for Notifications API på MDN anbefaler ligeledes at knytte anmodningen til en brugerhandling.
Hvornår push giver mening
- Status og tilgængelighed: En ordre, reservation, aftale eller et produkt er ændret.
- Tidsfølsomt indhold: En udsendelse begynder, en auktion slutter, eller en begivenhed, som personen selv har valgt, er indtruffet.
- Et tilbagevendende arbejdsværktøj: Brugeren forventer driftsnotifikationer som en del af tjenesten.
- Bevidst overvågning: Personen har aktivt slået et bestemt emne til i stedet for vage “nyheder”.
Jo tættere beskeden knytter sig til en handling eller overvågning, som brugeren udtrykkeligt har slået til, desto lettere er det at retfærdiggøre afbrydelsen. En generel rabat til alle er en svagere grund end en besked, nogen selv har bedt om.
Hvornår jeg ville holde fast i e-mail
E-mail egner sig bedre til en længere forklaring, et dokument, en opsummering og kommunikation, som nogen kan håndtere senere. Push har kun lidt plads, forsvinder hurtigt og bør ikke ved klik føre til en side, hvor brugeren igen skal lede efter beskedens betydning.
Hvis en virksomhed ikke kan håndtere relevant e-mail, vil endnu en kanal ofte blot forstørre problemet. Jeg ville først bringe databasen, tilbuddet og processen i orden ved hjælp af artiklen om e-mailmarketing. Derefter ville jeg vælge værktøjer efter et konkret scenarie, ikke efter antallet af ikoner på prislisten.
Hvad enhver besked skal indeholde
- en tydelig grund til, at den kom netop nu;
- en genkendelig afsender;
- et kort budskab uden falsk hast;
- en destinationsside, der følger beskeden præcist;
- en mulighed for at justere emner eller afslutte abonnementet;
- en frekvensgrænse og en stilleperiode baseret på brugerens situation.
Jeg ville ikke sende den samme besked samtidig via push, e-mail, SMS og chat, blot fordi integrationen findes. Orkestrering betyder at vælge den rette kanal, ikke at bruge dem alle.
Sådan måler du push
Levering og klik er driftsmæssige signaler. Forretningsværdi opstår først med det næste skridt: at gennemføre en reservation, vende tilbage til appen, købe et overvåget produkt eller reducere antallet af supporthenvendelser.
Jeg følger også negative signaler: tilbagekaldt tilladelse, afmeldinger fra emner, hurtige tilbagebesøg uden handling og klager. En høj klikrate kan skyldes aggressiv formulering, samtidig med at kanalen ødelægges på lang sigt.
Jeg tilføjer ensartede UTM-parametre til links, men tager højde for, at en del af målingen begrænses af browseren, samtykke og enhedens livscyklus. Dashboardets nøjagtighed er ikke en grund til at udvide dataindsamlingen uden fordel for personen.
Et lille pilotprojekt i stedet for en lancering på hele webstedet
- Jeg vælger ét scenarie for en hændelse med tydelig værdi.
- Jeg beskriver, hvem der kan aktivere abonnementet, og på hvilket tidspunkt.
- Jeg fastsætter en frekvensgrænse, beskedens udløb og en mulighed for at slå den fra.
- Jeg tester forskellige browsere, enheder og situationen uden tilladelse.
- Jeg måler den gennemførte opgave såvel som negative reaktioner.
- Efter flere cyklusser beslutter jeg, om kanalen skal udvides, justeres eller slås fra.
Min konklusion
Pushnotifikationer er ikke et billigere nyhedsbrev. De er korte, begrundede afbrydelser. De fungerer godt ved en begivenhed, som personen selv har valgt og har brug for at kende til i tide. De fungerer dårligt som endnu en flade til generel promovering.
Hvis du vil beslutte, om push hører hjemme i hele kunderejsen, så begynd med en gennemgang af dit marketingsystem. Du kan beskrive din konkrete situation via kontakt.