Multi-channel advertisement material data aggregation and cross-platform intelligent pushing method and system

Abstract

The application discloses a kind of multi-channel advertising material data aggregation and cross-platform intelligent pushing method and system, and relates to the technical field of advertising data processing.The method comprises the following steps: establishing an index registry, dividing the index into atomic index and aggregate index; responding to query requests, executing query functions in parallel to obtain atomic index data, combining dimensions to generate a unique identifier for cross-source data alignment and merging to calculate aggregate index; receiving cross-platform pushing tasks, maintaining a material tree directory based on a nested set model, and analyzing the directory range through path chain mapping and full selection detection; filtering materials according to target platform format rules, performing idempotent pushing after double deduplication verification through association table and pushing log. The application realizes cross-platform effect unified attribution with material as the core, intelligent adaptation and idempotent guarantee of pushing, and efficient and accurate analysis of directory range, improving the management efficiency and effect of cross-platform advertising.

Description

Technical Field

[0001] This invention relates to the field of advertising data processing technology, specifically to a method and system for multi-channel advertising material data aggregation and cross-platform intelligent push. Background Technology

[0002] In the field of internet advertising, advertisers typically need to simultaneously run ad creatives on multiple media platforms (such as short video platforms, social media platforms, and news platforms) to achieve broader user reach and better campaign results. Each advertising platform usually provides an independent ad management interface and data reporting system. Advertisers need to log in to each platform separately to complete operations such as uploading creatives, configuring campaigns, and viewing performance data. This is not only cumbersome but also leads to inefficiency and an increased risk of configuration errors due to manual switching between platforms.

[0003] In cross-platform analysis of advertising performance data, existing technologies typically employ a serial query approach: query requests are sent sequentially to the data interfaces of each platform, raw data is retrieved from each platform, and then field mapping and data concatenation are performed manually or via scripts. Data reports from different platforms are incompatible in terms of data structure and indicator systems; the same indicator may have different field names or calculation methods on different platforms, preventing advertisers from conducting cross-platform performance comparisons and attribution analysis based on individual creatives. When users need to perform aggregate queries based on arbitrary dimension combinations, existing solutions require rewriting the query logic, lacking flexibility. Expanding business indicators often necessitates modifying the underlying query code, resulting in high coupling and significant development and maintenance costs. Furthermore, the cumulative query response times across platforms under the serial query approach significantly increase overall query latency, making it difficult to support real-time or near-real-time multidimensional analysis needs.

[0004] Regarding cross-platform delivery of ad creatives, different ad platforms have varying technical restrictions on creative formats. For example, video length must be between 5-30 seconds, aspect ratio must conform to 9:16 or 1:1, file size cannot exceed 100MB, and image resolution must be at least 720p. Advertisers typically manually check each creative to ensure compliance with platform specifications. If a creative doesn't meet the rules, it must be manually adjusted before uploading, a tedious process prone to errors. Furthermore, current technology lacks an effective deduplication mechanism. When a push request is submitted multiple times due to network fluctuations, system anomalies, or repetitive manual operations, the same creative may be repeatedly pushed to the same advertiser's platform, wasting API call quotas and storage resources. Existing push tasks are usually executed synchronously and blockingly, resulting in slow response times when pushing a large number of creatives; the lack of progress tracking and status recording mechanisms makes accurate recovery impossible after abnormal interruptions.

[0005] In terms of creative catalog management and push scope resolution, advertisers typically establish hierarchical creative catalog structures based on dimensions such as media platform, launch date, and product line. Current technologies usually store creative catalogs using an adjacency list model (i.e., each catalog node records its parent node identifier). Querying all child nodes and their contained creatives under a catalog requires recursive traversal along the catalog hierarchy, which significantly degrades query performance when the catalog hierarchy is deep or the number of nodes is large. Furthermore, when the catalog structure changes, the counting relationship between each node and creative needs to be manually maintained, which is complex and makes it difficult to ensure data consistency. During push scope resolution, when a user selects all subdirectories under a parent directory, the existing system cannot automatically detect the "select all" state and include the parent directory itself in the push scope, resulting in redundant and inaccurate scope resolution results.

[0006] In summary, the existing technology has the following technical problems that urgently need to be improved: (1) The data structures and indicator systems of various advertising platforms are incompatible with each other, and there is a lack of unified attribution capability for cross-platform effects based on materials; (2) Cross-platform material push lacks an automatic verification and filtering mechanism before push and idempotency guarantee for push operation, which can easily lead to push failure or repeated push; (3) The aggregation query efficiency of multi-source heterogeneous data is low, the serial query latency is high, and the indicator expansion requires modification of the core code; (4) Subtree query of material directory requires recursive traversal, directory change and material counting lack efficient synchronization mechanism, and push range parsing lacks full selection detection capability. Summary of the Invention

[0007] The purpose of this invention is to provide a method and system for multi-channel advertising material data aggregation and cross-platform intelligent push, which has the advantages of significantly improving the efficiency and accuracy of multi-channel advertising material data aggregation, realizing cross-platform intelligent push, reducing manual intervention and errors, and optimizing catalog management performance.

[0008] On the one hand, this invention provides a method for multi-channel advertising material data aggregation and cross-platform intelligent push, including the following steps: Step A: Establish an indicator registration center, which maintains an indicator function mapping table and divides indicators into atomic indicators and aggregate indicators. The atomic indicators are obtained from the data source through direct query functions, and the aggregate indicators are calculated by calculation functions that depend on the preceding atomic indicators. Step B: In response to the user's query request containing dimension combinations and indicator lists, obtain the set of query functions corresponding to the indicator list from the indicator registry center, execute each query function in the set of query functions in parallel, and obtain atomic indicator data from multiple data sources; Step C: Generate a unique identifier for the value of each field in the dimension combination, and merge the query results from different data sources according to the unique identifier to form an aligned atomic dataset; Step D: Calculate the aligned atomic dataset according to the calculation function of the aggregation index to generate a final result set containing the aggregation index; Step E: Receive a cross-platform push task, wherein the push task includes the target platform identifier and the range of material catalogs; Step F: Maintain the tree-like directory structure of the materials based on the nested set model; Step G: When parsing the range of the material directory, obtain the identifier set of the user-selected node through path chain mapping, and perform a full selection detection: if all direct child nodes of the parent node are selected, the parent node is automatically added to the identifier set to obtain the final folder identifier set; Step H: Obtain the list of materials to be pushed according to the final folder identifier set, and filter the list of materials to be pushed according to the material format rules corresponding to the target platform identifier to remove non-compliant materials; Step 1: Perform dual deduplication verification using the associated table and push logs to filter out successfully pushed content; Step J: Push the verified materials to the target platform and update the push log and the association between the materials and the platform.

[0009] On the other hand, corresponding to the method described above, the present invention also provides a multi-channel advertising material data aggregation and cross-platform intelligent push system, including: The data aggregation engine is configured to perform steps A through D. The material catalog management module is configured to execute steps F to G. The cross-platform push engine is configured to execute steps E, H, and J. As can be seen from the above, the multi-channel advertising material data aggregation and cross-platform intelligent push method and system provided by the present invention achieves parallel data query, dimension alignment and merging, and aggregation calculation by establishing an indicator registration center. Combined with a nested set model and intelligent push mechanism, it solves the problems of low efficiency in multi-source heterogeneous data aggregation and unintelligent cross-platform push. It has the advantages of significantly improving the efficiency and accuracy of multi-channel advertising material data aggregation, realizing cross-platform intelligent push, reducing manual intervention and errors, and optimizing catalog management performance.

