Abnormal account determination method and device, storage medium and electronic equipment

Abstract

The invention discloses an abnormal account determination method and device, a storage medium and electronic equipment. The method comprises the steps that static features and dynamic features of a to-be-detected account are acquired, the static features are used for representing account information generated by the to-be-detected account in the registration process, the dynamic features are used for representing the invitation behavior of the to-be-detected account, and the invitation behavior represents the behavior that the to-be-detected account invites a new user to register; and generating a target evaluation parameter of the to-be-detected account based on the static feature and the dynamic feature, and determining the to-be-detected account as an abnormal account under the condition that the target evaluation parameter meets a preset threshold condition. According to the method and the device, the technical problems that the abnormal account identification efficiency is low and the accuracy is difficult to guarantee in the related technology are solved.

Description

Technical Field

[0001] The present application relates to the field of computers, and more specifically, to a method and device for determining an abnormal account, a storage medium, and an electronic device. Background Art

[0002] Currently, users can get rewards by inviting new users to participate in activities. Internet platforms and online service providers face the problem of malicious users taking advantage of new users' behavior when inviting new users to participate in activities. However, the parameter values ​​corresponding to user identities are too single, making it difficult to identify malicious behavior. This phenomenon is common in current promotion activities, which not only increases invalid expenditures, but also seriously affects the promotion effect.

[0003] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0004] The embodiments of the present application provide a method and device for determining an abnormal account, a storage medium, and an electronic device to at least solve the technical problems in the related art that the efficiency of identifying abnormal accounts is low and the accuracy is difficult to ensure.

[0005] According to one aspect of an embodiment of the present application, a method for determining an abnormal account is provided, comprising: obtaining static features and dynamic features of an account to be detected, wherein the static features are used to represent account information generated by the account to be detected during a registration process, and the dynamic features are used to represent an invitation behavior of the account to be detected, and the invitation behavior represents the behavior of the account to be detected inviting a new user to register; generating target evaluation parameters of the account to be detected based on the static features and the dynamic features; and determining the account to be detected as an abnormal account when the target evaluation parameters meet a preset threshold condition.

[0006] According to another aspect of an embodiment of the present application, a device for determining an abnormal account is also provided, including: an acquisition module, used to acquire static features and dynamic features of an account to be detected, wherein the static features are used to represent account information generated by the account to be detected during the registration process, and the dynamic features are used to represent the invitation behavior of the account to be detected, and the invitation behavior represents the behavior of the account to be detected inviting new users to register; a generation module, used to generate target evaluation parameters of the account to be detected based on the static features and the dynamic features; a determination module, used to determine the account to be detected as an abnormal account when the target evaluation parameters meet preset threshold conditions.

[0007] In an exemplary embodiment, the device is used to generate the target evaluation parameters of the account to be detected based on the static features and the dynamic features in the following manner: determine the first evaluation parameters of the account to be detected based on the static features and the sample static features of the registered accounts; determine the second evaluation parameters of the account to be detected based on the frequency and number of occurrences of the invitation behavior in the dynamic features; and perform a weighted combination of the first evaluation parameter and the second evaluation parameter to determine the target evaluation parameter.

[0008] In an exemplary embodiment, the device is used to determine the second evaluation parameter of the account to be detected based on the frequency and number of occurrences of the invitation behavior in the dynamic feature in the following manner: determine the frequency and number of occurrences in a preset manner, wherein the preset manner includes at least one of the following: sliding time window driven, event driven; determine the frequency evaluation parameter based on the frequency and a preset frequency threshold; determine the number of occurrence evaluation parameter based on the number of occurrences and a preset number threshold; determine the second evaluation parameter based on the frequency evaluation parameter and the number of occurrence evaluation parameter.

[0009] In an exemplary embodiment, the device is used to determine the second evaluation parameter of the account to be detected based on the frequency and number of occurrences of the invitation behavior in the dynamic feature in the following manner: determine the first dynamic evaluation sub-parameter of the account to be detected based on the frequency and number of occurrences of the invitation behavior in the dynamic feature; determine the second dynamic evaluation sub-parameter based on the similarity between the static characteristics of the invited accounts corresponding to the invitation behavior; and perform a weighted combination of the first dynamic evaluation sub-parameter and the second dynamic evaluation sub-parameter to determine the second evaluation parameter.

[0010] In an exemplary embodiment, the device is used to generate the target evaluation parameters of the account to be detected based on the static features and the dynamic features in the following manner: input the static features and the dynamic features into a target abnormal account identification model to determine the target evaluation parameters of the account to be detected, wherein the target abnormal account identification model includes a first sub-model and a second sub-model, the first sub-model is used to determine the similarity between the static features and the sample static features, and the second sub-model is used to determine the similarity between the invited account static features of the invited account corresponding to the invitation behavior.

[0011] In an exemplary embodiment, the device is used to determine the account to be detected as an abnormal account when the target evaluation parameter satisfies the preset threshold condition in the following manner: when the target evaluation parameter satisfies the first threshold condition, the account to be detected is determined as the abnormal account, and the abnormal level of the abnormal account is determined to be a first level, wherein the first level corresponds to a first response method, and the preset threshold condition includes the first threshold condition; when the target evaluation parameter satisfies the second threshold condition, the account to be detected is determined as the abnormal account, and the abnormal level of the abnormal account is determined to be a second level, wherein the second level is higher than the first level, the second level corresponds to a second response method, the second response method is different from the first response method, and the preset threshold condition includes the second threshold condition.

[0012] In an exemplary embodiment, the device is used to obtain static and dynamic features of the account to be detected in the following manner: obtaining the account information, geographic information and device information of the account to be detected; performing feature extraction on the account information, the geographic information and the device information of the account to be detected to determine the static features; and obtaining the dynamic features of the account to be detected in real time.

[0013] According to another aspect of the embodiments of the present application, a computer-readable storage medium is provided, in which a computer program is stored, wherein the computer program is configured to execute the above-mentioned method for determining abnormal accounts when running.

[0014] According to another aspect of the embodiment of the present application, a computer program product or a computer program is provided, the computer program product or the computer program includes computer instructions, the computer instructions are stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the above abnormal account determination method.

[0015] According to another aspect of the embodiments of the present application, there is also provided an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the above-mentioned method for determining an abnormal account through the computer program.

[0016] In an embodiment of the present application, a method of comprehensively analyzing the static features and dynamic features of the account to be detected is adopted. The static features are used to extract data generated during the registration process such as account information and device fingerprints, and the dynamic features are used to analyze the invitation behavior of the account. The static features and dynamic features are weighted and calculated through an anomaly detection algorithm to generate a comprehensive score. Graded alarms are given according to the score and frequency of occurrence, and possible abnormal behaviors are handled in a timely manner, thereby achieving the purpose of accurately identifying abnormal accounts, thereby achieving the technical effect of improving recognition efficiency and response speed, and further solving the technical problems in related technologies of low recognition efficiency and difficulty in ensuring accuracy of abnormal accounts. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0018] Figure 1 is a schematic diagram of an application environment of an optional method for determining an abnormal account according to an embodiment of the present application;

[0019] Figure 2 is a flowchart of an optional method for determining an abnormal account according to an embodiment of the present application;

[0020] Figure 3 is a system schematic diagram of an optional method for determining an abnormal account according to an embodiment of the present application;

[0021] Figure 4 is a schematic diagram of an optional method for determining an abnormal account according to an embodiment of the present application;

[0022] Figure 5 is a schematic structural diagram of an optional device for determining an abnormal account according to an embodiment of the present application;

[0023] Figure 6 is a schematic diagram of the structure of an optional abnormal account determination product according to an embodiment of the present application;

[0024] Figure 7 It is a schematic diagram of the structure of an optional electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0025] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0026] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0027] In order to more clearly understand the technical solution provided by the embodiments of the present application, the key terms involved in the embodiments of the present application are first introduced here:

[0028] Inviting new users: Inviting new users refers to the behavior of users inviting others to register or participate in promotional activities held by various Internet platforms or online merchants in order to obtain rewards or discounts. This behavior is usually a strategy to encourage users to expand their participation in activities and user base, which can not only enhance the popularity and influence of the activities, but also increase user participation and loyalty.

[0029] Rule Engine: A rule engine is a software tool or system for managing and executing rules. Based on a set of predefined rules, the rule engine helps automate decision-making and processing to improve efficiency and accuracy. It separates rules and business logic from the application, making rules more flexible to manage and modify without modifying the application code.

[0030] Static feature analysis: Identify users who may be abnormal by analyzing their basic information, including registration account, device information, geographic location, etc.

[0031] Dynamic feature analysis: Identify abnormal behaviors by monitoring and analyzing user behavior trajectories. Use data mining and machine learning algorithms to build user behavior models and detect users who do not conform to normal behavior patterns.

[0032] Anomaly detection method: Anomaly detection is the use of data mining methods to discover abnormal data that is inconsistent with the distribution of the data set. It is also called outlier detection, outlier detection, etc.

[0033] Sliding Window: Sliding Window is a technology used to manage and process data streams. It defines a fixed-size window on the data stream to achieve efficient data processing, transmission control, and resource management. This technology is widely used in computer networks, algorithm design, image processing, and other fields.

[0034] The present application is described below in conjunction with embodiments:

[0035] According to one aspect of an embodiment of the present application, a method for determining an abnormal account is provided. Optionally, in this embodiment, the above-mentioned method for determining an abnormal account can be applied to Figure 1 In the hardware environment composed of the server 101 and the terminal device 103 shown in FIG. Figure 1 As shown, the server 101 is connected to the terminal device 103 via a network, and can be used to provide services for the terminal device or an application 107 installed on the terminal device. The application can be a video application, an instant messaging application, a browser application, an educational application, a game application, etc. A database 105 may be set up on the server or independently of the server to provide data storage services for the server 101, for example, a game data storage server. The above-mentioned network may include, but is not limited to, a wired network and a wireless network, wherein the wired network includes, a local area network, a metropolitan area network and a wide area network; the wireless network includes, Bluetooth, WIFI and other networks that implement wireless communication; the terminal device 103 may be a terminal configured with an application, and may include, but is not limited to, at least one of the following: a mobile phone (such as an Android phone, an iOS phone, etc.), a laptop computer, a tablet computer, a PDA, a MID (Mobile Internet Devices), a PAD, a desktop computer, a smart TV, an intelligent voice interaction device, a smart home appliance, a vehicle-mounted terminal, an aircraft, a virtual reality (VR) terminal, an augmented reality (AR) terminal, a mixed reality (MR) terminal and other computer devices; the above-mentioned server may be a single server, a server cluster consisting of multiple servers, or a cloud server.

[0036] Combination Figure 1As shown, the above-mentioned method for determining an abnormal account can be executed by an electronic device, which can be a terminal device or a server. The above-mentioned method for determining an abnormal account can be implemented by the terminal device or the server separately, or by the terminal device and the server together.

[0037] The above is only an example and is not specifically limited in this embodiment.

[0038] Optionally, as an optional implementation, as Figure 2 As shown, the above method for determining abnormal accounts includes:

[0039] S202, obtaining static features and dynamic features of the account to be detected, wherein the static features are used to represent the account information generated during the registration process of the account to be detected, and the dynamic features are used to represent the invitation behavior of the account to be detected, and the invitation behavior represents the behavior of the account to be detected inviting new users to register;

[0040] S204, generating target evaluation parameters of the account to be detected based on the static features and the dynamic features;

[0041] S206: When the target evaluation parameter meets the preset threshold condition, the account to be detected is determined as an abnormal account.

[0042] Optionally, in an embodiment of the present application, static features refer to account information generated during the registration process of the account to be detected, including but not limited to the email address or mobile phone number submitted by the user when registering, device fingerprints, geographic information, etc. This information is used as the input of the model to detect abnormal behavior. For example, the email address / mobile phone number is an important credential that uniquely identifies the user. The format is verified by regular expressions, and its authenticity is ensured by third-party services. Device fingerprints include hardware features, terminal numbers, IP addresses, etc. This information is often fixed on the same device, which helps to identify and verify the uniqueness of the device. Geographic information involves the geographic location of the user when registering, which is obtained through IP geolocation or GPS positioning, which helps to further analyze user behavior patterns.

[0043] Optionally, in an embodiment of the present application, the dynamic feature refers to the invitation behavior of the account to be detected, that is, the behavior of the account to be detected inviting new users to register. This includes but is not limited to the total number of invitations, the invitation frequency, and the relevance of new users. For example, the total number of invitations records the total number of times a user invites new users, the invitation frequency analyzes the number of times a user invites new users within a specific time window, and the relevance of new users is based on the static features of the invited account, calculating the similarity between the invited account and the users invited by the inviter in the past. These dynamic indicators help to monitor and evaluate abnormal behavior of users in real time.

[0044] Optionally, in an embodiment of the present application, the target evaluation parameter refers to a parameter generated based on static features and dynamic features for evaluating whether the account to be detected is abnormal. These parameters include, but are not limited to, a static feature anomaly score and an invitation behavior anomaly score. The static feature anomaly score is based on the static features of the account and calculates its similarity with all registered users. The invitation behavior anomaly score is based on the number of invitations, frequency, and relevance of the user to new users to calculate whether the behavior is abnormal. After these scores are weighted and combined, a comprehensive score is obtained to determine whether the account is abnormal.

[0045] Optionally, in the embodiment of the present application, an abnormal account refers to an account that is determined to be abnormal when the target evaluation parameter meets the preset threshold condition. This means that when the comprehensive score of the account to be detected exceeds the set threshold, the account is marked as an abnormal account that may have abnormal behavior, and corresponding monitoring and disposal measures need to be taken. This setting helps to identify and deal with potential risks in a timely manner, reduce invalid expenditures, and maintain the fairness and security of the platform.

[0046] It should be noted that the acquisition of static features and dynamic features is not limited to specific information types, and this application does not limit this. Static features may include but are not limited to multiple dimensions such as user basic information, device information, and geographic location information. For example, basic information may cover the user's registered email address, mobile phone number, user name, etc.; device information may include device model, operating system version, device fingerprint, etc.; geographic location information may be obtained through IP address resolution, GPS positioning, etc. The combination of these static features helps to build a comprehensive user portrait and provide basic data for abnormal behavior identification. The invitation behavior of dynamic features also includes multiple dimensions, such as invitation frequency, invitation time distribution, invitation success rate, etc. Invitation frequency can refer to the number of invitations issued by a user within a specific time period; invitation time distribution can analyze the time period when the user issues invitations, whether it is concentrated in a specific time period; invitation success rate can measure the proportion of new users invited by the user that actually register. The analysis of these dynamic features helps to identify abnormal invitation patterns, such as abnormally high frequency invitations or abnormally high invitation success rates.

[0047] In addition, the generation of target evaluation parameters is based on the comprehensive consideration of the above-mentioned static and dynamic characteristics, which is not limited in this application. These parameters can be generated by various technical means such as machine learning algorithms, statistical analysis methods or rule engines. For example, cluster analysis can be used to classify user behaviors, or the risk level of user behaviors can be quantified by building a risk scoring model. The design of target evaluation parameters is intended to provide a quantitative and operational evaluation standard for real-time monitoring and evaluation of user behaviors.

[0048] Finally, the conditions for determining the account to be detected as an abnormal account are also diverse, and this application does not limit this. The preset threshold can be a statistical analysis result based on historical data, or it can be a policy parameter set according to business needs and risk tolerance. For example, a risk threshold can be set based on the output of the user behavior scoring model, and accounts exceeding this threshold are marked as abnormal; or a combination of multiple indicators, such as static feature anomaly scores and dynamic feature anomaly scores, can be used to comprehensively judge the risk level of the account. This flexible threshold setting mechanism allows adjustments based on different application scenarios and security requirements to achieve the best anomaly detection effect.

[0049] For example, the following is a specific implementation process of an e-commerce platform applying this proposal in new user registration and invitation activities:

[0050] S1: Collect static features. During the user registration process, the system automatically collects the user's static features, including but not limited to basic information filled in by the user such as email address or mobile phone number, device information such as device model and operating system version, and geographic location information such as the approximate location obtained through IP address resolution. In addition, the system will also detect device fingerprints, including hardware features, terminal number, IP address, whether jailbroken or rooted, etc., as well as more accurate geographic location information obtained through GeoIP services.

[0051] S2: Monitoring dynamic features. The system monitors the user's dynamic invitation behavior in real time, including the total number of invitations, invitation frequency, and new user relevance. For example, the system will count the number of times a user invites new users within a specific time window (such as 1 hour or 1 day), and analyze the similarity between the invited new users, such as calculating the similarity between the invited account and the historical inviting user through anomaly detection algorithms.

[0052] S3: Generate target evaluation parameters. Combining the above static and dynamic features, the system generates target evaluation parameters for each account to be detected. These parameters may include static feature anomaly scores and invitation behavior anomaly scores, which are calculated by anomaly detection algorithms such as the isolation forest model. The algorithm uses the behavior pattern of normal users as a benchmark, compares the behavior of the account to be detected with the benchmark, and calculates its degree of anomaly.

[0053] S4: Set thresholds and identify abnormal accounts. The system presets thresholds based on historical data and business needs. When the target evaluation parameter of the account to be detected exceeds this threshold, the system marks it as an abnormal account. The setting of thresholds may take into account multiple factors, including business risk tolerance, statistical analysis results of historical abnormal behavior data, etc.

[0054] S5: Respond to abnormal accounts. Once an account is identified as abnormal, the system will trigger the corresponding response mechanism. For accounts with serious abnormalities, the system may immediately suspend its new invite function and implement behavior interception through the API gateway or service middleware layer. At the same time, the system will notify the operator to conduct further review and may send warning information through instant messaging applications, text messages or emails.

[0055] Through this embodiment, it is possible to effectively identify and prevent abnormal new invitation behaviors, and reduce losses caused by abnormal behaviors of malicious users. The system improves the accuracy and efficiency of identifying abnormal behaviors by comprehensively analyzing static and dynamic features. The introduction of preset thresholds and real-time response mechanisms enables the platform to quickly respond to potential risks and take timely measures to protect the interests of the platform and normal users. In addition, by continuously collecting new data and actual detection results, the system can iteratively optimize models and rules, further improve the sensitivity and accuracy of detection, and provide a safer and fairer promotion environment for e-commerce platforms.

[0056] As an optional solution, target evaluation parameters of the account to be detected are generated based on static features and dynamic features, including:

[0057] Determine a first evaluation parameter of the account to be detected based on the static features and the sample static features of the registered accounts;

[0058] Determine a second evaluation parameter of the account to be detected based on the frequency and number of times the invitation behavior occurs in the dynamic feature;

[0059] The first evaluation parameter and the second evaluation parameter are weightedly combined to determine a target evaluation parameter.

[0060] Optionally, in an embodiment of the present application, the first evaluation parameter of the account to be detected based on the static features and the sample static features of the registered account refers to determining the first evaluation parameter of the account to be detected by analyzing the static features of the account to be detected and comparing it with the sample static features of the registered account. The static features here include basic information of the user, such as registered account, device information, geographic location, etc. Specifically, this information can be obtained through the user's registration form, including but not limited to the user's email or mobile phone number, device fingerprint (such as CPU model, memory size, storage space, etc.), terminal number (such as Android ID of Android or Identifier for Vendor of iOS), IP address, and device model and version number, etc. Through the detailed collection and analysis of these static features, the input quality of the model can be significantly improved, providing accurate and comprehensive basic data for subsequent abnormal behavior detection. For example, if the device fingerprint of an account to be detected is inconsistent with the device fingerprint of most registered accounts, or its IP address does not match the geographical location claimed by the user, then the first evaluation parameter of this account may be marked as abnormal.

[0061] Optionally, in an embodiment of the present application, the above-mentioned determination of the second evaluation parameter of the account to be detected based on the frequency and number of occurrences of the invitation behavior in the dynamic feature refers to determining the second evaluation parameter of the account to be detected by monitoring and analyzing the user's behavior trajectory, especially the behavior of inviting new users. Dynamic feature analysis focuses on the user's behavior pattern, including the total number of invitations and the frequency of invitations. For example, if a user invites a large number of new users in a very short period of time, or its invitation frequency is much higher than that of normal users, these behaviors may be regarded as abnormal. Through data mining and machine learning algorithms, a user behavior model can be established to detect users who do not conform to normal behavior patterns. For example, if an account invites 50 new users in one hour, and the invitation frequency of normal users may be only 1-2 new users per hour, then the second evaluation parameter of this account may be marked as abnormal.

[0062] Optionally, in an embodiment of the present application, the weighted combination of the first evaluation parameter and the second evaluation parameter, and determining the target evaluation parameter refers to combining the first evaluation parameter (based on static features) and the second evaluation parameter (based on dynamic features) of the account to be detected through a certain algorithm and weight to form a comprehensive evaluation parameter, namely the target evaluation parameter. This target evaluation parameter can more comprehensively reflect the behavioral characteristics of the account and help the system to more accurately identify abnormal accounts. In the process of weighted combination, different weights may be given to static features or dynamic features based on actual business needs and historical data analysis results. For example, if historical data shows that dynamic features are more critical in identifying abnormal behavior, then when calculating the target evaluation parameter, a higher weight may be given to dynamic features. In this way, the system can more flexibly adapt to different business scenarios and security requirements, and improve the accuracy and efficiency of abnormal behavior identification.

[0063] It should be noted that when determining the first evaluation parameter of the account to be detected based on static features and sample static features of registered accounts, the static features may include but are not limited to account information, device fingerprints, geographic information and other dimensions. For example, account information may include the type of domain name of the registered mailbox and the length of time the mailbox has been registered; device fingerprints may include the operating system version of the device, hardware configuration, whether it is jailbroken or rooted; geographic information may involve the geographic location corresponding to the IP address of the user when registering, GPS positioning results, etc. The combination of these dimensions can provide a comprehensive first evaluation parameter for the account to be detected.

[0064] Similarly, when determining the second evaluation parameter of the account to be detected based on the frequency and number of times of invitation behavior in the dynamic features, the dynamic features may involve the time distribution of invitation behavior, the geographical distribution of the invitees, the behavior patterns of the invitees, etc. For example, the time distribution of invitation behavior may include the number of invitations issued by the user in a specific time period; the geographical distribution of the invitees may involve the geographical locations where the invited users are concentrated; the behavior patterns of the invitees may include the behavior similarity of the invited users, the active time period, etc. These dimensions help to construct a multi-angle second evaluation parameter.

[0065] In addition, when the first evaluation parameter and the second evaluation parameter are weighted and combined, the weighting method can be flexibly adjusted according to actual business needs and data analysis results. For example, the weighting may be based on the registration time and activity of the account, and a newly registered account may require a higher dynamic feature weight; or based on the user's historical behavior record, the weight of static features may be increased for accounts with abnormal behavior in the past. In addition, the weighted combination may also consider dimensions such as the account's transaction volume, user feedback, and the account's social network connection strength. This application does not limit this, and allows personalized adjustment and optimization of these parameters according to different application scenarios and security requirements.

[0066] As an optional solution, the second evaluation parameter of the account to be detected is determined based on the frequency and number of times of the invitation behavior in the dynamic feature, including:

[0067] The occurrence frequency and the number of occurrences are determined by a preset method, wherein the preset method includes at least one of the following: sliding time window driven, event driven;

[0068] Determining an occurrence frequency evaluation parameter based on the occurrence frequency and a preset frequency threshold;

[0069] Determining an occurrence evaluation parameter based on the occurrence count and a preset number threshold;

[0070] The second evaluation parameter is determined based on the occurrence frequency evaluation parameter and the occurrence number evaluation parameter.

[0071] Optionally, in an embodiment of the present application, the above-mentioned preset method refers to a specific technology and method for determining the frequency and number of occurrences of user behavior, including but not limited to sliding time window drive and event drive. Sliding time window drive refers to defining a fixed-size time window and letting this window slide on the timeline to process and analyze user behavior events that occur within the time window. For example, a 1-hour sliding window can be set to count the number of invitations issued by users per hour. Event-driven means that the system responds to specific events. Whenever a user initiates an invitation behavior, the system records the event and analyzes the user's behavior frequency based on the accumulation of events. For example, whenever an invitation behavior of a new user is detected, the system updates the user's invitation behavior record.

[0072] Optionally, in an embodiment of the present application, the above-mentioned frequency evaluation parameter refers to a parameter obtained by comparing the actual frequency of occurrence of user behavior with a preset frequency threshold, which is used to evaluate the abnormality of user behavior. The preset frequency threshold can be the upper limit of the normal user behavior frequency obtained based on historical data analysis. For example, if the preset frequency threshold is set to no more than 5 invitations per hour, and a user initiates 10 invitations within an hour, then the user's frequency evaluation parameter will show abnormality. The above-mentioned number of occurrence evaluation parameter refers to a parameter obtained by comparing the total number of occurrences of user behavior with a preset number threshold, which is used to evaluate the frequency of user behavior. The preset number threshold can be the upper limit of the number of normal user behaviors obtained based on the analysis of user behavior patterns. For example, if the preset number threshold is set to no more than 20 invitations in a day, and a user initiates 30 invitations in a day, then the user's number of occurrence evaluation parameter will also show abnormality.

[0073] Optionally, in an embodiment of the present application, the second evaluation parameter refers to a comprehensive parameter obtained by comprehensively considering the frequency evaluation parameter and the number of occurrence evaluation parameter of the user behavior, which is used to more comprehensively evaluate the abnormality of the user behavior. This parameter can help the system more accurately identify possible abnormal behaviors, such as wool-pulling behavior. For example, if a user's frequency evaluation parameter and the number of occurrence evaluation parameter both exceed the preset threshold, then the user's second evaluation parameter will reflect a high risk, which may trigger further security review or automatic interception measures.

[0074] It should be noted that the sliding time window driver can be divided according to the time dimension, for example, user behavior can be counted at different granularities such as hours, days, and weeks. At the same time, the window size can also be adjusted according to different business scenarios. For example, a smaller time window can be used for high-frequency behavior analysis, and a larger time window can be used for low-frequency behavior analysis. Event-driven can be divided according to the behavior dimension. For example, an event record is triggered every time a user invites a new user. Events can be classified and processed according to different dimensions such as event type, source, or user grouping. This application is not limited to this. The frequency evaluation parameter can be considered from three dimensions: the density of user behavior, time distribution, and business rules. The density of user behavior can be measured by counting the number of behaviors in a unit time, the time distribution focuses on the distribution of user behavior in different time periods, and the business rule dimension involves specific frequency thresholds set according to different business needs. For example, during promotional activities, the threshold may need to be adjusted to adapt to different business needs. This application is not limited to this. The occurrence evaluation parameter can be evaluated from three dimensions: total control, user level, and behavior type. Total quantity control focuses on the total number of user behaviors within a certain period of time, user levels set different thresholds based on different user permissions and historical behavior records, and behavior types focus on specific categories of user behaviors, such as invitations, purchases, logins, etc. Each behavior type may have different number thresholds. This application does not limit this.

[0075] In addition, the second evaluation parameter can be comprehensively considered from three dimensions: comprehensive score, risk level and response strategy. The comprehensive score dimension weights and combines the evaluation parameters of frequency and number of occurrences to form a quantitative assessment of user behavior risk; the risk level dimension divides user behavior into different risk levels based on the comprehensive score, so as to facilitate the adoption of corresponding monitoring measures; the response strategy dimension formulates different response measures according to different risk levels, such as restricting behavior or manual review strategies for high-risk users. This application does not limit this.

[0076] As an optional solution, the second evaluation parameter of the account to be detected is determined based on the frequency and number of times of the invitation behavior in the dynamic feature, including:

[0077] Determine a first dynamic evaluation sub-parameter of the account to be detected based on the frequency and number of occurrences of the invitation behavior in the dynamic feature;

[0078] Determine a second dynamic evaluation sub-parameter based on the similarity between the static features of the invited accounts corresponding to the invitation behavior;

[0079] The first dynamic evaluation sub-parameter and the second dynamic evaluation sub-parameter are weightedly combined to determine a second evaluation parameter.

[0080] Optionally, in an embodiment of the present application, the above-mentioned first dynamic evaluation sub-parameter refers to a parameter determined based on the dynamic characteristics of the user's invitation behavior, and this parameter mainly focuses on the frequency and number of occurrences of the user's invitation behavior. Specifically, this parameter can be determined by analyzing the number of invitations issued by the user in a specific time period and the frequency of the invitations. For example, if a user sends a large number of invitations in a short period of time, or the frequency of invitations is much higher than normal, then the first dynamic evaluation sub-parameter of this user may show an abnormality. This parameter can help identify users who may have abnormal behavior, such as those who try to obtain improper benefits through a large number of invitations.

[0081] Optionally, in an embodiment of the present application, the above-mentioned second dynamic evaluation sub-parameter refers to a parameter determined by comparing static features between invited accounts, which include but are not limited to account registration information, device information, geographic location, etc. The determination of this parameter involves analyzing the static features of the invited accounts to identify whether there are abnormal similarities. For example, if multiple invited accounts have the same registered email suffix, the same device model, or a similar geographic location, this may indicate the possibility of batch registration or fake accounts. By calculating the similarity between the static features of these invited accounts, the second dynamic evaluation sub-parameter can be derived to further reveal potential abnormal behavior patterns.

[0082] In addition, the second evaluation parameter can be understood as a comprehensive parameter that combines the user's behavior frequency, number of occurrences, and the degree of similarity of static features between invited accounts to more comprehensively assess the user's abnormal behavior risk. The calculation of this parameter may involve different weight allocations, and different sub-parameters are given different weights based on actual business needs and risk control strategies. For example, if business analysis shows that the static feature similarity between accounts is more critical for identifying abnormal behavior, the second dynamic evaluation sub-parameter may be given a higher weight. The second evaluation parameter can more accurately reflect the user's abnormal behavior risk and provide support for subsequent risk control and decision-making.

[0083] It should be noted that the first dynamic evaluation sub-parameter may be considered from multiple dimensions, including but not limited to the time dimension, the behavior pattern dimension and the user history dimension. The time dimension involves the distribution of invitation behavior in a specific time period, such as the frequency of invitations during peak hours or non-peak hours. The behavior pattern dimension focuses on the regularity of user invitation behavior, such as whether there is a periodic or sudden invitation peak. The user history dimension is based on the user's past invitation behavior records and compares the difference between current behavior and historical behavior. This application does not limit this. The second dynamic evaluation sub-parameter can be analyzed from the account attribute dimension, network association dimension and behavior consistency dimension. The account attribute dimension includes the similarity of account registration information, device information, etc. The network association dimension involves the strength of social network connections between accounts or jointly participated activities. The behavior consistency dimension focuses on whether the behavior pattern of the invited account is similar to the behavior pattern of the inviting account. This application does not limit this. The weighting method can be flexibly adjusted according to actual business needs and data analysis results. Possible weighting dimensions include the risk priority dimension, which determines the risk weights of different sub-parameters based on business security requirements; the data reliability dimension, which assigns different weights based on the accuracy and stability of the data; and the business impact dimension, which assigns weights based on the size of the sub-parameters' impact on the business. In addition, the weights can be dynamically adjusted based on real-time feedback and historical performance. This application does not limit this.

[0084] As an optional solution, target evaluation parameters of the account to be detected are generated based on static features and dynamic features, including:

[0085] The static features and dynamic features are input into the target abnormal account identification model to determine the target evaluation parameters of the account to be detected, wherein the target abnormal account identification model includes a first sub-model and a second sub-model, the first sub-model is used to determine the similarity between the static features and the sample static features, and the second sub-model is used to determine the similarity between the static features of the invited accounts corresponding to the invitation behavior.

[0086] Optionally, in an embodiment of the present application, the above-mentioned target abnormal account identification model refers to a comprehensive analysis model that evaluates whether an account is abnormal by combining static features and dynamic features. The model includes two sub-models, namely a first sub-model and a second sub-model. The first sub-model is used to determine the similarity between static features and sample static features, which involves a comparative analysis of static data such as basic information, device information, and geographic location of the account. For example, the abnormal risk of the account can be assessed by comparing static features such as the registered email suffix, device model, and IP address of the account with the features of known normal account samples. The second sub-model is used to determine the similarity between the static features of the invited accounts corresponding to the invitation behavior, which involves analyzing the similarity between the invited accounts, such as the proximity of registration time, consistency of geographic location, etc. For example, if multiple invited accounts come from the same IP address or have similar device fingerprints, this may indicate collaborative fraud.

[0087] Among them, the target abnormal account identification model can be constructed using the integrated learning method in machine learning, where the first sub-model may be based on the decision tree algorithm, and the static features of the account are analyzed by constructing multiple decision trees, and each decision tree learns how to identify abnormal accounts from static features. The second sub-model may use a clustering algorithm, such as K-means or hierarchical clustering, to analyze the similarity of the static features of the invited accounts, cluster accounts with similar features together, and thus identify possible abnormal account groups. The outputs of these two sub-models can be integrated into a comprehensive scoring system, which, based on the scoring results of the two sub-models, ultimately determines the target evaluation parameters of the account to be detected through a weighted or voting mechanism to identify abnormal accounts. This model structure can comprehensively evaluate the abnormal risk of an account from multiple dimensions and improve the accuracy and efficiency of identification.

[0088] It should be noted that in the process of inputting static features and dynamic features into the target abnormal account identification model, there may be various situations, which can be listed and expanded from the three dimensions of data source, feature processing and model training. The data source dimension involves the collection method of static features and dynamic features. For example, static features may come from the user's registration information, device information and geographic location information, while dynamic features may come from the user's behavior log, transaction record and network activity. The feature processing dimension focuses on how to extract useful information from the raw data, including steps such as data cleaning, feature selection and feature conversion. For example, the noise in the device information can be removed by regularization processing, or the feature dimension can be reduced by principal component analysis (PCA). The model training dimension involves how to use these features to train the model, including selecting appropriate algorithms, setting hyperparameters and evaluating model performance. For example, the random forest algorithm can be used to train the first sub-model to determine the similarity between static features and sample static features, and the neural network can be used to train the second sub-model to identify the similarity between the static features of invited accounts. This application is not limited to this.

[0089] When determining the target evaluation parameters of the account to be detected, the construction and application of the target abnormal account identification model can also be diversified and expanded from three dimensions: model fusion, anomaly detection algorithm, and application scenario. The model fusion dimension explores how to effectively combine the outputs of the first sub-model and the second sub-model. For example, the prediction results of the two sub-models can be fused through weighted averaging, voting mechanisms, or stacked generalization. The anomaly detection algorithm dimension focuses on selecting and optimizing algorithms for identifying abnormal accounts. For example, an isolation forest algorithm can be used to identify abnormal behavior, or an autoencoder can be used to identify abnormal patterns. The application scenario dimension involves the application of the model in different business contexts, for example, in the financial field to identify fraudulent accounts, in the e-commerce field to identify false comment accounts, or in social networks to identify zombie fan accounts. This application is not limited to this.

[0090] As an optional solution, when the target evaluation parameter meets the preset threshold condition, the account to be detected is determined as an abnormal account, including:

[0091] When the target evaluation parameter satisfies the first threshold condition, the account to be detected is determined as an abnormal account, and the abnormal level of the abnormal account is determined to be a first level, wherein the first level corresponds to the first response mode, and the preset threshold condition includes the first threshold condition;

[0092] When the target evaluation parameters meet the second threshold condition, the account to be detected is determined as an abnormal account, and the abnormal level of the abnormal account is determined as a second level, wherein the second level is higher than the first level, the second level corresponds to a second response method, the second response method is different from the first response method, and the preset threshold condition includes the second threshold condition.

