Preisgestaltung ist schwer. Man kann es nie allen recht machen. Das weiß ich alles. Aber es deprimiert mich trotzdem länger, als ich zugeben möchte, wenn ich eine Bewertung wie diese lese:
Ein Nutzer, der seine Gefühle in einer negativen App-Store-Bewertung ausdrückt.
Es ist wirklich schwer, der Versuchung zu widerstehen, einfach ihrer Forderung nachzugeben und den Preis zu senken. Und ich konnte nicht immer widerstehen, wie du hier sehen kannst:
Ein Nutzer auf Reddit beschwert sich über den Preis einer Einmalkauf-App.
Ich bin eben auch nur ein Mensch und ich möchte, dass den Leuten gefällt, was ich mache. Aber ich muss als Indie-Entwickler auch Geld verdienen, sonst kann ich die App nicht weiter verbessern. Es liegt also sogar im Interesse der Nutzer, dass ich einen fairen Preis ansetze – nicht nur in meinem. Aber was ist fair?
„Faire” Preisgestaltung
Man kann das aus vielen verschiedenen Perspektiven betrachten.
Aus wirtschaftlicher Sicht sollte mein Ziel sein, meine Einnahmen zu maximieren. Wenn du nach einem Artikel über verschiedene Strategien dafür suchst, liest du besser einen Artikel wie diesen hier. Für mich ist Profit nur ein Mittel, um mich motiviert zu halten, weiter Apps zu bauen. Er ist nicht das Ziel. Die User Experience ist alles, was zählt. Und Probleme lösen. Ein fairer Preis gehört für mich zu einer guten UX dazu.
Eine reine Entwickler-Perspektive könnte sein, eine App nach dem Aufwand zu bepreisen, der nötig war, um sie zu bauen. Klingt fair, oder? Aber das funktioniert nicht in einem freien Markt. Und das aus gutem Grund! Was, wenn du etwas super Komplexes, aber total Irrelevantes gebaut hast? Warum sollte jemand dafür einen hohen Preis zahlen? Würdest du das?
Das bringt mich dazu, wie ich meine Anfangspreise meistens wähle: Was würde ich zahlen, wenn diese App von jemand anderem gebaut wäre und ich sie einfach nutzen wollte? Da ich ausschließlich Apps baue, die ich selbst brauche, bin ich auch Kunde! Es ist also quasi eine Ein-Personen-Kundenrecherche, auf der meine anfängliche Preisgestaltung basiert. Aber ist das eine gute Idee?
Zumindest nicht, wenn ich schlechte Bewertungen wie die 2-Sterne-Bewertung oben vermeiden will. Warum? Weil ich nicht nur Kunde bin, sondern auch genau weiß, was meine App bietet. Die Nutzer aber nicht. Sie wissen nur das, was ich ihnen auf der App-Store-Seite und in meinem Onboarding präsentiert habe. Und wahrscheinlich nicht mal alles davon.
Die Nutzer-Perspektive
Was sich für einen Nutzer fair anfühlt, hängt also stark davon ab, wie der Nutzer den Wert einer App wahrnimmt. Zum Beispiel die schlechte Bewertung oben, die ich für TranslateKit bekommen habe. Mein Vorschauvideo auf der App-Store-Seite kommuniziert die einfache Bedienbarkeit des Drag-&-Drop-Workflows zum Übersetzen von Apps. Aber der Nutzer hat sich beschwert, weil er sich bei einem Drittanbieter-Übersetzungsdienst registrieren musste, um die beworbenen Funktionen zu nutzen.
Natürlich erwähne ich diese Anforderung in meiner App-Store-Beschreibung. Aber wer liest Beschreibungen? Niemand! Ich könnte tun, was der Nutzer gefordert hat, und eingebaute Unterstützung für diese Übersetzungsdienste anbieten. Aber dann müsste ich für diese Dienste bezahlen und den Preis darauf aufschlagen. Und ich müsste zusätzlich einen Proxy-Server betreiben, um sicherzustellen, dass meine API-Keys nicht offengelegt werden, was weitere Kosten verursacht.
Das ist für die meisten meiner anderen Kunden aber nicht gut. Schließlich hat jeder Übersetzungsdienst, den ich unterstütze, ein großzügiges kostenloses Kontingent, das mehr als ausreicht, um eine App beliebiger Größe in viele Sprachen zu lokalisieren! Das einzige Problem ist die zusätzliche Hürde, ein kostenloses Konto zu erstellen und die API-Keys zu holen. Ich versuche zu helfen, indem ich auf die richtigen Seiten verlinke:
Alle Drittanbieter-Dienste ausgeklappt mit Links zur Registrierung & API-Key-Dokumentation.
Diese Hürde hat wahrscheinlich beim Nutzer Frust verursacht, der erwartet hatte, seinen String Catalog nach dem Herunterladen der App einfach „per Drag & Drop” reinzuziehen, wie im Vorschauvideo gezeigt. Aber das ging nicht sofort. Und als Konsequenz drückte er seine Gefühle aus, indem er das Einzige kritisierte, worüber er tatsächlich Bescheid wusste: den Preis. Denn den sieht man, wenn man im Hauptfenster auf „Upgrade” klickt.
Der obere Bereich des Hauptfensters in TranslateKit.
Die Beschwerde adressieren
Das Einfachste, was ich tun könnte, um Beschwerden über den Preis zu vermeiden, wäre, die Information über die kostenpflichtige Stufe zu verstecken, bis der Nutzer das kostenlose Limit überschreitet. Aber das betrachte ich als Dark Pattern, also würde ich das nie tun. Und selbst wenn ich es täte, würden sie sich wahrscheinlich einfach über etwas anderes beschweren – es löst das Problem nicht.
Viel nützlicher, um schlechte Bewertungen zu verhindern, wäre es, wenn ich mehr Anleitung und Hilfe beim Erstellen dieser Konten bieten würde, vielleicht mit Schritt-für-Schritt-Anleitungen oder Videos. Aber das senkt nur den Aufwand – es könnte für manche immer noch zu viel sein!
Die obige Analyse bringt mich zu dem Schluss, dass es eigentlich nicht der Preis meiner App war, der zur schlechten Bewertung geführt hat, sondern meine Unfähigkeit, ihren Wert zu kommunizieren. Nutzer können nicht wissen, dass meine App die String Catalogs nicht nur mit Übersetzungsdiensten verbindet, sondern auch unter der Haube allerlei Cleveres tut, um sicherzustellen, dass die Übersetzungen akkurat sind. Ein einfacher Weg, das zu kommunizieren, ist ein Beispiel:
Neues Fenster beim ersten App-Start zur Kommunikation des App-Werts.
Indem ich die verschiedenen Stufen zeige, die eine Übersetzung beim App-Start durchlaufen kann, erkläre ich meinen Nutzern, welchen zusätzlichen Mehrwert meine App bietet – über das hinaus, was schon auf der Store-Seite offensichtlich ist. Zusätzlich sollte ich diese Stufen & Anpassungen wahrscheinlich auch in der Übersetzungs-UI meiner App sichtbar machen, was ich in einem zukünftigen Update tun könnte. Aber es hätte die schlechte Bewertung sowieso nicht verhindert, da man die Übersetzungs-UI erst sieht, nachdem man mindestens einen API-Key eingerichtet hat.
Fazit
Preisgestaltung ist tatsächlich schwer und ich bin mir immer noch nicht zu 100 % sicher, ob das, was ich tue, richtig ist. Und das werde ich wahrscheinlich nie sein. Aber zumindest fühle ich mich nicht schlecht wegen meines Preises, da meine App viele Stunden Zeit spart und deutlich weniger kostet als der durchschnittliche Stundensatz. Und ich weiß, dass Leute die App abonnieren – das sehe ich an den Zahlen in App Store Connect. Jedes gekaufte Abo ist jemand, der mir sagt: „Der Preis ist nicht zu hoch.”
Nur weil ein Kunde sich über den Preis beschwert hat, heißt das nicht, dass er falsch ist. Die deprimierendsten Bewertungen können manchmal die nützlichsten Einblicke in die Schwächen deines App-Onboardings liefern. Ignoriere sie nicht einfach. Versuche zuerst zu verstehen, woher deine Nutzer kommen könnten. Und kommuniziere den Wert deiner App!