Du driver et sportsbook eller et kasinomærke med en hjemmeside og en native app, og ét push-budget. Så spørgsmålet om web push vs app push er ikke akademisk: det afgør, hvor din ingeniørtid går hen, hvilke spillere du kan nå på kampdagen, og hvad der sker med din liste næste gang et domæne eller en app store-politik flytter sig under dig. De fleste sammenligninger af de to kanaler er skrevet for generiske app-markedsførere. Denne scorer hver række op mod operatørrealitet: live-odds latenstid, pre-download-tragten, brand-portfolio-domæner og uninstall churn. (For det bredere kanallandskab, se vores generelle sammenligning af push vs in-app notifikationer.)
Det korte svar forud: disse kanaler dækker hinandens blinde vinkler, og de operatører, der behandler dem som rivaler, ender normalt med to halv-lister. Resten af denne guide er det lange svar, så du kan træffe beslutningen bevidst.
To kanaler, to forskellige kontrakter med spilleren
Begge kanaler sender en besked på en skærm, som spilleren allerede kigger på. Lighederne slutter der, for spilleren har accepteret forskellige ting i hvert tilfælde.
Hvad web push-notifikationer er
Web push-notifikationer er browser push-notifikationer. En besøgende klikker "Tillad" én gang på din side, browseren registrerer en service worker mod dit domæne, og du ejer den forbindelse. Ingen installation, ingen app store, ingen download. Abonnementet virker på desktop og Android i Chrome, Firefox, Edge og resten, og beskeden leveres, uanset om din side er åben eller ej.
Det enkelte klik er kanalens økonomi i miniature: den bredest mulige tragt, med den lavest mulige forpligtelse. En førstegangsbesøgende, der sammenligner odds, kan blive nåbar, før de overhovedet opretter en konto.
Hvad app push-notifikationer er
App push-notifikationer er native mobile push-notifikationer, leveret via Apples APNs og Googles FCM via et SDK inde i din app. Spilleren har foretaget en to-trins forpligtelse: de installerede din app, derefter accepterede de en systemtilladelsesprompt. Det er en langt højere barriere end et browserklik, og det viser sig i engagement. En app push-abonnent er næsten pr. definition en spiller, der ønsker dig på deres låseskærm.
Push-notifikations opt-in friktion: et klik vs en installation
Push-notifikations opt-in-barrieren er den reelle skillevej mellem de to kanaler. Web push beder om et enkelt klik fra en besøgende, der måske aldrig vender tilbage; app push beder om en installation plus en systemprompt. Så den ærlige indramning er ikke "hvilken kanal er bedre", men "hvilken kontrakt har hvert spillersegment med dig". Casual og pre-registration trafik har browserkontrakten. Dine indbetalende stamgæster har app-kontrakten.
Web push vs app push: operatørsammenligningstabellen
Her er hele beslutningen på én skærm, med 2026-platformens fakta, der ændrer den, dateret.
| Dimension | Web-push | App-push |
|---|---|---|
| Rækkevidde | Alle i en moderne browser, inklusive desktop. Ingen installation påkrævet. | Kun spillere, der har installeret appen og accepteret prompten. |
| Push-notifikations opt-in friktion | Et browserklik (eller en to-trins prompt, du kontrollerer). | Installation + systemtilladelse. Højeste friktion, højeste intention. |
| iOS-virkelighed | Kun for webapps installeret på startskærmen siden iOS 16.4 (marts 2023). Deklarativ Web Push (Safari 18.4, forår 2025) kræver, at hver push viser en notifikation. | Fuld rækkevidde på enhver iPhone via APNs. |
| Domæneafhængighed | Abonnement er bundet til det oprindelsessted, det blev oprettet på. | Ingen. Tokens tilhører dine APNs/FCM-legitimationsoplysninger, ikke noget domæne. |
| Afinstallationsrisiko | Overlever en app-afinstallation fuldstændigt. Chrome tilbagekalder automatisk tilladelse på oprindelsessteder med lavt engagement og højt volumen (annonceret oktober 2025). | En afinstallation dræber lydløst tokenet. Ingen begivenhed, intet farvel. |
| Latens for live odds | Sekunder. Men oprindelsessteder, som Chrome scorer som "forstyrrende", begrænses til 1.000 pushes pr. minut (live siden januar 2026). | Sekunder. FCM-grænser er pr. enhed (240/min), ikke pr. afsender. |
| Omkostningsgrundlag | Ingen app at bygge eller vedligeholde. Ingen gebyr pr. besked. | Antager en app, du allerede bygger, vedligeholder og holder i butikkerne. |
To af disse rækker fortjener et nærmere kig. Først rækken om latens: Chrome scorer nu hvert afsendende oprindelsessted dagligt baseret på beskeder sendt pr. minut af brugeropmærksomhed, og et markeret oprindelsessted begrænses til 1.000 pushes pr. minut. Med den hastighed tager en kampagne-start-udsendelse til 500.000 abonnenter over otte timer. Segmenterede afsendere er ikke målet, men broadcast-alt-afsendere er, og kampagnedagsafsendelser er præcis, hvor begrænsningen gør ondt.
Derefter iOS-rækken: Web push på iOS findes kun inde i webapps på startskærmen, som næsten ingen af dine spillere har installeret. Hvis din målgruppe primært er iPhone-brugere, efterlader web push alene de fleste af dem uopnåelige på mobil. Android 16's notifikations-nedkøling (juni 2025) opererer på notifikationslaget, så den bør mekanisk presse begge kanaler lige hårdt – en inferens snarere end en dokumenteret platformserklæring, men den sikre planlægningsantagelse. Hurtige bursts bliver gradvist dæmpet, så den tredje notifikation på fem minutter måske aldrig ses på nogen af kanalerne.
Hvornår web push-notifikationer vinder
Fire situationer, alle almindelige i denne vertikal, hvor web push-notifikationer er det rigtige første træk.
Du har ingen app, eller din app sidder fast i gennemgang. Native apps i denne kategori står over for lange, usikre butikstidslinjer på mange markeder. Web push-notifikationer behøver intet af dette: et snippet på dit websted, og din første kampagne sendes samme dag. Det er den hurtigste vej fra nul til en ejet gen-engagement-kanal, hvilket er grunden til, at spillesidens fastholdelses-playbook starter der.
Dine spillere er på desktop. Kampagnedagsadfærd er multi-skærm: streamen på tv'et, bookmakeren åben i en browserfane. App-push kan ikke nå en desktop. En kickoff-påmindelse eller en afgjort-indsats-meddelelse på den anden skærm når spilleren i det øjeblik, de kan handle på den.
Forudgående download-tragt. Enhver fremtidig app-bruger er først en web-besøgende. En push-notifikations-opt-in på hjemmesiden gør den besøgende tilgængelig, før de installerer, og kanalen bliver derefter din bedste overflade til installationskampagner: du ved allerede, hvad de har kigget på, så push-beskeden “få appen” kan være specifik i stedet for generisk.
Genaktivering af afinstallerede apps. Dette er det blinde punkt, som ingen prissætter. Når en spiller afinstallerer din app, dør tokenet stille, og app-push bliver for evigt mørklagt. Deres web-push-abonnement er ligeglad. Browser-abonnementet overlever afinstallationen, hvilket gør det til den eneste push-kanal, der kan køre genaktiveringen.
Når app-push-notifikationer vinder
Og fire situationer, hvor app-push-notifikationer er værd at den højere anskaffelsespris.
Logget ind, spillere med høj LTV. App-sessioner er godkendte sessioner. Det betyder, at app-push-notifikationer kan knyttes til reel identitet: indbetalingstier, yndlingsliga, spilhistorik, sessionens aktualitet. Web-push kan også segmentere på adfærd, men appens identitetsgraf er som standard rigere. For de spillere, der driver det meste af din omsætning, vinder den dybde.
Deep links. En app-push kan lande en spiller to tryk fra en kupon, en specifik markedsplads eller et ufærdigt KYC-trin. Et klik på en web-push lander på en URL, hvilket er kraftfuldt, men overfladisk. Når målet er “færdiggør det, du startede”, er deep link forskellen mellem et skub og en fuldført handling.
Rige medier og handlinger. Native notifikationer bærer billeder, udvidede layouts og handlingsknapper med færre rendering-overraskelser end browser-ækvivalenten. Cashout-prompter og live-score-opdateringer ser simpelthen bedre ud native.
iOS-rækkevidde. Den afgørende. APNs når enhver iPhone-spiller, der har opt-in. For en bookmaker med mange iPhones alene retfærdiggør dette app-kanalen, og guide til opsætning til fastholdelse for betting-apps gennemgår, hvordan man sætter den op korrekt.
Portabilitet: web-push er bundet til oprindelse, mobile push-notifikationer rejser med dig
Én strukturel forskel betyder mere, jo længere du opererer, fordi den bestemmer, hvad du beholder, når tingene ændrer sig.
Et web-push-abonnement oprettes mod én præcis oprindelse. Kør en multi-brand portefølje, regionale domæner eller en planlagt migrering, og hver oprindelse er sit eget abonnentunivers, medmindre du designer omkring det. Løsningen er at forankre abonnementer til én stabil oprindelse på tværs af flere domæner, så listen samles i stedet for at fragmenteres. Valg af leverandør er også formet af oprindelsen: tilladelse tilhører dit domæne, ikke din udbyder, hvilket er grunden til, at du kan skifte push-notifikationsudbydere uden en ny tilladelsesprompt, og hvorfor abonnementer indsamlet på en leverandørs underdomæne er det eneste, ingen kan flytte.
Mobile push-notifikationer har ingen sådan forankring. APNs-certifikater lever i din Apple-udviklerkonto; dit FCM-projekt lever i din Google-konsol. Tokens er dine, de eksporteres rent, og migrering af en iOS-app væk fra Firebase-baseret afsendelse kræver ingen geninstallation og ingen anden prompt. Roter webdomæner, som du vil; din app-målgruppe bemærker det aldrig.
Operatørens konklusion: mobile push-notifikationer er den mere bærbare ressource, og web push bliver kun holdbar, når du ejer abonnementsoprindelsen. Opsæt begge bevidst, og hverken migrering eller en rebranding koster dig en liste.
Hvorfor iGaming push-notifikationer skal køre fra ét dashboard
Efterhånden er mønsteret synligt: hver svaghed i en kolonne i tabellen er en styrke i den anden. Web push har rækkevidde og ingen installationsfriktion; app push har dybde og iOS. Web overlever afinstallationer; app overlever domæneændringer. At køre én kanal betyder at acceptere dens blinde vinkel som permanent.
At køre begge fra separate værktøjer skaber dog et andet problem: den samme spiller bliver to optegnelser. Frekvensbegrænsninger taler ikke med hinanden, så din bedste kunde får derby-promoen to gange. Og fejltilstanden for ansvarligt spil er værre end marketing-fejltilstanden. En selvudelukket spiller skal undertrykkes overalt på én gang. I en siloopdelt stak lander undertrykkelse på weblisten, mens app-tokenet fortsætter med at sende. Det er ikke en hypotetisk revisionsfund; det er standardadfærden for to usammenhængende værktøjer.
Dette er det ærlige argument for, at iGaming push-notifikationer kører fra et enkelt dashboard med forenede segmenter, og det er, hvad PushEngage er bygget til at gøre: web- og app-push på én abonnentidentitet, delte segmenter, cross-channel frekvensbegrænsninger, stille timer og én undertrykkelsesliste, som begge kanaler respekterer. Ingen hastighedsindramning på indbetalingsprompter og ingen jagt på tab ved at vinde tilbage er kampagnebeslutninger, men de holder kun, hvis hver kanal håndhæver dem sammen.
Skala er ikke spørgsmålet her. Betting- og spilsider på PushEngage har sendt over 3,5 milliarder notifikationer. Hvad der adskiller operatører inden for dette volumen er målretning: den mediane betting-sideafsender ser ~2,1% CTR på viste notifikationer; den øverste decil klarer 6,9% — cirka tredobbelt. Den kløft er en målretningskløft, ikke en kanalkløft, og forenede segmenter på tværs af begge kanaler er, hvordan du lukker den.
Hvilken push-kanal skal en betting-operatør bygge først?
Hvis du tager én ting fra denne sammenligning af web push vs. app push, så tag beslutningsreglerne snarere end en dom.
| Din situation | Start med |
|---|---|
| Ingen app endnu, eller app under gennemgang | Web push, i dag |
| Desktop-tung eller pre-registreringsmålgruppe | Web-push |
| iPhone-tung målgruppe, app installeret | App-push |
| Høj-LTV loggede faste kunder | App push, dybt linket |
| Multi-brand portefølje eller migrering forude | Web push på en stabil oprindelse, plus app push |
| Begge kanaler, to leverandører | Konsolider til ét dashboard |
For de fleste operatører er slutresultatet af et iGaming push-notifikationsprogram begge kanaler, én abonnentidentitet, ét sæt segmenter og én undertrykkelsesliste. Ingen af kanalerne erstatter den anden; hver dækker den andens fejltilstand.
Hvis du vil se, hvordan det ser ud i praksis, kører app push-notifikationer på PushEngage ved siden af web push fra den samme kampagnebygger, og prissætningen er baseret på aktive abonnenter, så en inaktiv installationsbase ikke puster regningen op. Hver betalt plan har en 14-dages pengene-tilbage-garanti, hvilket betyder, at du kan bevise to-kanalsopsætningen på din egen trafik, før beslutningen er endelig.
