A mobile advertisement cross-channel batch creation method and system

Abstract

This invention relates to a method and system for cross-channel batch creation of mobile advertisements, belonging to the field of mobile advertising delivery technology. It includes: a configuration orchestration layer for receiving configuration information input by users on different media pages and converting the configuration information into a unified configuration object; a preview matrix layer for calculating the number of projects, advertisements, and creatives to be created based on the unified configuration object before task submission, and generating a hierarchical submission matrix; and a task access layer for storing main task information, submission methods, and complete creation parameters. This invention converts configuration information from different media platforms into a unified configuration object through a configuration orchestration layer, and converts the unified configuration object into request parameters corresponding to each media platform through a media adaptation layer. This allows the main batch creation process to be reused across media, eliminating the need to develop independent batch creation processes for different media, thus reducing system complexity and development and maintenance costs.

Description

Technical Field

[0001] This invention relates to the field of mobile advertising technology, and in particular to a method and system for creating mobile advertisements in bulk across channels. Background Technology

[0002] Mobile advertising campaigns are typically not created as single objects, but rather as a combination of objects such as accounts, projects, ad units, creatives, assets, conversion goals, landing pages, titles, components, budgets, bids, and campaign durations. Different advertising media have inconsistent naming conventions, fields, validation rules, asset upload methods, and failure return formats for these objects, often forcing existing systems to implement batch creation logic separately for each media.

[0003] The core problem with existing technologies is not whether ads can be submitted, but the lack of a reusable cross-media technology chain: the front end cannot standardize multimedia configurations into a unified task object, the back end cannot automatically fill in media material identifiers after the material upload results are returned, asynchronous tasks cannot accurately express the state relationship of the three-layer objects of project, ad, and creative, and it is difficult to determine whether to retry, skip, mark failure, or reverse process the created parent object after failure.

[0004] Similar issues exist with managed optimization after ad creation. Fixed threshold alerts can only detect abnormal metrics, but cannot connect report queries, media status queries, rule judgments, comprehensive analysis of large models, and action execution into a closed loop. Therefore, it is difficult to achieve automatic shutdown, price adjustment, budget adjustment, and notification tracking. Summary of the Invention

[0005] The purpose of this invention is to overcome the shortcomings of the above-mentioned background technology and provide a method and system for cross-channel batch creation of mobile advertisements.

[0006] To achieve the above objectives, the present invention provides a cross-channel batch creation system for mobile advertisements, comprising:

[0007] The configuration orchestration layer is used to receive configuration information input by users on different media pages and convert the configuration information into a unified configuration object;

[0008] The preview matrix layer is used to calculate the number of projects, advertisements, and creatives to be created based on the unified configuration object before the task is submitted, and to generate a hierarchical submission matrix.

[0009] The task access layer is used to store the main task information, submission method, and complete creation parameters;

[0010] The media processing layer is used to perform media upload operations and establish a mapping relationship between local media identifiers and media-side media identifiers;

[0011] The media adaptation layer is used to convert unified task parameters into request parameters corresponding to the target media and call the interfaces of each media platform to perform the creation operation;

[0012] An asynchronous scheduling layer is used to execute creation tasks according to a preset dependency order;

[0013] The status backfill layer is used to track the execution progress of each level and write the execution results and error information into the task log.

[0014] The intelligent hosting layer is used to perform automated optimization operations on the target audience after the advertisement is delivered;

[0015] The audit notification layer is used to save operation history and send notifications to users.

[0016] As a preferred embodiment of the present invention, the smart hosting layer includes:

[0017] The rule engine's initial screening unit is used to deterministically screen the targets based on preset managed objects, basic indicator conditions, and action whitelists, and determine whether to enter the large model's decision-making process.

[0018] The large model decision agent is used to organize contextual information, call tools to supplement query data, and generate a structured action list based on multi-source evidence after the rule engine's initial screening unit determines that a match has been found.

[0019] The MCP tool layer is used to provide data query interfaces and action planning interfaces to the large model decision agent. The data query interfaces include report queries, media status queries, budget queries, conversion queries, and historical action queries. The action planning interface is used to convert the intent of the large model into standard action drafts.

[0020] An action executor is used to perform boundary checks on each action in the action list and execute the actions that pass the checks.

[0021] The history record unit is used to save triggering conditions, large model judgment criteria, tool call trajectory, action list, and execution results.

[0022] As a preferred embodiment of the present invention, the media adaptation layer implements a unified set of method signatures for each advertising media. The set of method signatures includes parameter generation methods, project creation methods, advertisement creation methods, creative creation methods, material upload methods, object deletion methods, error formatting methods, and result standardization methods. The asynchronous scheduling layer only relies on the unified method signatures to call each media adapter and does not directly perceive the differences in media interfaces.

[0023] As a preferred embodiment of the present invention, the asynchronous scheduling layer executes the creation tasks in the dependent order of material uploading, project creation, advertisement creation, and creative creation; the main task maintains the number of submissions, completions, and successes at the project level, the number of submissions, completions, and successes at the advertisement level, and the number of submissions, completions, and successes at the creative level; after each subtask is completed, the number of completions and successes are incremented according to the corresponding object level.

[0024] On the other hand, the present invention also provides a method for cross-channel batch creation of mobile advertisements, including the following steps:

[0025] Standardized configuration

[0026] It receives account configuration, project configuration, ad configuration, creative configuration, material configuration, title configuration, landing page configuration, conversion configuration, targeting configuration, budget configuration, and bid configuration from multiple advertising media, and splits the configuration into common fields and media extended fields to generate a unified configuration object;

[0027] Submission matrix generation