[0010] Specifically, the present invention has the following advantages over the prior art: (1) This invention separates atomic metrics from aggregate metrics through a metric registry center. Combined with a dimension hash alignment mechanism, it aligns and merges the unique identifiers generated by combining query results from various data sources according to dimensions into a single record. This allows users to compare performance metrics such as impressions, clicks, and registration costs across platforms using creative materials as the dimension. It solves the problem of incompatibility between data formats and metric systems across platforms from a data structure perspective, enabling advertisers to obtain unified cross-platform performance reports without manual assembly. The design of the metric registry center allows new business metrics to take effect simply by registering query or calculation functions, without modifying the core code of the aggregation engine, significantly reducing the development and maintenance costs of metric expansion.

[0011] (2) This invention uses a rule filter to automatically verify and filter non-compliant materials according to the material format rules of the target platform before pushing, avoiding push failures and resource waste caused by format incompatibility. Through dual deduplication verification of the association table and push log, the association table records the binding relationship between the material and the media-side resources, and the push log records the historical successful push records, ensuring that the same material will not be repeatedly pushed to the same advertiser due to network fluctuations or system retries. This mechanism guarantees the idempotency of the push operation and saves API call quotas and storage resources.

[0012] (3) This invention uses a nested set model to maintain a tree-like directory structure, so that material statistics and node queries under any subtree do not require recursive traversal and can be completed in a single range query. The query performance is no longer affected by the depth of the directory hierarchy. Through path chain mapping and the select-all detection algorithm, when a user selects all subdirectories under a parent directory, the parent directory is automatically included in the push range, realizing the logical convergence of the range and avoiding the range redundancy and low parsing efficiency caused by listing subdirectories one by one. When the material directory is added, deleted or moved, the directory change event is asynchronously propagated through the message queue and the nested set model is synchronously updated. The decoupling of the message queue allows the directory management operation to return without waiting for the left and right values ​​of the nested set model to be updated, avoiding the operation delay caused by synchronous updates; at the same time, it ensures the eventual consistency between the directory structure change and the query structure. Even if the nested set engine is temporarily unavailable, the change event can wait in the queue and be processed after recovery.

[0013] (4) This invention significantly reduces the overall response latency of multi-dimensional aggregation queries by compressing the time originally spent waiting for responses from various data sources sequentially to the slowest single query time through parallel execution of various indicator query functions. Combined with pluggable indicator registration and automatic deduplication of dependency functions, duplicate queries from the same data source are avoided, further reducing resource consumption. The fingerprint caching mechanism caches aggregation results with the same query conditions, enabling duplicate requests to directly return results and avoiding redundant calculations.

[0014] (5) This invention adopts a three-layer asynchronous push architecture: main task - execution plan - push log. The main task records the overall push information, the execution plan tracks the progress of each execution, and the push log records the push status of each material. This architecture ensures that the push task can accurately record the progress after an abnormal interruption and continue execution after recovery, without producing inconsistent states, thus improving the reliability of the push. The coroutine pool concurrent push refines the task granularity to the level of a single material, and the atomic counter tracks the progress in real time, enabling the system to accurately grasp the push completion status.

[0015] (6) This invention organically integrates a data aggregation engine, a material catalog management subsystem, and a cross-platform push engine into a single system: the data aggregation engine performs cross-platform effect attribution analysis based on the material dimension, providing advertisers with decision-making support; the material catalog management subsystem efficiently manages the organizational structure and push scope of materials through a nested set model and path chain parser; and the cross-platform push engine executes pushes based on the catalog scope parsing results. All three share the same material identification system and catalog structure, avoiding manual data transfer and format conversion between different stages.

[0016] (7) This invention controls concurrency through a token bucket mechanism. The query function acquires a token, executes the query, and returns the token upon completion, ensuring that the number of concurrent queries is always controlled within a preset limit. This mechanism maximizes query parallelism to shorten response time while ensuring that the number of database connections does not exceed a safe threshold, thus avoiding database connection exhaustion or service rejection due to excessive concurrency.

[0017] (8) This invention uses the MD5 algorithm to generate a fixed-length hash value as a unique row identifier for dimension combinations (material identifier, date, and custom dimension), enabling heterogeneous data from different data sources to complete row-level matching and merging in a constant time without the need for complex multi-field joint comparisons. Dimension combinations support custom dimensions, allowing users to perform flexible data slicing and comparative analysis from business perspectives such as product lines and distribution channels.

[0018] (9) The select-all detection of the present invention achieves accurate determination by comparing the number of selected direct child nodes of the parent node with the total number of direct child nodes. When the two are equal and the total number of child nodes is greater than zero, the parent node is automatically included in the push scope. This determination logic makes the push scope parsing result converge from "a flat list of multiple subdirectories" to "a single node of the parent directory", which reduces the number of filtering conditions for subsequent material queries and preserves the user's original intention to select all child nodes. Detailed Implementation

[0019] The technical solutions of the present invention will be clearly and completely described below with reference to specific embodiments. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Therefore, the following detailed description of the embodiments of the present invention is not intended to limit the scope of the claimed invention, but merely represents selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0020] In traditional internet advertising systems, the heterogeneous data structures and metrics used by different advertising platforms make it impossible to achieve unified attribution of cross-platform performance data based on advertising creatives.

[0021] For example, when advertisers need to perform cross-platform performance analysis on video creatives from a marketing campaign, they must send query requests sequentially to short video platforms, social media platforms, and news platforms. Because the field names and calculation logic returned by the data interfaces of each platform differ, advertisers need to manually map metrics such as "impressions" and "clicks" to a unified dimension and manually merge the data. When pushing the video creative to multiple platforms, advertisers need to verify that the video length meets the requirements of each platform (e.g., short video platforms require 15-60 seconds, news platforms require 30-90 seconds). If the verification fails, the creative needs to be readjusted. When the creative directory contains multiple levels of subdirectories, the system needs to traverse each node to determine if it is selected when parsing the push scope. If the user selects all subdirectories under the parent directory but does not explicitly select the parent directory, the system cannot automatically include the parent directory in the push scope, resulting in an incomplete push scope. During the execution of the push task, if duplicate submissions occur due to network fluctuations, the same creative may be pushed to the same platform multiple times, consuming additional API call quotas.

[0022] If the above issues are not addressed, advertisers will struggle to obtain accurate cross-platform performance attribution data, impacting their advertising strategy optimization decisions. The high latency of multi-source data aggregation queries makes real-time adjustments to delivery strategies impractical, potentially leading to inefficient budget allocation. Duplicate pushes during creative delivery, caused by a lack of automatic verification and idempotency guarantees, not only consume additional API call quotas but may also trigger platform-side rate limiting mechanisms, further hindering normal business processes. Inefficient querying in creative catalog management and deficiencies in push scope parsing will prolong push task execution time and result in inaccurate information, increasing the need for manual intervention and reducing overall system availability and user satisfaction. Therefore, the existing technical architecture suffers from fundamental deficiencies in data consistency, system response efficiency, and operational accuracy, urgently requiring a technical solution that unifies data processing logic and optimizes the push process.

