Sestav sekvenci pro konverzi zkušebních verzí podle chování uživatelů v produktu: aktivační událost, jeden úkol na e-mail, kontrola podmínek a testy ukončení.
E-mail, který má zkušební verzi proměnit v placený účet, by měl reagovat na to, co uživatel udělal. Kdo ještě nezaložil projekt, potřebuje pomoct s nastavením. Kdo produkt používá každý den, potřebuje jasné vysvětlení placeného tarifu. Když oběma pošleš stejné odpočítávání, tenhle rozdíl ti unikne.
Tento návod odděluje návrh sekvence od aplikační logiky, která rozhoduje, kdo má jednotlivé e-maily dostat.
Vyber jednu akci, která ukazuje, že uživatel v produktu dosáhl prvního užitečného výsledku. Musí být dost konkrétní, aby ji tvůj backend dokázal zaznamenat: založený projekt, dokončený import nebo pozvaný kolega. Zobrazení stránky samo o sobě málokdy stačí.
Čas registrace, konec zkušební verze, aktivaci a to, jestli účet platí, zaznamenávej v systému, který je u těchto faktů zdrojem pravdy. Pole kontaktu v e-mailové platformě ber jako synchronizovaná data, ne jako důkaz, že dřívější sekvence čte aktuální stav.
| Zpráva | Kdy se hodí | Podmínka ověřená v okamžiku odeslání |
|---|---|---|
| Uvítání | Po registraci nebo ověření | Účet existuje a smí tuto zprávu dostat |
| Pomoc s nastavením | Zhruba o dva dny později, podle tvého produktu | Zatím bez aktivace |
| Další užitečná akce | Po aktivaci | Aktivace proběhla, tato akce zatím ne |
| Konec zkušební verze | Před skutečným koncem zkušební verze | Zkušební verze pořád běží a účet není placený |
| Závěrečný dotaz, jak to jde | Po skončení zkušební verze, pokud je to vhodné | Pořád bez platby, splňuje podmínky a smí dostávat marketingové e-maily |
Tato načasování jsou výchozí body pro test, ne změřené nejúspěšnější intervaly. Uveď skutečný konec zkušební verze a co bude následovat. Nevyvolávej falešný dojem nedostatku a nenaznačuj, že dojde k platbě, když účet nemá uložený žádný platební prostředek.
V sekvenci v Brew spouštěné událostí čte payload.activated původní událost, kdežto contact.activated čte aktuální hodnotu pole kontaktu příjemce v Brew v okamžiku, kdy se provádí uzel Filtr nebo uzel podmíněného rozdělení. Pokud chceš po aktivaci připomínky nastavení přeskočit, deklaruj toto pole typu ano/ne, průběžně ho synchronizuj ze svého produktu a po každém relevantním kroku Čekání kontroluj contact.activated equals false. Pole bez hodnoty není totéž co pole s hodnotou ne, takže je otestuj zvlášť.
Tato čtení vycházejí z kontaktu uloženého v Brew, ne z databáze tvé aplikace ani z aktuálního dotazu do Stripe. Přijetí události o aktivaci nebo platbě dřívější běh automaticky nezruší. Graf proto potřebuje podmínku před každým odesláním, které závisí na stavu.
U faktů mimo Brew nech úlohu naplánovat svou aplikaci. Když nastane její čas, přečti aktuální stav účtu nebo faktury a samostatnou vlastní událost do Brew vyšli, jen pokud příjemce pořád splňuje podmínky. Do této nové události přidej aktuální data potřebná pro personalizaci.
Připomínka naplánovaná v aplikaci funguje třeba takhle:
Signup committed → fire welcome event
Reminder job becomes due → read current account
Already activated or paid → finish without firing an email event
Still eligible → fire setup-reminder event with current dataNeboli: po potvrzení registrace se vyšle uvítací událost. Když nastane čas úlohy pro připomínku, aplikace načte aktuální stav účtu. Pokud už účet prošel aktivací nebo je zaplacený, úloha skončí, aniž by vyslala událost pro e-mail; pokud pořád splňuje podmínky, vyšle událost pro připomínku nastavení s aktuálními daty.
Použij skutečné ID spouštěče, které ti Brew vrátí, a deklarované schéma spouštěče. Postupuj podle návodu k vytváření automatizací a dokumentace k typovaným schématům payloadu. Při opakovaném vysílání událostí použij zdokumentovaný mechanismus idempotence.
Pokud zkušební verzi spravuje Stripe, jeho události předplatného dodávají kontext o platbách. Integrace Stripe nabízí spouštěče pro podporované události, včetně customer.subscription.trial_will_end. Zdrojem pravdy o aktivaci v produktu ale zůstává tvoje aplikace, pokud tuto informaci neposíláš zvlášť.
U pozdější připomínky související s platbou zkontroluj aktuální záznam ve Stripe. Úspěšná aktualizace karty není důkaz, že je faktura zaplacená. Slaď to s e-maily, které posílá sám Stripe, aby zákazník ke každému účelu dostal jen jedno upozornění.
Začni skutečnou situací příjemce. Vysvětli jednu užitečnou akci a odkaž přímo na ni. E-mail s pomocí s nastavením může nabídnout krátký příklad a adresu pro odpovědi. E-mail o placeném tarifu by měl popsat relevantní limit nebo funkci a skutečnou cenu a odkázat na aktuální ceník.
Souhlas s marketingem, chování odhlášení i účel odesílací domény musí odpovídat zprávě. Registrace do zkušební verze neopravňuje k nesouvisejícím propagačním e-mailům.
Pro každou kontrolu podmínek otestuj, co se stane, když kontakt ještě před ní projde aktivací nebo zaplatí. U podmínek na kontaktu během čekání aktualizuj příslušná pole v Brew a ověř, že se připomínka přeskočí. U kontrol plánovaných v aplikaci ověř, že účty, které podmínky nesplňují, nevyvolají žádnou událost připomínky. Otestuj také opakované pokusy, prodloužení zkušební verze, smazání účtu, odhlášení a chybějící pole. Zkontroluj logy aplikace i historii běhů v Brew.
Aktivaci a konverzi na placený tarif vyhodnocuj podle dat z produktu, selhání doručení podle e-mailové platformy. Míra otevření sama neukáže, jestli sekvence uživateli ve zkušební verzi pomohla. Příklady najdeš v článku o návrhu uvítacích sekvencí a rozdělení implementace popisuje článek MCP vs. REST.
