Roku Developer Program

[wpinkman]

I'm been experimenting with a freemium model which consists of two channels:

1) a free trial (free channel)
2) paid, premium, version

These two channels are essentially the same codebase,

#1 can upgrade to #2 using ifChannelStore.DoUpgrade() and this all works fine.

Now add in the wrinkle that I'd like to offer a free upgrade to some users (you can imagine all the uses cases here). I've been using the test users facility and it works like this:

1. user click upgrade
2. two choices:
2a: purchase upgrade -> ifChannelStore.DoOrder,DoUprade,
2b: earn free upgrade ->ifChannelStore.GetPartialUserData('email'), I add email to testers list, I send user an email explaining that they are free to upgrade

I'm finding that 2b. is cumbersome. There are manual steps involved which slows it down, but I think the main issue is that even as a test user the channel store still shows them what appears to be a full charge. Only later, if they follow through, will they discover an invoice for $0.00 because they are on the testers list.

I attempt to explain all this in the email I send, but I'm afraid it's not enough, so I've been contemplating a different upgrade scenarios that I just do myself using flags on my backend database. This solution has several drawbacks:

1. I have to do the work 🙂
2. tends to be tied to a device, not a roku user which is a discouraged practice
3. impossible to change the actual channel (branding, posters, etc.)

My purpose in writing this is to start a discussion about best practices for this situation (I'm sure my channel, Rokagram, is not unique in this regard), and to ask about the possibility of two tweaks from the Roku side:

1. an API to manage the testers list
2. a flag on each tester "nocharge" which results in them seeing a $0.00 price when they upgrade.

I believe the second one is most important.

[TheEndless]

"wpinkman" wrote:
2. tends to be tied to a device, not a roku user which is a discouraged practice

Why not tie it to the email address you're already getting in 2b above?

"wpinkman" wrote:
3. impossible to change the actual channel (branding, posters, etc.)

Why can't you change the branding based on the user status? You can't change the home screen icon, but there's no reason you shouldn't be able to change the in-channel branding.

"wpinkman" wrote:
1. an API to manage the testers list
2. a flag on each tester "nocharge" which results in them seeing a $0.00 price when they upgrade.

I would disagree with both of these, at least as far as the subject at hand is concerned. Using the testers list is a workaround at best, isn't at all scalable, and doesn't allow you to control access to individual channel products (e.g., it's all or nothing, so if you want to give access to one paid feature, but not another, you're out of luck). I think what Roku needs is a way to issue coupon/discount codes.

[wpinkman]

Thanks TheEndless.

Yes, not very scalable. This technique did work well for a beta test, but that's a unique and smaller audience of early adopters.

I agree coupon codes would be a better way to go and a pretty common practice. I've done integration with other API's (Walgreens QuickPrints for example) that have a billing component and discount codes are usually a part of the mix.

I also agree the whole concept of using the test user facility is a bit of hack, which is mainly why I'm posting. Hoping there is a better solution out there.

[EnTerr]

How about if Roku API starts providing a unique account ID (a synthetic number / GUID) somewhere? With no need to ask user to "share or not share" PII (Personally Identifiable Information) of ifChannelStore.getUserData().

Using email address from ifChannelStore is closest to that but bad idea long term, since users may change email while keeping the same Roku account. Thus email IDs are unreliable.

If such unique ID is given, you can build on it whatever system of coupons/codes you please - and more. I think for RokuCo to provide specific coupon/discount facility - that is too narrow of a corner to work in. Should think more general, yet simpler.

[wpinkman]

I think a unique, opaque account id that does not require the user to be prompted is a good idea. If this was the "Roku Account" number seen in the "Transaction Details" report that would be most useful.

It would also provide a way to correlate users who have more than one Roku in their household.

If I had this, I guess I could have two channels based on the same code base but loaded into the store with different price tiers and different channel store branding (but identical theme and manifest file contents). Code would be 99% identical, but there would be some flag which defaults to "free" or "paid" depending.

Simply by setting a flag in the registry, the free version could morph into the paid version and then I could come up with any scheme to set that flag. In my case, I'd probably set the flag on in my database for that Roku account, and at next run of the channel, it could be retrieved and stored in the registry (and I'd probably show some one time screen saying "congratulations, you just got upgraded").

In other words.. I'd use ifChannelStore for "purchase upgade" and my own flag/mechanism for "earn free upgrade".