[0028] Based on the account set, material allocation rules, and ad hierarchy, a project submission matrix, an ad submission matrix, and a creative submission matrix are generated. Each row in the matrix contains a parent object reference, media type, account identifier, material placeholder, and fields to be filled back.

[0029] Preview Verification

[0030] Before the formal creation, the number of project submissions, ad submissions, creative submissions, number of creative groups, and number of creatives are calculated based on the submission matrix, and the required field validation, creative integrity validation, account authorization validation, media field conflict validation, delivery time validation, and budget boundary validation are performed.

[0031] Material Upload and Feedback

[0032] Upload materials by calling the media material interface at the account level, obtain the media-side material identifier, write the mapping between the local material identifier and the media-side material identifier into the cache and task details, and replace the material placeholders in the submission matrix with the media-side material identifier before creating a project, advertisement or creative.

[0033] Task scheduling and execution

[0034] The creation tasks are executed asynchronously according to the dependency order of material upload, project creation, ad creation, and creative creation. After each level of subtask is completed, the number of submissions, completions, and successes are updated according to the corresponding object level.

[0035] Status backfilling

[0036] When all lower-level objects fail to be created, the upper-level object is triggered to perform reverse processing operations, and the reason for the failure is written into the corresponding task details.

[0037] As a preferred embodiment of the present invention, in the task scheduling and execution steps, a scheduling strategy is selected according to the submission method: when the submission method is immediate submission, the main task is delivered and executed asynchronously immediately after creation; when the submission method is timed submission, the planned trigger time is recorded and the timed scheduler delivers and executes the task at the planned trigger time; when the submission method is batch submission, the submission matrix is ​​split into multiple batch tasks according to the batch quantity and submission interval, and each batch task is executed independently.

[0038] As a preferred embodiment of the present invention, the reverse processing operation includes: when all creative rows under an advertisement cannot be created, marking the advertisement as failed or skipped; when all advertisements under an item cannot be created, performing deletion, pause, archive, or marking as abnormal operations on the created items according to the capabilities of the media adapter.

[0039] As a preferred embodiment of the present invention, in the material uploading and backfilling steps, each material uploading task includes a task identifier, media type, account identifier, local material identifier, material type, upload parameters, and retry information; when all materials under the same advertising account fail to upload, the creative row that depends on that material is marked as uncreationable.

[0040] As a preferred embodiment of the present invention, a smart hosting step is also included:

[0041] Initial screening of rules

[0042] The set of managed objects is parsed according to the preset managed rules, basic indicator data is retrieved, and it is determined whether each managed object meets the preset basic indicator conditions. The managed rules include managed object type, basic indicator conditions, inspection frequency, do-not-disturb period, action whitelist and notification method.

[0043] Large Model Decision

[0044] When the managed object meets the basic indicator conditions, the rule snapshot, object snapshot, indicator window data, available tool list, historical action record and execution strategy are assembled into prompt words and sent to the large model decision agent; the large model decision agent calls the MCP tool to supplement the query data according to the prompt words, and generates a structured action list based on the evidence returned by the tool;

[0045] Action verification and execution

[0046] Perform permission verification, idempotency verification, budget bid boundary verification, and do-not-disturb policy verification on each action in the action list, and execute the actions that pass the verification.

[0047] Record

[0048] Save the snapshot of the rules triggered this time, the basis for the large model's judgment, the tool call trajectory, the action list, and the execution results.

[0049] As a preferred embodiment of the present invention, in the large model decision-making step, the prompt words have a four-layer structure: the system layer defines the agent role and constraints prohibiting direct execution of actions; the developer layer injects an action whitelist, a list of callable tools, output format requirements, and idempotency rules; the user layer injects the current rule screening results, object snapshots, indicator window data, historical actions, and execution strategies; the tool result layer carries the data evidence returned by the MCP tool; each action output by the large model decision agent includes an evidence reference field, which is used to bind the action with the data evidence returned by the MCP tool.

[0050] Compared with the prior art, the present invention has the following beneficial effects:

[0051] First, this invention converts configuration information from different media platforms into a unified configuration object by setting a configuration orchestration layer, and converts the unified configuration object into request parameters corresponding to each media platform by a media adaptation layer. This enables the batch creation and editing main process to be reused across media, eliminating the need to develop independent batch creation and editing processes for different media, thus reducing system complexity and development and maintenance costs.

[0052] Secondly, this invention uses a material upload and backfilling mechanism to treat material upload as an independent pre-processing task. After a successful upload, a mapping relationship is established between local material identifiers and media material identifiers. Material placeholders are batch-replaced with media material identifiers before ad or creative creation, solving the technical problem of the disconnect between material upload and ad creation parameters. At the same time, by tracing the reasons for material upload failures back to specific accounts, material combinations, and creative combinations, and blocking the creation of creatives that depend on those materials when all material uploads fail, this avoids creating ad objects lacking effective materials, reducing ineffective ad creation operations and resource waste.

[0053] Third, this invention maintains the number of submissions, completions, and successes at three levels: project, advertisement, and creative, through a hierarchical asynchronous task scheduling and hierarchical counting mechanism. This allows for fine-grained tracking of the execution progress, success rate, and reasons for failure of batch creation tasks at each level. Users can quickly locate the specific objects and reasons for creation failures without having to investigate them one by one.

[0054] Fourth, this invention, through the mechanism of triggering reverse processing of the superior object when all subordinate objects fail, can automatically perform operations such as deletion, pause, archiving or marking as abnormal on created empty projects or empty ad groups, reducing the number of invalid objects left in the delivery structure and avoiding invalid objects occupying delivery quotas and interfering with subsequent delivery strategies.

