Methods and systems for dynamically managing access of media content for users
Patent Information
- Application Number
- PCT/IN2026/050435
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2025-03-13
- Filing Date
- 2026-03-12
- Publication Date
- 2026-09-17
Smart Images

Figure IN2026050435_17092026_PF_FP_ABST
Abstract
Description
DescriptionTitle Of Invention: METHODS AND SYSTEMS FOR DYNAMICALLY MANAGING ACCESS OF MEDIA CONTENT FOR USERSCross-reference to related applications
[0001] This application claims priority from Indian provisional patent application 202521022625, filed on 13th March 2025, which is incorporated herein in its entirety by this reference thereto.Technical Field
[0002] The present disclosure generally relates to the streaming or delivering digital content, such as media content to content viewers, and more particularly, to methods and systems for dynamically managing a limited-access duration of media content associated with a digital media platform. Background
[0003] Streaming platforms often offer free access to live or regular media content for a limited duration for promotional and marketing reasons. To encourage user engagement and increase subscriber conversions, platforms implement promotions, where non-subscribers are granted a temporary free viewing period (called, limited-access duration) before being required to purchase a subscription. In other words, the goal of these promotions is to encourage free users to either subscribe to the platform or purchase a pay-per-view for the media content. Once this limited-access duration expires, users are redirected to a paywall facilitated by a payment platform where they can complete the payment process to continue watching the stream.
[0004] However, in scenarios where the limited-access duration for a large number of users expires simultaneously, especially during highly engaging, long-duration live events (such as sports matches), and the payment platform experiences a sudden surge in payment requests. For instance, if a streaming platform provides 20 minutes of free access during a live sports match, a significant portion of users may reach the paywall at the same time, triggering a high volume of concurrent payment transactions. This in turn will result in payment processing congestion at the payment platform, leading to slow-loading or failed payment pages, which negatively impacts user experience and reduces subscription conversion rates.
[0005] Traditional payment platforms are not optimized to handle such extreme bursts of transactions occurring in a short time window. This inability to process payments efficiently during these critical moments can lead to a bad user experience, platform abandonment, and lost advertisement opportunities. Furthermore, existing solutions do not offer a dynamic mechanism to smooth out transaction spikes, leading to potential server overload and payment gateway inefficiencies.
[0006] Thus, there exists a technological need for methods and systems for dynamically managing a limited-access duration of media content associated with a digital media platform to prevent payment failures due to payment gateway bottlenecks or platform instability.SUMMARY
[0007] Various embodiments of the present disclosure provide methods and systems for dynamically managing a limited-access duration of media content associated with a digital media platform.
[0008] In an embodiment, a computer-implemented method for dynamically managing a limitedaccess duration of media content associated with a digital media platform is disclosed. The computer-implemented method is implemented by a system and includes determining an expected traffic on a payment platform based, at least in part, on one or more users streaming the media content within the limited-access duration from the digital media platform on one or more user devices. Herein, the expected traffic indicates one or more users that are expected to be redirected to the payment platform on an expiry of the limited-access duration. In response to determining that the expected traffic is greater than a predetermined threshold load of the payment platform, the computer-implemented method further includes identifying a subset of users from the one or more users based, at least in part, on a propensity metric corresponding to each user. Herein, the propensity metric indicates a likelihood of a particular user subscribing to a streaming service offered by the digital media platform. The computer-implemented method further includes facilitating the digital media platform to update the limited-access duration for the subset of users by a predefined duration. Herein, updating the limited-access duration includes one of extending or reducing the limited-access duration.
[0009] In another embodiment, a system is disclosed. The system includes a memory module configured to store instructions. The system also includes a processor in communication with the memory module. The processor is configured to execute the instructions stored in the memory module and thereby cause the system to perform, at least in part, to determine an expected traffic on a payment platform based, at least in part, on one or more users streaming the media content within the limited-access duration from the digital media platform on one or more user devices. Herein, the expected traffic indicates one or more users that are expected to be redirected to the payment platform on an expiry of the limited-access duration. In response to determining that the expected traffic is greater than a predetermined threshold load of the payment platform, the system is further caused to identify a subset of users from the one or more users based, at least in part, on a propensity metric corresponding to each user. Herein, the propensity metric indicates a likelihood of a particular user subscribing to a streaming service offered by the digital media platform. The system is further caused to facilitate the digital media platform to update the limited-access duration for the subset of users by a predefined duration. Herein, updating the limited-access duration includes one of extending or reducing the limited-access duration.
[0010] In yet another embodiment, a non-transitory computer-readable storage medium is disclosed.The non-transitory computer-readable storage medium includes computer-executable instructionsthat, when executed by at least a processor of a system, cause the system to perform a method. The method performed includes determining an expected traffic on a payment platform based, at least in part, on one or more users streaming the media content within the limited-access duration from the digital media platform on one or more user devices. Herein, the expected traffic indicates one or more users that are expected to be redirected to the payment platform on an expiry of the limited-access duration. In response to determining that the expected traffic is greater than a predetermined threshold load of the payment platform, the method further includes identifying a subset of users from the one or more users based, at least in part, on a propensity metric corresponding to each user. Herein, the propensity metric indicates a likelihood of a particular user subscribing to a streaming service offered by the digital media platform. The method further includes facilitating the digital media platform to update the limited-access duration for the subset of users by a predefined duration. Herein, updating the limited-access duration includes one of extending or reducing the limited-access duration.
[0011] The foregoing summary is illustrative only and is not intended to be in any way limiting. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by reference to the drawings and the following detailed description.BRIEF DESCRIPTION OF THE FIGURES
[0012] The advantages and features of the invention will become better understood with reference to the detailed description taken in conjunction with the accompanying drawings, wherein like elements are identified with like symbols, and in which:
[0013] FIG. 1 depicts a process for provisioning the media content offered by a digital media platform to one or more users with a limited-access duration, in accordance with various embodiments of the present disclosure;
[0014] FIG. 2 illustrates a simplified block diagram of a system, in accordance with an embodiment of the present disclosure;
[0015] FIG. 3 illustrates various exemplary Graphical User Interfaces (GUIs) depicting a process for redirecting one or more users to a payment gateway associated with the payment platform on expiry of the limited-access duration, in accordance with an embodiment of the present disclosure;
[0016] FIG. 4 illustrates various exemplary Graphical User Interfaces (GUIs) depicting a process for dynamically managing the limited-access duration of the media content offered to the one or more users, in accordance with an embodiment of the present disclosure; and
[0017] FIG. 5 illustrates a process flow diagram depicting the method for dynamically managing a limited-access duration of media content associated with a digital media platform, in accordance with an embodiment of the present disclosure.
[0018] The drawings referred to in this description are not to be understood as being drawn to scale except if specifically noted, and such drawings are only exemplary in nature.DETAILED DESCRIPTION
[0019] The best and other modes for carrying out the present invention are presented in terms of the embodiments herein depicted in FIG. 1 to FIG. 5. The embodiments are described herein for illustrative purposes and are subject to many variations. It is understood that various omissions and substitutions of equivalents are contemplated as circumstances may suggest or render expedient but are intended to cover the application or implementation without departing from the scope of the invention. Further, it is to be understood that the phraseology and terminology employed herein are for the purpose of the description and should not be regarded as limiting. Any heading utilized within this description is for convenience only and has no legal or limiting effect.
[0020] Reference in this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. The appearance of the phrase “in an embodiment” in various places in the specification does not necessarily all refer to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described, which may be exhibited by some embodiments and not by others. Similarly, various requirements are described, which may be requirements for some embodiments but not for other embodiments.
[0021] Moreover, although the following description contains many specifics for the purposes of illustration, anyone skilled in the art will appreciate that many variations and / or alterations to said details are within the scope of the present disclosure. Similarly, although many of the features of the present disclosure are described in terms of each other or in conjunction with each other, one skilled in the art will appreciate that many of these features can be provided independently of other features. Accordingly, this description of the present disclosure is set forth without any loss of generality to, and without imposing limitations upon the present disclosure.
[0022] Embodiments of the present disclosure may be embodied as an apparatus, system, method, or computer program product. Accordingly, embodiments of the present disclosure may take the form of an entire hardware embodiment, an entire software embodiment (including firmware, resident software, micro-code, etc.), or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” "engine" “module” or “system”. Furthermore, aspects of the present disclosure may take the form of a computer program product embodied in one or more computer-readable storage media having computer-readable program code embodied thereon.
[0023] The terms “a” and “an” herein do not denote a limitation of quantity but rather denote the presence of at least one of the referenced items.OVERVIEW
[0024] Various embodiments of the present disclosure provide methods, systems, electronic devices, and computer program products for dynamically managing a limited-access duration of media content associated with a digital media platform (i.e., a streaming platform). The system includes a processor and a memory. In an embodiment, the system is configured to determine an expected traffic on a payment platform based, at least in part, on one or more users streaming the media content within the limited-access duration from the digital media platform on one or more user devices. Herein, the expected traffic indicates one or more users that are expected to be redirected to the payment platform on an expiry of the limited-access duration.
[0025] In an implementation, the system may utilize Time to Live (TTL) token refresh requests for determining the expected traffic on the payment platform. In particular, the system is configured to receive one or more Time to Live (TTL) token refresh requests from the one or more user devices streaming the media content associated with the digital media platform. Herein, each TTL token request is associated with an ongoing stream of the media content within the limited -access duration for a particular user device. Then, the system is configured to determine a remaining duration of the limited-access duration for each user device of the one or more user devices based, at least in part, on the one or more TTL token requests. Then, the system is configured to compute the expected traffic on the payment platform based, at least in part, on the remaining duration for each user device.
[0026] In another implementation, the system may utilize information related to a number of active users for determining the expected traffic on the payment platform. In particular, the system is configured to determine the number of active users streaming the media content with the limitedaccess duration using an application associated with the digital media platform. Then, the system is configured to determine a number of users to be redirected to the payment platform at a particular time instance concurrently on the expiry of the limited-access duration based, at least in part, on the number of active users. Then, the system is configured to compute the expected traffic on the payment platform based, at least in part, on the number of users.
[0027] In yet another implementation, the system may utilize event-related information for determining the expected traffic on the payment platform. In particular, the system is configured to identify an event in the media content, based, at least in part, on metadata associated with the media content. Then, the system is configured to access an event log from a database associated with the system based, at least in part, on the event. Herein, the event log includes information related to a number of users streaming content while one or more historical events similar to the identified event occurred during one or more historical streams. Then, the system is configured to determine via a prediction model with the system an expected number of concurrent users streaming the media content within the limited-access duration based, at least in part, on the event log. Then, the system is configured to compute the expected traffic on the payment platform based, at least in part, on the expected number of concurrent users.
[0028] In real-world scenarios, the traffic may encounter temporary fluctuations due to temporary spikes in viewership. In an implementation, the system is configured to identify an event in the media content, based, at least in part, on metadata associated with the media content. Then, the system accesses an event log from a database associated with the system based, at least in part, on the event. Then, the system computes a fluctuation metric for the media content based, at least in part, on the event log. Herein, the fluctuation metric indicates a temporary increase or decrease in the number of the one or more users in response to the event. Further, the system is configured to update the expected traffic based, at least in part, on the fluctuation metric. In other words, the expected traffic is compensated using the fluctuation metric.
[0029] Further, in an embodiment, in response to determining that the expected traffic is greater than a predetermined threshold load of the payment platform, the system is configured to identify a subset of users from the one or more users based, at least in part, on a propensity metric corresponding to each user. Herein, the propensity metric indicates a likelihood of a particular user subscribing to a streaming service offered by the digital media platform.
[0030] In a non-limiting implementation, the predetermined threshold load can be determined using health metrics of the payment platform. In particular, the system can receive one or more health metrics from the payment platform. Herein, the one or more health metrics indicate a real-time health of the payment platform. Then, the system can dynamically determine the predetermined threshold load based, at least in part, on the one or more health metrics.
[0031] In some instances, identifying the subset of users includes computing a user retention cost of each user of the one or more users for the digital media platform. Then, computing the propensity metric for each user based, at least in part, on a location of each user, a user device associated with each user, a subscription history of each user, and a network associated with each user. Then, the subset of users is determined based, at least in part, on the propensity metric and the user retention cost corresponding to each user.
[0032] Additionally, in some instances, identifying the subset of users further includes identifying an event in the media content, based, at least in part, on metadata associated with the media content. Then, determining an event-driven conversion metric for each user based, at least in part, on the event and a user profile corresponding to each user. Then, the subset of users is determined based, at least in part, on the event-driven conversion metric, the propensity metric, and the user retention cost corresponding to each user.
[0033] In another embodiment, the system is configured to facilitate the digital media platform to update the limited-access duration for the subset of users by a predefined duration. In various instances, the process of updating the limited-access duration includes one of extending or reducing the limited-access duration.
[0034] In an implementation, the process of facilitating the digital media platform to update the limitedaccess duration may further include identifying one or more user cohorts from the subset of users.Then, selecting a unique predefined duration for each user cohort from the one or more cohorts based, at least in part, on a set of duration rules. Then, notifying the digital media platform to update the limited-access duration of each user cohort with the corresponding unique predefined duration. Herein, the process of updating the limited-access duration includes one of extending or reducing the limited-access duration by the unique predefined duration.
[0035] In a non-limiting scenario, identifying the one or more user cohorts includes accessing a user profile corresponding to each user from the subset of users. Then, segregating the subset of users into the one or more user cohorts based, at least in part, on the corresponding user profile of each user and a set of predefined rules.
[0036] In another implementation, the process of facilitating the digital media platform to update the limited-access duration may further include computing a targeted content driven yield from each user of the subset of users. Herein, the targeted content driven yield is generated by streaming one or more targeted content in between the media content to each user. Then, determining the predefined duration for each user based, at least in part, on the targeted content driven yield from each user. Then, notifying the digital media platform to update the limited-access duration of each user by the corresponding predefined duration for each user. Herein, the process of updating the limited-access duration includes one of extending or reducing the limited-access duration by the predefined duration.
[0037] To that end, the present invention aims to provide a technical effect by dynamically managing access to media content for users. It is understood that by dynamically managing the limited access duration for different users based on various parameters, metrics, or factors, it is possible to optimize payment processing during high concurrency events, ensuring seamless user experience, reduced payment failures, and improved subscription conversions without causing payment gateway bottlenecks or platform instability.
[0038] To that end, the present disclosure aims to solve the technical problem of excess load spikes at the payment platforms by adding or removing time from the limited-access duration provided to free users. This aspect helps to stagger the load arriving at the payment platform such that its health is maintained, and any potential crash situation is mitigated. Thus, providing a good user experience to the users.
[0039] Various embodiments of the present disclosure are described hereinafter with reference to FIG.1 to FIG. 5.
[0040] FIG. 1 depicts a process for provisioning a media content 108 offered by a digital media platform 106 to one or more users 104 with a limited-access duration, in accordance with various embodiments of the present disclosure.
[0041] In an embodiment, the digital media platform 106 is an entity that holds the various digital rights associated with digital media content present within digital media content libraries. In some scenarios, the digital media platform 106 offers the digital media content (referred to hereinafterinterchangeably as ‘media content’ or ‘content’) on a subscription or free basis by using a digital platform and / or Over-The-Top (OTT) media services, i.e., content is streamed over the Internet to a user device of a user such as any of the user 104A, user 104B, and user 104C by the digital media platform 106.
[0042] The term ‘user’ as used herein implies a user who has subscribed, i.e., registered to a subscription plan (whether a free subscription plan or a paid subscription plan) from among a plurality of subscription plans for accessing content offered by the digital media platform 106. It is noted that for promotional or marketing purposes, the digital media platform 106 may allow its users or subscribers of the free tier (i.e., a free or advertisement-supported subscription plan) to watch or stream the media content 108 for a limited-access duration before requiring them to subscribe to a paid or an upgraded subscription plan. Here, user 104A, user 104B, and user 104C represent one or more users (collectively, referred to as users 104 or one or more users 104) who are given access to stream the media content 108 using the limited-access duration.
[0043] The term ‘limited-access duration’ refers to the time duration that is allotted to a particular user such as user 104A for streaming the media content such as media content 108 for free (or supported with Advertisements or targeted media content, described later). Once, the limitedaccess duration is expired, the user 104A is redirected to payment platform 126 for subscribing to a paid or upgraded tier or subscription plan offered by the digital media platform 106, or the viewing privileges of the user 104A are revoked. In some instances, the user 104A is allowed to stream the media content 108 with advertisements upon the expiry of the limited-access duration. In a nonlimiting implementation, each user of the users 104 is allocated a limited-access duration for streaming the media content (whether it’s the same media content or distinct media content for different users).
[0044] In the illustrated example, the one or more users 104 are depicted to be controlling one or more user devices that are capable of displaying the media content streamed from Content Delivery Networks (CDNs), such as the media content 108 streamed from a CDN 118. Herein, the content can be in the form of a stream of encoded content segments. Herein, user 104A is associated with a television, user 104B is associated with a tablet device, and user 104C is associated with a laptop for illustration purposes. Other examples of the user devices may include a smartphone, a laptop, a desktop, a personal computer, and so on. The users 104 may use their user devices to view the media content 108 provided by the digital media platform 106 via the CDN 118. Further, for the sake of simplicity, only three users 104 are shown in FIG. 1 however, the number of users 104 may be any non-zero natural number.
[0045] In at least some embodiments, the term ‘user’ may also be used to refer to other users in addition to the users 104, such as, for example, family members of the users 104, friends of the users 104, people in the same demographics as the users 104, and so on.
[0046] The representation 100 depicts an overview of the process of streaming exemplary content, such as the media content 108. The media content 108 may be embodied as streaming videocontent such as live-streaming content or on-demand video streaming content. As an example, the representation 100 shows that the media content 108 may be embodied as live-streamed content corresponding to a sports match being streamed from the event venue such as a stadium 110. In another illustrative example, the media content 108 may correspond to Video On Demand (VOD) content, i.e., content streamed from a content library such as a content library 112, on demand of any of the users 104.
[0047] It is noted that although the media content 108 offered by the digital media platform 106 has been described as video content throughout the various embodiments described herein, the same should not be construed as a limitation. To that end, the term ‘media content’ or ‘content’ as used herein may include ‘video content’, ‘audio content’, ‘gaming content’, ‘textual content’, and any combination of such content offered in an interactive or non-interactive form. Accordingly, the term ‘content’ is also interchangeably referred to hereinafter as ‘media content’ for the sake of simplicity throughout the description.
[0048] In an illustrative example, to subscribe to the content streaming services offered by the digital media platform 106, the users 104 may register with the digital media platform 106. This can be achieved by creating an online account on the digital media platform’s portal. As part of the account creation process, the users 104 may provide personal information, such as age, gender, language preference, content preference, and any other personal preferences, to the digital media platform 106. Such information may be stored in a user profile or subscriber profile along with other account information, such as a type of subscription, a validity date of the subscription, etc., in a database 116 associated with the digital media platform 106.
[0049] Once the users 104 has created their accounts, the users 104 may access a User Interface (Ul) of a mobile application or a Web application associated with the digital media platform 106 to view / access the content. It is understood that the user device may be in operative communication with a communication network, such as the Internet, enabled by a network provider, also known as the Internet Service Provider (ISP). The respective user devices of the users 104 may connect to the ISP network using a wired network, a wireless network, or a combination of wired and wireless networks. Some non-limiting examples of wired networks may include the Ethernet, the Local Area Network (LAN), a fiber-optic network, and the like. Some non-limiting examples of wireless networks may include Wireless LAN (WLAN), cellular networks, Bluetooth, ZigBee networks, and the like.
[0050] The respective user devices of the users 104 may fetch a Graphical User Interface (GUI or simply, Ul) associated with the digital media platform 106 over the ISP network and cause the display of the Ul on a display screen of the respective user devices of the users 104. In an illustrative example, the Ul may include a plurality of content titles corresponding to a variety of content items offered by the digital media platform 106 to its users 104. The users 104 may be provided with the functionality to select a content title from among the plurality of content titles shown on the Ul, which is displayed on the display screen of their respective user devices. For example, the user 104A may select a content title related to the live cricket match streamed from the event venue, such as thestadium 110. The selection of the content title may trigger a request for a playback Uniform Resource Locator (URL) to be sent from the corresponding user device to the digital media platform 106.
[0051] In addition to requesting the playback URL of the chosen content title, the request for the playback URL also includes metadata associated with the corresponding user. For example, the metadata includes information related to the type of the user device (for example, mobile phone, TV, or tablet device) used by the user 104A for requesting the content, the type of login method (for example, Email, mobile number, or Web login) used by the user 104A, the type of network access (for example, cellular or Wi-Fi) associated with playback URL request, network provider ID, device ID, IP address, geo-location information, browser information (e.g., cookie data), time of the day, and the like.
[0052] The digital media platform 106 is configured to forward the request for the playback URL to a content handling server 114. The term ‘content handling server 114’ is also interchangeably referred to hereinafter as ‘digital platform server 114’ for the purposes of description. It is noted in some example scenarios, the content handling server 114 may be incorporated within the digital media platform 106.
[0053] The content handling server 114 determines whether the users 104 should be allocated a limited-access duration for streaming the media content 108 based, a least in part, on their subscription plan and the type of content requested by the different users 104. The content handling server 114 relies on the request for their corresponding playback URL for understanding the type of content requested by the users 104. For example, if the type of content requested by the user 104A is a movie trailer or a non-content request (such as a request for the synopsis of the content), then the content handling server 114 may determine that there is no need to allocate a limitedaccess duration or no Ads insertion is required for the requested content, and the user 104A is allowed to stream the trailer without any hindrances. The term ‘Ad’ is also interchangeably referred to hereinafter as ‘targeted media content’. In particular, the digital media platform 106 may employ a video encoding team 120 that is responsible for identifying suitable positions within the media content 108 for inserting Ads. For example, during a live match, the video encoding team 120 may analyse the media content 108 and identify low interest portions during the match. They may add cue-in and cue-out markers within the media content 108 which indicate positions for cueing in and out of the Ads to the CDN 118.
[0054] In some scenarios, the type of content requested by the user 104A may be non-monetary in nature. For example, a president or prime minister’s public address to the nation during a pandemic, a natural disaster event, or any such announcement conveying news of national importance. In such scenarios, where the type of content requested by the user 104A is non-monetary in nature, the content handling server 114 may determine there is no need to allocate a limited-access duration or no Ads insertion is required for the requested content, and the user 104A is allowed to stream the trailer without any hindrances.
[0055] Alternatively, if the type of request corresponds to a content title or a live event, then the content handling server 114 may allocate a limited-access duration to the users 104 for streaming the media content 108. It is noted that the limited-access duration can be configured for each user of the users 104 based on various factors. Examples of the various factors include whether the user 104 has a propensity to subscribe to the streaming service, and whether Ad insertion is done in the content, or the user profile. As may be understood, advertisements help the digital media platform to recoup their costs, which may allow them to provide the users 104 with a longer limited-access duration. In a case, where Ad insertion is not performed, the limited-access duration may be shorter.
[0056] In another illustrative example, if the user 104B has requested streaming of the live cricket match from the stadium 110, then the content handling server 114 may determine that Ad can be integrated on the fly. Therefore, a longer limited-access duration such as 20 minutes may be allocated to the user 104B. In some scenarios, if the Ad integration is not possible, then the content handling server 114 is configured to allocate a shorter limited-access duration to the user 104B such as 10 minutes.
[0057] In an implementation, for inserting Ads, the content handling server 114 is configured to analyze the user metadata included in the request for playback URL along with any other user-related information, such as whether the user 104B watched a particular brand’s Ad completely in the past or not, or whether the user 104B clicked a product hyperlink in an Ad in the past and visited the product webpage, and the like. Based on the analysis, the content handling server 114 may be configured to predict a type of personalized Ads that may be suitable forthe interests or preferences of the user 104B. In a non-limiting implementation, the content handling server 114 utilizes a content prediction model, to predict the Ad to be accommodated within the media content 108 based, at least in part, on the preference of the user 104B. It should be noted that within the media content 108, one or more Ads may be accommodated.
[0058] It is noted that the content prediction model is trained before its operation during deployment based on the historical content viewer data. In an instance, the content prediction model is trained on the historical content viewer data to learn patterns, relationships, and trends in the input data during deployment. In various examples, the predicted one or more Ads may be at least one of the Ads that the user 104B is interested in while streaming the media content 108. In one specific implementation, an Al or ML model may be used as the content prediction model. In a non-liming implementation, the content prediction model may be a Light Gradient Boosting Machine (LightGBM), Random Forest (RF), Extreme Gradient Boosting (XGBoost), Adaptive Boosting (AdaBoost), Bootstrap Aggregating (Bagging), Gradient Boosting Machine (GBM), Voting Classifier, Stacked Generalization (Stacking), Multiple Additive Regression Trees (MART), Gradient Boosted Regression Trees (GBRT), and so on.
[0059] It is noted that even though the present disclosure has been described with regard to Ads as the targeted media content, other forms of digital content may also constitute the targeted media content, and the same is covered by the various embodiments of the present disclosure as well.For example, any form of ‘video content’, ‘audio content’, ‘gaming content’, ‘textual content’, ‘pictorial content’, ‘image content’, ‘webpage’, and any combination of such content may be used as the targeted media content as well.
[0060] The content handling server 114 is in operative communication with the database 116 configured to store one or more targeted media content files such as one or more Ads. The database 116 is configured to store a plurality of Ad creative received from a plurality of advertising entities, such as an example advertisement distributor 124 shown in the representation 100. Further, the exchange server 122 acts as an interface between the system 102 and the advertisement distributor 124 to facilitate the transfer of the plurality of the Ads from the advertisement distributor 124 to the database 116 of the system 102 based on the requirements of the digital media platform 106.
[0061] In some embodiments, the content handling server 114 is configured to classify users into different cohorts. The term ‘cohort’ as used herein refers to a group of users who share at least two or more commonalities from among an age group, gender, location, network provider, access patterns, content genre preferences, language preferences, and the like. For example, each cohort may be assigned a different limited-access duration. Since it is computationally complex to determine a unique limited-access duration for each user. Thus, users belonging to a particular user cohort may be assigned a unique limited-access duration to reduce the computational complexity.
[0062] For example, a cohort corresponding to a particular age group (above 40 years) and having a preference for a particular content genre (e.g., sports, music, etc.) may have a high likelihood of subscribing to a paid subscription plan or a pay-per-view for a live sporting event. To that end, the said cohort may be given a longer limited-access duration such as 30 minutes for streaming the media content 108. Based on these classifications, the content handling server 114 can allocate different limited-access durations to different users 104.
[0063] In an embodiment, after the expiry of the limited-access duration, the users 104 may be redirected to a webpage (such as a payment gateway) for subscribing to streaming services offered by the digital media platform 106. In an implementation, the webpage for processing payments for the users 104 willing to subscribe to the service offered by the digital media platform 106 is enabled by the payment platform 126. Herein, the payment platform 126 refers to a digital financial infrastructure that facilitates secure and efficient processing of payment transactions for the digital media platform 106. The payment platform 126 is configured to work in conjunction with a payment gateway, which serves as an intermediary between the digital media platform 106 and the payment networks for processing payments initiated by users 104 for accessing the media content 108.
[0064] In various implementations, the payment platform 126 can be integrated with various payment networks, allowing users 104 to perform payment transactions using multiple payment methods, including payment cards (e.g., credit cards, debit cards, prepaid cards), a Unified Payment Interface (UPI), digital wallets, and virtual payment accounts.
[0065] Herein, the term ‘payment transaction’ refers to the electronic transfer of funds initiated by a user, such as user 104A to access the streaming service, wherein a certain amount is deducted from the user's payment account and credited to the merchant’s (i.e., the digital media platform 106) financial account. Such transactions may include one-time purchases, recurring subscription payments, or pay-per-view content access. A payment transaction is typically processed between a buyer (i.e., the user 104A) and a seller (i.e., the digital media platform 106) through a payment gateway and is validated by the respective issuing bank and the respective acquiring bank within a payment network.
[0066] When the user 104A initiates a payment transaction, the payment platform 126 verifies the payment card or payment account details, processes the authorization request through the payment network, and completes the transaction by facilitating the fund transfer from the user’s payment account to the merchant’s financial account. The payment platform 126 may also handle subscription-based payments, enabling seamless recurring billing for continued access to the streaming service.
[0067] Additionally, the payment platform 126 may incorporate fraud detection mechanisms, encryption protocols, and compliance features to ensure secure and regulatory-compliant payment processing. It may also provide transaction tracking, refund processing, and user authentication functionalities to enhance the overall payment experience for users of the streaming service.
[0068] As described earlier, when the limited-access duration for many users expires simultaneously, especially during highly engaging, long-duration live events (such as sports matches), the payment platform 126 can experience a sudden surge in payment requests. For example, if the limitedaccess duration for millions of free users expires simultaneously during a live cricket match, a few hundred thousand users may opt to pay for a premium subscription. They may opt to pay for the subscription using the payment platform 126. This results in congestion at the payment gateway associated with the payment platform 126, leading to slow-loading or failed payment pages, which negatively impacts user experience and reduces subscription conversion rates.
[0069] To overcome the aforementioned drawbacks and provide additional advantages, a system 102 is provided.
[0070] In an embodiment, the system 102 is configured to determine an expected traffic on a payment platform based, at least in part, on one or more users streaming the media content 108 within the limited-access duration from the digital media platform 106 on one or more user devices. The term ‘expected traffic’ indicates one or more users 104 that are expected to be redirected to the payment platform 126 on an expiry of the limited-access duration. The process for determining the expected traffic has been described in detail later in the present disclosure.
[0071] In another embodiment, the system 102 is configured to determine if the expected traffic is lower or equal to a predetermined threshold load of the payment platform 126, then the system 102 allows the one or more users 104 to continue watching the media content 108 for a limited-accessduration. Herein, the term ‘predetermined threshold load’ may refer to the theoretical maximum number of users that can be handled by the payment platform 126 without crashing or an increase in payment failures. In a non-limiting implementation, the predetermined threshold load may be computed by the system 102. This aspect has been described later in the present disclosure.
[0072] It is noted that as long as the expected traffic remains below the predetermined threshold load, the payment gateway associated with the payment platform 126 will be able to process the payment transactions from the one or more users 104 without crashing or payment failures. Therefore, there exists no need for changing or configuring the limited-access duration in such circumstances.
[0073] Alternatively, if the system 102 determines that the expected traffic is greater than the predetermined threshold load of the payment platform 126, then the system 102 identifies a subset of users from the one or more users 104 based, at least in part, on a propensity metric corresponding to each user. The term ‘propensity metric’ indicates a likelihood of a particular user subscribing to a streaming service offered by the digital media platform 106.
[0074] In another embodiment, the system 102 is configured to facilitate the digital media platform 106 to update the limited-access duration for the subset of users by a predefined duration. Herein, the predefined duration may be determined based on business rules or the cohort of each user of the subset of users. This aspect has been described later in the present disclosure. It is noted that updating the limited-access duration includes one of extending or reducing the limited-access duration.
[0075] As may be appreciated, by dynamically managing the limited access duration for different users based on various parameters, metrics, or factors, it is possible to optimize payment processing during high concurrency events, ensuring seamless user experience, reduced payment failures, and improved subscription conversions without causing payment gateway bottlenecks or platform instability. It is noted that the various aspects of the system 102 have been explained in further detail with reference to FIG. 2.
[0076] FIG. 2 illustrates a simplified block diagram of a system 200, in accordance with an embodiment of the present disclosure. The system 200 is identical to the system 102 of FIG. 1. The system 200 is caused to configure the duration of the limited-access duration for each user (or user cohort of the user) of the users 104. In some embodiments, the system 200 may be deployed within the content handling server 114 or the digital media platform 106. In other embodiments, the system 200 may be implemented in a user device or as a standalone entity. It is noted that system 200 is identical to system 102 described with reference to FIG. 1.
[0077] The system 200 is depicted to include multiple components such as a processing module 202, a memory module 204, an Input / Output (I / O) module 206, and a communication module 208. The various components of the system 200, such as the processing module 202, the memory module 204, the I / O module 206, and the communication module 208, are configured to communicate with each other via or through a centralized circuit system 210. The centralized circuit system 210 maybe various devices configured to, among other things, provide or enable communication between the components of the system 200. In certain embodiments, the centralized circuit system 210 may be a Bus or a central Printed Circuit Board (PCB) such as a motherboard, a main board, a system board, or a logic board. The centralized circuit system 210 may also, or alternatively, include other Printed Circuit Assemblies (PCAs) or communication channel media.
[0078] In some embodiments, the system 200 is associated with a database 212. The database is substantially similar to the database 116 described with reference to FIG. 1. The database 212 is configured to store user profiles 214 of the users 104, an event log 216 for various historical events, and a prediction model 218. It is noted that although the system 200 is depicted to include the processing module 202, the memory module 204, the Input / Output (I / O) module 206, and the communication module 208. In some embodiments, the system 200 may include more or fewer components than those depicted herein. The various components of the system 200 may be implemented using hardware, software, firmware, or any combination thereof.
[0079] In one embodiment, the processing module 202 may be embodied as a multi-core processor, a single-core processor, or a combination of one or more multi-core processors and one or more single-core processors. For example, the processing module 202 may be embodied as one or more of various processing devices, such as a coprocessor, a microprocessor, a controller, a Digital Signal Processor (DSP), a processing circuitry with or without an accompanying DSP, or various other processing devices including integrated circuits such as, for example, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Microcontroller Unit (MCU), a hardware accelerator, a special-purpose computer chip, or the like.
[0080] In one embodiment, the memory module 204 is capable of storing machine-executable instructions, referred to herein as a set of platform instructions 205. Further, the processing module 202 is capable of executing the set of platform instructions 205. In an embodiment, the processing module 202 may be configured to execute hard-coded functionality. In an embodiment, the processing module 202 is embodied as an executor of the set of platform instructions 205. Herein, the set of platform instructions 205 may specifically configure the processing module 202 to perform the algorithms and / or operations described herein when the platform instructions 205 are executed. For example, in at least some embodiments, each component of the processing module 202 may be configured to execute the platform instructions 205 stored in the memory module 204 for realizing respective functionalities, as will be explained in further detail later.
[0081] The memory module 204 may be embodied as one or more non-volatile memory devices, one or more volatile memory devices, and / or a combination of one or more volatile memory devices and non-volatile memory devices. For example, the memory module 204 may be embodied as semiconductor memories, such as flash memory, Read Only Memory (ROM), programmable ROM (PROM), Erasable PROM (EPROM), Random Access Memory (RAM), etc., and the like. In at least some embodiments, the memory module 204 stores logic and / or instructions, which may be usedby modules of the processing module 202, such as a traffic estimation module 220, a user identification module 222, and a timer updation module 224.
[0082] In an embodiment, the I / O module 206 may include mechanisms configured to receive a set of predefined rules from an administrator (not shown) of the system 200, one or more health metrics from the payment platform 126, and so on. Further, the I / O module 206 is configured to store the received predefined rules and health metrics in the database 212. The processing module 202 of the system 200 and / or the I / O circuitry may be configured to control one or more functions of the elements of the I / O module 206 through computer program instructions, for example, software and / or firmware, stored on a memory. The memory module 204, and / or the like, is accessible to the processing module 202 of the system 200.
[0083] The communication module 208 is configured to facilitate communication between the system 200 and other components of the digital media platform 106 or the payment platform 126. For example, the communication module 208 is capable of facilitating communication between the system 200, the database 212, the digital media platform 106, the CDN 118, the exchange server 122, and the payment platform 126.
[0084] In some embodiments, the processing module 202 and / or other components of the traffic estimation module 220, the user identification module 222, and the timer updation module 224 may access the database 212 using a storage interface (not shown in FIG. 2). The storage interface may include, for example, an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a RAID controller, a SAN adapter, a network adapter, and / or any component providing the various modules or components described herein with access to the database 212.
[0085] In various non-limiting examples, the traffic estimation module 220 is configured to determine an expected traffic on the payment platform 126 based, at least in part, on the one or more users 104 streaming the media content 108 within the limited-access duration from the digital media platform 106 on one or more user devices. Herein, the expected traffic indicates one or more users that are expected to be redirected to the payment platform 126 on an expiry of the limited -access duration. It is noted that the determination of the expected traffic is performed continuously for different sets of users of the users 104 to ensure that the load on the payment platform 126 due to the expiry of the limited-access duration of different users is continuously monitored.
[0086] In an implementation, the traffic estimation module 220 is configured to utilize Time-to-Live (TTL) token refresh requests for determining the expected traffic on the payment platform 126. Herein, the term ‘Time-to-Live (TTL) token’ in the context of a streaming service refers to a temporary, time-bound authentication token that grants users 104 limited-time access to streaming content or platform resources. The TTL token ensures that access is restricted to a specific duration, after which it automatically expires, preventing unauthorized reuse or prolonged access beyond the allowed session.
[0087] In particular, the traffic estimation module 220 is configured to receive one or more Time to Live (TTL) token refresh requests from the one or more user devices streaming the media content 108 associated with the digital media platform 106. Herein, each TTL token request is associated with an ongoing stream of the media content 108 within the limited-access duration for a particular user device. As may be understood, the number of the TTL token requests received by the digital media platform 106 allows the traffic estimation module 220 to estimate the number of active users on the platform. Then, the traffic estimation module 220 is configured to determine a remaining duration of the limited-access duration for each user device of the one or more user devices based, at least in part, on the one or more TTL token requests. This aspect allows the traffic estimation module 220 to understand which users from the active users are streaming within the limited-access duration. Then, the traffic estimation module 220 is configured to compute the expected traffic on the payment platform 126 based, at least in part, on the remaining duration for each user device.
[0088] In an implementation module, the traffic estimation module 220 is configured to utilize information related to a number of active users for determining the expected traffic on the payment platform 126. In particular, the traffic estimation module 220 is configured to determine the number of active users streaming the media content 108 with the limited-access duration using an application associated with the digital media platform 106. Then, the traffic estimation module 220 is configured to determine a number of users to be redirected to the payment platform 126 at a particular time instance concurrently on the expiry of the limited-access duration based, at least in part, on the number of active users. Then, the traffic estimation module 220 is configured to compute the expected traffic on the payment platform based, at least in part, on the number of users.
[0089] In an implementation module, the traffic estimation module 220 is configured to utilize event- related information for determining the expected traffic on the payment platform 126. In particular, the traffic estimation module 220 is configured to identify an event in the media content, based, at least in part, on metadata associated with the media content 108. Herein, the term ‘event’ refers to any instance within the media content 108 being streamed by the users 104 that may be of particular interest to the said users 104. For example, during a football match, a goalkeeper losing or saving a goal may be called an event. In another example, a batter scoring a six during a cricket match can be called an event. In other words, events are special instances within themedia content 108 that may be increased interest to the users 104. As may be understood, whenever an event takes place during the stream of the media content 108, the interest of users 104 is generally increased which may cause new users to onboard the stream, thus increasing the traffic for the digital media platform 106. This in turn, will increase the traffic for the payment platform 126 when the limitedaccess duration of these new users expires.
[0090] For example, when a batter scores a six, the same may be reported on news and radio, which may garner interest from previously uninterested users prompting them to join the stream. It is noted that due to the nature of live events (such as sporting events), the rise and fall in user traffic oftenfollows a predictable pattern. To that end, this rise and fall in the user traffic may be predicted as well. To achieve this, the traffic estimation module 220 is configured to access the event log 216 from the database 212 associated with the system 200 based, at least in part, on the event. Herein, the event log 216 includes information related to a number of users streaming content while one or more historical events similar to the identified event occurred during one or more historical streams. Then, the traffic estimation module 220 is configured to determine, via the prediction model 218 with the system 200, an expected number of concurrent users streaming the media content 108 within the limited-access duration based, at least in part, on the event log 216. It is noted that the prediction model 218 is an Al or ML model that is capable of predicting user traffic that will be faced by the payment platform 126 at a particular time instance. Examples of the prediction model 218 includes, but are not limited, to linear regression, decision trees, random forests, Support Vector Machines (SVMs), neural networks, logistic regression, Naive Bayes, Lasso regression, etc., among other suitable models.
[0091] In an example, if the prediction model 218 recognizes a pattern from historical streams of a football match, that approximately a thousand new users join the stream using the limited-access duration after a new goal, then it determines the expected number of current users to be the sum of number of active users and the new thousand users (i.e., the expected users). Then, the traffic estimation module 220 is configured to compute the expected traffic on the payment platform 126 based, at least in part, on the expected number of concurrent users.
[0092] However, as may be understood, in real-world scenarios, the traffic may encounter temporary fluctuations due to temporary spikes in viewership due to such events as well. To that end, in an implementation, the traffic estimation module 220 is configured to identify an event in the media content 108 based, at least in part, on metadata associated with the media content 108. Then, the traffic estimation module 220 accesses an event log, such as the event log 216 from the database 212 based, at least in part, on the event. Then, the traffic estimation module 220 computes a fluctuation metric for the media content 108 based, at least in part, on the event log. Herein, the fluctuation metric indicates a temporary increase or decrease in the number of the one or more users in response to the event. Further, the traffic estimation module 220 is configured to update the expected traffic based, at least in part, on the fluctuation metric. In other words, the expected traffic is compensated using the fluctuation metric. For example, the prediction model 218 may recognize a pattern from the historical streams that after a wicket is lost during a cricket match, the viewership increases temporarily by five hundred new users who usually drop off even before their limited-access duration expires. Thus, the fluctuation metric may be used to update the expected traffic when such events are detected to ensure that the system 200 does not change the limitedaccess duration of the users 104 unnecessarily.
[0093] As described earlier, if the expected traffic is equal to or lowerthan the predetermined threshold load of the payment platform 126, then the system 200 does not change or update the limitedaccess duration for its users 104. In an embodiment, the traffic estimation module 220 determinesthe predetermined threshold load using health metrics of the payment platform 126. In particular, the traffic estimation module 220 can receive one or more health metrics from the payment platform 126. Herein, the one or more health metrics indicate the real-time health of the payment platform 126. Then, the traffic estimation module 220 can dynamically determine the predetermined threshold load based, at least in part, on the one or more health metrics.
[0094] In a scenario, where the expected traffic is greater than the predetermined threshold load of the payment platform 126, the traffic estimation module 220 is configured to invoke the user identification module 222. In this implementation, the user identification module 222 is configured to identify a subset of users from the one or more users 104 based, at least in part, on a propensity metric corresponding to each user. Herein, the propensity metric indicates the likelihood of a particular user subscribing to a streaming service offered by the digital media platform 106. The subset of users includes users who are likely to proceed with the payment process for subscribing or paying for the pay-per-view. In other words, this subset of users are those who will not drop off from the stream after the expiry of their corresponding limited-access duration.
[0095] In a particular instance, for identifying the subset of users, the user identification module 222 is configured to compute a user retention cost of each user of the one or more users for the digital media platform 106. Herein, the ‘user retention cost’ refers to the total expenses incurred by the digital media platform 106 to retain and engage non-paying users over a specific period. These costs are associated with content delivery, infrastructure usage, promotional offers, and engagement strategies, such as the limited-access duration, aimed at keeping free users active on the platform to convert them into paying subscribers. It is noted that for some users that user retention cost may be too high for them to be allowed in the subset of users. The limited-access duration for such users may be reduced to avoid congestion at the payment platform.
[0096] Then, the user identification module 222 is configured to compute the propensity metric for each user based, at least in part, on a location of each user, a user device associated with each user, a subscription history of each user, and a network associated with each user. It is noted that users 104 belonging to different locations and using different user devices have distinct likelihoods for subscribing to the platform. For example, a user using a high-end smartphone from an urban area generally has a better chance of subscribing to the streaming service than a user with a low- end television in a rural area. Further, information from the subscription history of the user can help the user identification module 222 configure the propensity metric as well. For example, a user with a history of previous pay-per-view purchases indicates a higher likelihood of future purchases as well. Further, it has been found through observations that users with higher-quality networks have higher chances of subscribing to the streaming service as well. Then, the subset of users is determined based, at least in part, on the propensity metric and the user retention cost corresponding to each user.
[0097] Further, in another implementation, the user identification module 222 is configured to identify the subset of users by identifying an event in the media content 108, based, at least in part, onmetadata associated with the media content 108. It is noted that the process for determining the event has already been described earlier. To that end, an explanation is not provided again for the sake of brevity. Then, the user identification module 222 is configured to determine an event-driven conversion metric for each user based, at least in part, on the event and a user profile corresponding to each user. Herein, the event-driven conversion metric indicates the likelihood of a particular user subscribing to the service in response to an event identified within the ongoing stream of the media content 108. As explained earlier, different events have different effects on different users. For instance, a goal from the Indian football team may prompt a user who is an Indian football fan to subscribe to the service, while it may discourage another user who is a fan of the German football team from subscribing to the service during a live stream of a football match between India and Germany. Therefore, the user identification module 222 utilizes information from the user profile of each user from the user profiles 214 available in the database 212, along with the information about the identified event for determining the even-driven conversion metric. Then, the subset of users is determined based, at least in part, on the event-driven conversion metric, the propensity metric, and the user retention cost corresponding to each user.
[0098] In an embodiment, the timer updation module 224 is configured to facilitate the digital media platform 106 to update the limited-access duration for the subset of users by a predefined duration. In various instances, the process of updating the limited-access duration includes one of extending or reducing the limited-access duration.
[0099] In an implementation, for updating the limited-access duration, the timer updation module 224 is configured to identify one or more user cohorts from the subset of users. Then, the timer updation module 224 is configured to select a unique predefined duration for each user cohort from the one or more cohorts based, at least in part, on a set of duration rules. Herein, the set of duration rules may be predefined by an administrator of the system 200. Then, the timer updation module 224 is configured to notify the digital media platform 106 to update the limited-access duration of each user cohort with the corresponding unique predefined duration. Herein, the process of updating the limited-access duration includes one of extending or reducing the limited-access duration by the unique predefined duration.
[0100] In a non-limiting scenario, for identifying the one or more user cohorts, the timer updation module 224 is configured to access a user profile corresponding to each user from the subset of users from the user profiles 214. Then, the timer updation module 224 is configured to segregate the subset of users into the one or more user cohorts based, at least in part, on the corresponding user profile of each user and a set of predefined rules.
[0101] In another implementation, for updating the limited-access duration, the timer updation module 224 is configured to compute a targeted content driven yield from each user of the subset of users. The term ‘targeted content driven yield’ refers to the yield generated by the digital media platform 106 by displaying one or more targeted media content, i.e., Ads, to its users. In other words, the targeted content driven yield is generated by streaming one or more targeted content in betweenthe media content 108 to each user. Then, the timer updation module 224 is configured to determine the predefined duration for each user based, at least in part, on the targeted content driven yield from each user. Then, the timer updation module 224 is configured to notify the digital media platform 106 to update the limited-access duration of each user by the corresponding predefined duration for each user. Herein, the process of updating the limited-access duration includes one of extending or reducing the limited-access duration by the predefined duration.
[0102] FIG. 3 illustrates various exemplary Graphical User Interfaces (GUIs) depicting a process 300 for redirecting one or more users 104 to a payment gateway associated with the payment platform 126 on expiry of the limited-access duration, in accordance with an embodiment of the present disclosure.
[0103] In the illustrated GUI 302, a live sports match (such as a cricket match) between two different teams is depicted. The live sports match can be viewed by the one or more users 104. In an instance, the one or more users 104 may be free-tier subscribers of the streaming service offered by the digital media platform 106. This subscription may grant the one or more users 104 access to the media content 108 such as the live sports match for a limited time, i.e., the limited-access duration. During the limited-access duration, the one or more users 104 are allowed to view the live sports match. In some instances, advertisements may be shown to the one or more users 104 during the limited-access duration as well.
[0104] The one or more users 104 can use their respective user devices to view the media content 108. In some instances, the one or more users 104 may access the media content 108 either using an application or a website offered by the digital media platform 106. The application or website may allow the one or more users 104 to view or interact with the media content 108 hosted by the digital media platform 106. In some instances, the application may be installed on the respective user devices of the one or more users 104. In a particular implementation, the application may be a web application that the user devices may access to view or interact with the services (such as a streaming service) offered by the digital media platform 106.
[0105] The GUI 302 further depicts a view progress bar for displaying the total duration of the media content 108 (see, 306) and how far along a particular user has viewed the said media content 108 (see, 304). The term ‘view progress bar’ refers to a graphical element on the GUI 302 that visually displays the ongoing progress of the media content 108 (here, the cricket match). The visual progress bar allows the users to see how far along they have viewed the media content 108 (see, 304), the overall duration of the media content 108 (see 306), orthe remaining duration of the media content 108. For the one or more users 104, the view progress bar may depict an indicator 312 for the limited-access duration as well. In other words, the indicator 312 is placed on the view progress bar to show the one or more users 104, the limited-access duration.
[0106] Upon the expiry of the limited-access duration, the one or more users 104 can be prompted to either subscribe to the service (such as one or more types of paid tier subscriptions) or purchase a pay-per-view for the media content, i.e., the live sports event. In other words, when the limited-access duration expires, the one or more users 104 may be prompted to subscribe to the service or watch the media content using a pay-per-view model.
[0107] In a non-limiting implementation, the GUI 308 may be shown to the one or more users 104 on the display on their respective user devices. Then, the users 104 may decide whether they wish to proceed with the subscription or stop watching the media content 108. Once, the one or more users 104 decide to proceed with the subscription, they can select an option to proceed from the GUI 308 on their display. For example, the user 104A may click on the ‘CLICK TO SUBSCRIBE’ button on the GUI 308 to subscribe to a paid tier of the streaming service.
[0108] Upon receiving the user selection, the one or more users 104 can be redirected to a payment gateway associated with a payment platform 126. The payment gateway facilitates the users 104 to perform a payment transaction for the subscription or pay-per-view. In a non-limiting example, GUI 310 illustrates an exemplary payment gateway that may be shown to the one or more users 104.
[0109] As described earlier, during live events, large numbers of users may be watching the media content 108 using the limited-access duration provided by the digital media platform 106. In such a scenario, the limited-access duration for many users, i.e., one or more users 104 may expire simultaneously or near each other, thus pushing a large number of users to the payment gateway. This user traffic from the one or more users 104 being redirected to the payment platform 126 can cause it to fail. In particular, since payment platform 126 is generally not configured to simultaneously serve such an unexpected user traffic volume, they can crash or fail to complete the payment transaction. In other words, many users from the one or more users 104 may fail to complete their payment transactions which would prevent them from viewing the live sports match. This leads to a poor user experience for these users. Further, the payment platform 126 may encounter a severe outage during the payment gateway crash, leading to failed / delayed payments which may require the platform to issue refunds or chargebacks, thus causing financial losses.
[0110] To avoid this situation, the system 200 of the proposed approach dynamically manages the limited-access duration of the media content 108 for different users from the one or more users 104. As may be appreciated, this aspect ensures that user traffic reaching the payment gateway is effectively staggered. Due to the staggering usertraffic, the payment platform 126 can easily handle the payment transactions without the risk of the payment gateway crashing or failing to complete the transactions. This aspect has been described further with reference to FIG. 4.
[0111] FIG. 4 illustrates various exemplary Graphical User Interfaces (GUIs) depicting a process 400 for dynamically managing the limited-access duration of the media content offered to the one or more users 104, in accordance with an embodiment of the present disclosure. The system 200 can dynamically manage the limited-access duration for different users based on various criteria to ensure that the user traffic reaching the payment platform 126 is staggered effectively. In an example, user 104A, user 104B, and user 104C may be the one or more users 104 watching the media content 108 using the limited-access duration.
[0112] As described earlier, the limited-access duration may be different for each user and different users may be watching different media content as well. The goal of the present disclosure is to stagger the user traffic reaching the payment platform 126 such that it does not face any issues in processing the payment transactions. To that end, the system 200 considers all the users, whose respective limited-access duration is expected to end simultaneously or in near the same time to be a part of the one or more users 104. In the illustrated example, it is assumed that the users 104A-104C are watching the same media content with an identical limited-access duration that will expire at the same time for the sake of explanation only. To that end, the same should not be construed to be a limitation of the present disclosure. Further, in some instances, each of the user 104A, user 104B, and user 104C may represent an individual user cohort containing multiple users as well.
[0113] In a non-limiting implementation, the user 104A may be watching the live event, i.e., the media content 108 on their television using the application offered by the digital media platform 106. The user 104A may be given a limited-access duration of X minutes, shown by indicator 312 on the view progress bar in GUI 302. The system 200 may compute the expected traffic on the payment platform 126 after X minutes when the user 104A is expected to be redirected to the payment gateway associated with the payment platform 126. It is noted that many users may have their respective limited-access duration expire at the same time as user 104A such that all of the said users will be redirected to the payment gateway. If the system 200 determines that the expected traffic is equal to or less than the predetermined threshold load of the payment platform 126, the system 200 does not update the limited-access duration of the user 104A.
[0114] Alternatively, if the system 200 determines that the expected traffic is greater than the predetermined threshold load of the payment platform 126, the system 200 can determine whether to update the limited-access duration of the user 104A or not. In particular, the system 200 computes the propensity metric for the user 104A. Then, the system 200 can determine whether to update the limited-access duration of the user 104A or not, based on the propensity metric and a set of predefined rules (defined by an administrator of the system 200). Herein, the set of predefined rules (or simply, predefined rules) may define the requisite metric values (or cost values) for choosing to update the limited-access duration. In some instances, the system 200 may compute an event-driven conversion metric and a user retention cost for the user 104A. Then, the system 200 may determine based on the event-driven conversion metric, the propensity metric, the user retention cost corresponding to the user 104A, and a set of predefined rules whether to update the limited-access duration of the user 104A or not. If it’s determined, based on the various metrics and the predefined rules, that user 104A is not eligible for the update in the limited-access duration, then the system 200 does not update the limited-access duration of the user 104A. As depicted in FIG. 4, the indicator 312 for the limited-access duration in GUI 400 remains constant and does not change its position.
[0115] As may be understood, since many users will be redirecting to the payment platform 126, it is not necessary for the system 200 to update the limited-access duration for every user (such as user 104A). To that end, the system 200 can leave the limited-access duration for the user 104A unchanged while reducing or extending the respective limited-access duration of other users to ensure that the load on the payment platform 126 does not exceed its predetermined threshold load. It is understood that GUI 302 indicates the limited-access duration using indicator 312 before the system 200 determines whether to update the limited-access duration for user 104A or not. While GUI 402 indicates it after the decision is made by the system 200. In the illustrated GUI 402, the indicator 408 for the limited-access duration remains at the same position as the indicator 312. It is noted that the various metrics, such as propensity metric, the user retention cost, and the event- driven conversion metric allow the system 200 to manage the limited-access duration for each user.
[0116] In another non-limiting implementation, the user 104B may be watching the live event, i.e., the media content 108 on their tablet device using the application offered by the digital media platform 106. The user 104B may be given a limited-access duration of X minutes, shown by indicator 312 on the view progress bar in GUI 302. The system 200 may compute the expected traffic on the payment platform 126 after X minutes when the user 104B is expected to be redirected to the payment gateway associated with the payment platform 126 along with other users.
[0117] If the system 200 determines that the expected traffic is greater than the predetermined threshold load of the payment platform 126, the system 200 can update the limited-access duration of the user 104B. In a particular scenario, the system 200 computes a propensity metric forthe user 104B. Then, the system 200 can determine whether to update the limited-access duration of the user or not, based on the propensity metric and a set of predefined rules. In some instances, the system 200 may compute an event-driven conversion metric and a user retention cost forthe user 104B. Then, the system 200 may determine based on the event-driven conversion metric, the propensity metric, the user retention cost corresponding to the user 104B, and the predefined rules whether to update the limited-access duration of the user or not.
[0118] If the system decides to update the limited-access duration of the user 104B based on the predefined rules, then the system 200 computes a predefined duration corresponding to the user 104B for updating the limited-access duration.
[0119] In an instance, the predefined duration may be determined by identifying a user cohort for the user 104B based on the user profile. Then, the system 200 assigns a unique predefined duration for the identified user cohort to the user 104B. In another instance, the predefined duration may be determined by computing a targeted content driven yield forthe user 104B. Then, the system 200 identifies the predefined duration based on the targeted content driven yield of the user 104B. In an example, the predefined duration determined forthe user 104B may be +Y minutes.
[0120] Upon determining the predefined duration for the user 104B, the system 200 updates the limited-access duration by extending it by the predefined duration. In other words, the limitedaccess duration of X minutes is extended by Y minutes to obtain an updated limited-access durationof (X+Y) minutes. Further, the system 200 is configured to update the position of the indicator 312 by extending (or moving) it by Y minutes on the view progress bar. It is understood that GUI 302 indicates the limited-access duration using indicator 312 before the system 200 determines whether to update the limited-access duration for user 104B or not. While GUI 404 indicates it after the decision is made by the system 200. In the illustrated GUI 404, the indicator 408 (i.e., at an identical position as indicator 312) for the limited-access duration changes to the position shown by indicator 410.
[0121] In another non-limiting implementation, the user 104C may be watching the live event, i.e., the media content 108 on their laptop using the browser installed on their laptop to view a web application or website offered by the digital media platform 106. The user 104C may be given a limited-access duration of X minutes, shown by indicator 312 on the view progress bar using GUI 302. The system 200 may compute the expected traffic on the payment platform 126 after X minutes when the user 104B is expected to be redirected to the payment gateway associated with the payment platform 126. If the system 200 determines that the expected traffic is greater than the predetermined threshold load of the payment platform 126, the system 200 updates the limitedaccess duration of the user 104C. In a particular scenario, the system 200 computes a propensity metric for the user 104C. In some instances, the system 200 may also compute an event-driven conversion metric and the user retention cost for the user 104C. Then, the system 200 may determine based on the event-driven conversion metric, the propensity metric, the user retention cost corresponding to the user 104B, and the set of predefined rules whether to update the limitedaccess duration of the user or not.
[0122] If the system 200 decides to update the limited-access duration of the user 104B based on the predefined rules, then the system 200 computes a predefined duration for updating the limitedaccess duration.
[0123] In an instance, the predefined duration may be determined by identifying a user cohort for the user 104C based on the user profile. Then, the system 200 assigns a unique predefined duration for the identified user cohort to the user 104C. In another instance, the predefined duration may be determined by computing a targeted content driven yield for the user 104C. Then, the system 200 identifies the predefined duration based on the targeted content driven yield of the user 104C. In an example, the predefined duration determined for the user may be -Z minutes.
[0124] Upon determining the predefined duration for the user 104C, the system 200 updates the limited-access duration by reducing or cutting it by the predefined duration. In other words, the limited-access duration of X minutes is reduced by Z minutes to obtain an updated limited-access duration of (X-Z) minutes. Further, the system 200 is configured to update the position of the indicator 312 by reducing (or moving) it by Z minutes on the view progress bar. It is understood that GUI 302 indicates the limited-access duration using indicator 312 before the system 200 determines whether to update the limited-access duration for user 104C or not. While GUI 406 indicates it after the decision is made by the system 200. In the illustrated GUI 406, the indicator 408 (i.e., at anidentical position as indicator 312) for the limited-access duration changes to the position shown by indicator 412.
[0125] FIG. 5 illustrates a process flow diagram depicting a method 500 for dynamically managing a limited-access duration of media content 108 associated with a digital media platform, in accordance with an embodiment of the present disclosure. The various steps and / or operations of the flow diagram, and combinations of steps / operations in the flow diagram, may be implemented by, for example, hardware, firmware, a processor, circuitry, and / or a system (such as the system 200) explained with reference to FIG. 2 and / or by a different device associated with the execution of software that includes one or more computer program instructions. The method 500 starts at operation 502.
[0126] At operation 502, the method 500 includes determining, by a system such as system 200, an expected traffic on a payment platform 126 based, at least in part, on one or more users streaming the media content 108 within the limited-access duration from the digital media platform 106 on one or more user devices. As described earlier, the expected traffic indicates one or more users that are expected to be redirected to the payment platform 126 on an expiry of the limited-access duration.
[0127] At operation 504, the method 500 includes in response to determining that the expected traffic is greater than a predetermined threshold load of the payment platform 126, identifying, by the system 200, a subset of users from the one or more users based, at least in part, on a propensity metric corresponding to each user. As described earlier, the propensity metric indicates a likelihood of a particular user subscribing to a streaming service offered by the digital media platform 106.
[0128] At operation 506, the method 500 includes facilitating, by the system 200, the digital media platform 106 to update the limited-access duration for the subset of users by a predefined duration, wherein updating the limited-access duration comprises one of extending or reducing the limitedaccess duration.
[0129] The disclosed method with reference to FIG. 5, or one or more operations of the system 200 may be implemented using software including computer-executable instructions stored on one or more computer-readable media (e.g., non-transitory computer-readable media, such as one or more optical media discs, volatile memory components (e.g., DRAM or SRAM), or non-volatile memory or storage components (e.g., hard drives or solid-state non-volatile memory components, such as Flash memory components) and executed on a computer (e.g., any suitable computer, such as a laptop computer, netbook, Web book, tablet computing device, smartphone, or other mobile computing devices). Such software may be executed, for example, on a single local computer or in a network environment (e.g., via the Internet, a wide-area network, a local-area network, a remote web-based server, a client-server network (such as a cloud computing network), or other such networks) using one or more network computers. Additionally, any of the intermediate or final data created and used during the implementation of the disclosed methods or systems may also be stored on one or more computer-readable media (e.g., non-transitory computer-readablemedia) and are considered to be within the scope of the disclosed technology. Furthermore, any of the software-based embodiments may be uploaded, downloaded, or remotely accessed through a suitable communication means. Such a suitable communication means include, for example, the Internet, the World Wide Web, an intranet, software applications, cable (including fiber optic cable), magnetic communications, electromagnetic communications (including RF, microwave, and infrared communications), electronic communications, or other such communication means.
[0130] Although the invention has been described with reference to specific exemplary embodiments, it is noted that various modifications and changes may be made to these embodiments without departing from the scope of the invention. For example, the various operations, blocks, etc., described herein may be enabled and operated using hardware circuitry (for example, complementary metal oxide semiconductor (CMOS) based logic circuitry), firmware, software, and / or any combination of hardware, firmware, and / or software (for example, embodied in a machine-readable medium). For example, the apparatuses and methods may be embodied using transistors, logic gates, and electrical circuits (for example, application-specific integrated circuit (ASIC) circuitry and / or Digital Signal Processor (DSP) circuitry).
[0131] Notably, the system 200 and its various components may be enabled using software and / or using transistors, logic gates, and electrical circuits (for example, integrated circuit circuitry such as ASIC circuitry). Various embodiments of the invention may include one or more computer programs stored or otherwise embodied on a computer-readable medium, wherein the computer programs are configured to cause a processor or the computer to perform one or more operations. A computer-readable medium storing, embodying, or encoded with a computer program or similar language may be embodied as a tangible data database storing one or more software programs that are configured to cause a processor or computer to perform one or more operations. Such operations may be, for example, any of the steps or operations described herein.
[0132] In some embodiments, the computer programs may be stored and provided to a computer using any type of non-transitory computer-readable media. Non-transitory computer-readable media includes any type of tangible storage media. Examples of non-transitory computer-readable media include magnetic storage media (such as floppy disks, magnetic tapes, hard disk drives, etc.), optical magnetic storage media (e.g. magneto-optical disks), CD-ROM (compact disc read-only memory), CD-R (compact disc recordable), CD-R / W (compact disc rewritable), DVD (Digital Versatile Disc), BD (BLU-RAY® Disc), and semiconductor memories (such as mask ROM, PROM (programmable ROM), EPROM (erasable PROM), flash memory, RAM (random access memory), etc.). Additionally, a tangible data database may be embodied as one or more volatile memory devices, one or more non-volatile memory devices, and / or a combination of one or more volatile memory devices and non-volatile memory devices. In some embodiments, the computer programs may be provided to a computer using any type of transitory computer-readable media. Examples of transitory computer-readable media include electric signals, optical signals, and electromagneticwaves. Transitory computer-readable media can provide the program to a computer via a wired communication line (e.g., electric wires and optical fibers) or a wireless communication line.
[0133] Various embodiments of the invention, as discussed above, may be practiced with steps and / or operations in a different order, and / or with hardware elements in configurations, which are different from those which are disclosed. Therefore, although the invention has been described based on these exemplary embodiments, it is noted that certain modifications, variations, and alternative constructions may be apparent and well within the spirit and scope of the invention.
[0134] Although various exemplary embodiments of the invention are described herein in a language specific to structural features and / or methodological acts, the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as exemplary forms of implementing the claims.
Claims
Claims
1. A computer-implemented method for dynamically managing a limitedaccess duration of media content associated with a digital media platform comprising:determining, by a system, an expected traffic on a payment platform based, at least in part, on one or more users streaming the media content within the limited-access duration from the digital media platform on one or more user devices, wherein the expected traffic indicates one or more users that are expected to be redirected to the payment platform on an expiry of the limited-access duration;in response to determining that the expected traffic is greater than a predetermined threshold load of the payment platform, identifying, by the system, a subset of users from the one or more users based, at least in part, on a propensity metric corresponding to each user, wherein the propensity metric indicates a likelihood of a particular user subscribing to a streaming service offered by the digital media platform; andfacilitating, by the system, the digital media platform to update the limited-access duration for the subset of users by a predefined duration, wherein updating the limited-access duration comprises one of extending or reducing the limited-access duration.
2. The computer-implemented method as claimed in claim 1, further comprising:receiving, by the system, one or more health metrics from the payment platform, the one or more health metrics indicating a real-time health of the payment platform; anddynamically determining, by the system, the predetermined threshold load based, at least in part, on the one or more health metrics.
3. The computer-implemented method as claimed in claim 1, wherein determining the expected traffic comprises:receiving, by the system, one or more Time to Live (TTL) token refresh requests from the one or more user devices streaming the media contentassociated with the digital media platform, wherein each TTL token request is associated with an ongoing stream of the media content within the limited-access duration for a particular user device;determining, by the system, a remaining duration of the limited-access duration for each user device of the one or more user devices based, at least in part, on the one or more TTL token requests; andcomputing, by the system, the expected traffic on the payment platform based, at least in part, on the remaining duration for each user device.
4. The computer-implemented method as claimed in claim 1, wherein determining the expected traffic comprises:determining, by the system, a number of active users streaming the media content with the limited-access duration using an application associated with the digital media platform;determining, by the system, a number of users to be redirected to the payment platform at a particular time instance concurrently on the expiry of the limited-access duration based, at least in part, on the number of active users; andcomputing, by the system, the expected traffic on the payment platform based, at least in part, on the number of users.
5. The computer-implemented method as claimed in claim 1, wherein determining the expected traffic comprises:identifying, by the system, an event in the media content, based, at least in part, on metadata associated with the media content;accessing, by the system, an event log from a database associated with the system based, at least in part, on the event, wherein the event log comprises information related to a number of users streaming content while one or more historical events similar to the identified event occurred during one or more historical streams;determining, by a prediction model associated with the system, an expected number of concurrent users streaming the media content within the limited-access duration based, at least in part, on the event log; and computing, by the system, the expected traffic on the payment platform based, at least in part, on the expected number of concurrent users.
6. The computer-implemented method as claimed in claim 1, wherein identifying the subset of users comprises:computing, by the system, a user retention cost of each user of the one or more users for the digital media platform;computing, by the system, the propensity metric for each user based, at least in part, on a location of each user, a user device associated with each user, a subscription history of each user, and a network associated with each user; and determining, by the system, the subset of users based, at least in part, on the propensity metric and the user retention cost corresponding to each user.
7. The computer-implemented method as claimed in claim 6, wherein identifying the subset of users further comprises:identifying, by the system, an event in the media content, based, at least in part, on metadata associated with the media content;determining, by the system, an event-driven conversion metric for each user based, at least in part, on the event and a user profile corresponding to each user; anddetermining, by the system, the subset of users based, at least in part, on the event-driven conversion metric, the propensity metric, and the user retention cost corresponding to each user.
8. The computer-implemented method as claimed in claim 1, wherein facilitating the digital media platform to update the limited-access duration comprises:identifying, by the system, one or more user cohorts from the subset of users;selecting, by the system, a unique predefined duration for each user cohort from the one or more cohorts based, at least in part, on a set of duration rules; and notifying, by the system, the digital media platform to update the limitedaccess duration of each user cohort with the corresponding unique predefined duration, wherein updating the limited-access duration comprises one of extending or reducing the limited-access duration by the unique predefined duration.
9. The computer-implemented method as claimed in claim 5, wherein identifying the one or more user cohorts comprises:accessing, by the system, a user profile corresponding to each user from the subset of users; andsegregating, by the system, the subset of users into the one or more user cohorts based, at least in part, on the corresponding user profile of each user and a set of predefined rules.
10. The computer-implemented method as claimed in claim 1, wherein facilitating the digital media platform to update the limited-access duration comprises:computing, by the system, a targeted content driven yield from each user of the subset of users, wherein the targeted content driven yield is generated by streaming one or more targeted content in between the media content to each user;determining, by the system, the predefined duration for each user based, at least in part, on the targeted content driven yield from each user; and notifying, by the system, the digital media platform to update the limitedaccess duration of each user by the corresponding predefined duration for each user, wherein updating the limited-access duration comprises one of extending or reducing the limited-access duration by the predefined duration.
11. The computer-implemented method as claimed in claim 1, further comprising:identifying, by the system, an event in the media content, based, at least in part, on metadata associated with the media content;accessing, by the system, an event log from a database associated with the system based, at least in part, on the event, wherein the event log comprisesinformation related to a number of the one or more users streaming content while one or more historical events similar to the identified event occurred during one or more historical streams;computing, by the system, a fluctuation metric for the media content based, at least in part, on the event log, wherein the fluctuation metric indicates a temporary increase or decrease in the number of the one or more users in response to the event; andupdating, by the system, the expected traffic based, at least in part, on the fluctuation metric.
12. A system for dynamically managing a limited-access duration of media content associated with a digital media platform comprises:a memory for storing instructions; anda processor configured to execute the instructions and thereby cause the system to at least:determine an expected traffic on a payment platform based, at least in part, on one or more users streaming the media content within the limited -access duration from the digital media platform on one or more user devices, wherein the expected traffic indicates one or more users that are expected to be redirected to the payment platform on an expiry of the limited-access duration;in response to determining that the expected traffic is greater than a predetermined threshold load of the payment platform, identify a subset of users from the one or more users based, at least in part, on a propensity metric corresponding to each user, wherein the propensity metric indicates a likelihood of a particular user subscribing to a streaming service offered by the digital media platform; andfacilitate the digital media platform to update the limited-access duration for the subset of users by a predefined duration, wherein updating the limitedaccess duration comprises one of extending or reducing the limited-access duration.
13. The system as claimed in claim 12, wherein the system is further caused, at least in part, to:receive one or more health metrics from the payment platform, the one or more health metrics indicating a real-time health of the payment platform; and dynamically determine the predetermined threshold load based, at least in part, on the one or more health metrics.
14. The system as claimed in claim 12, wherein to determine the expected traffic, the system is caused, at least in part, to:receive one or more Time to Live (TTL) token refresh requests from the one or more user devices streaming the media content associated with the digital media platform, wherein each TTL token request is associated with an ongoing stream of the media content within the limited-access duration for a particular user device;determine a remaining duration of the limited-access duration for each user device of the one or more user devices based, at least in part, on the one or more TTL token requests; andcompute the expected traffic on the payment platform based, at least in part, on the remaining duration for each user device.
15. The system as claimed in claim 12, wherein to determine the expected traffic, the system is caused, at least in part, to:identify an event in the media content, based, at least in part, on metadata associated with the media content;access an event log from a database associated with the system based, at least in part, on the event, wherein the event log comprises information related to a number of users streaming content while one or more historical events similar to the identified event occurred during one or more historical streams;determine, by a prediction model, an expected number of concurrent users streaming the media content within the limited-access duration based, at least in part, on the event log; andcompute the expected traffic on the payment platform based, at least in part, on the expected number of concurrent users.
16. The system as claimed in claim 12, wherein to identify the subset of users, the system is caused, at least in part, to:compute a user retention cost of each user of the one or more users for the digital media platform;compute the propensity metric for each user based, at least in part, on a location of each user, a user device associated with each user, a subscription history of each user, and a network associated with each user; anddetermine the subset of users based, at least in part, on the propensity metric and the user retention cost corresponding to each user.
17. The system as claimed in claim 12, wherein to facilitate the digital media platform to update the limited-access duration, the system is caused, at least in part, to:identify one or more user cohorts from the subset of users; select a unique predefined duration for each user cohort from the one or more cohorts based, at least in part, on a set of duration rules; andnotify the digital media platform to update the limited-access duration of each user cohort with the corresponding unique predefined duration, wherein updating the limited-access duration comprises one of extending or reducing the limited-access duration by the unique predefined duration.
18. The system as claimed in claim 12, wherein to facilitate the digital media platform to update the limited-access duration, the system is caused, at least in part, to:compute a targeted content driven yield from each user of the subset of users, wherein the targeted content driven yield is generated by streaming one or more targeted content in between the media content to each user;determine the predefined duration for each user based, at least in part, on the targeted content driven yield from each user; andnotify the digital media platform to update the limited-access duration of each user by the corresponding predefined duration for each user, wherein updating the limited-access duration comprises one of extending or reducing the limited-access duration by the predefined duration.
19. The system as claimed in claim 12, wherein the system is further caused, at least in part, to:identify an event in the media content, based, at least in part, on metadata associated with the media content;access an event log from a database associated with the system based, at least in part, on the event, wherein the event log comprises information related to a number of the one or more users streaming content while one or more historical events similar to the identified event occurred during one or more historical streams;compute a fluctuation metric for the media content based, at least in part, on the event log, wherein the fluctuation metric indicates a temporary increase or decrease in the number of the one or more users in response to the event; and update the expected traffic based, at least in part, on the fluctuation metric
20. A non-transitory computer-readable storage medium comprising computer-executable instructions that, when executed by at least a processor of a system, cause the system to perform a method comprising:determining an expected traffic on a payment platform based, at least in part, on one or more users streaming the media content within the limited -access duration from the digital media platform on one or more user devices, wherein the expected traffic indicates one or more users that are expected to be redirected to the payment platform on an expiry of the limited-access duration;in response to determining that the expected traffic is greater than a predetermined threshold load of the payment platform, identifying a subset of users from the one or more users based, at least in part, on a propensity metric corresponding to each user, wherein the propensity metric indicates a likelihood ofa particular user subscribing to a streaming service offered by the digital media platform; andfacilitating the digital media platform to update the limited-access duration for the subset of users by a predefined duration, wherein updating the limited-access duration comprises one of extending or reducing the limited -access duration.