I agree, you can already link to twitch in the embed by clicking their name, or “twitch” and there are already a ton of overlays that make the embed experience bad alone, now this just makes it worse. This is going totally against discoverability. I’ve found so many new broadcasters outside of twitch because of embeds. IF these types of popups are used, it should ONLY be on unauthenticated sessions. If someone is already apart of twitch, and they purposely go outside of twitch to change their experience, they won’t want you bugging them to bring them back.
I agree with the above as well!
I think there are different usecases of Embeds that have very different expectations / requirements to them.
I’d say there’s at least:
- Those that just want a raw feed and don’t intend to redirect users to Twitch as they enhance the experience outside of the player. Prime example: lolesports.com - or even just any sort of usecase where you want to, for example, restream the stream, like for a speedrunning marathon or tournament. (The “enhanced experience” can oftentimes be covered by a well-made Extension, but companies are slow to adapt to them, i think. And they obviously don’t cover all usecases of this category.)
- To promote a set of different streamers and get them known - in this case i think a CTA to head over to Twitch is very well placed. The discovery intent has happened and the initial few minutes ought to be sufficient to let the viewer know if they want to commit to the channel or not.
- Promotion through advertisement placements. This is similar to 2), but with the distinct difference that the Embed was shown to the viewer unintentionally. In this case, it should most certainly stop playing after a while to avoid using up background resources for everyone involved. (Because let’s face it, the people talking here uniformly don’t usually check out ads and rather ignore them. No need to waste resources in that case.)
One thing i could see happen: Be similar to OAuth Applications or even Extensions, where a registration is necessary with a traceable point of contact in case the embed gets abused. This allows for the different categories of Embeds to be placed in the different usecases and enhance the experience for everyone involved - if you want to help discover new streamers, you get a CTA, in an Ad, it stops wasting resources after a while and in a Tournament/Marathon/Restreaming environment, no unnecessary UI is blocking the feed.
It restricts access to embeds greatly, but i think it very effectively solves the issues at hand - In My Opinion.
And to address the usecase of Multitwitch/Kadgar/similar - this could be adressed by making squad streaming available to more broadcasters. I don’t see it necessary to use such an external tool if the afilliates I watch doing a race if squad streaming was available to them.
Until this becomes available, I very much support the usecase of undisturbed multi-viewers.
[And just to reiterate: This is just an opinion and a solution that i see that does not come without its own set of issues.]
1 Like
Thanks for this detailed feedback and consideration. As touched on in the original message, you outline the interrelated and complex potential use cases that this test will hopefully inform in a way that accounts for how to consider each one, both individually and in relation to one another.
Thanks for this feedback. Tests such as these will help inform potential monetization opportunities in the future.
Thanks for this feedback, particularly regarding embeds’ role in creator discoverability and unauthenticated session ideas. Tests such as these will help us make those distinctions in the future for a more accurate accounting of those differences, which in turn should hopefully make creator discoverability more contextualized and effective, as well.
Your rhetoric is disingenuous, suggesting that devs are presenting complex edge cases and not the most basic usage scenario of an embedded stream - placing it on a page along with some supporting content.
These use cases are very straight-forward and all resolved with the simplest technical solution possible – a parameter flag that disables the “feature”.
3 Likes
There are also creators that pay for custom pages such as on streamlabs, like streamername.live that embed their own stream to their own website, and this would also make loyal viewers leave that broadcaster’s own page.
1 Like
I appreciate the follow up here, as that was not my intention and I hope not to misconstrue. My feedback for that particular comment was related to the “expectations” of viewers/creators/devs and how their interrelated nature can shift in complex ways depending upon a number of different possible contexts. There is a lot still to learn here, and so this is not a permanent feature in any way as of yet. I do hope to be as transparent and constructive as I can here in this space.
1 Like
I think this test should be optional, but not required. It really changes the format a lot (embeded code) forces the user to open a second page.
Whether you block the entire screen or you provide a popup like this that is closeable, it’s clear the intention is to make it annoying or way less optimal enough for people to go to Twitch. But why do that?
Discoverability and marketing has always been a big part of this initiative for Twitch. I feel this move is just going to cause less people overall to be watching whatever streams would have been included in embeds.
If the issue is a monetization issue, why not just run ads on the embeds or come up with more ways for people watching on embeds to become Twitch subscribers. I don’t think many here would complain about that versus these annoying methods of blocking the visibility of the embed.
1 Like
I understand this cannot be turned off from settings? This greatly influences our use-case as well 
No
You should describe the use case to help Twitch understand why you don’t want this popup on your use case
We are using Twitch for online quiz events as it is the only video platform that seems to provide a constant and low delay. Since players interact with the quiz software in real time, it’s important that we are able to predict a consistent delay. For twitch we have found we can use a delay of about 4 seconds and all viewers stay within an acceptable treshold. The quiz software itself uses this delay to … well, delay the communication with the player devices.
However, we have found that twitch tends to get ‘out of sync’ if viewers have poor internet connection. If too much packets arrive ‘too late’, the viewer stream gets out of sync.
We have found out that with the javascript sdk we can measure/estimate the delay of the video. If this delays goes above a given treshold (about 8 seconds if I remember correctly), we pause and unpause the stream in javascript. This causes a stutter in the livestream, but it also makes sure that the viewer is ‘back in sync’.
Obviously this is only possible when embedding the stream, and that is our main reason why we don’t want to send our viewers to twitch: this ‘fallback solution’ does not work on the twitch framework itself. In those cases, we get support messages from people saying they are getting out of sync, and the only thing we can say is: please reload the twitch webpage.
I understand this is not what twitch was developed for, but this solution was working fine for now 
And now, with this popup, it kindof breaks our use-case.
As a side note, you could do a Twitch extension as that also provides the delay time (when running as a video extension, panels have a “fun bug”). You won’t be able to auto pause/play, but you will be able to delay buttons appearing until the right time in the stream (I use the delay to match buttons on the video players to OBS scene changes), and/or if the delay is too great prompt the user to pause/play.
Then you are on platform and intergrated nicely, (and can provide a in Twitch App expereince for mobile users)
1 Like
Hi
We really aim for the ‘second screen experience’, where one twitch stream is watched by multiple people in the same room, and each player uses its own device to answer. We’ve experimented with injecting audio watermarks that are picked up by the smart devices of the players… but that was a little too experimental
So I can’t see any way to get the second screen in sync with the the video stream
Greetings
Thijs
We use the embed code to display our stream on digital signage in our esports facility at the University of Kentucky. These screens have no user input. The popup breaks this functionality as it completely interrupts the stream. Our goal with the signage is to publicize and attract students to our Twitch streams when they are away from the facility. Please add a way to suppress these messages or remove it entirely so it doesn’t break digital signage.
2 Likes
To go along with that, my local retro store has twitch on a display looping channels too. Any of these kiosks would break from this too.
1 Like
We have a similar use case in which we’re pulling player feeds for our esports events since we cannot have players on-site. In essence we’re using a set of Twitch streams instead of a local switcher.
1 Like
I’ve already brought up some of my use cases impacted by this elsewhere, but I’ll add to the thread to keep everything in one place.
One of the events I worked has an LED wall, and one of our scenes displays streams with no easy way to interact directly with the embed. This previously was only an issue with Mature streams, where we couldn’t click the dialog box to accept, but we could handle that by just choosing other streams. This is an unavoidable issue though that impacts the experience so the studio was already considering alternative solutions since the purple wall of text change, and now this experiment has made the final decision to use ‘alternative’ methods of displaying streams.
Similarly, we have also used embeds in production of a large esports event on Twitch, where with permission from all the channels involved we included streams from 6 off-site teams, totalling around 12 Twitch streams we were utilizing. One of the ways they were integrated into our production was through a simple page with the embed on it and used as an input. This is now no longer possible without a way to guarantee viewing of the embed will be without disruption, as without that assurance we’ll need to use other methods to achieve that same goal.
And one final use case, in one situation we had a multiview of all our streams going live (1 event, in several different languages), so that at a glance the producer could ensure all streams were up, and easily monitor audio as it appears on Twitch. Again, this is no longer a suitable use if the embed is disrupted by this experiment, and the purple wall of text.
2 Likes
Thank you for your feedback on this unique use case. I would recommend leaving information regarding this particular implementation in the Embed Feedback form mentioned in the original post so that it can be logged and potentially mitigated.