[0055] Fifth, this invention utilizes an intelligent managed architecture consisting of a rule engine for initial screening, a large-scale model decision agent, an MCP tool layer, and an action executor to create a closed loop encompassing basic rule filtering, complex multi-indicator comprehensive decision-making, evidence retrieval, and action implementation. The rule engine is only responsible for deterministic screening and boundary constraints; the final decision is generated by the large-scale model with the support of multi-source data evidence provided by the MCP tool. This overcomes the technical shortcomings of fixed rule thresholds in handling multi-indicator joint decision-making scenarios, effectively reducing the probability of misjudgments and missed judgments. Attached Figure Description

[0056] Figure 1 This is a system architecture diagram of the present invention;

[0057] Figure 2 This is a flowchart illustrating the batch creation and execution process of this invention. Detailed Implementation

[0058] It should be noted that, unless otherwise specified, the embodiments and features described in this embodiment can be combined with each other. 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 a part of the embodiments of the present invention, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0059] To make the technical objectives, solutions, and effects of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are merely illustrative and do not constitute a limitation on the scope of protection of this invention.

[0060] like Figure 1 and Figure 2 As shown, this embodiment provides a cross-channel batch creation system for mobile advertising. Its overall architecture consists of nine functional layers: configuration and orchestration layer, preview matrix layer, task access layer, material processing layer, media adaptation layer, asynchronous scheduling layer, status backfilling layer, intelligent hosting layer, and audit notification layer. The system adopts a front-end / back-end separation architecture. The front-end is responsible for configuration input, preview display, and task submission, while the back-end is responsible for task scheduling, media interface calls, and status management.

[0061] The specific functions of each functional layer are explained in detail below.

[0062] The configuration orchestration layer is responsible for receiving configuration information input by users on different media pages and converting this information into a unified configuration object. In practical applications, users may need to create advertising campaigns on different media platforms such as ByteDance Ads, Tencent Ads, Kuaishou Ads, OPPO Ads, and Bilibili Ads. Although each media platform provides similar advertising functions, their data structures, field naming, and business rules differ. The role of the configuration orchestration layer is to unify these configuration inputs from different media pages, shield the underlying differences, and provide a consistent configuration data interface for the upper-layer processes. Specifically, the configuration orchestration layer splits the configuration information input by users into two parts: common fields and media extended fields. The common fields are used for unified cross-media processing, while the media extended fields retain the configuration information specific to each media, which is then interpreted by the subsequent media adaptation layer during the execution phase.

[0063] The preview matrix layer is responsible for calculating the number of projects, ads, and creatives to be created based on the unified configuration object generated by the configuration orchestration layer before the task is officially submitted, and generating a hierarchical submission matrix. The main functions of the preview matrix layer include two aspects: first, displaying the complete structure of the ad to be created to the user, allowing them to confirm the accuracy and completeness of the configuration before submission; second, performing various checks before submission, including required field checks, creative integrity checks, account authorization checks, media field conflict checks, delivery time checks, and budget boundary checks. After successful checks, the preview matrix layer serializes the submission matrix into task parameters; when the parameter size is large, the system writes the complete parameters to external storage and saves the reference address in the main task to avoid message queue or database transmission bottlenecks caused by excessively large parameter sizes.

[0064] The task access layer is responsible for storing the main task information, submission method, and complete creation parameters. The main task is the core record carrier of the entire batch creation process, storing the complete configuration submitted by the user, submission method, task status, and count information at each level. After receiving the submission matrix from the preview matrix layer, the task access layer creates a main task record and executes the corresponding scheduling logic according to the different submission methods; submission methods include immediate submission, timed submission, and batch submission.

[0065] The content processing layer is responsible for executing content upload operations and establishing a mapping between local content identifiers and media-side content identifiers. The core design philosophy of the content processing layer is to decouple content uploads from ad creation. Specifically, instead of directly writing local content paths into ad creation requests, the layer first generates independent content upload tasks. Each upload task includes a task identifier, media type, account identifier, local content identifier, content type, upload parameters, and retry information. The content processing layer calls the content upload interfaces of each media platform at the account level. Upon successful upload, it obtains the content identifier returned by the media side and writes the mappings of the task identifier, account identifier, local content identifier, and media content identifier into the cache and task details. In subsequent project, ad, or creative creation processes, the system scans the content placeholders in the submission matrix and replaces the local identifiers of images, videos, covers, image sets, components, etc., with the content identifiers returned by the media.

[0066] The media adaptation layer is responsible for converting unified task parameters into request parameters corresponding to the target media and calling the interfaces of each media platform to perform creation operations. The media adaptation layer implements a unified set of method signatures for each advertising media, including methods for parameter generation, project creation, ad creation, creative creation, material upload, object deletion, error formatting, and result standardization. The task scheduling layer only relies on the unified method signatures to call each media adapter and does not directly perceive the differences in media interfaces. The input to the media adapter is a standard configuration object, media extended fields, account authorization information, and the creation result of the parent object; the output is a standard execution result, including success or failure, media object identifier, error code, error message, original request summary, and original response summary. Through this standard output, the status backfilling layer can use the same logic to process the results returned by different media. When adding new media, only the new media adapter needs to be implemented and the media type registered; there is no need to modify the main task model, material upload process, hierarchical counting logic, and smart hosting rule structure.

[0067] The adapter's inputs include: a standard configuration object containing common fields, media extension fields containing media-specific configuration information, account authorization information, and the parent object creation result.

[0068] The adapter's output is a standard execution result, including: a boolean value indicating success or failure, a media object identifier, an error code, an error message, a summary of the original request, and a summary of the original response. This standard execution result allows the state backfilling layer to process results returned by different media using the same logic, eliminating the need to write separate state update logic for each media.

