An intelligent AI marketing data management device

CN122547873APending Publication Date: 2026-08-11TAIZHOU BOZHE ENTERPRISE MANAGEMENT CONSULTING CO LTD +1
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-05-22
Publication Date
2026-08-11

AI Technical Summary

Technical Problem

[0006]为解决上述技术问题,本发明提供一种智能AI营销数据管理设备,解决了现有营销数据管理中字段准入不可控、模块扩展不便、客群重复圈选、客户重复触达以及反馈结果难以追溯校准的问题

Benefits of technology

1.本发明通过可写入模块描述文件,实现营销数据处理模块的注册、校验、启用和回滚,提高设备对新增渠道、标签和触达接口的适配能力。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122547873A_ABST
    Figure CN122547873A_ABST
Patent Text Reader

Abstract

The application provides an intelligent AI marketing data management device, which is arranged in a cabinet type computing resource and comprises a module registration unit, a marketing event standardization unit, a dynamic attribute access unit, a customer identification merging unit, a label increment calculation unit, a customer group resource management unit, a strategy scoring reaching unit, a feedback calibration unit and a data security audit unit. The module registration unit is used for receiving a writable module description file and checking, enabling or rolling back a marketing data processing module. The marketing event standardization unit is used for converting multi-channel original marketing data into unified marketing events. The application solves the problems of uncontrollable field access, inconvenient module expansion, repeated customer group selection, repeated customer reaching and difficult feedback result tracing and calibration in the existing marketing data management.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of digital marketing, and more particularly to an intelligent AI marketing data management device. Background Technology

[0002] With the development of digital marketing, businesses typically need to simultaneously access data from multiple channels, including e-commerce platforms, membership systems, advertising platforms, customer service systems, offline stores, applications, and payment systems. They then use this data to create customer profiles, calculate tags, select target audiences, and reach out to customers. However, the data field names, data formats, statistical definitions, customer identifiers, and authorization statuses differ across channels. Adding new fields directly to the data system can easily result in duplicate fields, incorrect fields, conflicting definitions, or unauthorized fields, affecting the accuracy of subsequent marketing analysis results.

[0003] Meanwhile, existing marketing data processing rules are mostly deployed in a fixed procedure manner. When new channels, tags, or outreach interfaces are added, the main program usually needs to be redeveloped or modified, resulting in high deployment and maintenance costs. On the other hand, when multiple marketing campaigns are executed concurrently, the system is prone to repeatedly reading the same tags and customer group data, increasing the pressure on database access and potentially causing the same customer to be repeatedly reached within a short period of time.

[0004] Furthermore, it is often difficult to establish a stable correlation between reach feedback data and field versions, tag versions, and strategy versions, making it difficult to track and calibrate marketing effectiveness.

[0005] Therefore, it is necessary to provide a new intelligent AI marketing data management device to solve the above-mentioned technical problems. Summary of the Invention

[0006] To address the aforementioned technical problems, this invention provides an intelligent AI marketing data management device that solves the issues of uncontrollable field access, inconvenient module expansion, duplicate customer selection, duplicate customer outreach, and difficulty in tracing and calibrating feedback results in existing marketing data management systems.

[0007] This invention provides an intelligent AI marketing data management device, which is deployed in a rack-mounted computing resource to provide processing, storage, and network communication capabilities. The device includes a module registration unit, a marketing event standardization unit, a dynamic attribute access unit, a customer identifier merging unit, a tag incremental calculation unit, a customer group resource management unit, a strategy scoring and outreach unit, a feedback calibration unit, and a data security audit unit.

[0008] The module registration unit receives a writable module description file and registers the corresponding marketing data processing module according to the module description file. The module description file includes at least the module number, module type, module version, input field set, output field set, dependency field set, applicable channels, triggering method, permission level, and rollback version number. After the module is written, the module registration unit verifies its dependency fields, output fields, and execution results, and determines the module's enabled, isolated, or rollback status based on the verification results.

[0009] The marketing event standardization unit receives raw marketing data from different marketing channels and converts it into a unified marketing event. The unified marketing event includes at least an event number, event time, channel number, customer candidate identifier, event type, source system, authorization identifier, and a set of extended attributes. For fields that cannot be mapped to the formal field directory, the marketing event standardization unit writes them into the extended attribute set and submits them to the dynamic attribute admission unit.

[0010] The dynamic attribute admission unit is used to generate candidate attribute objects for unregistered fields in the extended attribute set, and calculates a quality score based on coverage, type stability, semantic attribution, authorization completeness, duplication and conflict, and abnormal volatility, thereby determining the isolation, candidate, gray-scale availability, or formal availability status of the candidate attribute object. Candidate attribute objects that do not reach the allowed call status shall not participate in tag calculation, customer group selection, and strategy scoring.

[0011] The customer identifier merging unit is used to generate or match unified customer identifiers based on customer candidate identifiers, and to aggregate unified marketing events belonging to the same customer under different marketing channels under the same unified customer identifier. The customer identifier merging unit calculates a merging score based on the evidence type and evidence weight in the identity relationship table, and determines whether to merge strongly, associate weakly, or create a new unified customer identifier based on the merging score.

[0012] The incremental tag calculation unit is used to query the tag dependency index table based on the event type and field name in the unified marketing event, determine the set of affected tags, and only perform incremental updates on the set of affected tags. For fields in isolated or candidate states, the incremental tag calculation unit does not call these fields to participate in tag calculation.

[0013] The customer group resource management unit is used to generate customer group fingerprints based on the activity number, customer group selection rules, tag version number, field version number, and time window, and to cache, lock, and reuse the customer group selection results based on the customer group fingerprints. The customer group resource management unit is also used to maintain customer reach status to prevent the same customer from being contacted repeatedly in a short period of time.

