Operator reward management

[bedeho]

Background

While distinct deployments of the YPP will involve distinct terms, almost all of them are likely to reward the following events

a) someone is verified as a real YT creator b) a video is synched c) a creator is verified as a real YT creator, d) pay depends on how many followers they have

Hence, being able to effectively determie who to pay, what amount and who may need further inspection or verification, will be key to being able to operate a YPP well.

Assumptions: Data Model

This proposal assumes that for each channel, the following information exists

1. Channel ID, URL and name on YT
2. A status indicating one among the following
   • unverified: currently being synched, initial status of all new channels that sign up in automated flow, hence no rewards should be paid out just yet.
   • verified: currently being synched, and some operator has explicitly green-lit this channel for rewards.
   • suspended: currently not being synched, operator made the call
   • opted-out: currently not being synched, end-user made the call.
3. Date at which channel signed up
4. All videos successfully replicated from YT to Joystream, where this means end-to-end upload 100% completed. Each video must have a publication ID and date on YouTube.
5. How many subscriber the person had upon signup, we don't update this.
6. Id of channel and channel account on Joystream.
7. The Id of another creator who referred them.

Assumptions: Reward Policy & Reward

A reward policy, as defined here, refers to a Gleev specific policy for it's YPP, and it defines.

• A list of follower count thresholds and reward multipliers: e.g. [(10, 1), (100, 4), (10000, 56)]
• A base $JOY amount for events a), b), c)

Computing the actual reward for a given channel over a given period in time involves the following:

• if the channel is not verified, then reward is 0, end of story. Otherwise add up the following
  • if the channel signed up in the given period, then use the base $JOY amount for this event
  • the number of verified channels which signed up in the given period and provided the given account as a referrer, multiplied by the base $JOY amount for this event
  • the number of videos replicated in the given period, multiplied by the base $JOY amount for this event
• multiplied this sum by the reward multiplier for the given channel

Proposal

The idea is to propose a set of tools which allows any operator to safely and effectively run a YPP, but still have enough flexibility to allow people to plug in their own secondary tools and processes.

User Story: Operator

• As an operator I would like to get a list of all channels for which there are some reward related events in a given time interval so that I can both review this data to determine how much to pay, and also determine who needs to go through initial verification.
• As an operator I would like to export this list (above) in a structured data format, so that I can further process it in other tools.
• As an operator I would like to see a list of all unverified channels, and update the status to verified or suspended on a given channel in that list.
• As an operator I would like to process the exported structured data format with another tool, which also takes my reward policy, and then outputs a structured data format which contains
  • some top line metrics, e.g. how much is gettin paid out in total, how many videos, etc.
  • time period information.
  • a list of channels which had relevant events and had reward > 0
  • channel id in Joystream
  • channel id in YT
  • channel URL on YT
  • channel name on YT
  • channel account in Joystream
  • total balance owed
  • short suggested autogenerated rationale: e.g. "10 videos, 2 referrals, payout tier x = 3450 $JOY"
  • a hash of the prior part of the report
• As an operator I would like some automated tool where I can load the output of the exported data in the prior story, and provide account/key from which I will draw funds, and then do automatic payment of all beneficiaries.

In the last story, one obviously would want the tool to

• ensure there is enough money to complete full payment
• allow operator to start at a particular channel id
• do payments interactively, so operator has to press enter before each one, otherwise the risk of failure, repaying multiple times, etc. will cause serious problems

API vs Website vs CLI

I'm really undecided on how to package all of tehse tools and experiences together. On one hand, I thin the best possible solution for Dmitry would be to ahve all of this as an integrated set of webpages that yt-synch bacend powers, perhaps allowing him to avoid doing any sort of manual exporting at all. On the other hand, that will start to create a bottlneck with updating and changing this, both for others, and also for Dmitry, when yt-synch maintainer is busy. It will also invariably lead us down the road of having it get too customised for Gleev vs. any app.

Perhaps its fine to just build this as a bunch of APIs+pages for now, where people can call the API directly if they want to, but also just use the webpages if they find it fits their needs?

┆Issue is synchronized with this Asana task by Unito

[dmtrjsg]

@bedeho thank you for putting this together, nice one 🙌

Just a few observations

1. We also compensate creators for referrals, so total reward must involve: Base amount for reward for referrer multiplied by number of channels that have Reffer_id= referring channel_id.
2. We also reward channels for manually uploaded videos, so this must be included into the events table.

cc @zeeshanakram3

[bedeho]

1. This was actually meant to be this case the number of verified channels which signed up in the given period, multiplied by the base $JOY amount for this event, but sentence was cut a bit short.
2. this one I don't think really works in any of this, best case is that you have to wrap it in some step in some of these tools, but now you are coupling in QN. I don't think we should do this, its not worth the added complexity.

[dmtrjsg]

@bedeho

1. Thanks for clarification 👍
2. I guess this can be done with a bunch of scripts where input is channel Id and data range and output is list of videos.. Which then can be added as a manual input in the tool we are discussing here? Or are you recommending to re-write the incentives towards YT sync exclusively?

[bedeho]

2. yeah just drop it, not worth the effort. Sorry to not have stood by ground on this before, hope it does not cause too much extra work or wastes work done.

[dmtrjsg]

@zeeshanakram3 please try and estimate this wrt to duration before Monday.

[chrlschwb]

How will manual video upload be compensated? Is there a separate tool for that, apart from the YPP payment tool? If not, would it mean that all content creators have to create a YT video first?

[bedeho]

Manual uplaods are not going to be covered, it became too operationally complicated to deal with that gracefully for us in Gleev YPP, compared to the expected value. Other apps are of course free to do things differently.