A user data gain backhaul method, device, apparatus and storage medium

Abstract

The application discloses a user data gain backhaul method and device, equipment and storage medium, relates to the field of advertisement putting, and includes: configuring the CPA mode and the cap value of putting the advertisement, determining the standard CPA of the current putting batch; executing the current putting batch running task, obtaining user data and user exposure record, and screening out to-be-backhauled data according to a preset gain backhaul logic and the user exposure record; determining the historical backhaul number before the end of the current putting batch, and judging whether the to-be-backhauled data satisfies the backhaul condition according to the standard CPA and the historical backhaul number; if yes, determining the gain backhaul number according to the historical backhaul number and the cap value, and backhauling the gain backhaul data from the to-be-backhauled data according to the gain backhaul number. The user data gain backhaul to the media can be realized by designing the inheritance gain strategy, and the increase of the backhaul number under certain conditions helps the continuous optimization of the putting model to achieve the purpose of the continuous iteration of the putting model.

Description

Technical Field

[0001] This invention relates to the field of advertising delivery, and in particular to a method, apparatus, device, and storage medium for user data gain backhaul. Background Technology

[0002] Currently, a common backtracking strategy adopted by advertisers during the advertising campaign is to backtrack high-quality customers. By backtracking high-quality customer models, they can jointly model and continuously optimize the campaign model with the advertising platform. However, this backtracking strategy suffers from an overly narrow backtracking benchmark, which affects the account's CVR (Conversion Rate = Conversions / Clicks) and model cycle. Specifically, the backtracking test results for high-quality customers are negative, and the quality gradually declines.

[0003] However, during the campaign, some accounts, due to the alignment with the high-quality customer model, have too few users meeting the feedback criteria, hindering the analysis and optimization of the media-side campaign model. Currently, the main approach is to configure the ad feedback strategy when configuring the campaign link. When a user completes a task, the user is attributed, and the configured feedback strategy is used to determine if the user meets the feedback criteria. If they do, the user is fed back; otherwise, no feedback is performed. This results in the current user feedback model only being able to feed back users who meet the strategy's high-quality customer base. Without adjusting the feedback strategy, the user feedback model is too simplistic, and the feedback criteria are too narrow. This prevents users who are close to high-quality from being fed back, thus failing to overcome the limitations of the media's algorithm and the difficulty in incremental growth, limiting the media's ability to further optimize its campaign model. In other words, current media modeling primarily focuses on sending back data to users who have passed credit approval and are considered high-quality. This means that the prerequisite for sending back data is that the user has passed credit approval. The standard data sending strategy is then used to determine whether a user is high-quality, considering factors such as education level, annual income, credit limit, credit rating, and People's Bank of China credit score. Therefore, even if a customer has passed credit approval, they will not be sent back if they do not meet the standard data sending strategy. Thus, improving the user data sending strategy to ensure continuous optimization of the advertising model is a problem that needs to be solved in this field. Summary of the Invention

[0004] In view of this, the purpose of this invention is to provide a user data gain backhaul method, apparatus, device, and storage medium. This method allows for the backhaul of user data to the media through an inherited gain strategy. Increasing the number of backhauls under certain conditions helps in the continuous optimization of the delivery model, thereby achieving continuous iteration of the delivery model. The specific solution is as follows:

[0005] Firstly, this application provides a user data gain backhaul method, including:

[0006] Configure the CPA mode and corresponding cap value for the ad delivery according to preset rules, and determine the standard CPA for the current batch of ad delivery according to the CPA mode; the cap value is the upper limit multiple of the gain for user data feedback of the ad delivery.

[0007] The batch execution task of the current deployment batch is executed according to the preset execution time, the user data and corresponding user exposure records issued by the data warehouse are obtained, and the data to be transmitted back is filtered from the user data according to the preset gain back transmission logic and the user exposure records.

[0008] The number of historical backhauls of the advertised product before the end of the current batch is determined within a preset time range, and the data to be backhauled in the current batch is judged to meet the preset backhaul conditions based on the standard CPA and the number of historical backhauls; the number of historical backhauls is the sum of the number of historical regular backhauls and the number of historical gain backhauls of the advertised product within the preset time range;

[0009] If the data to be returned meets the preset return conditions, the number of gain return records for the current batch is determined based on the number of historical return records and the cap value, and gain return data is selected from the data to be returned based on the number of gain return records for return.

[0010] Optionally, determining the standard CPA for the current batch of advertising based on the CPA model includes:

[0011] Configure the critical CPA, default CPA, and standard CPA exception conditions according to the CPA mode, and determine the historical CPA;

[0012] If the historical CPA is greater than the critical CPA, or the historical CPA meets the abnormal condition, then the default CPA will be used as the standard CPA for the current batch.

[0013] If the historical CPA is not greater than the critical CPA, then the historical CPA is used as the standard CPA for the current batch.

[0014] Alternatively, a preset custom CPA can be obtained, and the custom CPA can be directly used as the standard CPA for the current batch.

[0015] Optionally, determining whether the data to be returned in the current batch meets the preset return conditions based on the standard CPA and the number of historical returned records includes:

[0016] Calculate the cumulative ad spend of the ads within the preset time range before the end of the current ad batch, and determine the expected conversion rate of the ads within the preset time range based on the cumulative ad spend, the standard CPA, and the preset gain multiple;

[0017] The expected gain number of return messages for the current batch is obtained by subtracting the expected conversion number from the historical return message number, and it is determined whether the expected gain number of return messages is greater than zero.

[0018] If the value is greater than zero, then the data to be transmitted back is determined to meet the preset transmission conditions.

[0019] If the value is not greater than zero, it is determined that the data to be returned does not meet the preset return conditions, and the return of the data to be returned in the current batch is prohibited.

[0020] Optionally, determining the gain return count for the current deployment batch based on the historical return count and the cap value includes:

[0021] The upper limit of the capped return data for the current batch is obtained by multiplying the historical regular return data count and the capped value.

[0022] The difference between the sum of the expected gain backhaul count and the historical gain backhaul count and the capping backhaul limit is calculated, and the gain backhaul count for the current deployment batch is determined based on the obtained target difference.

[0023] Optionally, the step of selecting gain return data from the data to be returned based on the number of gain return data entries includes:

[0024] Determine whether the target difference is greater than zero;

[0025] If the target difference is greater than zero, the difference between the cap return upper limit and the historical gain return number is taken as the gain return number, and the gain return data is selected from the data to be returned based on the gain return number for return.

[0026] If the target difference is not greater than zero, the expected gain back transmission count is directly used as the gain back transmission count, and the gain back transmission data is selected from the data to be back transmission based on the gain back transmission count.

[0027] Optionally, the step of filtering the data to be returned from the user data according to the preset gain return logic and the user exposure records includes:

[0028] Determine whether there are any return records in the user data within a preset query time range, and remove the target user data containing the return records based on the determination result;

[0029] Obtain the user exposure records corresponding to the remaining user data after removing the target user data within the preset query time range;

[0030] If the media delivery plan corresponding to the remaining user data meets the preset gain backhaul limit, the user exposure record corresponding to the remaining user data is saved to the pre-backhaul table, and the data to be backhauled is determined according to the pre-backhaul table.

[0031] Optionally, saving the user exposure records corresponding to the remaining user data to the pre-return table includes:

[0032] If the remaining user data corresponds to multiple user exposure records, then the multiple user exposure records are sorted according to their corresponding risk level and exposure time to obtain the record sorting result;

[0033] The target exposure record is obtained by identifying the user exposure record that meets the preset gain backhaul limit condition from the user exposure record, and the first target exposure record is saved to the pre-backhaul table according to the record sorting result;

[0034] If none of the user exposure records meet the preset gain backhaul limit, the first user exposure record in the record sorting result is saved to the pre-backhaul table.

[0035] Secondly, this application provides a user data gain backhaul device, comprising:

[0036] The parameter configuration module is used to configure the CPA mode and corresponding cap value of the advertisement according to preset rules, and to determine the standard CPA of the current batch of advertisements according to the CPA mode; the cap value is the upper limit multiple of the gain for the advertisement to transmit user data back.

[0037] The data filtering module is used to execute the batch task of the current deployment batch according to the preset execution time, obtain the user data and corresponding user exposure records issued by the data warehouse, and filter out the data to be transmitted back from the user data according to the preset gain feedback logic and the user exposure records.

[0038] The data judgment module is used to determine the number of historical backhauls of the advertised ads before the end of the current batch within a preset time range, and to determine whether the data to be backhauled in the current batch meets the preset backhaul conditions based on the standard CPA and the number of historical backhauls; the number of historical backhauls is the sum of the number of historical regular backhauls and the number of historical gain backhauls of the advertised ads within the preset time range;

[0039] The data determination module is used to determine the number of gain return records in the current batch based on the number of historical return records and the cap value if the data to be returned meets the preset return conditions, and to filter out the gain return data from the data to be returned based on the number of gain return records for return.

[0040] Thirdly, this application provides an electronic device, which includes a processor and a memory; wherein the memory is used to store a computer program, which is loaded and executed by the processor to implement the aforementioned user data gain backhaul method.

[0041] Fourthly, this application provides a computer-readable storage medium for storing a computer program that, when executed by a processor, implements the aforementioned user data gain backhaul method.

[0042] This application configures the CPA mode and corresponding cap value for ad placement according to preset rules, and determines the standard CPA for the current ad placement batch according to the CPA mode; executes the batch task of the current placement batch according to a preset execution time, obtains the user data and corresponding user exposure records issued by the data warehouse, and filters out the data to be returned from the user data according to the preset gain return logic and the user exposure records; determines the number of historical returns of the ad placement before the end of the current placement batch within a preset time range, and judges whether the data to be returned in the current placement batch meets the preset return conditions according to the standard CPA and the number of historical returns; if the data to be returned meets the preset return conditions, determines the number of gain returns for the current placement batch according to the number of historical returns and the cap value, and filters out the gain return data from the data to be returned for return according to the number of gain returns. In this way, by setting parameters such as CPA and cap value, the number of users to be returned in each batch of batch tasks can be calculated. By setting a gain return strategy, it can be determined whether to return non-high-quality users who have not been returned in this batch, thereby realizing gain return of media. This breaks through the current situation of algorithm limitations and incremental difficulties of media, increases the return of more high-quality users to promote model iteration, and solves the problem that some advertising accounts have a low number of returned samples when aligning with the high-quality customer model, which is not conducive to the iteration of media advertising model. Attached Figure Description

[0043] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0044] Figure 1 A flowchart of a user data gain backhaul method provided in this application;

[0045] Figure 2 A standard CPA determination flowchart is provided for this application;

[0046] Figure 3 A flowchart for determining the number of gain return transmissions is provided in this application;

[0047] Figure 4 A specific user data gain backhaul flowchart is provided for this application;

[0048] Figure 5 An example diagram of gain return data calculation provided in this application;

[0049] Figure 6 A flowchart of a method for determining data to be transmitted back, provided in this application;

[0050] Figure 7 This application provides a complete logic diagram of inherited gain backhaul.

[0051] Figure 8 A schematic diagram of a user data gain backhaul device provided in this application;

[0052] Figure 9 This application provides a structural diagram of an electronic device. Detailed Implementation

[0053] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0054] Currently, a common backfeed strategy adopted by advertisers during ad campaigns is to backfeed high-quality customers. This involves using a backfeed high-quality customer model to jointly model and continuously optimize the ad campaign model with the advertising platform. However, this strategy suffers from a narrow backfeeding scale, impacting account and model cycles. This application, by setting parameters such as CPA and capping value, can calculate the number of users to be backfeeded in each batch of batch tasks. By setting a gain backfeed strategy, it determines whether to backfeed non-high-quality users not yet backfeeded in the current batch, achieving gain backfeeding for the media. This overcomes the limitations of media algorithms and the difficulty in incremental growth, increasing the backfeeding of more high-quality users, promoting model cycles, and facilitating continuous optimization and iteration of the ad campaign model.

[0055] See Figure 1 As shown, this embodiment of the invention discloses a user data gain backhaul method, including:

[0056] Step S11: Configure the CPA mode and corresponding cap value of the ad according to the preset rules, and determine the standard CPA of the current batch of the ad according to the CPA mode; the cap value is the upper limit multiple of the gain for the ad to transmit user data back.

[0057] In this embodiment, the first step is to configure the CPA mode and corresponding cap value for the currently displayed advertisement, and then... Figure 2 The process shown configures the standard CPA for the current batch of ad delivery. It's understood that CPA, or Cost Per Action, is a pricing model defined in the online advertising industry. It charges based on each action taken by a visitor in response to an online ad. CPA = Ad spend C / Conversions V = Cost per conversion (per unit). The cap is a manually set upper limit on the gain from user data feedback during ad delivery, used to control the cap feedback limit for subsequent batches of ad delivery.

[0058] It should be noted that in this embodiment, when determining the standard CPA for the current batch of ads based on the CPA model, the aforementioned standard CPA is not a constant value and can fluctuate according to actual conditions. In a specific embodiment, a floating CPA method can be selected. First, abnormal conditions for the critical CPA, default CPA, and standard CPA are configured according to the CPA model, and the historical CPA (i.e., T-1 CPA, yesterday's average conversion cost per user) is determined. If the historical CPA is greater than the critical CPA, or the historical CPA meets the abnormal conditions, then the default CPA is used as the standard CPA for the current batch. By setting a critical CPA (critical average conversion cost per user) and a default CPA (default average conversion cost per user), if T-1 CPA > critical CPA or an abnormal value, i.e., yesterday's average conversion cost per user is very high, such as the normal average conversion cost per user... The cost per person is 1000 yuan. The critical CPA is set to 1000 yuan per person. However, yesterday the account spent 10000 yuan and converted 2 or 0 people, resulting in CPAs of 5000 yuan per person and outliers respectively. In this case, T-1 CPA is calculated using the default CPA. If the historical CPA is not greater than the critical CPA, then the historical CPA is used as the standard CPA for the current batch. When the CPA mode is configured with a floating CPA, if T-1 CPA <= critical CPA, then the standard CPA = T-1 CPA, meaning the standard CPA = yesterday's average conversion cost per person. This indicates that yesterday's average conversion cost per person is within a reasonable range. Figure 2 As shown, if T-1CPA is greater than the critical CPA or an outlier (e.g., converted to 0 yesterday), the standard CPA = the default CPA; if T-1CPA is less than or equal to the critical CPA, the standard CPA = T-1CPA. By setting the default CPA, critical CPA, and custom CPA, exception handling when T-1CPA is not within a reasonable range can be resolved.

[0059] In another specific embodiment, a preset custom CPA can be obtained and directly used as the standard CPA for the current campaign batch, i.e., standard CPA = custom CPA. It can be understood that the standard CPA configuration value can be the industry standard CPA value or the average CPA over a certain period. Since the daily cumulative return S = daily cumulative cost C (i.e., cumulative ad spend) / standard CPA, the standard CPA affects the calculation of subsequent return volumes. Therefore, when a new account has not been campaigned and the CPA value is 0 or unsatisfactory (due to excessively high or low average conversion cost per user leading to excessively high or low S), the campaign administrator can set a more ideal CPA (average conversion cost per user) as the parameter for calculating the return volume S. It should be noted that only one of the above-mentioned custom CPA and floating CPA can be selected for configuration.

[0060] Step S12: Execute the batch task of the current deployment batch according to the preset execution time, obtain the user data and corresponding user exposure records issued by the data warehouse, and filter out the data to be transmitted back from the user data according to the preset gain back transmission logic and the user exposure records.

[0061] In this embodiment, the batch execution task for the current campaign can be executed according to a preset execution time. This process acquires user data and corresponding user exposure records from the data warehouse. Based on a preset gain feedback logic and user exposure records, data to be fed back is filtered from the user data. This allows for subsequent determination of whether the data needs to be fed back, thus enabling the feedback of some users who do not meet the feedback criteria (these users were pushed ads by the media, indicating they are potential conversion customers). This increases the feedback sample size, facilitating media optimization of the campaign model. For example, the preset execution time in this embodiment can be 30 minutes, with each batch execution ending after 30 minutes. It is understood that in normal feedback, users who do not meet the feedback criteria are not fed back; there is a feedback threshold, meaning only high-quality customers who meet the feedback criteria are fed back. This embodiment uses a half-hour batch execution cycle to determine whether other non-high-quality users can be fed back, thus achieving gain feedback logic and breaking through the threshold for high-quality customer feedback.

[0062] Step S13: Determine the number of historical backhauls of the advertisement before the end of the current batch within the preset time range, and determine whether the data to be backhauled in the current batch meets the preset backhaul conditions based on the standard CPA and the number of historical backhauls; the number of historical backhauls is the sum of the number of historical regular backhauls and the number of historical gain backhauls of the advertisement within the preset time range.

[0063] In this embodiment, the number of historical data transfers for the ads delivered before the end of the current delivery batch within a preset time range is first determined. Then, based on the standard CPA and the number of historical data transfers, it is determined whether the data to be transferred for the current delivery batch meets the preset transfer conditions. The aforementioned number of historical data transfers is the sum of the historical regular data transfers and the historical gain data transfers for the ads delivered within the preset time range. For example... Figure 3As shown, the preset time range can be set to 24 hours per day. When determining whether the data to be returned for the current batch meets the preset return conditions based on the standard CPA and the number of historical return records, the system first calculates the cumulative ad spend of the ads placed before the end of the current batch within the preset time range. Based on the cumulative ad spend, standard CPA, and preset gain multiple, the expected conversion rate of the ads placed within the preset time range is determined. Then, the difference between the expected conversion rate and the number of historical return records is calculated to obtain the expected gain return record number for the current batch. The system then determines whether the expected gain return record number is greater than zero. If it is greater than zero, the data to be returned is determined to meet the preset return conditions. If it is not greater than zero, the data to be returned is determined not to meet the preset return conditions, and the return of the data to be returned for the current batch is prohibited.

[0064] like Figure 3 As shown, when running a batch every 30 minutes, the expected number of data returned that day and the expected number of data returned for this batch can be calculated based on the standard CPA, the cumulative daily consumption C, the cumulative daily conversion V1, and the gain factor Y1. First, calculate the cumulative cost C and cumulative conversion V of the advertising campaign from today to the current batch. Then, according to the above steps, the standard cumulative return count S for the day can be obtained as: Daily cumulative cost C / Standard CPA. The result is rounded down. Then, using the preset gain multiplier Y1, the expected conversion count E for the day can be obtained as: Daily standard cumulative return count S * (1 + Gain multiplier Y1) = (Daily total cost C / Standard CPA) * (1 + Gain multiplier Y1). Next, the expected gain return count for the current batch can be obtained: Expected return count Z0 for this batch = E - V1 = E - Daily cumulative return count (Cumulative regular T1 + Cumulative gain Z1). The above-mentioned daily cumulative return count, i.e., the historical return count, is the sum of the historical regular return count (Cumulative regular T1) and the historical gain return count (Cumulative gain return count Z1) from the day the advertisement was placed up to this batch. It can be understood that in this embodiment, the expected return count E refers to the number of returns expected on that day, including both regular return count and gain return count.

[0065] Step S14: If the data to be returned meets the preset return conditions, then determine the number of gain return records for the current batch based on the number of historical return records and the cap value, and select gain return data from the data to be returned based on the number of gain return records for return.

[0066] In this embodiment, if the data to be returned meets the preset return conditions, that is, the expected number of gain return records is greater than zero, the number of gain return records in the current batch is determined based on the historical number of return records and the cap value, and the gain return data is selected from the data to be returned based on the number of gain return records for return.

[0067] First, the capped return count for the current batch is obtained by multiplying the historical regular return count and the cap value. Then, the difference between the expected gain return count, the sum of the historical gain return count, and the capped return count is calculated, and the gain return count for the current batch is determined based on the target difference. The capped return count G0 = cap value G * cumulative regular T1. Next, the expected return count Z0 + the gained return count Z1 for this batch is compared with the capped return count G0 to determine the actual number of returns to be made in this batch. First, it is determined whether the target difference is greater than zero. If the target difference is greater than zero, the difference between the capped return count and the historical gain return count is used as the gain return count, and gain return data is selected from the data to be returned based on this count. If the target difference is not greater than zero, the expected gain return count is directly used as the gain return count, and gain return data is selected from the data to be returned based on this count. Figure 3 As shown, when Z0 = 0, it means that the expected number of backhauls in this batch is 0, so no backhauls will be performed in this batch; when Z0 ≠ 0, if Z0 + Z1 - G0 > 0, it means that the sum of the expected number of backhauls and the historical gain number is greater than the cap number, so the gain backhaul count of the current batch, i.e., the actual number of backhauls in this batch, X = G0 - the gain backhaul count Z1; if Z0 + Z1 - G0 >= 0, it means that the sum of the expected number of backhauls and the historical gain number is less than or equal to the cap number, so the actual number of backhauls in this batch, X = Z0. It is understandable that the above-mentioned capped return limit refers to the maximum number of users that this account can return, which is a dynamically calculated value. For example, if the number of regular returns in the previous batch was 10 and the capping multiplier was 2, then the capped return limit for this batch = 10 * 2 = 20. If 2 more users are regularly returned in this batch within half an hour, then the capped return limit for this batch = (10 + 2) * 2 = 24. This can limit the total number of gain returns, that is, the ratio of regular returns to gain returns is controllable. This increases the number of users returning to the media (regular returns + gain returns). At the same time, because when the gain returns are too large, the media side will consider the gain return model to be the best delivery model, causing its delivery model to gradually bias towards gain returns during iteration, thus leading to delivery model pollution. Therefore, this embodiment also avoids the distortion of the return model due to excessive gain returns.

[0068] It should be noted that the expected return Z0 for this batch is calculated as follows: expected E - (cumulative regular return T1 + cumulative gain return Z1) = C / CPA*(1+Y1)-(T1+Z1); cap limit G0 = cap value G*cumulative regular return T1; since the total consumption C, CPA (total consumption of the previous round / total conversion of the previous round V), T1, Z1 and other parameters change in each round, according to the formula, the larger the regular return amount, the smaller the expected gain return amount, and vice versa. Therefore, the calculation is dynamically adjusted in each round of gain return to limit the disordered return of gain.

[0069] like Figure 4 As shown, first, configure the CPA mode and capping factor, calculate the standard CPA, and every 30 minutes when running batch tasks, calculate the maximum number of backhauls for the day using the standard CPA, and check whether the number of backhauls already completed for the day has reached the maximum number of backhauls. If the maximum value has not been reached, determine the number of gain backhauls to perform. For example... Figure 5 As shown, the current batch's S = C / standard CPA = 10000 / 2000 = 5, the expected value E (gain multiplier 2) = 5 * (1 + 2) = 15, Z0 = expected E - historical feedback V (cumulative regular T1 + cumulative gain Z1) = 15 - (2 + 0) = 13, the cap limit GO (G = 2.5) = 2.5 * 2 = 5, therefore Z (Z0 + Z1) = 13 is greater than GO, so the gain can be obtained as: X = G0 - Z1 = 5 - 0 = 5.

[0070] In this embodiment, the CPA mode and corresponding cap value of the advertising are configured according to preset rules, and the standard CPA of the current batch of advertising is determined according to the CPA mode; the batch running task of the current batch is executed according to a preset execution time, the user data and corresponding user exposure records issued by the data warehouse are obtained, and the data to be returned is filtered from the user data according to the preset gain return logic and the user exposure records; the number of historical return records of the advertising before the end of the current batch within a preset time range is determined, and the data to be returned in the current batch is judged according to the standard CPA and the number of historical return records to determine whether the data to be returned in the current batch meets the preset return conditions; if the data to be returned meets the preset return conditions, the number of gain return records of the current batch is determined according to the number of historical return records and the cap value, and the gain return data is filtered from the data to be returned for return according to the number of gain return records. In this way, by setting parameters such as CPA and capping value, gain backfeed can be dynamically adjusted, limiting disordered gain backfeed. In each batch of batch tasks, the number of users to be backfeeded in this batch is calculated, and a gain backfeed strategy is set to determine whether to backfeed non-high-quality users who have not been backfeeded in this batch. This achieves gain backfeed to the media, thereby overcoming the current situation of algorithm limitations and incremental difficulties in the media, increasing the number of high-quality users backfeeding and promoting model iteration. Furthermore, since the model iteration in advertising is based on the tags, behaviors, profiles, and other information of backfeeding users, the media will continuously model based on the user information backfeeding the advertiser during continuous advertising. If the backfeeding user sample is too small or the tags are too simple, the iteration frequency or model iteration difference will decrease, thus affecting the continuous iteration of the advertising model. Therefore, this embodiment can perform gain backfeed to the media through the above gain backfeed scheme, especially when the sample of high-quality customers is low, to expand the backfeeding sample and achieve the purpose of continuous iteration of the advertising model.

[0071] As can be seen from the previous embodiment, this application can calculate the number of users that need to be back-transmitted in this batch and determine whether to back-transmit non-premium users who have not yet been back-transmitted in this batch by setting a gain back-transmission strategy, thereby achieving gain back-transmission of the media. Next, this embodiment will describe in detail the process of determining the data to be back-transmitted before data back-transmission. See [link to documentation]. Figure 6 As shown in the figure, an embodiment of the present invention discloses a method for determining data to be transmitted back, including:

[0072] Step S21: Execute the batch task of the current deployment batch according to the preset execution time, obtain the user data and corresponding user exposure records issued by the data warehouse, and determine whether there are any feedback records in the user data within the preset query time range, and remove the target user data with feedback records according to the determination result.

[0073] In this embodiment, a batch processing task for the current deployment batch can be executed according to a preset execution time to obtain user data and corresponding user exposure records issued by the data warehouse. It can also determine whether there are any feedback records within a preset query time range for the user data, and remove target user data with feedback records based on the determination result. For example... Figure 7 As shown, the data warehouse identifies a subset of "high-quality customers" based on the risk assessment criteria each day and distributes them with T-1 exposure records. Every 30 minutes during batch processing, users with existing feedback records (regular & gain) are removed. The preset query time range can be 30 days, which is considered a point in time where industry consensus indicates a correlation between user conversion and ad viewing; alternatively, it can be 14 days.

[0074] Step S22: Obtain the user exposure records corresponding to the remaining user data after removing the target user data within the preset query time range.

[0075] In this embodiment, the remaining user data after removing the target user data is obtained, and the corresponding user exposure records are obtained within a preset query time range. For each user, the earliest exposure record within 30 days is retrieved, and the corresponding MCode (the media's campaign code) is recorded. These users are "complete users," meaning all users who were rejected or approved. The MCode is the unique identifier of the media test campaign link, and it corresponds one-to-one with the media's campaign plan. Since there are multiple campaign plans under a media test campaign account, the data returned above describes the number of returned campaigns from each campaign account.

[0076] Step S23: If the media delivery plan corresponding to the remaining user data meets the preset gain backhaul limit condition, then the user exposure record corresponding to the remaining user data is saved to the pre-backhaul table, and the data to be backhauled is determined according to the pre-backhaul table.

[0077] In this embodiment, if the media delivery plan corresponding to the remaining user data meets the preset gain feedback limit, the user exposure record corresponding to the remaining user data is saved to the pre-feedback table, and the data to be fed back is determined according to the pre-feedback table. Furthermore, when saving the user exposure record corresponding to the remaining user data to the pre-feedback table, if the remaining user data corresponds to multiple user exposure records, the multiple user exposure records are sorted according to their corresponding risk level and exposure time to obtain a record sorting result; and the user exposure record that meets the preset gain feedback limit is determined from the user exposure records to obtain the target exposure record, and the first target exposure record is saved to the pre-feedback table according to the record sorting result; if multiple user exposure records do not meet the preset gain feedback limit, the first user exposure record in the record sorting result is saved to the pre-feedback table.

[0078] Every 30 minutes, during batch processing, users with existing feedback records (regular & gain) are removed, and the remaining users are sorted. The sorting method for each user is based on their earliest exposure record within the last 30 days, along with the corresponding mcode (media placement plan). For each mcode, all users are ranked according to the risk level tag used and the selected exposure record events. Then, based on the order of users within each mcode, it is determined whether they conform to the regular feedback strategy for that mcode (i.e., users who do not conform to the regular feedback strategy for the attribution mcode may conform to the strategy for the exposure mcode). Figure 7 As shown, if the conditions are met, the inherited gain backhaul pre-screening is successful and the data is added to the inherited gain backhaul pre-screening table; if not, the second exposure record for that user is retrieved until the last record; if the user does not meet the standard backhaul strategy for all exposure records' mcodes, the first record is forcibly added to the inherited gain backhaul pre-screening table. Every 30 minutes, the selected data is filtered and added to the "inherited gain backhaul pre-screening table." Then, all users associated with mcodes under each ad account are sorted by risk level + time for backhaul filtering, until all users for each account have been filtered. In this way, by sorting a portion of the "high-quality customer group" identified by the data warehouse according to risk control rules by each mcode (or campaign), a batch run is performed every 30 minutes to determine whether a user should undergo gain backhaul, and the user with the most recent ad reach is selected for backhaul based on the user's ad reach time. In this embodiment, since the gain backhaul configuration is based on the advertising account dimension, gain backhaul configuration can be performed on some accounts while other accounts are not configured. After the media advertising model has been running for a period of time, user conversion can be compared, and the advertising account can be specified to perform gain backhaul. The performance of the advertising model can be compared in the ABTEST method.

[0079] For example, the following exposure records exist: Example 1: User A (When User A has only one exposure record, it is directly assigned to the mcode of this exposure record)

[0080] Exposure record 1: 2023-09-07 18:00:00mcode=ym_zjtd_jrtt_a_1 Risk level 1;

[0081] Exposure Record 2: 2023-09-07 17:00:00mcode=ym_zjtd_jrtt_a_2 Risk Level 1;

[0082] Exposure record 3: 2023-09-06 18:00:00mcode=ym_tengxun_gdt_a_1 Risk level 1;

[0083] User A is then associated with their assigned mcode, and sorted as follows:

[0084] Example 2: mcode=ym_tengxun_gdt_a_1

[0085] User A: 2023-09-04 18:00:00mcode=ym_tengxun_gdt_a_1 Risk Level 1;

[0086] 2023-09-07 17:00:00mcode=ym_zjtd_jrtt_a_2 Risk Level 1;

[0087] 2023-09-07 18:00:00mcode=ym_tengxun_gdt_a_1 Risk Level 1;

[0088] User B: 2023-09-05 16:00:00mcode=ym_tengxun_gdt_a_1 Risk Level 2;

[0089] User C: 2023-09-06 16:00:00mcode=ym_tengxun_gdt_a_1 Risk Level 1;

[0090] Then mcode = ym_tengxun_gdt_a_1 is finally sorted as follows (in descending order of time according to risk level 1-5, with risk level weight > exposure time).

[0091] Final sort:

[0092] 1: User A, 2023-09-04 18:00:00, mcode=ym_tengxun_gdt_a_1, risk level 1;

[0093] 2: User C 2023-09-06 16:00:00mcode=ym_tengxun_gdt_a_1 Risk Level 1;

[0094] 3: User B 2023-09-05 16:00:00mcode=ym_tengxun_gdt_a_1 Risk level 2.

[0095] Furthermore, if user A's record 2023-09-04 18:00:00mcode=ym_tengxun_gdt_a_1 with risk level 1 does not meet the requirements, then the second record 2023-09-07 17:00:00mcode=ym_zjtd_jrtt_a_2 with risk level 1 will be used, and so on, until the last exposure record.

[0096] In this embodiment, the batch execution task for the current deployment batch is executed according to a preset execution time. User data and corresponding user exposure records from the data warehouse are obtained, and it is determined whether the user data has any feedback records within a preset query time range. Based on the determination result, target user data with feedback records is removed. The remaining user data after removing the target user data is then obtained, along with the corresponding user exposure records within the preset query time range. If the media deployment plan corresponding to the remaining user data meets the preset gain feedback constraint, the user exposure records corresponding to the remaining user data are saved to a pre-feedback table, and the data to be fed back is determined based on the pre-feedback table. By configuring gain feedback at the account level, some accounts can be configured for gain feedback while others are not. This allows for a comparison of user conversion after a media deployment model has been deployed for one cycle, achieving an ABTEST-style comparison of the performance of different deployment models.

[0097] See Figure 8 As shown in the illustration, this application also discloses a user data gain backhaul device, comprising:

[0098] The parameter configuration module 11 is used to configure the CPA mode and corresponding cap value of the advertisement according to preset rules, and to determine the standard CPA of the current batch of the advertisement according to the CPA mode; the cap value is the upper limit multiple of the gain for the advertisement to transmit user data back.

[0099] The data filtering module 12 is used to execute the batch task of the current deployment batch according to the preset execution time, obtain the user data and corresponding user exposure records issued by the data warehouse, and filter out the data to be transmitted back from the user data according to the preset gain feedback logic and the user exposure records.

[0100] The data judgment module 13 is used to determine the number of historical backhauls of the advertisement before the end of the current delivery batch within a preset time range, and to determine whether the data to be backhauled in the current delivery batch meets the preset backhaul conditions based on the standard CPA and the number of historical backhauls; the number of historical backhauls is the sum of the number of historical regular backhauls and the number of historical gain backhauls of the advertisement within the preset time range;

[0101] The data determination module 14 is used to determine the number of gain return records in the current batch based on the number of historical return records and the cap value if the data to be returned meets the preset return conditions, and to select gain return data from the data to be returned based on the number of gain return records for return.

[0102] In this embodiment, the CPA mode and corresponding cap value of the advertising are configured according to preset rules, and the standard CPA of the current batch of advertising is determined according to the CPA mode; the batch running task of the current batch is executed according to a preset execution time, the user data and corresponding user exposure records issued by the data warehouse are obtained, and the data to be returned is filtered from the user data according to the preset gain return logic and the user exposure records; the number of historical return records of the advertising before the end of the current batch within a preset time range is determined, and the data to be returned in the current batch is judged according to the standard CPA and the number of historical return records to determine whether the data to be returned in the current batch meets the preset return conditions; if the data to be returned meets the preset return conditions, the number of gain return records of the current batch is determined according to the number of historical return records and the cap value, and the gain return data is filtered from the data to be returned for return according to the number of gain return records. By setting parameters such as CPA and cap value, the number of users to be backed up in each batch of batch tasks can be calculated. By setting a gain backed up strategy, it can be determined whether to back up non-high-quality users who have not been backed up in this batch. This enables gain backed up of media, thereby breaking through the current situation of algorithm limitations and incremental difficulties of media, increasing the backed up of more high-quality users, promoting model cycle, and helping to continuously optimize the delivery model to achieve the goal of continuous iteration of the delivery model.

[0103] In some specific embodiments, the parameter configuration module 11 specifically includes:

[0104] The parameter configuration unit is used to configure the abnormal conditions of critical CPA, default CPA and standard CPA according to the CPA mode, and to determine historical CPA.

[0105] The first standard CPA configuration unit is used to set the default CPA as the standard CPA for the current batch if the historical CPA is greater than the critical CPA or the historical CPA meets the abnormal condition.

[0106] The second standard CPA configuration unit is used to use the historical CPA as the standard CPA for the current batch if the historical CPA is not greater than the critical CPA.

[0107] The third standard CPA configuration unit is used to obtain a preset custom CPA and directly use the custom CPA as the standard CPA for the current batch.

[0108] In some specific embodiments, the data judgment module 13 specifically includes:

[0109] The expected conversion number determination unit is used to calculate the cumulative ad spending of the ad campaign within the preset time range before the end of the current campaign batch, and to determine the expected conversion number of the ad campaign within the preset time range based on the cumulative ad spending, the standard CPA and the preset gain multiple.

[0110] The expected gain backhaul number determination unit is used to calculate the expected gain backhaul number of the current batch by subtracting the expected conversion number from the historical backhaul number, and to determine whether the expected gain backhaul number is greater than zero.

[0111] The first return condition judgment unit is used to determine that the data to be returned satisfies the preset return condition if the value is greater than zero.

[0112] The second return condition judgment unit is used to determine that the data to be returned does not meet the preset return condition if it is not greater than zero, and to prohibit the return of the data to be returned in the current batch.

[0113] In some specific embodiments, the data determination module 14 specifically includes:

[0114] The upper limit of the return transmission is determined by multiplying the number of historical regular return transmissions and the capping value to obtain the upper limit of the capping return transmission for the current batch.

[0115] The gain backhaul number determination unit is used to calculate the difference between the sum of the expected gain backhaul number and the historical gain backhaul number and the cap backhaul upper limit, and determine the gain backhaul number of the current deployment batch based on the obtained target difference.

[0116] In some specific embodiments, the data determination module 14 specifically includes:

[0117] A difference determination unit is used to determine whether the target difference is greater than zero;

[0118] The first data filtering unit is used to, if the target difference is greater than zero, take the difference between the cap return upper limit and the historical gain return number as the gain return number, and filter the gain return data from the data to be returned according to the gain return number for return.

[0119] The second data filtering unit is used to directly use the expected gain back transmission number as the gain back transmission number if the target difference is not greater than zero, and to filter the gain back transmission data from the data to be back transmission according to the gain back transmission number for back transmission.

[0120] In some specific embodiments, the data filtering module 12 specifically includes:

[0121] The data removal unit is used to determine whether there are any return records in the user data within a preset query time range, and remove the target user data containing the return records based on the determination result.

[0122] The record acquisition unit is used to acquire the user exposure records corresponding to the remaining user data after removing the target user data within the preset query time range.

[0123] The record saving submodule is used to save the user exposure record corresponding to the remaining user data to the pre-backhaul table if the media delivery plan corresponding to the remaining user data meets the preset gain backhaul limit condition, and to determine the data to be backhauled according to the pre-backhaul table.

[0124] In some specific embodiments, the record storage submodule specifically includes:

[0125] The record sorting unit is used to sort the multiple user exposure records according to their corresponding risk levels and exposure times to obtain a record sorting result if the remaining user data corresponds to multiple user exposure records.

[0126] The first record storage unit is used to determine the user exposure record that meets the preset gain backhaul limit condition from the user exposure record to obtain the target exposure record, and save the first target exposure record to the pre-backhaul table according to the record sorting result;

[0127] The second record storage unit is used to save the first user exposure record in the record sorting result to the pre-backhaul table if none of the multiple user exposure records meet the preset gain backhaul limit condition.

[0128] Furthermore, embodiments of this application also disclose an electronic device, Figure 9 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application.

[0129] Figure 9 This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this application. Specifically, the electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 stores a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the user data gain backhaul method disclosed in any of the foregoing embodiments. Alternatively, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0130] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 25 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0131] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 221, computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0132] The operating system 221 is used to manage and control the various hardware devices on the electronic device 20 and the computer program 222, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of performing the user data gain backhaul method executed by the electronic device 20 as disclosed in any of the foregoing embodiments, the computer program 222 may further include a computer program capable of performing other specific tasks.

