An end-cloud cooperative marketing content distribution optimization method

Abstract

The application relates to the technical field of marketing data processing, and discloses an end-cloud cooperative marketing content distribution optimization method; the method first collects budgets, frequencies, experimental groups, brand exposures, inventories and compliance restrictions according to a marketing activity update period on the cloud side, generates a constraint rule set with an effective period, a rollback level, a version number and a check value, and distributes the constraint rule set to the end side; after the end side checks the rule, session context and an ordered candidate material list are formed based on user browsing, clicking, staying, searching, adding and coupon receiving behaviors, and compliance, inventory, experimental grouping, brand mutual exclusion, frequency and budget verification are performed on the to-be-distributed material; when the verification fails, the end side selects a replacement material according to the rollback level to continue verification, and asynchronously uploads distribution records, rollback paths and no-distributable material information to the cloud side, and the cloud side corrects next-period rule parameters and candidate material strategies, so that the end-side real-time marketing distribution and the cloud-side global constraint are cooperatively controlled.

Description

Technical Field

[0001] This invention relates to the field of marketing data processing technology, specifically to a method for optimizing marketing content distribution through end-to-end cloud collaboration. Background Technology

[0002] With the development of edge computing technology and mobile terminal computing capabilities, marketing content distribution methods are gradually evolving from centralized cloud-based decision-making to edge-cloud collaborative decision-making. In existing technologies, the published invention patent application CN114049155B discloses a marketing operation method and system based on big data analysis. This method primarily uses cloud-side models to analyze and predict e-commerce time-series data, user profiles, and purchase intentions to assist in marketing activity configuration and operational decisions. However, this type of method still relies mainly on centralized cloud-side analysis and periodic updates, making it difficult to instantly verify marketing constraints based on real-time user behaviors such as browsing, clicking, dwell time, and adding items to cart. Similarly, the published invention patent application CN107087019B discloses a task scheduling method and device based on an edge-cloud collaborative computing architecture. This method improves resource utilization and reduces task processing latency by including terminals in a computing resource pool and allocating tasks between the edge and cloud. However, this method mainly focuses on computing task scheduling and does not establish a real-time verification mechanism on the edge for global marketing constraints such as budget allocation, frequency of placement, experimental grouping, brand exposure, inventory availability, and compliance restrictions specific to the marketing content distribution scenario. Therefore, in the existing edge-cloud collaborative marketing content distribution process, edge-side personalized decisions are usually triggered within sub-second timeframes based on real-time user behavior, while cloud-side global marketing constraints are typically updated on a minute- or hour-level basis, resulting in an inconsistency in time scales. When the edge selects the optimal marketing materials solely based on local user behavior, it is prone to exceeding budget, frequency, inventory, experimental grouping, and compliance limits due to a failure to promptly detect changes in cloud-side constraints. This leads to problems such as premature consumption of marketing budgets, repeated reach to the same user, disturbance of experimental sample groups, conflicting exposures of different brands or materials, continued distribution of unsellable materials, and difficulty in tracing the distribution decision process. Consequently, there is a need to provide an edge-cloud collaborative marketing content distribution optimization method that establishes a constraint issuance, edge verification, anomaly rollback, and deviation synchronization mechanism between cloud-side global constraints and edge-side real-time decisions. This would enable edge-side personalized distribution to complete real-time adjustments while meeting global marketing constraints, thereby improving the stability, compliance, and traceability of the marketing content distribution process. Summary of the Invention

[0003] To address the shortcomings of existing technologies, this invention provides a method for optimizing marketing content distribution through end-to-end cloud collaboration, which solves the problems mentioned in the background section.

[0004] To achieve the above objectives, the present invention provides the following technical solution: A method for optimizing marketing content distribution through edge-cloud collaboration includes: S1: The cloud side aggregates budget, frequency, experiment groups, brand exposure, inventory, and compliance restrictions according to the update cycle of marketing activities, generates a set of constraint rules with validity periods and rollback levels, and distributes them to the edge side; S2: The terminal receives and verifies the constraint rule set, listens to the real-time interactive behavior of the user's mobile client, and forms a session context and an ordered list of candidate materials. S3: The client side performs local verification of materials to be distributed in the ordered candidate material list based on compliance, inventory, experimental grouping, brand exposure, frequency and budget constraints. S4: When the material to be distributed fails local verification, the terminal selects a substitute material according to the fallback level and continues to verify until a distributable material is determined or the state of no distributable material is entered. S5: The terminal registers distribution records and asynchronously sends constraint usage, rollback path, and information on undistributable materials to the cloud according to the update cycle of the marketing campaign. The cloud updates the constraint rule set for the next cycle based on the sent information.

[0005] Preferably, S1 includes: The cloud side responds to activity creation, cycle switching, constraint data changes, or the usage of constraints on the edge side reaches the warning condition, and determines the update cycle according to the activity type, data return speed, and constraint sensitivity. Convert budget, frequency, experiment grouping, brand exposure, inventory, and compliance restrictions into budget amount, remaining reach, experiment grouping correspondence, brand mutual exclusion list, inventory status, and compliance list, respectively. A set of constraint rules is generated based on the validity period, rollback level, downgrade action, version number, and checksum, and differential distribution is performed based on the version number and checksum in the client-side cache digest.

[0006] Preferably, S2 includes: The endpoint performs integrity, timeliness, and endpoint time verification on the constraint rule set. Rules that pass the verification are written to the local rule cache by activity identifier, rule dimension and version number, and abnormal rules are retransmitted or downgraded. The system collects user page dwell, scrolling, clicking, searching, favorites, adding to cart, and coupon redemption behaviors through a sliding window in the conversation. This forms a conversation context that includes page intent, category intent, brand preference, price sensitivity, discount preference, and purchase urgency. Based on the conversation context, the system filters and sorts candidate materials from the candidate material pool.

[0007] Preferably, rules that pass verification are written to the local rule cache by activity identifier, rule dimension, and version number, and abnormal rules are retransmitted or downgraded, including: The client will index the validated constraint rule set according to the activity identifier, rule dimension, and version number; When there are old and new versions of the same rule dimension, the old version will be overwritten immediately according to the emergency overwrite flag, or the new version will be enabled after the current update cycle ends. For rules that fail verification, generate retransmission requests, and after consecutive retransmission failures, perform conservative budget usage, frequency tightening, conservative inventory judgment, or compliance whitelist filtering according to the rule dimension.

[0008] Preferably, S3 includes: When a valid set of constraint rules exists locally on the client side, starting from the first material in the ordered candidate material list, read the session context, local distribution record, user session identifier, activity cycle number, and current client side time. According to the rollback level, the materials to be distributed are matched in the following order: compliance list, inventory status, experimental grouping, brand mutual exclusion, frequency window and budget amount. Generate verification records for each verification dimension, mark materials that pass all verifications as distributable materials, and pass materials that fail verification and the reasons for failure to the alternative material selection process.

[0009] Preferably, in order of rollback level, the materials to be distributed are matched sequentially with the compliance list, inventory status, experiment grouping, brand exclusivity, frequency window, and budget limit, including: When matching materials to be distributed on the client side, the compliance list is first compared with the material identifier, brand identifier, text summary, and image summary. Verify the sellability and safety stock level according to the product label; Then, check whether the user experiment group and the group label of the material to be distributed are consistent, determine whether the brand of the material to be distributed is within the brand mutual exclusion window, and count the number of touches in the session window, hourly window and daily window. Compare the amount used in this cycle with the estimated consumption of materials to be distributed.

[0010] Preferably, S4 includes: The terminal classifies the materials to be distributed into four categories based on the dimensions that were not approved: uncorrectable, replaceable, frequency-balanced, and consumption-controlled. Skip uncorrectable materials; For materials that are brand-incompatible, exceed frequency limits, or have insufficient budget, select alternative materials in the order of consistent image, same category, same benefits, and low consumption, and return to local verification. Record the original materials, alternative materials, failed dimensions, reasons for substitution, and re-validation results. When candidate materials are exhausted, the rollback limit is reached, rules are missing, local distribution record reading fails, or the user leaves the current page, enter the state of having no materials to distribute.

