12
votes

Google Play In-App Facturing Donner un article gratuitement

J'ai déjà une application entièrement gratuite publiée sur Google Play Store.

Étant donné que l'application est plus populaire que celle que j'ai pensée, j'ai décidé de verrouiller certaines des fonctionnalités et de la demande de facturation intégrée avant de l'utiliser. Cependant, je préfère que tous les utilisateurs existants continueront à profiter des fonctionnalités premium gratuitement.

Alors, j'ai pensé à ce qui suit:

  • Téléchargez une version avec une facturation intégrée gratuitement, de sorte que les utilisateurs existants va "acheter" gratuitement.
  • Après une certaine quantité de temps, commencez à charger les articles, mais depuis les utilisateurs existants possèdent déjà les articles premium qu'ils ne seraient pas blessé.

    Y a-t-il un moyen d'accorder des utilisateurs un article pour "Gratuit"? Dans la documentation de facturation intégrée, il est écrit qu'il doit y avoir un prix pour tous les articles de facturation intégrés.


0 commentaires

4 Réponses :


4
votes

Il n'y a pas de mauvaise façon de le faire de Google. Vous aurez 2 cas de test: -

  1. Utilisateur existant
  2. nouvel utilisateur Vous devez stocker un article unique user-id sur votre serveur et lorsque vous implémentez votre application dans l'application Envoyer cet utilisateur-ID sur votre serveur.

    cas 1: - Votre serveur correspondra à celui-ci avec DB existant s'il correspond au message de réussite de votre réussite.

    cas 2: - Pour les nouveaux utilisateurs, ainsi que cet identifiant d'utilisateur, votre application doit envoyer un jeton d'achat à votre serveur pour vérification et après vérification de l'achat, votre serveur doit envoyer un message de réussite.

    tâche commune: - Lorsque votre application commence, vous devez toujours appeler RestoreTansaction () après avoir obtenu une liste de Google contient des informations sur les éléments déjà achetés et vous déverrouillez ce contenu. Assurez-vous d'avoir une implémentation de vérification du serveur dans votre application.


7 commentaires

Merci pour votre réponse. Je n'ai pas pensé à garder un identifiant utilisateur unique. C'est une bonne idée! Cependant, n'est pas si utile pour moi, car l'application est uniquement client et je n'ai pas le temps de mettre en œuvre un côté serveur en ce moment. J'accepte votre réponse depuis que cela est de savoir comment cela devrait être fait. La solution pour moi, ne serait tout simplement pas chargée aux utilisateurs qui mettent à niveau, mais la prochaine fois, lorsqu'ils installent une application sur un autre appareil, ils seront facturés.


Comment vous allez vérifier si l'utilisateur a mis à niveau l'application ou à la nouvelle installation car lorsque l'utilisateur met à niveau n'importe quelle application Full APK Fichier est téléchargé à partir de Google Play et réinstallez l'application sur le périphérique de la même manière que la nouvelle installation de l'application?


Je suis au courant de ce que vous avez écrit. Ne pensez-vous pas que cela pourrait être un compromis équitable de commencer à charger les clients pour chaque nouvelle installation complète?


Oui, je suis d'accord avec vous, mais je veux savoir comment vous allez distinguer entre une nouvelle installation et une nouvelle mise à jour?


@ Bankit Si vous utilisez des préférences SharedPrefer dans votre application, vous pouvez vérifier cela pour les valeurs. Si c'est une nouvelle installation que les valeurs ne seront inexistantes si c'est une mise à jour, les valeurs seront là. Mais méfiez-vous si l'utilisateur désinstalle / efface les données de l'application, l'application pensera que c'est une nouvelle installation ... Je recommande de commencer à charger même les utilisateurs existants


Mais ces préférences SharedPreferences peuvent être supprimées si l'utilisateur a effacé les données dans Paramètres >> Application >> Votre application


@Ankit, je peux savoir si un utilisateur a mis à jour ou non en cochant certaines données dans la base de données SQLITE que l'application stockée.



2
votes