[0133] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned user data gain backhaul method. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0134] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0135] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0136] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0137] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0138] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A user data gain backhaul method, characterized in that, include: Configure the CPA mode and corresponding cap value for the ad delivery according to preset rules, and determine the standard CPA for the current batch of ad delivery according to the CPA mode; The cap value is the upper limit multiple of the gain for user data feedback during the ad delivery; The batch execution task of the current deployment batch is executed according to the preset execution time, the user data and corresponding user exposure records issued by the data warehouse are obtained, and the data to be transmitted back is filtered from the user data according to the preset gain back transmission logic and the user exposure records. The number of historical backhauls of the advertised product before the end of the current batch is determined within a preset time range, and the data to be backhauled in the current batch is judged to meet the preset backhaul conditions based on the standard CPA and the number of historical backhauls; the number of historical backhauls is the sum of the number of historical regular backhauls and the number of historical gain backhauls of the advertised product within the preset time range; If the data to be returned meets the preset return conditions, then the number of gain return records for the current batch is determined based on the number of historical return records and the cap value, and gain return data is selected from the data to be returned based on the number of gain return records for return. The standard CPA for determining the current batch of advertising based on the CPA model includes: Configure the critical CPA, default CPA, and standard CPA exception conditions according to the CPA mode, and determine the historical CPA; If the historical CPA is greater than the critical CPA, or the historical CPA meets the abnormal condition, then the default CPA will be used as the standard CPA for the current batch. If the historical CPA is not greater than the critical CPA, then the historical CPA is used as the standard CPA for the current batch. Alternatively, obtain a preset custom CPA and directly use the custom CPA as the standard CPA for the current batch of deployments; Furthermore, the step of determining whether the data to be returned in the current batch meets the preset return conditions based on the standard CPA and the number of historical return records includes: Calculate the cumulative ad spend of the ads within the preset time range before the end of the current ad batch, and determine the expected conversion rate of the ads within the preset time range based on the cumulative ad spend, the standard CPA, and the preset gain multiple; The expected gain number of return messages for the current batch is obtained by subtracting the expected conversion number from the historical return message number, and it is determined whether the expected gain number of return messages is greater than zero. If the value is greater than zero, then the data to be transmitted back is determined to meet the preset transmission conditions. If the value is not greater than zero, it is determined that the data to be returned does not meet the preset return conditions, and the return of the data to be returned in the current batch is prohibited. The step of filtering the data to be returned from the user data according to the preset gain return logic and the user exposure records includes: Determine whether there are any return records in the user data within a preset query time range, and remove the target user data containing the return records based on the determination result; Obtain the user exposure records corresponding to the remaining user data after removing the target user data within the preset query time range; If the media delivery plan corresponding to the remaining user data meets the preset gain backhaul limit, the user exposure record corresponding to the remaining user data is saved to the pre-backhaul table, and the data to be backhauled is determined according to the pre-backhaul table.

