In-app előfizetés fájdalom nélkül

Miért nehezebb az előfizetés, mint amilyennek látszik

A happy path – a felhasználó rányom a vásárlásra, felugrik a store dialógusa, feloldódik a funkció – egyheti munka. Az igazi projekt minden, ami e köré épül: a nem hamisítható receipt-ellenőrzés, a vásárlások visszaállítása egy új telefonon, az a felhasználó, aki iOS-en fizetett elő, de Androidon nyitja meg az appot, a visszatérítések, a billing-retry türelmi idők, a családi megosztás, a lejárt bankkártyák – és mindezek store-specifikus furcsaságai két olyan platformon, amelyek egészen másképp modellezik az előfizetést.

Ha ezekből valamit elrontasz, a hibának van egy kellemetlen tulajdonsága: vagy egy fizető felhasználót zár ki abból, amiért fizetett, vagy egy nem fizetőnek adja ingyen a terméket. Mindkettő valódi pénzbe és bizalomba kerül, és mindkettőről jellemzően nem hibajegyből, hanem egycsillagos értékelésből értesülsz.

Miért RevenueCatet használunk saját megoldás helyett

Az előfizetéses appjainkban – köztük az Invoice Guruban – a RevenueCat az előfizetési réteg, nem közvetlenül a StoreKittel és a Google Play Billinggel beszélünk. Az indoklás ugyanaz a „megépítsük vagy megvegyük” logika, amit mindenhol követünk: ez a réteg nem különbözteti meg a terméket, minden appban ugyanaz, viszont rengeteg benne a határeset – és ezeket egy erre szakosodott szolgáltató mindig jobban fogja kezelni, mint egy termékcsapat:

• —Egyetlen API a két store fölött – az entitlementek („van-e pro csomagja ennek a felhasználónak?”) kiváltják a platformspecifikus receipt-logikát az app kódjában
• —Szerveroldali receipt-ellenőrzés alapból – az az ellenőrzés, amit a felhasználó nem tud meghamisítani, saját validációs backend nélkül
• —Platformok közötti entitlementek – iOS-en fizetsz elő, Androidon is megmarad a hozzáférésed, egyedi fiókösszekötés nélkül
• —A határeseteket – türelmi idők, visszatérítések, upgrade-ek, vásárlás-visszaállítások – egyszer oldják meg olyanok, akiknek az egész terméke pontosan ezekről szól
• —Bevételi analitika és churn-adatok ingyen – az üzleti oldal a launch utáni héten úgyis kérni fogja

A store-szabályok, amelyekhez igazodnod kell

Digitális termékre előfizetést csak a store-ok saját in-app vásárlási rendszerén keresztül lehet árulni. Ha appon belüli külső fizetési linkkel próbálod megkerülni az Apple jutalékát, az előbb-utóbb elutasításba – vagy az app eltávolításába – torkollik. A jutalék pedig nem elhanyagolható: alapesetben 30%, a kisvállalkozói programokon keresztül a legtöbb kis cégnek 15%. Ezt az árazási modellnek az első naptól bele kell kalkulálnia, nem az első kifizetésnél kell szembesülni vele.

A store-ok magát az előfizetési UX-et is szabályozzák: mit kell feltüntetnie egy paywallnak, hogyan alakul át a próbaidőszak fizetős előfizetéssé, hogyan kell működnie a lemondásnak. Különösen az Apple utasít el rendszeresen appokat olyan paywall miatt, amely elrejti az árat vagy a megújítás feltételeit. Az átlátható paywall pedig nemcsak a szabályoknak felel meg: mérhetően jobban is konvertál, mint a trükkös.

Terméktanácsok, amelyek a technikai réteget is túlélik

A technikai réteget meg lehet venni, a termékdöntéseket nem. Hogy mi marad örökre ingyenes, mi kerül az előfizetés mögé, és a felhasználói út melyik pontján bukkan fel a paywall – ezek jobban meghatározzák a bevételt, mint bármelyik implementációs részlet. Az általános tanácsunk: hagyd, hogy a felhasználó a paywall előtt megtapasztalja az app lényegét. Aki már kiállította az első számláját, tudja, miért fizet; aki az első indításkor falba ütközik, nem. Az árat a nyújtott értékhez szabd, ne a saját költségeidhez. És az első naptól mérj mindent, mert a paywall helye csak egy hipotézis, amit később úgyis felülvizsgálsz.