Financial event-driven real-time dynamic marketing method and device, equipment and medium

Abstract

The invention provides a financial event-driven real-time dynamic marketing method and device, equipment and a medium, and the method comprises the steps: carrying out the registration processing of a label, an event and an index of a target financial event, and configuring corresponding standard rule information; acquiring offline data and real-time data related to a target financial event, processing the target data, updating the real-time wide table of the customer, account and card granularity in the HBase, and issuing a basic event drive stream; and based on basic event driving flow triggering rule calculation, calling rule collision logic to match standard rule information with a real-time wide table in the HBase to generate a standard message, and finally pushing the standard message to a target client. According to the method, dynamic combination and real-time driven marketing of financial events, labels and indexes are realized, the accuracy and the real-time performance of marketing are improved, and the real-time dynamic diversified marketing requirements of financial services are met.

Description

Technical Field

[0001] This application relates to the field of financial technology, and in particular to a financial event-driven real-time dynamic marketing method, device, equipment, and medium. Background Technology

[0002] In the context of the digital economy, the banking industry is becoming increasingly competitive. How commercial banks can leverage new technologies to improve customer insight, enhance operational efficiency, effectively control risks, and boost business performance has become crucial to overcoming this predicament. Customer insight is reflected in the precise capture of key customer events, such as "first activation," "first binding," "first transaction," "coupon redemption," "weekly cumulative transactions exceeding 3,000 yuan," "weekly cumulative transactions exceeding 10," "signing up a debit card to repay a credit card," "travel preference tags," "high-income group tags," "premium card tags," and "marketing to selected customer groups." Combining these events with analysis and rapid scenario-based marketing or responses can effectively improve customer service satisfaction.

[0003] Current financial event marketing mainly relies on capturing customer events to determine when an event has occurred. It may also combine customer tags for filtering, target specific groups, or determine whether users have accumulated enough transactions to meet certain criteria. Then, it conducts marketing through apps, mini-programs, and official accounts in different scenarios such as first-time purchases and first-time bindings. This requires customized development, which is complex, costly, and cannot be quickly configured to take effect in real time to meet the needs of dynamic marketing. Summary of the Invention

[0004] In view of this, the embodiments of this application provide a financial event-driven real-time dynamic marketing method, apparatus, device and medium, which can accurately, efficiently and in real time realize the financial marketing closed loop through multi-dimensional registration of financial events, full data collection and processing and real-time rule matching, thereby improving marketing accuracy and customer experience.

[0005] The technical solution of this application embodiment is implemented as follows: In a first aspect, embodiments of this application provide a financial event-driven real-time dynamic marketing method, the method comprising: The target financial events are registered, and corresponding compliance rules are configured for the registered target financial events. The registration process includes tag registration, event registration, and indicator registration. Tags include basic information tags, preference tags, and risk tags for customers, accounts, and cards, respectively. Events include first-time swipe events, card binding events, and first activation events. Indicators include core indicators and other indicators. For the target financial event, target data associated with the target financial event is collected; wherein, the target data includes offline data and real-time data; The target data is processed to obtain basic information tags, event information and basic indicators. Based on the processing results, the real-time wide tables of customer, account and card granularity in HBase are updated and basic event-driven streams are sent out. Based on the basic event-driven flow trigger rule calculation, the rule collision logic is called to match the compliance rule information with the real-time wide tables of customers, accounts, and cards stored in HBase to generate compliance messages; The achievement message will be pushed to the target customers.

[0006] Secondly, embodiments of this application also provide a financial event-driven real-time dynamic marketing device, the device comprising: The registration module is used to register target financial events and configure corresponding compliance rules for the registered target financial events. The registration process includes tag registration, event registration, and indicator registration. Tags include basic information tags, preference tags, and risk tags for customers, accounts, and cards, respectively. Events include first-swipe events, card binding events, and first activation events. Indicators include core indicators and other indicators. The data acquisition module is used to acquire target data associated with the target financial event; wherein the target data includes offline data and real-time data. The processing module is used to process the target data to obtain basic information tags, event information and basic indicators, and update the real-time wide tables of customer, account and card granularity in HBase based on the processing results, and issue basic event-driven streams. The calculation module is used to calculate the rules based on the basic event-driven flow, call the rule collision logic to match the compliance rule information with the real-time wide tables of customers, accounts, and cards stored in HBase, and generate compliance messages; The push module is used to push the achievement message to the target customer.

[0007] Thirdly, embodiments of this application also provide an electronic device, including: a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the financial event-driven real-time dynamic marketing method described in any of the first aspects.

[0008] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the financial event-driven real-time dynamic marketing method described in any one of the first aspects.

[0009] The embodiments of this application have the following beneficial effects: By accurately registering and configuring tags, events, and metrics across customer, account, and card dimensions, and integrating offline and real-time data, the system processes and updates HBase wide tables to trigger rule calculations, achieving event-driven operation throughout the entire marketing process. Leveraging multi-dimensional data correlation and real-time wide tables, it accurately captures customer behavior and quickly matches qualifying rules, ensuring marketing reach aligns with immediate customer needs. Furthermore, its standardized registration, processing, and matching processes guarantee efficient and accurate marketing responses, helping financial institutions improve marketing precision, enhance customer interaction, and build a real-time dynamic marketing closed loop from event triggering to customer reach, effectively optimizing marketing resource allocation and customer experience. Attached Figure Description

[0010] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a flowchart illustrating steps S101-S105 provided in the embodiments of this application; Figure 2 This is a flowchart illustrating steps S201-S203 provided in the embodiments of this application; Figure 3 This is a flowchart illustrating steps S301-S303 provided in the embodiments of this application; Figure 4 This is a schematic diagram of the event marketing configuration process provided in the embodiments of this application; Figure 5 This is a schematic diagram of the functional modules provided in the embodiments of this application; Figure 6 This is a schematic diagram of the internal data flow provided in the embodiments of this application; Figure 7 This is a schematic diagram of the structure of the financial event-driven real-time dynamic marketing device provided in the embodiments of this application; Figure 8 This is a schematic diagram of the composition structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0013] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0014] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0015] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0016] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0017] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application and is not intended to limit this application.

