Information active group sending method

Abstract

The invention discloses an information active group sending method, which belongs to the technical field of information distribution, and comprises the following steps: triggering a task and analyzing to generate task metadata; capturing real-time features of users, generating dynamic tags, and screening effective users; generating compliant personalized single instance content in combination with the dynamic tag matching material; an optimal channel is matched and sent through a high-concurrency mechanism, and full-process compliance monitoring is executed; according to the method, the accuracy is improved through dynamic label and personalized content generation, the sending efficiency is guaranteed by means of high-concurrency scheduling and channel optimization, the risk is avoided through full-process compliance monitoring, the effect is continuously optimized by means of automatic iteration, and the method has the advantages of being high in practicability and high in practicability. The method solves the problems of low precision, poor efficiency and insufficient compliance of an existing group sending method, and is suitable for various large-scale information active distribution scenes.

Description

Technical Field

[0001] This invention belongs to the field of information distribution technology, and specifically relates to a method for proactively sending mass information. Background Technology

[0002] Against the backdrop of rapid development in information interaction technology, mass messaging, as an efficient means of information transmission, has been widely used in various data distribution scenarios. However, with the surge in data volume and the increasing sophistication of user needs, traditional mass messaging technologies face multiple challenges related to real-time performance, accuracy, stability, and compliance.

[0003] Existing mass messaging methods generally suffer from problems such as insufficient targeting accuracy, low content personalization, limited sending efficiency, and incomplete compliance control. Traditional mass messaging methods often use fixed templates for batch sending, failing to adjust content based on real-time user characteristics and preferences, resulting in low click-through rates and low willingness to receive messages. Furthermore, the lack of intelligent scheduling and compliance monitoring throughout the entire sending process makes them prone to risks such as channel congestion, sending of inappropriate content, and leakage of user privacy. Moreover, strategy optimization relies on manual intervention, making it difficult to adapt to dynamically changing business needs and user behavior. Overall, the effectiveness and security of mass messaging need improvement. Summary of the Invention

[0004] To address the problems mentioned in the background section, this invention provides a proactive mass messaging method to solve the problems of low accuracy, insufficient personalization, low efficiency, poor compliance, and lagging strategy optimization in existing technologies.

[0005] To achieve the above objectives, the present invention provides the following technical solution: A method for proactively sending mass messages includes the following steps: S1: Generate mass sending instructions through preset configuration or external signal trigger, perform structured parsing of mass sending instructions to extract core parameters as task metadata, and push the task metadata to the subsequent processing flow after task conflict detection. S2: Start the sliding time window to capture the real-time features of the users to be sent, generate a dynamic tag set after feature preprocessing, perform user matching and filtering according to the filtering target in the task metadata, and output a list of valid users; S3: Call the variable template corresponding to the metadata of task S1, match the dynamic tags of each user in the list of valid users output by S2 to match the appropriate materials, fill the template to generate single instance content, and output a set of compliant personalized content after sensitivity detection and format verification. S4: Based on the compliant personalized content set output by S3, collect the status of each channel and evaluate and match the optimal channel, execute the sending through a high-concurrency control mechanism, and perform compliance verification, anomaly monitoring and privacy protection operations before, during and after sending. S5: Capture end-to-end data, including data from the sending, delivery, and user feedback stages; preprocess and perform feature association analysis on the captured end-to-end data, and train iterative strategy rules through a fusion model to form a closed-loop optimization.

[0006] Compared with the prior art, the beneficial effects of the present invention are: 1. High accuracy: By capturing real-time user characteristics to generate dynamic tags, combined with the filtering target to accurately locate effective users, and matched with user-specific dynamic tag matching materials to generate personalized content, the matching degree between information and user needs is greatly improved; 2. High sending efficiency: Employing a high-concurrency control mechanism and optimal channel matching strategy ensures rapid sending of massive tasks; 3. Strong compliance: A full-process compliance monitoring system is built from pre-send to during-send to post-send, combining sensitive detection, privacy protection and anomaly alarm mechanisms to effectively avoid the risk of violations and privacy leaks; 4. Continuous optimization: Based on full-link data, the strategy is automatically iterated, and the rules of each link can be dynamically adjusted without manual intervention. It continuously adapts to business changes and user behavior, ensuring that the mass messaging effect steadily improves. Attached Figure Description