[0011] Preferably, for materials that are brand-incompatible, exceed frequency limits, or have insufficient budget, alternative materials are selected in the order of consistent image, same category, same benefits, and lowest consumption, and then verified locally, including: For materials that fail verification due to brand mutual exclusion, the client selects materials of the same category, not belonging to the same mutual exclusion set, and matching the session context from the candidate material list. For materials that fail verification due to exceeding the frequency limit, select materials of different brands or different material types; For materials that failed verification due to insufficient budget, select materials whose estimated consumption is lower than the remaining budget amount; According to the page meaning Figure 1 After selecting alternative materials based on consistency in product category, rights and benefits, and reduced consumption amount, compliance, inventory, experimental grouping, brand exposure, frequency, and budget verification are re-executed.

[0012] Preferably, S5 includes: When the client completes the material presentation, confirms the status of no materials to distribute, reaches the periodic upload time point, reaches the triggered upload threshold, or receives the cloud synchronization requirement, it generates local distribution records according to the dimensions of budget, frequency, brand exposure, experimental group, inventory, and compliance, and forms a periodic summary item. If the upload fails, a retry will be performed and the data will be written to the pending queue. The cloud side performs version verification, duplicate filtering, and dimension summarization on the uploaded information, and adjusts the rule parameters and candidate material strategy for the next cycle based on the usage deviation ratio, rollback path, and reasons for undistributable materials.

[0013] Preferably, when the upload fails, a retry is performed and the data is written to the pending queue, including: When asynchronous transmission fails on the end side, the periodic summary entry is resent according to the retry interval corresponding to the number of failures. After consecutive failed retries, the content to be sent will be written to the pending queue according to the update cycle. When the network recovers or the next update cycle begins, the cycle summary entries in the pending queue are merged and sent up, and the summary entries of the latest update cycle are retained when the pending queue exceeds the local storage limit.

[0014] Compared with existing technologies, this invention provides a method for optimizing marketing content distribution through edge-cloud collaboration, which has the following beneficial effects: 1. This invention, via the cloud, aggregates budget, frequency, experiment grouping, brand exposure, inventory, and compliance restrictions according to the marketing activity update cycle, generates a set of constraint rules with validity periods, rollback levels, version numbers, and verification values, and distributes them to the client side. When marketing content distribution is triggered by real-time user interactions such as browsing, clicking, dwelling, searching, adding to cart, and coupon redemption, the client side first verifies the completeness, timeliness, and client-side time of the constraint rules. Then, combining the session context, local distribution records, and an ordered candidate material list, it verifies compliance, inventory, experiment grouping, brand exclusivity, frequency, and budget for each material to be distributed. When a material to be distributed does not meet the constraint conditions, the client side... Based on the failed dimension and rollback level, alternative materials are selected and re-verified. When no distributable materials that meet the constraints can be obtained, the system enters a state of no distributable materials. At the same time, the distribution records, constraint usage, rollback path, and information on no distributable materials are asynchronously sent to the cloud side. The cloud side then adjusts the rule parameters and candidate material strategies for the next cycle based on the usage deviation, rollback reason, and candidate material coverage. This allows the personalized marketing content distribution on the client side to respond quickly to users' immediate behavior while remaining under the global marketing constraints and control of the cloud side. This avoids problems such as premature budget consumption, duplicate outreach, experimental group disturbances, brand exposure conflicts, continued distribution of unsellable materials, and difficulty in tracing the distribution process.

[0015] 2. This invention enables the orderly management of rule data across different activities, rule dimensions, and update cycles by setting version numbers, checksums, validity periods, and emergency coverage identifiers in the constraint rule set, and by establishing a local rule index on the client side according to activity identifiers, rule dimensions, and version numbers. When rule verification fails, network anomalies occur, or the client side experiences significant time deviations, the client side uses methods such as retransmission requests, incremental retries, pending queues, conservative degradation, and periodic merged uploads to classify and process abnormal rules and content to be uploaded. After receiving the aggregated information from the client side, the cloud side performs version verification, duplicate filtering, and dimension aggregation on the uploaded data, and identifies the deviation status between the rules used on the client side and the rules published on the cloud side. This reduces the occurrence of duplicate rule distribution, duplicate data uploads, and the involvement of erroneous version rules in distribution decisions, thereby improving the continuity of client-cloud rule synchronization in weak network environments, the availability of client-side cached rules, and the consistency of multi-device distributed data. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the process of a cloud-edge collaborative marketing content distribution optimization method according to the present invention. Figure 2 This is a schematic diagram illustrating the generation of constraint rule sets and the distribution of differences in this invention; Figure 3 This is a flowchart of the endpoint rule verification, cache indexing, and degradation processing of the present invention; Figure 4This is a flowchart of the local verification process for candidate materials at the end side of this invention; Figure 5 This is a schematic diagram illustrating the alternative material selection and the determination of the undistributable state in this invention; Figure 6 This is a schematic diagram of the closed loop for asynchronous data transmission on the terminal side and rule correction on the cloud side in this invention. Detailed Implementation

[0017] 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.

[0018] Example 1: Figures 1-6 A method for optimizing marketing content distribution through edge-cloud collaboration is presented, including: S1: The cloud side aggregates budget, frequency, experiment groups, brand exposure, inventory, and compliance restrictions according to the update cycle of marketing activities, generates a set of constraint rules with validity periods and rollback levels, and distributes them to the edge side; S2: The terminal receives and verifies the constraint rule set, listens to the real-time interactive behavior of the user's mobile client, and forms a session context and an ordered list of candidate materials. S3: The client side performs local verification of materials to be distributed in the ordered candidate material list based on compliance, inventory, experimental grouping, brand exposure, frequency and budget constraints. S4: When the material to be distributed fails local verification, the terminal selects a substitute material according to the fallback level and continues to verify until a distributable material is determined or the state of no distributable material is entered. S5: The terminal registers distribution records and asynchronously sends constraint usage, rollback path, and information on undistributable materials to the cloud according to the update cycle of the marketing campaign. The cloud updates the constraint rule set for the next cycle based on the sent information.

[0019] This method is applicable to membership marketing content distribution scenarios, specifically business environments such as retail, e-commerce, local services, and membership operations that require distributing coupons, activity cards, brand materials, or membership benefit reminders to users via mobile clients. Participants include cloud-based marketing operations, brand operations, compliance review, inventory management, mobile clients, and member users. Input information includes at least the following fields: marketing campaign configuration data, user interaction data, marketing material data, user profile summary, budget constraint data, frequency constraint data, experimental group constraint data, brand exposure constraint data, inventory constraint data, and compliance constraint data. The user profile summary represents membership level, category preference, brand preference, historical reach status, and historical conversion status. The status does not include the user's original click path, complete search content, and single page dwell details; by updating cloud-side global constraints at the minute or hour level and triggering personalized distribution on the client side at the sub-second level, the cloud-side constraint rules are locally verified on the client side, candidate material replacement is performed, distribution record registration is carried out, and deviations are asynchronously sent up, so that the cloud side can update the constraint rule set for the next cycle based on the status returned by the client side; after processing, the client side distribution decision record, constraint consumption status, rollback processing record, information on materials that cannot be distributed, and the constraint rule set for the next cycle updated by the cloud side are obtained; the constraint rule set is a set of rule data generated by the cloud side according to constraint dimensions such as budget, frequency, experiment grouping, brand exposure, inventory, and compliance, which is used for local reading, verification, and execution by the client side.