[0069] In its implementation, the adapter's parameter generation method is responsible for converting the unified configuration object and media extension fields into the request parameter format required by the target media API. Different media APIs have significantly different parameter structures; for example, some media use flat parameter structures, while others use nested structures; some media require camelCase parameter names, while others require underscore naming. The adapter's parameter generation method handles these differences.

[0070] The adapter's project creation, ad creation, and creative creation methods are responsible for calling the corresponding API interfaces of the target media and processing the returned results. The adapter's material upload method is responsible for calling the target media's material upload interface and handling special logic such as file format conversion and chunked upload.

[0071] When adding new media, only a new media adapter needs to be implemented and the media type registered in the system; there is no need to modify the main task model, material upload process, hierarchical counting logic, or smart hosting rule structure. This design gives the system good scalability and allows it to flexibly support new advertising media platforms.

[0072] The asynchronous scheduling layer is responsible for executing creation tasks according to a preset dependency order. In batch creation scenarios, there are strict hierarchical dependencies between projects, ads, and creatives: projects must be created first before ads can be created under that project; ads must be created first before creatives can be created under that ad. Furthermore, asset uploading, as an independent preprocessing step, needs to be completed before ad or creative creation. Therefore, the asynchronous scheduling layer executes creation tasks in the dependency order of asset uploading, project creation, ad creation, and creative creation. The asynchronous scheduling layer also selects different scheduling strategies based on the task submission method: for immediate submission, the main task is delivered asynchronously immediately after creation; for scheduled submission, the system records the planned trigger time and the scheduled scheduler delivers the task at the planned trigger time; for batch submission, the system splits the submission matrix into multiple batch tasks based on the batch size and submission interval, with each batch task executing independently.

[0073] The status backfilling layer is responsible for tracking the execution progress of each level and writing the execution results and error information to the task log. The status backfilling layer uses a hierarchical counting update method, rather than simply using a single success or failure flag. The main task maintains multi-dimensional counts, including project submissions, project completions, project successes, ad submissions, ad completions, ad successes, creative submissions, creative completions, and creative successes. After a subtask is completed, the completion and success counts are incremented according to the corresponding object hierarchy, and the main task is judged to have entered the completion state based on the completion and submission counts. When media returns a failure, the status backfilling layer records the failed object, failure stage, failure reason, and original error summary. If all lower-level objects fail, the status backfilling layer triggers reverse processing operations such as deletion, pause, archiving, or marking an exception, based on the media adapter's capabilities.

[0074] The intelligent hosting layer is responsible for performing automated optimization operations on the target audience after ad delivery. The intelligent hosting layer consists of a rule engine initial screening unit, a large-scale model decision agent, an MCP tool layer, an action executor, and a history recording unit. The rule engine initial screening unit is responsible for deterministic screening, including the hosting target, basic indicator conditions, check frequency, do-not-disturb periods, action whitelist, and notification method; this unit only determines whether a particular hosting target enters the large-scale model decision process, without directly providing the final delivery action. The large-scale model decision agent is responsible for organizing the context, calling tools, summarizing multi-source evidence, and generating a structured action list after the initial screening is successful. The MCP tool layer provides interfaces for report queries, media status queries, budget queries, conversion queries, historical action queries, and action candidate generation. The action executor is responsible for implementing the verified actions to the media target or notification channel. The history recording unit is responsible for saving trigger conditions, large-scale model judgment criteria, tool call history, action list, and execution results.

[0075] The following provides a detailed explanation of the rule engine's initial screening unit, the large model decision agent, the MCP tool layer, the action executor, and the history record unit:

[0076] Rule Engine Initial Screening Unit

[0077] The rule engine's initial screening unit is responsible for deterministic screening, including the managed object, basic indicator conditions, inspection frequency, do-not-disturb periods, action whitelist, and notification method. This unit only determines whether a particular managed object enters the large model's decision-making process, without directly providing the final deployment action.

[0078] When a rule is executed, the system first parses the account, project, ad, or creative collection based on the managed objective. For example, when the objective type of the rule is "ad account," the system parses all projects under that account; when the objective type is "project," the system parses all ads under that project; and when the objective type is "ad," the system directly processes the specified ad collection.

[0079] The system executes the rules periodically according to the configured check frequency. The check frequency can be configured by the user, such as every 15 minutes, every hour, every day, or a custom interval. Scheduled tasks are managed uniformly by the Celery Beat scheduler.

[0080] The system retrieves basic metric data and performs initial screening. Basic metric data includes spending, conversions, cost per conversion, click-through rate, and impressions. Basic metric conditions are configured by the user when creating rules, for example, "trigger when spending is greater than X yuan and cost per conversion is greater than Y yuan". Conditional expressions support combinations of logical operators such as AND, OR, and NOT.

[0081] If the basic conditions are met, the system sends a rule snapshot, object snapshot, indicator window data, a list of available tools, historical actions, and execution strategies to the large model decision agent. The rule snapshot records the complete configuration of the current rule; the object snapshot records basic information about the managed object, such as object type, object ID, and current status; the indicator window data records the indicator change trend over a recent period; the list of available tools lists the MCP tools that the large model decision agent can call; historical actions record the managed actions previously executed for this object; and the execution strategy defines the constraints for action execution, such as whether shutdown or price adjustment is allowed.

[0082] Large Model Decision Agent

[0083] The large model decision agent is responsible for organizing the context, calling tools, summarizing multi-source evidence, and generating a structured action list after the initial screening.

[0084] After receiving context information from the rule engine's initial screening unit, the large model decision agent first assembles prompt words. The prompt words employ a four-layer structure:

[0085] The system-level fixed agent role is "ad hosting decision agent," defining compliance boundaries and the principle of "only outputting structured actions, not directly executing them." System-level prompts ensure that the large model always answers questions as a hosting decision assistant and cannot bypass the system to directly execute any operations.

[0086] The developer layer constrains the available MCP tools, action whitelist, risk levels, idempotency requirements, and outputs. Developer-level prompts define the list of tools the model can use in this dialogue, the allowed action types, the risk level classification criteria, the rules for generating idempotent keys, and the output format requirements.

[0087] The user layer injects the initial rule screening results, managed object snapshots, indicator window data, historical actions, and execution strategies. User-layer prompts contain all the contextual information needed for the current decision, enabling the model to make judgments based on the latest data.

[0088] The tool results layer summarizes the data returned by the MCP tool and requires the model to associate each action with a piece of evidence. The tool results layer prompts contain the structured data returned by the MCP tool query; the model needs to generate actions based on this data evidence and reference the corresponding evidence in each output action.

[0089] The large model decision agent supplements the MCP tool layer with segmented query report data, media status, budget consumption, conversion quality, historical actions, and performance of similar objects through tool invocation. The model can invoke different MCP tools multiple times as needed, and each tool invocation returns results with an evidence reference key for the model to reference when outputting actions.

[0090] The large model decision agent outputs a structured list of actions without directly modifying the advertising object. Each action contains at least the following fields: action type, target object, execution parameters, reason for belief, evidence citation, risk level, and idempotent key.

[0091] MCP tool layer

[0092] The MCP tool layer is not a simple data forwarding layer, but a controlled collection of tools for the large model decision agent. Each tool declares its purpose, input parameters, returned evidence fields, and invocation boundaries. The model can only generate actions based on the structured evidence returned by the tools and cannot bypass the action executor to directly modify media objects.

[0093] The tools provided by the MCP tool layer include the following categories:

[0094] Data query tools include: report query tool, used to obtain delivery report data for a specified object within a specified time window; media status query tool, used to obtain the current status of an object on the media side; budget query tool, used to obtain the budget configuration and consumption status of an object; conversion query tool, used to obtain conversion tracking configuration and conversion data; and historical action query tool, used to read recent action memories within the same rule, the same object, and the same metric window.

[0095] Action planning tools include: a pause planning tool, used to convert the pause intention of a large model into a standard pause action draft; a budget adjustment planning tool, used to convert the budget adjustment intention of a large model into a standard budget adjustment draft and calculate the budget value before and after the adjustment; a bid adjustment planning tool, used to convert the bid adjustment intention of a large model into a standard bid adjustment draft and calculate the bid value before and after the adjustment; and a notification planning tool, used to convert the notification intention of a large model into a standard notification draft.

[0096] The action planning tool is only responsible for converting the intent of the large model into a standard action draft, completing the action type, target type, target ID, parameters, rationale, evidence citation, risk level, and idempotency key; it does not directly call the media modification interface. The actual media writing operation is completed by the action executor.

[0097] Action actuator

[0098] The action executor is responsible for implementing the validated actions onto media objects or notification channels. The action executor needs to perform multiple validations before executing an action.

[0099] Permission verification: The action executor verifies whether the current operator or system has the authority to perform the action on the media object. Permission verification is based on account authorization information and an action whitelist.

[0100] Idempotency check: The action executor checks whether the idempotency key already exists in the execution record. If an action with the same idempotency key has already been executed within the specified time, the current execution is skipped to avoid duplicate operations. The period of idempotency check is controlled by the cooldown time parameter.

[0101] Budget boundary verification: Before executing a budget adjustment, the action executor checks whether the adjusted budget is lower than the media's minimum budget, exceeds the maximum budget allowed by the rules, exceeds the account or project budget limit, exceeds the maximum adjustment ratio for this instance, and conflicts with the currently consumed amount. For example, if the currently consumed amount has already exceeded the adjusted budget, the budget adjustment action should not be executed, otherwise it will cause the budget to be exhausted immediately.

[0102] Bid boundary verification: Before executing a bid adjustment, the action executor checks whether the current bid method supports adjustment. For example, some media do not allow modification of the bid method for ads that have already been placed. It also checks whether the adjusted bid falls between the media's minimum and maximum bids, whether the single adjustment ratio exceeds the risk control threshold, whether it is within the cooldown period, and whether it will fluctuate back and forth with recent historical actions, such as repeatedly raising and lowering the bid in a short period of time.

[0103] Do Not Disturb Policy Verification: The action executor checks whether the current time falls within the do not disturb period configured in the rules. If it does, non-urgent actions are delayed, while urgent actions can be configured to execute but send a notification.

[0104] When the large model outputs a risk level of "high", the executor marks the action as pending review or converts it into a notification, generates a notification or confirmation task, and writes the high-risk reason, evidence reference, and recommended action; the media action will only continue to be executed after the execution strategy explicitly allows it and it has been manually confirmed or approved.

[0105] After the action executor completes its execution, it writes the execution result to the execution record and updates the historical action table.

[0106] Historical Records Unit

[0107] The history record unit is responsible for saving triggering conditions, the basis for the large model's judgment, tool call history, action list, and execution results. The information recorded by the history record unit includes: a complete snapshot of the rule triggered this time, basic indicator data of the initial hits, prompt words sent to the large model, request and response summaries for each tool call by the large model, a structured action list output by the large model, and the verification and execution results of the action executor.

[0108] These historical records are used for subsequent auditing, rule effectiveness analysis, and model tuning. Users can view the complete record of each trigger through the AI ​​hosting page to understand what evidence the large model used to make what decisions, and the results of those decisions.

