Spletna potisna obvestila

Kako meriti prihodek iz spletnih potisnih obvestil

Posted on July 18, 2026 by

Za merjenje prihodka iz spletnih potisnih obvestil potrebujete tri stvari: sledilni parameter na vsaki povezavi v obvestilu, jasno določeno okno pripisovanja, s katerim se dejansko strinjate, in poročilo, ki prikazuje naročila na obvestilo — ne le klikov. Delovna metrika je prihodek na 1.000 poslanih obvestil, preverjena s tem, kar vaše analitično orodje pokaže o prometu iz potisnih obvestil. Kliki sami po sebi povedo le, da je bilo sporočilo zanimivo. Ničesar ne povedo o tem, ali se je motnja, ki jo je povzročilo, splačala. Ta članek vas popelje skozi nastavitev, metrike, ki jih je vredno spremljati, in dve mesti, kjer številke o prihodku iz potisnih obvestil redno lažejo: napihnjeno število dostavljenih sporočil in dvojno pripisovanje.

Težava: potisna obvestila izgledajo bodisi fantastično bodisi ničvredno, odvisno od tega, kdo šteje

Večina lastnikov trgovin, s katerimi se pogovarjam, spada v enega od dveh taborov. Prvi je odprl nadzorno ploščo svojega orodja za potisna obvestila, poleg vsake kampanje zagledal številko prihodka in sklenil, da potisna obvestila tiskajo denar. Drugi je odprl Google Analytics, pod prometom iz potisnih obvestil našel skoraj nič prihodka in potihem prenehal pošiljati.

Oba bereta resnične številke. Obe številki sta zavajajoči, vsaka v svojo smer.

Vaša platforma za potisna obvestila želi zasluge za vsako naročilo, ki ga lahko verjetno pripiše sebi, zato pripisuje radodarno — pogosto vsakomur, ki je kliknil (ali včasih zgolj prejel) obvestilo in kupil znotraj večdnevnega okna. Vaše analitično orodje pa naročilo običajno pripiše zadnjemu kliku, tako da se kupec, ki je v torek kliknil vaše obvestilo in se v četrtek vrnil prek Googlovega iskanja, prikaže kot organski prihodek. Resnica leži nekje vmes, kanala pa ne morete voditi, kadar vaša ocena njegove vrednosti niha za faktor pet, odvisno od tega, kateri zavihek je odprt.

Zakaj “samo poglej na nadzorno ploščo” ni dovolj

Številka na nadzorni plošči ima dve strukturni pomanjkljivosti, ki ju je dobro poznati, preden ji zaupate.

Dostavljeno ne pomeni videno. Spletno potisno obvestilo šteje za dostavljeno, ko ga prejme brskalnik. A brskalniki prejemajo obvestila na zaklenjene zaslone, zaprte prenosnike in v obvestilne centre, ki jih uporabnik zbriše, ne da bi jih prebral. Vaš imenovalec “dostavljeno” je torej napihnjen, zaradi česar vsaka stopnja na dostavljeno obvestilo izgleda slabše od resničnosti — in kar je še bolj nevarno, trendi postanejo šumni, saj se delež resnično videnih obvestil spreminja z navadami vašega občinstva, ne z vašo vsebino.

Okna pripisovanja so odločitev, ne dejstvo. Če vaša platforma potisnim obvestilom pripiše vsako naročilo, oddano znotraj recimo treh dni od klika, bo posrkala prihodek, ki so ga v resnici prinesli e-pošta, oglasi ali zgolj navada. Pošljite potisno obvestilo in e-pošto o isti akciji istim ljudem in oba kanala si lahko lastita isto naročilo. Preverite, kakšno okno in kakšno logiko uporablja vaše konkretno orodje — to se razlikuje med platformami in paketi, in bolje je nameniti deset minut branju dokumentacije kot ugibati.

Nobena od teh pomanjkljivosti ne pomeni, da je nadzorna plošča neuporabna. Pomeni le, da je nadzorna plošča zgornja meja.

Kje signal o prihodku dejansko pušča

Takole izgleda praktična slika. Klik na obvestilo sproži svežo sejo brskalnika, običajno v novem zavihku. Od tega trenutka lahko obiskovalcu sledite kot vsakemu drugemu viru prometa — če je povezava nosila sledilne parametre. Večina trgovin izgubi signal ravno tam: obvestila gredo ven z golimi URL-ji izdelkov, seja pristane kot neposredni promet, naročilo, ki sledi, pa je za vedno nepripisljivo.

Drugo puščanje je časovna razdalja. Nakupi, ki jih poženejo potisna obvestila, se pogosto ne zaključijo v seji klika. Nekdo med kosilom na telefonu klikne opozorilo o padcu cene, nato pa zvečer dokonča naročilo na prenosniku — na napravi, kjer sploh nikoli ni bil naročen na potisna obvestila. Analitika zadnjega klika teh pik nikoli ne bo povezala. Okno vaše platforme jih morda. Prav zato želite obe številki in navado, da ju berete skupaj.

Vzpostavitev meritev, ki jim lahko zaupate

Naredite te štiri stvari, v tem vrstnem redu.

1. Na vsako povezavo v obvestilu dodajte parametre UTM. Nekaj takega kot utm_source=push&utm_medium=notification&utm_campaign=price-drop-june. Zdaj lahko GA4 (ali karkoli že uporabljate) izolira seje iz potisnih obvestil, njihovo stopnjo konverzije in njihov prihodek. Brez tega nič dolvodno ne deluje.

2. Enkrat določite svoje stališče glede pripisovanja in ga zapišite. Moje lastno pravilo: naročilo štejem kot prihodek iz potisnih obvestil, če je prišlo v seji klika ali istega dne od istega obiskovalca. Vse poznejše obravnavam kot pripomoglo, ne prisvojeno. Lahko potegnete drugačno mejo — bistvo je, da izberete eno in nehate o njej vsak mesec razpravljati.

3. Zgradite eno poročilo na avtomatizacijo, ne ene zmešane številke. Potisno obvestilo ob zapuščeni košarici in tedenski promocijski razpošiljki sta različna posla. Obvestilo o košarici lahko prinese 4 € na obvestilo, razpošiljka pa 0,03 €, in zmešano povprečje skrije oba podatka. Razčlenite po sprožilcu. Če se še odločate, kateri sprožilci sploh zaslužijo potisno obvestilo, začnite pri kdaj naj trgovina pošlje potisno obvestilo.

4. Spremljajte tudi stolpec s stroški. Potisna obvestila nimajo stroška na poslano sporočilo kot SMS, a niso zastonj: vsako obvestilo porabi pozornost naročnika, viden strošek pa so odjave. Kampanja, ki je zaslužila 200 € in porabila 300 naročnikov, je lahko izguba, ko ovrednotite, koliko bi ti naročniki kupili v naslednjem letu.

Metrike, ki so pomembne, in tiste, ki niso

Štiri številke pokrijejo skoraj vse:

Prihodek na 1.000 poslanih — glavna metrika, primerljiva med kampanjami in meseci.
Stopnja klikov — presoja sporočilo. Uporabna za testiranje, neuporabna kot merilo uspeha sama zase.
Stopnja konverzije sej iz potisnih obvestil — presoja, kaj se zgodi po kliku. Če so kliki v redu, ta pa je skoraj nič, je težava na strani spletne strani, ta način odpovedi pa ima svojo diagnozo v članku zakaj potisna obvestila ustvarjajo klike, vendar ne naročil.
Stopnja odjav na poslano sporočilo — vaša postavka stroškov. Spremljajte trend, ne posameznih pošiljanj.

Metriko “stopnja dostave” bi kot merilo uspešnosti povsem preskočil, iz zgoraj navedenih razlogov, celotni prihodek, ki ga pripiše platforma, pa bi obravnaval kot zgornjo mejo za preverjanje smiselnosti, ne kot rezultat za poročanje.

Rešen primer (za ponazoritev)

Recimo, da pošljete obvestilo o vrnitvi zaloge 8.000 naročnikom. 240 jih klikne (3 %). Od teh sej jih 12 kupi pri povprečnem naročilu 55 € — 660 €, ali približno 82 € na 1.000 poslanih. Nadzorna plošča vaše platforme trdi 1.900 €, ker je njeno tridnevno okno pobralo naročila ljudi, ki so prejeli tudi e-pošto o vrnitvi zaloge. GA4 pokaže 510 €, ker se je nekaj kupcev pozneje vrnilo prek iskanja.

Nobena od teh številk ni lažna. Številka 660 € iz iste seje je tista, ki bi si jo zapisal, razpon med platformo in analitiko pa bi zabeležil kot grobo mero prekrivanja z drugimi kanali. Vse številke tukaj so zgolj za ponazoritev — vaše stopnje so odvisne od kakovosti seznama, izdelka in cenovnega razreda.

Kaj avtomatizirati okoli meritev