Voici comment vous pourriez accomplir partiellement ce que vous désirez, sans utiliser d'un serveur:

  1. Mettez à jour votre application avec une nouvelle version qui rédigera une valeur unique aux préférences partagées. Cette valeur doit être un hachage d'un identifiant unique au périphérique (ou au moins, que pas de nombreux autres appareils partagent). La raison pour laquelle la valeur devrait être relativement unique est de l'empêcher d'être partagée entre les utilisateurs ultérieurs. Si vous voulez survivre à une réinstallation, vous pouvez également l'écrire dans une zone de la mémoire externe de l'utilisateur qui ne sera pas supprimée lorsque votre application est installée.

  2. Attendez une période suffisamment longue pour que la plupart de vos utilisateurs actuels aient mis à jour la nouvelle version. Dans le processus, tous les nouveaux utilisateurs au cours de cette phase recevront également la valeur unique dans leurs préférences partagées.

  3. publier une nouvelle version qui ne pas écrire l'identifiant unique et qui permet aux fonctionnalités pour lesquelles vous souhaitez facturer seul si si soit l'identifiant est présent ou si l'utilisateur a payé via une facturation intégrée.

    Ce n'est pas parfait, mais cela pourrait permettre au moins la plupart de vos utilisateurs actuels de continuer à accéder aux fonctionnalités.

    Je ne sais pas si cela violerait votre accord avec Google Play et vous auriez besoin de vérifier ce problème vous-même. Le fait que vous ayez présenté l'application à vos utilisateurs actuels comme étant libre et souhaite maintenant facturer que certaines de ses caractéristiques puissent être considérées comme une fausse déclaration que si vous êtes grand-père dans vos utilisateurs existants et que l'approche que je viens de découvrir ne garantit pas que Tous les utilisateurs existants seront accordés avec succès.

    Notez que l'approche soumise dans une autre réponse qui obligerait à utiliser votre propre serveur semblerait avoir ces mêmes problèmes, car vous auriez besoin de publier une nouvelle version de votre application qui disposait de code pour communiquer avec votre serveur et il n'y a pas de moyen de forcer vos utilisateurs actuels à mettre à jour la nouvelle version dans un intervalle de temps spécifique. Sinon, comment allez-vous collecter les identifiants uniques qui identifient vos utilisateurs actuels sur la base de données de votre serveur, car les utilisateurs d'applications gratuites ne sont généralement pas connus du développeur?

    Une approche plus propre consisterait à ajouter de nouvelles fonctionnalités qui s'intègrent étroitement avec les fonctionnalités existantes, ce qui les rendent plus précieux, ainsi que tout contenu déjà entré à l'aide de Old caractéristiques plus précieux. Vous pouvez continuer à fournir des fonctionnalités existantes gratuites, mais chargez les nouvelles fonctionnalités.

    En prenant cette approche, aucun utilisateur actuel ne serait privé de fonctionnalité et vous pouvez également charger vos utilisateurs actuels (et non seulement les nouveaux utilisateurs) pour les fonctionnalités à valeur ajoutée. L'utilisation de cette approche pourrait être non seulement plus agréable à vos utilisateurs, mais également potentiellement plus rémunératrice pour vous, car vous aurez toute votre base d'utilisateurs actuelle en tant que clients payants potentiels.

    En outre, vous pourriez considérer que la popularité actuelle de votre application pourrait bien être due aux fonctionnalités pour lesquelles vous souhaitez maintenant facturer. Et ainsi, vous risquez d'attirer un flux continu de nouveaux utilisateurs une fois que ces fonctionnalités ne sont plus libres.


3 commentaires

Merci pour votre réponse approfondie. Je prévois de faire quelque chose de similaire à ce que vous avez proposé. 1) Je garderai une trace des utilisateurs existants (autant que je peux) en utilisant SharedPreferences. Je n'ai même pas besoin de libérer une version intermédiaire car je peux savoir si un utilisateur a mis à jour ou non en cochant certaines données dans la base de données SQLITE que l'application stockée. 2) Je vais ajouter des trucs cool aux fonctionnalités que je vais charger.


Rappelez-vous simplement que SharedPreferences disparaîtra sur une désinstallation, et aussi si l'utilisateur dispose de plusieurs périphériques, la valeur peut ne pas être automatiquement disponible sur ces périphériques si elle est installée là-bas plus tard. Charge forcablement nouvelle fonctionnalité semble toujours être l'approche la plus propre de moi, mais vous connaissez votre application, et vos utilisateurs, bien mieux, il se peut donc que, dans votre cas, la distinction entre les utilisateurs actuels et futurs est une bonne approche. Je crains que cela continue à distinguer vos deux classes d'utilisateurs puisse devenir un véritable mal de tête à l'avenir.


De plus, si vous utilisez une valeur existante écrite dans une base de données locale pour distinguer des utilisateurs droits et nouveaux, il est possible qu'une telle valeur puisse être fausse, à moins que vous n'ayez déjà un processus de validation en place (tel que j'ai décrit dans ma réponse).



2
votes

Bien que cela ne soit pas réalisable pour les applications avec un nombre important de téléchargements, à compter de janvier 2016, vous pouvez accorder jusqu'à 500 codes promotionnels par application par quart.


0 commentaires