Introduction

In this post, we’ll dive into two modern approaches to monetizing content that will change the way you think about traditional Pay-per-view (PPV). Join us as we dissect the advantages, disadvantages, and potential solutions associated with each approach.

For anyone in media or broadcast, the PPV model is one the easiest and most common ways to monetize online video. PPV originated in the 1950s with closed-circuit television (CCTV) broadcasts of events like boxing matches. One of the earliest examples was the "Thrilla in Manila" fight between Muhammad Ali and Joe Frazier in 1975. PPV expanded in the 1980s with cable and satellite TV, offering a wider range of content. The 1990s saw a surge in popularity, driven by major sporting events. While PPV remains a popular model for monetizing live events, it can be overly broad, and more importantly, leave money on the table.

‍

Exploring a PPV Alternative

Picture yourself in the shoes of a software engineer at Live Jams TV, a hypothetical company specializing in broadcasting live music performances. The company offers a broad range of 24/7 content, including acoustic sets, behind-the-scenes footage, performances by various artists, and interactive jam sessions. Your task? To implement an advanced monetization system, charging viewers not based on a single event, but based on their overall view time.  To cater to an audience that is increasingly price sensitive, Live Jams TV wants to allow viewers to be selective about when they tune in. That’s where the magic of Native Frame™’s authentication comes in, and our unique ability to power granular pay-per-view, or as we like to call it, pay-per-unit (PPU).

Before we dive into the strategies, let’s introduce a few important concepts that lie at the heart of the implementations - webhooks and client-side tokens.

Webhooks are like virtual messengers that deliver real-time updates from one app to another. Imagine you're waiting for a package delivery, and instead of constantly checking the tracking website, you get a text message whenever there's a status change—like when the package is out for delivery or has been delivered. That's similar to how webhooks work in the digital world. They allow different apps or systems to communicate with each other automatically, sending notifications or triggering actions whenever certain events occur. This seamless exchange of information helps streamline processes, improve efficiency, and keep everyone in the loop without manual intervention.

‍

‍

Client-side tokens, particularly JSON Web Tokens (JWTs), act like digital passes that grant access to specific areas or services within an application or website. Imagine you're attending a concert and instead of showing your ticket every time you want to enter a different section or get a drink, you're given a special wristband that lets you move around freely. Similarly, a client-side token, like a JWT, is a small piece of digital information stored on your device after you've logged in or authenticated. It contains details about your identity, permissions, and possibly an expiration time. When you access different parts of the application or perform actions, the token is checked to ensure you have the right permissions, much like showing your wristband at different checkpoints during the concert. This streamlined authentication process not only enhances security but also improves user experience by reducing the need for constant reauthentication.

‍

‍

Now that we have a basic understanding of webhooks and client-side tokens, let’s dive into the strategies to implement pay-per-unit for live streaming.

As we navigate through the strategies and considerations, these hypothetical scenarios will include three parties: the client (viewer), the platform (the live streaming service, such as Native Frame™), and the implementor (Live Jams TV). Our focus will be on two distinct strategies: webhook auth and client-side tokens.

‍

‍

Strategy One: Webhook Auth

The first strategy we’ll look at is leveraging webhooks to authorize the viewer. In this strategy, the client kicks off the flow by first sending a request to the platform (1). The platform then sends a request to the implementor via a webhook (2) requesting if the client (user) has access to view a particular stream. The implementor checks user access (3) and sends a response back to the platform (4), which then returns a response back to the client either granting or denying permissions. Note that steps 1-4 happen each time a check is performed.

‍

‍

An advantage to this strategy is that it can be used to implement a fine-grained pay-per-unit experience with small increments of time. Let’s say the requirement is to charge by the minute to view content. Implementing such a feature would be as trivial as incrementing a counter with every request from the platform to the implementor (2) and charging the client accordingly for the view time.

One downside to this approach is if the request between the platform and the implementor were to timeout or go down, the client would lose access to the stream. A workaround for this is by using HTTP status codes with grace periods. Let’s say if the client has access to the stream, a 200 is returned from the implementor to the platform. If they do not have access, a 403 is returned. If the platform receives a 403 from the implementor, the platform terminates the client stream immediately. However if another 4xx or 500 status code is returned, a grace period of 5 minutes is granted, that would allow for any service restarts or scaling to occur, as to protect the client experience from unexpected events.

Another caveat to this approach is around scaling. Let’s say a performance becomes popular and 5,000 viewers join to watch. The implementor’s pay-per-unit service must be able to scale accordingly to meet this new demand. If access were checked every minute, that would be 5,000 requests per minute to check all clients. One solution to this problem is to bulk the requests waiting, say 500 ms, to queue requests from the platform to the implementor.