[0020] Specifically, such as Figure 2 As shown: In S1, the cloud side is used to convert the constraints scattered in the marketing campaign, budget, inventory, experimentation and compliance systems into a set of constraint rules that can be directly read by the edge side; the generation of the constraint rule set is triggered by the creation of a marketing campaign, the marketing campaign entering a new update cycle, changes in budget or inventory, updates to compliance restrictions, adjustments to brand exposure rules, the creation or modification of experiment groups, or the usage of constraints sent from the edge side reaching the cloud side's warning conditions; The update cycle for marketing campaigns is determined based on the campaign type, data feedback speed, and constraint sensitivity. For campaigns involving regular membership benefits and brand exposure, an update cycle of 300 to 900 seconds is suitable. For campaigns involving coupons, limited-time promotions, and inventory-sensitive activities, an update cycle of 30 to 120 seconds is suitable. For campaigns with rapid budget depletion and a large number of participating users, an update cycle of 60 seconds is preferred. The above cycles are based on the data feedback and aggregation interval of cloud-side exposure, clicks, and conversions. The update cycle should not be less than the data feedback and aggregation interval and should not exceed the time window in which the campaign status changes significantly. Mobile marketing platforms can typically complete the aggregation of exposure and click data in 30 to 60 seconds. The budget, inventory, and frequency status of marketing campaigns usually change identifiablely at the minute level. Therefore, adopting the above cycles can balance the response speed on the client side and the pressure of cloud-side rule issuance. At the start of each update cycle, the cloud side reads marketing campaign configuration data and converts restrictions from different sources into rule entries. Budget rules are derived from the campaign budget table and brand budget allocation table, and include at least the following fields: total campaign budget, remaining budget for the cycle, estimated cost per reach, channel budget cap, and brand budget cap. Frequency rules are derived from user reach rules, and include at least the following fields: daily reach cap for users, reach cap for materials, reach cap for brands, and shortest reach interval within a session. Experiment rules are derived from A / B experiment configurations, and include at least the following fields: experiment number, user group tag, group ratio, group effective time, and group freeze period. Brand rules are derived from brand campaign schedules and material exclusion tables, and include at least the following fields: brand identifier, material identifier, mutually exclusive brand set, simultaneous screen exposure limit, and campaign period exposure target. Inventory rules are derived from the product inventory system, and include at least the following fields: product identifier, inventory status, available quantity, locked inventory, near sell-out indicator, and sell-out update time. Compliance rules are derived from compliance audit data, and include at least the following fields: material identifier, brand identifier, copy summary, image summary, compliance status, blacklist status, and emergency removal indicator. The available budget for this period in the budget rules is determined jointly based on the remaining budget, the remaining activity period, and the conversion trend of the most recent update periods; for example, if the remaining budget for the activity is B, the number of remaining periods is N, and the conversion gain coefficient is r, then the available budget CB for this period is determined by the following formula: Where r is the average of the actual conversion rates of the most recent three update cycles compared to the activity baseline conversion rate; the activity baseline conversion rate can be the average conversion rate of similar marketing activities over the most recent 7 to 30 days, or the target conversion rate configured by the cloud side when the activity is created. When both exist, the historical average conversion rate of similar marketing activities is preferred; when r is less than 0.7, r is set to 0.7, and when r is greater than 1.3, r is set to 1.3, in order to suppress the excessive impact of short-term traffic fluctuations, abnormal clicks, or short-term conversion increases on the budget release amount within a single cycle; Frequency rules are represented by the remaining number of touchpoints across three dimensions: users, materials, and brands. Experimentation rules are represented by a fixed correspondence between user identifiers and experiment groups, which cannot be changed by the client during the experiment's validity period. Brand rules are represented by a brand mutual exclusion list and a material mutual exclusion list. Inventory rules are represented by three states: available, near sell-out, and sold-out. When the inventory quantity is below the safety stock threshold, it enters the near sell-out state. The safety stock threshold is determined by 3 to 5 times the average transaction volume of the most recent 10 minutes or the amount of inventory locked. This multiple is used to cover the latency of client-cloud synchronization, concurrent ordering, and inventory deduction. Compliance rules are represented by a permitted distribution list, a prohibited distribution list, and an emergency block list, with the emergency block list having higher priority than other restrictions. The constraint rule set is generated using a unified field order and includes at least the following fields: activity identifier, rule dimension, update cycle number, rule effective time, rule expiration time, available quota or status value, rollback level, downgrade action, version number, and checksum. The validity period is determined based on the rule change rate. The validity period for budget rules can be selected from 60 to 120 seconds, preferably 60 seconds, as this period matches the budget consumption return cycle. The validity period for frequency rules can be selected from 300 to 600 seconds, preferably 300 seconds, as this period covers common intervals where users repeatedly open the client within a short period. The validity period for experimental rules can be selected as the experimental period or 24 hours, preferably remaining fixed within 24 hours to avoid disturbances caused by client-side reordering of experimental samples. The validity period for brand rules can be selected from 600 to 1800 seconds. The validity period is set to 900 seconds, which covers a single continuous activity visit or a short brand exposure window. The validity period for inventory rules can be selected from 30 to 60 seconds, preferably 30 seconds, as this period is suitable for the rapid changes in inventory sell-out and locked status. The validity period for compliance rules is preferably 3600 seconds, which expires immediately upon receiving an emergency delisting order. The rollback level is determined based on the consequences of the violation, with compliance restrictions being the highest level, followed by inventory restrictions, then experimental group restrictions, and finally brand exposure restrictions, frequency restrictions, and budget restrictions in descending order. The reason for this level setting is that compliance violations usually cannot be remedied by subsequent budget adjustments, inventory errors directly affect the user's transaction experience, experimental group errors will disrupt statistical standards, and brand exposure, frequency, and budget anomalies can be partially corrected in subsequent cycles. After the constraint rule set is generated, the cloud side distributes it differently based on the client-side cache summary. The client-side cache summary consists of the activity identifier, rule dimension, version number, and checksum received by the client. The cloud side compares the client-side cache summary with the constraint rule set generated in the current period. If the version number and checksum are the same, it will not be distributed again. If the version number changes or the checksum is inconsistent, the corresponding rule entry will be distributed. The checksum is calculated by the cloud side by concatenating the activity identifier, rule dimension, update cycle number, validity period, quota or status value, and rollback level. It is used by the client to determine whether the rule has been tampered with, mismatched, or expired. The distribution channels are divided into regular channels and emergency channels. The regular channel is used for periodic updates, and the emergency channel is used for inventory sell-out, compliance removal, budget freeze, and temporary changes due to brand exclusivity. If the client is in a weak network state, the cloud side prioritizes distributing compliance, inventory, and experimental group rules, and then distributes brand exposure, frequency, and budget rules to reduce the occupation of key rule synchronization by low-priority rules. The generated and distributed constraint rule set serves as the basis for subsequent verification and local distribution control on the client side.