2. The user data gain backhaul method according to claim 1, characterized in that, The step of determining the gain return count of the current deployment batch based on the historical return count and the cap value includes: The upper limit of the capped return data for the current batch is obtained by multiplying the historical regular return data count and the capped value. The difference between the sum of the expected gain backhaul count and the historical gain backhaul count and the capping backhaul limit is calculated, and the gain backhaul count for the current deployment batch is determined based on the obtained target difference.

3. The user data gain backhaul method according to claim 2, characterized in that, The step of selecting gain-return data from the data to be returned based on the number of gain-return data entries includes: Determine whether the target difference is greater than zero; If the target difference is greater than zero, the difference between the cap return upper limit and the historical gain return number is taken as the gain return number, and the gain return data is selected from the data to be returned based on the gain return number for return. If the target difference is not greater than zero, the expected gain back transmission count is directly used as the gain back transmission count, and the gain back transmission data is selected from the data to be back transmission based on the gain back transmission count.

4. The user data gain backhaul method according to claim 1, characterized in that, Saving the user exposure records corresponding to the remaining user data to the pre-return table includes: If the remaining user data corresponds to multiple user exposure records, then the multiple user exposure records are sorted according to their corresponding risk level and exposure time to obtain the record sorting result; The target exposure record is obtained by identifying the user exposure record that meets the preset gain backhaul limit condition from the user exposure record, and the first target exposure record is saved to the pre-backhaul table according to the record sorting result; If none of the user exposure records meet the preset gain backhaul limit, the first user exposure record in the record sorting result is saved to the pre-backhaul table.