A real life use case where small increments of time is beneficial is with something like Cameo, where fans can connect live with celebrities. Here, the granularity of billing becomes crucial, as interactions may last only a few minutes. Using the webhook auth strategy, a fan, Bella, decides to join a live Q&A with her favorite author. As Bella enters the stream, the platform begins tracking her viewing time using webhooks, allowing for billing in exact one-minute increments. This ensures Bella pays precisely for the time she spends on the stream. If Bella's connection drops or she decides to leave the stream, the next webhook event will recognize this change, terminating access and ensuring billing stops instantly. This level of control is ideal for Cameo, where fan interactions can vary significantly in duration and fans value the flexibility to engage with celebrities for precisely the time they desire.

‍

Strategy Two: Client-Side Tokens

The second strategy we’ll discuss is to use a client-side token. In this approach, the flow starts with the client requesting access directly with the implementor. The implementor responds with a 200 (with the token) or 403 to the client (2a) and also sends a request to the platform (2b) with a client token and expiration time. Then, the client ↔ platform (3) request/response is all that is required to check if the client still has access to the stream.

‍

‍

Consider a fan, Evan, who wants to catch the last few songs of a much-anticipated concert on Live Jams TV. With the client-side token approach, Evan is charged in 15-minute increments. As the performance nears its climax, Evan purchases a 15-minute viewing block, receiving a token that grants access. This token, embedded with an expiration time, ensures that Evan is billed only for the specific time slot, even if the concert ends sooner. The simplicity of this system means Evan can enjoy the concert’s conclusion without worrying about overpaying for unused time. However, should the concert extend unexpectedly into an encore, Evan might face a sudden stream cutoff unless they quickly purchase additional time.

One of the advantages to this approach is once the client token and expiration has been passed to the platform, then only 1 request (3) needs to happen to check access. This reduces scaling complexities, removing the implementor from the picture. This approach will be cheaper due to the reduced network traffic as well.

A downside to this approach is, if JWTs are used for the client token, there is not a simple way to revoke access to the stream and this approach couldn’t be used with the above requirement for checking, say 1 minute stream intervals for access. Another downside to this approach is if the client to implementor (1) connection goes down, the client is unable to view the stream.

In both examples, the choice of pay-per-unit strategy—client-side tokens for pay-per-increment and webhook auth for more granular billing with something like pay-per-minute —reflects the unique requirements and user experiences of each platform. For Jams Live TV, where viewers might want to watch specific portions of an event without commitment, the client-side token provides a simple, user-friendly solution. On the other hand, Cameo’s dynamic and unpredictable interaction lengths necessitate the tight control and flexibility offered by webhook auth, ensuring fans pay only for their exact time engaged, enhancing the user experience and fairness of the billing system.

‍

Next Steps

If pay-per-unit is something worth exploring for your business, here are some next steps to consider. See Native Frame™’s guide to authorization for more information.

1. Assessment of Platform Needs

‍Evaluate the specific requirements and goals of your live streaming platform regarding PPV integration. Consider factors such as audience size, content type, billing preferences, and technical capabilities.

2. Selection of Integration Strategy

‍Determine which PPV integration strategy—webhook auth or client-side tokens—best aligns with your platform's needs, technical infrastructure, and user experience goals. Consider the advantages, disadvantages, and potential challenges outlined in this blog post.

2. Technical Implementation

‍Engage your development team or technical partners to implement the chosen PPV integration strategy. This may involve configuring webhooks, integrating client-side token authentication, updating billing systems, and ensuring scalability and reliability of the platform.

3. Testing and Quality Assurance

‍Conduct thorough testing and quality assurance processes to ensure the seamless functioning of the PPV features within your live streaming platform. Test various scenarios, including user authentication, payment processing, stream access, and error handling.

4. User Experience Optimization

Pay close attention to the user experience aspects of the PPV integration, such as ease of purchase, access management, billing transparency, and error messaging. Iterate on design and functionality based on user feedback and usability testing.

5. Launch and Promotion

‍Once the PPV integration is implemented and tested successfully, plan a launch strategy to promote the new features to your audience. Utilize marketing channels, social media, email newsletters, and partnerships to generate awareness and drive engagement.

6. Monitoring and Optimization

‍Continuously monitor the performance and usage of the PPV features post-launch. Analyze key metrics such as conversion rates, viewer engagement, revenue generation, and user feedback. Use these insights to iterate, optimize, and refine the PPV integration over time.

‍

Summary

In this post, we've examined two strategies for implementing a pay-per-unit feature within the realm of live streaming. Strategy one, utilizing webhook auth, offers granular control over access permissions, yet presents challenges regarding scalability and potential interruptions. On the other hand, strategy two, employing client-side tokens, streamlines the access-checking process, reducing complexity and network traffic. However, it poses its own set of challenges, including difficulties with access revocation and potential disruptions in client-implementor connections. By weighing the pros and cons of each approach, we've provided insights into how to navigate the complexities of integrating pay-per-unit functionality into live streaming services effectively.

Native Frame™ is a Live Streaming SAAS Platform.

Take a look at this great resource to get started integrating live video for developers.