Monetizing Data Fields

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

So, you'll have to cook your own.

Grace period: DataField is essentially reset when you uninstall / reinstall so nothing will be bomb proof. As such, it is best not to lose too much sleep over it and hope for honest users. When I want a grace period, I set a value on first use and use that to compare and manage lock status.

Purchase and unlock: Pretty sure DataField has no web access. Certainly, there are lots of devices it doesn't. So you need to have some code and validation that you can supply through settings to control unlock.

Payment: Either roll your own or use somebody else's... I've done both. Currently, my datafield system (as per https://www.gdcsoft.com/garmin/help/datafield ) uses Kiezelcode's API (Home (kiezelpay.com) purely because the sums are too small for me to want to spend time managing taxes and the whole payment system.

Garmin isn't involved in payments at all.  How it's done is all up to you.

The only way you see a user's email is if they used "Contact developer" for something and included their email address. When you build your own payment system, you could include an option for the user to include their email address with a checkbox for "Send me tips and tricks?"

Not sure I'd turn something that's been free into a payment app.  That could upset people that have been using it for a while. I'd probably do it as a new app, so what's been free remains freww, but maybe end enhancements, etc on the free version.

Thanks! For a grace period I was considering a date/time cutoff. After June 1st, 2023, it won't work without a code. Something like that. I joined the Kiezel Discord channel and asked if there is a guide to walk me thru the process of turning my DFs into fee based. I'll look into that approach. THANK YOU!

Thanks Jim. I agree that asking for $3.00 for something they've enjoyed using for free for a few years could be upsetting. I do need to balance that.

9635560 said:

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

I'm not thought about trial apps for years.  I was there at the summit where they were announced in a breakout (2017?).

I seem to recall you had to be approved by Garmin to have them, and you still needed your own payment system.  There is then a handshake with the store so the user gets sent an unlocked version of the prg.

It'complex to setup/use which is probably why you don't see things in the store that use "trial apps"

Faced with a similar problem a while ago, this is what I did...

1. I released an update that explicitly and automatically sets the unlock key

2. I waited for what I considered long enough for people who were actually using it to update (thus explicitly unlocking the installed version)

3. I released a new update that meant new installs had to unlock

4. I added a note to the page (that, of course everybody reads and nobody ever skips past :sarcasm: ) to say that I had done this and that any prior users who felt they should be unlocked should contact me for an unlock code

Maybe because nobody really cares, or maybe because the system works, this went smoothly and the field is now one of my top sellers.

I like this. I could add my e-mail addr to the Garmin screen for those using the DF that need an unlock code for it to work. Maybe even a transient message starting a couple of weeks ahead of time that an unlock code will be needed soon.

How did you manage payments and code distribution? If you have a LARGE number of users, manually processing the payment/code interactions would be time-consuming.

Garmin doesn't handle purchases. You can use https://kiezelpay.com/ with secure, payment but this needs network, or even PayPal and sending out some static code, but then it can be shared by anyone.

I am trying to add payment to my DF, and I am wasting way more time on just to add this that whatever amount I expect it to ever pay, so it's a double waste of time.

In my case I'm also a) supporting old devices with only 16 or 32K memory, b) already tight on memory, so this more or less means it's impossible to add it to the existing app (keep the same id in the manifest), because if I add Background permission then I need to add (:background) annotation to lot of places, and it just keep on coming... And even adding all these to the older devices, without adding actual code there increases the code size.

This could work. If your DF records fit file as mine you can even ask the users who claim they already used it when it was free to send you a link to such an activity. They can still send their friend's activity, but it's one more lie they have to do.

I do use FIT writes. I could even WRITE to the session the device S/N and use that to generate a unique code. But the issue with Session writes is that only 1 gets written. If there is more than one DF that records a SESSION string, only one gets written. It may be a random race condition to determine which DF's Session string gets recorded? In my case I would expect current users to pony up the $3.00 for continued lifetime use after a grace period. But I need to figure out an easy way to get $3.00 payments (PayPal Friends/Family?) and an efficient way to generate a unique code based on S/N.