[0018] See Figure 1 , Figure 1This is a flowchart illustrating steps S101-S105 of the financial event-driven real-time dynamic marketing method provided in this application embodiment, which will be combined with... Figure 1 Steps S101-S105 are explained below.

[0019] In step S101, the target financial event is registered, and the corresponding compliance rule information is configured for the registered target financial event; wherein, the registration process includes tag registration, event registration, and indicator registration. The tags include basic information tags, preference tags, and risk tags for customers, accounts, and cards, respectively. The events include first-swipe events, card binding events, and first activation events. The indicators include core indicators and other indicators.

[0020] In this embodiment, registration is a prerequisite for marketing activities and requires the completion of three types of registration: Tag registration: For three types of entities, namely "customer, account, and card", register basic information tags (such as customer name, account type, card number), preference tags (such as travel preferences, consumption preferences), and risk tags (such as credit risk level, fraud risk tags); Event registration: Register key events in financial scenarios, including first swipe (customer's first card transaction), card binding (customer binds bank card to APP / mini program), first activation (customer activates credit card for the first time), etc. Metrics Registration: Register metrics for evaluating customers or business, including core metrics (such as weekly cumulative transaction amount, monthly transaction frequency) and other metrics (such as customer activity, average transaction amount per card).

[0021] All of the aforementioned events, tags, indicators, and identifiers are assigned unique numbers to ensure the uniqueness and traceability of registration information.

[0022] After registration, you can configure the achievement rules and dynamically combine the above tags, events, and indicators according to marketing needs to form rules (such as "first-time visit event + travel preference tag + weekly cumulative transactions exceeding 3,000 yuan").

[0023] In step S102, for the target financial event, target data associated with the target financial event is collected; wherein, the target data includes offline data and real-time data.

[0024] Here, all data related to the target financial event is collected, divided into offline data and real-time data. Offline data includes non-real-time data collected through IFT files (such as historical transaction summaries and batch update data of customer basic information); real-time data includes data generated in real time collected through tools such as OGG and Flume (such as real-time customer card swipe transactions and APP card binding operation logs). The data content covers credit card tracking data (such as in-app click behavior), business data (such as transaction records and installment applications), and data collected by the head office (such as customer information from head office channels).

[0025] Specifically, real-time collection of event tracking data is achieved by uploading it to Kafka via an SDK, and then synchronizing the message queue via MirrorMaker. Offline event tracking data is retrieved from HDFS files on the event tracking platform. Real-time collection of business data utilizes different log collection tools (EDB-Bridge, Sloth, and OGG) depending on the business system's library type (EverDB, GoldenDB, Oracle), with some real-time event messages proactively pushed by the business systems. Offline business data is retrieved from IFT files in various application systems and uploaded to the data service platform. The real-time portion of the data collected by the head office is synchronized from the head office's Kafka cluster to the card center's Kafka cluster via MirrorMaker2, while the offline portion is retrieved from the head office's data lake / data warehouse and uploaded to the data service platform. Other data types include gateway data, asset monitoring data from the unified monitoring platform, data collected from BPC cloud / on-premises environments, and Promethus data.

[0026] In step S103, the target data is processed to obtain basic information tags, event information and basic indicators. Based on the processing results, the real-time wide tables of customer, account and card granularity in HBase are updated and basic event-driven streams are sent out.

[0027] Here, the collected real-time data is processed, including: basic information tag processing (such as extracting customer account status), event extraction (such as identifying "first-time transaction events" from the transaction flow), and basic indicator processing (such as calculating "weekly cumulative transaction amount" in real time). Based on HBase's "partial-update" feature, the processed basic information tags, event information, and basic indicators can be partially refreshed to the "customer, account, and card granular real-time wide table" (i.e., a table integrating full information on customers, accounts, and cards), ensuring that the wide table data reflects the latest status in real time. After processing, the identified key events (such as "first-time transaction event occurrence") are encapsulated into a basic event-driven stream to trigger subsequent rule calculations.

[0028] Real-time basic metrics processing covers daily / weekly / monthly transaction volume, number of transactions, transaction amount, and check-in data across different dimensions of cards, accounts, and customers; real-time event extraction also includes events such as "cancellation" and "transaction". In addition, non-basic tags such as consumption preferences and risk attributes, which require long-term data accumulation, are refreshed into the customer, account, and card HBase wide tables according to the offline data update cycle.

[0029] In step S104, based on the basic event-driven flow trigger rule calculation, the rule collision logic is called to match the compliance rule information with the real-time wide tables of customers, accounts, and cards stored in HBase to generate compliance messages.

[0030] Rule calculation is based on event-driven stream triggering, with the core being "rule collision logic." By calling the Flink engine, the configured qualifying rule information is matched with the real-time updated "customer, account, and card wide tables" in HBase (e.g., determining whether a customer simultaneously meets the criteria of "first-time transaction event," "travel preference tag," and "weekly cumulative transactions exceeding 3000 yuan"). If the match is successful, a qualifying message is generated (e.g., "Customer A meets the conditions for the 'first-time transaction exceeding 3000 yuan to receive a travel voucher' activity").

[0031] In rule collision detection, custom UDF functions also support marketing campaign priority judgment (issuing higher priority results based on the achievement results of multiple campaigns) and campaign status identification (allowing for emergency suspension, shutdown, or resumption of campaigns in case of emergencies; achievement calculations are not performed during suspension). When selecting customer groups, marketers can select customer group lists and blacklist / whitelist identifiers on the front end to block or include specific customer groups.

[0032] In step S105, the achievement message is pushed to the target customer.

[0033] Finally, through the "marketing channel push module", the achievement message is sent to the target customers through channels such as SMS, APP push, and official account notification to achieve marketing reach (such as APP pop-up prompts to claim coupons).

[0034] Marketing channels cover SMS, APP, official account, mini program, intelligent customer service, email, etc., to achieve omnichannel reach and ultimately achieve real-time event-driven full-touchpoint management centered on improving user experience.

[0035] In some embodiments, the method further includes: The constraint content is defined based on the rule constraint framework, and the constraint content includes process constraints, event definition constraints, label definition constraints, indicator definition constraints, and configuration constraints. The process constraints are used to constrain the entire process of marketing campaign configuration, data collection, real-time calculation, offline calculation, rule collision, target achievement message issuance, reconciliation, and compensation. The event definition constraints, tag definition constraints, and indicator definition constraints are used to ensure that the registered events, tags, and indicators are consistent with the business scope of big data computing. The configuration constraints are used to limit the matching of the compliance rule information with the rule collision parsing logic of big data processing.

[0036] The rule constraint framework is a constraint system designed to avoid problems such as inconsistent data definitions and unresolved rules in the marketing process. Specifically, it includes: (1) Process constraints: This includes marketing campaign configuration (front-end rule settings), data collection (offline / real-time data acquisition), real-time computation (Flink engine processing), offline computation (Spark / MapReduce processing), rule collision (rules matching with wide tables), achievement message delivery (pushing to channels), reconciliation (comparing real-time and offline results), and compensation (processing discrepancies).

[0037] Violating process constraints (such as starting rule calculations before data collection is completed) can lead to marketing campaigns failing (e.g., no data to match the rules) or errors occurring (e.g., message push failures).

[0038] (2) Event / tag / metric definition constraints: Events (such as "first-time purchase"), tags (such as "high-income group"), and metrics (such as "10 cumulative transactions per week") registered on the front end must be consistent with the business criteria agreed upon by the big data computing side (real-time / offline computing module).

[0039] For example: If the front end defines "first swipe" as "first purchase after activation", while the big data side defines it as "first purchase after card activation", it will lead to event recognition errors (such as misjudging that the target is not met).

[0040] (3) Configuration constraints: The qualifying rules configured on the front end (such as "first visit + travel preference") must match the rule collision parsing logic processed by big data (such as the parsing algorithm of the Flink engine). If they do not match (such as the use of undefined tags in the rules), the rules cannot be parsed, and ultimately it will be impossible to determine whether the customer meets the criteria.

[0041] In some embodiments, the offline data is collected via IFT files, and the real-time data is collected via at least one of the OGG tool, Flume tool, and MirrorMaker2 tool. The target data includes credit card tracking data, business data, head office data, and other types of data. The head office data is synchronized from the head office Kafka to the card center using the MirrorMaker2 tool.

[0042] Here, offline data is collected by using IFT files (offline data transfer files) to collect non-real-time, batch-generated data (such as daily customer tag summaries and batch export of historical transaction details). Real-time data is collected using at least one of OGG (Oracle GoldenGate, a real-time data synchronization tool), Flume (a log collection tool), and MirrorMaker2 (a Kafka cross-cluster synchronization tool). OGG is used to synchronize real-time database changes (such as account status updates); Flume is used to collect application log data (such as APP operation tracking logs); and MirrorMaker2 is used to synchronize Kafka data across clusters (such as Kafka data synchronization between the head office and the card center).

[0043] The target data includes credit card event tracking data, business data, head office-collected data, and other types of data. Credit card event tracking data refers to customer behavior data within the credit card app (such as clicking the "Claim Coupon" button or browsing installment payment pages); business data refers to core credit card business data (such as transaction records, installment applications, and repayment records); head office-collected data is data collected from head office channels (such as the head office app and official WeChat account) and then transferred to the credit card center (such as basic customer information in the head office Kafka). This type of data is synchronized from the head office Kafka cluster to the card center Kafka cluster using the MirrorMaker2 tool; other types of data include customer preference data provided by external partners and third-party risk rating data. The head office-collected data is stored in the head office Kafka, and the card center needs to synchronize the data from the head office Kafka to the card center Kafka using MirrorMaker2 (Kafka's official cross-cluster synchronization tool) to ensure that the card center can obtain customer data from head office channels in real time.

[0044] In some embodiments, see Figure 2 , Figure 2 This is a flowchart illustrating steps S201-S203 provided in the embodiments of this application. The step of processing the target data to obtain basic information tags, event information, and basic indicators, and updating the real-time wide tables of customer, account, and card granularity in HBase based on the processing results, and issuing basic event-driven streams can be achieved through steps S201-S203, which will be explained in conjunction with each step.

[0045] In step S201, basic information labeling, event extraction, and basic indicator processing are performed on the real-time data.

[0046] In step S202, based on HBase's partial-update feature, the processed basic information tags, event information, and basic indicators are partially refreshed to the real-time wide table at the customer, account, and card granularities.

[0047] In step S203, the basic event-driven stream is generated and sent out based on the processed event information.

[0048] Here, the collected real-time data (such as real-time transactions and APP operations) is processed to generate basic information tags, event information, and basic indicators that can be used for rule matching, and the HBase wide table is updated to trigger subsequent rule calculations.

[0049] For basic information tag processing, real-time basic information about customers, accounts, and cards is extracted (such as the customer's current account balance and whether the card status is normal). For event extraction, key events are identified from the real-time data stream (such as extracting the "card binding event" when a customer completes the card binding operation). For basic indicator processing, real-time available basic indicators are calculated (such as "cumulative weekly consumption amount after the current transaction" and "number of transactions per day"). Utilizing HBase's "partial-update" feature (which supports updating only some fields in a table instead of the entire table), the processed basic information tags, event information, and basic indicators are partially refreshed to the "real-time wide table at the customer, account, and card granularity" (e.g., updating only the "card binding status" field without rewriting the entire table), ensuring the real-time nature of the wide table data and reducing resource consumption. Finally, the extracted key events (such as the "first swipe event") are encapsulated into a basic event-driven stream and pushed to the rule calculation module to trigger subsequent rule collision logic (e.g., determining whether the event meets the eligibility rules of a certain marketing campaign).

[0050] In some embodiments, see Figure 3 , Figure 3 This is a flowchart illustrating steps S301-S303 provided in the embodiments of this application. The step of processing the target data to obtain basic information tags, event information, and basic indicators, and updating the real-time wide tables of customer, account, and card granularity in HBase based on the processing results, and issuing basic event-driven streams can also be achieved through steps S301-S303, which will be explained in conjunction with each step.

[0051] In step S301, the Spark engine or MapReduce engine is used to process and obtain non-basic information tags, derived indicators, and the offline status of first-time swipe and card binding events.

[0052] In step S302, offline wide tables with customer, account, and card granularities are constructed based on the processing results and stored in HBase.

[0053] In step S303, the compliance rule information is compared with the offline wide table of customer, account, and card granularity to generate offline compliance results.

[0054] Here, offline data processing tools utilize Spark (an in-memory computing engine) or MapReduce (a distributed computing framework), suitable for scenarios requiring long-term computation and large data volumes (such as long-term customer consumption preference analysis). Processing includes generating non-basic information tags (such as a deep preference tag like "travel consumption accounted for over 50% in the past 3 months"), derived indicators (such as "average monthly consumption = total consumption / number of months," calculated based on basic indicators), and offline status of events like first-time purchases / card binding (such as a summary of historical first-time purchase records). Then, the processed non-basic tags, derived indicators, and event offline statuses are integrated to build an offline wide table, which is stored in HBase. The offline wide table supplements the real-time wide table, storing long-term data that cannot be obtained through real-time computation (such as annual consumption trends) and providing a data foundation for subsequent "reconciliation and compensation." Finally, based on the compliance rules configured on the front end, the data in the offline wide table is matched against the rules (such as matching "travel preference tags in the past 3 months" with the "travel-related marketing activities" rule) to generate offline compliance results (i.e., the result determining whether a customer meets the criteria from the perspective of offline data).

[0055] The offline calculation module also includes customer segmentation and processing, which is divided into fixed customer groups and dynamic customer groups. Fixed customer groups are imported all at once at the start of the activity and are not updated during the activity, forming a long-term list; dynamic customer groups are updated on a daily, weekly, monthly or activity cycle basis.

[0056] In some embodiments, the rule calculation is based on the Flink engine calling a custom UDF function to execute rule collision logic. The custom UDF function includes at least one of the following functions: Scheduled rule reloading loads the latest compliance rule information according to a preset cycle. Derivative indicators are calculated based on the basic indicators. Field condition matching involves matching the compliance rules with fields in the real-time wide tables for customers, accounts, and cards. Customer segmentation and judgment: Determine whether the target customers belong to the pre-selected customer group; Cross-rule evaluation involves cross-validating multiple compliance rules. Event-driven multi-marketing campaign compliance assessment: This involves verifying compliance across multiple marketing campaigns triggered by the same event and generating a set of compliance results.

[0057] Here, in this embodiment, rule computation is based on the Flink engine (a real-time computing engine that supports low-latency processing) calling a custom UDF (user-defined function, used to extend engine functionality) to execute rule collision logic, ensuring the real-time nature and flexibility of rule matching. The functions of the custom UDF include: Scheduled rule reloading: Load the latest compliance rule information at a preset period (e.g., every 5 seconds) (the front end may dynamically modify the rules) to ensure that the rule calculation uses the latest configuration (e.g., after the rule is modified, it will take effect within a maximum of 5 seconds).

[0058] Derivative indicator calculation: Based on the basic indicators (such as "weekly consumption amount" and "weekly number of transactions") obtained in real time, derivative indicators (such as "average order value = weekly consumption amount / weekly number of transactions") are calculated to meet the judgment requirements of the rules for derivative indicators (such as "average order value exceeds 500 yuan").

[0059] Field condition matching: The fields in the criteria rules (such as "first-time event + high income tag") are matched with the corresponding fields in the HBase real-time wide table (such as "event status = first-time event completed" and "income tag = high income") to determine whether the conditions are met.

[0060] Customer segmentation judgment: If the marketing campaign targets a specific customer segment (such as "credit card platinum card customers"), then determine whether the target customer belongs to that customer segment (by querying the "card level" label in the wide table).

[0061] Cross-rule verification: When the eligibility criteria involve multiple rules (such as "first-time purchase and weekly spending exceeding 3,000 yuan, with no overdue records"), the multiple rules are cross-verified to ensure that all conditions are met simultaneously before the criteria are deemed met.

[0062] Event-driven multi-marketing campaign compliance assessment: The same event (such as "first swipe") may trigger multiple marketing campaigns (such as "first swipe coupon" or "first swipe credit limit increase invitation"). The rules of each campaign need to be verified to meet the requirements, and finally a result set containing all the campaigns that meet the requirements is generated (if a customer meets the requirements of 3 campaigns at the same time, the result set contains the compliance information of these 3 campaigns).

[0063] Through the logical processing of the above UDF function, the final set of achievement results is generated, which serves as the core content of the achievement message (such as "Customer A meets the achievement conditions of Activity 1 and Activity 3").

[0064] In some embodiments, the method further includes: The real-time achievement results corresponding to the achievement messages are compared with the offline achievement results obtained through offline calculation to obtain the difference data; The discrepancy data is compensated and confirmed, and a compensation compliance message is generated; The notification that the compensation has been met will be issued.

[0065] Here, the embodiments of this application generate achievement messages based on real-time data and real-time wide tables (e.g., "Customer A's first purchase has been achieved"); and achievement results generated based on offline data and offline wide tables (e.g., confirming from historical data that "Customer A has indeed completed the first purchase"). Because real-time calculations may have a few omissions (e.g., real-time data loss due to network fluctuations) or some combined conditions may not be covered (e.g., long-term indicators not calculated in real-time), discrepancies need to be identified through comparison (e.g., real-time determination of non-achievement, but offline determination of achievement). After obtaining the discrepancy data, compensation confirmation is performed (e.g., manual review or automatic system verification of the cause of the discrepancy). If it is confirmed to be due to a real-time calculation omission, a compensation achievement message is generated (e.g., "Re-issued the first purchase achievement coupon to Customer A"). Afterwards, the compensation achievement message is pushed to the target customers to ensure comprehensive marketing coverage and reduce customer complaints caused by real-time calculation errors (e.g., customers actually achieved the target but did not receive the message).

[0066] Below, we will combine Figure 4 , Figure 5 , Figure 6 The embodiments of this application will be described in full.

[0067] Please see Figure 4 , Figure 5 , Figure 6 , Figure 4 This is a schematic diagram of the event marketing configuration process provided in the embodiments of this application. Figure 5 This is a schematic diagram of the functional modules provided in the embodiments of this application. Figure 6 This is a schematic diagram of the internal data flow provided in the embodiments of this application, such as... Figure 4 , Figure 5 , Figure 6 As shown, this application's embodiment constructs a real-time dynamic marketing system based on "financial event-driven" principles. Through four key stages—marketing front-end configuration, data collection and processing, rule calculation and matching, and marketing outreach—and combined with a process and rule constraint framework, it achieves a closed-loop process from event definition to customer outreach. The core logic is: driven by financial events (first-time purchase, card binding, etc.), it integrates customer, account, and card data, and accurately reaches target customers by matching qualifying rules through real-time and offline calculations. The process covers the entire lifecycle of "configuration-collection-calculation-matching-outreach," ensuring marketing accuracy and real-time performance.

[0068] The marketing front end is the entry point for business needs and is responsible for defining the core elements of marketing: In the "Registration (Events, Tags, Metrics, etc.) Configuration" module, this embodiment of the application completes three types of core registrations: Event registration: Define key events in financial scenarios such as first swipe, card binding, and first activation (e.g., "first credit card swipe transaction completed"). Tag registration: Build a tag system for customers, accounts, and cards, based on basic information (name, account type), preferences (travel consumption preferences), and risks (credit delinquency risk); Indicator registration: Define the core indicator (weekly cumulative transaction amount) and other indicators (average transaction amount per card) to provide "data atoms" for rule configuration.

[0069] Each event, tag, and metric has a unique number to ensure that registration information is unique and traceable.

[0070] The "Meeting Rules (Dynamic Combination of Conditions) Configuration" allows for the dynamic combination of registered events, tags, and metrics into marketing rules (e.g., "First-time visit event + travel preference tag + weekly cumulative transactions exceeding 3000 yuan → triggering travel voucher marketing"). The rules must comply with the "Rule Constraint Framework" (process, event, tag, metric, configuration constraints) to ensure consistency with big data calculation standards.

[0071] Regarding data acquisition, the embodiments of this application cover both offline and real-time data, providing a foundation for computation. Data types include: Offline data: Collect historical credit card transactions and batch customer tag data through IFT files; Real-time data: Utilizing tools such as OGG (real-time database synchronization), Flume (log collection), and MirrorMaker2 (Kafka cross-cluster synchronization), we collect credit card event tracking (APP click behavior), business data (real-time transactions), and head office data (head office Kafka synchronized to the card center), covering all dimensions of "credit card business data, financial transaction data, event tracking data, and head office data".

[0072] Data from data tracking points is reported to Kafka in real time via SDK and synchronized via MirrorMaker, and is also retrieved offline from HDFS; business data is collected in real time according to system library type using EDB-Bridge, Sloth, and OGG, and is retrieved offline as IFT files; head office data is synchronized to Kafka in real time using MirrorMaker2, and is retrieved offline as IFT files from the head office data lake / warehouse.

[0073] The collected data enters the "real-time processing layer" and the "offline buffer data layer" to support real-time computing and offline computing, respectively.

[0074] Data processing and computation are handled through a dual-engine approach: real-time and offline processing. Real-time computation is based on the Flink engine, performing "streaming computation" on real-time data. This includes basic information tagging: extracting real-time customer account status and card benefits information; event extraction: identifying events such as first-time transactions, cancellations, transactions, and card bindings from the transaction stream (e.g., if "transaction type = first-time transaction", then "first-time transaction event completed"); and indicator processing: calculating core indicators in real-time (e.g., "weekly cumulative transaction amount" is updated with each transaction, including daily / weekly / monthly transaction volume, number of transactions, etc.). Leveraging HBase's partial-update feature, the processing results are partially refreshed to the "customer, account, and card granularity real-time wide table" (e.g., only updating the "first swipe event status" field) to ensure data real-time performance. This generates a "basic event-driven stream" (e.g., the "first swipe event trigger stream"), which is then pushed to the rule calculation module. Non-basic tags such as consumption preferences are refreshed into the HBase wide table according to offline cycles.

[0075] Offline computing utilizes the Spark / MapReduce engine to process offline data, such as processing derived tags and metrics, generating tags that require long-term calculations (e.g., "tourism spending accounts for over 60% in the past 3 months") and derived metrics (e.g., "average monthly spending = total spending / number of months"). Historical data is integrated to construct an "offline wide table with customer, account, and card granularity," storing the historical status of events such as first-time transactions and card binding, supplementing the long-term perspective of the real-time wide table, and finally generating offline achievement results (e.g., "customer's historical first-time transaction achievement records"), which are then verified in conjunction with real-time results.

[0076] This application's embodiment completes rule matching based on real-time and offline calculation results: rule calculation is triggered by a "basic event-driven flow" (such as the first-swipe event flow); a custom UDF function of the Flink engine is called to execute the "rule collision logic," updating the qualifying rules periodically (such as every 5 seconds) to ensure rule real-time performance; derived indicators (such as average monthly consumption) are derived based on real-time indicators; qualifying rules (such as "first-swipe + travel preference") are matched with HBase real-time wide table fields (event status, tag value); it is determined whether the customer belongs to the target customer group (such as platinum card customers), and multiple rule cross conditions (such as "first-swipe and no overdue risk") are verified; and a "real-time qualifying message" (such as "customer A meets the 'first-swipe qualifying coupon' rule") is generated.

[0077] Offline calculation generates "offline achievement results" (based on offline wide table backtracking verification), which are compared with real-time results to identify discrepancies (such as real-time missed achievement events); by "compensation confirmation" of the discrepancies, "compensation achievement messages" are generated to ensure that no marketing is missed.

[0078] Real-time and compensation achievement messages are entered into the "Achievement Data Global Processing" module and integrated into a unified message format. These messages are then pushed to target customers through "marketing channels" (SMS, app push notifications, official accounts, mini-programs, etc.), covering marketing scenarios such as "promoting consumption, promoting first-time purchases, and promoting card binding." Marketing scenarios are matched based on event type (e.g., a first-time purchase event triggers a "first-time purchase achievement gift" notification), achieving precise mapping between "event-rule-scenario-customer."

[0079] The process constraints in this application cover the entire chain of "marketing campaign configuration → data collection → real-time / offline calculation → rule collision → outreach → reconciliation / compensation", constraining the execution order and standards of each step (e.g., "rule calculation must not be triggered if data collection is not completed"); the definitions of events, tags, and indicators must be consistent with the big data calculation caliber (e.g., "first-time transaction event" must simultaneously satisfy "transaction type = first-time transaction" and "account status = normal"); the compliance rules must match the rule collision logic (e.g., the "travel preference tag" in the rule must be consistent with the tag storage format in the wide table) to avoid parsing failure.

[0080] For data flow and collaboration, this application's embodiments employ a dual-track approach of real-time and offline processing: Real-time stream: Data → Real-time acquisition → Flink computation → HBase real-time wide table update → Rule collision → Real-time delivery; Offline Stream: Data → Offline Collection → Spark / MapReduce Computation → HBase Offline Wide Table Construction → Offline Verification → Compensation Outreach; Real-time streaming ensures "instant response" (such as reaching customers within seconds after the first swipe), while offline streaming supplements long-term data through "backtracking and verification" (such as historical consumer preference analysis). This dual-track approach ensures the accuracy and completeness of marketing efforts.

[0081] In summary, the embodiments of this application have the following beneficial effects: By constructing a financial event-driven marketing system, and through the registration and rule configuration of multi-dimensional tags, events, and indicators for customers, accounts, and cards, this system integrates real-time and offline data collection and processing. Leveraging HBase wide tables, rule collision detection, and multi-channel outreach, it achieves improvements in accuracy, real-time performance, and standardization. In terms of accuracy, multi-dimensional data matching and dual-calculation collaborative verification precisely target customer groups and fill marketing gaps. Regarding real-time performance, event-driven low-latency response and dynamic rules take effect quickly, seizing golden marketing opportunities and flexibly adapting to business changes. In terms of standardization, end-to-end constraints and data rule adaptation ensure compliant and efficient business operations, ultimately helping financial institutions improve marketing effectiveness, optimize customer experience, and build a closed-loop business value chain of "marketing-feedback-iteration."

[0082] Based on the same inventive concept, this application also provides a financial event-driven real-time dynamic marketing device corresponding to the financial event-driven real-time dynamic marketing method in the first embodiment. Since the principle of the device in this application is similar to that of the above-mentioned financial event-driven real-time dynamic marketing method, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0083] like Figure 7 As shown, Figure 7This is a schematic diagram of the structure of the financial event-driven real-time dynamic marketing device 700 provided in this application embodiment. The financial event-driven real-time dynamic marketing device 700 includes: The registration module 701 is used to register target financial events and configure corresponding compliance rules for the registered target financial events. The registration process includes tag registration, event registration, and indicator registration. Tags include basic information tags, preference tags, and risk tags for customers, accounts, and cards, respectively. Events include first-swipe events, card binding events, and first activation events. Indicators include core indicators and other indicators. The acquisition module 702 is used to acquire target data associated with the target financial event; wherein the target data includes offline data and real-time data. The processing module 703 is used to process the target data to obtain basic information tags, event information and basic indicators, and update the real-time wide tables of customer, account and card granularity in HBase based on the processing results, and issue basic event-driven streams. The calculation module 704 is used to calculate the rules based on the basic event-driven flow, call the rule collision logic to match the compliance rule information with the real-time wide tables of customers, accounts, and cards stored in HBase, and generate compliance messages. The push module 705 is used to push the achievement message to the target customer.

[0084] Those skilled in the art should understand that Figure 7 The functions of each unit in the financial event-driven real-time dynamic marketing device 700 shown can be understood by referring to the relevant description of the aforementioned financial event-driven real-time dynamic marketing method. Figure 7 The functions of each unit in the financial event-driven real-time dynamic marketing device 700 shown can be implemented by a program running on a processor or by specific logic circuits.

[0085] In one possible implementation, the registration module 701 further includes: The constraint content is defined based on the rule constraint framework, and the constraint content includes process constraints, event definition constraints, label definition constraints, indicator definition constraints, and configuration constraints. The process constraints are used to constrain the entire process of marketing campaign configuration, data collection, real-time calculation, offline calculation, rule collision, target achievement message issuance, reconciliation, and compensation. The event definition constraints, tag definition constraints, and indicator definition constraints are used to ensure that the registered events, tags, and indicators are consistent with the business scope of big data computing. The configuration constraints are used to limit the matching of the compliance rule information with the rule collision parsing logic of big data processing.

[0086] In one possible implementation, the offline data is acquired via IFT files, and the real-time data is acquired via at least one of the OGG tool, Flume tool, and MirrorMaker2 tool. The target data includes credit card tracking data, business data, head office data, and other types of data. The head office data is synchronized from the head office Kafka to the card center using the MirrorMaker2 tool.

[0087] In one possible implementation, the processing module 703 processes the target data to obtain basic information tags, event information, and basic indicators. Based on the processing results, it updates the real-time wide tables in HBase at the customer, account, and card granularities and issues a basic event-driven stream, including: Perform basic information tagging, event extraction, and basic indicator processing on real-time data; Based on HBase's partial-update feature, the processed basic information tags, event information, and basic indicators are partially refreshed to real-time wide tables at the customer, account, and card granularities. The basic event-driven stream is generated and distributed based on the processed event information.

[0088] In one possible implementation, the processing module 703 processes the target data to obtain basic information tags, event information, and basic indicators. Based on the processing results, it updates the real-time wide tables in HBase at the customer, account, and card granularities and issues a basic event-driven stream, including: The Spark or MapReduce engine is used to process non-basic information tags, derived metrics, and offline status of first-time swipe and card binding events; Based on the processing results, offline wide tables with customer, account, and card granularities are constructed and stored in HBase; Based on the compliance rule information, rule collision is performed with the offline wide tables of customer, account, and card granularity to generate offline compliance results.

[0089] In one possible implementation, the rule calculation is based on the Flink engine calling a custom UDF function to execute rule collision logic, wherein the custom UDF function includes at least one of the following functionalities: Scheduled rule reloading loads the latest compliance rule information according to a preset cycle. Derivative indicators are calculated based on the basic indicators. Field condition matching involves matching the compliance rules with fields in the real-time wide tables for customers, accounts, and cards. Customer segmentation and judgment: Determine whether the target customers belong to the pre-selected customer group; Cross-rule evaluation involves cross-validating multiple compliance rules. Event-driven multi-marketing campaign compliance assessment: This involves verifying compliance across multiple marketing campaigns triggered by the same event and generating a set of compliance results.

[0090] In one possible implementation, the computing module 704 further includes: The real-time achievement results corresponding to the achievement messages are compared with the offline achievement results obtained through offline calculation to obtain the difference data; The discrepancy data is compensated and confirmed, and a compensation compliance message is generated; The notification that the compensation has been met will be issued.

[0091] The aforementioned financial event-driven real-time dynamic marketing device constructs a financial event-driven marketing system. Through the registration and rule configuration of multi-dimensional tags, events, and indicators for customers, accounts, and cards, it integrates real-time and offline data collection and processing. Relying on HBase wide tables, rule collision detection, and multi-channel outreach, it achieves improvements in accuracy, real-time performance, and standardization. In terms of accuracy, multi-dimensional data matching and dual-calculation collaborative verification accurately target customer groups and fill marketing gaps. Regarding real-time performance, event-driven low-latency response and rapid dynamic rule activation seize marketing opportunities and flexibly adapt to business changes. In terms of standardization, end-to-end constraints and data rule adaptation ensure compliant and efficient business operations, ultimately helping financial institutions improve marketing effectiveness, optimize customer experience, and build a closed-loop business value system of "marketing-feedback-iteration."

[0092] like Figure 8 As shown, Figure 8 This is a schematic diagram of the composition structure of the electronic device 800 provided in the embodiments of this application. The electronic device 800 includes: The device includes a processor 801, a storage medium 802, and a bus 803. The storage medium 802 stores machine-readable instructions executable by the processor 801. When the electronic device 800 is running, the processor 801 communicates with the storage medium 802 via the bus 803. The processor 801 executes the machine-readable instructions to perform the steps of the financial event-driven real-time dynamic marketing method described in the embodiments of this application.

[0093] In practical applications, the various components in the electronic device 800 are coupled together via bus 803. It can be understood that bus 803 is used to achieve communication between these components. In addition to a data bus, bus 803 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in... Figure 8 The general labeled all buses as Bus 803.

[0094] The aforementioned electronic devices construct a financial event-driven marketing system. Through the registration and rule configuration of multi-dimensional tags, events, and indicators for customers, accounts, and cards, and by integrating real-time and offline data collection and processing, and relying on HBase wide tables, rule collision, and multi-channel outreach, they achieve improvements in accuracy, real-time performance, and standardization. In terms of accuracy, multi-dimensional data matching and dual-calculation collaborative verification accurately target customer groups and fill marketing gaps. In terms of real-time performance, event-driven low-latency response and dynamic rules take effect quickly, seizing the golden marketing window and flexibly adapting to business changes. In terms of standardization, full-process constraints and data rule adaptation ensure business compliance and efficient operation, ultimately helping financial institutions improve marketing effectiveness, optimize customer experience, and build a closed-loop business value system of "marketing-feedback-iteration".

[0095] This application also provides a computer-readable storage medium storing executable instructions. When the executable instructions are executed by at least one processor 801, the financial event-driven real-time dynamic marketing method described in this application is implemented.

[0096] In some embodiments, the storage medium may be a magnetic random access memory (FRAM), a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM), etc.; or it may be a device that includes one or any combination of the above-mentioned memories.

[0097] In some embodiments, executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0098] As an example, executable instructions may, but do not necessarily, correspond to files in the file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple collaborating files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0099] As an example, executable instructions can be deployed to execute on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network.