Same meritve so lahko večinoma nastavi-in-pozabi:

Označevanje: enkrat pripravite predlogo strukture UTM, da jo vsako obvestilo podeduje — ime kampanje iz imena avtomatizacije, brez ročnega tipkanja.
Segmentirano poročanje: od prvega dne obdržite avtomatizirana obvestila (košarica, opustitev brskanja, padec cene) v ločenih poročilih od ročnih kampanj.
Sprožilec za mesečni pregled: ponavljajoč se termin v koledarju, kjer primerjate prihodek na 1.000 poslanih in trend odjav med avtomatizacijami ter ukinete ali popravite najslabšo.

Kako to obravnava Omnisend

Potisna obvestila v svojih trgovinah poganjam prek Omnisenda, predvsem zato, ker drži e-pošto, SMS in spletna potisna obvestila na enem mestu — kar je pri prav tej temi izjemno pomembno. Ko vsi trije kanali živijo na eni platformi, ta lahko vidi, da je isti kupec prejel e-pošto in obvestilo, prihodek po avtomatizaciji pa lahko berete drug ob drugem, namesto da bi se prepirali med tremi nadzornimi ploščami. Poročanje prikazuje prodajo, pripisano vsakemu delovnemu toku in sporočilu, tako da je gradnja pogleda po avtomatizacijah iz koraka 3 večinoma klikanje po vmesniku namesto izvažanja preglednic.

Poštena zadržka: prihodek, ki ga pripiše Omnisend, je še vedno pripisovanje platforme, zato ga navzkrižno preverjam z GA4 natanko tako, kot je opisano zgoraj, vi pa preberite, kako deluje njihovo okno pripisovanja na vašem paketu, namesto da bi se zanašali na moj spomin. Nobeno orodje ne popravi neoznačene povezave ali zmešanega poročila, ki ga nikoli ne pogledate.

Vaš naslednji korak

Odprite svojih zadnjih pet kampanj potisnih obvestil in preverite, ali so povezave nosile parametre UTM. Če jih niso, popravite predlogo še danes — vsako pošiljanje do takrat je prihodek, ki ga nikoli ne boste mogli prisvojiti ali se iz njega kaj naučiti. Ko so podatki čisti, jih poženite v delo: začnite A/B-testirati svoja potisna obvestila, da bo številka prihodka na 1.000 imela kam iti le še navzgor.

Web Push Notifications

How to Measure Revenue From Web Push Notifications

Posted on July 17, 2026 by

To measure revenue from web push, you need three things: a tracking parameter on every notification link, a defined attribution window you actually agree with, and a report that shows orders per notification — not just clicks. The working metric is revenue per 1,000 notifications sent, checked against what your analytics tool says landed from push traffic. Clicks alone tell you the message was interesting. They say nothing about whether it paid for the interruption. This article walks through the setup, the metrics worth watching, and the two places where push revenue numbers routinely lie to you: inflated delivery counts and double-counted attribution.

The problem: push looks either amazing or worthless, depending on who’s counting

Most store owners I talk to sit in one of two camps. The first opened their push tool’s dashboard, saw a revenue figure next to each campaign, and concluded push is printing money. The second opened Google Analytics, found almost no revenue under push traffic, and quietly stopped sending.

Both are reading real numbers. Both numbers are misleading in different directions.

Your push platform wants credit for every order it can plausibly claim, so it attributes generously — often anyone who clicked (or sometimes merely received) a notification and bought within a multi-day window. Your analytics tool, meanwhile, usually hands the sale to the last click, so a customer who clicked your push on Tuesday and came back through a Google search on Thursday shows up as organic revenue. The truth sits between the two, and you can’t manage a channel when your estimate of its value swings by a factor of five depending on which tab is open.

Why “just check the dashboard” isn’t enough

The dashboard number has two structural weaknesses you should know about before trusting it.

Delivered doesn’t mean seen. A web push notification counts as delivered when the browser receives it. But browsers receive notifications onto locked screens, closed laptops, and into notification centers the user clears without reading. So your “delivered” denominator is inflated, which makes every per-delivery rate look worse than reality — and, more dangerously, makes trends noisy, because the share of truly-seen notifications shifts with your audience’s habits, not your content.

Attribution windows are a choice, not a fact. If your platform credits push with any order placed within, say, three days of a click, it will absorb revenue that email, ads, or plain habit actually drove. Send push and email about the same sale to the same people and both channels may claim the same order. Check what window and what logic your specific tool uses — this varies by platform and plan, and it’s worth ten minutes to read the documentation rather than guessing.