[0023] Example 1 (Method) This embodiment proposes a method for multi-channel advertising creative data aggregation and cross-platform intelligent push, which includes the following steps: Step A: Establish an indicator registry center, which maintains an indicator function mapping table and divides indicators into atomic indicators and aggregate indicators. The atomic indicators are obtained from the data source through direct query functions, and the aggregate indicators are calculated by the calculation function depending on the preceding atomic indicators. Step B: In response to the user's query request containing a combination of dimensions and a list of indicators, obtain the set of query functions corresponding to the indicator list from the indicator registry center, execute each query function in the set of query functions in parallel, and obtain atomic indicator data from multiple data sources; Step C: Generate a unique identifier for the values ​​of each field in this dimension combination, and merge the query results from different data sources according to this unique identifier to form an aligned atomic dataset; Step D: Calculate the aligned atomic dataset according to the calculation function of the aggregation index to generate a final result set containing the aggregation index; Step E: Receive a cross-platform push task, which includes the target platform identifier and the range of material catalogs; Step F: Maintain the tree-like directory structure of the materials based on the nested set model; Step G: When parsing the range of the material directory, obtain the identifier set of the user-selected node through path chain mapping, and perform a select all check: if all direct child nodes of the parent node are selected, the parent node is automatically added to the identifier set to obtain the final folder identifier set; Step H: Obtain the list of materials to be pushed based on the final folder identifier set, and filter the list of materials to be pushed according to the material format rules corresponding to the target platform identifier, removing non-compliant materials; Step 1: Perform dual deduplication verification using the associated table and push logs to filter out successfully pushed content; Step J: Push the verified materials to the target platform and update the push log and the association between the materials and the platform.

[0024] For ease of understanding, the following explains some key terms in this embodiment: Indicator Registry: Used for centralized management and maintenance of the definitions and acquisition or calculation logic of various data indicators. Its main function is to provide a unified interface that enables the system to dynamically acquire or calculate the required business indicator data based on requests.

[0025] Indicator Function Mapping Table: This table is maintained within the indicator registry center and stores the association between indicator names and their corresponding query or calculation functions. Through this mapping table, the system can quickly locate and invoke the appropriate processing logic based on the requested indicator type (atomic indicator or aggregate indicator).

[0026] Atomic metrics: These are basic data that can be directly obtained from raw data sources (such as advertising platforms) through direct query functions. Atomic metrics are typically the smallest indivisible unit of data, such as ad impressions, clicks, and spend.

[0027] Aggregate metrics: These are composite metrics that cannot be directly obtained from data sources and require calculation using predefined functions based on one or more preceding atomic metrics. Examples include advertising registration costs and return on investment (ROI).

[0028] Alignment and merging operation: This refers to the process of matching and integrating query results from different data sources based on pre-generated unique identifiers. This operation eliminates heterogeneity between data sources, forming a unified, dimension-aligned atomic dataset.

[0029] Atomic dataset: This dataset refers to a unified data set that, after alignment and merging, contains atomic metric data from all requests and corresponding dimension combinations. This dataset forms the basis for subsequent calculations of aggregate metrics.

[0030] Final Result Set: This result set refers to the data collection containing all requested atomic and aggregate metrics, derived from the atomic dataset by applying the aggregation metric calculation function. This result set is the final output of the user's query.

[0031] Cross-platform push task: This task refers to the operation instruction to push advertising creatives from one management system to multiple different advertising platforms. This task typically includes information about the creatives to be pushed, the target platforms, and other relevant configurations.

[0032] Nested set model: This model is a data structure used to represent and manage tree-structured data (such as a catalog of materials). It enables efficient subtree queries and structural operations by assigning each node a pair of values ​​(usually called left and right values) to represent its position and range in the tree.

[0033] Path chain mapping: This mapping refers to generating a path string or identifier sequence representing the complete hierarchical relationship of each node by parsing the tree structure of the material directory. This mapping helps to quickly identify and locate the user-selected node and all its child nodes when parsing the range of the material directory.

[0034] Select All Detection: This detection refers to the process by which the system determines whether all direct subdirectories under a parent directory have been selected by the user when parsing the range of material directories. If all direct subdirectories are selected, the parent directory is automatically identified as "selected all" and added to the set of identifiers to be processed, in order to simplify subsequent processing.

[0035] Final Folder Identifier Set: This set refers to the unique identifiers of all the media folders that need to be processed, determined after path chain mapping and select-all detection. This set is used to accurately locate the media to be pushed.

[0036] Creative Material Format Rules: These rules refer to the specific technical requirements set by each advertising platform for the format, size, duration, and file size of the advertising creative materials it receives. Creative materials that do not comply with these rules will be rejected by the platform.

[0037] Association Table: This table records the correspondence between media materials and their corresponding resource identifiers. Through this table, the unique identifiers of media materials on different platforms can be tracked, enabling cross-platform material management and deduplication.

[0038] Double deduplication verification: This verification refers to the process of checking the association table and push log simultaneously before the creative is pushed to ensure that the same creative is not pushed to the same target platform or the same advertiser, thereby improving the efficiency and accuracy of the push.

[0039] The following example will provide a more detailed explanation of the above technical solution: Suppose an advertising company needs to push a batch of newly created advertising materials, including images and videos, to the two major short video platforms, Douyin and Kuaishou, and wants to be able to view the impressions, clicks, and registration costs of these materials on both platforms in real time. First, the system has pre-established a metric registry center. Within this center, a metric function mapping table is maintained. For example, "impressions" and "clicks" are defined as atomic metrics, and their query functions point to the API interfaces of Douyin and Kuaishou platforms respectively, for directly retrieving data. "Registration cost" is defined as an aggregate metric, and its calculation function is set to "cost / number of registrations," where "cost" and "number of registrations" are atomic metrics.

[0040] When User A submits a query request in the ad management backend, requesting to view the "impressions," "clicks," and "registration cost" of "Article A" on the "Douyin" and "Kuaishou" platforms from "October 1, 2023" to "October 7, 2023," the system parses the request, identifying the dimension combination as "Article A, October 1, 2023 - October 7, 2023, Douyin / Kuaishou," and the metric list as "impressions, clicks, registration cost." The system retrieves the query function set corresponding to the four atomic metrics—"impressions," "clicks," "cost," and "registrations"—from the metric registry center. Subsequently, the system executes these query functions in parallel, simultaneously sending requests to the data interfaces of Douyin and Kuaishou to obtain the impressions, clicks, cost, and registration data for "Article A" within the specified date range.

[0041] Assuming the data format returned by Douyin differs from that of Kuaishou, but both contain dimensional information such as material ID, date, and platform ID, the system will concatenate the values ​​of fields such as "Material A," "October 1, 2023," and "Douyin" from the dimension combination to generate a unique identifier, such as "MD5(Material A_20231001_Douyin)." Similarly, the data returned by Kuaishou will undergo similar processing. Then, based on these unique identifiers, the system will align and merge the data from Douyin and Kuaishou to form a unified atomic dataset. For example, if both Douyin and Kuaishou return data for "Material A" on "October 1, 2023," they will be merged into the same row of records using the same unique identifier.

[0042] Next, the system will use the existing "spending" and "registration count" data in the atomic dataset and the "registration cost" calculation function (spending / registration count) defined in the metric registry center to calculate the registration cost of "material A" on the specified date and platform. Finally, a final result set containing "impressions", "clicks", "spending", "registration count", and "registration cost" will be generated for user A to view.