[0007] Figure 1 This is a flowchart illustrating the process of this application. Detailed Implementation

[0008] To facilitate understanding of the technical content of this invention by those skilled in the art, the invention will be further described in detail below with reference to the accompanying drawings and specific examples. It should be understood that the specific examples described herein are merely illustrative and not intended to limit the scope of the invention.

[0009] A method for proactively sending mass messages, such as Figure 1 As shown, it includes the following steps: S1: Task triggered; Triggering mode; Preset configuration trigger: Users enter parameters such as filtering target (e.g., "inactive users within 30 days"), content type (text / multimedia / mixed) and time requirement (normal tasks ≤ 2 hours to complete sending, high priority tasks ≤ 10 minutes to complete sending) through the visual console, and generate standardized task instructions in JSON format; External signal triggering: Receive trigger requests from third-party systems (such as CRM, business middle platform) through the RESTful API interface, support synchronous / asynchronous call mode, set the interface timeout to 5s, and automatically trigger a retry mechanism of up to 3 times with a retry interval of 2s after timeout.

[0010] Structured parsing: The mass sending command is parsed by a syntax parser to extract core parameters including the task ID generated by the UUID, the target user tag set, the content template ID, the four-level sending timeliness level P0-P3 (P0 is the highest priority), the channel preference list, and the compliance control threshold (such as the daily receiving limit).

[0011] Task conflict detection and push: The execution order of high-priority tasks (P0 / P1 level) within the same user group is determined by the priority weight algorithm W = timeliness coefficient × 0.6 + user scale coefficient × 0.4. High-weight tasks occupy resources first; task metadata is pushed to the subsequent processing flow through RabbitMQ / Kafka message queue, and task tracking logs containing trigger time, trigger source, and core parameter summary are generated. The logs are stored using a blockchain notarization mechanism to ensure immutability.

[0012] S2: Real-time feature processing and user filtering; Real-time feature capture: Start a sliding time window (default size 10s, adjusted to 3s for high-priority tasks) to capture real-time features from user behavior data streams (clicks, browsing, transactions, etc.) through the Flink stream processing engine. Feature dimensions include dynamic behavior features (operation sequence in the past 1 hour), static attribute features (basic fields of user profile), and environmental features (device type, network status). The feature sampling frequency is 1000 samples / second, and the latency is controlled within 200ms.

[0013] Feature preprocessing: The original features are normalized to the [0,1] interval, invalid data are removed by the IQR rule, and the core features are retained by the feature selection method based on information gain, with a retention rate of ≥85%.

[0014] Dynamic tag generation: A dynamic tag set is generated by calculating the weighted matching degree model M=∑(F×W) / ∑W, where F is a single feature value and W is the feature weight trained by the gradient boosting tree algorithm (core feature weight ≥ 0.3, secondary feature weight ≤ 0.1). When M≥ 0.7, the tag is automatically updated. The tag set is stored in the Redis cache, and the expiration time = task validity + 12h.

[0015] User filtering and output: The rule engine executes a Boolean expression (such as "tag A ∩ tag B ∩ ¬ tag C") matching operation based on the task metadata filtering target to filter valid users; high-priority tasks start PCA dimensionality reduction optimization logic F'=UF (U is the feature vector matrix, with a cumulative variance contribution rate ≥90%), reducing the feature dimension to within 30 dimensions, reducing the filtering time by more than 60%; the list of valid users (including user ID, matching tag set, and priority score) is stored through the HDFS distributed file system, and a ready signal with user list index and task metadata is sent to S3.

[0016] S3: Single-instance content generation and compliance verification; Variable template retrieval: Based on the content type in the S1 task metadata, retrieve the variable template TPL=Fixed+Var from the template library, where Fixed is a fixed text segment (such as a brand slogan) and Var is a dynamic variable segment (such as a user nickname or personalized recommended products). The template supports version control, and historical versions are retained for 90 days.

