Multi-ad platform advertisement request scheduling method and system based on value decay prediction, and storage medium
Patent Information
- Application Number
- CN202611200831.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-08-10
- Publication Date
- 2026-10-23
AI Technical Summary
本发明要解决的技术问题是:现有移动应用客户端在多广告平台环境下采用静态的并发请求策略与单一价格排序策略,在某一广告平台针对同一用户标识和同一广告位标识连续中标后,仍持续向该已进入返回质量衰减状态的广告平台发送广告请求,导致客户端产生大量无效网络请求与超时重试,广告位平均加载耗时增加、移动设备网络流量与电量消耗增加;同时客户端逐条上传全量竞价明细,导致上传数据量偏大、服务端存储与计算负载偏高;而采用硬性屏蔽的频次控制又会使候选集收缩、填充失败率升高
[0049]与现有技术相比,本发明至少具有以下有益效果。
Smart Images

Figure CN122966301A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of mobile communication and data processing technology, and in particular to a method, system, and storage medium for scheduling the sending of advertising requests and the ranking of candidate advertisements based on value decay prediction when a mobile application client accesses multiple advertising platforms. Background Technology
[0002] Mobile application clients typically integrate software development kits (SDKs) from multiple third-party advertising platforms. When an ad display request is generated, the client's ad aggregation module concurrently sends ad requests to all candidate advertising platforms. Each advertising platform returns candidate ad creatives and their corresponding estimated revenue per thousand impressions (ROI). The client sorts these according to the returned RPI and displays the highest-ranked candidate ad.
[0003] The existing client-side ad aggregation implementation has the following technical problems.
[0004] First, the request strategy is static. Regardless of the quality of previous responses from various advertising platforms, the client concurrently sends requests to all candidate advertising platforms for each ad display request. When an advertising platform is repeatedly selected and displayed for the same user ID and the same ad slot ID, the number of candidate ads returned by that platform in subsequent requests decreases, the response timeout rate increases, and the proportion of empty ads or invalid candidates below the minimum price increases. The client still needs to complete the entire request establishment, timeout waiting, response parsing, and retry process for these invalid responses, generating a large number of invalid network requests. In a mobile network environment, this directly manifests as an increase in the average loading time of ad slots, an increase in the number of retries after request failures, an increase in network traffic consumption of mobile devices and the working time of radio frequency modules, and consequently, an increase in device power consumption.
[0005] Second, the amount of data uploaded by the client to the server is too large. Existing implementations typically upload the complete bidding details for each ad request (including the original user identifier value, the price returned by each platform, timestamp, etc.) to the server one by one, so that the server centrally calculates the scheduling strategy. On the one hand, this causes the amount of uploaded data to increase linearly with the number of ad requests, consuming the uplink bandwidth of mobile devices; on the other hand, it requires the server to store and traverse the entire detailed data, resulting in high storage consumption and computational load.
[0006] Third, the existing exposure frequency control mechanism is a hard-blocking mechanism, which controls individual ad creatives or individual advertisers. Once the frequency limit is reached, the corresponding creative is directly removed from the candidate set. This mechanism cannot be applied to the ad platform level; and once a hard block is implemented on the ad platform, it will cause the candidate ad set to shrink drastically, which will increase the ad slot fill failure rate and display failure rate, causing the client to trigger a new round of supplementary requests, further increasing the number of requests.
[0007] Therefore, a scheduling scheme is needed that can dynamically adjust the client's ad request sending behavior and candidate ranking based on the historical return data of the advertising platform, in order to reduce invalid network requests, reduce ad slot loading time and device power consumption, and reduce the amount of data uploaded by the client and the load on the server. Summary of the Invention
[0008] I. Technical problems to be solved The technical problem this invention aims to solve is as follows: Existing mobile application clients, in multi-ad platform environments, employ static concurrent request strategies and single-price ranking strategies. After winning bids for the same user identifier and the same ad slot identifier consecutively on a certain ad platform, they continue to send ad requests to the ad platform that has already entered a quality degradation state. This results in the client generating a large number of invalid network requests and timeout retries, increasing the average loading time of ad slots, and increasing the network traffic and power consumption of mobile devices. At the same time, the client uploads the full bidding details one by one, resulting in a large amount of uploaded data and a high server storage and computing load. Furthermore, using hard-blocking frequency control will shrink the candidate set and increase the filling failure rate. Technical solution
[0009] To address the aforementioned technical problems, this invention provides a multi-advertising platform ad request scheduling method based on value decay prediction, applicable to mobile application clients accessing multiple advertising platforms, comprising the following steps.
[0010] Step S1: Receive an ad display request and obtain the user identifier, ad slot identifier, ad type, request time, and candidate ad platform set corresponding to the ad display request. The user identifier is an ad identifier that has been anonymized; if the anonymized ad identifier cannot be obtained, the mobile application client generates a unique client identifier and stores it locally, using the unique client identifier as the user identifier. The ad type includes at least one of rewarded video, splash screen ad, interstitial ad, feed ad, and banner ad.
[0011] Step S2: Send advertising requests to multiple advertising platforms in the candidate advertising platform set, and receive candidate advertisements and corresponding converted revenue per thousand impressions returned by each advertising platform. The converted revenue per thousand impressions refers to a value that can be compared horizontally among multiple advertising platforms after converting the price returned by the advertising platform according to the revenue sharing ratio, currency conversion rules and settlement rules.
[0012] Step S3: Read the historical display data of each advertising platform relative to the same user identifier and the same ad slot identifier within a preset historical window from the local storage of the mobile application client. The preset historical window is 1 day. The historical display data includes the consecutive highest bid and actual number of impressions, the actual revenue per thousand impressions within the preset historical window, the number of impressions, and the time of the most recent impression.
[0013] Step S4: Calculate the user value consumption characteristics of each advertising platform based on the historical display data. The user value consumption characteristics include continuous winning bid characteristics, exposure density characteristics, time interval characteristics, and revenue change characteristics.
[0014] Step S5: Input the user value consumption characteristics into the value decay prediction model to obtain the value decay prediction value for each advertising platform. The value decay prediction value is used to characterize the decrease in the actual revenue per thousand impressions of the user identifier and the ad slot identifier within a subsequent time window when the advertising platform continues to display its ads.
[0015] Step S6: Maintain an over-bid index for each advertising platform. The over-bid index is determined based on the platform's consecutive highest bids and actual impressions, and the corresponding over-bid trigger threshold. The over-bid trigger threshold is dynamically adjusted according to the decrease in the platform's actual revenue per thousand impressions relative to the preset historical window start value: when the decrease exceeds a first proportion, the over-bid trigger threshold is lowered by one level; when the decrease exceeds a second proportion, it is lowered by another level, where the second proportion is greater than the first proportion; when the actual revenue per thousand impressions does not decrease, the over-bid trigger threshold is maintained or increased.
[0016] Step S7: Calculate the scheduling score for each advertising platform based on its converted revenue per thousand impressions, predicted value decay, and over-bidding index. Then, for advertising platforms whose over-bidding index reaches the preset over-bidding condition, implement a soft demotion. This soft demotion lowers the scheduling score of the advertising platform while retaining its eligibility to participate in subsequent bidding.
[0017] Step S8: Determine the target advertisement from the candidate advertisements returned by the multiple advertising platforms based on the scheduling score, and display the target advertisement.
[0018] Step S9: In at least one subsequent ad display request, reduce the request priority of the ad platform that has been subject to the soft downgrade; for ad platforms that have been subject to the soft downgrade and whose scheduling score is lower than a preset request threshold, skip sending ad requests to the ad platform in at least one subsequent ad display request, so as to reduce the number of ad requests sent by the mobile application client within the preset history window.
[0019] Step S10: The mobile application client calculates the over-bid index and scheduling parameters locally, uploads the over-bid index and scheduling parameters to the server, and receives the scheduling parameters issued by the server according to a preset issuance cycle.
[0020] III. Definitions of Key Parameters and Terms Revenue per thousand impressions (ROI): This refers to a value that developers can horizontally compare after being converted based on the advertising platform's return price, revenue sharing ratio, currency conversion rules, and settlement rules.
[0021] Actual revenue per thousand impressions: This refers to the value calculated based on the actual revenue and the actual number of impressions returned by the advertising platform after the ad is displayed.
[0022] Number of consecutive highest bids and actual impressions: refers to the number of times a candidate with the highest scheduling score is consecutively displayed on the same advertising platform under the same user ID and the same ad slot ID, and is denoted as N.
[0023] Excessive bidding trigger threshold: refers to the consecutive highest bids and actual impressions required for an advertising platform to enter the excessive bidding state, denoted as T.
[0024] Excessive Bidding Index: This refers to the degree to which an advertising platform continuously occupies display opportunities for the same user ID and the same ad slot ID, and is denoted as 0.
[0025] Soft demotion: refers to reducing the scheduling score or scheduling weight of an advertising platform, but not permanently removing the advertising platform from the candidate advertising platform set.
[0026] IV. Specific Implementation of the Value Decline Prediction Model In the first implementation, the value decay prediction model is a weighted linear model, and the predicted value decay value D_i of the i-th advertising platform is calculated according to the following formula: D_i = w1 × n(N_i) + w2 × n(Drop_i) + w3 × n(D_den_i) − w4 × n(Δt_i) The calculation methods for each input feature are as follows.
[0027] Continuous winning bid feature N_i: Take the highest consecutive bid and actual number of times the i-th advertising platform is displayed relative to the current user ID and the current ad slot ID within the preset history window.
[0028] Revenue variation characteristic Drop_i: Let E_start be the actual revenue per thousand impressions of the i-th advertising platform at the beginning position of the preset history window, and E_now be the most recent actual revenue per thousand impressions of the advertising platform. Then Drop_i = (E_start − E_now) / E_start; when E_now is greater than E_start, Drop_i is 0.
[0029] Exposure density feature D_den_i: The ratio of the number of times the i-th advertising platform is displayed in the preset historical window to the duration of the preset historical window.
[0030] The time interval feature Δt_i is the difference between the current request time and the most recent display time of the i-th advertising platform.
[0031] Normalization function n(x): n(x) = min(x / x_max, 1), where x_max is the normalization upper limit corresponding to the feature, which is issued by the server along with the scheduling parameters; when no issued value is received, the normalization upper limit of N_i is 10, the normalization upper limit of Drop_i is 0.5, the normalization upper limit of D_den_i is 20 times / day, and the normalization upper limit of Δt_i is 3600 seconds.
[0032] The initial values of weights w1 to w4 are 0.4, 0.3, 0.2, and 0.1, respectively. The server, based on the aggregated feedback data, uses the percentage decrease in the actual revenue per thousand impressions for each advertising platform in the subsequent request relative to the previous request as the target value, and employs the least squares method to fit and update w1 to w4. This updated value is then sent to the mobile application client along with the scheduling parameters.
[0033] In the second implementation, the value decay prediction model is a logistic regression model or a gradient boosting decision tree model. Using the four normalized features and the one-hot encoding of the ad type as model inputs, and the training label "whether the actual revenue per thousand impressions for the next request from the advertising platform for the same user identifier and the same ad slot identifier decreases by more than a set percentage compared to the current request," the server trains the model offline daily using aggregated historical data. The trained model parameters are then sent to the mobile application client along with the scheduling parameters, and the mobile application client performs forward inference locally.
[0034] V. Calculation of Over-Bidding Index and Scheduling Score In one implementation, the over-hit index O_i of the i-th advertising platform is calculated using the following formula: O_i = max(0, N_i − T_t) × W_t + Drop_i Where N_i represents the consecutive highest bid and the actual number of impressions, T_t represents the over-bidding trigger threshold corresponding to ad type t, W_t represents the weight corresponding to ad type t, and Drop_i represents the revenue change characteristic. When O_i is greater than 0, the ad platform is determined to have reached the preset over-bidding condition.
[0035] In the first implementation of the scheduling score, the scheduling score Score_i of the i-th advertising platform is calculated using the following formula: Score_i = Bid_i − P_i × D_i + L_i Wherein, Bid_i is the discounted revenue per thousand impressions returned by the advertising platform this time, D_i is the predicted value decay, P_i is the decay penalty weight, and L_i is the long-term revenue correction term. The long-term revenue correction term is determined based on at least one of the advertising platform's average actual revenue per thousand impressions, fill rate, click-through rate, and actual revenue within a preset time window.
[0036] In the second implementation of the scheduling score, the scheduling score Score_i of the i-th advertising platform is calculated using the following formula: Score_i = Bid_i × C_i + Explore_i Where C_i is the continuous winning bid cooling factor, and Explore_i is the exploration correction term. The continuous winning bid cooling factor C_i is calculated according to the following formula: C_i = max(C_min, 1 − k_t × O_i + r_t) Where C_min is the minimum cooling coefficient, ranging from 0.5 to 0.8; k_t is the weight reduction intensity corresponding to ad type t; r_t is the recovery term, determined based on the time interval between the current request time and the most recent display time of the ad platform. The longer the time interval, the larger the recovery term r_t, thus gradually increasing C_i back to 1. As can be seen from the above formula, C_i is less than or equal to 1, therefore this implementation performs a soft weight reduction rather than a hard blocking of the ad platform.
[0037] In one implementation, when the discounted revenue per thousand impressions (ROI) of the first advertising platform exceeds that of the second advertising platform by a preset price difference threshold, the soft downweighting of the first advertising platform is reduced or canceled, i.e., C_i is reset to 1, or the attenuation penalty term is set to zero. The second advertising platform is the advertising platform whose discounted RPI is second only to the first advertising platform in this ad display request. The preset price difference threshold can be an absolute difference or a relative proportion, such as 30%.
[0038] In one implementation, after displaying the target advertisement, the highest consecutive bid and actual number of impressions of the advertising platform corresponding to the target advertisement are incremented by one; the highest consecutive bid and actual number of impressions of the advertising platforms that were not identified as the target advertisement are reset to zero, or reduced by a preset attenuation coefficient, wherein the preset attenuation coefficient ranges from 0.3 to 0.7.
[0039] VI. Parameter configuration for advertising type tiers Different ad types have varying impacts on user exposure, revenue per ad, and display frequency. Therefore, baseline values and soft weighting parameters are set for the excessive bidding trigger threshold for each type. Splash screen ads have a strong exposure impact and are set to a strict control strategy; interstitial ads are set to a relatively strict control strategy; feed ads are set to a normal control strategy; rewarded video ads are triggered by users and have high revenue per ad, so a conservative control strategy is set; banner ads have high display frequency but low impact per ad, so a lenient control strategy is set. Specific parameters are shown in the table below.
[0040] Splash screen ads: Strict control strategy, trigger threshold is set at 3 times, if the drop exceeds 10%, it is reduced to 2 times, if the drop exceeds 20%, it remains at 2 times and the soft weighting intensity is increased.
[0041] Interstitial ads: The control strategy is relatively strict, with a trigger threshold of 4 times. If the decrease exceeds 10%, the threshold is lowered to 3 times, and if the decrease exceeds 20%, the threshold is lowered to 2 times.
[0042] In-feed ads: The control strategy is normal, with a trigger threshold of 5 times as the baseline value. If the decrease exceeds 10%, the threshold is reduced to 4 times, and if the decrease exceeds 20%, the threshold is reduced to 3 times.
[0043] Incentivized video ads: The control strategy is conservative, with a trigger threshold of 6 times as the baseline value. If the decrease exceeds 10%, the threshold is reduced to 5 times, and if the decrease exceeds 20%, the threshold is reduced to 4 times.
[0044] Banner Ads: The control strategy is lenient, with a trigger threshold of 8 times as the baseline value. If the decrease exceeds 10%, the threshold is reduced to 6 times, and if the decrease exceeds 20%, the threshold is reduced to 5 times.
[0045] In implementations that do not differentiate by ad type, the baseline value for the excessive bidding trigger threshold is uniformly set at 5 consecutive times; when the decrease exceeds 10%, it is reduced to 4 times; when it exceeds 20%, it is reduced to 3 times; and when the actual revenue per thousand impressions remains stable or increases, it is maintained at 5 times or increased to 6 times.
[0046] VII. Data Interaction Between Client and Server The mobile application client maintains historical display data indexed by advertising platform identifiers, ad slot identifiers, and user identifiers in its local storage, and performs user value consumption characteristic calculations, value decay predictions, over-winning index calculations, and scheduling score calculations locally. The mobile application client does not upload the original value of the user identifier to the server; it only uploads the over-winning index, scheduling parameters, and feedback statistics aggregated by advertising platform, ad type, and ad slot identifier. Therefore, the amount of uploaded data does not increase linearly with the number of ad requests, but is related to the product of the number of advertising platforms, ad types, and ad slots.
[0047] The server stores uploaded data for 10 days, aggregates it according to at least one of the following: advertising platform, advertising type, and advertising slot identifier, and sends scheduling parameters to the mobile application client once every 2 hours according to a preset delivery cycle. The scheduling parameters include a baseline value and reduction rules for the over-bidding trigger threshold, weights w1 to w4, a normalization upper limit, a decay penalty weight P, a reduction intensity k_t, a minimum cooling coefficient C_min, and a preset request threshold. Compared to the strategy of requesting the server one request at a time, batch delivery at a fixed cycle reduces the communication frequency between the client and the server.
[0048] When the mobile application client fails to receive the scheduling parameters, it continues to use the scheduling parameters of the previous version stored locally; when the scheduling parameters of the previous version do not exist locally, it uses the default scheduling parameters built in during compilation, thereby ensuring that the scheduling process can still be executed normally when there is a network anomaly. Beneficial effects
[0049] Compared with the prior art, the present invention has at least the following beneficial effects.
[0050] First, it reduces the number of invalid ad requests sent by the client. This invention identifies ad platforms whose return quality has entered a state of decline by using value decay prediction values and over-bid indexes, and lowers the priority of their requests or skips sending ad requests to them in subsequent ad display requests. Since these ad platforms are the main sources of empty ad returns, low-priced invalid candidates, and request timeouts, skipping requests to them directly reduces the total number of network requests initiated by the client within the statistics window and the number of timeouts.
[0051] Second, it reduced the average loading time and display failure rate of ad slots. The waiting time for a client in an ad display request depends on the slowest response among concurrent requests. After eliminating ad platforms with high timeout rates, the overall response time of concurrent requests converged, the average time from triggering to completing rendering of ad slots decreased, and the number of supplementary requests and retries triggered due to request timeouts decreased accordingly.
[0052] Third, it reduces network traffic and power consumption of mobile devices. The reduction in the number of invalid requests and retries directly reduces the uplink and downlink data transmission volume of mobile devices; at the same time, it reduces the number of times the radio frequency module switches from idle state to connected state and the dwell time, thereby reducing device power consumption.
[0053] Fourth, it reduces the amount of data uploaded by the client and the storage and computing load on the server. This invention performs the calculation of user value consumption characteristics, value decay prediction, and over-winning index locally on the client, and only uploads the aggregated index and parameters to the server, thus decoupling the amount of uploaded data from the number of ad requests; the server does not need to store and traverse each bidding detail, and its storage usage and the scale of data for aggregation calculation are reduced accordingly.
[0054] Fifth, by using soft demotion instead of hard blocking, the increased failure rate of fill caused by the shrinking of the candidate ad set is avoided. Ad platforms that are soft-demoted still retain the qualification to participate in subsequent bidding, and can immediately regain the winning bid when their price advantage exceeds the preset price difference threshold. Therefore, while reducing invalid requests, it will not cause a situation where there are no ads to display in the ad slots.
[0055] Sixth, the client only uses the de-identified advertising identifier or the locally generated client unique identifier for local statistics, and does not upload the original identifier value. While achieving the above scheduling function, the transmission range of identifier data is reduced.
[0056] Seventh, by configuring trigger thresholds and soft weighting parameters according to ad type, ad positions with different exposure impact intensities and display frequencies adopt request control intensities that match their request characteristics, further improving the balance between reducing the number of requests and maintaining the fill rate. Attached Figure Description
[0057] Figure 1 A flowchart of a multi-advertising platform ad request scheduling method based on value decay prediction provided in an embodiment of the present invention.
[0058] Figure 2 This is a schematic diagram illustrating the system architecture and data interaction between a mobile application client, multiple advertising platforms, and a server, as provided in an embodiment of the present invention.
[0059] Figure 3This diagram illustrates the feature inputs, over-bid index calculation, and scheduling score output of the value decay prediction model provided in this embodiment of the invention. Detailed Implementation
[0060] The embodiments of the present invention will now be described with reference to the accompanying drawings. These embodiments are for illustrative purposes only and are not intended to limit the scope of the invention. Example
[0061] A mobile application client connects to four advertising platforms: the first, second, third, and fourth advertising platforms. The types of ads include rewarded videos, splash screen ads, interstitial ads, feed ads, and banner ads.
[0062] See Figure 1 When a user triggers a certain information feed ad slot, the client's ad aggregation module executes the following process.
[0063] The client prioritizes reading the anonymized ad identifier as the user identifier. If the system is unauthorized and cannot obtain the ad identifier, the client generates a unique client identifier and writes it to local storage, which is then used as the user identifier. The client also obtains the ad placement identifier, ad type, and current request time.
[0064] The client sends ad requests concurrently to four ad platforms. Each ad platform returns candidate ads and their calculated revenue per thousand impressions (RPI). The first ad platform returns 3.2, the second returns 3.0, the third returns 2.8, and the fourth returns 2.7.
[0065] The client retrieves historical display data from local storage for four advertising platforms relative to the current user ID and current ad slot ID within a one-day historical window. The results show that the first advertising platform had a consecutive highest bid and 4 actual impressions, with its actual revenue per thousand impressions sequence being 4.0, 3.8, 3.5, and 3.2, respectively. The most recent impression was 300 seconds after the current request, and the number of impressions within the one-day window was 6. The other three advertising platforms all had a consecutive highest bid and 0 actual impressions.
[0066] The client calculates the user value consumption characteristics of the first advertising platform: N = 4; Drop = (4.0 − 3.2) / 4.0 = 0.2; Exposure density D_den = 6 times / day; Time interval Δt = 300 seconds. Based on the aforementioned normalization upper limit, n(N) = 0.4, n(Drop) = 0.4, n(D_den) = 0.3, n(Δt) ≈ 0.083.
[0067] The client calculates the predicted value decay using the aforementioned weighted linear model: D = 0.4 × 0.4 + 0.3 × 0.4 + 0.2 × 0.3 − 0.1 × 0.083 ≈ 0.33. This value indicates that if ads on the first advertising platform continue to be displayed, the actual revenue per thousand impressions is expected to decrease by approximately 30%.
[0068] The client calculates the over-bidding trigger threshold for the first advertising platform. The baseline trigger threshold for feed ads is 5 times. Since the actual revenue per thousand impressions for the first advertising platform has decreased by 20% relative to the initial window value of 4.0, exceeding the first ratio of 10%, the trigger threshold is lowered from 5 to 4 times. At this point, the first advertising platform's consecutive highest bids and actual impressions N = 4 have reached the lowered trigger threshold, indicating it has entered the over-bidding state. The over-bidding index is calculated using the aforementioned formula: O = max(0, 4 − 4) × W + 0.2 = 0.2.
[0069] The client calculates the scheduling score according to the second scheduling scoring implementation method described above. Taking C_min = 0.6, the weighting intensity of the feed ad k_t = 1.25, and the recovery term r_t = 0.05, the continuous winning cooling factor C of the first advertising platform is max(0.6, 1 − 1.25 × 0.2 + 0.05) = max(0.6, 0.80) = 0.80, and its scheduling score is 3.2 × 0.80 = 2.56. The second advertising platform is not in an over-winning state; its cooling factor is 1, and its scheduling score is 3.0. Since 3.0 is greater than 2.56, the client determines the candidate ad returned by the second advertising platform as the target ad and displays it.
[0070] After the display is completed, the client sets the highest consecutive bid and actual number of impressions on the second advertising platform to 1, and reduces the highest consecutive bid and actual number of impressions on the first, third and fourth advertising platforms by a preset decay coefficient of 0.5, with the first advertising platform decreasing from 4 to 2.
[0071] In the subsequent ad display requests, because the scheduling score of the first advertising platform was lower than the preset request threshold, the client skipped sending ad requests to the first advertising platform and only sent requests to the second, third, and fourth advertising platforms. As a result, the number of concurrent requests initiated by the client for that ad slot that day was reduced from four to three; at the same time, the waiting and retries caused by the first advertising platform returning empty ads in a decaying state and request timeouts were eliminated, and the average loading time of that ad slot decreased.
[0072] After several requests, the highest consecutive bid and actual number of impressions on the first advertising platform have decreased to 0, and the time interval Δt increases, causing the recovery term r_t to increase. The cooling factor C rises back to 1, and the first advertising platform resumes normal participation in requests and bidding. Example
[0073] Following Example 1, in the next ad display request, the first ad platform returns a discounted revenue per thousand impressions of 4.5, while the second ad platform returns 3.0. The relative difference between the two is 50%, exceeding the preset price difference threshold of 30%. At this point, the client reduces or cancels the soft downgrade of the first ad platform, resetting its cooling factor to 1, and its scheduling score to 4.5, which is higher than the second ad platform's 3.0. Therefore, the first ad platform's ad will still be displayed in this instance. Thus, this invention does not display ads in a fixed order or perform hard blocking of ad platforms, but rather dynamically balances the reduction in the number of requests with the advantage of a single-application price. Example
[0074] See Figure 2 After completing all feature and scoring calculations locally, the client aggregates the over-winning index, scheduling parameters, and feedback statistics by advertising platform, advertising type, and advertising slot identifier, and uploads them to the server. The uploaded content does not include the original value of the user identifier. The server stores the uploaded data for 10 days, aggregates it by advertising platform, advertising type, and advertising slot identifier, and updates the weights w1 to w4 using the aforementioned least squares fitting method. Scheduling parameters are sent to the client every 2 hours. If the client fails to receive scheduling parameters, it continues to use the previously saved scheduling parameters; if the previous version does not exist locally, the default scheduling parameters built in during compilation are used. Example
[0075] See Figure 3 For different ad types within the same mobile application, the client loads the corresponding trigger threshold baseline and soft weighting parameters according to the aforementioned parameter table categorized by ad type. For splash screen ads, the trigger threshold baseline is 3 times, which is reduced to 2 times when the actual revenue per thousand impressions decreases by more than 10%. Therefore, request control intervenes earlier for splash screen ads, enabling faster removal of decaying ad platforms and a more significant improvement in splash screen loading time. For banner ads, the trigger threshold baseline is 8 times, with later intervention, thus maintaining a larger candidate set and higher fill rate in high-frequency display scenarios. Example
[0076] In another implementation, the value decay prediction model employs the aforementioned gradient boosting decision tree model. The server trains the model offline daily using aggregated historical data, serializes the tree structure and leaf node weights, and sends them to the client along with scheduling parameters. The client performs forward inference on the feature vectors of the four advertising platforms locally to obtain the value decay prediction value for each advertising platform. The subsequent process is the same as in Embodiment 1.
[0077] The above-described embodiments can be implemented individually or in combination. Equivalent substitutions and conventional modifications made by those skilled in the art based on the technical solutions of this invention are all within the scope of protection of this invention.
[0078] The present invention also provides a multi-advertising platform advertising request scheduling system based on value decay prediction, including a request receiving module, a bidding request module, a historical data module, a feature calculation module, a decay prediction module, an over-winning bidding module, a scoring module, an advertising determination module, a request control module, and a parameter synchronization module. Each module is used to perform the processing corresponding to steps S1 to S10 above.
[0079] The present invention also provides an electronic device, including a processor and a memory, wherein the memory stores a computer program that, when executed by the processor, implements the above-described method. The present invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the above-described method.
Claims
1. A method for scheduling ad requests across multiple ad platforms based on value decay prediction, applied to a mobile application client accessing multiple ad platforms, characterized in that, include: Receive an ad display request and obtain the user identifier, ad slot identifier, ad type, and candidate ad platform set corresponding to the ad display request; The user identifier is an ad identifier that has been anonymized. When the anonymized ad identifier cannot be obtained, the user identifier is a unique client identifier generated and stored locally by the mobile application client. Send advertising requests to multiple advertising platforms in the candidate advertising platform set, and receive candidate advertisements and corresponding converted revenue per thousand impressions returned by each advertising platform; Read the historical display data of each advertising platform relative to the user identifier and the ad slot identifier within a preset historical window from the local storage of the mobile application client. The historical display data includes the consecutive highest bid and actual number of times it is displayed, the actual revenue per thousand displays within the preset historical window, the number of displays, and the time of the most recent display. The user value consumption characteristics of each advertising platform are calculated based on the historical display data. The user value consumption characteristics include continuous winning bid characteristics, exposure density characteristics, time interval characteristics, and revenue change characteristics. The user value consumption characteristics are input into the value decay prediction model to obtain the value decay prediction value for each advertising platform. The value decay prediction value is used to characterize the decrease in the actual revenue per thousand impressions of the user identifier and the ad slot identifier in the subsequent time window when the advertising platform continues to display the ads. An over-bid index is maintained for each advertising platform. The over-bid index is determined based on the platform's consecutive highest bid and actual number of impressions, and the corresponding over-bid trigger threshold. The over-bid trigger threshold is dynamically adjusted according to the decrease in the platform's actual revenue per thousand impressions relative to the preset historical window start value: when the decrease exceeds a first proportion, the over-bid trigger threshold is lowered by one level; when the decrease exceeds a second proportion, the over-bid trigger threshold is lowered by another level, where the second proportion is greater than the first proportion; when the actual revenue per thousand impressions does not decrease, the over-bid trigger threshold is maintained or increased. The scheduling score is calculated based on the converted revenue per thousand impressions, the predicted value decay, and the over-bid index of each advertising platform. The advertising platform whose over-bid index reaches the preset over-bid conditions is subject to soft demotion. The soft demotion is used to reduce the scheduling score of the advertising platform while retaining the advertising platform's eligibility to participate in subsequent bidding. The target advertisement is determined from the candidate advertisements returned by the multiple advertising platforms based on the scheduling score, and the target advertisement is displayed. In at least one subsequent ad display request, the request priority of the ad platform that has been subject to the soft downgrade is reduced, or ad requests are skipped to ad platforms that have been subject to the soft downgrade and whose scheduling score is lower than a preset request threshold, so as to reduce the number of ad requests sent by the mobile application client within the preset history window. The mobile application client calculates the over-bid index and scheduling parameters locally, uploads the over-bid index and scheduling parameters to the server, and receives the scheduling parameters issued by the server according to a preset issuance cycle.
2. The method according to claim 1, characterized in that, The preset historical window is 1 day; the baseline value for the excessive bidding trigger threshold is 5 consecutive highest bids that are actually displayed; the first ratio is 10%, and the second ratio is 20%; when the decrease exceeds 10%, the excessive bidding trigger threshold is lowered from 5 times to 4 times; when the decrease exceeds 20%, the excessive bidding trigger threshold is lowered to 3 times; when the actual revenue per thousand displays remains stable or increases, the excessive bidding trigger threshold is maintained at 5 times or increased to 6 times.
3. The method according to claim 1, characterized in that, The ad types include at least one of rewarded video ads, splash screen ads, interstitial ads, feed ads, and banner ads. Different ad types have corresponding baseline values and soft weighting parameters for setting excessive bidding trigger thresholds. Specifically, the baseline value for splash screen ads is 3 consecutive times, the baseline value for interstitial ads is 4 consecutive times, the baseline value for feed ads is 5 consecutive times, the baseline value for rewarded video ads is 6 consecutive times, and the baseline value for banner ads is 8 consecutive times.
4. The method according to claim 1, characterized in that, The step of inputting the user value consumption characteristics into the value decay prediction model to obtain the value decay prediction value corresponding to each advertising platform includes: The continuous highest bid and actual number of impressions, the decrease ratio of the actual revenue sequence per thousand impressions relative to the starting value of the preset historical window, the exposure density within the preset historical window, and the time interval between the current request time and the most recent impression time are normalized to obtain the normalized continuous winning bid features, revenue change features, exposure density features, and time interval features. The value decay prediction value is obtained by taking positive weights for the normalized continuous winning bid feature, the revenue change feature and the exposure density feature, and taking negative weights for the normalized time interval feature. The positive weights and negative weights are updated by the server based on the aggregated feedback data and sent to the mobile application client along with the scheduling parameters.
5. The method according to claim 1, characterized in that, The calculation of the scheduling score based on the discounted revenue per thousand impressions, the predicted value decay, and the over-winning index for each advertising platform includes any of the following methods: The decay penalty term is obtained by multiplying the predicted value of value decay by the decay penalty weight. The decay penalty term is then subtracted from the discounted revenue per thousand impressions, and a long-term revenue correction term is added to obtain the scheduling score; or... The continuous winning bid cooling factor is determined based on the over-winning bid index. The scheduling score is obtained by multiplying the converted revenue value per thousand impressions by the continuous winning bid cooling factor and adding an exploration correction term. The continuous winning bid cooling factor is less than or equal to 1.
6. The method according to claim 5, characterized in that, The continuous winning bid cooling factor is the larger of the lowest cooling coefficient and the first value; the first value is 1 minus the product of the excessive winning bid index and the ad type weight reduction intensity, plus the value obtained by adding the recovery item; the recovery item is determined according to the time interval between the current request time and the most recent display time, and the longer the time interval, the larger the recovery item.
7. The method according to claim 1, characterized in that, Also includes: After displaying the target advertisement, at least one of the following is collected: exposure feedback, click feedback, actual revenue, and changes in revenue per thousand impressions from each advertising platform in subsequent advertising requests. This data is then aggregated locally on the mobile application client by advertising platform, advertising type, and advertising slot identifier and uploaded to the server. The original value of the user identifier is not uploaded. The server stores the uploaded data for 10 days and sends the scheduling parameters to the mobile application client once every 2 hours according to the preset sending cycle. If the mobile application client fails to receive the scheduling parameters, it continues to use the scheduling parameters of the previous version; if the scheduling parameters of the previous version do not exist locally, the built-in default scheduling parameters are used.
8. A multi-advertising platform ad request scheduling system based on value decay prediction, characterized in that, include: The request receiving module is used to receive an ad display request and obtain the user identifier, ad slot identifier, ad type, and candidate ad platform set corresponding to the ad display request; The bidding request module is used to send advertising requests to multiple advertising platforms and receive candidate ads and corresponding converted revenue per thousand impressions returned by each advertising platform. The historical data module is used to read the historical display data of each advertising platform relative to the user identifier and the ad slot identifier within a preset historical window from local storage; The feature calculation module is used to calculate the user value consumption characteristics of each advertising platform based on the historical display data. The decay prediction module is used to input the user value consumption characteristics into the value decay prediction model to obtain the value decay prediction value corresponding to each advertising platform. The over-bid module is used to maintain an over-bid index for each advertising platform and dynamically adjust the over-bid trigger threshold for that advertising platform according to the decrease in the actual revenue per thousand impressions. The scoring module is used to calculate the scheduling score based on the converted revenue per thousand impressions, the predicted value decay, and the over-bid index, and to perform soft demotion on advertising platforms whose over-bid index reaches the preset over-bid conditions. The advertisement determination module is used to determine and display target advertisements based on the scheduling score; The request control module is used to reduce the request priority of the advertising platform that has been subject to the soft downgrade, or skip sending an advertising request to that advertising platform, in at least one subsequent advertising display request. The parameter synchronization module is used to calculate the over-bid index and scheduling parameters locally and upload them to the server, as well as to receive the scheduling parameters issued by the server according to a preset issuance cycle.
9. An electronic device comprising a processor and a memory, wherein the memory stores a computer program, characterized in that, When the computer program is executed by the processor, it implements the method of any one of claims 1 to 7.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.