[0021] Specifically, such as Figure 3 As shown: In S2, the client-side is used to receive and verify the constraint rule set sent by the cloud side, and form a session context and an ordered candidate material list based on the user's real-time interactive behavior in the mobile client; the triggering conditions for the client-side processing include the mobile client starting up, the user logging into the member account, the client entering the foreground running state, the user entering the marketing content display page, or the client-side receiving the constraint rule set sent by the cloud side; the marketing content display pages include the member center homepage, activity page, product details page, search page, and shopping cart page, etc. After receiving the constraint rule set, the client performs integrity and timeliness checks on it. Integrity checks determine if the constraint rule set includes at least the following fields: activity identifier, rule dimension, version number, validity period, rollback level, and checksum. Timeliness checks determine if the client's current time is between the rule's effective and expiration times. The client's current time is corrected using the client's local clock, the cloud's response time, and the most recent network time synchronization result. If the difference between the client's local clock and the cloud's time exceeds 5 seconds, the client records the time deviation and uses the cloud's response time as the rule verification time. If the difference exceeds 30 seconds, the client suspends the use of budget and inventory rules and enters a conservative verification state. The 5-second time difference is used to identify slight deviations in the client's local clock, and 30 seconds is close to the minimum validity period for inventory and short-cycle budget rules; exceeding this time difference may cause the client to use expired rules. After the constraint rule set is validated on the client side, the rules that pass the validation are written to the local rule cache. The rule cache is indexed by activity identifier, rule dimension, and version number for subsequent local validation. For cases where there are two versions of the same rule dimension, if the old version is still valid and the new version is not marked as urgent overwrite, the client side will activate the new version after the current update cycle ends. If the new version has an urgent overwrite flag, the client side will immediately overwrite the old version and record the overwrite time. For rules that fail validation, the client side will not use the rule for distribution decisions and will generate a retransmission request to the cloud side. If the retransmission request fails three times consecutively, the retransmission interval will be 10. The intervals are 30 seconds, 30 seconds, and 60 seconds; this incremental interval is used to reduce the overhead of continuous retransmissions in weak network conditions, while allowing critical rules to be re-requested within a short period; after continuous retransmission failures, the end side enters the corresponding rule dimension's degradation processing; the budget dimension uses 70% of the previous effective rule's limit conservatively, the frequency dimension is limited to 80% of the previous effective rule's upper limit, the inventory dimension treats near-sold-out materials as undistributable, and the compliance dimension only allows the distribution of low-risk materials that have been confirmed in the local whitelist and whose material version has not changed; low-risk materials are those that have passed compliance review and whose text, images, prices, or redirect links have not changed during the current activity period; When monitoring real-time user interactions on the mobile client, the system collects data on a per-user session basis, including the current page, page dwell time, scroll direction, scroll speed, clicked area, click interval, search keywords, favorites events, add-to-cart events, coupon redemption events, back events, and foreground / background switching events. The collection interval can be selected from 50 milliseconds to 200 milliseconds; this range matches the normal refresh interval of the mobile client's event queue and can cover the granularity of continuous interactive events such as clicks, swipes, dwell times, and page switching. Page dwell time is obtained based on the difference between page entry time and page exit time; scroll speed is obtained based on the amount of page displacement per unit time; click interval is obtained based on the time difference between adjacent click events; search keywords, after being segmented on the client side, only retain product category, brand, and activity-related words, without sending the original input content. On the client side, the interaction behavior of the most recent 30 to 120 seconds is stored in a session sliding window; high-performance devices retain a 120-second window, medium-performance devices retain a 60-second window, and low-performance devices retain a 30-second window; high-performance devices are defined as having at least 500MB of available client memory and a processor load below 60%; medium-performance devices are defined as having 200MB to 500MB of available client memory; and low-performance devices are defined as having less than 200MB of available client memory or a processor load exceeding 80%; the processor load is taken as the average load over the 5 to 10 seconds after the client enters the current page to avoid frequent switching of performance levels due to instantaneous load fluctuations; the above window length and level division are used to maintain a balance between behavior recognition granularity and operational burden on different client devices; The client-side generates a session context based on the session sliding window. The session context includes at least state fields such as page intent, category intent, brand preference, price sensitivity, discount preference, and purchase urgency. Page intent is determined based on the user's current page type and navigation path. For example, if a user continuously navigates from the search page to the product details page and stays there for more than 3 seconds, the page intent is marked as a details comparison state; if a user adds items to their cart but does not complete the payment process within 20 seconds, the page intent is marked as a payment hesitation state; if a user enters the activity page and clicks on the coupon area, the page intent is marked as a promotion response state. The 3-second interval is used to exclude misjudgments caused by quickly swiping through the page, and the 20-second interval is used to identify the session state where the user has not immediately entered the payment process after adding items to their cart. The ranking is determined based on the frequency of product categories viewed in the last 30 minutes, with the top 1 to 3 categories selected as candidate categories; brand preference is ranked based on the user's purchases, favorites, and browsing of brands in the last 90 days, with recent behavior weighted higher than older behavior; price sensitivity is determined based on the user's order price distribution in the last 90 days, coupon redemption rate, and time spent on promotional pages, divided into high, medium, and low levels; discount preference is determined based on the redemption and redemption records of coupons, discount coupons, category coupons, and membership coupons; purchase urgency is determined based on click interval, add-to-cart behavior, page dwell time, and number of exits; when the click interval shortens, add-to-cart actions occur, and page dwell time exceeds 3 seconds, purchase urgency increases; After forming a session context, the client generates an ordered list of candidate materials from its local candidate material pool. The candidate material pool is distributed by the cloud side when a user logs in or opens an activity entry point, with a capacity of 60 to 240 items. The metadata for a single marketing material typically includes at least the following fields: material identifier, brand identifier, product identifier, activity identifier, material type, effective time, estimated consumption, and group tags, typically occupying 1KB to 3KB of storage. Based on this range, 240 candidate materials would occupy approximately 240KB to 720KB, which is within the acceptable range for typical mobile client caching. The client first determines the candidate material based on category intent and brand preference. The system selects a first-level candidate set from the candidate material pool based on both price sensitivity and availability. The number of candidates in the first-level candidate set can be selected from 12 to 24. Then, the candidates are sorted according to purchase urgency, discount preference, and page intent to obtain an ordered candidate material list. The sorting process does not change the experimental group affiliation and does not add materials that users are not assigned to experimental groups to the list in advance. If the candidate material pool is empty or all expired, the client requests additional candidate materials from the cloud. If the request fails, the client retains the default non-marketing content and does not proceed to formal distribution verification. The generated session context and ordered candidate material list serve as inputs for local verification of the materials to be distributed.

[0022] Specifically, such as Figure 4 As shown: In S3, the client side matches the ordered candidate material list with the local rule cache item by item to determine whether the candidate material can enter the formal distribution process. When the client side generates the ordered candidate material list and there is a set of constraint rules within the validity period locally, it starts local verification processing. The input data for the verification processing includes at least the ordered candidate material list, session context, client side rule cache, local distribution record, user session identifier, activity cycle number, and current client side time. The client side starts verification from the first material in the ordered candidate material list and executes compliance verification, inventory verification, experimental group verification, brand exposure verification, frequency verification, and budget verification in descending order of rollback level. The reason for setting the above verification order is that once high-level restrictions such as compliance, inventory, and experimental group are violated, it is usually difficult to eliminate the impact through subsequent budget or sorting corrections. Prioritizing the verification of these restrictions can reduce invalid verification and erroneous distribution. The compliance verification process reads compliance restriction rules and compares the material identifier, brand identifier, copy summary, image summary, and activity identifier of the materials to be distributed. If any of the above identifiers falls into the prohibited distribution list or emergency block list, the compliance verification of the materials to be distributed will fail. If the compliance rules have expired and the cloud side is unreachable, only low-risk materials are allowed to continue verification on the client side, while high-risk materials are put into the replacement process. Low-risk materials are those that have passed compliance review and have not undergone changes in copy, images, prices, or redirect links during the current activity period. High-risk materials are those with large coupons, medical and health products, financial services, price promises, and redirect links that have changed during the current activity period. The inventory verification process reads the inventory status rules and determines the sellability of the corresponding product based on the product identifier. If the sellability status is "sold out," the client continues with the next verification step. If the sellability status is "sold out," the inventory verification fails. If the sellability status is "nearly sold out," the client further compares the current cycle's inventory safety margin with the estimated material consumption. If the inventory safety margin is less than three times the estimated material consumption, the inventory verification fails. This three-times safety margin is used to cover the latency of client-cloud synchronization, concurrent ordering, and inventory locking, and is suitable for situations where inventory changes rapidly and the client-side trigger volume is uneven in mobile promotional scenarios. The experiment group verification reads the experiment group rules and matches the user identifier, experiment number, and group label. If the material to be distributed is not associated with an experiment number, the material is not subject to experiment group restrictions. If the material to be distributed is associated with an experiment number, the material to be distributed must be consistent with the user's local group label. The group label is generated by the cloud side and has an expiration date. The client side must not change the group label based on the user's real-time behavior. If the client side does not obtain the corresponding experiment group rules, the material to be distributed will enter the replacement process and will not pass local verification. Brand exposure verification reads brand exclusion rules and local distribution records, and compares the brands and materials that the same user has received during the campaign period. If the brand of the material to be distributed is in the same exclusion set as the most recently distributed exclusion brand, and the time interval between the two touches is less than the brand exclusion window, then the brand exposure verification fails. The brand exclusion window can be selected from 600 seconds to 1800 seconds. This time range can cover a user's continuous browsing cycle or a campaign access cycle, in order to avoid multiple exclusion brands appearing repeatedly in a short period of time. Frequency verification reads frequency limit rules and local distribution records to count the number of times reached by user, material, and brand dimensions, respectively. The statistics windows include a session window, an hourly window, and a daily window. The session window limits repeated reach to the same user during a single continuous client session; the hourly window limits high-frequency reach in short periods; and the daily window limits the total reach for the entire day. Preferably, the same material is reached no more than once in the same session, the same brand is reached no more than twice within one hour, and the total number of marketing reach per user per day can be selected from 6 to 10. For activity reminders actively subscribed to and explicitly authorized by the user, the daily maximum number of reach can be increased to 12, and this increase only applies to the activity categories subscribed to by the user. These values ​​are based on the conventional control of user disturbance in mobile membership operations, and can reduce duplicate exposure while retaining marketing reach opportunities. The budget verification reads the budget limit rules and local cycle usage, and compares them with the estimated consumption of the materials to be distributed; the estimated consumption C can be determined according to the following formula: C0 is the basic reach cost, which is the average single consumption of the material in the same channel over the past 7 days; Kp is the channel position coefficient, which is set separately for pop-ups, banners, information flow cards, and message positions; Kd is the discount coefficient, which is determined according to the proportion of the discount amount to the product price; if the used quota in this period plus the estimated consumption of the materials to be distributed exceeds the available quota in this period, the budget verification will fail; using the average single consumption of the same channel over the past 7 days as the basic reach cost can reflect the recent channel placement price and user response status, and avoid the budget estimation lag caused by using too long a historical period; The client generates a verification record for each verification. The verification record includes at least the following fields: user session identifier, activity identifier, material identifier, verification dimension, rule version number, verification time, verification result, and reason for failure. For dimensions that pass verification, the client records the pass status. For dimensions that fail verification, the client records the specific reason, such as compliance hit, insufficient inventory, experimental group mismatch, brand incompatibility, frequency exceeding limit, or insufficient budget. If the material to be distributed passes all dimensions verification, the client marks the material as a distributable material and passes the verification record to the subsequent distribution registration process. If any dimension verification fails, the client passes the current material, the failed dimension, the reason for failure, the passed dimensions, and the current position in the candidate list to the subsequent alternative material selection process.

