Monetizing Data Fields

All my data fields are free. I have a collection of pretty cool fields used by a few thousand cyclists, mostly for serious ultra-distance types.

I just wrote these for my use but offered them in the marketplace.

I'm thinking of converting these to fee-based. Something like $3.00. Not much. But I want to write quality user guides and spend more time testing and making the set of fields have a consistent UI, color scheme, etc.

I was thinking of adding code in the next versions that allow the fields to work for another couple of months, as a grace period before they need to purchase the fields.

Is the process of buying a data field very easy for the user? Does Garmin handle the authorization to use, and process the one-time payments on my behalf?

Is there any way to know who is running my data fields? For example, to send them use tips, a link to updated Google Doc based documentation, etc?

Thanks!

  • They can use the "Contact Dveloper" link to reach you.

    I had two iterations of payment... a home-cooked one using Paypal and a partially home-cooked integration with Kiezelpay API.

    But essentially... for CIQ after (I think) 2.3, there is a unique identifier value that is unique to the DF and device (I think). Otherwise, you can use storage and generate a value of your own.

    1. On first run of the DF (has to be added to a datascreen and then viewed on the device) you can write a calculated value into storage that is a digest of the UUID, your own app identifier (up to you) and (optionally) a checksum value and also set a value in settings for the user to see.

    2. User can send you that key by reading it from settings or, if you're cleverer than I am and can make the key _REALLY_ short... on screen... sending can be whatever, in my case, a web form, but email works too, if the numbers are really small

    3. (Validate code with checksum, if used.) Extract app id and identifier, process purchase, generate revised key and checksum.

    4. User saves revised key to DF, DF reads key, validates checksum, validates key, unlocks.

    For me, that is done via my server with a service to contact Kiezel's API. But you can do it however you see fit, dependent on the number of users.

  • Regarding grace period: i would make sure to write a notice in the beginning of the description AND what's new not to upgrade if they don't want to pay. This will make somewhat fewer angry users. Plus later the new features will be at the beginning of what's new so even some cheap users might consider upgrading.

    Look at the unlock feature in kiezplay. That is one scenario that you'll also need to solve: paid, uninstalled, reinstalled, or (depending on whether you define the license to be per device, or per user) when the user moves to new device.

    And what you might also find that you'll have to deal with refunds.

    As for the multiple datafields on in one activity: if you have 2 datafields then use a uniq field name in each. Or consider bundles like in kpay. They told me most developers do the big money by selling bundles.

  • (If anybody told you "big money", they ... um ... at the very least exaggerated even if their idea of "big" is quite "small".)

  • That works if your licence is per device. If you want it to be per user and allow it to be moved to new device then you need something more complex or you give up some of the security because bad guys can share or even sell the "movable" license if it's not invalidating it on the old device (which needs network)

  • yeah, it's big money, not BIG MONEY Slight smile

    Search in this forum, in the past 2 weeks there was some talk about it, and the founder of KPay gave some numbers. If you join their discord channel there you can also see some stats.

    Personally I'm still hasitating, but probably it's not worth the effort to add to an existing datafield, if you support old devices that have both memory problems and network problems in datafields. If you do start a new datafield from scratch then maybe.

  • Although Garmin docs mention an unlock system, I have yet to see examples of... anyone... actually using it.

    There are not many examples, but this developer is using it: https://apps.garmin.com/nl-NL/apps/b9f2f705-4094-4a03-a7d1-8059c2607909

    I like that the download button has the same visibility as the unlock button

  • That's NICE! This could be a good way, and if I understand correctly then Garmin is doing most of the stuff, and the only thing left to us to do in the code is to call AppBase.isTrial(). The only question is if the license is for the app on the device, or for the app + user (which enables him to put it on multiple devices and to move to a new device)

  • That's honestly the _first_ time I've seen it in use! Suddenly it makes sense and I want to find the docs for it.

  • You can also use this to sell, generate and monitor unlock codes
    https://pay-to-use.com/

    And you will see your customers