@WittyAdrian That’s correct. If you want a holistic view, you can poll the subscriptions endpoints.
You mean the one where you get the entire list of every current subscriber? I was already thinking about that myself, but just wanted to confirm that that’s the way we should go for statistical analysis. Thanks for your replies :).
Will there be any updates to the subscribers API endpoint (https://dev.twitch.tv/docs/v5/reference/channels/#get-channel-subscribers) to add cursor like the followers endpoint (https://dev.twitch.tv/docs/v5/reference/channels/#get-channel-followers)? this will allow much easier polling the API instead of having to do a complete reload each time.
@billygerhard We don’t have any immediate term plans, but we do want to have all endpoints use cursors for consistency and better performance. It takes time since it would be a breaking change for folks that rely on offset/limit. I’ll keep the community posted as we add cursors to endpoints. 
@DallasNChains Followers have both options, so couldn’t it be added to work just like the followers end point? It wouldn’t break the current offset/limit method, but add the additional functionality.
@billygerhard It’s possible to have both, yes, but that’s up to the individual teams to support. The followers team decided to support both for now. The subscriptions teams may make a different decision for technology reasons. Each API is owned by a different team, so they have different capacity to support multiple pagination methods.
How many people running sub-announce bots in a channel that don’t get authorization from the broadcaster?
Why is ONE PATH better? The more ways and easier it is to acknowledge and reward someone for subscribing, THAT’S better. This change makes more work for every new sub to get acknowledged, that’s WORSE. You want it to be EASY and REWARDING for people who spend money and sub. “Code path” is a secondary concern to paying user experience.
@Dist
Feature losing: “[twitchnotify] 11 viewers resubscribed while you were away!”
Some advantages are simplification of code, both for Twitch devs to maintain and end users to implement as both sub and resubs now can use the same system. Subs now have the added benefit of being able to choose if/when to share and include a message, which was impossible before. I’m sure @BarryCarlyon or others could give a more in-depth explanation as they are a lot more experienced that me, but even as new-ish dev I have a lot of benefits to this change.
If you poll the API and compare the sub data from the end of the last stream, to the beginning of a new stream, you will see how many people subbed, or unsubbed during that period.
Subs and resubs are now completely the same for how they are handled it twitch’s code and in our own bot code.
This change makes it fully optional for a new sub to allow themselves to be recognised and they can leave a message for the caster if they choose.
It makes sense to have that on the video page so the new subscriber doesn’t miss their shout out. If they choose to ask for one by sharing their sub.
It can’t be done on the payment page in case there is a problem with coming back in time. And the payment page has to bugger off elsewhere to other places. So it can’t all be on the payment page.
And with regards to the x people resubbed. What use is it to anyone? I never had a use for it myself! Aside for some backup stream is now live notification.
Yes you can poll the api for the count. But the count isn’t clear to calculate. Since it would involve some math on sub creation dates and figuring out which people actually had a payment today
People running bots without broadcaster’s permission? How rude. Besides, those who do not wish to be announced should not be announced, but I’m guessing this is just something we’ll have to agree to disagree on.
So… because you don’t use it, you can’t imagine a case that anyone else would?
Why is that tiny minority (which noone wants to post any numbers about to support this “privacy” position) more important than all the people who are new to twitch or confused by the nonintuitive sub process? The ability to lurk-sub already existed, I just don’t understand why this is the only reason put forward for this change.
I asked “What use is it to anyone?” and your answer:
Whats your use case then? (I was on mobile and poorly worded my way of asking what your use case was). If enough people have a use case for it, I’m sure Twitch can re-add it. As I recall, the “X resub” message was added on a whim by a Twitch Developer anyway.
Twitch is working to fix that, as of right now, last I heard, you hit sub, go off to pay (If not Prime) come back and the “Share dialog” auto pops without the need to Reload the page, put a message in and hit share and you are done. It’s literally these steps
- Click Sub
- Pay or Prime (Pay goto 3 Prime goto 5)
- Go to Xsolla interface (And/Or Paypal)
- Do the payment/subscription setup steps
- Complete (offer to route back to stream page)
- Share Dialog appears at the top of chat.
The share dialog, allows the subscriber to input a message and make sure they are present in chat to see their sub appear. For example, I open the subscription system in a new tab to prevent video interruption, some people don’t and thus get stream reload. Before this, a number of people have been too slow coming back to the stream and missed the sub announcing on stream, and the inevitable:
“hey did the streamer see my sub”,
“Why yes”, I say, “it animated on the overlay at x minutes past this hour”,
“Oh”, they say. “I missed it”
Are you reporting a problem? Is this flow broken? Please report it to TwitchSupport on Twitter so it can be fixed.
Hurrah Spam reduction \o/
There are some channels where (before this change have not tested it recently), when I hit my sub/resub and boom my message is pushed off the screen because of the literal wall of bot announces.
I may be under NDA which I may or may not be able to discuss, with the caster(s) I may or may not work with and can’t discuss any statistics I may or may not have.
And, the key word here is “privacy”.
Most people will cite “lurk sub” because it gives users what users want, choice.
From a code and programming perspective:
You no longer have to parse what Twitch Notify says,
- You don’t have to parse TN to see if it’s on about a new Sub from a channel your channel is hosting
- You don’t have to parse TN to see if it’s a new sub or a resub
- You don’t have to parse TN to see if the user subbed with Prime
- You don’t have to parse TN to see if it is sending the “x viewers resubbed” message and ignore if for your sub notifier
And
- You don’t have to parse USERNOTCE to see if, Twitch sent the charity stuff over USERNOTICE with bad flags again,
What you do now is you write two lines of code to read a JSON object (yes ignoring PUBSUB setup lines of code, as I am IRC/WS Chat bot lines of code), and see if the context is sub or resub. And you can see if the NEW SUB, is using an International Display name, without having to use the Twitch Search API to guess who is subbing.
AND: everything comes over one route, rather than consuming two routes with the possibility of bad parsing.
AND: less CPU cycles and/or memory usage parsing data you are ultimately gonna ignore (unless you ARE collecting new sub data on a channel you are hosting, which I believe is probably against the Twitch Developer agreement)
Everything is now in a nice JSON object instead of having to parse what TN is saying.
2 Likes
- Giveaways run at the start of a stream based on if enough people resub. Gets people to want to get to the stream as fast as possible and encourages resubs of all kind.
- Useful for people who don’t want to write bots to poll the API to get the info as @Dist describes. You seem to want to keep forgetting that no everyone is, or wants to be, writing code.
So you quote an extra step, and don’t think it’s an extra step. IF a user wants their sub to be known in the channel a 6th step is now required. That’s more work. More work when people are paying money makes them less interested in paying money.
You’re blaming someone’s spam walls and poorly written bot messages for “needing” to put every new sub forever through extra work? That’s… very odd.
Which can be circumvented as @Dist has pointed out. It’s no private if I still have access to the data by polling the API. If the keyword is “Privacy” and you still insist on 1) being unable to provide data to support it being an important issue then b) the more intelligent solution would be to have a “Click this box to not share your sub” at the start of the process checkbox. That doesn’t create additional work for anyone else and lets the <.1% of users who are concerned about “privacy” feel a little more private. Applying more work to literally everyone else is the wrong solution.
You didn’t have to parse what twitchnotify says, any more than you have to parse join/parts, or usernotices, or bans or messages. You don’t have to parse any of it. Your bot can easily treat TN messages the same as any other user’s message without causing you any more code time or processing time.
Your whole “point” seems to be that “it’s tidier on the backend”. That should NEVER supersede a user’s experience. User requests are what computers are for.
1 Like
Requires the broadcaster’s explicit permission instead of some anonymous stat collecting.
An extra step that adds value to the payment. That makes people more interested balancing it out (potentially more than that, I don’t have the stats nor could I share them if I did). Changes aren’t done on a whim.
It’s difficult when it’s literally impossible until twitchnotify is removed and there are no extensive surveys on the matter. Most people will just accept the way it is instead of waiting for the quiet hours of the night, or won’t sub at all. We don’t hear vocal feedback from either of those people.
2 Likes
I don’t understand what you mean. It’s up to the developers to use the tools available to them to make their app, the ones using it don’t need to know how to write code. Not everything is, or should, be available through chat, if you want certain features or data you are going to have to use the tools available to you which is the API.
For someone who keeps going on about wanting statistics, despite some of us here not being able to disclose our work product, I haven’t seen you give any hard figures on this point. Yes, 1 click is more work than not having a click, but you are ignoring the value of that click by giving choice to the user, and you place so much weight on a click being ‘more work’ yet I would like to know how many users have complained about it? Not complaints about the poor communication about how sharing works, that’s a separate issue, I want to know how many people have actually complained about needing to press 1 button?
Now if a user wants their sub to be private they can as the only people who will see that info are the subscriber, the broadcaster, and apps explicitly authorized to access subscriber information.
So you run a giveaway based on the number of people who’s sub automatically renews overnight whether they are present or not?
I would argue it’s better to do a giveaway if enough people announce their sub/resub as part of a sub train would be greater value, other wise people turn up, see “4 people resubbed” then leave because they go “oh no giveaway is gonna be run”
This use case doesn’t account well for false stream starts or cases where a stream is restarted within a few moments of the stream scheduled start but thats a side point
I agree, now you have to write less code.
But because of this step you can guarantee the user will see their sub in chat.
Someone’s? No the twenty odd different people running a tiny mIRC script
Parsing what twitch notify says isn’t as simple as just parsing what people say for filtering and/or command responses, you have missed my point.
I don’t see a problem with the users experience here.
So, twitchnotify alerts just got removed, but apparently, I have noticed some of the USERNOTICE events are not working properly on my mIRC. And seems like this only happens on some re-subs. My mIRC received all of the USERNOTICE events on the debug window but not all of them appears on the status window as intended. Looks like this is a bug with the IRC system and not my side. Everything was working until twitchnotify alerts were removed.
2 Likes
@Jacky1356400 What do you mean by “are not working properly”? Also, are the debug and status windows specific to mIRC? I’ve never heard the terms. The Twitch implementation of IRC may not be compatible with how mIRC is interpreting the messages. This might be a side effect of that.
I actually forgot to delete that message. Everything seems working now after I restarted mIRC. And yes, debug and status windows are specific to mIRC only.