[0093] Optionally, in an embodiment of the present application, the above-mentioned first threshold condition refers to a preset standard or limit for evaluating whether the target evaluation parameter of the account to be detected has reached the level considered as an abnormal account. This condition can be set based on the behavior pattern, historical data and business rules of the account, including but not limited to the activity of the account, the transaction frequency and the degree of deviation from normal behavior. For example, if the number of transactions of an account in a short period of time exceeds a certain percentage of the average number of transactions of normal users, or its behavior pattern is significantly different from that of most users, then the target evaluation parameter of this account may meet the first threshold condition. An account that meets the first threshold condition will be determined as an abnormal account, and the abnormal level is set to the first level, which corresponds to a specific response measure. The second threshold condition is another preset standard, which is more stringent than the first threshold condition and is used to identify accounts with higher risks or more abnormal behaviors. This condition may involve the intensity of abnormal behavior of the account, the scope of influence and the potential degree of harm. For example, if the abnormal behavior of an account is not only frequent but also involves large transactions, or its behavior has a negative impact on other users, then the target evaluation parameter of this account may meet the second threshold condition. The second level indicates that the account is more abnormal, so the corresponding response method will be more stringent, which may include limiting account functions, increasing review processes, or conducting in-depth investigations. The second response method is different from the first response method, which means that they take different measures and urgency when dealing with abnormal accounts. The preset threshold conditions include the second threshold condition to ensure that appropriate response measures can be taken according to different levels of abnormal behavior.

[0094] It should be noted that the setting of preset threshold conditions can be adjusted in a variety of ways according to different risk assessment models, business requirements and security policies. These conditions can be expanded from the risk assessment dimension, business impact dimension and response efficiency dimension. The risk assessment dimension involves how to set thresholds based on the behavior patterns and historical data of different accounts. For example, the first threshold condition and the second threshold condition can be set based on data such as the account's transaction volume, login frequency and user feedback. The business impact dimension focuses on the impact that abnormal accounts may have on the business, such as the impact that fraudulent behavior may have on financial transactions, or the impact of fake accounts on the reputation of e-commerce platforms, thereby setting corresponding threshold conditions. The response efficiency dimension considers how to respond quickly and effectively when the threshold conditions are met, such as setting an automated response process to improve the efficiency of handling abnormal accounts. This application does not limit this.

[0095] When determining the abnormal level of an abnormal account, various extensions can be made from the severity dimension, the impact scope dimension, and the urgency dimension. The severity dimension involves the severity of the abnormal behavior of the account, such as the amount of money involved in the account, the type of violation, etc., and the account is classified as the first level or the second level based on this. The impact scope dimension focuses on the impact of abnormal behavior on other users or systems, such as whether the abnormal account triggers a chain reaction or a group incident. The urgency dimension sets the level based on the urgency of the abnormal behavior. For example, some abnormal behaviors may require immediate action, while other behaviors can be handled later. Based on these dimensions, the settings of the first and second levels can be more refined to meet the needs of different situations. This application does not limit this.

[0096] The difference between the first response method and the second response method can be expanded in various ways from the dimensions of response measures, resource allocation, and long-term impact. The response measures dimension involves specific measures taken for abnormal accounts at different levels. For example, the first level may involve warnings and restrictions on some functions, while the second level may involve account freezing and legal actions. The resource allocation dimension focuses on how to allocate human and technical support resources according to the different levels of abnormalities to ensure effective response. The long-term impact dimension considers the long-term impact of response measures on users and businesses, such as maintaining user trust and business reputation. These dimensions help to design response strategies that adapt to different levels of abnormalities to achieve the best security management effect. This application does not limit this.

[0097] As an optional solution, static and dynamic features of the account to be detected are obtained, including: obtaining the account information, geographic information and device information of the account to be detected; extracting features of the account information, geographic information and device information of the account to be detected to determine static features; and obtaining dynamic features of the account to be detected in real time.

[0098] Optionally, in an embodiment of the present application, the account information of the above-mentioned account to be detected refers to the basic data provided by the user when registering or using the platform service, including but not limited to the user name, registered email address, mobile phone number, password setting, etc. This information is the starting point for identifying the user's identity and behavior pattern, and is crucial for subsequent behavior analysis and anomaly detection. For example, the email domain name in the account information may indicate the user's location, the prefix of the mobile phone number may indicate the user's registration place, and the complexity of the password setting may be related to the user's security awareness. Geographic information includes but is not limited to the user's IP address, GPS positioning data, Wi-Fi positioning information, etc. Through this information, the user's activity range, common login locations, etc. can be analyzed, and abnormal behaviors such as abnormal geographic location changes or impossible travel speeds can be identified. For example, if an account logs in at two locations far apart in a short period of time, this may indicate that the account is at risk of being stolen. Device information involves relevant data of the specific device used by the user, including but not limited to device model, operating system version, device ID, IP address, ROOT, etc. By extracting features from the device information, static features such as the unique identifier of the device, the security of the operating system, etc. can be determined, which help to identify and distinguish user behavior patterns. For example, if an account is logged in on multiple devices of different models, or the device operating system version is inconsistent with that of most users, this may indicate that there is an abnormality in the account.

[0099] Optionally, in an embodiment of the present application, the above-mentioned real-time acquisition of dynamic features of the account to be detected refers to the real-time collection and analysis of user behavior data, including but not limited to login behavior, transaction behavior, browsing habits, etc., during the user's use of platform services. The acquisition of dynamic features can reveal real-time changes in user behavior, which is crucial for timely detection and response to abnormal behavior. For example, if an account suddenly has frequent login attempts or large transactions, these dynamic features may indicate that the account is being attacked or abused. By real-time monitoring and analysis of these dynamic features, abnormal behavior can be quickly identified and corresponding security measures can be taken.

[0100] It should be noted that when obtaining the account information, geographic information and device information of the account to be tested, this information can be comprehensively considered from multiple dimensions, including but not limited to the timeliness of the data, the diversity of sources and the integrity of the information. The timeliness dimension of the data involves the latest status of the information, such as the last login time of the account, the last use time of the device, etc. The source diversity dimension focuses on the information collection channels, which may include the user's active submission, the platform's automatic recording and third-party data provision. The information integrity dimension ensures that the collected information can fully cover the user's account, geographic and device characteristics, such as the account registration information, the geographic IP address and the device model. This application does not limit this.

[0101] Among them, when extracting features from the account information, geographic information, and device information of the detected account and determining static features, it can be expanded from three dimensions: feature correlation, stability, and discrimination. The correlation dimension explores the correlation between features and user behavior patterns, such as the correlation between the registered email suffix of an account and the user group. The stability dimension focuses on the degree of change of features over time, such as the hardware configuration of a device is usually relatively stable. The discrimination dimension measures the effectiveness of features in distinguishing different users or accounts, such as the importance of geographic location information in identifying malicious behavior. Through feature extraction in these dimensions, a static feature portrait of a user can be constructed more accurately. This application does not limit this.

[0102] In addition, when obtaining the dynamic characteristics of the account to be detected in real time, it can be considered from three dimensions: real-time, diversity, and predictability of behavior. The real-time dimension emphasizes the ability to monitor user behavior in real time, such as real-time tracking of user transaction behavior and login attempts. The diversity dimension involves the breadth of user behavior types, including login behavior, transaction behavior, browsing habits and other behavioral patterns. The predictive dimension focuses on the ability to predict future user behavior based on historical and real-time behavioral data, such as predicting possible abnormal transactions of users. The acquisition of real-time dynamic features in these dimensions helps to identify and respond to potential security threats in a timely manner. This application is not limited to this.

[0103] The following is a further explanation of this application with reference to specific examples:

[0104] In recent years, the Internet has developed rapidly at home and abroad. In order to attract users, major platforms have launched a series of activities targeting new users. Among them, users can get rewards by inviting new users to participate in activities. At present, many Internet platforms and online service providers are facing the problem of malicious users taking advantage of new users' behavior when inviting new users to participate in activities. However, the parameter values ​​corresponding to user identities are too single, making it difficult to identify malicious behavior. This phenomenon is common in current promotion activities, which not only increases invalid expenditures, but also seriously affects the promotion effect.

[0105] This application uses the user's static features and dynamic behavior data to effectively identify users who attempt to maliciously simulate newcomer behavior and prevent them from obtaining improper rewards or discounts. This abnormal invitation behavior identification method and system based on static features and dynamic behavior can effectively reduce invalid expenditures, reduce the risk of malicious users abusing activities, improve the identification effect of activities, increase user participation, and maintain a fair and just activity environment. By applying this method and system, Internet platforms can better protect user rights, enhance brand image, and achieve better operational results. In terms of application background, it is applicable to various Internet platforms, including e-commerce, social media, sharing economy, online education and other fields.

[0106] Figure 3 is a system diagram of an optional method for determining an abnormal account according to an embodiment of the present application, such as Figure 3 As shown, including:

[0107] Indicator collection module: The indicator collection module is used to collect static features of registered users and dynamic new user invitation behaviors, and the two are combined as the data source for scoring.

[0108] Dynamic scoring module: Input the collected data and dynamically calculate the score of each new user's registration behavior based on the anomaly detection algorithm.

[0109] Rule engine module: Set alarm rules based on the user's score and frequency of occurrence, and trigger an alarm when the rules are met.

[0110] Security response and disposal module: After the platform triggers an alarm, the subsequent disposal logic is triggered, such as active interception, notification of operators, etc. The alarm is marked with authenticity results and fed back to the indicator collection module to improve the accuracy of subsequent scoring.

[0111] Figure 4 is a schematic diagram of an optional method for determining an abnormal account according to an embodiment of the present application, such as Figure 4 As shown, including:

[0112] S402, static feature extraction: First, it is necessary to extract the static features of each account. These features will be used as the input of the model to detect abnormal behavior. The static features that can be collected include but are not limited to:

[0113] Account information: information submitted by the user when registering, such as email address or mobile phone number.

[0114] Email / mobile phone number: Users can be forced to provide their email address or mobile phone number when registering. This information is important credentials that uniquely identify the user.

[0115] Uniqueness verification: Use regular expressions to verify the format and use third-party services (such as SMS or email verification APIs) to ensure the authenticity of the email address or mobile phone number.

[0116] Encryption and privacy protection: To protect user privacy, email addresses and mobile phone numbers should be encrypted and stored using a hash algorithm (such as SHA-256 or bcrypt) to ensure that the information cannot be easily cracked in the event of a data leak.

[0117] Device fingerprint: Uses static information such as the device's hardware features, terminal number, IP address, device model, version number, ROOT, etc. This information is often fixed on the same device.

[0118] Hardware characteristics: including CPU model, memory size, storage space, etc. This information can be obtained through native APIs (such as Android's "Build" class or iOS's "UIDevice").

[0119] Terminal ID: For example, Android ID or Identifier for Vendor (IDFV) of iOS. These IDs can uniquely identify the device.

[0120] IP address: The user's external IP address can be obtained through the header information in the HTTP request. The GeoIP database can also be used to obtain the user's approximate geographic location from the IP address.

[0121] Device model and version number: Get the model of the current device and the operating system version (such as iOS15 or Android 12) through the system API.

[0122] ROOT: You can check the existence of system directories (such as " / Applications / Cydia.app"), or check whether iOS allows access to unauthorized system files. Detect ROOT (Android): You can check whether there is superuser privileges (via the "SU" command), or check whether there are common ROOT files in the system (such as the "su" file).

[0123] Geographic information: The user's geographic location information when registering.

[0124] IP geolocation: Use GeoIP services (such as MaxMind GeoIP2 or IP2Location) to obtain the approximate geographical location of the user at the time of registration based on their IP address. Geographic information usually includes city, longitude and latitude, etc.

[0125] GPS positioning: If the user allows the application to access their location information, accurate geographic location information can be obtained through the phone's GPS sensor, which is particularly suitable for application scenarios on mobile devices.

[0126] WiFi positioning: By obtaining the WiFi network information to which the user is connected, WiFi positioning technology can be used to infer the user's approximate location, especially in indoor environments.

[0127] Through the detailed collection and analysis of these static features, the input quality of the model can be significantly improved, providing accurate and comprehensive basic data for subsequent abnormal behavior detection.

[0128] S404, counting new user invitation behaviors and analyzing the invitation behaviors of each user in real time, including but not limited to:

[0129] Total number of invitations: the total number of times a user invites new users. To achieve this feature, a record of each user's invitation behavior is maintained in a database (which may include MySQL, ElasticSearch but is not limited to the above databases. This case uses MySQL as an example) and the total number of invitations is recorded. After each invitation behavior is generated, the record is saved and the count is updated.

[0130] Invitation frequency: Analyze the number of times a user invites new users within a specific time window (e.g., 1 hour or 1 day). To achieve this feature, multiple time windows are set (in this case, 1 hour and 1 day are set as time windows as examples), and the frequency of user behavior within a fixed time is analyzed by using sliding window technology (such as Flink or Spark Streaming). For example, after a user generates a new invitation behavior, the number of new invitations in the past hour / day is calculated and updated through a sliding window, and recorded in the database at the same time.

[0131] New user association: the similarity between the invited new users. Based on the static characteristics of the invited account, the similarity between the invited account and the users previously invited by the inviter is calculated through an anomaly detection algorithm. (Here, the same anomaly detection algorithm as step S406 is used to calculate the new user association separately as one of the dynamic indicators of the new user invitation behavior. The anomaly detection algorithm will be described in detail in step S402). Similarly, the calculation result is also maintained through the database.

[0132] S406, anomaly detection algorithm calculates score: assign a dynamic score to each user's behavior and monitor its changes in real time. The score is based on the following factors:

[0133] Static feature anomaly score: Based on the static features of the account, calculate its similarity with all registered users. If the score is too high, it may be an abnormal account.

[0134] Invitation behavior abnormality score: Based on the number and frequency of invitations and the relevance of new users, the user's behavior is calculated to determine whether it is abnormal. If any of these three factors is too high, the score will increase accordingly.

[0135] Based on the above factors, an anomaly detection algorithm is used to build a model, and the static feature score and the behavior score are weighted and combined to obtain a comprehensive score. If the comprehensive score exceeds the set threshold, the user is marked as having abnormal behavior. Anomaly detection algorithms include half-space depth method, minimum ellipsoid estimation method, isolation forest algorithm, etc. When using the method of this case, the model can be constructed by using algorithms including but not limited to the above. This application takes the isolation forest algorithm as an example, as follows:

[0136] Isolation Forest: Use static features and invitation behavior data to build an isolation forest model. Isolation Forest is a tree-based anomaly detection algorithm that isolates normal sample points on a shorter path in the tree structure, while abnormal sample points require a longer path for isolation. By calculating the average path length of the sample point from the root node, its degree of abnormality can be determined. In this way, abnormal users can be detected. By applying the isolation forest algorithm, combined with static features and invitation behavior data, the accuracy of identifying abnormal users can be improved.

[0137] S408, establish an alarm rule engine: The alarm rule engine design includes a rule engine framework, and uses rule engines including Drools and Easy Rules but not limited to the above to define and manage alarm rules. The rule engine allows alarm rules to be defined in a declarative manner, making the addition, deletion or modification of rules more flexible. The rules can be configured to be dynamically adjusted based on factors such as user scores, event frequencies and time windows, supporting real-time or near real-time calculations. The alarm rule implementation includes rule definition and threshold setting. The rules are defined in a fixed format, such as: "score>=80and occurrence>=1", corresponding to severe alarms. The severity of the alarm is set according to the rules, and a hierarchical alarm mechanism is used to distinguish between minor alarms, general alarms, and severe alarms. Each alarm level corresponds to a different processing flow or response strategy. The alarm information of each user can be updated in real time and stored in a dedicated database or memory for subsequent query and analysis.

[0138] Real-time analysis and alarm triggering, including:

[0139] Sliding time window: Use sliding window technology (including Flink or Spark Streaming but not limited to the above technologies, this application can but is not limited to using Flink) to analyze the frequency of user behavior within a fixed time. For example, behaviors that occur within 10 minutes can be counted using a sliding window and matched with alarm rules. When user behavior meets a certain rule, the alarm engine will immediately trigger the corresponding alarm.

[0140] Asynchronous processing and event-driven: With an event-driven architecture, each user's operation behavior will be sent as an event to the event stream processing system (such as Apache Kafka, RabbitMQ). The event processor is responsible for calculating the user's score, operation frequency, and checking whether the alarm conditions are met. When the alarm conditions are met, the alarm information is sent to the early warning system (such as SMS, email notification or integration into the monitoring system) through the asynchronous message push mechanism.

[0141] Alarm optimization and adjustment, including:

[0142] Adaptive rule adjustment: Combined with the above methods, the accuracy of alarms is continuously optimized to reduce false positives and missed positives. Safe list mechanism: For normal users or verified safe users, safe list policies can be set to avoid frequent alarm interference. Even if the behavior of such users triggers certain alarm rules, the alarm can be automatically ignored.

[0143] Alarm system integration and response, including:

[0144] Integrated monitoring platform: Integrate the alarm system with existing monitoring platforms (such as Prometheus, Grafana, ELK Stack) to facilitate real-time viewing of alarm information and user behavior trends. Emergency responses can be automatically triggered based on the level of the alarm, such as temporarily blocking certain user accounts or sending alarm information to system administrators.

[0145] Visualized alarm information: Alarm trends are displayed through visualization tools (such as Grafana and Kibana), providing a real-time alarm dashboard to help operation and maintenance personnel quickly understand the alarm situation and handle it.

[0146] S410, Security Response and Disposal:

[0147] After the platform triggers an alarm, subsequent processing logic is triggered for different levels of alarms, for example:

[0148] Serious alarm: immediate interception and notification.

[0149] New user invitation behavior interception: Real-time blocking mechanism: When a serious alarm is triggered, the user's new user invitation function is immediately suspended. You can mark the user status as "frozen" or temporarily set the user's related operation permissions to unavailable in the database. Behavior blocking: Combined with the API gateway or service middleware layer to implement behavior interception to ensure that malicious users cannot continue any registration or invitation operations. Abnormal activity rollback: For suspicious new user invitation operations that have occurred, a transaction mechanism can be provided to roll back and cancel the impact of these operations, such as freezing the invited new user account or withdrawing bonus rewards.

[0150] Notification mechanism: Multi-channel notification: Instant messaging applications: Use the APIs of these platforms to push alarm information to specific work groups or individuals so that relevant personnel can take timely measures. SMS / email / phone reminders: Integrate third-party SMS and email services to automatically send emergency notifications, and phone reminders can use voice APIs to trigger voice phone notifications. Priority mechanism: For serious alarms, high-priority notification strategies can be set to ensure that information is delivered to relevant persons in charge first. For example, through emergency calls, text messages, etc., to improve response speed.

[0151] Platform reporting and recording: Event log system: All serious alarm information is stored in the log system (such as ELK Stack, Graylog), including the alarm time, user information, trigger conditions, disposal measures, etc., to facilitate subsequent audit and analysis. Alarm history database: Establish an alarm history record table in the database to store detailed information on each serious alarm, which is convenient for subsequent query, statistics and tracking.

[0152] General alarm: notification and reporting.

[0153] Notification mechanism: Similar notification channels as critical alerts: Use instant messaging applications, SMS, email, etc. to notify the relevant security team or operation team, but the priority can be set lower than that of critical alerts. For example, SMS or phone notifications can be determined based on the situation. Multi-role notification: The notification scope of general alerts can be expanded to multiple roles, including system administrators, security teams, product operation teams, etc., to ensure that relevant parties are aware and follow up.

[0154] Automated response: Review task assignment: When receiving general alerts, automatically create pending tasks and assign them to the security or operations team for manual review. For example, through integration with Jira, Trello, or internal ticket systems, task tickets can be automatically generated and assigned to relevant personnel. Platform feedback and review: Feedback alert information to the management platform for managers to manually check whether further processing is necessary. For eligible accounts, they can be marked or frozen through the review tools provided by the platform.

[0155] Reporting platform: Real-time alarm display: Provide an alarm dashboard in the management background to display general alarm information for system administrators to view and operate. This information can be integrated into the existing operation and maintenance platform, such as Prometheus, Grafana or ELK Stack to achieve real-time visualization of alarm data. Alarm summary and analysis: Generate alarm reports regularly, summarize the frequency, distribution, users involved and other information of general alarms, and provide data analysis tools to assist decision-making.

[0156] Minor alarm: record and report.

[0157] Alarm recording and storage: Minor alarms can be recorded directly in the system log without triggering real-time notifications or behavior interception. Centralized recording through a log system (such as ELK or Splunk) facilitates subsequent analysis and query. Create a dedicated table or field for minor alarms in the database to record the information of each minor alarm, so as to facilitate subsequent big data analysis, abnormal behavior pattern mining, etc.

[0158] Platform reporting and monitoring: Minor alarms can be displayed in the background management system, but can be set to low priority. For example, they can be displayed in the alarm dashboard, but no specific operation tasks are issued to the operation or security team. Minor alarms can be summarized through big data analysis tools to find potential trends. For example, if the frequency of minor alarms increases abnormally, it may be necessary to upgrade to general alarms or severe alarms and adjust the corresponding rules.

[0159] Continuous monitoring and feedback optimization: The authenticity of the reported data can be manually marked, and the confirmed behavior can be used as feedback and as part of the scoring indicators to help further improve the accuracy of subsequent scoring results.

[0160] S412, Model and rule iteration and optimization: Iterate and optimize the model and rules by continuously collecting new data and actual detection results. Add new features, adjust thresholds, and enhance the sensitivity and accuracy of detection.

[0161] This application pays more attention to collecting more static indicators, including the hardware characteristics of the device, terminal number, IP address, device model, version number, whether it is jailbroken / ROOT, and GPS information. These static indicators can provide more information about the user's device and environment, which helps to improve the accuracy of identifying abnormal behavior. On the basis of the static indicators that have been combined, further consideration is given to collecting dynamic invitation behaviors. Use an anomaly detection algorithm to perform weighted calculations on static indicators and dynamic invitation behaviors to generate a comprehensive score. According to the score and frequency of occurrence, abnormal behaviors can be graded and alarmed. Depending on the alarm level, take appropriate measures to deal with it, and further track and verify users with abnormal behavior. For the reported alarm, mark it for authenticity, and feed back relevant information to the model to recalculate the score. Through the analysis of the results, the model and rules can be further optimized and iterated to continuously improve the accuracy and reliability of the model.

[0162] It is understandable that in the specific implementation of this application, related data such as user information is involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of relevant data need to comply with relevant laws, regulations and standards of relevant countries and regions.

[0163] It should be noted that, for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the described order of actions, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present application.

[0164] According to another aspect of the embodiment of the present application, there is also provided an abnormal account determination device for implementing the above abnormal account determination method. Figure 5 As shown, the device comprises:

[0165] The acquisition module 502 is used to acquire static features and dynamic features of the account to be detected, wherein the static features are used to represent the account information generated during the registration process of the account to be detected, and the dynamic features are used to represent the invitation behavior of the account to be detected, and the invitation behavior represents the behavior of the account to be detected inviting new users to register;

[0166] A generating module 504, used to generate target evaluation parameters of the account to be detected based on static features and dynamic features;

[0167] The determination module 506 is used to determine the account to be detected as an abnormal account when the target evaluation parameter meets the preset threshold condition.

[0168] As an optional solution, the above-mentioned device is used to generate target evaluation parameters of the account to be detected based on static features and dynamic features in the following manner: determine the first evaluation parameter of the account to be detected based on the static features and sample static features of registered accounts; determine the second evaluation parameter of the account to be detected based on the frequency and number of occurrences of the invitation behavior in the dynamic features; and perform a weighted combination of the first evaluation parameter and the second evaluation parameter to determine the target evaluation parameter.

[0169] As an optional solution, the above-mentioned device is used to determine the second evaluation parameter of the account to be detected based on the frequency and number of occurrences of the invitation behavior in the dynamic characteristics in the following manner: the frequency and number of occurrences are determined by a preset method, wherein the preset method includes at least one of the following: sliding time window driven, event driven; determining the frequency evaluation parameter based on the frequency and the preset frequency threshold; determining the number of occurrence evaluation parameter based on the number of occurrences and the preset number threshold; determining the second evaluation parameter based on the frequency evaluation parameter and the number of occurrence evaluation parameter.

[0170] As an optional solution, the above-mentioned device is used to determine the second evaluation parameter of the account to be detected based on the frequency and number of occurrences of the invitation behavior in the dynamic characteristics in the following manner: determine the first dynamic evaluation sub-parameter of the account to be detected based on the frequency and number of occurrences of the invitation behavior in the dynamic characteristics; determine the second dynamic evaluation sub-parameter based on the similarity between the static characteristics of the invited accounts corresponding to the invitation behavior; and perform weighted combination of the first dynamic evaluation sub-parameter and the second dynamic evaluation sub-parameter to determine the second evaluation parameter.

[0171] As an optional solution, the above-mentioned device is used to generate target evaluation parameters of the account to be detected based on static features and dynamic features in the following manner: input the static features and dynamic features into a target abnormal account recognition model to determine the target evaluation parameters of the account to be detected, wherein the target abnormal account recognition model includes a first sub-model and a second sub-model, the first sub-model is used to determine the similarity between the static features and the sample static features, and the second sub-model is used to determine the similarity between the invited account static features of the invited accounts corresponding to the invitation behavior.

[0172] As an optional solution, the above-mentioned device is used to determine the account to be detected as an abnormal account in the following manner when the target evaluation parameters meet the preset threshold conditions: when the target evaluation parameters meet the first threshold conditions, the account to be detected is determined as an abnormal account, and the abnormal level of the abnormal account is determined to be a first level, wherein the first level corresponds to the first response method, and the preset threshold conditions include the first threshold conditions; when the target evaluation parameters meet the second threshold conditions, the account to be detected is determined as an abnormal account, and the abnormal level of the abnormal account is determined to be a second level, wherein the second level is higher than the first level, the second level corresponds to the second response method, the second response method is different from the first response method, and the preset threshold conditions include the second threshold conditions.

[0173] As an optional solution, the above-mentioned device is used to obtain the static and dynamic features of the account to be detected in the following manner: obtaining the account information, geographic information and device information of the account to be detected; performing feature extraction on the account information, geographic information and device information of the account to be detected to determine the static features; and obtaining the dynamic features of the account to be detected in real time.

[0174] In the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program with a predetermined function, and works together with other related parts to achieve a predetermined goal, and can be implemented in whole or in part by using software, hardware (such as processing circuits or memories) or a combination thereof. Similarly, a processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be part of an overall module or unit that includes the function of the module or unit.

[0175] Regarding the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0176] According to one aspect of the present application, a computer program product is provided. The computer program product includes a computer program.

[0177] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0178] Figure 6 The structure block diagram of a computer system for implementing an electronic device according to an embodiment of the present application is schematically shown.

[0179] It should be noted that Figure 6 The computer system 600 of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0180] like Figure 6 As shown, the computer system 600 includes a central processing unit 601 (CPU), which can perform various appropriate actions and processes according to the program stored in the read-only memory 602 (ROM) or the program loaded from the storage part 608 to the random access memory 603 (RAM). Various programs and data required for system operation are also stored in the random access memory 603. The central processing unit 601, the read-only memory 602 and the random access memory 603 are connected to each other through a bus 604. An input / output interface 605 (Input / Output interface, i.e., I / O interface) is also connected to the bus 604.

[0181] The following components are connected to the input / output interface 605: an input section 606 including a keyboard, a mouse, etc.; an output section 607 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a local area network card, a modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the input / output interface 605 as needed. A removable medium 611, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 610 as needed so that a computer program read therefrom is installed into the storage section 608 as needed.

[0182] In particular, according to an embodiment of the present application, the process described in each method flow chart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer readable medium, and the computer program contains a program code for executing the method shown in the flow chart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 609, and / or installed from the removable medium 611. When the computer program is executed by the central processor 601, various functions defined in the system of the present application are executed.

[0183] In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 609, and / or installed from the removable medium 611. When the computer program is executed by the central processor 601, various functions provided by the embodiment of the present application are performed.

[0184] According to another aspect of the embodiment of the present application, an electronic device for implementing the above-mentioned method for determining an abnormal account is also provided. The electronic device may be Figure 1 The terminal device or server shown in the figure. This embodiment is described by taking the electronic device as a terminal device as an example. Figure 7 As shown, the electronic device includes a memory 702 and a processor 704. The memory 702 stores a computer program, and the processor 704 is configured to execute the steps in any of the above method embodiments through the computer program.

[0185] Optionally, in this embodiment, the electronic device may be located in at least one network device among a plurality of network devices of a computer network.

[0186] Optionally, in this embodiment, the above-mentioned processor can be configured to execute the methods in each embodiment of the present application through a computer program.

[0187] Alternatively, a person skilled in the art may understand that: Figure 7 The structure shown is for illustration only. Figure 7 The structure of the electronic device is not limited. Figure 7 More or fewer components (such as network interfaces, etc.) as shown in, or with Figure 7 Different configurations shown.

[0188] Among them, the memory 702 can be used to store software programs and modules, such as the program instructions / modules corresponding to the method and device for determining abnormal accounts in the embodiments of the present application. The processor 704 executes various functional applications and data processing by running the software programs and modules stored in the memory 702, that is, implementing the above-mentioned method for determining abnormal accounts. The memory 702 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 702 may further include a memory remotely located relative to the processor 704, and these remote memories may be connected to the terminal via a network. Examples of the above-mentioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. Among them, the memory 702 can be specifically, but not limited to, used to store information such as account data. As an example, such as Figure 7 As shown, the memory 702 may include but is not limited to the acquisition module 502, the generation module 504 and the determination module 506 in the abnormal account determination device. In addition, it may also include but is not limited to other module units in the abnormal account determination device, which will not be repeated in this example.

[0189] Optionally, the transmission device 706 is used to receive or send data via a network. Specific examples of the network may include a wired network and a wireless network. In one example, the transmission device 706 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices and routers via a network cable so as to communicate with the Internet or a local area network. In one example, the transmission device 706 is a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0190] In addition, the electronic device further includes: a display 708 for displaying account information of the abnormal account, etc.; and a connection bus 710 for connecting various module components in the electronic device.

[0191] In other embodiments, the terminal device or server may be a node in a distributed system, wherein the distributed system may be a blockchain system, and the blockchain system may be a distributed system formed by connecting the multiple nodes through network communication. The nodes may form a peer-to-peer network, and any form of computing device, such as a server, terminal or other electronic device, may become a node in the blockchain system by joining the peer-to-peer network.

[0192] According to one aspect of the present application, a computer-readable storage medium is provided, and a processor of an electronic device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the electronic device executes the method for determining an abnormal account provided in various optional implementations of the above-mentioned abnormal account determination.

[0193] Optionally, in this embodiment, the above-mentioned computer-readable storage medium can be configured to store data for executing the methods in various embodiments of the present application.

[0194] Optionally, in this embodiment, a person of ordinary skill in the art may understand that all or part of the steps in the various methods of the above embodiments may be completed by instructing hardware related to the terminal device through a program, and the program may be stored in a computer-readable storage medium, and the storage medium may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a disk or an optical disk, etc.

[0195] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0196] If the integrated units in the above embodiments are implemented in the form of software functional units and sold or used as independent products, they can be stored in the above computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for one or more electronic devices to execute all or part of the steps of the methods described in each embodiment of the present application.

[0197] In the above embodiments of the present application, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0198] In the several embodiments provided in the present application, it should be understood that the disclosed application can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

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

[0200] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0201] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A method for determining an abnormal account, characterized in that: include: Obtain static features and dynamic features of the account to be detected, wherein the static features are used to represent the account information generated by the account to be detected during the registration process, and the dynamic features are used to represent the invitation behavior of the account to be detected, and the invitation behavior represents the behavior of the account to be detected inviting new users to register; Generate a target evaluation parameter of the account to be detected based on the static feature and the dynamic feature; When the target evaluation parameter meets a preset threshold condition, the account to be detected is determined as an abnormal account.

2. The method according to claim 1, characterized in that The generating the target evaluation parameter of the account to be detected based on the static feature and the dynamic feature includes: Determine a first evaluation parameter of the account to be detected based on the static feature and the sample static features of the registered account; Determining a second evaluation parameter of the account to be detected based on the frequency and number of occurrences of the invitation behavior in the dynamic feature; The first evaluation parameter and the second evaluation parameter are weightedly combined to determine a target evaluation parameter.

3. The method according to claim 2, characterized in that The determining of the second evaluation parameter of the account to be detected based on the frequency and number of occurrences of the invitation behavior in the dynamic feature includes: The occurrence frequency and the number of occurrences are determined by a preset method, wherein the preset method includes at least one of the following: sliding time window driven, event driven; Determining an occurrence frequency evaluation parameter based on the occurrence frequency and a preset frequency threshold; Determining an occurrence number evaluation parameter based on the occurrence number and a preset number threshold; The second evaluation parameter is determined based on the occurrence frequency evaluation parameter and the occurrence number evaluation parameter.

4. The method according to claim 2, characterized in that: The determining of the second evaluation parameter of the account to be detected based on the frequency and number of occurrences of the invitation behavior in the dynamic feature includes: Determine a first dynamic evaluation sub-parameter of the account to be detected based on the frequency and number of occurrences of the invitation behavior in the dynamic feature; Determining a second dynamic evaluation sub-parameter based on the similarity between the static features of the invited accounts corresponding to the invitation behavior; The first dynamic evaluation sub-parameter and the second dynamic evaluation sub-parameter are weightedly combined to determine the second evaluation parameter.

5. The method according to claim 2, characterized in that: The generating the target evaluation parameter of the account to be detected based on the static feature and the dynamic feature includes: The static features and the dynamic features are input into a target abnormal account identification model to determine target evaluation parameters of the account to be detected, wherein the target abnormal account identification model includes a first sub-model and a second sub-model, the first sub-model is used to determine the similarity between the static features and the sample static features, and the second sub-model is used to determine the similarity between the invited account static features of the invited account corresponding to the invitation behavior.

6. The method according to claim 1, characterized in that When the target evaluation parameter satisfies a preset threshold condition, determining the account to be detected as an abnormal account includes: In the case where the target evaluation parameter satisfies a first threshold condition, the account to be detected is determined as the abnormal account, and the abnormal level of the abnormal account is determined to be a first level, wherein the first level corresponds to a first response mode, and the preset threshold condition includes the first threshold condition; When the target evaluation parameter satisfies the second threshold condition, the account to be detected is determined as the abnormal account, and the abnormal level of the abnormal account is determined as the second level, wherein the second level is higher than the first level, the second level corresponds to a second response method, the second response method is different from the first response method, and the preset threshold condition includes the second threshold condition.

7. The method according to claim 1, characterized in that The step of obtaining the static features and dynamic features of the account to be detected includes: Obtaining account information, geographic information, and device information of the account to be detected; Extracting features from the account information, the geographic information, and the device information of the account to be detected to determine the static features; The dynamic features of the account to be detected are obtained in real time.

8. A device for determining an abnormal account, characterized in that: include: An acquisition module, used to acquire static features and dynamic features of the account to be detected, wherein the static features are used to represent the account information generated by the account to be detected during the registration process, and the dynamic features are used to represent the invitation behavior of the account to be detected, and the invitation behavior represents the behavior of the account to be detected inviting new users to register; A generating module, used for generating target evaluation parameters of the account to be detected based on the static features and the dynamic features; The determination module is used to determine the account to be detected as an abnormal account when the target evaluation parameter meets a preset threshold condition.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes a stored program, wherein the program is executed by a processor to perform the method described in any one of claims 1 to 7.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the method described in any one of claims 1 to 7 are implemented.

11. An electronic device comprising a memory and a processor, characterized in that: A computer program is stored in the memory, and the processor is configured to execute the method according to any one of claims 1 to 7 through the computer program.

Images