[0100] The aforementioned computer-readable storage medium, by constructing a financial event-driven marketing system, leverages the registration and rule configuration of multi-dimensional tags, events, and indicators for customers, accounts, and cards. It integrates real-time and offline data collection and processing, relying on HBase wide tables, rule collision analysis, and multi-channel outreach to achieve improvements in accuracy, real-time performance, and standardization. In terms of accuracy, multi-dimensional data matching and dual-calculation collaborative verification precisely target customer groups and fill marketing gaps. Regarding real-time performance, event-driven low-latency response and dynamic rules take effect quickly, seizing golden marketing opportunities and flexibly adapting to business changes. In terms of standardization, end-to-end constraints and data rule adaptation ensure compliant and efficient business operations, ultimately helping financial institutions improve marketing effectiveness, optimize customer experience, and build a closed-loop business value chain of "marketing-feedback-iteration."

[0101] In the several embodiments provided in this application, it should be understood that the disclosed methods and electronic devices can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components may be combined, or integrated into another system, or some features may be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed may be through some interfaces, and the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0102] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0103] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0104] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a platform server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

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

Claims

1. A financial event-driven real-time dynamic marketing method, characterized in that, The method includes: The target financial events are registered, and corresponding compliance rules are configured for the registered target financial events. The registration process includes tag registration, event registration, and indicator registration. Tags include basic information tags, preference tags, and risk tags for customers, accounts, and cards, respectively. Events include first-time swipe events, card binding events, and first activation events. Indicators include core indicators and other indicators. For the target financial event, target data associated with the target financial event is collected; wherein, the target data includes offline data and real-time data; The target data is processed to obtain basic information tags, event information and basic indicators. Based on the processing results, the real-time wide tables of customer, account and card granularity in HBase are updated and basic event-driven streams are sent out. Based on the basic event-driven flow trigger rule calculation, the rule collision logic is called to match the compliance rule information with the real-time wide tables of customers, accounts, and cards stored in HBase to generate compliance messages; The achievement message will be pushed to the target customers.

