[ENTWICKLUNG] Auf der Suche nach der besten Purchase Methode

  • Antworten:24
  • OffenNicht stickyNicht beantwortet
  • Forum-Beiträge: 2.901

25.03.2017, 15:13:23 via Website

Hallo liebe Gemeinde,

ich stehe immer wieder vor der gleichen Frage .....

Nehmen wir an dieser Stelle folgendes Grundgerüst

Ein und die Gleiche App in zwei Versionen :

  • Eine Free + AdMob App Version
  • Eine Premium ohne AdMob Version.

Derzeit arbeite ich mit inApp Purchase, bin allerdings des öfteren schon übers Ohr gehauen worden,
deshalb auch dieser Thread.

Wird die App bei der InApp-Puchase-Technik - egal ob Free oder Premium ohne INet Verbindung verwendet -
besteht natürlich keine Möglichkeit mehr, weder Werbung noch den InApp zu kontrollieren.

Wie würdet Ihr diesen Umstand absichern (oder tut es schon) ?

Checkt man kontinuierlich die Internet- Verbindung ? Schreibt man den letzten Versuch ab ?
Wenn ja , in welchem Rythmus fragt man wieder an ?

Was macht ihr , wenn einer z.b. das Ding kauft , es innerhalb der 3 Stunden zurück gibt und dann
(bevor er die App öffnet ) für immer offline geht ?

Das betrifft auch die freie AdMob version : Lässt man das Benutzen nach eine Weile nicht mehr zu ?
(Keine Werbung = kein Nutzen)

Aber was wäre , wenn einer die Free oder Premium besitzt und dann im Flieger benutzt ?

All diese Fragen sollen eher eine Diskussiongrundlage darstellen, was ihr Umsetzt oder umsetzen
würdet und was man schlussendlich auch dem KUNDEN zumuten kann.
(Die Balance zwischen Shitstorm und "Der Kauf lohnt sich")

Derzeit :
Ich neige immer mehr dazu, vom InApp Purchase abzurücken und wieder zwei Versionen im Store zu platzieren.
(Durch Gradle Flavor unterstützt)

Ideen herzlichst willkommen und ich danke euch :)

Liebe Grüße - Stefan
[ App - Entwicklung ]

Antworten
Pascal P.
  • Mod
  • Blogger
  • Forum-Beiträge: 10.165

26.03.2017, 13:06:31 via Website

Hallo Stefan,
ich sehe die ganze Problematik nicht so eng, da:
1. ich keine Pro Version oder InApp Pruchase biser benutzt habe (auch keine Werbung)
2. ich eher als Hobby programmiere, daher brauch ich auch keinen wesentlichen Profit.

Allerdings weiß ich auch, das du das beruflich machst, da nimmt man die Finanzen auf jeden Fall genauer als jetzt ich mit meinem Hobby.
In deiner Situation würde ich wahrscheinlich auch 2 Versionen machen, einfach weil man sichergehen kann dass es auch funktioniert.
Jedoch würde ich dies abhängig von den Funktionen machen, z.b. wenn die Pro-App als Gesmtpaket mehr kann dann als eine App, wenn nur mehr oder weniger unabhängige Funktionen dazukommen, dann mit InAppPurchase etc.
Oder man Packt die Inhalte in "Plugins" die man kaufen muss (gibts z.b. bei der App OsmAnd im Store)

Sind alles denkbare Szenarien, die mal mehr und mal weniger Aufwnad für den Entwickler bedeuten.
Bei Kunden kann man im normalfall erwarten, dass sie zum erwerben der Pro Version den Play-Store aufrufen und den Kauf dort abschließen. Kannst du ja aus der App direkt verlinken. Zudem wollen sie ja auch mehr Funktionen haben, ich hätte aus Nutzersicht kein Problem für die Pro eine extra App zu laden.

Hierzu noch ein Anmerkung:

Checkt man kontinuierlich die Internet- Verbindung ? Schreibt man den letzten Versuch ab ?
Wenn ja , in welchem Rythmus fragt man wieder an ?

Aus Nutzersicht würde mich so eine Überprüfung stören, da ich ja einen onlinezwang habe auch wenn die App unter umständen gar kein Internet benötigt. Das wäre für die nicht-Entwickler ein Nachteil, den sie nicht verstehen warum das so gemacht wurde.

Also als Empfehlung: 2 Apps free+pro auf gleicher Codebasis :)

PS: Ich erinnere mich dunkel das wir das schonmal hatten oder?

LG Pascal //It's not a bug, it's a feature. :) ;)

swa00

Antworten
  • Forum-Beiträge: 2.901

26.03.2017, 13:45:26 via Website

Hallo Pascal,
erst mal lieben Dank für Deine Gedanken, ich weis ja dass du derzeit im Stress bist und lieber irgendwo draussen sein würdest :-)

Ja das hatten wir schon mal in ähnlicher Weise und ich hatte mich dann auf InApp zur Premium eingeschossen.

Was ich allerdings dann total unterschätzt habe , war das "kriminelle" Potiential einiger Nutzer.
Ich gehe immer von einer gewissen Portion Ehrlichkeit aus , das war wohl eher eine Fehleinschätzung :-)

Schlussendlich müssen wir dann feststellen , dass InApp nur im Sonderfalle (z.b. Juwelen) verwendet werden kann .
In wirklichen Premium Versionen eher die 2 Varianten Technik.

Das war bis dato Aufwand in der Pflege , jedoch wenn man sein ProductFlavor im Gradle ordentlich einmal stehen hat, ist es eigentlich erträglich.

e.g.

 productFlavors {
    free {
        applicationIdSuffix ".free"
        versionNameSuffix "-free"
        resValue "string", "app_name", "Company AppName Free"
        resValue "string", "icon_name", "AppName Free"
        manifestPlaceholders = [
                appIcon: "@mipmap/ic_launcher_free"
        ]
    }
    premium {
        applicationIdSuffix ".premium"
        versionNameSuffix "-premium"
        resValue "string", "app_name", "Company AppName Premium"
        resValue "string", "icon_name", "AppName Premium"
        manifestPlaceholders = [
                appIcon: "@mipmap/ic_launcher_premium"
        ]
    }
}

Nochmals lieben Dank für deinen Input , das hilft mir bei meiner Entscheidung schon mal deutlich weiter

P.S Viel Erfolg bei deinen letzten "Zügen" und das mir dabei ja ein ordentliches 1.0 herauskommt :-)

— geändert am 26.03.2017, 13:55:15

Liebe Grüße - Stefan
[ App - Entwicklung ]

Antworten
Pascal P.
  • Mod
  • Blogger
  • Forum-Beiträge: 10.165

26.03.2017, 14:14:43 via App

Danke, ich versuche den Stress nicht an mich heran zu lassen :)
Das mit den GradleFlavors klingt interessant muss ich mich mal einlesen wenn ich mal wieder Zeit habe ;)
LG

— geändert am 26.03.2017, 14:14:59

LG Pascal //It's not a bug, it's a feature. :) ;)

Antworten
  • Forum-Beiträge: 2.901

26.03.2017, 14:30:55 via Website

Na dann schick ich Dir mal Zusatzinfo

a ) in den Build Variants wählst du dann die Version aus und machst ein ReleaseBulid
Herauskommen tun dann die zwei apks
b ) Die Manifest ist dann auch übersichtlich

 <application
    android:allowBackup="true"
   android:label="@string/app_name"
    android:supportsRtl="true"
    android:theme="@style/Theme.AppCompat.Light.NoActionBar">
    <activity android:name=".MainActivity"
        android:label="@string/icon_name" >
        <intent-filter>
            <action android:name="android.intent.action.MAIN" />
            <category android:name="android.intent.category.LAUNCHER" />
        </intent-filter>
    </activity>
