(Feature Request): Gather data from YouTube Studio

[Nubebuster]

Extension or Userscript?

Both

Request or suggest a new feature!

Most content creators also disagree with the removal of the dislike button. Wouldn't it be a good idea to give content creators the option to share their dislike amounts automatically when they open the analytics on YouTube Studio?

This would have to be an opt-in future. I reckon it would be a good idea to ask new installers whether they want to share that data or not when they first open YouTube Studio with the extension/script installed to make sure people are aware of the feature.

This is a low priority feature as it can take a while to implement this. But once YouTube stops sharing the numbers in their API, methods of collecting data such as this are vital to ensure the quality of predictions remain high.

Ways to implement this!

We can check if a user is on creator studio and determine which video they are analyzing by checking the URL.

https://studio.youtube.com/video/VIDEOID/analytics/tab-interest_viewers/period-default/explore?entity_type=VIDEO&entity_id=pYRMBktRcjM&time_period=since_publish&explore_type=TABLE_AND_CHART&metric=LIKES_PER_LIKES_PLUS_DISLIKES_PERCENT&granularity=DAY&t_metrics=LIKES_PER_LIKES_PLUS_DISLIKES_PERCENT&t_metrics=RATINGS_LIKES&t_metrics=RATINGS_DISLIKES&dimension=VIDEO&o_column=LIKES_PER_LIKES_PLUS_DISLIKES_PERCENT&o_direction=ANALYTICS_ORDER_DIRECTION_DESC
<div class="value-container layout horizontal end-justified style-scope yta-explore-table-row"><div class="value debug-metric-value style-scope yta-explore-table-row">0</div><dom-if restamp="" class="style-scope yta-explore-table-row"></dom-if></div>

When a user does not inspect the Likes amount we can determine the amount of dislikes by calculating them from the Likes percentage on the main video analytics page which looks like this:

<div class="percentage style-scope yta-table-card" style="width:100%;background:rgba(235, 93, 166, 1);"> </div>

Can you work on this?

• Yes
• No

[Anarios]

Yes, it's in plans.

[174n]

I don't think the creators have the ability to prove the number of dislikes they are sharing is legit

[SkyyySi]

The extension would need to provide some kind of way to prove that the user submitting something is actually the channel. Perhaps making it require linking the extension with your account first could help.

[elaine-jackson]

I don't think the creators have the ability to prove the number of dislikes they are sharing is legit

That's true, it would be the honor system, we could likely detect cheating by rouge creators, for example if they report less dislikes than extension users have sent. We could also, while the API is shutdown, require YouTube creators to verify their channel with the Google API to make sure that only the channel creator can submit stats for their channel to the API Server vs anyone with a Python script, channel ID, and some time.

[Nubebuster]

Good point @174n

[mphelp]

@irlcatgirl I like your idea for a quick and easy litmus test by checking archived dislikes against what they report.

[sy-b]

I don't think the creators have the ability to prove the number of dislikes they are sharing is legit

That's true, it would be the honor system, we could likely detect cheating by rouge creators, for example if they report less dislikes than extension users have sent. We could also, while the API is shutdown, require YouTube creators to verify their channel with the Google API to make sure that only the channel creator can submit stats for their channel to the API Server vs anyone with a Python script, channel ID, and some time.

To find rouge creators, we'll need to compare known dislikes with reported ones.
& its not possible after 13th

If #56 and/or this is completed before 13th, then possibly we can have time for that.

Anyone willing to start work on that?

[elaine-jackson]

I don't think the creators have the ability to prove the number of dislikes they are sharing is legit

That's true, it would be the honor system, we could likely detect cheating by rouge creators, for example if they report less dislikes than extension users have sent. We could also, while the API is shutdown, require YouTube creators to verify their channel with the Google API to make sure that only the channel creator can submit stats for their channel to the API Server vs anyone with a Python script, channel ID, and some time.

To find rouge creators, we'll need to compare known dislikes with reported ones. & its not possible after 13th

If #56 and/or this is completed before 13th, then possibly we can have time for that.

Anyone willing to start work on that?

We can't get perfect accuracy but:

1. If a creator reports less dislikes than dislikes reported by the extension that may be a sign of dishonesty.
2. If the dislike to view ratio is considerably different than the dislike to view ratio by extension users.
3. We can compare the data they report against https://en.wikipedia.org/wiki/Benford’s_law as an additional anti-cheating mechanism.

[sy-b]

1. If a creator reports less dislikes than dislikes reported by the extension that may be a sign of dishonesty.

👍, but only valid till 13th December (+/- 1-2days)