[0014] The strategy scoring outreach unit is used to calculate a comprehensive score for candidate outreach solutions based on customer tags, campaign objectives, channel costs, historical feedback, outreach frequency, and authorization status, and to select candidate outreach solutions that meet authorization restrictions, outreach frequency restrictions, channel availability conditions, and outreach status restrictions to generate marketing outreach tasks.

[0015] The feedback calibration unit receives feedback data from marketing outreach tasks and associates this data with the activity number, strategy version number, tag version number, field version number, and unified customer identifier to update customer tags and strategy scoring parameters. When the conversion rate, unsubscription rate, or complaint rate of the same strategy within a preset period does not meet preset requirements, the feedback calibration unit changes the strategy status to pending review and notifies the module registration unit to adjust the execution status of the marketing data processing module corresponding to the strategy.

[0016] The data security audit unit is used to perform permission verification and audit records for module writing, field access control, customer identifier merging, tag calculation, customer group selection, outreach task generation, and feedback write-back. When a field involves sensitive information or the customer's authorization status does not meet the outreach conditions, the data security audit unit restricts the corresponding field or customer from participating in subsequent processing.

[0017] The beneficial effects of this invention are: 1. This invention enables the registration, verification, activation, and rollback of marketing data processing modules through a writable module description file, thereby improving the device's adaptability to new channels, tags, and reach interfaces.

[0018] 2. This invention uses a dynamic attribute admission mechanism to perform quality, semantic, authorization, and conflict judgments on newly added fields, preventing erroneous, duplicate, and unauthorized fields from directly entering the formal data system.

[0019] 3. This invention manages multi-channel customer data in a unified manner by merging customer identifiers and calculating incremental tags, and only updates tags affected by new events, thereby reducing computational pressure.

[0020] 4. This invention reduces repeated selection, repeated querying, and repeated outreach by using customer fingerprinting, caching, task locking, and outreach status flow, thereby improving the execution stability of high-concurrency marketing campaigns.

[0021] 5. This invention associates outreach results with field versions, tag versions, and strategy versions through feedback calibration and audit trails, facilitating marketing effectiveness tracking, strategy optimization, and compliance management. Attached Figure Description

[0022] Figure 1 A schematic diagram of the functional module structure of the intelligent AI marketing data management device provided by the present invention; Figure 2A schematic diagram of the overall marketing data processing flow provided by this invention; Figure 3 This is a schematic diagram of the dynamic attribute admission process provided by the present invention; Figure 4 This is a schematic diagram of the customer resource management and outreach execution process provided by the present invention. Detailed Implementation

[0023] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0024] Please refer to the following: Figure 1 , Figure 2 , Figure 3 as well as Figure 4 ,in Figure 1 A schematic diagram of the functional module structure of the intelligent AI marketing data management device provided by the present invention; Figure 2 A schematic diagram of the overall marketing data processing flow provided by this invention; Figure 3 This is a schematic diagram of the dynamic attribute admission process provided by the present invention; Figure 4 This is a schematic diagram of the customer resource management and outreach execution process provided by the present invention.

[0025] In the specific implementation process, such as Figures 1-4 As shown, this embodiment provides an intelligent AI marketing data management device, which is deployed in a rack-mounted computing resource. The rack-mounted computing resource includes a processor, memory, network communication interface, cache medium, and data storage medium, used for centrally running marketing data management programs. In this embodiment, the rack-mounted computing resource merely indicates that the invention uses a centralized device form to carry out data management functions. The key improvements of this invention lie in the module writing, field access, customer merging, tag incremental calculation, customer group locking, reach scoring, and feedback calibration processes running on this device.

[0026] The intelligent AI marketing data management device in this embodiment includes a module registration unit, a marketing event standardization unit, a dynamic attribute access unit, a customer identifier merging unit, a tag incremental calculation unit, a customer group resource management unit, a strategy scoring and outreach unit, a feedback calibration unit, and a data security audit unit. Each unit can be implemented through software modules or through a combination of software and hardware.

[0027] To achieve the above functions, this embodiment sets up a module directory table, a formal field directory table, a candidate attribute table, a marketing event table, a customer index table, an identity relationship table, a tag definition table, a tag dependency table, a customer group cache table, a customer reach status table, a reach task table, a feedback event table, and an audit log table in the data storage medium.

[0028] The module directory table is used to store information about marketing data processing modules that have been written to the device, including module number, module name, module type, module version, input fields, output fields, dependency fields, applicable channels, triggering method, execution priority, permission level, module status, activation time, deactivation time, and rollback version number.

[0029] The official field directory table is used to store approved marketing fields, including field number, standard field name, field type, field theme, statistical scope, applicable channels, authorization scope, sensitivity level, field version number, and field status.

[0030] The candidate attribute table is used to store newly added fields, newly added label fields, or newly added indicator fields that have not yet been officially approved. It includes candidate attribute number, original field name, recommended standard name, source channel, field data type, field sample, non-null ratio, value distribution, semantic category, similar official fields, conflicting fields, authorization scope, sensitivity level, quality score, approval status, and approval version number.

[0031] The marketing event table is used to store marketing events in a uniform format, including event number, event time, channel number, customer candidate identifier, event type, object number, object type, amount field, behavior field, source system, collection batch number, authorization identifier, field version number, and extended attribute set.

[0032] The customer index table is used to store unified customer identifiers, including unified customer identifier, primary identifier type, primary identifier value, creation time, last update time, and customer status.

[0033] The identity relationship table is used to store the relationships between different customer candidate identifiers, including first identifier, second identifier, evidence type, evidence source, evidence weight, first appearance time, most recent appearance time, and relationship status.

[0034] The tag definition table is used to store customer tag definitions, including tag number, tag name, dependent fields, calculation expression, time window, update method, applicable scenarios, tag version number, and expiration condition.

