Push notifikace: navrhněte retenční kampaň, která má důvod přijít

01Začněte činností, ke které se má uživatel vrátit

Retenci definujte podle produktu. U aplikace pro pravidelné objednávky může jít o další dokončenou objednávku v určitém období. U pracovního nástroje o vyřízení úkolu, u vzdělávání o pokračování v rozpracované lekci. Pouhé otevření aplikace se hodí jako dílčí signál, ale samo nedokládá, že služba člověku pomohla.

Sepište jednu hypotézu: „Lidé, kteří dokončili první rezervaci, si díky včasné připomínce snáze uloží oblíbené místo a při další potřebě se vrátí.“ Oddělte okamžitý cíl od pozdějšího přínosu. Uložení místa můžete změřit brzy; skutečný další návrat vyžaduje delší sledování. Bez tohoto rozdílu snadno vyhlásíte úspěch po několika kliknutích.

Vyberte jednu kampaň a jednoho vlastníka. Určete, kdo schvaluje obsah, kdo kontroluje segment a kdo může rozesílání zastavit. Do zadání napište také minimální podmínky produktu: oblíbené místo musí jít uložit, odkaz se musí otevřít ve správné obrazovce a změna musí zůstat uložená po dalším přihlášení.

• Komu zpráva řeší konkrétní potřebu a v jaké situaci?
• Jakou činnost má usnadnit a jak poznáme její dokončení?
• Která událost připomínku zruší ještě před odesláním?
• Jak dlouho musíme sledovat výsledek, aby odpovídal obvyklému použití?

02Segment a oprávnění tvoří vstupní podmínky

Segment není jen seznam lidí, kteří poslední týden aplikaci neotevřeli. Zvažte stav jejich práce, poslední relevantní událost a očekávanou četnost použití. Zákazník objednávající servis jednou za několik měsíců není po sedmi dnech automaticky ztracený. Nový uživatel, který nepochopil první krok, potřebuje jinou pomoc než zkušený člověk s hotovým úkolem.

Vylučte lidi, kteří už cílovou akci dokončili, zrušili účet nebo upozornění vypnuli. Pravidla ověřujte těsně před odesláním, nejen při sestavení segmentu. Mezi plánováním a rozesláním se může změnit objednávka, dostupnost služby i nastavení uživatele. U sdíleného zařízení se zpráva nesmí řídit zastaralým přihlášením jiné osoby.

Technické povolení systému posuzujte samostatně od oprávnění použít data a od pravidel konkrétního obchodního sdělení. Tlačítko „Povolit oznámení“ nepopisuje účel všech budoucích kampaní. Zvlášť evidujte uživatelské volby pro marketing a provozní informace, jejich změny a způsob odhlášení. Právní posouzení přizpůsobte obsahu a vztahu se zákazníkem, ne pouze názvu kanálu.

03O povolení žádejte v okamžiku srozumitelné hodnoty

Na Androidu 13 a vyšším je pro běžná nevyňatá oznámení vyžadováno runtime oprávnění. Dokumentace doporučuje žádat v kontextu funkce, například po objednávce nebo stisku zvonku. Nezakrývejte systémový dotaz slibem, že odmítnutí znemožní používat celý produkt, pokud to není skutečná technická nutnost.

Apple rovněž doporučuje kontextovou žádost. Standardní první žádost zobrazí systémový dialog, další stejné žádosti už nevyvolají nový dotaz. Dokumentace popisuje i prozatímní oprávnění pro tichá oznámení. Je to odlišný režim, nikoli univerzální náhrada uživatelské volby nebo právního titulu kampaně.

V aplikaci vysvětlete konkrétní užitek: „Upozorníme vás, když bude možné dokončit rezervaci.“ Po odmítnutí nechte člověka pokračovat a nabídněte srozumitelnou správu preferencí. Stav oprávnění průběžně aktualizujte. Člověk může systémové nastavení změnit mimo aplikaci; údaj zaznamenaný při instalaci proto nemusí platit dnes.

Na Androidu lze oddělit typy oznámení do kanálů, jejichž viditelnost a vyrušování řídí také uživatel. Navrhněte srozumitelné kategorie. Směšování informací o objednávce a všech akcí do jediné hlučné skupiny komplikuje možnost ponechat si jen potřebné zprávy.

04Rozhodněte, zda zpráva opravdu potřebuje push

Někdy je nejlepší zprávu vůbec neposlat. Když člověk aplikaci právě používá, může další krok vysvětlit přímo obrazovka. Když služba přirozeně funguje jen občas, neaktivita nemusí znamenat problém. Rozhodnutí „neodeslat“ evidujte jako správný výsledek pravidla, ne jako selhání marketingu.

05Omezte součet vyrušení a nastavte platnost