[0109] The audit notification layer is responsible for storing operation history records and sending notifications to users. Operation history records include configuration change history, task execution history, media operation history, and smart hosting trigger history. Notification methods include in-site messages, emails, SMS messages, and webhooks.

[0110] The front-end architecture of this invention is mainly composed of the following:

[0111] The main front-end application uses the Vue 3 framework, with Vue Router for route management, Pinia for state management, Element Plus as the UI component library, and Vite as the build tool. Front-end routing uses a hash-based model. Batch-created routes are uniformly mounted under the batch-created parent route, with child routes split according to media type, including pages for ByteDance Ads, Tencent Ads, Kuaishou Ads, OPPO Ads, Bilibili Ads, etc. AI-powered intelligent managed routes are mounted under the management module, containing sub-pages for managed rules management, execution records, and trigger records.

[0112] The batch creation page consists of a configuration area, a materials area, a title area, a landing page area, a conversion area, a preview area, and a task submission pop-up. The configuration area maintains the current configuration and the baseline configuration, used to identify modified items, strategy group reuse, and task reuse. The preview area expands the configuration into a matrix view at the account, project, ad, and creative levels, and uploads the large JSON file to object storage before submitting it to the backend. The task submission pop-up allows users to choose the submission method and configure the corresponding submission parameters.

[0113] The AI-hosted page consists of a rule list, a rule creation drawer, rule details, a target object pop-up, execution records, and trigger records. The rule creation drawer generates structured parameters such as media type, hosted object type, metric conditions, check frequency, execution actions, sending method, and do-not-disturb time. In the rule creation interface, users can configure hosted objects, basic metric conditions, check frequency, execution action whitelist, and do-not-disturb time periods. Hosted objects can include specific advertising accounts, projects, ad sets, or creative collections. Basic metric conditions include spend thresholds, conversion cost thresholds, and click-through rate thresholds. Check frequency can be set to hourly, daily, or custom intervals. Execution action whitelists include shutdown, price adjustment, budget adjustment, and sending notifications.

[0114] The backend architecture of this invention mainly consists of the following components:

[0115] The backend uses the Django framework. Requests enter the task module through the global URL route, where the authentication layer verifies identity and permissions, and the response processing layer returns a uniformly formatted response. The batch task creation access layer creates the main task and persists its configuration, creation parameters, submission method, and hierarchical count.

[0116] The asynchronous execution layer uses Celery as a distributed task queue. The material upload task is executed first to generate media material mapping. The project creation task, ad creation task, and creative creation task are executed in the order of dependency. The task execution results are written to the task details table, and Redis is used to maintain short-cycle counters, material upload mappings, and intermediate relationship data.

[0117] The media adaptation layer selects the appropriate adapter implementation based on the media type. The task layer only relies on a unified method signature; differences in media fields are handled internally by the adapter. The adapter encapsulates the calling details of each media platform SDK, including parameter conversion, API calls, error handling, and result standardization.

[0118] This embodiment also provides a method for mass creation of mobile advertisements across channels, including the following steps:

[0119] Configuration standardization and submission matrix generation

[0120] The configuration standardization and submission matrix generation process includes the following steps.

[0121] Step S1, Receive cross-media configuration

[0122] The system receives user input on the front-end page, including media type, application type, ad account set, project basic configuration, ad basic configuration, creative basic configuration, material configuration, title configuration, landing page configuration, conversion configuration, targeting configuration, budget and bid configuration, submission method, batching parameters, and timing parameters. Fields specific to different media types are not discarded but stored in the media extended field area, preserving complete configuration information for later use.

[0123] Step S2, construct the standard configuration object

[0124] The system breaks down the user input received in step S1 into common fields and media-extended fields. Common fields are used for unified cross-media processing and include account information, object hierarchy information, media reference information, creation quantity information, scheduling method information, and basic budget bidding information. Media-extended fields are interpreted a second time by the media adapter before the actual request. Through this breakdown method, the system can both uniformly process common configuration information across media and retain the complete information of media-specific configurations.

[0125] Step S3: Generate the hierarchical submission matrix

[0126] The system first generates an account-dimensional matrix based on the account set and creative allocation rules. Then, it generates project rows based on project creation rules, ad rows based on ad creation rules, and creative rows based on the combination of titles, creatives, components, and landing pages. Each row in the matrix contains a reference to the parent object, media type, account identifier, creative placeholders, and fields to be filled. Specifically, the project row contains a reference to the account it belongs to; the ad row contains a reference to the project it belongs to; and the creative row contains a reference to the ad it belongs to and a list of creative placeholders. The creative placeholder is a temporary identifier for the local creative and will be replaced with the actual creative identifier returned by the media side after the creative is uploaded.

[0127] Step S4, perform preview verification

[0128] Before formal creation, the system calculates the number of project submissions, ad submissions, creative submissions, the number of creative groups, and the number of creatives, and displays these statistics to the user. Simultaneously, the system checks whether required fields are complete, whether creatives are missing, whether account authorization is valid, whether media fields conflict, whether the delivery time is legal, and whether the budget is within allowable limits. After successful verification, the submission matrix is ​​serialized into task parameters; when the parameter body is large, the system writes the complete parameters to object storage or equivalent external storage and saves the reference address in the main task.

[0129] Step S5: Upload materials and fill in parameters

[0130] The creative processing layer does not directly write the local creative path into the ad creation request. Instead, it first generates an independent creative upload task. Each creative upload task includes at least a task identifier, media type, account identifier, local creative identifier, creative type, upload parameters, and retry information.

[0131] The system calls the creative upload interfaces of various media platforms on an account-by-account basis. For multiple creatives under the same advertising account, they can be aggregated into a single creative upload batch to reduce the number of interface calls and improve upload efficiency. Upload parameters vary depending on the media type; for example, some media require specifying the intended use of the creative during upload, while others require specifying the creative size and format.