[0035] The tag dependency table is used to store the dependency relationship between fields and tags, including field number, tag number, event type, triggering condition, and update priority.

[0036] The customer group cache table is used to store customer group selection results, including customer group fingerprint, activity number, customer group rule summary, tag version number, field version number, time window, customer group result address, expiration time, and cache status.

[0037] The customer reach status table is used to store the reach status of customers in marketing campaigns, including the unified customer identifier, campaign number, channel number, reach status, status update time, cooldown deadline, lock token, and priority.

[0038] The Outreach Tasks table stores generated marketing outreach tasks, including task number, activity number, strategy number, unified customer identifier, content number, channel number, planned outreach time, overall score, outreach status, lock token, strategy version number, tag version number, and field version number.

[0039] The feedback event table is used to store feedback data after contact, including feedback number, task number, activity number, channel number, unified customer identifier, feedback type, feedback time, feedback value, strategy version number, tag version number, and field version number.

[0040] Through the aforementioned data objects, this embodiment can record marketing data in a versioned manner throughout the entire process from access, admission, profiling, selection, outreach, feedback to calibration.

[0041] The module registration unit is used to receive writable module description files. The module description file can be in a parsable text format, and its content includes at least the module number, module name, module type, module version, input fields, output fields, dependency fields, applicable channels, triggering method, execution priority, permission level, rollback version number, and verification signature.

[0042] Operations personnel or system administrators can write a coupon sensitivity tag calculation module. The input fields for this module include coupon redemption time, coupon usage time, and order amount; the output field is the coupon sensitivity score; applicable channels include e-commerce platforms, applications, and mini-programs; and the triggering method is event-driven.

[0043] After receiving the module description file, the module registration unit performs the following steps: Step 1: Parse the module description file and extract the input fields, output fields, and dependency fields.

[0044] Step 2: Match the input fields, output fields, and dependent fields with the formal field directory table.

[0045] Step 3: If the field name, field type, statistical scope, and authorization range are all consistent, then record the field as a usable field of the module.

[0046] Step 4: If a field does not exist in the formal field directory table, or if the field name is similar to an existing field but the statistical caliber is different, the module registration unit will not directly write the field into the formal field directory, but will submit the field to the dynamic attribute admission unit.

[0047] Step 5: When all the module's dependency fields are available to the module and the verification signature of the module description file passes, register the module as a candidate module.

[0048] Step 6: The module registration unit extracts historical marketing events from the sandbox dataset to run candidate modules, and detects the output field types, output data range, null value ratio, outlier value ratio, and execution time of the candidate modules.

[0049] Step 7: If the output field type of the candidate module is consistent with the module description file, the proportion of outliers is lower than the preset threshold, the execution time is lower than the preset time threshold, and no fields exceeding the permission level are called, then the candidate module status is changed to enabled.

[0050] Step 8: If a candidate module fails the sandbox verification, its status is changed to isolated; if the module is an upgraded version of an enabled module, it is rolled back to the previous available version.

[0051] In this way, the device can be programmed with new data source access modules, field mapping modules, tag calculation modules, customer group selection modules, strategy scoring modules, outreach interface modules, and feedback processing modules without modifying the main program or changing the rack-mount deployment method.

[0052] The Marketing Event Standardization Unit is used to receive raw marketing data from different channels and transform it into a unified marketing event.

[0053] The device receives data from e-commerce platforms, membership systems, advertising platforms, offline store systems, customer service systems, SMS platforms, application push platforms, and payment systems. Because different channels use different names for the same meaning field—for example, e-commerce platforms use buyer ID to represent customers, membership systems use member ID, advertising platforms use advertising user ID, and offline stores use membership card number—a unified conversion is required.

[0054] The standardized unit for marketing events is executed according to the following steps: Step 1: Identify the channel number based on the source system. For example, mark e-commerce platforms as e-commerce channels, applications as application channels, offline stores as store channels, and advertising platforms as advertising channels.

[0055] Step two involves calling the data source access module corresponding to the channel number to read the raw data. The raw data can be interface data, message queue data, batch file data, or database synchronization data.

[0056] Step 3: Call the field mapping module to convert the original fields into unified event fields. For example, map buyer ID, member ID, advertising user ID, and membership card number to customer candidate IDs; map payment time, order time, and transaction time to event times; and map product ID and item ID to object IDs.

[0057] Step four: Standardize event types. For example, unify browsing products and accessing product detail pages into a single product browsing event; unify claiming coupons and successfully claiming coupons into a single coupon claiming event; unify successful payment and order completion into a single order payment event; and unsubscribe from SMS messages into a single unsubscribe event.

[0058] Step 5: Generate a unified marketing event. A unified marketing event includes at least the event number, event time, channel number, customer candidate identifier, event type, object number, source system, collection batch number, authorization identifier, and extended attribute set.

[0059] Step six: For fields that cannot be mapped, the marketing event standardization unit does not discard them directly, nor does it write them directly into the formal field directory. Instead, it temporarily writes them into the extended attribute set and submits the field to the dynamic attribute admission unit.

[0060] For example, an advertising platform adds a new field called "Creative Sentiment Score" to represent the emotional tendency of advertising creative content. If this field does not exist in the official field directory table, the marketing event standardization unit adds it to the extended attribute set and submits it to the dynamic attribute admission unit for approval.

[0061] The dynamic attribute admission unit is used to determine the admission of unregistered fields in the extended attribute set. This unit does not simply set a defined or undefined flag for newly added fields, but rather makes a multi-dimensional judgment based on marketing business semantics, data quality, authorization scope, and field conflict.

[0062] The dynamic attribute admission unit generates a candidate attribute object for each newly added field and calculates the quality score of the candidate attribute object.

[0063] The formula for calculating the quality score is as follows: Quality Score = A × Coverage + B × Type Stability + C × Semantic Attribution + D × Authorization Completeness - E × Duplication / Conflict - F × Abnormal Volatility Among them, A, B, C, D, E, and F are preset weight coefficients.