Limit nastavujte přes celou aplikaci. Tři týmy mohou jednotlivě poslat jednu rozumnou zprávu, ale zákazník dostane tři upozornění v krátkém sledu. Centrální pravidlo má znát provozní i retenční komunikaci, její prioritu a možnosti sloučení. Frekvenci volte podle potřeby produktu; neexistuje jedno bezpečné číslo pro všechny aplikace.

Dohodněte klidové období v místním čase uživatele a chování při cestování nebo změně časového pásma. Běžnou připomínku můžete odložit nebo zahodit, když odklad zruší její význam. Skutečně časově důležitou provozní zprávu posuzujte samostatně. Z naléhavosti obchodního plánu nedělejte naléhavost pro zákazníka.

Firebase Cloud Messaging umožňuje určit životnost zprávy. Na Androidu a webu se nastavuje TTL, pro iOS dokumentace odkazuje na APNs expiration. Pokud zařízení není dostupné, může doručení přijít později. Uvolněný termín, který už obsadil jiný člověk, proto nemá zůstat platnou výzvou.

Před odesláním kontrolujte aktuální stav a po kliknutí jej ověřte znovu. Když nabídka mezitím vypršela, ukažte lidské vysvětlení a dostupnou alternativu. Neposílejte člověka na prázdnou stránku. Přidělte kampani identifikátor, který pomůže dohledat obsah, příjemce, rozhodnutí pravidel a případné opakování.

06Text a otevřená obrazovka musí splnit stejný slib

Napište, co se změnilo a co lze udělat. „Pokračujte v rozpracované rezervaci“ je konkrétnější než „Něco vám uniká“. Když připomínáte uložený zájem, ověřte, že je obsah stále relevantní. Nepoužívejte falešnou naléhavost ani výčitky za neaktivitu. Text má člověku usnadnit rozhodnutí, nikoli zakrýt skutečnou nabídku.

Odkaz musí otevřít správné místo po přihlášení i při vypnuté aplikaci. Otestujte nový účet, více účtů, chybějící připojení, starší podporovanou verzi a už dokončenou činnost. U citlivé informace použijte neutrální náhled a detail zobrazte až po odpovídajícím ověření. Úspěšné doručení neznamená bezpečné zobrazení.

Modelový návrh může obsahovat dvě varianty stejného sdělení, ale testujte jednu významnou změnu. Když najednou změníte text, příjemce, čas i obrazovku, získáte těžko vysvětlitelný výsledek. Zaznamenejte přesnou podobu variant. Potřebujete vědět, co lidé skutečně viděli, ne jen dnešní přepis šablony.

07Retenci vyhodnocujte s kontrolní skupinou

Porovnejte vhodně rozdělené skupiny způsobilých lidí. Jedné odešlete retenční připomínku, druhá ji nedostane. Důležité provozní zprávy jim kvůli testu neodebírejte. Sledujte stejný časový horizont a stejné cílové chování. Srovnání lidí s povoleným push a lidí bez povolení samo o sobě příčinu neprokáže, protože tyto skupiny se mohou lišit už před kampaní.

Vyhodnocujte dokončení cílové akce, opakované použití a náklady. Vedle toho kontrolujte vypnutí daného typu upozornění, dostupné signály zrušení oprávnění a stížnosti. Odinstalace nebývají pro každou aplikaci přímo a úplně pozorovatelné. Omezení měření přiznejte a neslibujte přesnost, kterou váš nástroj neposkytuje.

Doručení, zobrazení, otevření a následná akce jsou různé kroky. Před výpočtem míry otevření definujte jmenovatel a dostupnost jednotlivých událostí. Údaj o odeslání není údaj o přečtení. Měřte také chyby segmentace a neplatné odkazy, protože bez nich může vypadat špatně i užitečná myšlenka.

Modelový příklad: rezervaci dokončí část lidí i bez připomínky, protože ji potřebují. Počet dokončení po otevření zprávy proto není celý přínos kampaně. Kontrolní skupina pomáhá odhadnout, co by se stalo bez ní. Pokud se obě skupiny vracejí podobně, vysoký počet otevření nemusí ospravedlnit další vyrušování. Výsledek vždy interpretujte s ohledem na velikost skupin, náhodnou nejistotu a délku sledování.

Pravidelně zkontrolujte i výběr příjemců. Kampaň může vypadat úspěšně jen proto, že se do ní nově dostali lidé s větší motivací. Udržujte pravidla segmentu a rozdělení během testu srozumitelná. Změnu dostupnosti služby nebo větší souběžnou akci zaznamenejte, aby závěr nestál na chybném předpokladu stejného prostředí.

Předem stanovte, co povede k zastavení nebo úpravě kampaně. Při malém počtu příjemců nevyvozujte vítěze z několika dokončení. První pilot může sloužit hlavně k ověření pravidel a kvality dat. Širší práci s návraty popisujeme v průvodci retencí aplikace.

08Nejčastější otázky k retenčním push kampaním