2. The method according to claim 1, characterized in that, The method further includes: The constraint content is defined based on the rule constraint framework, and the constraint content includes process constraints, event definition constraints, label definition constraints, indicator definition constraints, and configuration constraints. The process constraints are used to constrain the entire process of marketing campaign configuration, data collection, real-time calculation, offline calculation, rule collision, target achievement message issuance, reconciliation, and compensation. The event definition constraints, tag definition constraints, and indicator definition constraints are used to ensure that the registered events, tags, and indicators are consistent with the business scope of big data computing. The configuration constraints are used to limit the matching of the compliance rule information with the rule collision parsing logic of big data processing.

3. The method according to claim 1, characterized in that, The offline data is collected via IFT files, and the real-time data is collected via at least one of the OGG tool, Flume tool, and MirrorMaker2 tool. The target data includes credit card tracking data, business data, head office data, and other types of data. The head office data is synchronized from the head office Kafka to the card center using the MirrorMaker2 tool.

4. The method according to claim 1, characterized in that, The target data is processed to obtain basic information tags, event information, and basic indicators. Based on the processing results, the real-time wide tables at the customer, account, and card granularities in HBase are updated, and basic event-driven streams are issued, including: Perform basic information tagging, event extraction, and basic indicator processing on real-time data; Based on HBase's partial-update feature, the processed basic information tags, event information, and basic indicators are partially refreshed to real-time wide tables at the customer, account, and card granularities. The basic event-driven stream is generated and distributed based on the processed event information.