[0064] Coverage is used to represent the proportion of non-empty records for a field within the same source channel or the same collection batch. For example, if a field has 9,200 non-empty records out of 10,000 events, then the coverage is 0.92.

[0065] Type stability is used to represent the proportion of the primary data type in a field sample. For example, if more than 95% of the data in a field sample are numeric, then the type stability is high; if a field contains a large number of dates, strings, and numeric values, then the type stability is low.

[0066] Semantic attribution indicates the degree to which a field matches marketing themes such as customers, orders, products, activities, channels, outreach, feedback, payments, and stores. Semantic attribution can be determined through keyword matching of field names, thesaurus matching, or semantic vector similarity calculations.

[0067] Authorization completeness indicates whether the field falls within the scope of customer authorization. If the field involves sensitive data such as mobile phone number, geographical location, payment information, or complaint records, and the authorization identifier is missing, the authorization completeness is reduced.

[0068] The duplication conflict level is used to indicate the degree of name similarity, sample distribution similarity, and statistical discrepancy between the candidate field and existing fields in the official field catalog. If a candidate field is highly similar to an existing official field but has a different statistical discrepancy, the duplication conflict level is increased.

[0069] Abnormal volatility is used to indicate whether there are anomalous changes in the distribution of values ​​for a field. If a field mainly takes values ​​from 0 to 100 in the previous batch, but a large number of negative values ​​or extreme values ​​appear in the subsequent batch, then the abnormal volatility increases.

[0070] In one embodiment, A, B, C, D, E, and F are set to 0.20, 0.20, 0.20, 0.20, 0.10, and 0.10, respectively. Those skilled in the art can adjust the above weights according to industry requirements.

[0071] The dynamic attribute admission unit determines the admission status of candidate attribute objects based on the quality score: When the quality score is below the first threshold, the candidate attribute object remains isolated, and this field cannot be used in subsequent tag calculations, customer group selection, and strategy scoring.

[0072] When the quality score is not lower than the first threshold and is lower than the second threshold, the candidate attribute object enters the candidate state and can only be called in the sandbox task.

[0073] When the quality score is not lower than the second threshold and there are no authorization anomalies or sensitivity level conflicts, the candidate attribute object enters a gray-scale availability state, which can only be called in a specified channel, a specified activity, or a specified test group.

[0074] When a candidate attribute object in the grayscale availability state passes the data quality check a preset number of times, the dynamic attribute admission unit writes it into the formal field directory and changes its status to formal availability.

[0075] For example, a new field called "Livestream Dwell Time" is added to a mini-program channel. If the device detects that the proportion of non-empty fields in this field is higher than 90% in the last 7 collection periods, the field type is consistently numeric, the semantics belong to the behavioral theme, there are no sensitive authorization conflicts, and there are no conflicts with existing fields, then this field can move from the candidate state to the gray-scale availability state. If the field remains stable during the gray-scale use period, it will then enter the officially available state.

[0076] By using the methods described above, we can prevent misspelled fields, duplicate fields, unauthorized fields, or fields with inconsistent definitions from directly entering the formal marketing data system.

[0077] The customer identifier merging unit is used to merge customer candidate identifiers from different channels into a unified customer identifier.

[0078] In one embodiment, customer candidate identifiers include mobile phone numbers, membership numbers, device numbers, advertising platform accounts, payment accounts, store membership card numbers, customer service chat accounts, and encrypted third-party accounts. Devices do not directly assume that different identifiers necessarily belong to the same customer; instead, a merge score is calculated using evidence weighting.

[0079] The formula for calculating the identity merging score is as follows: Identity merging score = 1 - (1 - Evidence weight one) × (1 - Evidence weight two) × ... × (1 - Evidence weight N) Among them, evidence weight 1 to evidence weight N represent the weights of different evidence types.

[0080] In one embodiment, the evidence weight for the same mobile phone number is 0.90, the evidence weight for the same membership number is 0.85, the evidence weight for the same payment account is 0.80, the evidence weight for the same device number is 0.60, the evidence weight for the same order receipt information is 0.55, the evidence weight for the same advertising feedback identifier is 0.50, and the evidence weight for the same customer service session identifier is 0.45.

[0081] The customer identification merging unit is executed according to the following steps: Step 1: Read the customer candidate identifiers from the unified marketing event.

[0082] Step 2: Query the customer index table to determine whether the customer candidate identifier already corresponds to a unified customer identifier.

[0083] Step 3: If a direct match is found, the marketing event will be grouped under the corresponding unified customer identifier.

[0084] Step 4: If no direct match is found, query the identity relationship table to obtain other identifiers that are related to the customer candidate identifier.

[0085] Step 5: Calculate the identity merging score based on the type and weight of evidence.

[0086] Step 6: When the identity merging score is not lower than the merging threshold, the customer candidate identifier is merged into the corresponding unified customer identifier.

[0087] Step 7: When the identity merging score is lower than the merging threshold but not lower than the association threshold, only weak associations are established, and identity merging is not performed.

[0088] Step 8: When the identity merging score is lower than the association threshold, create a new unified customer identity for the customer candidate identity.

[0089] For example, if a customer uses a buyer ID on an e-commerce platform and a member ID in the membership system, and both are linked to the same encrypted mobile phone number, the identity merging score will be high, and the device will classify them as the same unified customer identifier. If two accounts only use the same device ID, but the mobile phone number, member ID, and payment account are different, the device will only establish a weak association to avoid mistakenly merging family members or users sharing the same device.

[0090] The incremental tag calculation unit is used to calculate customer tags based on unified marketing events and tag definition objects. Unlike a full recalculation, this embodiment uses a field dependency and event triggering mechanism to update only the affected tags.

