Nachdem ich RevenueCat ausprobiert und (öffentlich) festgestellt hatte, dass es meine (zugegebenermaßen sehr hohen) Erwartungen an die Benutzerfreundlichkeit nicht erfüllt, beschloss ich, das Problem selbst anzugehen und begann mit der Arbeit an der Open-Source-Bibliothek FreemiumKit. Für mich bedeutet „Benutzerfreundlichkeit” bei einem Framework, das bei In-App-Käufen hilft, drei Dinge:
Eine klare Schritt-für-Schritt-Anleitung zum Einstieg – einschließlich App Store Connect.
Ein einfaches, aber flexibles Berechtigungssystem basierend auf den Käufen des aktuellen Nutzers.
Ein einheitliches Paywall-Design-Framework für wiederverwendbaren, gemeinsam genutzten Paywall-UI-Code.
Die ersten beiden plane ich in der README der Bibliothek abzudecken. Dieser Artikel konzentriert sich auf den dritten Aspekt: Wie hilft dir FreemiumKit, schnell eine erfolgreiche Paywall zu bauen? Und wie kann es dir bei A/B-Tests helfen?
FreemiumKit macht die StoreKit-2-Integration kinderleicht. Mit eingebauten Paywalls & Berechtigungen.
Grundidee
Eines der Dinge, die ich von RevenueCat erwartet hatte – einfach weil die Leute immer sooo positiv darüber gesprochen haben – war, dass sie fertige UI-Komponenten in ihrem Swift SDK mitliefern. Tun sie aber nicht. (UPDATE: Nach meinen Beschwerden haben sie damit angefangen!) Stattdessen integrieren sie sich mit einem anderen Dienst, der sich auf Paywalls spezialisiert hat und Nutzern hilft, ihre Paywalls durch Ausprobieren verschiedener Designs zu optimieren: Superwall. Falls du übrigens nicht weißt, was A/B-Tests sind – verschiedene Designs auszuprobieren und die Daten auszuwerten, um zu sehen, was am besten funktioniert, ist so ziemlich die Definition davon. Eine Paywall ist wahrscheinlich der wichtigste Screen, den man A/B-testen sollte. Die Idee des Dienstes gefällt mir also sehr, aber das Pricing skaliert nicht so gut nach unten: Sie verlangen 0,20 $ pro Kauf, was bei einem monatlichen Abo von 1 $ ganze 20 % deiner Einnahmen sind – das ist sogar höher als die 15 %, die Apple bei Small Businesses einbehält!
Außerdem bin ich persönlich kein Fan davon, viele Drittanbieter-Dienste zu nutzen. Ich halte meine App-Datenschutzerklärungen gerne kurz und einfach, was mit jedem neuen Dienst schwieriger wird. Daher bevorzuge ich es, einen eher „universellen” Analytics-Dienst zu wählen, der unter anderem A/B-Testing unterstützt, und diesen sorgfältig auszuwählen, statt viele Microservices zu integrieren. Aber das ist natürlich nur mein persönlicher Geschmack und du kannst dich anders entscheiden. Eine Sache gibt es allerdings, die ich an Superwall wirklich liebe: Sie betreiben die Website PaywallScreens, auf der du eine schöne Übersicht von Tausenden realer Paywalls findest, sortiert nach dem geschätzten Umsatz jeder App – aktuell angeführt von YouTube, TikTok und Disney+.
Beim ersten Release von FreemiumKit wollte ich alles mitliefern, was man braucht, um schnell eine erfolgreiche Paywall-UI zu bauen. Also scrollte ich durch alle 312 Paywall-Screens von Apps mit einem geschätzten Umsatz von über 500.000 $ pro Monat, wählte die 20 Screens aus, die ich am einladendsten und aufgeräumtesten fand, und analysierte sie, um Gemeinsamkeiten zu finden. Basierend auf meinen Erkenntnissen entwickelte ich dann 2 verschiedene und hochgradig anpassbare UI-Komponenten, mit denen du die meisten der analysierten Varianten erstellen kannst!
Hier sind die 20 ausgewählten Screens in absteigender Umsatzreihenfolge:
Quelle: paywallscreens.com
Quelle: paywallscreens.com
Quelle: paywallscreens.com
Quelle: paywallscreens.com
Häufige Design-Entscheidungen
Alles, was mir aufgefallen ist und was mindestens 50 % (einer Art) gemeinsam haben:
100 % bieten entweder einen monatlichen oder wöchentlichen „Kurzzeit”-Plan an.
100 % bieten entweder einen jährlichen oder lebenslangen „Langzeit”-Plan an.
100 % verwenden schlichten weißen oder schwarzen Text für die Pläne oder die Liste freigeschalteter Features.
95 % füllen den gesamten Bildschirm ohne zusammenhanglose Navigationselemente.
95 % bringen alle wichtigen Informationen auf einen Bildschirm, ohne dass gescrollt werden muss.
90 % verwenden eine Hintergrundfarbe, um ihren Haupt-Call-to-Action-Button hervorzuheben.
85 % haben die Preispläne in der unteren Bildschirmhälfte aufgelistet.
80 % verwenden einen abgerundeten Rahmen, um die aktuell ausgewählte Option hervorzuheben.
80 % haben entweder einen Zurück-Pfeil oder einen „X”-Button oben zum Schließen.
61 % der „X”-Buttons befinden sich in der linken Ecke (schwerer erreichbar für die meisten).
80 % haben einen deutlich hervorgehobenen Call-to-Action-Button ganz unten.
75 % der Call-to-Action-Buttons sind kapselförmig (Enden zu 100 % abgerundet).
56 % der Call-to-Action-Buttons verwenden exakt denselben Titel: „Continue”
70 % verwenden eine vertikale Liste von Buttons für die verschiedenen Planoptionen.
70 % derjenigen mit Vorauswahl entscheiden sich für die langfristige wiederkehrende Option.
60 % verwenden einen weißen Hintergrund hinter der Planliste zur Auswahl.
55 % erwähnen den App-Namen irgendwo in der oberen Hälfte.
65 % bieten entweder eine Liste, ein Grid oder eine Seitenansicht mit 2–6 (durchschn. 4) freigeschalteten Features.
77 % derjenigen mit Liste verwenden ein Häkchen-Symbol vor jedem Feature.
55 % verwenden ein Hintergrundbild, das sich bis zum oberen Bildschirmrand erstreckt.
50 % bieten eine kostenlose Testversion für mindestens einen bezahlten Plan an.
50 % erwähnen einen Rabattprozentsatz im Vergleich zu anderen Optionen.
Weniger häufige Design-Entscheidungen
Dinge, die mir bei einigen Paywalls aufgefallen sind, die aber die Mehrheit nicht macht:
45 % verwenden eine andere Hintergrundfarbe für den aktuell ausgewählten Plan.
35 % haben ein „Beliebt”- / „Empfohlen”-Tag bei einer der Kaufoptionen.
30 % haben einen Radio-Button wie einen Punkt oder eine Checkbox, um die Auswahl hervorzuheben.
30 % verwenden eine horizontale Liste von Buttons für die verschiedenen Planoptionen.
30 % bieten einen (weniger hervorgehobenen) „Wiederherstellen”-Button innerhalb der Paywall.
30 % bieten einen (weniger hervorgehobenen) Link zu ihren Nutzungsbedingungen und ihrer Datenschutzerklärung.
15 % verwenden eine Seitenansicht, um die durch den Kauf freigeschalteten Features zu präsentieren.
10 % bieten ein Segmented Control zum Wechseln zwischen Monatlich/Jährlich usw.
5 % haben eine Animation auf ihrem Call-to-Action-Button (oder anderswo).
Der Paywall-Bauplan
Mit den obigen Erkenntnissen habe ich einen „Bauplan” erstellt, der sie alle einbezieht:
Ich bin kein professioneller Designer, aber ich denke, es ist gut genug für das erste öffentliche Release von FreemiumKit. Bessere Designer als ich in der Community sind eingeladen, (ausgefallene) Verbesserungen oder ganz andere Designs beizusteuern. Die README hat einen eigenen Abschnitt, der beschreibt, wie man eigene Designs baut. Wenn man sich anschaut, wie dieser Screen insgesamt aussieht und die 20 Paywall-Designs betrachtet, die ich geprüft habe, denke ich, es ist klug für das Framework, sich auf den Teil mit der meisten Logik zu konzentrieren. Die gesamte obere Hälfte des Screens ist in SwiftUI sehr einfach umzusetzen (nur ein Image mit einem .overlay, ein Button und eine List von Text-Views). Und dasselbe gilt für die weniger hervorgehobenen „Nutzungsbedingungen”-, „Wiederherstellen”- und „Datenschutzerklärung”-Buttons ganz unten.
Das ist der einzige Teil im Paywall-Bauplan mit komplexer Logik.
Konzentrieren wir uns also auf den Teil, der die verfügbaren Produkte lädt und auflistet, die aktuelle Auswahl hervorhebt, potenziell verfügbare Testzeiträume anzeigt, Langzeitplan-Rabatte, das Preisschild, ein zweites Monatspreisschild für besseren Vergleich, ein „Bester Wert”- oder „Beliebteste”-Badge, die aktuelle Planauswahl handhabt und die Logik für die Anzeige & Deaktivierung des „Weiter”-Buttons bei Bedarf. Wie du sehen kannst, ist dieser Teil ziemlich komplex, um ihn richtig hinzubekommen, und weil (fast) all diese Informationen der App tatsächlich von StoreKit bereitgestellt werden, ist es eine großartige Gelegenheit, die Dinge zu vereinfachen. Indem der Rest des Screens dem Entwickler/Designer überlassen wird – mit all den Erkenntnissen und dem Bauplan von oben – sollten Nutzer der Bibliothek volle Freiheit & Flexibilität haben, ein einzigartiges Aussehen für die Paywall ihrer App zu gestalten.
Um die Sache etwas spaßiger zu machen und A/B-Tests schon im ersten Release von FreemiumKit zu ermöglichen, erstellen wir auch eine horizontale Listenvariante wie diese:
Beide nebeneinander in ihrer Vollbild-Ausdehnung sehen so aus:
Die vertikale (links) und horizontale (rechts) Paywall-Baupläne nebeneinander.
Vertikaler & Horizontaler Produkt-Stil
FreemiumKit liefert eine SwiftUI-View namens AsyncProducts, die ganz ähnlich wie AsyncImage funktioniert: Du gibst die Produkt-IDs an, die du in deiner Paywall anzeigen willst (wie du AsyncImage eine URL deines Bildes gibst), und AsyncProducts kümmert sich um das Abrufen der Produkte aus dem App Store (wie AsyncImage die Bilder aus dem Web abruft), zeigt einen Platzhalter während des Ladens an und zeigt sogar eine Fehlermeldung mit einem Neu-laden-Button an, falls es Netzwerkprobleme gibt. Mit anderen Worten: Es erledigt die ganze schwere Arbeit – du musst nur entscheiden, wo auf deiner Paywall du es platzieren willst und welche Größe am besten passt:
AsyncProducts(
style: PlainProductsStyle(),
productIDs: ProductID.allCases,
inAppPurchase: AppDelegate.inAppPurchase
)Beispielverwendung von AsyncProducts.
Die Parameter productIDs & inAppPurchase werden in der Schritt-für-Schritt-Anleitung Getting Started in der README erklärt. Was uns in diesem Artikel interessiert, ist der style-Parameter, der es dir ermöglicht, verschiedene Designs für die UI-Komponente zu übergeben. Der PlainProductsStyle ist nur ein Demo-Stil, der die minimale Implementierung eines Stils zeigt, für diejenigen, die eigene Stile erstellen wollen. Er ist nicht für die direkte Verwendung gedacht. Die zwei echten Stile, die FreemiumKit in 1.0 mitliefert, sind:
VerticalPickerProductsStylefür das linke Design von obenHorizontalPickerProductsStylefür das rechte Design von oben (in Arbeit)
Außerdem plane ich, mindestens einen weiteren Stil hinzuzufügen, der etwa HorizontalButtonsProductStyle heißen könnte und ein UI ohne „Weiter”-Button implementiert, wie es in der Paywall von Apples neuester App Final Cut Pro für iPad verwendet wird:
Paywall in Apples neuer Final-Cut-Pro-App für iPad.
Aber konzentrieren wir uns auf die heute verfügbaren Stile und verwenden den vertikalen Picker:
AsyncProducts(
style: VerticalPickerProductsStyle(
preselectedProductID: ProductID.proYearly,
tintColor: .blue
),
...
)Er nimmt zwei Argumente entgegen: Eines, mit dem du das Produkt angeben kannst, das als Vorauswahl hervorgehoben werden soll. Erkenntnis Nr. 15 aus der obigen Analyse sagt uns, dass 70 % die langfristige wiederkehrende Option vorauswählen. Das andere Argument lässt dich die Akzentfarbe wählen, die sowohl für den „Weiter”-Button-Hintergrund als auch zur Hervorhebung der aktuellen Auswahl des Nutzers verwendet wird. Achte darauf, eine Farbe zu wählen, die gut mit Weiß kontrastiert, denn das ist die Textfarbe des Weiter-Buttons.
Wenn du verschiedene Paywall-Designs testen willst, ist es sehr einfach, den Stil für A/B-Tests auszutauschen: Ersetze einfach VerticalPickerProductsStyle durch HorizontalPickerProductsStyle und alles sollte einfach funktionieren. Diese beiden Stile nehmen sogar dieselben Argumente entgegen, es ist also wirklich einfach. Andere Stile wie der geplante HorizontalButtonsProductsStyle werden andere Argumente haben, da es bei einem reinen Button-Stil ohne Auswahl kein Konzept von „Selection” gibt – aber es sollte trotzdem einfach genug sein, das zu ändern. Alle Stile konformieren zum AsyncProductsStyle-Protokoll. Wenn du also eine Variable erstellen willst, der du je nach A/B-Test-Gruppe verschiedene Stile zuweisen kannst, kannst du any AsyncProductsStyle als Typ verwenden.
Fazit
Das waren meine Erkenntnisse aus der Analyse von 20 erfolgreichen Paywalls. Ich habe alle Erkenntnisse in den VerticalPickerProductsStyle eingebaut, der in FreemiumKit mitgeliefert wird. So kannst du einfach die AsyncProducts-View in SwiftUI nutzen, statt dich mit komplexer Logik herumzuschlagen. Du musst dir nur merken, die weniger komplexen Erkenntnisse anzuwenden – wie AsyncProducts in der unteren Bildschirmhälfte zu platzieren, sowohl ein Kurzzeit- als auch ein Langzeit-Abo anzubieten oder eine Liste der freigeschalteten Features in der oberen Hälfte bereitzustellen.