[0043] Now, suppose user A needs to push "Material A" and "Material B" to the Douyin and Kuaishou platforms. User A selects the two directories "Promotional Activities / Double Eleven / Video Materials" and "Promotional Activities / Double Eleven / Image Materials" in the material management interface, and specifies the target platforms as "Douyin" and "Kuaishou". The system receives this cross-platform push task.

[0044] The material management system has maintained a tree-like directory structure for materials based on a nested set model. For example, the left and right values ​​of the "Promotional Activities" directory might be (1, 20), its subdirectory "Double Eleven" might be (2, 15), while "Video Materials" and "Image Materials" are located under "Double Eleven" and have their own left and right value ranges.

[0045] Subsequently, the system analyzes the range of material directories selected by user A. Through path chain mapping, the system identifies the node identifiers corresponding to "Promotional Activities / Double Eleven / Video Materials" and "Promotional Activities / Double Eleven / Image Materials". Assume that the "Double Eleven" directory only has two direct child nodes, "Video Materials" and "Image Materials," and both are selected. At this point, the system performs a select-all check, finding that all direct child nodes of the "Double Eleven" parent node are selected. Therefore, the identifier of the "Double Eleven" parent node is automatically added to the final folder identifier set.

[0046] Based on the final folder identifier set, the system retrieves a list of all materials to be pushed under the "Double Eleven" directory from the material library, including "Material A" (videos) and "Material B" (images). The system queries the material format rules of Douyin and Kuaishou platforms respectively. For example, Douyin may require videos to be no longer than 60 seconds and images to have a 9:16 aspect ratio; Kuaishou may require videos to be no longer than 30 seconds and images to have a 1:1 aspect ratio. The system filters "Material A" and "Material B" according to these rules. If the video length of "Material A" is 45 seconds, it meets Douyin's requirements but not Kuaishou's, and therefore will be rejected when pushed to Kuaishou. If the image size of "Material B" is 1:1, it meets Kuaishou's requirements but not Douyin's, and therefore will be rejected when pushed to Douyin.

[0047] Next, the system performs double deduplication checks on the filtered materials to be pushed. For example, the system checks the association table to see if "Material A" already has an associated record on the Douyin platform; at the same time, it checks the push log to see if "Material A" has been successfully pushed to Douyin. If it finds that "Material A" has been successfully pushed to Douyin before, it will be filtered out from the list of materials to be pushed to Douyin this time.