[0023] Specifically, such as Figure 5As shown: In S4, when a material to be distributed fails local verification, the client selects a replacement material based on the failed dimension and the fallback level. The input data for the replacement material selection process includes at least an ordered candidate material list, the currently failed material, the failed dimension, the reason for failure, the fallback level, the session context, the client's rule cache, and local distribution records. The client first determines the fallback action based on the failed dimension. The fallback actions include skipping directly, replacing with the same type, downgrading replacement, pausing distribution processing due to budget constraints, and processing when there are no materials to distribute. When the failure reason is compliance restrictions, sold-out inventory, or mismatched experimental groups, it falls under the category of uncorrectable failure. The client will skip the current material and select the next material from the ordered candidate material list for local verification again. When the failure reason is mutually exclusive brand exposure, it falls under the category of replaceable failure. The client will prioritize searching for materials of the same category but different mutually exclusive brands that match the session context in the candidate material list. When the failure reason is frequency exceeding the limit, it falls under the category of frequency balancing failure. The client will prioritize selecting candidate materials of different brands or different material types. When the failure reason is insufficient budget, it falls under the category of consumption control failure. The client will prioritize selecting materials whose estimated consumption is lower than the remaining budget amount. If no matching materials are found, the process will proceed to budget suspension distribution. Alternative material selection employs a tiered rollback rule. The first tier is a consensus rollback, where the next priority material is selected under the same page intent and category intent. The second tier is a same category rollback, maintaining category consistency while allowing brand changes. The third tier is a same benefit rollback, maintaining consistent discount formats while allowing category changes. The fourth tier is a low-cost rollback, selecting materials that consume little or no budget. The fifth tier is handling materials with no distribution options, stopping the current marketing material selection and entering a state with no distribution options. After each rollback, compliance, inventory, experimental grouping, brand exposure, frequency, and budget verifications are re-executed, and compliance, inventory, and experimental grouping verifications cannot be skipped. The rollback depth can be selected from 8 to 16 tiers, with 12 tiers being preferred. 8 tiers are suitable for scenarios with a small candidate material pool or limited end-user resources, 16 tiers are suitable for scenarios with abundant candidate materials, and 12 tiers match the median size of a candidate material list of 12 to 24 items, achieving a balance between response time and replacement success rate. During the rollback process, the client maintains the rollback path. The rollback path includes at least the following fields: original material identifier, substitute material identifier, rollback level, failed dimension, reason for substitution, re-verification result, and rollback time. If the same distribution trigger event determines a distributable material within the rollback depth, the client outputs the final material identifier, all rollback paths, and the final verification record. If the candidate material list has been traversed, or the rollback depth has reached its limit, or the remaining candidate materials cannot pass verification due to compliance, inventory, experimental grouping, or budget constraints, the client enters a state where no distributable materials are available. When there are no materials to distribute, the client does not generate marketing distribution records. It only records the triggered event, candidate list version, rule version, and reason for the miss, and displays the client's native recommendation slot, basic membership benefits prompt, or a blank placeholder. This state does not consume budget, does not increase frequency, and does not change the experimental group statistics. For abnormal scenarios, the client-side handles them according to the risk level; if the constraint rule set is partially missing, and the missing dimension is budget or frequency, the client-side performs rollback verification according to a conservative proportion of the previous valid rule; if the missing dimension is compliance, inventory, or experimental grouping, the client-side does not distribute marketing materials involving that dimension; if local distribution record reading fails, the client-side executes frequency and brand exposure verification according to stricter rules, i.e., it is considered that the current session has been reached once; if the client is in a low battery or high temperature state, the client-side reduces the rollback depth, for example, from 12 layers to 8 layers, and prioritizes entering the state of no distributable materials to reduce the computational burden on the client-side; if the user leaves the current page during rollback verification, the client-side stops the current distribution trigger event and does not continue verification to prevent the old candidate material list from being used after the page context changes; the distributable materials, rollback paths, or no distributable materials information generated by the client-side are used as input for subsequent distribution registration and asynchronous uploading.