[0132] After successful upload, the system receives the media identifier returned by the media platform. Different media platforms use different identifier formats; some are string-type media IDs, while others are composite identifiers containing multiple pieces of information. Regardless of the format, the system stores all media identifiers uniformly as media-side media identifiers.

[0133] The system writes the mappings of "task identifier, account identifier, local material identifier, and media material identifier" to the cache and task details. Writing to the cache allows for quick lookup of material mapping relationships during subsequent project, ad, or creative creation processes; writing to the task details persists the mapping relationships so that uploaded materials can be reused when a task fails or is retried.

[0134] Before creating a project, advertisement, or creative, the system scans the placeholder materials in the submission matrix and replaces the local identifiers of images, videos, covers, image sets, components, etc., with the material identifiers returned by the media. Specifically, for each row in the submission matrix, the system iterates through the list of material placeholders in that row, queries the media material identifier corresponding to each local material identifier, and completes the replacement operation.

[0135] If all creatives under the same advertising account fail to upload, the corresponding creative rows that depend on those creatives will be marked as uncreateable. The system records the reason for the failure, including account identifier, creative identifier, error code, and error message, to help users locate the problem.

[0136] If all creative rows for an ad are unavailable for creation, the ad enters a failed or skipped state. In this case, the system will not attempt to create the ad because there are no valid creatives available to run under that ad.

[0137] If all ads under a certain project cannot be created, the system will not continue to create empty projects; for projects that have already been created, the system will perform reverse processing operations such as deletion, pausing, archiving, or marking as abnormal based on the capabilities of the media adapter, in order to avoid invalid projects occupying the delivery structure.

[0138] The technical effect of this mechanism is to limit the uncertainty of material uploads to the early stage, avoid creating ad targets that lack effective materials, and make the reasons for failure traceable to specific accounts, materials, and creative combinations, so that users can quickly locate and solve problems.

[0139] Step S6, Asynchronous Scheduling and State Machine Implementation

[0140] The system selects a scheduling strategy based on the task submission method. For immediate submission, the main task is immediately delivered to the Celery task queue for asynchronous execution after creation. For scheduled submission, the system records the planned trigger time, and the Celery Beat timer delivers the task to the queue for execution at the planned trigger time. For batch submission, the system splits the submission matrix into multiple batches based on the number of tasks in each batch and the submission interval. Each batch of tasks is delivered sequentially according to the time interval, and within each batch, the order of material upload, project creation, ad creation, and creative creation is still followed.

[0141] Task status updates use a hierarchical counting system, rather than a single success or failure flag. The main task maintains the following counts: project submissions, project completions, project successes, ad submissions, ad completions, ad successes, creative submissions, creative completions, and creative successes. These counts are initialized when the task is created and dynamically updated during subtask execution.

[0142] Specifically, after the material upload phase is completed, the system updates the creative submission count based on the upload results. During the project creation phase, the system increments the project completion count after each project is created; if creation is successful, the system also increments the project success count. During the ad creation phase, the system increments the ad completion count after each ad is created; if creation is successful, the system also increments the ad success count. During the creative creation phase, the system increments both the creative completion count and the creative success count after each creative is created.

[0143] After a subtask is completed, the system determines whether the main task has entered the completion state by comparing the number of completed tasks with the number of submitted tasks. When the number of completed tasks at a certain level equals the number of submitted tasks, it means that all objects at that level have been processed; when the number of completed tasks at all levels equals the number of submitted tasks, it means that the main task is completed as a whole.

[0144] When media returns a failure, the system records the failure object, failure stage, failure reason, and original error summary. The failure reason includes the error code returned by the media, the error description, and system-level error information. This error information is written to the task details for users to query and troubleshoot.

[0145] If all child objects fail to create, the system performs reverse processing based on the media adapter's capabilities, such as deletion, pausing, archiving, or marking as abnormal, to prevent invalid parent objects from continuing to occupy the delivery structure. For example, when all creatives under an ad fail to create, the system can delete the ad or mark it as abnormal; when all ads under an item fail to create, the system performs similar reverse processing on the already created items.

[0146] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A cross-channel batch creation system for mobile advertisements, characterized in that, include: The configuration orchestration layer is used to receive configuration information input by users on different media pages and convert the configuration information into a unified configuration object; The preview matrix layer is used to calculate the number of projects, advertisements, and creatives to be created based on the unified configuration object before the task is submitted, and to generate a hierarchical submission matrix. The task access layer is used to store the main task information, submission method, and complete creation parameters; The media processing layer is used to perform media upload operations and establish a mapping relationship between local media identifiers and media-side media identifiers; The media adaptation layer is used to convert unified task parameters into request parameters corresponding to the target media and call the interfaces of each media platform to perform the creation operation; An asynchronous scheduling layer is used to execute creation tasks according to a preset dependency order; The status backfill layer is used to track the execution progress of each level and write the execution results and error information into the task log. The intelligent hosting layer is used to perform automated optimization operations on the target audience after the advertisement is delivered; The audit notification layer is used to save operation history and send notifications to users.

2. The mobile advertising cross-channel batch creation system according to claim 1, characterized in that, The intelligent hosting layer includes: The rule engine's initial screening unit is used to deterministically screen the targets based on preset managed objects, basic indicator conditions, and action whitelists, and determine whether to enter the large model's decision-making process. The large model decision agent is used to organize contextual information, call tools to supplement query data, and generate a structured action list based on multi-source evidence after the rule engine's initial screening unit determines that a match has been found. The MCP tool layer is used to provide data query interfaces and action planning interfaces to the large model decision agent. The data query interfaces include report queries, media status queries, budget queries, conversion queries, and historical action queries. The action planning interface is used to convert the intent of the large model into standard action drafts. An action executor is used to perform boundary checks on each action in the action list and execute the actions that pass the checks. The history record unit is used to save triggering conditions, large model judgment criteria, tool call trajectory, action list, and execution results.

