The Alex (2h) 27/3/23

[richardbirkin]

No Pentrich! Denied!

Greg told me about Jeremy Keith talking about things about design and the web. This is a reminder for me to check his talks out.

Before coming out to meet, Greg was listening to Queens of the Stone Age and heard the lyric:

"Not everything that goes around comes back around"

• QUOTSA, Like Clockwork

I think we were discussing when the design style for old beer adverts and pub mirrors is going to come back around.

Revenue Splits

We talked about Revenue Splits being the next logical thing to add to the Bandcamp import - what we hope will becomes Trackshift for Labels.

What value are we adding?

So a label knows who the money is for.

How?

Show how income is split at product level.

What does it look like?

Product income: £1000
Artist share (50%) = £500
Label share (50%) = £500

If there is no Revenue Share data to begin with, the label is shown as 100% share holder in the table.
They can then enter a Revenue Share. Could be 50/50. Could be 80/20. Could be 70/15/15 if there are more than two Parties.

It always adds up to 100%.

User imports a Bandcamp Statement.
User sees table of Products and Amounts.
User adds Parties to the Product.

(party(s), not people (yet))

For example, the label is only interested in paying The Band, not the individuals in The Band.

Money comes into label.
Label work out revenue splits between Label and Band.
Label pays money to Band.
Band decide how to split (e.g. pay the rent on the practice room, then split the profit 5 ways)

This is different from how Writer Royalties work, which is what you get from PRS.

A Party could be an individual, a partnership (band), an LLP, a management agency.

Bandcamp API Integration

Once the Label has entered the Revenue Split for a Product, they don't have to again. And once we're hooked up to the Bandcamp API then ideally no-one would have to log in, it would all JUST HAPPEN.

What's Next?

Periods.

We have the money coming in.
We have who the money belongs to.
Now we need to show WHEN the money has come in and gone out.

For this we need to consider an Accounting Period, that could be just months, or quarters, or custom to a Label.

[g105b]

Following on with some thoughts about how to link this up to our data structures...

I want to clarify the terminology we're using, so I can understand how this data structure looks, and whether the same generic data structure can be used to define all areas of the system.

The way I understand it currently is that we have the following main Entities of the system:

• Label - representing 0 or more other Label Entities, and 0 or more Band Entities
• Band - representing 0 or more BandMember Entities, and 0 or more Product Entities
• Product - an abstract Entity that can be things like MerchProduct or AlbumProduct, representing 0 or more ProductSale Entities, and 0 or more ProductStream Entities

When sale/stream data is uploaded, the individual distinct elements in the upload need to be allocated to the according AlbumProduct, and next time they're detected they will be automatically allocated.

AlbumProducts are internal to TrackShift and have to be configured by the user in the web app - they are not inferred from any data source.

Another key point we made:

If you upload something, then your user is the owner of that data. It might happen that multiple users end up uploading the same data. That's OK - they will just see their own version of the interface and don't need to know of each other's existence in the app. We don't need to worry about merging user data at this point because it's likely that this will never be a problem anyway.

@richardbirkin please can you read over the statements I've made above to see if it makes sense what I've said, or if you think something is wrong or needs more detail?