Retention in iGaming is a harder problem than acquisition. Getting a player through the door is a solvable budget equation. Keeping them engaged once the welcome bonus is spent requires giving them reasons to come back — and those reasons have to compete with everything else competing for their attention.
Increasingly, that "everything else" is live content: Twitch streamers, YouTube gambling channels, Facebook groups. The irony is that operators often have the content — live game sessions, hosted events, dealer streams — but no systematic way to reach their players on the platforms where those players actually spend their time.
That's the problem our re-streaming solution was built to solve.
The retention problem, precisely stated
An operator has three audiences they typically can't reach effectively with live content:
- Inactive players — accounts that haven't logged in for 30, 60, or 90 days. Email campaigns have declining open rates. Push notifications are blocked or ignored. But the same player might spend three hours watching a Twitch stream on a Wednesday evening.
- Existing players between sessions — players who haven't churned but aren't currently playing. Live content on the platforms they already use keeps the brand present without requiring the player to visit the operator's site.
- Potential new players — audiences on Twitch and YouTube who are already interested in gambling content but aren't registered. A branded live stream is a direct acquisition channel.
Live sessions become marketing when they're distributed to the platforms where audiences already are. Viewers on Twitch who click through to an operator's site during a live session are warmer prospects than cold traffic from a display ad. The stream is the ad — and the content is what the operator is already producing.
How the re-streaming pipeline works
The technical foundation is nginx with the RTMP module, running in a Docker container on AWS ECS. The operator's streaming setup (OBS, Streamlabs, vMix, or any standard encoder) sends a single RTMP stream to the ingest point. From there, everything else is automatic.
The single stream reaches all destinations simultaneously. The operator runs one encoder, manages one stream key, and appears live on multiple platforms in the same instant. There's no delay between platforms, no separate streaming sessions to manage, and no additional encoder hardware required.
Platform-specific delivery
Each platform has its own RTMP endpoint and its own requirements:
The Facebook delivery is worth noting specifically: Facebook Live requires RTMP over TLS on port 443, which a standard RTMP server can't send directly. The solution uses Stunnel — a lightweight TLS proxy — to wrap the RTMP stream in SSL before forwarding it to Facebook's ingest endpoint. This runs transparently alongside the other stream destinations.
Adaptive bitrate for the operator's own site
When the stream appears on the operator's own site, it's delivered via HLS with adaptive bitrate switching. The pipeline encodes the source stream into five quality tiers — from 160p at 200 kbps up to 1080p at 7 Mbps — and the player selects automatically based on the viewer's available bandwidth.
This matters for international operators: a player on a slow mobile connection in one market gets 360p without buffering. A player on a fiber connection gets 1080p source quality. The streaming experience degrades gracefully rather than failing.
Automatic VOD: stream once, publish everywhere
Every stream is recorded automatically. When the stream ends:
- The recorded
.flvfile is encoded to MP4 via FFmpeg - The MP4 is uploaded to AWS S3 for storage
- A post is automatically created in the CMS with the video embedded
- A preview keyframe is extracted and used as the thumbnail
The operator doesn't need to do anything after the stream ends. The VOD is published and accessible on the operator's site automatically. For YouTube and Facebook, the platforms create their own VOD archives from the live stream. A single live session produces persistent content on multiple platforms simultaneously.
One hour of live streaming produces: a live audience across Twitch, YouTube, Facebook, and the operator's own site; a VOD on YouTube (automatically indexed by search); a VOD on Facebook (shareable by viewers); an archived video post on the operator's CMS; an S3-stored recording for future use. The same production effort that used to serve one channel now serves five.
Authentication and stream security
Before nginx-rtmp accepts an incoming stream, it makes an HTTP callback to validate the stream key. An invalid key results in an immediate connection rejection — the stream never reaches the ingest server. This prevents unauthorized streams from appearing on the operator's channels.
The validation is intentionally lightweight: the stream key is validated against a configured token before any encoding or pushing begins. The operator's channels can only be published by an authenticated encoder with the correct credentials.
Branded overlays and the viewer experience
The streaming pipeline supports branded overlays applied at the encoder level — the operator's branding, promotional messages, responsible gaming disclosures, and call-to-action overlays are part of the stream itself. Every viewer on every platform sees the branded experience, not a raw unbranded feed.
This is important for compliance in regulated markets: responsible gaming messages can be incorporated into the stream overlay, ensuring they appear consistently regardless of which platform the viewer is watching on.
How Trustplay uses it
Trustplay Technology Sweden AB — the first live customer on WebPrefer's platform — is running the re-streaming solution in production. Their live content reaches viewers on their own site and across social platforms simultaneously, with the full PAM integration behind it: players who click through from a live stream to register land in the same player management system, with the same compliance controls, as players who found the operator through any other channel.
The re-streaming solution was developed with Lead3 Media and is live with Trustplay. A single operator stream reaches Twitch, YouTube, Facebook, and the operator's own site simultaneously — with full recording, automatic VOD publishing, and adaptive bitrate delivery on the operator's own player. The streaming infrastructure runs on AWS ECS with nginx-rtmp at the core, handling authentication, encoding, re-streaming, recording, and VOD pipeline in a single container deployment.
The retention argument
Retention spending in iGaming is mostly defensive: bonuses, free spins, cashback offers designed to make leaving more expensive. Live streaming is different — it's a reason to pay attention, not a financial incentive to stay.
A player who watches a 90-minute live session on Twitch, chats with a host, sees an interesting game, and clicks through to play is in a different state of engagement than a player who reacted to a promotional email. The content creates intent. The operator's platform converts it.
The re-streaming solution is the infrastructure that makes this possible at scale — without requiring the operator to manage multiple streaming sessions, multiple platforms, or manual VOD publishing after each session.