3. The mobile advertising cross-channel batch creation system according to claim 1, characterized in that, The media adaptation layer implements a unified set of method signatures for each advertising media. The set of method signatures includes parameter generation methods, project creation methods, advertisement creation methods, creative creation methods, material upload methods, object deletion methods, error formatting methods, and result standardization methods. The asynchronous scheduling layer only relies on the unified method signature to call each media adapter and does not directly perceive the differences in media interfaces.

4. The mobile advertising cross-channel batch creation system according to claim 1, characterized in that, The asynchronous scheduling layer executes creation tasks in the dependency order of material upload, project creation, ad creation, and creative creation; the main task maintains the number of submissions, completions, and successes at the project level, the number of submissions, completions, and successes at the ad level, and the number of submissions, completions, and successes at the creative level; after each subtask is completed, the number of completions and successes is incremented according to the corresponding object level.

5. A method for cross-channel batch creation of mobile advertisements based on the cross-channel batch creation system for mobile advertisements according to any one of claims 1 to 4, characterized in that, Includes the following steps: Standardized configuration It receives account configuration, project configuration, ad configuration, creative configuration, material configuration, title configuration, landing page configuration, conversion configuration, targeting configuration, budget configuration, and bid configuration from multiple advertising media, and splits the configuration into common fields and media extended fields to generate a unified configuration object; Submission matrix generation Based on the account set, material allocation rules, and ad hierarchy, a project submission matrix, an ad submission matrix, and a creative submission matrix are generated. Each row in the matrix contains a parent object reference, media type, account identifier, material placeholder, and fields to be filled back. Preview Verification Before the formal creation, the number of project submissions, ad submissions, creative submissions, number of creative groups, and number of creatives are calculated based on the submission matrix, and the required field validation, creative integrity validation, account authorization validation, media field conflict validation, delivery time validation, and budget boundary validation are performed. Material Upload and Feedback Upload materials by calling the media material interface at the account level, obtain the media-side material identifier, write the mapping between the local material identifier and the media-side material identifier into the cache and task details, and replace the material placeholders in the submission matrix with the media-side material identifier before creating a project, advertisement or creative. Task scheduling and execution The creation tasks are executed asynchronously according to the dependency order of material upload, project creation, ad creation, and creative creation. After each level of subtask is completed, the number of submissions, completions, and successes are updated according to the corresponding object level. Status backfilling When all lower-level objects fail to be created, the upper-level object is triggered to perform reverse processing operations, and the reason for the failure is written into the corresponding task details.

6. The method for cross-channel batch creation of mobile advertisements according to claim 5, characterized in that, In the task scheduling and execution steps, a scheduling strategy is selected according to the submission method: when the submission method is immediate submission, the main task is delivered for asynchronous execution immediately after creation. When the submission method is scheduled submission, the planned trigger time is recorded and the scheduled scheduler delivers the execution at the planned trigger time. When the submission method is batch submission, the submission matrix is ​​split into multiple batch tasks according to the quantity of each batch and the submission interval, and each batch task is executed independently.

7. The method for cross-channel batch creation of mobile advertisements according to claim 5, characterized in that, The reverse processing operations include: when all creative rows under an advertisement cannot be created, marking the advertisement as failed or skipped; when all advertisements under an item cannot be created, performing deletion, pause, archive, or marking as abnormal operations on the created items according to the capabilities of the media adapter.

8. The method for cross-channel batch creation of mobile advertisements according to claim 5, characterized in that, In the material upload and backfilling steps, each material upload task includes a task identifier, media type, account identifier, local material identifier, material type, upload parameters, and retry information; when all uploads of a certain material under the same advertising account fail, the creative row that depends on that material is marked as uncreationable.

9. The method for cross-channel batch creation of mobile advertisements according to claim 5, characterized in that, It also includes the smart hosting step: Initial screening of rules The set of managed objects is parsed according to the preset managed rules, basic indicator data is retrieved, and it is determined whether each managed object meets the preset basic indicator conditions. The managed rules include managed object type, basic indicator conditions, inspection frequency, do-not-disturb period, action whitelist and notification method. Large Model Decision When the managed object meets the basic indicator conditions, the rule snapshot, object snapshot, indicator window data, available tool list, historical action record and execution strategy are assembled into prompt words and sent to the large model decision agent; The large model decision agent calls the MCP tool to supplement the query data based on the prompt words, and generates a structured action list based on the evidence returned by the tool; Action verification and execution Perform permission verification, idempotency verification, budget bid boundary verification, and do-not-disturb policy verification on each action in the action list, and execute the actions that pass the verification. Record Save the snapshot of the rules triggered this time, the basis for the large model's judgment, the tool call trajectory, the action list, and the execution results.

10. The method for cross-channel batch creation of mobile advertisements according to claim 9, characterized in that, In the large model decision-making process, the prompt words have a four-layer structure: the system layer defines the agent role and constraints prohibiting direct execution of actions; the developer layer injects an action whitelist, a list of callable tools, output format requirements, and idempotency rules; the user layer injects the initial rule screening results, object snapshots, indicator window data, historical actions, and execution strategies; the tool result layer carries the data evidence returned by the MCP tool; each action output by the large model decision agent includes an evidence reference field, which is used to bind the action with the data evidence returned by the MCP tool.

Images