5. The method according to claim 1, characterized in that, The target data is processed to obtain basic information tags, event information, and basic indicators. Based on the processing results, the real-time wide tables at the customer, account, and card granularities in HBase are updated, and basic event-driven streams are issued, including: The Spark or MapReduce engine is used to process non-basic information tags, derived metrics, and offline status of first-time swipe and card binding events; Based on the processing results, offline wide tables with customer, account, and card granularities are constructed and stored in HBase; Based on the compliance rule information, rule collision is performed with the offline wide tables of customer, account, and card granularity to generate offline compliance results.

6. The method according to claim 1, characterized in that, The rule calculation is based on the Flink engine calling a custom UDF function to execute rule collision logic. The custom UDF function includes at least one of the following functions: Scheduled rule reloading loads the latest compliance rule information according to a preset cycle. Derivative indicators are calculated based on the basic indicators. Field condition matching involves matching the compliance rules with fields in the real-time wide tables for customers, accounts, and cards. Customer segmentation and judgment: Determine whether the target customers belong to the pre-selected customer group; Cross-rule evaluation involves cross-validating multiple compliance rules. Event-driven multi-marketing campaign compliance assessment: This involves verifying compliance across multiple marketing campaigns triggered by the same event and generating a set of compliance results.

7. The method according to claim 5, characterized in that, The method further includes: The real-time achievement results corresponding to the achievement messages are compared with the offline achievement results obtained through offline calculation to obtain the difference data; The discrepancy data is compensated and confirmed, and a compensation compliance message is generated; The notification that the compensation has been met will be issued.

8. A financial event-driven real-time dynamic marketing device, characterized in that, The device includes: The registration module is used to register target financial events and configure corresponding compliance rules for the registered target financial events. The registration process includes tag registration, event registration, and indicator registration. Tags include basic information tags, preference tags, and risk tags for customers, accounts, and cards, respectively. Events include first-swipe events, card binding events, and first activation events. Indicators include core indicators and other indicators. The data acquisition module is used to acquire target data associated with the target financial event; wherein the target data includes offline data and real-time data. The processing module is used to process the target data to obtain basic information tags, event information and basic indicators, and update the real-time wide tables of customer, account and card granularity in HBase based on the processing results, and issue basic event-driven streams. The calculation module is used to calculate the rules based on the basic event-driven flow, call the rule collision logic to match the compliance rule information with the real-time wide tables of customers, accounts, and cards stored in HBase, and generate compliance messages; The push module is used to push the achievement message to the target customer.

9. An electronic device, characterized in that, include: The device includes a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the financial event-driven real-time dynamic marketing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the financial event-driven real-time dynamic marketing method as described in any one of claims 1 to 7.

Images