</application>

und im Source machste dann sowas

  if (getPackageName().contains("premium")) .......

— geändert am 26.03.2017, 14:33:45

Liebe Grüße - Stefan
[ App - Entwicklung ]

Antworten
Pascal P.
  • Mod
  • Blogger
  • Forum-Beiträge: 10.165

26.03.2017, 14:42:04 via Website

Danke :)
Ich sehe das ganze als "offiziellen Workaround" zu Compilerdirketiven, denn der Code wird in der APK trotzdem mitgeliefert, halt nicht ausfeführt.
Aus dem .NET Umfeld kenne ich das über Compiler Parameter, dass im Output auch nur das drin ist, was man auch haben will, anscheinend funktioniert das mit Java Compilern wohl nicht, so ist es zumindest besser als garnicht ;)

LG Pascal //It's not a bug, it's a feature. :) ;)

Antworten
  • Forum-Beiträge: 2.901

26.03.2017, 14:45:11 via Website

Kenne ich aus auch dem C++/MFC in VS2015

Habe das verzweifelt auch in AS / Java gesucht .... deshalb der Workaround.

Lässt sich mit Leben :-)

Liebe Grüße - Stefan
[ App - Entwicklung ]

Antworten
  • Forum-Beiträge: 2.232

27.03.2017, 12:46:36 via Website

Nur mal so ein paar 'semi-professionelle' Fragen zum Verständnis bzw. auch zur Anregung:

Wie wurdest Du denn mit InApp-Purchases übers Ohr gehauen?
Ist es nicht gerade so, dass man diese bspw. auch nicht erstattet bekommen kann. Somit wärst Du auf der sichereren Seite.

Wieso muss man den InApp-Kauf kontinuierlich überprüfen? Um die App nicht mit Daten zu sichern und auf einem anderen Gerät wiederherstellen zu können?
Kann man da nicht alle möglichen Account-Daten mitspeichern bzw. es einfach Geräteinstallations-bezogen (Android-ID) speichern?
Bei jeder InApp-Aktivierung auf einem neuen Gerät wäre dann eine Internet-Verbindung nötig. Das kann man Pro-Usern durchaus zumuten.

Als User finde ich InApp-Käufe komfortabler - allenfalls eine Extra-App als Pro-Key (wie es sie aus Zeiten ohne InApp noch gibt). Bei Free & Pro getrennt ist es leider oft so, dass Einstellungen beim Wechsel auf Pro nicht übernommen werden. Es sei denn, das ist für Deine Apps nicht relevant bzw. sowieso einfach zu handeln und viele Entwickler zu nur zu faul zur Übernahme ;)

Antworten
  • Forum-Beiträge: 870

27.03.2017, 12:59:41 via Website

Luigi

Wieso muss man den InApp-Kauf kontinuierlich überprüfen?

Mal ganz unbedarft als User? Ich dachte, die Lizenzprüfungen laufen über Google bzw. Google Play Services?

Grundsätzlich:
Eine App, die ich selbst nicht fürs Internet verwende, bekommt von mir den Zugang auf mobile Daten/WLAN verboten, vor allem wenn nicht offen gesagt wird, was da übertragen wird.

Dass zu Beginn eine eigene Lizenzprüfung stattfindet, ok. Aber wenn da kontinuierlich "irgendwelche" Daten fließen, bin ich al User wenig begeistert...

— geändert am 27.03.2017, 13:00:01

Antworten
  • Forum-Beiträge: 2.232

27.03.2017, 13:08:28 via Website

Genau, das war ja die Frage: Wieso notwendigerweise kontinuierlich und nicht einmalig (je Gerät)?

Die account- oder gerätebezogenen Daten, welche man in der App zur Pro-Validierung speichert, könnte man ja auch noch (simpel) verschlüsseln, so dass auch einem versierten Anroid-User die manuelle Übertragung eben jener Daten auf ein anderes Gerät schwer bis unmöglich gemacht wird.