[0024] Specifically, such as Figure 6 As shown: In S5, the client side sends the actual distribution status, constraint consumption status, and rollback status back to the cloud side. The cloud side then modifies the constraint rule set for the next cycle based on the information sent back from the client side. This process is triggered when the client side generates a distribution processing result, reaches a periodic upload time point, reaches a trigger upload threshold, or when the cloud side actively requests the client side to synchronize its status. The input data includes at least the final material identifier, verification record, rollback path, information on materials that cannot be distributed, local rule version number, the amount used in this cycle, local distribution record, and client side timestamp. After the client side completes the material presentation or confirms the status of materials that cannot be distributed, it writes the processing result to the local distribution record. The local distribution record includes at least the user session identifier, activity identifier, material identifier, brand identifier, product identifier, experiment group label, distribution location, distribution time, rule version number, constraint usage, verification result, rollback path summary, and record verification value. Constraint usage is registered according to constraint dimensions; budget usage is the estimated or actual consumption corresponding to this distribution; frequency usage is one additional reach for each of the user, material, and brand dimensions; brand exposure usage is the number of exposures for the brand dimension; experimental group usage is the number of exposures for the corresponding experimental group; inventory usage is the inventory attention or discount lock-in amount generated due to material reach; compliance usage is not included in the consumption limit, but the compliance rule version and interception results are recorded; the client performs incremental aggregation of distribution records within the same update cycle to form periodic summary entries; periodic summary entries are statistically analyzed according to activity dimension, brand dimension, material dimension, and experimental group dimension, and are submitted using summary fields; Asynchronous delivery employs a combination of periodic and trigger-based delivery. Periodic delivery follows the update cycle of marketing campaigns; for example, a 60-second cycle campaign might be delivered once in the last 10 seconds of each cycle. Triggered delivery executes an intermediate delivery when the current cycle's budget usage reaches 50% of the available allowance, a high-priority delivery when the current cycle's budget usage reaches 80% of the available allowance, an abnormal delivery when the number of times no materials can be distributed reaches 20% of the trigger count in the same cycle, and a brand-specific abnormal delivery when there are 5 consecutive failed rollbacks for the same brand. 50% is used to reflect the entry of constrained consumption into the middle stage, and 80% is used for... When the constraint consumption is close to the limit, a 20% undistributable material ratio is used to identify insufficient candidate material coverage or overly tight rules. Five consecutive rollback failures are used to exclude occasional rollbacks caused by single user behavior differences or single material anomalies. When the end-side upload fails, a retry is initiated, with the first retry interval being 10 seconds, the second retry interval being 30 seconds, and the third retry interval being 60 seconds. When there are more than five consecutive failures, the end-side stores the uploaded content in the pending queue and merges the upload when the network recovers or the next cycle begins. The pending queue prioritizes the latest cycle data, and when the queue exceeds the local storage limit, it retains the summary entries of the three most recent update cycles. After receiving information from the client side, the cloud side first performs version verification and duplicate filtering. Version verification is used to determine whether the constraint rule set used by the client side is a version already released by the cloud side. Duplicate filtering is used to remove duplicate packets caused by network retries. The cloud side then summarizes the constraint usage, fallback path, and undistributable material information sent by the client side according to the dimensions of activity, brand, material, and experiment group, and compares it with the original available quota of the cloud side. The deviation ratio P is calculated according to the following formula: Where U represents the actual usage on the device side and A represents the allocated quota on the cloud side; if the deviation ratio P is less than 5%, the cloud side maintains the rules for the next cycle; if the deviation ratio P is between 5% and 15%, the cloud side makes a reverse correction to the available quota for the next cycle, for example, reducing the budget quota for the next cycle when the budget is used up too quickly, or widening the range of candidate materials or reducing the priority of reaching the same brand when the frequency rollback is large; if the deviation ratio P exceeds 15%, the cloud side immediately regenerates the constraint rule set for the corresponding dimension and sends it to the relevant device side through the emergency channel; 5% is used to represent the normal difference caused by regular device-cloud latency, network jitter and small-scale user behavior fluctuations, and 15% is used to represent the warning line for obvious deviation of device-cloud status, which is suitable for large-scale mobile distribution scenarios with a large number of devices and inconsistent network status. The cloud side also updates the candidate material strategy based on rollback paths and information on undistributable materials. "Large number of edge devices" refers to the proportion of edge devices that roll back for the same reason within the same update cycle exceeding 10% of the total number of participating edge devices, or the number of rollbacks for the same reason exceeding 1000 times. In activities with a small total number of participating edge devices, a 10% threshold is used as the judgment condition. If a large number of edge devices roll back due to inventory constraints, the cloud side lowers the ranking of the relevant product materials in the candidate list for the next cycle or removes them directly from the candidate list. If a large number of edge devices roll back due to mismatched experimental grouping, the cloud side checks the experimental grouping rules and the scope of candidate material distribution. Whether they are consistent; if a large number of end-users enter a state of having no materials to distribute due to insufficient budget, the cloud side will reduce the proportion of budget-consuming materials and increase membership benefit reminders or brand exposure materials that do not consume budget; if the number of compliance interceptions of the same material in one update cycle exceeds twice that of the previous update cycle, or if the number of end-users with compliance interceptions reaches more than 5% of the number of participating end-users, the cloud side will trigger an emergency review of the corresponding material; 10% is used to identify group rollback anomalies, 1000 times is used to cover anomalies with a low proportion but a high absolute number in large-scale activities, 2 times is used to identify a sudden increase in compliance interceptions, and 5% is used to identify the scope of compliance impact; The updated constraint rule set for the next cycle on the cloud side enters the next round of cloud side rule generation and local verification process on the device side, thus forming a closed-loop processing link from cloud side rule generation, local verification on the device side, rollback processing on the device side, and asynchronous upload of the device side to the cloud side rule update. Through the above processing link, the device side is still subject to global constraint control on the cloud side even under sub-second user interaction triggers. The cloud side can modify the rules for the next cycle based on the actual consumption and rollback status of the device side, thereby improving the synchronization, stability, compliance and traceability of the device-cloud collaborative distribution.