[0091] In one embodiment, the tag definition table stores the following tags: The coupon sensitivity tag depends on fields including coupon redemption time, coupon usage time, and order amount. It is calculated as the ratio of the number of times the coupon was used to the number of times the coupon was redeemed in the last 30 days.

[0092] Channel preference tags depend on fields including channel number, event type, and feedback type, and are calculated using the normalized result of the number of responses from different channels.

[0093] The repeat purchase tendency tag depends on fields including order time, order amount, and product category. It is calculated as a combined score of purchase interval, category repetition rate, and amount change.

[0094] The tag increment calculation unit executes the following steps: Step 1: Read the newly written unified marketing event and obtain the event type and field name.

[0095] Step 2: Determine the set of affected tags based on the tag dependency table.

[0096] Step 3: If the event type is a coupon redemption event, then only update the relevant tags such as the number of coupon redemptions, promotion sensitivity, and number of event responses.

[0097] Step 4: If the event type is an order payment event, then only update the relevant tags such as spending power, repurchase tendency, category preference, and customer value.

[0098] Step 5: If the event type is a cancellation event, only update the relevant tags such as cancellation risk, reach fatigue, and channel preference.

[0099] Step 6: Read the historical tag values ​​and current event data corresponding to the unified customer identifier, and perform incremental calculations according to the calculation method in the tag definition table.

[0100] Step 7: Associate the calculation results with the unified customer identifier, tag number, tag version number, field version number, and update time for storage.

[0101] Step 8: If a field is an isolated or candidate attribute object, the incremental tag calculation unit will not call that field to participate in the tag calculation; if the field is in a gray-scale available state, it will only participate in the tag calculation in the allowed channels, activities or test groups.

[0102] By using the above methods, when processing high-frequency marketing events, the device does not need to recalculate all customer tags every time, which can reduce the computing pressure and improve the speed of profile updates.

[0103] The customer group resource management unit is used to cache, lock, and reuse customer group selection results, and to manage customer reach status.

[0104] When the strategy scoring outreach unit requests the generation of target customer groups, the customer group resource management unit reads the activity number, customer group selection rules, tag version number, field version number, and time window, and generates a customer group fingerprint.

[0105] The formula for calculating customer group fingerprints is as follows: Customer group fingerprint = hash value (activity number + customer group rule summary + tag version number + field version number + time window) For example, if an activity is designated as Member Day Activity 1, and the customer group rules are "received a coupon but did not use it in the past 30 days, have a purchase record in the past 90 days, have not unsubscribed, and are not in a cooling-off period", the tag version number is tag version 12, the field version number is field version 8, and the time window is from June 1, 2025 to June 18, 2025, then the device will generate a unique customer group fingerprint based on the above information.

[0106] The customer resource management unit operates according to the following steps: Step 1: Query the customer group cache table based on the customer group fingerprint.

[0107] Step 2: If there are unexpired fingerprints of the same customer group, directly read the corresponding customer group selection results.

[0108] Step 3: If there are no expired fingerprints for the same customer group, then set a task lock for that customer group's fingerprints.

[0109] Step four: Requests that acquire the task lock perform customer selection calculations, while requests that do not acquire the task lock wait for requests that have acquired the lock to be written to the cache, or read the cache again after the waiting time expires.

[0110] Step 5: The request to obtain the task lock reads the customer tags and reach status according to the customer group selection rules, generates candidate customer group results, and writes them to the customer group cache table.

[0111] Step six: The device checks the reach status for each customer in the candidate customer group. Reach status includes idle, reserved, in progress, reached, cooling down, released, and blacklisted.

[0112] Step 7: When a customer is in an idle state, the customer group resource management unit changes its status from idle to reserved by comparison and update, and generates a lock token.

[0113] Step 8: When the outreach task begins, change the customer outreach status from pre-emptive to in progress; when the outreach task is completed, change the outreach status to reached, and set a cooldown deadline according to the outreach frequency rules; when the cooldown period expires, change the outreach status to released.

[0114] Step 9: If a customer is in a pre-emptive, active, reached, or cooling-off state, other activities must not make them reachable again unless the activity meets the preset priority coverage rules.

[0115] Step 10: If a customer is on a blacklist or their authorization status does not allow marketing outreach, remove them directly from the customer pool to be reached.

[0116] By using customer group fingerprint caching, task locking, and customer reach status transition mechanisms, the device can avoid multiple activities repeatedly targeting the same customer group, reduce database query pressure, and prevent repeated outreach to the same customer in a short period of time.

[0117] The Strategy Scoring Outreach Unit is used to generate marketing outreach tasks based on customer tags, campaign objectives, channel costs, historical feedback, outreach frequency, and authorization status.

[0118] In this embodiment, the device does not output general marketing suggestions, but rather outputs actionable outreach tasks. Each candidate outreach plan includes a unified customer identifier, activity number, strategy number, content number, channel number, planned outreach time, expected conversion probability, customer value score, channel cost score, outreach fatigue score, compliance risk score, comprehensive score, and lock token.

[0119] The formula for calculating the overall score is as follows: Overall Score = P × Expected Conversion Probability + Q × Customer Value Score - R × Channel Cost Score - S × Outreach Fatigue Score - T × Compliance Risk Score Among them, P, Q, R, S, and T are preset weighting coefficients.

[0120] The expected conversion probability is determined based on the customer's historical response, lifecycle stage, channel preference, campaign type, product preference, and recent behavior.

[0121] Customer value is determined based on customer spending amount, repurchase frequency, membership level, and estimated lifetime value.

[0122] Channel costs are determined based on the unit reach cost of SMS, telephone, app push, ad retargeting, WeChat Work, or offline sales channels.

[0123] Reach fatigue score is determined based on the number of recent contacts, the number of recent unresponsive contacts, unsubscription records, complaint records, and cooling-off status.