[0017] Material matching: A mapping relationship is established between the effective set of dynamic user tags and variable fields through a feature mapping function, based on the cosine similarity algorithm Sim(M,F)=∑(M×F) / [√∑M 2 ×√∑F 2 Match suitable materials from the material library, and determine the optimal material when Sim≥0.6 (supports combinations of multiple elements such as text fragments, images, and links).

[0018] Single-instance content compositing: The replacement compositing algorithm is called to fill the corresponding fields of the template with the matching materials, generating unique single-instance content (including a unique identifier ID). The compositing process uses atomic operations to ensure data consistency.

[0019] Compliance verification and output: A sensitive detection using an AC automaton (time complexity O(L), where L is the content length) is employed. The built-in sensitive word database is updated at a frequency of ≤1 hour / time. Simultaneously, the compliance of the content format is verified (e.g., SMS messages have ≤70 characters, emails contain unsubscribe links). Unqualified content triggers a maximum of 2 material replacement retries. If it still fails to meet the requirements, it is marked as non-compliant content and stored in the exception database. A "user ID-content ID-template ID" association mapping is established for the compliant personalized content set. It is pushed to S4 through a message queue and logs containing generation time, matching similarity, and compliance detection results are recorded.

[0020] S4: Multi-channel intelligent scheduling and task sending; Channel status collection: Every 1 second, core indicators of each channel (SMS, email, APP push, etc.) are collected via SNMP protocol and HTTP interface: Availability A (0-1, 1 is fully available), Response speed S (≤500ms is excellent), Delivery rate D (30-day historical average), Load L (current concurrent users), Maximum load T (channel rated concurrent users). The collected data is stored in InfluxDB.

[0021] Optimal channel matching: The comprehensive channel state value (α=0.3, β=0.2, γ=0.3, δ=0.2) is calculated using the weighted summation algorithm State=αA+βS+γD+δ(1-L / T). Based on the AHP algorithm, a decision model is constructed with target layer (optimal channel), criterion layer (State value, cost, user preference), and solution layer (each channel). When State≥0.8, priority is given to allocation, and when State<0.5, it is marked as unavailable.

[0022] High-concurrency sending: The hash sharding algorithm ShardID=Hash(UserID)modN (N defaults to 32, supports dynamic expansion) is used to split massive tasks; the thread pool is configured Size=ceil(QPS×AvgTime) (QPS is the real-time request volume, AvgTime is the average processing time of a single task, and the statistical window = 5min), with a maximum capacity = channel maximum load T×0.8; and the token bucket algorithm token=min(Capacity, token+Rate×Δt) (Capacity = channel concurrency limit, Rate = number of tokens generated per second) is used to avoid channel overload.

[0023] Compliance monitoring and failover: Before sending: Query the user's receiving records, unsubscription status, and compliance blacklist in the cache for the past 30 days. The query complexity is O(1). Remove users who receive ≥5 times in a single day, have unsubscribed, or are on the blacklist. Sending in progress: The frequency of user reception is counted through a 24-hour sliding time window (Count=∑(Event), where Event is a single sending event). If the upper limit is exceeded, sending is paused (default 5 times / day, which can be adjusted according to task type). The 3σ algorithm is used to monitor the channel sending success rate and response time. If the indicators exceed the range of [μ-3σ,μ+3σ] (μ is the mean, σ is the standard deviation), a graded alarm is triggered and the channel task allocation weight is reduced. After sending: User privacy information is encrypted and stored using AES-256 (key rotated every 7 days), transmitted using SSL / TLS 1.3 encryption, and desensitized using SHA-256 + salt hash. Failover: When the channel State value is lower than 0.6 or three consecutive transmission failures occur, a greedy algorithm is used to prioritize the selection of alternative channels of the same type. The failover time is ≤1 second, ensuring that the task is not duplicated or lost.

[0024] S5: End-to-end data capture and automated strategy iteration; Data capture: Capture full-link data, including the sending stage (sending status, response time, channel load), the delivery stage (delivery result, delay time), and the user feedback stage (clicks, opening, unsubscribing, complaints, etc.). Collect ≥20 dimensions, push the data to relevant modules for strategy iteration in real time through the data bus, and store it in the Hive data warehouse.

[0025] Data preprocessing: Perform CRC32 integrity check on the captured data (data that fails the check is automatically discarded), process missing values ​​(fill in the mean for numerical values ​​and fill in the mode for categorical values) and outliers (remove data with |Z|>3 using the Z-score method), and extract key features using the TF-IDF algorithm and statistical methods to generate a feature vector matrix.

[0026] Feature association analysis: The correlation between features and the current strategy is analyzed using the Pearson correlation coefficient Corr(X,Y)=Cov(X,Y) / [Std(X)×Std(Y)]. Strongly correlated features with |Corr|≥0.3 are selected, and a feature-strategy association graph is constructed and stored in the Neo4j graph database.

[0027] Strategy Training and Synchronization: A fusion model (logistic regression + collaborative filtering + reinforcement learning) is invoked, with the optimization objectives of success rate, user click rate, and compliance pass rate. The iterative strategy rules are trained using the gradient descent algorithm θ=θ-η∇J(θ) (η=0.01). The training process uses 5-fold cross-validation to ensure generalization ability. The optimized rules are synchronized to the relevant processes of S1-S4 through the Kafka publish-subscribe mode, using version control and canary release mechanism (synchronizing to 10% of the servers first, and then synchronizing the whole batch after verification). The synchronization time is ≤30s.

[0028] Threshold warning and iteration cycle: Set thresholds for core performance indicators (success rate ≥95%, user click rate ≥3%, compliance pass rate ≥99.5%). If the indicators are below the threshold for 1 hour, trigger model retraining. If the indicators still fail to meet the standards after retraining, push a manual intervention notification. The regular iteration cycle is 24 hours / time, and the iteration cycle for high-priority tasks is 6 hours / time, so as to achieve continuous optimization of the strategy.

Claims

1. A method for proactively sending mass messages, characterized in that, Includes the following steps: S1: Generate mass sending instructions through preset configuration or external signal trigger, perform structured parsing of mass sending instructions to extract core parameters as task metadata, and push the task metadata to the subsequent processing flow after task conflict detection. S2: Start the sliding time window to capture the real-time features of the users to be sent, generate a dynamic tag set after feature preprocessing, perform user matching and filtering according to the filtering target in the task metadata, and output a list of valid users; S3: Call the variable template corresponding to the metadata of task S1, match the dynamic tags of each user in the list of valid users output by S2 to match the appropriate materials, fill the template to generate single instance content, and output a set of compliant personalized content after sensitivity detection and format verification. S4: Based on the compliant personalized content set output by S3, collect the status of each channel and evaluate and match the optimal channel, execute the sending through a high-concurrency control mechanism, and perform compliance verification, anomaly monitoring and privacy protection operations before, during and after sending. S5: Capture end-to-end data, including data from the sending, delivery, and user feedback stages; preprocess and perform feature association analysis on the captured end-to-end data, and train iterative strategy rules through a fusion model to form a closed-loop optimization.

2. The method for proactively sending mass messages according to claim 1, characterized in that, In S1, the default configuration trigger is: inputting default conditions including filtering targets, content types, and timeliness requirements through the visual console to generate standardized task instructions in JSON format; the external signal trigger is: receiving trigger requests from third-party systems through the API interface.

3. The method for proactively sending mass messages according to claim 2, characterized in that, In S1, structured parsing is implemented through a syntax parser. The core parameters extracted include the task ID generated by the UUID, the target user tag set, the content template ID, the P0-P3 four-level sending timeliness level, the channel preference list, and the compliance control threshold. Task conflict detection is achieved by sorting tasks using a priority weight algorithm; task metadata is pushed via a message queue.

4. The method for proactively sending mass messages according to claim 3, characterized in that, In S2, dynamic behavioral features, static attribute features, and environmental features are captured from user behavior data streams through the Flink stream processing engine; Feature preprocessing includes normalizing the original features to the [0,1] interval, removing invalid data using the IQR rule, and retaining core features based on information gain with a retention rate greater than a preset value.

5. The method for proactively sending mass messages according to claim 4, characterized in that, In S2, dynamic label generation is achieved through a weighted matching degree calculation model: M=∑(F×W) / ∑W; where F is a single feature value, W is the feature weight trained by the gradient boosting tree algorithm, and automatic label update is triggered when M≥0.

7. The label set is stored in Redis cache. User filtering is performed by the rules engine using Boolean expression matching operations based on the filtering targets constructed from task metadata; The list of valid users is stored through the HDFS distributed file system, and a ready signal with the user list index and task metadata is sent to the S3 content generation process.

6. The method for proactively sending mass messages according to claim 5, characterized in that, In S3, the variable template is TPL=Fixed+Var, where Fixed is a fixed text segment and Var is a dynamic variable segment. Material matching establishes a mapping relationship between the effective user tag set and the variable field through the feature mapping function, and then matches from the material library based on the cosine similarity algorithm Sim(M,F)=∑(M×F) / [√∑M²×√∑F²]. When Sim is greater than the preset value, the optimal material is determined.

7. The method for proactively sending mass messages according to claim 6, characterized in that, In S3, single-instance content is generated by filling the corresponding fields of the variable template with matching materials through a replacement synthesis algorithm; compliance verification adopts AC automaton sensitive detection, with a time complexity of O(L), where L is the content length, and simultaneously verifies the compliance of the content format. Unqualified content triggers a maximum of preset material replacement retry. If it is still unqualified, it is marked as non-compliant content and stored in the exception database; the generated set of compliant personalized content establishes a "user ID-content ID-template ID" association mapping and is pushed to the channel scheduling process of S4 through a message queue.

8. The method for proactively sending mass messages according to claim 7, characterized in that, In S4, channel status is collected every preset second via SNMP protocol and HTTP interface, acquiring core indicators such as availability (A), response speed (S), delivery rate (D), load (L), and maximum load (T) for each channel. The collected data is stored in InfluxDB. The comprehensive channel status value is calculated using the weighted summation algorithm State=αA+βS+γD+δ(1-L / T), where α, β, γ, and δ are weight parameters. A decision model is built based on the AHP algorithm to match the optimal channel. High concurrency control is implemented by splitting tasks using the hash sharding algorithm ShardID=Hash(UserID) mod N, combined with the thread pool and token bucket algorithm. The maximum capacity of the thread pool is equal to the maximum channel load T×0.

8.

9. A method for proactively sending mass messages according to claim 8, characterized in that, In S4, compliance verification before sending is achieved by querying the user's recent preset days of receiving records, unsubscription status, and compliance blacklist in the cache. The query complexity is O(1). Users who receive more than a preset number of times in a single day, have unsubscribed, or are on the blacklist are excluded. During sending, the receiving frequency is controlled by a sliding time window. If the preset upper limit is exceeded, sending is paused. Channel anomaly monitoring adopts the 3σ algorithm. When the indicator exceeds the range of [μ-3σ,μ+3σ], a graded alarm is triggered and the channel task allocation weight is reduced. After sending, user privacy information is encrypted and stored using AES-256, transmitted using SSL / TLS1.3 encryption, and desensitized using SHA-256+salt hash.

10. A method for proactively sending mass messages according to claim 9, characterized in that, In S5, data preprocessing includes CRC32 integrity verification, missing value imputation, and outlier removal. Key features are extracted using the TF-IDF algorithm and statistical methods. The fusion model includes logistic regression, collaborative filtering, and reinforcement learning. Iterative strategy rules are trained using the gradient descent algorithm θ=θ-η∇J(θ) (η=0.01), and 5-fold cross-validation is used to ensure generalization ability. The optimized strategy rules are synchronized through Kafka publish-subscribe mode, with preset regular iteration cycles and high-priority task iteration cycles. Thresholds for core performance indicators are set, including sending success rate, user click-through rate, and compliance pass rate.

Images