[0025] Example 2: Based on Example 1, the specific application process of a cloud-edge collaborative marketing content distribution optimization method is further explained: Taking a retail platform's Member Day marketing campaign as an example, the target audience is members who have logged into the mobile client. The campaign includes brand coupons, exclusive member benefit cards, product promotional materials, and campaign reminders. Before the campaign begins, the cloud-based marketing operations team creates the Member Day campaign and configures constraints such as campaign budget, user reach frequency, A / B test groups, brand exclusivity, product inventory status, and compliance review results. Based on the campaign type and data feedback speed, the cloud-based team sets the rule update cycle for the campaign to 60 seconds. This cycle matches the mobile marketing platform's processing capacity, which typically completes an exposure and click data aggregation every 30 to 60 seconds. This allows the cloud-based team to promptly perceive changes in budget, inventory, and frequency status, while avoiding excessively frequent rule issuance that could put pressure on the client-side communication. After the campaign starts, the cloud side reads the campaign budget, user reach rules, experiment configuration, brand schedule, product inventory, and compliance review data in each update cycle, and generates a set of constraint rules that can be read by the client side. For example, the campaign includes coupons for brand A, discount coupons for brand B, and reminders of ordinary member benefits. Brand A and brand B have mutually exclusive exposure relationships within the same campaign window, some product inventory is nearing sell-out, and some materials are only allowed to be distributed to users in experiment group A. The cloud side converts the above restrictions into rule items such as budget amount, frequency limit, group identifier, brand mutual exclusion list, inventory status, and compliance list, and configures the validity period and rollback level for different rules. For products with rapid inventory changes, the validity period of the inventory rule can be selected as 30 seconds; for frequency restrictions, the validity period of the frequency rule can be selected as 300 seconds; for experiment groups, the experiment rules remain fixed within the experiment cycle. The above periods correspond to the handling requirements of rapid inventory changes, repeated user visits in a short period of time, and the stability of the experiment group, respectively. After a user opens the mobile client and enters the member center homepage, the client receives a set of constraint rules from the cloud. The client first verifies whether the constraint rule set includes at least the fields of activity identifier, rule dimension, version number, validity period, rollback level, and check value. Then, it determines whether the client's current time is between the rule's effective time and the rule's expiration time. If the time difference between the client's local clock and the cloud's time exceeds 5 seconds, the client uses the cloud's response time as the rule verification time. If the time difference exceeds 30 seconds, the client suspends the use of budget rules and inventory rules and performs local verification in a conservative manner. 5 seconds is used to identify ordinary clock offset, and 30 seconds is close to the minimum validity period of short-cycle inventory rules. Continuing to use the local time after this time difference may cause the client to use expired rules. After rule validation, the client writes the rules to the local rule cache and monitors the user's real-time interactive behavior on the mobile client. For example, a user stays on the member center homepage, enters the search page, searches for a certain category of goods, enters the product details page and stays for more than 3 seconds, then adds the product to the shopping cart but does not complete the checkout within 20 seconds. The client forms a session context based on these interactive behaviors, marking the page intent as a details comparison state and a checkout hesitation state, marking the category intent as the category to which the product belongs, and combining the user's purchase, favorites, and browsing history over the past 90 days to determine brand preference and price sensitivity. The interval for the client to collect interactive behaviors can be selected from 50 milliseconds to 200 milliseconds, which can cover continuous interactive events such as clicks, swipes, pauses, and page switching. The client saves the interactive behaviors from the most recent 30 seconds to 120 seconds as a session sliding window, with a longer window reserved for high-performance devices and a shorter window reserved for low-performance devices, to balance the granularity of behavior recognition and the device's operating burden. After forming a session context, the client-side filters candidate materials from its local candidate material pool. The candidate material pool is pre-deployed by the cloud side when the user logs in or enters the activity entry point, and its capacity can be selected from 60 to 240 items. The metadata of a single marketing material typically includes at least the following fields: material identifier, brand identifier, product identifier, activity identifier, material type, effective time, estimated consumption, and group tags, and its storage usage is typically 1KB to 3KB. Based on this range, 240 candidate materials would occupy approximately 240KB to 720KB, which is within the acceptable range of regular mobile client caching. The client-side first filters 12 to 24 first-level candidate materials based on the user's current category intent, brand preference, and price sensitivity, and then sorts the candidate materials according to purchase urgency, discount preference, and page intent. If a user shows a clear purchase intention for a certain category of goods and has historically responded highly to discount coupons, the client-side will prioritize discount coupons or membership benefit materials related to that category, but will not add materials that the user does not belong to an experimental group to the candidate list in advance. The client-side performs local verification starting with the top-ranked candidate materials. If the first candidate material is a coupon for brand A, the client first verifies whether the material falls on the compliance prohibition list or the emergency block list. After compliance is passed, the client continues to verify whether the corresponding product is salable. After inventory is approved, the client verifies whether the user belongs to the permitted experimental group for the material. After the experimental group is approved, the client verifies whether there is any mutual exclusion between brand A and the brand material most recently received by the user. Then, the client verifies whether the number of times the user is reached in the current session, the 1-hour window, and the daily window exceeds the limit. Finally, the client verifies whether the remaining budget for the current period is sufficient to support the distribution of the material. The verification order starts with high-risk restrictions such as compliance, inventory, and experimental grouping, which can stop subsequent verification in time if key restrictions are not met, reducing invalid processing and incorrect distribution. If a coupon for Brand A passes all verifications, the client will identify it as a distributable material and display it on the member center homepage or product details page. If a coupon for Brand A fails verification due to near-out-of-stock inventory, the client will not display the coupon but will instead select a replacement material from the ordered candidate material list according to the rollback level. If the next candidate material is a discount coupon for Brand B in the same category, the client will continue to determine whether Brand B is mutually exclusive with brands already accepted by the user. If there is brand mutual exclusion, the client will continue to search for materials in the same category that do not belong to the mutually exclusive brand set. If there are no materials in the same category, the client will select materials with the same benefit form but different categories. If the remaining budget is insufficient, the client will prioritize member benefit prompts with low or no budget consumption. The rollback depth can be selected from 8 to 16 layers, with 12 layers being preferred. 8 layers are suitable for scenarios with few candidate materials or limited client resources, 16 layers are suitable for scenarios with abundant candidate materials, and 12 layers match the median size of the 12 to 24 candidate material lists, maintaining a balance between response time and replacement success rate. During the rollback process, the client continuously records the rollback path. The rollback path includes at least the following fields: original material identifier, substitute material identifier, failed dimension, reason for substitution, re-verification result, and rollback time. For example, if a coupon for brand A fails due to insufficient inventory, and a discount coupon for brand B fails due to brand incompatibility, but ultimately a regular membership benefit prompt is selected and passes verification, the client records the complete rollback path from the coupon for brand A to the discount coupon for brand B and then to the membership benefit prompt. If the candidate material list has been traversed, or the rollback depth has reached its limit, or all remaining candidate materials fail verification due to compliance, inventory, experimental grouping, or budget limitations, the client enters a state of no distributable materials. In this state, the client does not display marketing materials, consume budget, increase frequency, or change experimental grouping statistics; it only displays the client's native recommendation slot, basic membership benefit prompt, or a blank placeholder, and records the reason for failure. After the client completes the material display or confirms that there are no materials to distribute, it writes a local distribution record. The local distribution record includes at least the following fields: user session identifier, activity identifier, material identifier, brand identifier, product identifier, experiment group tag, distribution location, distribution time, rule version number, constraint usage, verification result, fallback path summary, and record verification value. For distributed materials, the client registers the constraint usage according to dimensions such as budget, frequency, brand exposure, experiment group, and inventory. For the state of no materials to distribute, the client registers the trigger page, candidate list version, rule version, and reason for the miss, but does not register the budget consumption and reach frequency. The client performs incremental aggregation of records within the same update cycle and forms periodic aggregation entries according to the activity dimension, brand dimension, material dimension, and experiment group dimension. The client-side uses a combination of periodic and trigger-based uploads to synchronize its status with the cloud. For activities with a 60-second update cycle, the client-side uploads a cycle summary entry 10 seconds before the end of each cycle. When the budget usage for the current cycle reaches 50% of the available amount, the client-side performs an intermediate upload. When the budget usage reaches 80%, the client-side performs a high-priority upload. When the number of times no materials can be distributed reaches 20% of the number of triggers in the same cycle, the client-side performs an abnormal upload. When the same brand fails to rollback 5 times consecutively, the client-side performs a brand abnormal upload. 50% is used to reflect that the constraint consumption has entered the middle stage, 80% is used to reflect that the constraint consumption is close to the upper limit, 20% is used to identify insufficient candidate material coverage or overly tight rules, and 5 consecutive failures are used to exclude occasional rollbacks caused by single user behavior differences or single material anomalies. If the client-side upload fails, the client-side retryes at intervals of 10 seconds, 30 seconds, and 60 seconds. If there are more than 5 consecutive failures, the uploaded content is stored in the pending queue and merged for upload when the network recovers or the next cycle begins. After receiving information from the client, the cloud side first verifies whether the rule version used by the client is a version already released by the cloud side and filters out duplicate messages caused by retries. Then, the cloud side summarizes the budget usage, frequency usage, rollback paths, and undistributable material information submitted by the client side according to the dimensions of activity, brand, material, and experiment group, and compares it with the cloud side's allocated quota. If the deviation between the actual usage submitted by the client side and the cloud side's allocated quota is less than 5%, the cloud side determines that the client-cloud status is basically consistent and maintains the rules for the next cycle. If the deviation is between 5% and 15%, the cloud side adjusts the quota for the next cycle. Reverse corrections are made, such as reducing the budget for the next cycle when the budget is used up too quickly, or broadening the range of candidate materials or reducing the priority of reaching the same brand when there are many frequency rollbacks; if the deviation exceeds 15%, the cloud side determines that the cloud status of the end-to-end is significantly deviated, and regenerates the constraint rule set for the corresponding dimension, and sends it to the relevant end-to-end through the emergency channel; 5% is used to represent normal differences caused by regular cloud-to-end latency, network jitter and small-scale user behavior fluctuations, and 15% is used to represent the warning state of significant deviation of cloud-to-end status, which is suitable for large-scale mobile distribution scenarios with a large number of end-to-end devices and inconsistent network status; The cloud side also updates the candidate material strategy based on rollback paths and undistributable material information; if the number of end-side devices rolling back for the same reason within the same update cycle accounts for more than 10% of the total number of participating end-side devices, or if the number of rollbacks for the same reason exceeds 1000 times, the cloud side identifies this reason as a group rollback anomaly; if a large number of end-side devices roll back due to inventory constraints, the cloud side lowers the ranking of the relevant goods / materials in the candidate list for the next cycle or removes them from the candidate list; if a large number of end-side devices roll back due to mismatched experimental grouping, the cloud side checks whether the experimental grouping rules are consistent with the candidate material distribution scope; if a large number of end-side devices roll back due to... If the budget is insufficient and the material is in a state of no distribution, the cloud side will reduce the proportion of budget-consuming materials and increase the number of membership benefit reminders or brand exposure materials that do not consume the budget. If the number of compliance interceptions of the same material in one update cycle exceeds twice that of the previous update cycle, or if the number of compliance interceptions on the end reaches more than 5% of the number of participating end devices, the cloud side will trigger an emergency review of the material. 10% is used to identify group rollbacks with a large impact, 1000 times is used to cover anomalies with a low proportion but a high absolute number in large-scale activities, 2 times is used to identify a sudden increase in compliance interceptions, and 5% is used to identify the scope of compliance impact. Through the above process, the constraint rule set generated on the cloud side can be verified and executed on the client side. The client side completes the sorting and local verification of candidate materials based on the user's real-time interaction behavior, and selects alternative materials or enters a state of no materials to distribute when the verification fails through a rollback mechanism. The client side then asynchronously sends the actual distribution status, constraint usage, and rollback path back to the cloud side, which then corrects the constraint rule set for the next cycle accordingly. As a result, while the client side can quickly respond to user behavior, the distribution of marketing content is continuously constrained by budget, frequency, experiment grouping, brand exposure, inventory, and compliance restrictions, and the distribution process has a recordable, verifiable, and traceable processing link.