[0124] Compliance risks are determined based on the customer's authorization status, the use of sensitive fields, blacklist status, the purpose of reaching, and channel restrictions.

[0125] The strategy scoring outreach unit is executed according to the following steps: Step 1: Read the target campaign configuration. The campaign configuration includes campaign objectives, budget limit, target audience, available channels, reach frequency limit, campaign start time, campaign end time, and content asset set.

[0126] Step 2: Read the set of pre-occupied customers output by the customer group resource management unit.

[0127] Step 3: Generate multiple candidate outreach options for each customer. For example, the same customer may have multiple candidate options such as SMS outreach, app push notifications, WeChat Work outreach, ad retargeting, or outbound phone calls.

[0128] Step 4: Calculate the expected conversion probability, customer value score, channel cost score, reach fatigue score, and compliance risk score for each candidate outreach plan.

[0129] Step 5: Calculate the overall score for each candidate outreach plan according to the comprehensive scoring formula.

[0130] Step 6: Select the candidate solution with the highest overall score that meets the restrictions on authorization, frequency, channel availability, and reach status, and generate a marketing outreach task.

[0131] Step 7: Write the marketing outreach tasks into the outreach task table and send them to the corresponding outreach interface module.

[0132] Step 8: After the outreach interface module starts execution, change the task status to "in execution" and notify the customer resource management unit to update the customer outreach status synchronously.

[0133] For example, if SMS outreach has a higher expected conversion rate for the same customer, but the customer has not authorized SMS marketing, then the SMS solution is eliminated; if application push notifications have lower costs, but the customer has not responded multiple times in the past 7 days, then the outreach fatigue score increases; if WeChat outreach has a higher expected conversion rate and lower compliance risk, then the device will ultimately choose the WeChat outreach solution.

[0134] The feedback calibration unit is used to receive feedback data after outreach and associate the feedback data with the original outreach task, policy version, tag version, and field version.

[0135] Feedback data includes impressions, opens, clicks, inquiries, add-to-cart, orders placed, payments, unsubscribes, complaints, repeat purchases, and no response.

[0136] The feedback calibration unit performs the following steps: Step 1: Receive feedback data from the channels you reached.

[0137] Step 2: Based on the activity number, channel number, unified customer identifier, and lock token in the feedback data, query the outreach task table to obtain the original outreach task.

[0138] Step 3: Write the feedback data into the feedback event table and record the corresponding strategy version number, tag version number, and field version number.

[0139] Step 4: Update customer tags based on feedback type. For example, if the feedback type is a click, update the recent response count and channel preference; if the feedback type is a payment, update repurchase tendency, customer value, and category preference; if the feedback type is a cancellation or complaint, update cancellation risk, complaint risk, and reach fatigue.

[0140] Step 5: Calculate click-through rate, conversion rate, unsubscribe rate, complaint rate, return on investment, and customer retention metrics according to the dimensions of activity, channel, customer group, content, and time.

[0141] The formula for calculating click-through rate is as follows: Click-through rate = Number of clicks ÷ Actual number of users reached × 100% The formula for calculating conversion rate is as follows: Conversion rate = Number of paying customers ÷ Number of customers actually reached × 100% The formula for calculating the cancellation rate is as follows: Unsubscription rate = Number of unsubscribed subscribers ÷ Number of subscribers actually reached × 100% The formula for calculating the complaint rate is as follows: Complaint rate = (Number of complainants ÷ Number of people actually reached) × 100% The formula for calculating the input-output ratio is as follows: Return on investment = Marketing revenue ÷ Marketing cost Step six: The feedback calibration unit writes the above indicators into the strategy scoring parameter table as the source of parameters for the next round of comprehensive scoring.

[0142] Step 7: When the conversion rate of a certain strategy is lower than the conversion rate threshold within a preset period, or the cancellation rate or complaint rate is higher than the risk threshold, the feedback calibration unit changes the status of the strategy to pending review and notifies the module registration unit to reduce the execution priority of the module corresponding to the strategy or suspend the strategy module.

[0143] Step 8: If the feedback data cannot be matched with the original outreach task, the feedback calibration unit writes it into the anomaly feedback table and submits it to the data security audit unit to check for anomalies such as channel feedback errors, lost task tokens, or unauthorized outreach.

[0144] Through the above methods, the device can reverse the marketing results to tag calculation and strategy scoring, realizing a closed loop from data access, field access, customer profiling, customer group selection, outreach execution to effect calibration.

[0145] The data security audit unit is used to audit field access, module writing, customer merging, tag calculation, customer group selection, outreach task generation, and feedback write-back.

[0146] When the dynamic attribute admission unit identifies a sensitive field, the data security audit unit reads the field's sensitivity level and authorization scope. If the field involves contact information, geographic location, payment information, complaint records, or personal identification, the authorization identifier determines whether it is allowed to be used for tag calculation or policy scoring.

[0147] When a new module is written to the module registration unit, the data security audit unit checks the permission level and applicable business scenario in the module description file. If the module's call fields exceed the permission level, or the call purpose is inconsistent with the applicable business scenario, the module's activation is blocked.

[0148] When sensitive fields are called for customer group selection or strategy scoring, the data security audit unit records the calling module, calling time, calling fields, calling purpose, calling result, and operating entity.

[0149] If a customer's authorization status is "deny marketing outreach," the device must not generate a marketing outreach task for that customer. If a customer is on a blacklist, the device will exclude that customer directly during the customer segmentation phase.

[0150] If the size of the query results or customer group results is lower than the preset anonymization threshold, such as less than 10 people, the device will only output summary statistics and will not output customer details to reduce the risk of personal information leakage.

[0151] Audit results are written to the audit log table and can be traced by module number, field number, customer ID, activity number, and time range.