Antworten
  • Forum-Beiträge: 2.901

27.03.2017, 14:11:58 via Website

@Brian, @Luigi

Die Überprüfung der InApp-Käufe und deren damit beknüpften Berechtigungen , wird NICHT über die Internetverbindung abgewickelt, die ihr in den Berechtigungen einstellt.

Dieses Hin & her findet über den PlayService von Google statt, dieser müsste dann vom User die Berechtigung entzogen bekommen.

Auch gibt es keinen internen schlüssel ( ein 64 Byte schlüssel ) , der lokal abgesichert wird , sondern die App muss halt mit diesem Schlüssel über die PlayServices bei Google anfragen, ob der Schlüssel noch valide ist.

Und da ist dann genau der Haken : Nehmen wir eine Spiele- App, bei denen du Leben für 99 cent kaufen kannst,
dann kannst du rein theoretisch diesen Kauf innerhalb von 3 Stunden rückgängig machen.
Gehst du dann nach dem Kauf sofort offline, lässt dir das Geld erstatten , dann kann der Appanbieter nichts mehr gegen tun .

Aus diesem Grunde gibt es dann noch die Sicherheit bei Google : Machst du das als User öfters,
wirst du für weitere Rückgaben gesperrt - der Schaden ist allerdings immer noch vorhanden .

— geändert am 27.03.2017, 14:28:06

Liebe Grüße - Stefan
[ App - Entwicklung ]

Antworten
  • Forum-Beiträge: 2.232

27.03.2017, 14:35:37 via Website

swa00

dann kannst du rein theoretisch diesen Kauf innerhalb von 3 Stunden rückgängig machen.

Genau hier kannte ich halt die aktuellen Richtlinien nicht. Ich dachte, das ginge bei InApp-Käufen gar nicht .

Antworten
  • Forum-Beiträge: 2.901

27.03.2017, 14:37:18 via Website

Genau hier kannte ich halt die aktuellen Richtlinien nicht. Ich dachte, das ginge bei InApp-Käufen gar nicht .

Das ist aber wohlbemerkt ein wenig versteckt , geht nur über die Web ... auf dem Smartphone findest du den Punkt nicht.

Playstore -> Konten -> und dann auf die jeweilige App im Menu (drei Punkte )

— geändert am 27.03.2017, 14:42:07

Liebe Grüße - Stefan
[ App - Entwicklung ]

Luigi

Antworten
  • Forum-Beiträge: 434

27.03.2017, 21:57:41 via Website

Hmm, mir ist nicht ganz schlüssig wo eine Pro-Version mehr Sicherheit bietet. In der Regel läufts doch so:
adb pull your-pgk-name ... Oder der 13 jährige Scherzkeks nimmt sich eine root App mit hübscher GUI, mit der er die key.apk / pro.apk vom Handy zieht. Nun wandert das gute Stück in ein virenverseuchtes Forum und schon ist der Schaden im worst case für beide Seiten größer, als wenn ein paar Leute die Käufe zurückziehen. Habe bei meinen IAB keine Ungereimtheiten bemerkt - wobei ich insgesamt im Jahr auf ca. 130-150€ Gewinn komme, also nicht der Rede wert.

Es ist (und bleibt vermutlich auch) Fakt, dass Nutzer sich Inhalte "erklauen" können. App-Zustände solide zu verschlüsseln (zB via AES256) ist schnell implementiert und bietet keine Beeinträchtigung von "fairen" Nutzern.
Vor diesem Hintergrund ist IAB inkl. persistenter Speicherung des Premium Status für mich der Way to go.
Im Zweifel habe ich lieber 10 Idioten die App geschenkt, als jemandem, der mir zuvor vertraut hat, einen Grund zu geben in Zukunft misstrauisch zu sein. Dazu kommt: Ich weiß selbst zu genau wie viel Arbeit in der Entwicklung steckt und dass gerade kleine Entwickler ganz sicher NICHT die dicke Asche machen. Dementsprechend würde ich mich regelrecht schämen, wäre ich der Grund dafür, dass ein Nutzer in Zukunft nichts mehr kauft.
... und wer sich Leistungen erschleicht, dem wünsche ich viel Glück. Er wird schon wissen was er tut.

