Solved

How do I structure offetings when users can subscribe to user-generated content?

  • 17 December 2021
  • 3 replies
  • 47 views
S
Badge +2

Hi!

I have a social app for which I want to implement something like Twitter’s super-follows. Basically the flow goes like this:

  1. User A can apply via email for eligibility for super-follows.
  2. We manually set user A’s metadata to reflect that they can now be super-followed.
  3. When user B tries to super-follow user A, they have to buy a subscription to user A’s paywalled posts.
  4. As long as user B’s subscription is active, they can view user A’s posts.
  5. User B can buy an unlimited number of super-follow subscriptions to other users’ posts.

Does this make sense? Can this be implemented via RevenueCat?

I’m adding images of how this looks for Twitter for reference:

Subscription screen

 

Subscriptions screen in settings (note the custom text for that particular super-follow of the user)

icon

Best answer by ryan 27 December 2021, 18:54

View original

3 replies

ryan
Rank
Userlevel 5
Badge +9

Hey @Stas! 

Good question, but unfortunately not a straight forward answer. Subscribing to user-generated content is becoming a more popular business model now but there are some special considerations you should think about with in-app purchases.

For starters, Apple limits the number of products your app can have to 10,000. They also require each product to be reviewed by their team so you wouldn't be able to spin up products on the fly. Twitter, Youtube, and other large companies that you've seen implement this business model have done so by working closely with Apple to get around these restrictions. So unfortunately there isn't a setup every developer could do to automate what Twitter has done with super-follows. 

That said, you mentioned an application process, so it sounds like if someone applies you could create the product, submit it for review, and add an Entitlement to RevenueCat manually if you approve their application. Hopefully by the time you hit the 10,000 product limit you may be able to get an account manager at Apple to help you get around this limitation - I honestly have no clue how this process works.

On the RevenueCat side each creator would have their own Entitlement that could be unlocked with their corresponding product.

You didn't mention it in your post, but some apps may want to pay out creators a percentage of the revenue they drive. You definitely want to give each creator their own product ID in this case, and don't pay them out until you get the financial report from Apple that shows the exact revenue (after taxes and fees) that each product ID generated for the fiscal month.

Another option I've seen apps do is build a coin-based system where customer buy or subscribe to an amount of coins that they could "pay" out to creators. I would say this does add some complexity on the development side to build a system to track the purchase and redemption of these coins. 

S
Badge +2

Hey Ryan! Thank you so much for the detailed response

 

 

You didn't mention it in your post, but some apps may want to pay out creators a percentage of the revenue they drive. You definitely want to give each creator their own product ID in this case, and don't pay them out until you get the financial report from Apple that shows the exact revenue (after taxes and fees) that each product ID generated for the fiscal month.

I’ve been thinking about doing this via my own backend, where I can see which users are subscribed to which creators. So I thought I’d infer the payout amount based on the subscription cost and the amount of subscribers for that user. Are there any common pitfalls with this approach?

ryan
Rank
Userlevel 5
Badge +9

I’ve been thinking about doing this via my own backend, where I can see which users are subscribed to which creators. So I thought I’d infer the payout amount based on the subscription cost and the amount of subscribers for that user. Are there any common pitfalls with this approach?

Whenever you’re dealing with real money, I’d error on the side of caution. Having a unique product_id for each creator solves a lot of these problems because you can be more confident people aren’t scamming the system through any unknown loopholes (since you’re relying on Apple/Google receipts). 

Common pitfalls to inferring the subscription cost:

  1. You don’t know with certainty any country specific taxes that Apple is applying that you can’t infer.
  2. You don’t know with certainty the exchange rate Apple is applying to transactions.
  3. Customers may request a refund through Apple after you’ve already paid out a creator.
  4. Apple doesn’t pay you until 33 days until after the close of their fiscal month (great blog resource). If you pay out creators on a more regular cadence you could run into some serious cash flow issues.

Reply


Terms & ConditionsCookie settings