[0048] Finally, for materials that pass verification (for example, assuming "Material A" has not been pushed to Kuaishou and conforms to Kuaishou's format), the system pushes it to the target platform (Kuaishou). After a successful push, the system immediately updates the push log to record that "Material A" has been successfully pushed to the Kuaishou platform, and updates the association table to record the association between "Material A" and the resource identifier on the Kuaishou platform.

[0049] In summary, this method, through an innovative combination of multiple technical aspects such as data aggregation, intelligent push, and efficient catalog management, effectively solves a series of problems in existing technologies, such as data heterogeneity, inefficient push, and complex management, providing advertisers with more efficient, accurate, and flexible multi-channel advertising material management and delivery capabilities.

[0050] This embodiment further proposes that the atomic metrics in step A include impressions, clicks, spending, and registrations obtained directly from data sources of various advertising platforms; the aggregated metrics include registration cost and return on investment, wherein the registration cost depends on spending and registrations, and the return on investment depends on advertising revenue and spending; in step B, when each query function is executed in parallel, the concurrency is controlled by a token bucket method, the query function obtains a token and executes, and returns the token after execution.

[0051] In addition to the metrics listed above, atomic metrics can also include impressions, conversions, and downloads. Among aggregate metrics, cost of registration can be calculated by dividing spending by the number of registrations, while return on investment (ROI) can be calculated by dividing the difference between advertising revenue and spending by the spending. Besides cost of registration and ROI, aggregate metrics can also include cost per thousand impressions (CPM), cost per click (CPC), or cost per action (CPA).

[0052] The token bucket is a traffic shaping and rate limiting algorithm. Its core idea is to maintain a "bucket" with a fixed capacity and add "tokens" to the bucket at a constant rate. Each time an operation (such as a query function) needs to be executed, a token must be taken from the bucket. If there are no tokens in the bucket, the operation must wait until new tokens become available. Once the query function obtains a token, it can execute the data query operation and return the used token to the token bucket after completion. Besides the token bucket approach, leaky bucket algorithms, semaphore mechanisms, or sliding window-based counters can also be used to control concurrency.

[0053] In step C, the unique identifier can be a hash value generated using the MD5 algorithm. The MD5 algorithm is a cryptographic hash function that can map data of arbitrary length to a fixed-length hash value. By combining the field values ​​in the dimension combination and generating a fixed-length hash value using the MD5 algorithm as a unique identifier, a specific state of the dimension combination can be efficiently represented, ensuring accurate alignment of query results from different data sources during merging. Besides MD5, other hash algorithms such as SHA-1 and SHA-256 can also be used, or the hash value can be calculated by concatenating strings with the dimension fields. The dimension combination includes a creative identifier, a date, and at least one custom dimension. Dimension combinations are data slicing conditions specified by the user when querying data, used to limit the scope and granularity of the data. The creative identifier is used to uniquely identify advertising creatives, the date is used to specify a time range, and custom dimensions allow users to flexibly expand query conditions according to business needs, such as ad placement, target area, audience characteristics, etc. These dimensions together constitute the query context and are the foundation for data aggregation and analysis.

[0054] Step D further includes fingerprint caching of the final result set of the aggregation query, directly returning cached results for requests with the same query conditions. The fingerprint caching mechanism aims to improve query response speed and reduce redundant calculations. When a query request is received, the system first generates a unique fingerprint based on the query conditions (e.g., by hashing the query condition string), and then checks if the result set corresponding to that fingerprint exists in the cache. If it exists and has not expired, the cached result is returned directly, avoiding re-execution of the data aggregation and calculation process. This cache can be stored in an in-memory database (e.g., Redis), a distributed caching system (e.g., Memcached), or a local file system. Furthermore, the detection results of the media date directory are cached for a short period to avoid repeated database queries during high-frequency creation. Detection of the media date directory may involve frequent database queries, especially when new materials are added or released. Through short-term caching, the system can store the existence status of detected directories for a certain period (e.g., minutes or hours). When the same directory is detected again, the result can be directly retrieved from the cache, thereby reducing database load and improving response efficiency. This cache can be a memory cache, a local file cache, or a distributed cache.

[0055] Some of the above implementations propose receiving cross-platform push tasks and filtering, verifying, and pushing materials based on the task content. However, in the actual process of cross-platform material push, the complexity of the tasks, the tracking of execution status, and the investigation of anomalies often present challenges.

[0056] Especially when dealing with a large amount of material and multiple target platforms, the lack of a refined task management mechanism may lead to an opaque push process and difficulty in controlling progress, thereby affecting push efficiency and reliability.

[0057] In response, this embodiment further proposes a three-layer model for managing the cross-platform push task in step E, including a main task, an execution plan, and a push log: the main task records the overall push information, the execution plan records the progress of a single execution, and the push log records the push status of each material.

[0058] This three-tiered management model aims to structurally decompose complex cross-platform push tasks by establishing management entities at different levels to clearly define the scope, progress, and detailed status of tasks. It can be implemented using object-oriented design patterns; for example, defining each level as an object with specific attributes and behaviors; or storing and managing data at different levels through multiple related tables in a database to ensure data consistency and traceability.

[0059] The master task is the top-level abstraction for cross-platform push tasks, used to record macro-level information about the entire push process. This includes, but is not limited to, the task creator, creation time, task name, total number of target platforms, total number of materials, overall task status (such as "pending execution," "in execution," "completed," "cancelled"), and task priority. The master task can serve as the entry point for task scheduling and monitoring, providing an overview of the entire push process.

[0060] An execution plan is a sub-level of the main task, used to record each specific execution attempt or stage of progress under the main task. A main task may contain one or more execution plans. For example, push notifications for different target platforms can correspond to different execution plans, or a push notification retried after a failure can also generate a new execution plan. The information recorded in the execution plan may include its main task identifier, target platform identifier, start time, end time of this execution, current execution status (e.g., "Pushing on Platform A", "Pushing on Platform B failed"), number of pushed materials, number of materials to be pushed, etc.

[0061] The push log is the finest-grained management layer in the three-layer model, used to record the detailed status of each creative in each push attempt. Specifically, it includes: the creative's unique identifier, the execution plan identifier, the target platform identifier, the push time, the push result (e.g., "success," "failure," "deduplicated"), the reason for failure, and the error code returned by the platform. The push log provides a complete record of the push status of a single creative and is an important basis for troubleshooting and performance analysis.

[0062] The aforementioned hierarchical management mechanism effectively solves the problems of difficulty in tracking complex push tasks and lack of transparency in progress, ensuring the reliability, traceability, and efficiency of cross-platform material push, thereby optimizing the operational efficiency and stability of the entire multi-channel advertising material data aggregation and cross-platform intelligent push method.

[0063] In step F, the nested set model represents each directory node using lvalues ​​and rvalues, and supports the following operations: When adding a child node, insert and update the left and right values ​​of the entire table at the left value position of the parent node; When deleting a node, remove the specified node and its subtree, and shrink the left and right values ​​of the entire table. When moving nodes, delete first and then add to achieve cross-level movement; query the total amount of materials under any subtree by left and right value range.

[0064] In addition, when the material is first added to the database or about to be deployed to the target platform, the metadata features of the material are extracted, the features are input into a pre-trained machine learning model, the performance indicators of the material during the cold start phase on the target platform are predicted, and the prediction results are compared with the platform's historical benchmarks to generate an initial performance prediction report.

[0065] The machine learning model is trained based on the metadata features of historically deployed materials and their actual performance metrics during the cold start phase, which is the first 24 or 72 hours after material deployment. When the material catalog is updated, deleted, or moved, the catalog change event is asynchronously propagated through a message queue, triggering a synchronous update of the nested set model.

[0066] Nested set model is a data storage method for representing tree structures. Its core idea is to assign each node in the tree a pair of values: an left-value pair and a right-value pair. These values ​​define the range of a node within the tree, making it highly efficient to query all descendants (subtrees) of a given node; simply check if its left and right values ​​fall between the left and right values ​​of its parent node. This model is particularly suitable for scenarios involving frequent queries of subtree structures or counting the number of elements within a subtree.

[0067] In implementation, when adding a child node, it can be inserted at the left-hand value position of its parent node, and the integrity of the model is maintained by adjusting the left and right values ​​of all affected nodes. This can be done, for example, by executing a series of update statements in the database, or by batch updating after building the tree structure in memory. When deleting a node and its subtrees, all nodes within the range of left and right values ​​of the deleted node can be removed, and the left and right values ​​of the remaining nodes can be shrunk to fill the gaps left by the deleted node.

[0068] When moving nodes (including their subtrees), a "delete first, then add" strategy can be adopted. First, logically delete the node to be moved and its subtree from their original positions and adjust the left and right values ​​of the relevant nodes; then, insert it as a new child node into the left value position of the target parent node, and update the left and right values ​​of the entire table again. The total amount of materials under any subtree can be statistically calculated by querying the range of left and right values. This is achieved because for any parent node, the left value of all its child nodes (including direct and indirect child nodes) will be greater than the left value of the parent node, and the right value will be less than the right value of the parent node. Therefore, by simply querying the number of records in the database whose left value is greater than the left value of the parent node and whose right value is less than the right value of the parent node, the total amount of materials under that subtree can be efficiently obtained.

[0069] This solution aims to improve the accuracy of creative content delivery through intelligent prediction. The metadata features of the creative content refer to data describing its content, format, and attributes, such as its size, duration, file size, color composition, text keywords, and creative type. These features can be automatically extracted from the creative files or manually labeled when the content is added to the database. The pre-trained machine learning model is a model whose parameters have been learned and adjusted through a large amount of historical data, capable of outputting prediction results based on the input creative features. This model can be a deep learning model (such as a convolutional neural network for image / video feature extraction, or a recurrent neural network for text feature processing) or a traditional machine learning model (such as a gradient boosting tree or support vector machine), depending on the type of creative features and the complexity of the prediction task. Predicting the performance metrics of the creative content during the cold start phase on the target platform refers to the key performance indicators that may be achieved in the early stages of creative content delivery (e.g., the first 24 hours or the first 72 hours), such as click-through rate (CTR), conversion rate (CVR), impressions, and cost. The prediction results are compared with the platform's historical benchmarks to generate an initial performance forecast report. This is achieved by comparing the predicted performance indicators with the average performance of historical materials of the same type, industry, or budget on the target platform, thereby assessing the potential performance of the new materials and presenting them to users in the form of a report to assist in decision-making.

[0070] The training of the machine learning model is an iterative process designed to teach the model the mapping relationship from input features to output predictions. Training data consists of two parts: first, metadata features of historically deployed creatives, which serve as the model's input; and second, actual performance metrics of these creatives during the cold start phase, which are the model's true labels or target values. The training process can employ supervised learning algorithms to optimize model parameters by minimizing the error between predicted and actual values. For example, for regression tasks (predicting continuous values ​​such as click-through rate and conversion rate), mean squared error (MSE) can be used as the loss function; for classification tasks (predicting whether a creative will perform well), cross-entropy loss can be used. After training, the model can generalize its cold start performance metrics from new creative metadata features. The cold start phase is a critical period in the initial stage of ad creative deployment, and its performance often significantly impacts subsequent deployment strategies and results. Defining the cold start phase as the first 24 or 72 hours after deployment is a time window derived from industry experience and data analysis. Choosing between 24 hours or 72 hours as the cold start phase allows for flexible configuration based on different advertising platforms' data feedback cycles, creative types (for example, short video creatives may show initial results within 24 hours, while some long-cycle conversion creatives may require 72 hours), and business needs. During this period, the system closely monitors creative performance and uses it as a basis for training and predicting machine learning models.

[0071] This embodiment further proposes a full-selection detection mechanism: this mechanism compares the number of selected direct child nodes of a parent node with the total number of direct child nodes; when the two are equal and the total number of direct child nodes is greater than zero, it is determined that all nodes are selected, and the parent node identifier is added to the identifier set. Specifically, full-selection detection is a mechanism used to determine whether all direct child nodes of a given parent node have been explicitly selected or marked. Its purpose is to simplify user interaction and data processing by automatically inferring the selection status of parent nodes, thereby reducing the need for users to manually select parent nodes and optimizing the generation process of the final folder identifier set.

[0072] When parsing the media directory, the system first obtains the set of node identifiers explicitly selected by the user through path chain mapping. Based on this, to optimize user experience and simplify subsequent processing, the system performs a "select all" check for each parent node. This check mechanism precisely compares the number of selected direct child nodes under the current parent node with the total number of direct child nodes that parent node possesses. When these two numbers are equal, and the total number of direct child nodes is greater than zero, the system logically determines that the parent node is in a "select all" state. Once determined to be "select all," the parent node's identifier is automatically included in the final identifier set. This mechanism avoids the tedious operation of manually selecting the parent node after selecting all child nodes, ensuring the integrity and accuracy of the final folder identifier set, while reducing the user's operational burden. In this way, even when the user only selects all child nodes, the system can intelligently identify and include their parent nodes, thus more accurately reflecting the user's intent and providing a more precise scope for subsequent media acquisition and delivery.

[0073] Step H further includes: periodically pulling material lists and daily performance data according to the open application interfaces of each advertising platform through scheduled tasks, and uniformly writing them into a wide table of the columnar storage database; automatically checking whether the corresponding media date directory exists when new materials are added to the database, and creating and triggering the synchronization of the nested collection model if it does not exist; the material format rules include at least one of video duration range, image size ratio, and file size limit.

[0074] This technical feature is designed to ensure that the system can continuously and promptly acquire the latest creative information and its performance data from different advertising platforms. By periodically calling the open application programming interfaces (APIs) provided by each advertising platform, metadata of the creatives (such as creative ID, name, type, size, duration, etc.) and daily performance data (such as impressions, clicks, cost, etc.) can be automatically collected.

[0075] Centralized storage of retrieved heterogeneous data from multiple sources, unified integration, and writing to wide tables in a columnar storage database effectively addresses the demands of high-concurrency writes, multi-dimensional queries, and massive data storage for advertising data. Columnar storage databases, due to their column-based storage characteristics, offer significant performance advantages in aggregation queries and analysis, while the wide table design facilitates the flattening and integration of related data from different sources, simplifying query logic. For example, distributed columnar databases such as Apache Cassandra or HBase can be used to store this data; alternatively, analytical columnar databases such as ClickHouse or Vertica can be employed to optimize subsequent data analysis and report generation efficiency.

[0076] When new materials are retrieved and ready to be added to the database, the system automatically determines whether the corresponding directory exists based on information such as the material's media source and the date of addition. If the corresponding directory has not yet been created, the system will automatically create it. Simultaneously, since the directory structure is maintained based on a nested set model, any addition, deletion, or movement of a directory requires triggering a synchronous update of the nested set model to ensure the consistency of the directory's left and right values, thereby guaranteeing the accuracy of subsequent directory queries and management operations. For example, a directory management module can be integrated into the material addition process. This module is responsible for detecting and creating directories and sending synchronization instructions to the nested set model; alternatively, an event-driven architecture can be adopted, where a directory change event is published when a new material is added to the database, and is handled asynchronously by a dedicated directory synchronization service.

[0077] This embodiment further proposes a mechanism for dual deduplication verification using an association table and push logs to filter successfully pushed content. The association table records the correspondence between content and media-side resource identifiers, while the push logs record the combination of successfully pushed content identifiers with target platform identifiers and advertiser identifiers. During dual deduplication verification, if a corresponding relationship already exists in the association table or a successful record exists in the push logs, the content is determined to have been pushed and is filtered out.

[0078] The association table is used to store and manage data mapping relationships between different systems or entities. In this embodiment, it is used to establish a connection between the unique identifier of the advertising creative in the internal system and the resource identifier of the creative on an external media platform (such as an advertising platform). This correspondence can be stored in various forms, for example, it can be a relational database table containing fields for creative ID and media resource ID; or a key-value store system, where the creative ID is the key and the media resource ID is the value.

[0079] The dual deduplication verification refers to the process of simultaneously checking two independent recording systems (i.e., the association table and the push log) to determine whether the material has already been pushed before performing the material push operation. When the system finds the correspondence between the material to be pushed and the resource identifier on the target platform's media side in the association table, or finds a record in the push log that the material has been successfully pushed to the target platform and the advertiser, the system will determine that the material has been pushed. Once determined to have been pushed, the material will be removed from the list of materials to be pushed and no further actual push operation will be performed, so as to effectively avoid duplicate pushes, save system resources, and ensure data consistency.

[0080] In step J, when pushing materials to the target platform, a millisecond-level sliding window is used to protect the frequency of application interface calls; the sliding window records the millisecond request count based on the time slice array, compresses expired time slices through dynamic header pointers, and merges the counts of requests with the same timestamp.

[0081] A millisecond sliding window is a mechanism for real-time monitoring and control of data flow or event rate. It defines a fixed-size time window and slides it in milliseconds to count the number of events occurring within the window at each point in time.

[0082] Application programming interface (API) call frequency control protection refers to limiting and managing the call frequency of application programming interfaces provided by a system or service to prevent service overload, resource exhaustion, or violation of third-party platform usage policies due to excessively fast or numerous calls.

[0083] By introducing a millisecond-level sliding window in step J for frequency control protection of application interface calls, this embodiment enables fine-grained and real-time management of API call frequency during material delivery. By recording millisecond request counts using a time slice array and combining dynamic header pointer compression of expired time slices with techniques for merging requests with the same timestamp, the accuracy and efficiency of the frequency control mechanism are significantly improved. This effectively avoids problems such as API rate limiting, request failures, or service interruptions caused by instantaneous high-concurrency pushes, ensuring that materials can be pushed to the target platform stably and reliably. Simultaneously, this fine-grained frequency control mechanism also optimizes system resource utilization and reduces the risk of interaction with external platforms, thereby guaranteeing the overall operational efficiency and user experience of multi-channel advertising material data aggregation and cross-platform intelligent push methods.

[0084] Example 2 (System) This embodiment proposes a multi-channel advertising creative data aggregation and cross-platform intelligent push system. The system includes a data aggregation engine, a creative catalog management module, and a cross-platform push engine.

[0085] The data aggregation engine is configured to execute steps A through D. Specifically, the data aggregation engine establishes an indicator registry center, which maintains an indicator function mapping table, dividing indicators into atomic indicators and aggregated indicators. In response to a user-submitted query request containing dimension combinations and an indicator list, the engine retrieves the set of query functions corresponding to the indicator list from the indicator registry center, executes each query function in the set in parallel, and obtains atomic indicator data from multiple data sources. It generates unique identifiers for the values ​​of each field in the dimension combinations, aligns and merges the query results from different data sources according to these unique identifiers, forming an aligned atomic dataset. Finally, it calculates the aligned atomic dataset according to the calculation function of the aggregated indicators, generating a final result set containing the aggregated indicators.

[0086] The media catalog management module is configured to execute steps F to G. Specifically, this media catalog management module maintains a tree-like catalog structure of media based on a nested set model; when parsing the media catalog range, it obtains the identifier set of the user-selected node through path chain mapping and performs a select-all check: if all direct child nodes of a parent node are selected, the parent node is automatically added to the identifier set, resulting in the final folder identifier set.

[0087] The cross-platform push engine is configured to execute steps E, H, and J. Specifically, the cross-platform push engine receives a cross-platform push task, which includes a target platform identifier and a media directory range; it obtains a list of media to be pushed based on the final folder identifier set, filters the list of media to be pushed according to the media format rules corresponding to the target platform identifier, and removes non-compliant media; it performs dual deduplication verification through an association table and push logs to filter successfully pushed media; it pushes the verified media to the target platform and updates the push logs and the association between the media and the platform.

[0088] This embodiment effectively solves the multi-channel advertising data aggregation and push problem existing in the prior art by systematically integrating a data aggregation engine, a material catalog management module, and a cross-platform push engine. The data aggregation engine overcomes the incompatibility defects of data structures and indicator systems across different advertising platforms through an indicator registry center and parallel query mechanism, achieving unified cross-platform effect attribution centered on materials and significantly improving the efficiency of multi-source heterogeneous data aggregation queries. The material catalog management module adopts a nested set model and a select-all detection mechanism to avoid the performance bottleneck of recursive traversal required for material catalog subtree queries, improving the accuracy of push range parsing. The cross-platform push engine implements format rule filtering and double deduplication verification to ensure the idempotency of push operations and effectively prevent push failures and duplicate pushes. Through the above technical solutions, this system can provide advertisers with efficient, accurate, and flexible multi-channel advertising material data aggregation analysis and cross-platform intelligent push services, significantly improving the efficiency and effectiveness of advertising placement management.

[0089] In this embodiment, the data aggregation engine includes: an indicator registration center, a concurrent query unit, a dimension hash aligner, and an aggregation indicator calculator.

[0090] The indicator registry is a centralized management module responsible for maintaining indicator definitions and their corresponding function mappings. Indicators are explicitly divided into atomic indicators and aggregate indicators. Atomic indicators are basic data directly obtained from the data source, while aggregate indicators are composite indicators derived from atomic indicators using specific calculation functions. This registry can be implemented as a configuration service, recording the name, type, data source, query function, or calculation function of each indicator through a metadata table stored in a database (e.g., a relational or document-oriented database). Alternatively, it can be designed as an independent microservice, providing an API interface for other modules to query and register indicator definitions, ensuring consistency and maintainability of indicator definitions.

[0091] The concurrent query unit executes multiple query functions in parallel to efficiently retrieve atomic metric data from different data sources. Its purpose is to significantly improve data retrieval efficiency, especially when data needs to be pulled from multiple advertising platforms simultaneously. This unit can be implemented using multithreading or coroutine techniques. For example, a thread pool can manage concurrent database connections or API requests, with each query function submitted to the thread pool as an independent task for execution. Alternatively, an asynchronous I / O model can be employed, using an event loop mechanism to handle query requests from multiple data sources non-blockingly, thereby maximizing system resource utilization.

[0092] The role of a dimension hash aligner is to standardize and merge query results from different data sources. It generates a unique identifier for each field value in a dimension combination and then uses this identifier to align and merge data from different data sources. For example, for a combination containing dimensions such as material identifiers and dates, these dimension values ​​can be concatenated into a string, and a fixed-length hash value can be generated using a hash algorithm (such as MD5 or SHA-256) as a unique identifier. This identifier is then used to link logically corresponding data records from different data sources in memory or through database operations (such as JOIN) to form a unified atomic dataset.

[0093] The function of the aggregated metric calculator is to perform calculations on atomic datasets processed by a dimensional hash aligner according to predefined calculation functions, thereby deriving the final result set of aggregated metrics. Its core lies in executing complex business logic, transforming atomic data into meaningful business metrics. This calculator can be a data processing engine that receives aligned atomic datasets as input and performs data transformation and calculations based on aggregated metric calculation functions (such as summation, averaging, ratios, etc.) provided by the metric registry. When processing large-scale data, distributed computing frameworks (such as Apache Spark or Hadoop MapReduce) can be used to achieve efficient parallel computing.

[0094] The material directory management subsystem includes: a tree-shaped directory manager, a nested collection engine, and a path chain parser.

[0095] The tree-structured directory manager is used to maintain the creation, renaming, deletion, and hierarchical relationships of resource folders. It uses parent node references as its basic storage structure. Parent node references are a common method of representing tree structures, implementing hierarchical relationships by storing a unique identifier of its parent node in each child node. For example, in a database, each directory record can contain a field pointing to its parent directory record. In addition to parent node references, a path enumeration model can also be used, where each node stores its complete path string from the root node to itself, such as " / root directory / first-level directory / second-level directory".

[0096] The nested collection engine is used to maintain a tree-like directory query structure using left and right values, supporting the addition, deletion, and movement of nodes, as well as subtree asset counting. The nested collection model is an efficient method for storing and querying tree structures, representing the range of each node within the tree by assigning a pair of values ​​(left and right values). A node's left value is less than the left values ​​of all its child nodes, and its right value is greater than the right values ​​of all its child nodes. When adding a child node, it is typically inserted at the left value position of the parent node, and the left and right values ​​of all affected nodes are updated accordingly. When deleting a node, the specified node and its subtree are removed, and the left and right values ​​of the entire table are shrunk. Moving nodes can be achieved by first deleting and then inserting, or through a more complex left and right value update algorithm. By querying the range of left and right values, the total amount of assets under any subtree can be quickly calculated.

[0097] In addition to the nested set model, the closure table model can also be used, which stores all ancestor-descendant relationships in an additional table, thereby enabling efficient path lookup and subtree operations.

[0098] The path chain parser recursively constructs a complete path identifier chain for each node based on the parent-child relationship of a tree-structured directory, and performs a full-selection check when parsing the directory range for push tasks. The path chain is constructed by recursively tracing upwards from the current node to its parent node, up to the root node, and connecting the identifiers of all nodes sequentially. During the full-selection check, the path chain parser compares the number of selected direct child nodes of a parent node with the total number of direct child nodes of that parent node. When the two are equal and the total number of direct child nodes is greater than zero, a full selection is determined, and the parent node's identifier is automatically added to the final identifier set. The path chain can also be pre-computed and stored in a database, or dynamically generated using a JOIN operation when needed. The full-selection check can also be performed in real-time on the front-end interface, passing the parent node identifier, instead of being performed during back-end parsing.

[0099] This embodiment establishes a basic hierarchical relationship through a tree-structured directory manager, and a nested collection engine builds an efficient query structure on this basis, optimizing complex operations on the material directory (such as subtree queries and node movements). Simultaneously, the path chain parser utilizes this structure to accurately construct path identifier chains and, when parsing the directory range of the push task, intelligently identifies the user's selection intent for the entire directory through a full-selection detection mechanism.

[0100] The cross-platform push engine includes: The Task Manager is used to manage the lifecycle of push tasks, asynchronously receive push requests through a message queue, create execution plans, and track progress. Rule filters are used to automatically filter out non-compliant materials according to the material format rules of the target platform; The deduplication checker is used to ensure that the same creative is not pushed to the same advertiser repeatedly through dual verification of the related table and push log; The concurrent push unit is used to push verified materials to the target platform and update the push log and related records; The frequency control current limiter uses a millisecond-level sliding window to protect the frequency control of application interface calls on various platforms. The sliding window records the millisecond request count based on the time slice array and compresses expired time slices using a dynamic header pointer.

[0101] This embodiment's cross-platform push engine achieves comprehensive management and optimization of cross-platform push tasks for advertising creatives through refined module collaboration. Upon receiving a cross-platform push task, the task manager intervenes first, receiving and parsing the push request, creating a detailed execution plan based on the request content, and tracking the progress of the entire push process in real time. Subsequently, the list of creatives to be pushed enters a rule filter. This filter performs strict compliance checks on the creatives based on preset format rules for each target platform, automatically removing non-compliant creatives to ensure that only high-quality creatives that meet platform requirements can enter the subsequent process. Creatives that have passed the rule filter are further processed by a deduplication checker. The deduplication checker performs double verification by querying the association table between the creative and the media-side resource identifier and detailed push logs to ensure that the same creative is not repeatedly pushed to the same advertiser or the same platform, thereby avoiding resource waste and potential conflicts. For creatives that pass all verifications, the concurrent push unit is responsible for efficiently pushing them to the designated target platform. During this process, the concurrent push unit does not initiate requests indefinitely but works closely with the frequency control and rate limiter. The frequency control rate limiter employs a millisecond-level sliding window mechanism to precisely monitor and control the call frequency to the application interfaces of various platforms, effectively preventing the platform's rate limiting policy from being triggered due to request overload, thus ensuring the stability and success rate of push notifications. Finally, after completing the material push, the concurrent push unit promptly updates the push logs and the association between the material and the platform, forming a complete closed loop. Through this collaborative working mode, this cross-platform push engine can significantly improve the efficiency, accuracy, and stability of material push notifications, effectively solving the challenges faced in material push management in a complex and ever-changing multi-channel advertising environment.

[0102] Through the above technical solutions, the cross-platform push engine in this embodiment effectively addresses many challenges encountered in the process of pushing advertising creatives across multiple channels. The task manager ensures the orderly reception, plan generation, and progress tracking of push tasks, significantly improving the efficiency and transparency of task management. The rule filter automatically identifies and removes creatives that do not conform to the target platform's specifications, thereby reducing push failures and manual review costs caused by non-compliant creatives and improving the quality of creative delivery. The deduplication checker, through a dual verification mechanism, effectively avoids duplicate pushes of the same creative, saving system resources and preventing data redundancy on the advertiser's side. The collaborative work of the concurrent push unit and the frequency control limiter not only ensures efficient parallel processing capabilities for creative pushes but also, through precise control of millisecond-level sliding windows, strictly adheres to the call frequency limits of each advertising platform's application programming interface, greatly reducing the risk of push failures due to exceeding limits and ensuring the stability and reliability of the push process. Overall, this solution significantly improves the automation level, accuracy, efficiency, and stability of cross-platform creative pushes, providing a more reliable technical guarantee for advertising delivery.

[0103] The above description is merely an embodiment of the present invention and is not intended to limit the scope of protection of the present invention. For those skilled in the art, the present invention can have various modifications and variations. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for multi-channel advertising material data aggregation and cross-platform intelligent push, characterized in that, Includes the following steps: Step A: Establish an indicator registration center, which maintains an indicator function mapping table and divides indicators into atomic indicators and aggregate indicators; The atomic metrics are obtained from the data source through direct query functions, and the aggregated metrics are calculated by calculation functions that depend on the preceding atomic metrics. Step B: In response to the user's query request containing dimension combinations and indicator lists, obtain the set of query functions corresponding to the indicator list from the indicator registry center, execute each query function in the set of query functions in parallel, and obtain atomic indicator data from multiple data sources; Step C: Generate a unique identifier for the value of each field in the dimension combination, and merge the query results from different data sources according to the unique identifier to form an aligned atomic dataset; Step D: Calculate the aligned atomic dataset according to the calculation function of the aggregation index to generate a final result set containing the aggregation index; Step E: Receive a cross-platform push task, wherein the push task includes the target platform identifier and the range of material catalogs; Step F: Maintain the tree-like directory structure of the materials based on the nested set model; Step G: When parsing the range of the material directory, obtain the identifier set of the user-selected node through path chain mapping, and perform a full selection detection: if all direct child nodes of the parent node are selected, the parent node is automatically added to the identifier set to obtain the final folder identifier set; Step H: Obtain the list of materials to be pushed according to the final folder identifier set, and filter the list of materials to be pushed according to the material format rules corresponding to the target platform identifier to remove non-compliant materials; Step 1: Perform dual deduplication verification using the associated table and push logs to filter out successfully pushed content; Step J: Push the verified materials to the target platform and update the push log and the association between the materials and the platform.

2. The method according to claim 1, characterized in that, The atomic metrics in step A include impressions, clicks, spending, and registrations obtained directly from data sources on various advertising platforms; the aggregate metrics include registration cost and return on investment (ROI), where registration cost is calculated based on spending and registrations, and ROI is calculated based on advertising revenue and spending; in step B, when executing each query function in parallel, concurrency is controlled using a token bucket approach, where a query function obtains a token before execution and returns the token after completion.

3. The method according to claim 1, characterized in that, Step D also includes: fingerprinting the final result set of the aggregate query, directly returning the cached result for requests with the same query conditions; and short-term caching of the detection results of the media date directory.

4. The method according to claim 1, characterized in that, The cross-platform push task mentioned in step E is managed using a three-layer model, including a main task, an execution plan, and a push log. The main task records the overall push information, the execution plan records the progress of a single execution, and the push log records the push status of each material.

5. The method according to claim 1, characterized in that, In step F, the nested set model represents each directory node with left and right values, and supports the following operations: when adding a child node, insert and update the left and right values ​​of the entire table at the left value position of the parent node; when deleting a node, remove the specified node and its subtree and shrink the left and right values ​​of the entire table. When moving nodes, delete first and then add to achieve cross-level movement; query the total amount of materials under any subtree by querying the range of left and right values; It also includes: when the material is first added to the database or about to be deployed to the target platform, extracting the metadata features of the material, inputting the features into a pre-trained machine learning model, predicting the performance indicators of the material during the cold start phase on the target platform, and comparing the prediction results with the platform's historical benchmarks to generate an initial performance prediction report; when the material catalog is added, deleted, or moved, the catalog change event is asynchronously propagated through a message queue to trigger the synchronous update of the nested set model.

6. The method according to claim 1, characterized in that, The "select all" detection in step G is achieved by comparing the number of selected direct child nodes of the parent node with the total number of direct child nodes; when the two are equal and the total number of direct child nodes is greater than zero, it is determined that all are selected, and the parent node identifier is added to the identifier set.

7. The method according to claim 1, characterized in that, Step H also includes: periodically pulling the list of creative materials and daily performance data according to the open application interfaces of each advertising platform through scheduled tasks, and uniformly writing them into the wide table of the columnar storage database; when new creative materials are added to the database, automatically checking whether the corresponding media date directory exists, and if not, creating it and triggering the synchronization of the nested collection model.

8. The method according to claim 1, characterized in that, The association table mentioned in step I records the correspondence between the material and the media-side resource identifier, and the push log records the combination of the material identifier, target platform identifier, and advertiser identifier that have been successfully pushed; during the double deduplication verification, if there is already a corresponding relationship in the association table or there is a successful record in the push log, it is determined that the material has been pushed and is filtered out.

9. The method according to claim 1, characterized in that, In step J, when pushing materials to the target platform, a millisecond-level sliding window is used to protect the application interface calls by frequency control. The sliding window records the count of each millisecond request based on the time slice array, compresses expired time slices through dynamic header pointers, and merges the counts of requests with the same timestamp.

10. A multi-channel advertising material data aggregation and cross-platform intelligent push system, characterized in that, include: The data aggregation engine is configured to perform steps A to D as described in claim 1; The material catalog management module is configured to execute steps F to G as described in claim 1; A cross-platform push engine is configured to perform steps E, H to J as described in claim 1.