Neither weakness means the dashboard is useless. It means the dashboard is an upper bound.

Where the revenue signal actually leaks

Here’s the practical picture. A push click starts a fresh browser session, usually in a new tab. From that moment you can follow the visitor like any other traffic source — if the link carried tracking parameters. Most stores lose the signal right there: notifications go out with bare product URLs, the session lands as direct traffic, and the order that follows is unattributable forever.

The second leak is timing. Push-driven purchases often don’t complete in the click session. Someone taps a price-drop alert on their phone during lunch, then finishes the order on a laptop that evening — a device where they were never a push subscriber at all. Last-click analytics will never connect those dots. Your platform’s window might. This is exactly why you want both numbers and a habit of reading them together.

Setting up measurement that you can trust

Do these four things, in this order.

1. Put UTM parameters on every push link. Something like utm_source=push&utm_medium=notification&utm_campaign=price-drop-june. Now GA4 (or whatever you run) can isolate push sessions, their conversion rate, and their revenue. Without this, nothing downstream works.

2. Decide your attribution stance once and write it down. My own rule: I count an order as push revenue if it came in the click session or same-day from the same visitor. Anything later I treat as assisted, not owned. You can pick a different line — the point is to pick one and stop re-litigating it every month.

3. Build one report per automation, not one blended number. An abandoned-cart push and a weekly promo blast are different businesses. The cart push might drive €4 per notification while the blast drives €0.03, and a blended average hides both facts. Break it out by trigger. If you’re still deciding which triggers deserve a push at all, start with when a store should send a push notification.

4. Track the cost column too. Push has no per-send fee like SMS, but it isn’t free: every notification spends subscriber attention, and the visible cost is opt-outs. A campaign that made €200 and burned 300 subscribers may be a loss once you price what those subscribers would have bought over the next year.

The metrics that matter, and the ones that don’t

Four numbers cover almost everything:

Revenue per 1,000 sent — the headline metric, comparable across campaigns and months.
Click rate — judges the message. Useful for testing, useless as a success metric on its own.
Conversion rate of push sessions — judges what happens after the click. If clicks are fine but this is near zero, the problem is on the site side, and that failure mode has its own diagnosis in why push notifications get clicks but no orders.
Opt-out rate per send — your cost line. Watch the trend, not single sends.

I’d skip “delivery rate” as a performance metric entirely, for the reasons above, and I’d treat the platform’s total attributed revenue as a ceiling to sanity-check, not a result to report.

A worked example (illustrative)

Say you send a back-in-stock notification to 8,000 subscribers. 240 click (3%). Of those sessions, 12 buy at an average order of €55 — €660, or about €82 per 1,000 sent. Your platform dashboard claims €1,900 because its three-day window scooped up orders from people who also got the back-in-stock email. GA4 shows €510 because a few buyers returned later through search.

None of these numbers is fake. The €660 same-session figure is the one I’d write down, and I’d note the platform-to-analytics spread as a rough measure of overlap with other channels. All figures here are illustrative — your rates depend on list quality, product, and price point.

What to automate around measurement

Measurement itself can be mostly set-and-forget:

Tagging: template your UTM structure once so every notification inherits it — campaign name from the automation name, no manual typing.
Segmented reporting: keep automated pushes (cart, browse abandonment, price drop) in separate reports from manual campaigns from day one.
A monthly review trigger: a recurring calendar slot where you compare revenue per 1,000 sent and opt-out trend across automations, and cut or fix the worst performer.

How Omnisend handles this

I run push through Omnisend in my own stores, mainly because it keeps email, SMS, and web push in one place — which matters enormously for this exact topic. When all three channels live in one platform, the platform can see that the same customer got the email and the push, and you can read per-automation revenue side by side instead of arguing between three dashboards. The reporting shows sales attributed to each workflow and message, so building the per-automation view from step 3 is mostly clicking around rather than exporting spreadsheets.

The honest caveats: Omnisend’s attributed revenue is still platform attribution, so I cross-check it against GA4 exactly as described above, and you should read how their attribution window works on your plan rather than taking my memory for it. No tool fixes an untagged link or a blended report you never look at.

Your next step

Open your last five push campaigns and check whether the links carried UTM parameters. If they didn’t, fix the template today — every send until then is revenue you’ll never be able to claim or learn from. Once the data is clean, put it to work: start A/B testing your push notifications so the revenue-per-1,000 number has somewhere to go but up.