5. A user data gain backhaul device, characterized in that, include: The parameter configuration module is used to configure the CPA mode and corresponding cap value of the advertisement according to preset rules, and to determine the standard CPA of the current batch of advertisements according to the CPA mode. The cap value is the upper limit multiple of the gain for user data feedback during the ad delivery; The data filtering module is used to execute the batch task of the current deployment batch according to the preset execution time, obtain the user data and corresponding user exposure records issued by the data warehouse, and filter out the data to be transmitted back from the user data according to the preset gain feedback logic and the user exposure records. The data judgment module is used to determine the number of historical backhauls of the advertised ads before the end of the current batch within a preset time range, and to determine whether the data to be backhauled in the current batch meets the preset backhaul conditions based on the standard CPA and the number of historical backhauls; the number of historical backhauls is the sum of the number of historical regular backhauls and the number of historical gain backhauls of the advertised ads within the preset time range; The data determination module is used to determine the number of gain return records in the current batch based on the number of historical return records and the cap value if the data to be returned meets the preset return conditions, and to filter out the gain return data from the data to be returned based on the number of gain return records for return. The parameter configuration module includes: The parameter configuration unit is used to configure the abnormal conditions of critical CPA, default CPA and standard CPA according to the CPA mode, and to determine historical CPA. The first standard CPA configuration unit is used to set the default CPA as the standard CPA for the current batch if the historical CPA is greater than the critical CPA or the historical CPA meets the abnormal condition. The second standard CPA configuration unit is used to use the historical CPA as the standard CPA for the current batch if the historical CPA is not greater than the critical CPA. The third standard CPA configuration unit is used to obtain a preset custom CPA and directly use the custom CPA as the standard CPA for the current batch. Furthermore, the data judgment module includes: The expected conversion number determination unit is used to calculate the cumulative ad spending of the ad campaign within the preset time range before the end of the current campaign batch, and to determine the expected conversion number of the ad campaign within the preset time range based on the cumulative ad spending, the standard CPA and the preset gain multiple. The expected gain backhaul number determination unit is used to calculate the expected gain backhaul number of the current batch by subtracting the expected conversion number from the historical backhaul number, and to determine whether the expected gain backhaul number is greater than zero. The first return condition judgment unit is used to determine that the data to be returned satisfies the preset return condition if the value is greater than zero. The second return condition judgment unit is used to determine that the data to be returned does not meet the preset return condition if it is not greater than zero, and to prohibit the return of the data to be returned in the current batch. The data filtering module includes: The data removal unit is used to determine whether there are any return records in the user data within a preset query time range, and remove the target user data containing the return records based on the determination result. The record acquisition unit is used to acquire the user exposure records corresponding to the remaining user data after removing the target user data within the preset query time range. The record saving submodule is used to save the user exposure record corresponding to the remaining user data to the pre-backhaul table if the media delivery plan corresponding to the remaining user data meets the preset gain backhaul limit condition, and to determine the data to be backhauled according to the pre-backhaul table.

6. An electronic device, characterized in that, The electronic device includes a processor and a memory; wherein the memory is used to store a computer program, which is loaded and executed by the processor to implement the user data gain backhaul method as described in any one of claims 1 to 4.

7. A computer-readable storage medium, characterized in that, Used to store a computer program, which, when executed by a processor, implements the user data gain backhaul method as described in any one of claims 1 to 4.

Images