Ich für meinen Teil bin jedenfalls froh, dass ich mit meinen Apps keine Aktionäre vertreten muss. Anderenfalls müsste ich meine Nutzer hassen und mit IP-Banns sperren, wenn sie sich 2x falsch eingeloggt haben :D

PS: Wie gesagt.. ich bin mir voll darüber bewusst, dass meine Vorgehensweise mit Sicherheit keine wasserdichte "Lösung" ist. Aber am Ende ist es der Kompromiss, der mir als am fairsten erscheint.

— geändert am 27.03.2017, 22:01:21

Open Source

swa00

Antworten
  • Forum-Beiträge: 2.901

27.03.2017, 22:11:43 via Website

Hallo Pepp,

ich stimme dir 100 % zu ... :-)

Die Wahrscheinlichkeit, dass wir an den Scherzkeks geraten und seinem ADB / Root ist jedoch geringer,
als der Klick im Playstore und der Tipp vom guten Freund. :-)

Ach alles dämlich , ich mach jetzt mal die 2 Version-Variante .Mal schauen , was ich euch dann in einem
halben Jahre berichten kann.

Vielleicht bin ich dann völlig entnervt :-)

Liebe Grüße - Stefan
[ App - Entwicklung ]

DerGü

Antworten
  • Forum-Beiträge: 28

31.10.2018, 10:12:24 via Website

swa00
Mal schauen , was ich euch dann in einem halben Jahre berichten kann.

Hallo,

sorry, dass ich einen so alten Thread noch mal aufgreife aber ich fand die Diskussion überaus interessant und inspirieren und mich würde wirklich sehr die Essenz nach dem halben Jahr, auch wenn es jetzt 1 1/2 Jahre sind, von @swa00 oder auch aktuelle Erkenntnisse anderer sehr interessieren!

Danke schon mal.

Antworten
  • Forum-Beiträge: 2.901

31.10.2018, 10:51:24 via Website

Hallo DerGü

nun , die beste Variante ist immer noch die Zwei-Modell-Variante mit einem Sourcecheck über GooglePlayStore
(Also die Premium läuft nur , wenn sie aus dem Playstore mit dem zahlenden Account verknüpft wird)

Damit hauen zwar die APK-Mirror Kandidaten ab , das kann man aber verschmerzen :-)

— geändert am 31.10.2018, 10:51:35

Liebe Grüße - Stefan
[ App - Entwicklung ]

DerGü

Antworten
  • Forum-Beiträge: 28

31.10.2018, 11:09:25 via Website

Danke für die Antwort. Darf ich vielleicht noch kurz fragen wie du den Sourcecheck machst? Hopla nu hab ich schon gefragt :). Unterstützt mich da Google bei oder muss man da wieder selbst, umfangreicher aktiv werden?

Antworten
  • Forum-Beiträge: 28

31.10.2018, 11:47:04 via Website

Perfekt, danke. Mein größtes Problem sind gerade die Rückgaben. Bei mir behalten alle User ihre Käufe trotz Rückgabe und ich komme irgendwie nicht an die Info wer seinen In-App-Kauf schon zurückgegeben hat. Darum denke ich auch über zwei Versionen nach. Wie ich Google verstanden habe soll das bei Käufen in der App gar nicht so leicht sein. Warum das nun aber laut Google bei zwei Versionen leichter ist erschließt sich mir noch nicht so wirklich. Wenn du da noch einen kleinen Tipp parat hättest wäre mein Tag gerettet und ich hätte mehr Zeit anderen zu helfen (Omas über die Straße und so) :).

— geändert am 31.10.2018, 11:50:07

Antworten

Empfohlene Artikel