[0026] It should be noted that this invention can be deployed on the device itself to realize embedded applications, or it can run on a PC or other terminal with a user interface, thereby meeting various hardware environments and usage requirements.

[0027] The above embodiments can be implemented in whole or in part by software, hardware, firmware, or any other combination. When implemented in software, the above embodiments can be implemented in whole or in part by a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, the processes or functions of the embodiments of this application are implemented in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted wirelessly or wiredly from one website, computer, server, or data center to another website, computer, server, or data center. Wired methods include optical fiber, twisted pair, coaxial cable, etc. Wireless methods include infrared, microwave, etc. Available media include any available media that can be accessed by a computer or data storage devices such as servers and data centers that contain one or more sets of available media. Available media can be magnetic media (floppy disks, hard disks, magnetic tapes), optical media (DVDs), or semiconductor media. Semiconductor media can be solid-state drives.

[0028] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0029] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for optimizing marketing content distribution through edge-cloud collaboration, characterized in that, include: S1: The cloud side aggregates budget, frequency, experiment groups, brand exposure, inventory, and compliance restrictions according to the update cycle of marketing activities, generates a set of constraint rules with validity periods and rollback levels, and distributes them to the edge side; S2: The terminal receives and verifies the constraint rule set, listens to the real-time interactive behavior of the user's mobile client, and forms a session context and an ordered list of candidate materials. S3: The client side performs local verification of materials to be distributed in the ordered candidate material list based on compliance, inventory, experimental grouping, brand exposure, frequency and budget constraints. S4: When the material to be distributed fails local verification, the terminal selects a substitute material according to the fallback level and continues to verify until a distributable material is determined or the state of no distributable material is entered. S5: The terminal registers distribution records and asynchronously sends constraint usage, rollback path, and information on undistributable materials to the cloud according to the update cycle of the marketing campaign. The cloud updates the constraint rule set for the next cycle based on the sent information.

2. The method for optimizing marketing content distribution through end-to-end cloud collaboration according to claim 1, characterized in that, S1 includes: The cloud side responds to activity creation, cycle switching, constraint data changes, or the usage of constraints on the edge side reaches the warning condition, and determines the update cycle according to the activity type, data return speed, and constraint sensitivity. Convert budget, frequency, experiment grouping, brand exposure, inventory, and compliance restrictions into budget amount, remaining reach, experiment grouping correspondence, brand mutual exclusion list, inventory status, and compliance list, respectively. A set of constraint rules is generated based on the validity period, rollback level, downgrade action, version number, and checksum, and differential distribution is performed based on the version number and checksum in the client-side cache digest.

3. The method for optimizing marketing content distribution through end-to-end cloud collaboration according to claim 1, characterized in that, S2 includes: The endpoint performs integrity, timeliness, and endpoint time verification on the constraint rule set. Rules that pass the verification are written to the local rule cache by activity identifier, rule dimension and version number, and abnormal rules are retransmitted or downgraded. The system collects user page dwell, scrolling, clicking, searching, favorites, adding to cart, and coupon redemption behaviors through a sliding window in the conversation. This forms a conversation context that includes page intent, category intent, brand preference, price sensitivity, discount preference, and purchase urgency. Based on the conversation context, the system filters and sorts candidate materials from the candidate material pool.

4. The method for optimizing marketing content distribution through end-to-end cloud collaboration according to claim 3, characterized in that, Rules that pass verification are written to the local rule cache by activity identifier, rule dimension, and version number. Abnormal rules are retransmitted or downgraded, including: The client will index the validated constraint rule set according to the activity identifier, rule dimension, and version number; When there are old and new versions of the same rule dimension, the old version will be overwritten immediately according to the emergency overwrite flag, or the new version will be enabled after the current update cycle ends. For rules that fail verification, generate retransmission requests, and after consecutive retransmission failures, perform conservative budget usage, frequency tightening, conservative inventory judgment, or compliance whitelist filtering according to the rule dimension.

5. The method for optimizing marketing content distribution through end-to-end cloud collaboration according to claim 1, characterized in that, S3 includes: When a valid set of constraint rules exists locally on the client side, starting from the first material in the ordered candidate material list, read the session context, local distribution record, user session identifier, activity cycle number, and current client side time. According to the rollback level, the materials to be distributed are matched in the following order: compliance list, inventory status, experimental grouping, brand mutual exclusion, frequency window and budget amount. Generate verification records for each verification dimension, mark materials that pass all verifications as distributable materials, and pass materials that fail verification and the reasons for failure to the alternative material selection process.

6. The method for optimizing marketing content distribution through end-to-end cloud collaboration according to claim 5, characterized in that, In order of rollback level, the materials to be distributed are matched sequentially with the compliance list, inventory status, experiment grouping, brand exclusivity, frequency window, and budget, including: When matching materials to be distributed on the client side, the compliance list is first compared with the material identifier, brand identifier, text summary, and image summary. Verify the sellability and safety stock level according to the product label; Then, check whether the user experiment group and the group label of the material to be distributed are consistent, determine whether the brand of the material to be distributed is within the brand mutual exclusion window, and count the number of touches in the session window, hourly window and daily window. Compare the amount used in this cycle with the estimated consumption of materials to be distributed.

7. The method for optimizing marketing content distribution through end-to-end cloud collaboration according to claim 1, characterized in that, S4 includes: The terminal classifies the materials to be distributed into four categories based on the dimensions that were not approved: uncorrectable, replaceable, frequency-balanced, and consumption-controlled. Skip uncorrectable materials; For materials that are brand-incompatible, exceed frequency limits, or have insufficient budget, select alternative materials in the order of consistent image, same category, same benefits, and low consumption, and return to local verification. Record the original materials, alternative materials, failed dimensions, reasons for substitution, and re-validation results. When candidate materials are exhausted, the rollback limit is reached, rules are missing, local distribution record reading fails, or the user leaves the current page, enter the state of having no materials to distribute.

8. The method for optimizing marketing content distribution through end-to-end cloud collaboration according to claim 7, characterized in that, For materials that are brand-incompatible, exceed frequency limits, or have insufficient budget, select alternative materials in the following order: consistent image, same category, same benefits, and lowest consumption, and return to local verification, including: For materials that fail verification due to brand mutual exclusion, the client selects materials of the same category, not belonging to the same mutual exclusion set, and matching the session context from the candidate material list. For materials that fail verification due to exceeding the frequency limit, select materials of different brands or different material types; For materials that failed verification due to insufficient budget, select materials whose estimated consumption is lower than the remaining budget amount; After selecting alternative materials based on consistency in page intent, product category, benefit form, and consumption amount, compliance, inventory, experimental grouping, brand exposure, frequency, and budget verification are re-executed.

9. The method for optimizing marketing content distribution through end-to-end cloud collaboration according to claim 1, characterized in that, S5 includes: When the client completes the material presentation, confirms the status of no materials to distribute, reaches the periodic upload time point, reaches the triggered upload threshold, or receives the cloud synchronization requirement, it generates local distribution records according to the dimensions of budget, frequency, brand exposure, experimental group, inventory, and compliance, and forms a periodic summary item. If the upload fails, a retry will be performed and the data will be written to the pending queue. The cloud side performs version verification, duplicate filtering, and dimension summarization on the uploaded information, and adjusts the rule parameters and candidate material strategy for the next cycle based on the usage deviation ratio, rollback path, and reasons for undistributable materials.

10. The method for optimizing marketing content distribution through end-to-end cloud collaboration according to claim 9, characterized in that, If the upload fails, a retry is performed and the data is written to the pending queue, including: When asynchronous transmission fails on the end side, the periodic summary entry is resent according to the retry interval corresponding to the number of failures. After consecutive failed retries, the content to be sent will be written to the pending queue according to the update cycle. When the network recovers or the next update cycle begins, the cycle summary entries in the pending queue are merged and sent up, and the summary entries of the latest update cycle are retained when the pending queue exceeds the local storage limit.

Images