You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This feels a little off-topic for the API spec but Dalton's blog on revenue sharing linked here, so...
Assuming the hosting economics work, consider:
Allow anyone to register an account and follow people for free
Only paid members get to post anything
App revenue share is based on fraction of posts for each user only (i.e. no read operations)
Deleted posts can't count and there should be some feature to enable spam reporting so offending apps get kicked out. You might also want to weight posts by visibility (i.e. more for public posts and less for private ones, possibly even on a scale for how many people they are addressing).
If you go with my other suggestion (#20) then you may also consider applying a log scale to the totals for each app before you compare them - so that games don't dominate and the revenue shares are more even across multiple clients used for different purposes.
A bonus for a post-only approach is that it will probably make sense for existing popular apps and websites to integrate another sharing option, even if the user-base is relatively small.
The text was updated successfully, but these errors were encountered:
One of App.net's models is GitHub. This is a free public repository on GitHub. Freemium is very different from free & ad-supported. With freemium, giving users a taste of what your product is like for free is essentially a marketing strategy.
One freemium approach is to allow users to sign in using their email address or OpenID for read only privileges without reserving a username. Freemium users can follow users but don't have a customizable profile on App.net and cannot engage with paid user accounts. Obviously freemium users cannot be followed because they will not be able to publish anything.
It is better to implement this freemium model for App.net since clients will be able to scrape multiple accounts for a locally created follow list anyway. Better in two ways, first there will be a sort of engagement that might be elevated to a paid account, secondly users can count their followers and get statistics of how often their posts are being viewed which is probably more important for journalistic and marketing users.
This feels a little off-topic for the API spec but Dalton's blog on revenue sharing linked here, so...
Assuming the hosting economics work, consider:
Deleted posts can't count and there should be some feature to enable spam reporting so offending apps get kicked out. You might also want to weight posts by visibility (i.e. more for public posts and less for private ones, possibly even on a scale for how many people they are addressing).
If you go with my other suggestion (#20) then you may also consider applying a log scale to the totals for each app before you compare them - so that games don't dominate and the revenue shares are more even across multiple clients used for different purposes.
A bonus for a post-only approach is that it will probably make sense for existing popular apps and websites to integrate another sharing option, even if the user-base is relatively small.
The text was updated successfully, but these errors were encountered: