Abnormal account processing method and device, equipment and storage medium

CN123034967APending Publication Date: 2026-11-03BEIJING UCAP INTERNET TECH
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202610980077.2
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-07-02
Publication Date
2026-11-03

AI Technical Summary

Technical Problem

Existing technologies have low accuracy in identifying abnormal accounts, resulting in poor stability and reliability of social platform services. Furthermore, they lack quantitative assessments adapted to different scenarios, cluster anomaly identification, and large-scale linkage circuit breaker mechanisms, leading to delayed handling and high resource consumption during large-scale anomalies.

Method used

By acquiring basic account information, behavioral information, and scenario information from the platform, feature extraction and weight assignment are performed. Combined with preset circuit breaker rules, abnormal accounts and cluster abnormal accounts are identified and processed, and the circuit breaker strategy is dynamically adjusted to improve identification accuracy.

Benefits of technology

It improved the accuracy of abnormal account identification, reduced the false positive rate, ensured the service reliability and security of social platforms, and avoided resource overload and service instability during large-scale anomalies.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN123034967A_ABST
    Figure CN123034967A_ABST
Patent Text Reader

Abstract

The application discloses an abnormal account processing method and device, equipment and storage medium, and belongs to the computer technical field. The method specifically comprises the following steps: obtaining account basic information, account behavior information and scene information of a platform; based on the scene information, performing feature extraction processing on the account basic information and the account behavior information to obtain account feature information corresponding to the scene information and a weight value of the account feature information; based on the account feature information corresponding to the scene information and the weight value of the account feature information, performing evaluation processing on the account of the platform to obtain abnormal account information of the platform; based on the account basic information and the account behavior information, determining cluster abnormal account information of the platform; and based on the abnormal account information and the cluster abnormal account information, obtaining a fuse strategy of an abnormal account by using a preset fuse rule.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to the fields of big data analysis technology, account management technology, etc., and particularly to a method, apparatus, device and storage medium for processing abnormal accounts. Background Technology

[0002] As the core carrier of information dissemination and user interaction, the health of social media platforms' account ecosystem directly impacts platform service quality, user experience, and information security. Account health monitoring is a fundamental technical means for social media platform operations, with its core purpose being to identify abnormal accounts such as spam accounts, marketing accounts, and maliciously registered accounts.

[0003] Currently, abnormal account identification solutions in related technologies include rule verification based on account registration information, statistical analysis based on behavioral data, and text recognition based on content. However, these solutions still suffer from low accuracy in identifying abnormal accounts, leading to poor stability and reliability of social media platform services. Summary of the Invention

[0004] This application provides a method, apparatus, device, and storage medium for handling abnormal accounts, which can solve the problem of poor stability and reliability of social platform services. The technical solution is as follows: Firstly, a method for handling abnormal accounts is provided, the method comprising: Obtain basic account information, account behavior information, and scenario information from the platform; Based on the scenario information, feature extraction processing is performed on the basic account information and account behavior information to obtain the account feature information corresponding to the scenario information and the weight value of the account feature information; Based on the account feature information corresponding to the scenario information and the weight value of the account feature information, the accounts on the platform are evaluated to obtain abnormal account information of the platform. Based on the account basic information and account behavior information, the abnormal account information of the platform's cluster is determined; Based on the abnormal account information and cluster abnormal account information, the circuit breaker strategy for abnormal accounts is obtained using preset circuit breaker rules. Based on the circuit breaker policy for the abnormal accounts, the abnormal accounts on the platform are processed.

[0005] In one possible implementation, the step of performing feature extraction processing on the account basic information and account behavior information based on the scenario information to obtain account feature information corresponding to the scenario information and the weight value of the account feature information includes: Determine the preset feature weight table corresponding to the scene information; Based on the scenario information, feature extraction processing is performed on the basic account information and account behavior information to obtain the account feature information corresponding to the scenario information; Based on the account feature information corresponding to the scenario information and the preset feature weight table, the weight value of the account feature information is obtained.

[0006] In one possible implementation, the process of evaluating the platform's accounts based on the account feature information corresponding to the scenario information and the weight value of the account feature information to obtain abnormal account information of the platform includes: Based on the account feature information corresponding to the scenario information and the weight value of the account feature information, the health score of the account is obtained using a preset health score algorithm. If the health score of an account is less than a preset health threshold, the account is identified as an abnormal account on the platform.

[0007] In one possible implementation, determining the abnormal account information of the platform's cluster based on the account basic information and account behavior information includes: Based on the aforementioned basic account information and account behavior information, determine the account information associated with the device, the account information associated with the IP address, and the account information associated with the behavior. Based on preset abnormal account conditions for the cluster, account information associated with the device, account information associated with the IP, and account information associated with the behavior, the abnormal account information for the cluster of the platform is determined.

[0008] In one possible implementation, the abnormal cluster account information of the platform is determined based on preset cluster abnormal account conditions, account information associated with the device, account information associated with the IP address, and account information associated with behavior, including: Based on the account information associated with the device, the number of accounts associated with the device is determined, and in response to the number of accounts associated with the device exceeding a preset first threshold, the account associated with the device is determined to be a first cluster abnormal account, or... Based on the account information associated with the IP address, the number of accounts associated with the IP address is determined. If the number of accounts associated with the IP address exceeds a preset second threshold, the accounts associated with the IP address are determined to be abnormal accounts in the second cluster. Based on the account information associated with the behavior, the similarity of the accounts associated with the behavior is determined, and in response to the similarity of the accounts associated with the behavior exceeding a preset similarity threshold, the accounts associated with the behavior are determined to be abnormal accounts in the third cluster. Based on the abnormal accounts in the first cluster, the abnormal accounts in the second cluster, and the abnormal accounts in the third cluster, the abnormal account information of the platform's clusters is determined.

[0009] In one possible implementation, the step of obtaining the circuit breaker strategy for the abnormal account based on the abnormal account information and the cluster abnormal account information, using preset circuit breaker rules, includes: Based on the abnormal account information and cluster abnormal account information, the percentage of abnormal accounts and the percentage of cluster abnormal accounts are obtained; In response to the abnormal account ratio and the cluster abnormal account ratio meeting the preset first-level circuit breaker condition, the circuit breaker policy for the abnormal account is obtained based on the first-level circuit breaker policy. In response to the abnormal account ratio or the abnormal account ratio of the cluster meeting the preset second-level circuit breaker condition, the circuit breaker policy for the abnormal account is obtained based on the second-level circuit breaker policy. In response to the abnormal account ratio meeting the preset third-level circuit breaker condition, the circuit breaker strategy for the abnormal account is obtained based on the third-level circuit breaker strategy.

[0010] Secondly, an apparatus for processing abnormal accounts is provided, the apparatus comprising: The acquisition unit is used to acquire basic account information, account behavior information, and scenario information from the platform. The extraction unit is used to perform feature extraction processing on the account basic information and account behavior information based on the scene information, so as to obtain the account feature information corresponding to the scene information and the weight value of the account feature information; An evaluation unit is used to evaluate the accounts on the platform based on the account feature information corresponding to the scenario information and the weight value of the account feature information, so as to obtain abnormal account information of the platform. The determining unit is used to determine the abnormal account information of the platform's cluster based on the account basic information and account behavior information; The obtaining unit is used to obtain the circuit breaker strategy for the abnormal account based on the abnormal account information and the cluster abnormal account information, using preset circuit breaker rules. The circuit breaker unit is used to process abnormal accounts on the platform based on the circuit breaker policy of the abnormal accounts.

[0011] Thirdly, a computer-readable storage medium is provided, wherein at least one instruction is stored therein, the at least one instruction being loaded and executed by a processor to implement the aspects and any possible implementations described above.

[0012] Fourthly, an electronic device is provided, comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the methods described above and any possible implementations.

[0013] Fifthly, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the aspects and any possible implementations described above.

[0014] The beneficial effects of the technical solution provided in this application include at least the following: As can be seen from the above technical solution, the embodiments of this application can obtain the platform's basic account information, account behavior information, and scenario information. Then, based on the scenario information, feature extraction processing can be performed on the basic account information and account behavior information to obtain the account feature information corresponding to the scenario information and the weight value of the account feature information. Based on the account feature information corresponding to the scenario information and the weight value of the account feature information, the platform's accounts are evaluated to obtain abnormal account information. Based on the basic account information and account behavior information, cluster abnormal account information of the platform is determined. Based on the abnormal account information and cluster abnormal account information, a circuit breaker strategy for abnormal accounts is obtained using preset circuit breaker rules. Based on the circuit breaker strategy for abnormal accounts, the abnormal accounts of the platform are processed. Since abnormal account identification and cluster abnormal account identification can be performed on platform accounts according to the platform's scenario information, and a circuit breaker strategy for abnormal accounts is obtained based on the two types of abnormal accounts using preset circuit breaker rules, the accuracy of abnormal account identification is improved, the false judgment rate is effectively reduced, and accurate identification of abnormal accounts in social platforms can be achieved, thereby ensuring the reliability and security of social platform services.

[0015] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent from the following description. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating a method for handling abnormal accounts provided in one embodiment of this application; Figure 2This is a flowchart illustrating a method for handling abnormal accounts provided in another embodiment of this application; Figure 3 This is a structural block diagram of an abnormal account processing device provided in another embodiment of this application; Figure 4 This is a block diagram of an electronic device used to implement the abnormal account handling method of the embodiments of this application. Detailed Implementation

[0018] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of this application, including various details to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this application. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0019] Obviously, the described embodiments are only some, not all, of the embodiments in this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0020] Furthermore, the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0021] The harm caused by abnormal accounts is mainly reflected in three aspects: First, they interfere with normal user interaction, such as sending mass advertising private messages leading to user complaints; second, they consume platform resources, such as a large number of abnormal accounts logging in concurrently consuming server computing power; and third, they cause security risks, such as abnormal account clusters spreading false information and causing public opinion disturbances. Therefore, after monitoring abnormal accounts, platforms usually take measures such as banning, restricting functions, and manual review. Account health monitoring is a basic technical means for social media platform operation. Its core purpose is to identify abnormal accounts such as spam accounts, marketing accounts, and maliciously registered accounts. Commonly used technologies include rule verification based on account registration information, such as verification based on mobile phone number location and email suffix; statistical analysis based on behavioral data, such as statistical analysis of login frequency and number of posts; and text recognition based on content, such as identifying whether posts contain sensitive words.

[0022] However, the solutions in the related art adopt fixed features and fixed thresholds, without considering the difference in feature weights under different scenarios, leading to a high false positive rate. Meanwhile, they do not combine the correlation between accounts, and cannot identify clustered abnormal accounts, resulting in a high false negative rate. Most of the solutions in the related art adopt a single-account one-by-one processing mode, without a collaborative response mechanism for batch anomalies, so that processing lag and resource overload occur when large-scale anomalies appear. Moreover, it is impossible to cut off the harm transmission when the anomaly scale exceeds the limit, leading to unstable platform services. It can be seen that the social platform account health monitoring in the related art has the technical problems of low abnormal account identification accuracy, lagged processing and high resource consumption during large-scale anomalies, and vulnerable and unstable platform services, due to the lack of scenario-adaptive quantitative evaluation, cluster anomaly identification and scale-linked fusing mechanism.

[0023] Therefore, there is an urgent need for an abnormal account processing method, which can realize accurate identification of abnormal accounts in social platforms, so as to ensure the reliability and security of social platform services.

[0024] Please refer to Figure 1 , which shows a schematic flowchart of an abnormal account processing method provided by an embodiment of the present application. The abnormal account processing method may specifically include: Step 101: Obtain platform account basic information, account behavior information, and scenario information.

[0025] Step 102: Perform feature extraction processing on the account basic information and account behavior information based on the scenario information, so as to obtain account feature information corresponding to the scenario information and a weight value of the account feature information.

[0026] Step 103: Perform evaluation processing on the accounts of the platform based on the account feature information corresponding to the scenario information and the weight value of the account feature information, so as to obtain abnormal account information of the platform.

[0027] Step 104: Determine clustered abnormal account information of the platform based on the account basic information and account behavior information.

[0028] Step 105: Obtain a fusing strategy for abnormal accounts by using a preset fusing rule based on the abnormal account information and the clustered abnormal account information.

[0029] Step 106: Process the abnormal accounts of the platform based on the fusing strategy for abnormal accounts.

[0030] It should be noted that the account basic information may include, but is not limited to, a registration number, registration time, device model, device ID, login IP, etc.

[0031] It should be noted that account behavior information may include, but is not limited to, the number of posts, the number of private messages sent, the number of recipients of private messages, the number of likes and comments, login frequency, and the number of times the IP address has changed. Account behavior information can be the account's functional actions performed within a preset time period. Here, the preset time period can be 24 hours.

[0032] It should be noted that the scenario information may include, but is not limited to, the type of the current date, the number of users online on the platform, and the usage rate of core functions. The type of the current date can be used to determine whether it is a promotional day or a holiday. Core functions may include private messaging, posting, etc. Preferably, the platform's basic account information, account behavior information, and scenario information can be collected at a frequency of once per minute to ensure data real-time performance.

[0033] In this way, by acquiring the platform's basic account information, account behavior information, and scenario information, feature extraction processing can be performed on the basic account information and account behavior information based on the scenario information to obtain the account feature information and weight values ​​corresponding to the scenario information. Based on the account feature information and the weight values ​​of the account feature information, the platform's accounts are evaluated to obtain abnormal account information. Based on the basic account information and account behavior information, cluster abnormal account information of the platform is determined. Based on the abnormal account information and cluster abnormal account information, a circuit breaker strategy for abnormal accounts is obtained using preset circuit breaker rules. Since abnormal account identification and cluster abnormal account identification can be performed on platform accounts separately based on the platform's scenario information, and a circuit breaker strategy for abnormal accounts is obtained based on the two types of abnormal accounts using preset circuit breaker rules, the accuracy of abnormal account identification is improved, the false positive rate is effectively reduced, and accurate identification of abnormal accounts in social platforms can be achieved, thereby ensuring the reliability and security of social platform services.

[0034] Optionally, in one possible implementation of this embodiment, in step 102, firstly, a preset feature weight table corresponding to the scene information can be determined. Secondly, based on the scene information, feature extraction processing can be performed on the account basic information and account behavior information to obtain the account feature information corresponding to the scene information. Thirdly, based on the account feature information corresponding to the scene information and the preset feature weight table, the weight value of the account feature information can be obtained.

[0035] In one specific implementation of this approach, firstly, the current scene type can be determined based on the scene information. Secondly, a preset feature weight table corresponding to the scene type is obtained.

[0036] Here, the platform's scenario types can include daily scenarios, high-activity scenarios, and ultra-high-activity scenarios. For example, a high-activity scenario could be a scenario during a promotional event. An ultra-high-activity scenario could be a scenario during a holiday.

[0037] In this implementation, the preset feature weight table can be obtained by iterative analysis of the platform's historical operational data, normal user behavior data, and abnormal account attack characteristics.

[0038] In this implementation, the account feature information corresponding to the scenario information may include the proportion of private messages to strangers, the number of accounts bound to the device, the frequency of post-registration behavior, the number of times the IP address was changed, and the similarity of behavior sequences.

[0039] In another specific implementation of this approach, firstly, the current scenario type can be determined based on the scenario information. Secondly, based on the scenario type, feature extraction processing can be performed on the account basic information and account behavior information to obtain the account feature information corresponding to the scenario type.

[0040] In this implementation, account characteristic information for everyday scenarios may include the percentage of private messages sent to strangers, the number of accounts bound to a device, the frequency of post-registration behavior, the number of IP address changes, and the similarity of behavior sequences. Account characteristic information for highly active scenarios may include the percentage of private messages sent to strangers, the number of accounts bound to a device, the frequency of post-registration behavior, the number of IP address changes, and the similarity of behavior sequences. Account characteristic information for extremely highly active scenarios may include the percentage of private messages sent to strangers, the number of accounts bound to a device, the frequency of post-registration behavior, the number of IP address changes, and the similarity of behavior sequences.

[0041] In this implementation, the preset feature weight table may include a daily scene weight table, a high-activity scene weight table, and an ultra-high-activity scene weight table.

[0042] For example, the weight table for everyday scenarios is as follows: the percentage of private messages to strangers, with a weight of 0.25; the number of accounts bound to a device, with a weight of 0.2; the frequency of post-registration behavior, with a weight of 0.15; the number of times the IP address was changed, with a weight of 0.2; and the similarity of behavior sequences, with a weight of 0.2.

[0043] High-activity scenario weighting table: percentage of private messages to strangers, weight value 0.3; number of accounts bound to a device, weight value 0.3; frequency of post-registration behavior, weight value 0.1; number of IP changes, weight value 0.1; similarity of behavior sequence, weight value 0.2.

[0044] Weighting table for ultra-high activity scenarios: Percentage of private messages to strangers, weight value 0.35; Number of accounts bound to a device, weight value 0.35; Frequency of post-registration behavior, weight value 0.05; Number of IP changes, weight value 0.05; Similarity of behavior sequences, weight value 0.2.

[0045] In this way, based on the scenario information and the preset feature weight table, feature extraction processing can be performed on the basic account information and account behavior information to obtain the account feature information corresponding to the scenario information and the weight value of the account feature information, which can facilitate the subsequent assessment of the accuracy of account health.

[0046] Optionally, in one possible implementation of this embodiment, in step 103, firstly, based on the account feature information corresponding to the scene information and the weight value of the account feature information, a preset health score algorithm is used to obtain the health score of the account. Secondly, in response to the account's health score being less than a preset health threshold, the account can be determined to be abnormal account information of the platform.

[0047] In a specific implementation of this approach, firstly, based on the account feature information corresponding to the scenario information and the weight value of the account feature information, the account feature information corresponding to the scenario type and the weight value of the account feature information can be determined. Secondly, based on the account feature information corresponding to the scenario type and the weight value of the account feature information, a preset health score algorithm is used to obtain the health score of the account. Thirdly, in response to the account's health score being less than a preset health threshold, the account can be determined to be abnormal account information of the platform.

[0048] One specific implementation involves standardizing the account feature information corresponding to the scenario type to obtain standardized values ​​for the account feature information. Then, based on a preset penalty coefficient, the standardized values ​​of the account feature information, and the weight values ​​of the account feature information, the health score of the account is calculated.

[0049] Here, preferably, the preset health threshold can be 60.

[0050] Another specific implementation method is that, in the case of a daily scenario, the health of the account can be obtained based on the account feature information corresponding to the daily scenario and the weight value of the account feature information, using a preset health algorithm.

[0051] Another specific implementation method is that, in the case of a high-activity scenario, the health of the account can be obtained by using a preset health algorithm based on the account feature information corresponding to the high-activity scenario and the weight value of the account feature information.

[0052] Another specific implementation method is that, in the case of an ultra-high activity scenario, the health of the account can be obtained based on the account feature information corresponding to the ultra-high activity scenario and the weight value of the account feature information, using a preset health algorithm.

[0053] In this way, by using a preset health score algorithm, the health score of an account can be calculated based on the account feature information corresponding to the scene information and the weight value of the account feature information. Accounts with a health score less than a preset health threshold are identified as abnormal accounts on the platform, which can further improve the accuracy of abnormal account identification.

[0054] It should be noted that the specific implementation process provided in this implementation method can be combined with various specific implementation processes provided in the aforementioned implementation methods to implement the abnormal account handling method of this embodiment. Detailed descriptions can be found in the relevant content of the aforementioned implementation methods, and will not be repeated here.

[0055] Optionally, in one possible implementation of this embodiment, in step 104, firstly, based on the account basic information and account behavior information, device-associated account information, IP-associated account information, and behavior-associated account information can be determined. Secondly, based on preset cluster abnormal account conditions, the device-associated account information, IP-associated account information, and behavior-associated account information, the platform's cluster abnormal account information can be determined.

[0056] In this implementation, basic account information may include, but is not limited to, registration number, registration time, device model, device ID, and login IP. Account behavior information may include, but is not limited to, number of posts, number of private messages sent, number of private message recipients, number of likes and comments, login frequency, and number of IP changes. Account behavior information can include account function execution actions within the past 24 hours.

[0057] In a specific implementation of this approach, the association relationships of accounts can be analyzed and processed based on the basic account information and account behavior information, and the account information associated with devices, IP addresses, and behaviors can be determined respectively.

[0058] Here, device-associated account information can include multiple accounts associated with the same device. IP-associated account information can include multiple accounts associated with the same IP address. Behavior-associated account information can include multiple accounts performing the same operation at the same time. Here, the same operation can include registering, sending private messages with the same content, etc.

[0059] In this implementation, the preset abnormal account conditions for the cluster may include the number of accounts associated with the device exceeding a preset first quantity threshold, the number of accounts associated with the IP exceeding a preset second quantity threshold, and the similarity of accounts associated with behavior exceeding a preset similarity threshold.

[0060] In another specific implementation of this approach, based on the account information associated with the device, the number of accounts associated with the device is determined. If the number of accounts associated with the device exceeds a preset first threshold, the account associated with the device is determined to be a first cluster abnormal account. Based on the account information associated with the IP address, the number of accounts associated with the IP address is determined. If the number of accounts associated with the IP address exceeds a preset second threshold, the account associated with the IP address is determined to be a second cluster abnormal account. Based on the account information associated with the behavior, the similarity of the behavior-associated accounts is determined. If the similarity of the behavior-associated accounts exceeds a preset similarity threshold, the account associated with the behavior is determined to be a third cluster abnormal account. Based on the first, second, and third cluster abnormal accounts, the platform's cluster abnormal account information is determined.

[0061] Here, the platform's cluster abnormal account information can include the cluster identifier, the number of abnormal accounts within the cluster, and the association characteristics of the abnormal accounts within the cluster. The association characteristics of abnormal accounts within the cluster can characterize the association type of abnormal accounts within the cluster, and can include device association, IP association, and behavior association.

[0062] It is understandable that the similarity of accounts with related behaviors can be expressed as the similarity of the accounts' behavioral sequences.

[0063] Preferably, the preset first quantity threshold can be 5. The preset second quantity threshold can be 10. The preset similarity threshold can be 0.9.

[0064] In this way, the abnormal account information of the platform can be obtained by analyzing the preset abnormal account conditions and account information of various related types, so as to facilitate the subsequent identification of abnormal accounts in the platform and further improve the comprehensiveness of the identification results.

[0065] It should be noted that the specific implementation process provided in this implementation method can be combined with various specific implementation processes provided in the aforementioned implementation methods to implement the abnormal account handling method of this embodiment. Detailed descriptions can be found in the relevant content of the aforementioned implementation methods, and will not be repeated here.

[0066] Optionally, in one possible implementation of this embodiment, in step 105, firstly, the percentage of abnormal accounts and the percentage of abnormal accounts in the cluster can be obtained based on the abnormal account information and the cluster abnormal account information. Secondly, in response to the percentage of abnormal accounts and the percentage of abnormal accounts in the cluster satisfying a preset first-level circuit breaker condition, a circuit breaker strategy for the abnormal accounts can be obtained based on the first-level circuit breaker strategy. Thirdly, in response to the percentage of abnormal accounts or the percentage of abnormal accounts in the cluster satisfying a preset second-level circuit breaker condition, a circuit breaker strategy for the abnormal accounts can be obtained based on the second-level circuit breaker strategy. Fourthly, in response to the percentage of abnormal accounts satisfying a preset third-level circuit breaker condition, a circuit breaker strategy for the abnormal accounts can be obtained based on the third-level circuit breaker strategy.

[0067] In this implementation, the abnormal account information may include the number of abnormal accounts. The cluster abnormal account information may include the number of abnormal accounts in the cluster.

[0068] In a specific implementation of this method, firstly, the total number of accounts on the platform can be obtained. Secondly, based on the number of abnormal accounts and the number of abnormal accounts in the cluster, the total number of abnormal accounts can be calculated. Thirdly, the ratio of the total number of abnormal accounts to the total number of accounts on the platform is calculated to obtain the percentage of abnormal accounts.

[0069] In another specific implementation of this approach, firstly, the total number of abnormal accounts can be calculated based on the number of abnormal accounts and the total number of abnormal accounts in the cluster. Secondly, the percentage of abnormal accounts in the cluster can be calculated based on the number of abnormal accounts in the cluster and the total number of abnormal accounts.

[0070] In this implementation, the preset circuit breaker rules may include the relationship between the percentage of abnormal accounts and the percentage of abnormal accounts in the cluster and the preset first-level circuit breaker conditions, the preset second-level circuit breaker conditions, and the preset third-level circuit breaker conditions, respectively.

[0071] In this implementation, the preset first-level circuit breaker condition may include the percentage of abnormal accounts being within a preset first percentage range, and the percentage of abnormal accounts in the cluster being less than a preset first percentage threshold.

[0072] In a specific implementation of this method, when the proportion of abnormal accounts is within a preset first proportion range and the proportion of abnormal accounts in the cluster is less than a preset first proportion threshold, the circuit breaker strategy for the abnormal accounts is obtained based on the first-level circuit breaker strategy.

[0073] Here, preferably, the preset first percentage range can be 5%-10%. The preset first percentage threshold can be 30%.

[0074] Preferably, the first-level circuit breaker strategy is to limit the frequency of new account registrations from 10 per minute to 5 per minute, and to limit the private message sending function of abnormal accounts to ≤10 messages per account per hour. Here, the second-level circuit breaker strategy can be used as the circuit breaker strategy for abnormal accounts on the current platform.

[0075] In one specific implementation scenario, when the current scenario type of the scenario information is a daily scenario or a high-activity scenario, the proportion of abnormal accounts is within a preset first proportion range, and the proportion of abnormal accounts in the cluster is less than a preset first proportion threshold, the circuit breaker strategy for the abnormal accounts is obtained based on the first-level circuit breaker strategy.

[0076] In this implementation, the preset second-level circuit breaker condition may include the percentage of abnormal accounts being within a preset second percentage range, or the percentage of abnormal accounts in the cluster being greater than or equal to a preset first percentage threshold.

[0077] In another specific implementation of this method, when the proportion of abnormal accounts is within a preset second proportion range, or when the proportion of abnormal accounts in the cluster is greater than or equal to a preset first proportion threshold, the circuit breaker strategy for the abnormal accounts is obtained based on the second-level circuit breaker strategy.

[0078] Here, preferably, the preset second percentage range can be 10%-20%. The preset first percentage threshold can be 30%.

[0079] Preferably, the second-level circuit breaker strategy is to suspend new account registration, disable the posting and private messaging functions of abnormal accounts, and limit login requests from abnormal IP ranges by 50%. Here, the second-level circuit breaker strategy can be used as the circuit breaker strategy for abnormal accounts on the current platform.

[0080] In this implementation, the preset third-level circuit breaker condition may include the percentage of abnormal accounts being greater than the preset second percentage threshold.

[0081] In another specific implementation of this method, when the proportion of abnormal accounts exceeds a preset second proportion threshold, the circuit breaker strategy for the abnormal accounts is obtained based on the third-level circuit breaker strategy.

[0082] Here, preferably, the preset second percentage threshold can be 20%.

[0083] Preferably, the third-level circuit breaker strategy involves suspending new account registration, limiting the posting and private message frequency of all accounts, reducing the posting frequency of normal accounts to 80% of their original frequency, banning abnormal accounts, activating core function protection mode, prioritizing login and browsing functions, and suspending non-core commenting and liking functions. Here, the third-level circuit breaker strategy can be used as the current circuit breaker strategy for abnormal accounts on the platform.

[0084] In another specific implementation of this approach, firstly, the platform's resource utilization rate and feedback information from normal account users are obtained. Secondly, if the platform's resource utilization rate and feedback information from normal account users meet preset upgrade conditions, the circuit breaker policy for abnormal accounts can be upgraded. Thirdly, if the platform's resource utilization rate and feedback information from normal account users meet preset downgrade conditions, the circuit breaker policy for abnormal accounts can be downgraded.

[0085] In this implementation, the preset upgrade conditions may include resource utilization exceeding 80% or a normal user response time exceeding 3 seconds. The preset downgrade conditions may include resource utilization less than 60% and no impact on the normal user experience.

[0086] For example, if the platform's resource utilization rate is still above 80% or the normal user response time is >3 seconds, an upgraded circuit breaker will be triggered; if the normal user experience is not affected and the resource utilization rate is <60%, the circuit breaker level will be downgraded or lifted, forming a dynamically adjusted closed loop.

[0087] In this way, by dynamically adjusting the three-tier circuit breaker strategy, abnormal accounts can be controlled while avoiding excessive circuit breaker impact on normal users, further improving the stability of platform services and user experience.

[0088] It should be noted that the specific implementation process provided in this implementation method can be combined with various specific implementation processes provided in the aforementioned implementation methods to implement the abnormal account handling method of this embodiment. Detailed descriptions can be found in the relevant content of the aforementioned implementation methods, and will not be repeated here.

[0089] To better understand the methods of the embodiments of this application, the methods of the embodiments of this application will be described below in conjunction with the accompanying drawings and specific application scenarios.

[0090] Figure 2 This is a flowchart illustrating a method for handling abnormal accounts provided in another embodiment of this application, as shown below. Figure 2 As shown.

[0091] Step 201: Obtain the platform's basic account information, account behavior information, and scenario information.

[0092] Step 202: Based on the scenario information, perform feature extraction processing on the account's basic information and account behavior information to obtain the account feature information corresponding to the scenario information.

[0093] In this embodiment, the current scenario type can be determined based on scenario information. Scenario types can include daily scenarios, high-activity scenarios such as promotions, and ultra-high-activity scenarios.

[0094] Here, account characteristic information may include the percentage of private messages sent to strangers, the number of accounts bound to a device (0.35), the frequency of short-term behavior after registration, the number of times the IP address was changed, and the similarity of behavior sequences.

[0095] Step 203: Based on the account feature information corresponding to the scene information and the preset feature weight table, obtain the weight value of the account feature information.

[0096] In this embodiment, the preset feature weight table may include account feature information and the weight values ​​of account feature information in different scenario types.

[0097] Understandably, the process begins by determining the current scenario type based on the scenario information, and then calling the corresponding scenario's feature weight table. This weight table can be iteratively obtained based on the platform's massive historical operational data, normal user behavior baselines, and abnormal account attack characteristics, adapting to three core operational scenarios.

[0098] The specific feature information, weight allocation, and adaptation logic for each scenario are as follows: First, the daily scenario, where user activity is at a normal baseline and there are no major holiday events, focuses on basic abnormal account behavior. The features and weight allocation are: percentage of private messages to strangers 0.25, number of accounts bound to a device 0.2, short-term behavior frequency after registration 0.15, number of IP changes 0.2, and account behavior sequence similarity 0.2. In this scenario, ordinary user behavior is stable, while frequent IP changes and high-frequency operations are mostly abnormal features, thus they are given higher weights. Second, the high-activity scenario, which is the peak traffic period on weekends, when the number of active users on the platform is about twice that of daily days, sees ordinary users exhibiting regular behaviors such as concentrated posting, private messaging, and high-frequency operations. Therefore, the weights of general behavioral features that are easily affected by the scenario are reduced, while the weights of core cluster anomalies are increased. The feature weights and their allocation are as follows: percentage of private messages to strangers 0.3, number of accounts bound to a device 0.3, short-term behavior frequency after registration 0.1, number of IP changes 0.1, and account behavior sequence similarity 0.2. This avoids misjudgments caused by normal user activity and focuses on the cluster characteristics of malicious accounts. Third, in ultra-high activity scenarios, i.e., large holidays or events where the number of active users is three times or more than usual, user behavior fluctuates greatly. High-frequency operations and frequent IP changes by a single account are common phenomena. Therefore, the weight of individual behavior features is further weakened, while the weight of batch cluster anomaly features is maximized. The feature and weight allocation are as follows: percentage of private messages to strangers 0.35, number of accounts bound to a device 0.35, short-term behavior frequency after registration 0.05, number of IP changes 0.05, and account behavior sequence similarity 0.2. The total weight of all three scenarios is 1, thus achieving accurate adaptation to the needs of account anomaly judgment under different traffic environments.

[0099] Step 204: Based on the account feature information corresponding to the scene information and the weight value of the account feature information, obtain the health score of the account using the preset health score algorithm.

[0100] In this embodiment, firstly, the account feature information corresponding to the scene information can be standardized to obtain standardized values ​​of the account feature information. Secondly, the standardized values ​​and weighted values ​​of the account feature information are weighted and summed to obtain the health score of the account.

[0101] Preferably, the result of the weighted summation calculation can be multiplied by a preset penalty coefficient to calculate the account's health score.

[0102] Step 205: In response to the account's health score being less than the preset health threshold, the account is identified as an abnormal account on the platform.

[0103] In this embodiment, the preset health threshold can be 60.

[0104] Understandably, steps 204 and 205 yield a list of abnormal accounts and the health score of each account. This list and score represent the platform's information on abnormal accounts.

[0105] Step 206: Based on the account basic information and account behavior information, determine the account information associated with the device, the account information associated with the IP, and the account information associated with the behavior.

[0106] Step 207: Based on the preset abnormal cluster account conditions, device-associated account information, IP-associated account information, and behavior-associated account information, determine the abnormal cluster account information of the platform.

[0107] In this embodiment, the device-associated account information may include the number of accounts associated with the device, which can be the number of accounts bound to the same device. The IP-associated account information may include the number of accounts associated with an IP address, which can be the number of accounts logged in from the same IP address. The behavior-associated account information may include the similarity of behavior-associated accounts, which can be the similarity of behavior sequences.

[0108] In this embodiment, based on basic account information and account behavior information, device-associated account information, IP-associated account information, and behavior sequence-associated account information are extracted. Device association can indicate that multiple accounts are bound to the same device ID. IP association can indicate that multiple accounts come from the same IP or IP range. Behavior sequence association can indicate that multiple accounts perform the same operation at the same time, such as registering simultaneously or sending the same private message simultaneously.

[0109] In this embodiment, if any one of the device-associated account information, IP-associated account information, and behavior-associated account information meets the preset cluster abnormal account conditions, the account can be identified as a cluster abnormal account of the platform, and the corresponding cluster abnormal account information of the platform can be obtained.

[0110] For example, when the number of accounts bound to the same device is greater than 5, or the number of accounts logged in from the same IP is greater than 10, or the behavioral sequence similarity is greater than 0.9, the account can be determined as an abnormal account in the cluster. Then, by judging each account, the abnormal account information of the platform's cluster can be output. The abnormal account information of the platform's cluster can include the cluster ID, the number of accounts in the cluster, and core related features.

[0111] Step 208: Based on the abnormal account information and cluster abnormal account information, obtain the percentage of abnormal accounts and the percentage of cluster abnormal accounts.

[0112] In this embodiment, the percentage of abnormal accounts = total number of abnormal accounts / total number of accounts on the platform × 100%. The percentage of abnormal accounts in the cluster = number of abnormal accounts in the cluster / total number of abnormal accounts × 100%.

[0113] Here, the total number of abnormal accounts can be the sum of the number of abnormal accounts and the number of abnormal accounts in the cluster after deduplication.

[0114] Step 209: If the percentage of abnormal accounts is within a preset first percentage range and the percentage of abnormal accounts in the cluster is less than a preset first percentage threshold, the first-level circuit breaker strategy shall be used as the circuit breaker strategy for abnormal accounts; or, if the percentage of abnormal accounts is within a preset second percentage range or the percentage of abnormal accounts in the cluster is greater than or equal to the preset first percentage threshold, the second-level circuit breaker strategy shall be used as the circuit breaker strategy for abnormal accounts; or, if the percentage of abnormal accounts is greater than the preset second percentage threshold, the third-level circuit breaker strategy shall be used as the circuit breaker strategy for abnormal accounts.

[0115] Step 210: Based on the circuit breaker strategy for abnormal accounts, process the abnormal accounts on the platform.

[0116] In this embodiment, the first-level circuit breaker strategy can be a level 1 circuit breaker. When the percentage of abnormal accounts is 5%-10% and the percentage of abnormal accounts in the cluster is <30%, and the triggering condition is a daily or high-activity scenario, the following can be implemented: limiting the frequency of new account registration (reducing it from 10 / minute to 5 / minute) and limiting the rate of private message sending function for abnormal accounts (≤10 messages per account per hour).

[0117] The second-level circuit breaker strategy can be a two-level circuit breaker: when the percentage of abnormal accounts is 10%-20% or the percentage of abnormal accounts in the cluster is ≥30%, the triggering condition is any scenario, and it can suspend new account registration, disable the posting and private messaging functions of abnormal accounts, and limit the login requests of abnormal IP ranges by 50%.

[0118] The third-level circuit breaker strategy can be a three-level circuit breaker: when the percentage of abnormal accounts is >20%, the trigger condition is any scenario, and it can be implemented to suspend new account registration, limit the posting and private message frequency of all accounts (normal accounts are reduced to 80% of the original frequency, and abnormal accounts are prohibited), and activate the core function protection mode (prioritize the login and browsing functions, and suspend non-core comment and like functions).

[0119] In addition, if a certain level of conditions is met, the corresponding policy will be executed; if no level of conditions is met, conventional measures such as banning or restricting the individual abnormal account will be implemented.

[0120] In this embodiment, the platform's resource utilization, such as server CPU and memory usage, and normal user experience information, such as login success rate, core function response time, and number of user complaints, can be monitored. If the resource utilization is still detected to exceed 80% or the normal user response time is >3 seconds, an upgraded circuit breaker is triggered; if the normal user experience is not affected and the resource utilization is <60%, the circuit breaker level is allowed to be downgraded or lifted, forming a dynamically adjusted closed loop.

[0121] In this embodiment, taking a social e-commerce platform as an example, the platform has 5 million daily active accounts and 20 million total registered accounts. During promotional activities, i.e., in high-activity scenarios, malicious registration tools may be used to generate accounts in bulk to send private messages advertising products. An application example of the solution of this invention on this platform is as follows: A promotional activity starts at 0:00. At 0:30, the number of registered accounts surges (from the usual 500 / hour to 2000 / hour), and the newly registered accounts have a high rate of duplicate device IDs (10 accounts bound to the same device ID). On one hand, the scenario type is determined to be a high-activity scenario. A high-activity scenario weight table is obtained, and the health score of the newly registered accounts is calculated. For example, account A: sent 20 private messages within 10 minutes of registration, 100% of which were to unknown recipients, and changed its IP address once. After standardization and weighted summation, it scores 45 points, which is considered abnormal. On the other hand, 100 device IDs are obtained, each bound to 10 accounts, forming a cluster of 1000 accounts, which is considered an abnormal cluster. The total number of abnormal accounts is calculated to be 1200, out of a total of 20,001,200 accounts, representing an abnormal percentage of 0.06%, which does not reach the 5% threshold for Level 1 circuit breaker. Therefore, only the 1200 abnormal accounts can be banned. At 10:00 AM, the total number of abnormal accounts rose to 1.2 million, accounting for 6% of all accounts, with 80% of the clusters being abnormal (960,000 abnormal accounts in the cluster), triggering the Level 1 circuit breaker. At 12:00 PM, the total number of abnormal accounts rose to 2.2 million, accounting for 11% of all accounts, triggering the Level 2 circuit breaker. At 2:00 PM, server CPU utilization dropped from 70% to 50%, and the response time for private messages from normal users dropped from 2 seconds to 1 second, indicating that the circuit breaker was effective. At 6:00 PM, the growth of abnormal accounts slowed down, the abnormal percentage dropped to 9%, and the circuit breaker level was lowered to Level 1. At midnight, the abnormal account percentage dropped to 3%, the circuit breaker was lifted, and normal operation resumed.

[0122] Specifically, the weighting table for high-activity scenarios can be: percentage of private messages to strangers (0.3), number of accounts bound to the device (0.3), short-term behavior frequency after registration (0.1), number of IP changes (0.1), and behavior sequence similarity (0.2). The circuit breaker threshold remains at the default value: Level 1 abnormal account percentage 5%, Level 2 10%, and Level 3 20%. The system retrieves account information associated with newly registered accounts, such as device ID: DEV001 bound to 10 accounts, and account information associated with the IP address, such as IP: 192.168.1.100 logging into 8 accounts. Behavioral logs of these accounts are collected from the behavioral database to obtain account information associated with the behavior, such as account A: registered at 0:05, sent 20 private messages at 0:10, all received by users not followed. The collection frequency is 1 minute per instance.

[0123] For example, the feature information of account A and the corresponding high-activity scenario weights are: percentage of private messages to strangers 0.3, number of accounts bound to the device 0.3, short-term behavior frequency after registration 0.1, number of IP changes 0.1, and account behavior sequence similarity 0.2, with a total weight of 1. First, the feature information of account A is standardized in the range of 0-1. Short-term behavior frequency after registration: The original data shows 20 private messages sent within 10 minutes of registration. The maximum benchmark threshold for high-activity scenarios on the platform is 30 compliant private messages sent by a single account within 30 minutes. The standardized value = 20 / 30 ≈ 0.67, with a corresponding weight of 0.1, and a sub-item score = 0.67 × 0.1 = 0.067. Percentage of private messages sent to strangers: The original data shows 100% strangers. The standardized value = 1.0, with a corresponding weight of 0.3, and a sub-item score = 1.0 × 0.3 = 0.3. Number of IP changes: The original data shows 1 change. The maximum benchmark threshold for a single time period on the platform is 5 changes. The standardized value = 1 / 5 = 0.2, with a corresponding weight of 0.1, and a sub-item score = 0.2 × 0.1 = 0.02. The total value of the five comprehensive features = 0.067 + 0.3 + 0.02 + 0.3 + 0.16 = 0.847. The base score is 100 points. The penalty coefficient for abnormal accounts is 0.53. The final health score for account A = 0.847 × 100 × 0.53 ≈ 45 points. Since the score is less than 60 points, it is considered an abnormal account. Determine the number of accounts bound to the current device: Extract the 10 accounts bound to device ID: DEV001. If the number of accounts bound to this device exceeds the threshold of 5, it is considered a cluster anomaly. Generate a cluster ID: CLUSTER001 and mark the 10 accounts as cluster anomalies. Based on the abnormal accounts and cluster anomaly accounts, after deduplication, the total number of abnormal accounts is obtained, and the percentage of abnormal accounts is calculated. At 10:00 AM, the total number of abnormal accounts was 1.2 million, and the total number of accounts was 20 million. The percentage of abnormal accounts was 1.2 million / 20 million × 100% = 6%, and the percentage of abnormal accounts within the cluster was 96% / 1.2 million × 100% = 80%. The 6% percentage of abnormal accounts met the conditions for a Level 1 circuit breaker (5%-10%), generating the following Level 1 circuit breaker policy: limiting the frequency of new account registration (from 10 per minute to 5 per minute) and limiting the private message traffic of abnormal accounts (≤10 messages per hour). At 12:00 PM, the total number of abnormal accounts was 2.2 million, and the percentage of abnormal accounts was 2.2 million / 20 million × 100% = 11%, meeting the conditions for a Level 2 circuit breaker (10%-20%). The following Level 2 circuit breaker policy was generated: suspending new account registration, disabling posting and private message functions for abnormal accounts, and limiting login traffic from abnormal IP ranges to 50%. The request frequency of the registration interface is limited through the user-side interface (a counter is set to process only 5 registration requests per minute), a rate limiting prompt is returned for the private message interface of abnormal accounts, and only 50 login requests per second are processed for abnormal IP ranges (such as 192.168.1.0 / 24); the regular handling service B7 bans newly identified abnormal accounts (for 7 days).Real-time monitoring of server CPU utilization showed a decrease from 75% before the Level 1 circuit breaker to 60%, and further to 50% after the Level 2 circuit breaker. Response time for normal user private messages collected from the client interface decreased from 2.5 seconds to 1 second. User complaints decreased from 50 per hour to 10 per hour. The circuit breaker was deemed effective, and the Level 2 circuit breaker was maintained until 6 PM. At 6 PM, the percentage of abnormal accounts dropped to 9%, a circuit breaker downgrade command was generated, and new account registration resumed at a frequency of 8 per minute, while abnormal accounts were still subject to rate limiting. At midnight, the percentage of abnormal accounts dropped to 3%, a circuit breaker release command was generated, normal configuration was restored, and remaining abnormal accounts continued to be processed.

[0124] In addition, data such as health scores, abnormal percentages, and cluster size can be pushed to the operation and management end in real time and displayed as visual reports; the log analysis service records the time, measures, and effects of circuit breaker execution and stores them in the behavior database for subsequent optimization of scenario weights and thresholds.

[0125] Thus, by adopting the solution in this embodiment, a three-layer collaborative logic based on "scenario-based quantitative assessment - cluster association identification - scale threshold circuit breaker" can be used to first achieve accurate quantification of account health through dynamic weight adjustment of scenarios, then identify clustered abnormal accounts through association dimensions such as devices and IPs to improve the comprehensiveness of identification, and finally trigger a tiered circuit breaker mechanism based on real-time monitoring of the proportion of abnormal accounts. This controls anomalies while ensuring the stability of platform resources and services, achieving closed-loop control of "accurate identification - cluster management and control - tiered circuit breaker".

[0126] Furthermore, by adopting the solution in this embodiment, in highly active scenarios, the weight of features that may also increase for normal users, such as the number of posts and login frequency, is reduced, while the weight of core abnormal features, such as the number of accounts bound to a device and the proportion of strangers sending private messages, is increased. This avoids misjudging users who post normally during promotional periods as abnormal. At the same time, by mining device associations, 1,000 abnormal accounts bound to 100 devices are identified. Compared with the single-account judgment of related technologies, the false negative rate is reduced by 70%, which improves the accuracy of abnormal account identification and reduces the false positive rate of abnormal accounts by 60%.

[0127] Furthermore, by employing the solution in this embodiment, a tiered circuit breaker mechanism can improve the response speed for handling large-scale anomalies by 80% and reduce resource consumption by 40%. When the proportion of abnormal accounts reaches a threshold, registration and rate limiting of abnormal behavior are directly restricted at the system level. Compared to handling individual accounts one by one with related technologies, this reduces repetitive processing tasks on the server. For example, after a level 2 circuit breaker, the server CPU utilization drops from 75% to 50%, the response time drops from 2.5 seconds to 1 second, the handling speed is improved from 0.5 seconds for a single account ban to instantaneous batch rate limiting, and the response latency is reduced from 30 minutes to 1 minute.

[0128] Furthermore, the solution in this embodiment establishes a closed loop of anomaly scale monitoring, circuit breaker triggering, and effect feedback. Through dynamic adjustment of the three circuit breaker levels, anomalies are controlled while avoiding excessive circuit breaking that could impact normal users. In this example, the three-level circuit breaker only suspends non-core functions like commenting and liking, ensuring core functions such as login and browsing are maintained. Real-time data feedback allows for precise adjustment of the circuit breaker level, preventing service paralysis during outbreaks of related technical anomalies. The number of complaints from normal users decreased from 50 per hour to 10, significantly improving the user experience guarantee rate, enhancing platform service stability, and achieving a 99% normal user experience guarantee rate.

[0129] Furthermore, by adopting the solution in this embodiment, the need for manual intervention can be reduced through an automated circuit breaker mechanism. Only one operator is required to monitor reports, thus reducing labor costs. At the same time, accurate anomaly identification reduces user churn and compensation costs caused by mistakenly banning normal accounts. It can prevent normal users from being mistakenly banned, improve user retention rate by 5%, and reduce operating costs by 30%.

[0130] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0131] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0132] Figure 3 This application provides a structural block diagram of an apparatus for processing abnormal accounts according to one embodiment of the present application. Figure 3As shown. The abnormal account processing device 300 of this embodiment may include an acquisition unit 301, an extraction unit 302, an evaluation unit 303, a determination unit 304, an acquisition unit 305, and a circuit breaker unit 306. The acquisition unit 301 is used to acquire basic account information, account behavior information, and scenario information of the platform; the extraction unit 302 is used to perform feature extraction processing on the basic account information and account behavior information based on the scenario information to obtain account feature information corresponding to the scenario information and the weight value of the account feature information; the evaluation unit 303 is used to evaluate the platform's accounts based on the account feature information corresponding to the scenario information and the weight value of the account feature information to obtain abnormal account information of the platform; the determination unit 304 is used to determine cluster abnormal account information of the platform based on the basic account information and account behavior information; the acquisition unit 305 is used to obtain a circuit breaker strategy for abnormal accounts based on the abnormal account information and cluster abnormal account information using preset circuit breaker rules; and the circuit breaker unit 306 is used to process the abnormal accounts of the platform based on the circuit breaker strategy for abnormal accounts.

[0133] Optionally, in one possible implementation of this embodiment, the extraction unit 302 is used to determine a preset feature weight table corresponding to the scene information; based on the scene information, perform feature extraction processing on the account basic information and account behavior information to obtain account feature information corresponding to the scene information; and based on the account feature information corresponding to the scene information and the preset feature weight table, obtain the weight value of the account feature information.

[0134] Optionally, in one possible implementation of this embodiment, the evaluation unit 303 is used to obtain the health score of the account based on the account feature information corresponding to the scene information and the weight value of the account feature information using a preset health score algorithm; and in response to the account health score being less than a preset health threshold, to determine that the account is abnormal account information of the platform.

[0135] Optionally, in one possible implementation of this embodiment, the determining unit 304 is used to determine, based on the account basic information and account behavior information, the device-associated account information, the IP-associated account information, and the behavior-associated account information; and to determine the platform's cluster abnormal account information based on preset cluster abnormal account conditions, the device-associated account information, the IP-associated account information, and the behavior-associated account information.

[0136] Optionally, in one possible implementation of this embodiment, the determining unit 304 is configured to: determine the number of accounts associated with the device based on the account information associated with the device; and determine the accounts associated with the device as first cluster abnormal accounts in response to the number of accounts associated with the device exceeding a preset first quantity threshold; or determine the number of accounts associated with an IP address based on the account information associated with the IP address; and determine the accounts associated with the IP address as second cluster abnormal accounts in response to the number of accounts associated with the IP address exceeding a preset second quantity threshold; or determine the similarity of accounts associated with behavior based on the account information associated with behavior; and determine the accounts associated with behavior as third cluster abnormal accounts in response to the similarity of accounts associated with behavior exceeding a preset similarity threshold; and determine the cluster abnormal account information of the platform based on the first cluster abnormal accounts, the second cluster abnormal accounts, and the third cluster abnormal accounts.

[0137] In one possible implementation, the obtaining unit 305 is configured to obtain the percentage of abnormal accounts and the percentage of abnormal accounts in the cluster based on the abnormal account information and the cluster abnormal account information; in response to the percentage of abnormal accounts and the percentage of abnormal accounts in the cluster satisfying a preset first-level circuit breaker condition, obtain a circuit breaker strategy for the abnormal accounts based on the first-level circuit breaker strategy; in response to the percentage of abnormal accounts or the percentage of abnormal accounts in the cluster satisfying a preset second-level circuit breaker condition, obtain a circuit breaker strategy for the abnormal accounts based on the second-level circuit breaker strategy; and in response to the percentage of abnormal accounts satisfying a preset third-level circuit breaker condition, obtain a circuit breaker strategy for the abnormal accounts based on the third-level circuit breaker strategy.

[0138] In this embodiment, the acquisition unit obtains basic account information, account behavior information, and scenario information of the platform. The extraction unit performs feature extraction processing on the basic account information and account behavior information based on the scenario information to obtain account feature information corresponding to the scenario information and the weight value of the account feature information. The evaluation unit evaluates the platform's accounts based on the account feature information corresponding to the scenario information and the weight value of the account feature information to obtain abnormal account information of the platform. The determination unit determines the platform's cluster abnormal account information based on the basic account information and account behavior information. The acquisition unit obtains the abnormal account circuit breaker strategy based on the abnormal account information and cluster abnormal account information using preset circuit breaker rules. The circuit breaker unit processes the abnormal accounts of the platform based on the circuit breaker strategy. Because abnormal account identification and cluster abnormal account identification can be performed on platform accounts separately based on the platform's scenario information, and the circuit breaker strategy for abnormal accounts is obtained based on the two types of abnormal accounts using preset circuit breaker rules, the accuracy of abnormal account identification is improved, the false positive rate is effectively reduced, and accurate identification of abnormal accounts in social platforms can be achieved, thereby ensuring the reliability and security of social platform services.

[0139] The technical solution of this application involves the collection, storage, use, processing, transmission, provision, and disclosure of user personal information, such as user image and attribute data, which comply with relevant laws and regulations and do not violate public order and good morals.

[0140] According to embodiments of this application, this application also provides an electronic device, a readable storage medium, and a computer program product.

[0141] Figure 4 A schematic block diagram of an example electronic device 400 that can be used to implement embodiments of this application is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein.

[0142] like Figure 4As shown, the electronic device 400 includes a computing unit 401, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 402 or a computer program loaded from a storage unit 408 into a random access memory (RAM) 403. The RAM 403 may also store various programs and data required for the operation of the electronic device 400. The computing unit 401, ROM 402, and RAM 403 are interconnected via a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.

[0143] Multiple components in electronic device 400 are connected to I / O interface 405, including: input unit 406, such as keyboard, mouse, etc.; output unit 407, such as various types of displays, speakers, etc.; storage unit 408, such as disk, optical disk, etc.; and communication unit 409, such as network card, modem, wireless transceiver, etc. Communication unit 409 allows electronic device 400 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0144] The computing unit 401 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 401 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 401 performs the various methods and processes described above, such as the abnormal account processing method. For example, in some embodiments, the abnormal account processing method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 408. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 400 via ROM 402 and / or communication unit 409. When the computer program is loaded into RAM 403 and executed by the computing unit 401, one or more steps of the abnormal account processing method described above may be performed. Alternatively, in other embodiments, the computing unit 401 may be configured to perform the abnormal account processing method by any other suitable means (e.g., by means of firmware).

[0145] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0146] The program code used to implement the methods of this application may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0147] In the context of this application, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0148] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0149] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0150] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0151] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this application can be achieved, and this is not limited herein.

[0152] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for handling abnormal accounts, characterized in that, The method includes: Obtain basic account information, account behavior information, and scenario information from the platform; Based on the scenario information, feature extraction processing is performed on the basic account information and account behavior information to obtain the account feature information corresponding to the scenario information and the weight value of the account feature information; Based on the account feature information corresponding to the scenario information and the weight value of the account feature information, the accounts on the platform are evaluated to obtain abnormal account information of the platform. Based on the account basic information and account behavior information, the abnormal account information of the platform's cluster is determined; Based on the abnormal account information and cluster abnormal account information, the circuit breaker strategy for abnormal accounts is obtained using preset circuit breaker rules. Based on the circuit breaker policy for the abnormal accounts, the abnormal accounts on the platform are processed.

2. The method according to claim 1, characterized in that, The step of performing feature extraction processing on the account basic information and account behavior information based on the scenario information to obtain account feature information corresponding to the scenario information and the weight value of the account feature information includes: Determine the preset feature weight table corresponding to the scene information; Based on the scenario information, feature extraction processing is performed on the basic account information and account behavior information to obtain the account feature information corresponding to the scenario information; Based on the account feature information corresponding to the scenario information and the preset feature weight table, the weight value of the account feature information is obtained.

3. The method according to claim 1, characterized in that, The process of evaluating accounts on the platform based on account feature information corresponding to the scenario information and the weight value of the account feature information to obtain abnormal account information on the platform includes: Based on the account feature information corresponding to the scenario information and the weight value of the account feature information, the health score of the account is obtained using a preset health score algorithm; If the health score of an account is less than a preset health threshold, the account is identified as an abnormal account on the platform.

4. The method according to claim 1, characterized in that, The process of determining abnormal account information in the platform's cluster based on the account's basic information and account behavior information includes: Based on the aforementioned basic account information and account behavior information, determine the device-associated account information, IP-associated account information, and behavior-associated account information; Based on preset abnormal account conditions for the cluster, account information associated with the device, account information associated with the IP, and account information associated with the behavior, the abnormal account information for the cluster of the platform is determined.

5. The method according to claim 4, characterized in that, Based on preset abnormal cluster account conditions, account information associated with the device, account information associated with the IP address, and account information associated with behavior, the abnormal cluster account information of the platform is determined, including: Based on the account information associated with the device, the number of accounts associated with the device is determined, and in response to the number of accounts associated with the device exceeding a preset first threshold, the account associated with the device is determined to be a first cluster abnormal account, or... Based on the account information associated with the IP address, the number of accounts associated with the IP address is determined. If the number of accounts associated with the IP address exceeds a preset second threshold, the accounts associated with the IP address are determined to be abnormal accounts in the second cluster. Based on the account information associated with the behavior, the similarity of the accounts associated with the behavior is determined, and in response to the similarity of the accounts associated with the behavior exceeding a preset similarity threshold, the accounts associated with the behavior are determined to be abnormal accounts in the third cluster. Based on the abnormal accounts in the first cluster, the abnormal accounts in the second cluster, and the abnormal accounts in the third cluster, the abnormal account information of the platform's clusters is determined.

6. The method according to any one of claims 1-5, characterized in that, The step of obtaining a circuit breaker strategy for abnormal accounts based on the abnormal account information and cluster abnormal account information, using preset circuit breaker rules, includes: Based on the abnormal account information and cluster abnormal account information, the percentage of abnormal accounts and the percentage of cluster abnormal accounts are obtained; In response to the abnormal account ratio and the cluster abnormal account ratio meeting the preset first-level circuit breaker condition, the circuit breaker policy for the abnormal account is obtained based on the first-level circuit breaker policy. In response to the abnormal account ratio or the abnormal account ratio of the cluster meeting the preset second-level circuit breaker condition, the circuit breaker policy for the abnormal account is obtained based on the second-level circuit breaker policy. In response to the abnormal account ratio meeting the preset third-level circuit breaker condition, the circuit breaker strategy for the abnormal account is obtained based on the third-level circuit breaker strategy.

7. A device for processing abnormal accounts, characterized in that, The device includes: The acquisition unit is used to acquire basic account information, account behavior information, and scenario information from the platform. The extraction unit is used to perform feature extraction processing on the account basic information and account behavior information based on the scene information, so as to obtain the account feature information corresponding to the scene information and the weight value of the account feature information; An evaluation unit is used to evaluate the accounts on the platform based on the account feature information corresponding to the scenario information and the weight value of the account feature information, so as to obtain abnormal account information of the platform. The determining unit is used to determine the abnormal account information of the platform's cluster based on the account basic information and account behavior information; The obtaining unit is used to obtain the circuit breaker strategy for the abnormal account based on the abnormal account information and the cluster abnormal account information, using preset circuit breaker rules. The circuit breaker unit is used to process abnormal accounts on the platform based on the circuit breaker policy of the abnormal accounts.

8. An electronic device, characterized in that, include: At least one processor; as well as A memory that is communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1-6.

9. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-6.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method according to any one of claims 1-6.