2. If the dislike to view ratio is considerably different than the dislike to view ratio by extension users.

extension users are way too less, for this.

3. We can compare the data they report against https://en.wikipedia.org/wiki/Benford’s_law as an additional anti-cheating mechanism.

👍

[sy-b]

(Most of it it was discussed on discord but I am mentioning it here again)

It is possible for creators to get an API key with read only scope & share it with backend. This way the backend can get dislikes & without creator's intervention.

But it has its own problem that - what if an API key was stolen from creator and provided to backend.

• If creator wants to stop RYD from using their API key, their are 2 ways
  (i) Disable the key from their side
  (ii) Ask RYD server to stop using key. This would need some contact information to be shared with RYD.

To address the problem and point (ii), creators can be asked to provide their email ID.
But then backend will also need to verify in some way that the email ID holder is a person who has some authority over the channel.

[aidanhasaknife]

perhaps this issue is a good candidate for pinning? there have been several duplicates of it...

yes, it's planned
@Anarios in #21 (comment)

In plan
@DARKDRAGON532 in #329 (comment)

[floriegl]

Ask RYD server to stop using key. This would need some contact information to be shared with RYD.

Wouldn't it just be possible to have a second form where they input the same API key again to tell RYD to disable it? No one except the creator and RYD should know the key anyway.

[Blitszy]

I'm probably just stupid because I have no idea how to do this but could the extension ask for permission to collect Youtube Studio data, send it to the DB and update it that way? Maybe then they can't lie since the plugin is collecting the info and the user isn't submitting anything, they just answer a prompt.

[sy-b]

To get data from YT studio, extension will need permission to studio.youtube.com, which should be declared in its manifest.json.

If we add that, the browser will automatically disable the extension and all users will get a prompt asking if they want to permit it or uninstall it (& maybe to keep the extension disabled).
This had happened once (with http://localhost) and the result was not good.

Amount of users dropped by a non-trivial amount. It was significant number back then.

It was a mistake but, we all learnt that adding a new permission isn't going to be a good idea.

But there's hope.

This permission is called host_permission. In other words - what websites can this extension access.
There is a features called as optional permissions but not optional_host_permissions. This is pushed to git but I don't know when it'll be released.
This will allow us to declares permissions but users wouldn't be asked until they visit the site. And the extension wouldn't be disabled automatically.

Edit: While writing, I just fact-checked myself & found that optional_host_permissions was just released in chromium v102. So, yes now it is possible to do that

Now problem 2:

How can we be sure that whatever is being submitted isn't being tampered with?
(There were very long discussions)

Maybe then they can't lie since the plugin is collecting the info and the user isn't submitting anything, they just answer a prompt.

They can.
You and many others suggested that the a extension should read from YT studios & then send the data to RYD server.
There are 2 points here.

1. Extension will read from YT studios
2. It will send the data to RYD server.

I'll start with the second one -
It is very easy to make a script/app to send the data using the API used by the extension. (i.e. mimicking the extension.)
This is actually a good thing as it allows this functionality to be easily implementable in other apps.
If we simply collect & send, then there's no way to distinguish between genuine & fake data.
(There are other ways but they are too complicated)

First Point:
There are lots of ways to change the data on the website.
Here's an example of one of those - https://testableapple.com/note-6/#dont-take-seriously . (Just 11 lines of python code)
Except this one, all others can be prevented just by collecting the data immediately when the page loads.
It can be detected, but it'll eventually increase the complexity.
Also, it isn't worth the effort if we consider point 1.

And as far as the dislike submission is concerned, I do have plans (but not time) to make it, but it'll be too complicated for non tech-savvy creators. So, I don't expect many creators using it. (This is one of the reason why I don't prioritize it)

[cyrildtm]

Just to add to you @sy-b , (1) MITM attack is as widely and conveniently used as local ad filters like pihole (I believe so; haven't used) There's no easy way to get around official API in terms of authentication -- why don't we already have a FAQ on why it's been so long and no creators database? (2) can we separate the viewers app from the creators app? Just make it a unified version with a hard-coded switch during compile/build, don't enable the uploading functionality for the viewer edition.

[sy-b]

can we separate the viewers app from the creators app?

Yes, but I'll prefer a single app.
But I don't have a strong opinion.

[Sainan]

Can't believe it's already been over 2 years, but just thought I'd chime in here to say that this might be something to prioritise because there is a real concern about the numbers reported by the extension being vastly different than reality.

I think the idea of having a separate extension is a good way to avoid adding a new permission, but it might also be possible to have it not be an extension at all, instead make a web app that creators can authorise and then you use the Metrics API to fetch the required data?