[0152] The following uses the "Member Day Coupon Promotion Activity" as an example to illustrate the complete operation process of the device of this invention.

[0153] Step 1: Operations personnel input the coupon sensitivity tag calculation module through the management interface. After parsing the module description file, the module registration unit finds that the input fields "coupon redemption time" and "coupon usage time" already exist in the official field directory, but the output field "coupon sensitivity score" does not yet exist. The module registration unit then submits this output field to the dynamic attribute admission unit.

[0154] Step two: The dynamic attribute admission unit generates candidate attribute objects for the coupon sensitivity score. After reading the sandbox data, the device finds that this field is numeric, with a non-empty ratio of 0.93, stable field samples, semantically belonging to the customer tag theme, and does not involve sensitive personal information. The calculated quality score is higher than the second threshold, and this field enters a gray-scale available state.

[0155] Step 3: The module registration unit runs the coupon sensitivity label calculation module in the sandbox dataset. The results show that the output field contains values ​​between 0 and 1, the proportion of outliers is below the threshold, and the execution time meets the requirements. Therefore, the module is registered as enabled, but its output field is only for use in this Member Day test activity.

[0156] Step four: The marketing event standardization unit receives coupon redemption, browsing, clicking, order placement, and payment events generated by e-commerce platforms, applications, and mini-programs, and converts them into marketing events in a unified manner.

[0157] Step 5: The customer identifier merging unit merges candidate customer identifiers from different channels into a unified customer identifier based on mobile phone number, membership number, device number, and order information. For accounts with only weak associations, devices are not forcibly merged.

[0158] Step 6: The tag incremental calculation unit queries the tag dependency table based on the newly written coupon redemption event and only updates tags such as coupon sensitivity, recent activity response count, and promotion preference.

[0159] Step 7: Operations personnel configure Member Day activities, with customer group rules defined as "those who have received coupons but not used them in the past 30 days, have purchase records in the past 90 days, have not unsubscribed, and are not currently in a cooling-off period." The customer group resource management unit generates customer group fingerprints based on the activity number, customer group rules, tag version number, field version number, and time window.

[0160] Step 8: If no matching customer group fingerprints exist in the cache, the customer group resource management unit sets a task lock and performs customer group selection. After selection, the customer group results are written to the cache, and the reachability status of reachable customers is changed from idle to reserved, and a lock token is generated.

[0161] Step nine: The strategy scoring outreach unit generates candidate outreach options such as SMS, app push notifications, and WeChat Work for each customer, and calculates the expected conversion probability, customer value score, channel cost score, outreach fatigue score, and compliance risk score for each option.

[0162] Step 10: If a customer has not authorized SMS marketing, the SMS plan will be removed; if a customer has received multiple push notifications in the past 7 days, the reach fatigue score of the application push plan will increase; if the expected conversion probability of reaching via WeChat Work is high and the compliance risk is low, the device will generate a WeChat Work outreach task.

[0163] Step 11: After the interface module executes its task, the feedback calibration unit receives feedback such as "open," "click," "place order," "pay," or "unsubscribe." The device associates and stores the feedback data with the activity number, policy version number, tag version number, field version number, and unified customer identifier.

[0164] Step 12: The feedback calibration unit updates customer tags and strategy scoring parameters based on the feedback results. If a certain content has a high conversion rate among customers with high coupon sensitivity, the device increases the strategy score of that content among similar customer groups; if the unsubscription rate of a certain channel increases, the priority of that channel is reduced.

[0165] Step 13: After the campaign concludes, the device outputs a campaign performance report, including customer base size, actual reach, click-through rate, conversion rate, unsubscribe rate, complaint rate, return on investment, contribution from different channels, and performance differences under different tag versions. Since each feedback item is linked to the field version, tag version, and strategy version, it's possible to trace whether a change in marketing performance was caused by changes in field access, tag rules, or strategy modules.

[0166] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent structural or procedural transformations made based on the content of the present invention specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. An intelligent AI marketing data management device, characterized by, The device is deployed in a rack-mounted computing resource, which provides processing, storage, and network communication capabilities. The device includes a module registration unit, a marketing event standardization unit, a dynamic attribute access unit, a customer identifier merging unit, a tag incremental calculation unit, a customer group resource management unit, a strategy scoring outreach unit, a feedback calibration unit, and a data security audit unit. The module registration unit is used to receive a writable module description file and register the corresponding marketing data processing module according to the module description file; The marketing event standardization unit is used to receive raw marketing data from different marketing channels and convert the raw marketing data into a unified marketing event. The unified marketing event includes at least an event number, event time, channel number, customer candidate identifier, event type, source system, authorization identifier, and extended attribute set. The dynamic attribute admission unit is used to generate candidate attribute objects for unregistered fields in the extended attribute set, and to determine the admission status based on the data quality, business semantics, authorization scope and field conflict of the candidate attribute objects; The customer identifier merging unit is used to generate or match a unified customer identifier based on the customer candidate identifier, and to aggregate unified marketing events belonging to the same customer under different marketing channels into the same unified customer identifier. The tag incremental calculation unit is used to determine the affected tag set based on the event type and field name in the unified marketing event, and to perform incremental updates only on the affected tag set; The customer group resource management unit is used to generate customer group fingerprints based on activity number, customer group selection rules, tag version number, field version number and time window, and cache, lock and reuse customer group selection results based on the customer group fingerprints, and set the reach status for customers selected into the customer group to be reached. The strategy scoring outreach unit is used to calculate a comprehensive score for candidate outreach solutions based on customer tags, campaign objectives, channel costs, historical feedback, outreach frequency, and authorization status, and to generate marketing outreach tasks based on the comprehensive score. The feedback calibration unit is used to receive feedback data from marketing outreach tasks and associate the feedback data with the activity number, strategy version number, tag version number, field version number, and unified customer identifier to update customer tags and strategy scoring parameters. The data security audit unit is used to perform permission verification and audit records for module writing, field access, customer identifier merging, tag calculation, customer group selection, outreach task generation, and feedback write-back. 2.The intelligent AI marketing data management device of claim 1, wherein, The module description file shall include at least the module number, module type, module version, set of input fields, set of output fields, set of dependent fields, applicable channels, triggering method, permission level, and rollback version number; After receiving a new module description file, the module registration unit matches the input field set, output field set, and dependency field set with the formal field directory, respectively. When a field exists in the official field directory and its field type, statistical scope, and authorization range are consistent, the field is determined to be a usable field for the module. When a field does not exist in the official field directory, or when field names are similar but statistical definitions are inconsistent, the field is submitted to the dynamic attribute admission unit to generate a candidate attribute object. When all the dependent fields of the marketing data processing module are available fields for the module, the module registration unit runs the marketing data processing module on the sandbox dataset and determines the enabled, isolated or rolled-back status of the marketing data processing module based on the output field type, output data range, outlier ratio and execution time. 3.The intelligent AI marketing data management device of claim 2, wherein, The dynamic attribute admission unit generates a candidate attribute record for each candidate attribute object. The candidate attribute record includes at least the candidate attribute number, original field name, recommendation standard name, source channel, field data type, field sample, non-empty ratio, value distribution, semantic category, similar formal fields, conflicting fields, authorization scope, sensitivity level, quality score, admission status, and admission version number. The quality score is determined as follows: Quality score = a × coverage + b × type stability + c × semantic attribution + d × authorization completeness - e × duplication and conflict - f × abnormal volatility; Where a, b, c, d, e, and f are preset weight coefficients; When the quality score is lower than the first threshold, the candidate attribute object is in an isolated state; when the quality score is not lower than the first threshold and is lower than the second threshold, the candidate attribute object is in a candidate state; when the quality score is not lower than the second threshold and no authorization exception or sensitivity level conflict is triggered, the candidate attribute object is in a gray-scale available state; when the candidate attribute object in the gray-scale available state passes the data quality test a preset number of times, the dynamic attribute admission unit writes the candidate attribute object into the formal field directory and changes its state to the formal available state. 4.The intelligent AI marketing data management device of claim 1, wherein, The customer identification merging unit includes a customer index table and an identity relationship table; The customer index table is used to store the unified customer identifier, primary identifier type, primary identifier value, creation time, last update time, and customer status; The identity relationship table is used to store the first identifier, the second identifier, the evidence type, the evidence source, the evidence weight, the first appearance time, the most recent appearance time, and the relationship status; When a new customer candidate identifier is received, the customer identifier merging unit first queries the customer index table based on the customer candidate identifier. If a directly matching unified customer identifier exists, the corresponding unified marketing event is aggregated under that unified customer identifier. If no directly matching unified customer identifier exists, the merging score is calculated based on the evidence type and evidence weight in the identity relationship table, and a strong merging, weak association, or new unified customer identifier is determined based on the merging score. 5.The intelligent AI marketing data management device of claim 1, wherein, The tag incremental calculation unit includes a tag definition table and a tag dependency index table; The tag definition table is used to store tag definition objects. The tag definition objects include at least tag number, tag name, dependency fields, calculation expression, time window, update method, applicable scenario, tag version number, and expiration condition. The tag dependency index table is used to store the dependency relationship between fields and tags; When a new unified marketing event is written, the tag incremental calculation unit reads the event type and field name in the unified marketing event, determines the affected tag set according to the tag dependency index table, performs incremental calculation only on the tags in the affected tag set, and stores the calculation results in association with the unified customer identifier, tag version number and field version number. When the field corresponding to the unified marketing event belongs to the candidate attribute object in the isolated state or the candidate state, the tag incremental calculation unit does not call the field to participate in the tag calculation.

6. The intelligent AI marketing data management device according to claim 1, characterized in that, The customer group resource management unit generates customer group fingerprints in the following manner: Customer group fingerprint = hash value (activity number + customer group selection rule + tag version number + field version number + time window); When a customer group selection request is received, the customer group resource management unit queries the cache area based on the customer group fingerprint; If there are unexpired fingerprints of the same customer group in the cache, then read the corresponding customer group selection result; If there are no expired identical customer group fingerprints in the cache, a task lock is set for the customer group fingerprint, and the customer group selection calculation is performed by the request that obtains the task lock. The customer group resource management unit is also used to maintain the customer reach status, which includes at least idle, reserved, in progress, reached, cooling down, released, and blacklisted status. When a customer is in the reserved, in progress, reached, or cooling down status, the customer group resource management unit excludes the customer from other marketing reach tasks that do not meet the priority coverage rules. 7.The intelligent AI marketing data management device of claim 1, wherein, The strategy scoring outreach unit calculates a comprehensive score for any candidate outreach plan for a customer in the following manner: Overall score = p × expected conversion probability + q × customer value score - r × channel cost score - s × reach fatigue score - t × compliance risk score; Where p, q, r, s, and t are preset weight coefficients; The strategy scoring and outreach unit selects the candidate outreach plan with the highest comprehensive score that meets the authorization restrictions, outreach frequency restrictions, channel availability conditions, and outreach status restrictions, and generates a marketing outreach task. After receiving the feedback data from the marketing outreach task, the feedback calibration unit queries the original marketing outreach task based on the activity number, channel number, unified customer identifier, and lock token, writes the feedback data into the feedback event table, and updates the corresponding customer tags and strategy scoring parameters. When the conversion rate of the same strategy is lower than the conversion rate threshold within a preset period, or the cancellation rate or complaint rate is higher than the risk threshold, the feedback calibration unit changes the status of the strategy to pending review and notifies the module registration unit to adjust the execution status of the marketing data processing module corresponding to the strategy.