Bad debt risk detection method and apparatus, electronic device, and storage medium

Abstract

Embodiments of the present application provide a risk detection method and device, electronic equipment and storage medium, and relate to the technical field of CDN content distribution. The risk detection method comprises: obtaining user data of a content distribution network (CDN) charging user, wherein the user data comprises CDN usage data; predicting potential risks of the CDN charging user according to the user data of the CDN charging user, and screening potential risk users from the CDN charging user; and performing a preliminary estimation on consumption of the potential risk users in the CDN system according to the CDN usage data of the potential risk users, to obtain a risk detection result of the potential risk users. The embodiments of the present application solve the problem that the risk detection in the prior art relies on manual implementation, resulting in poor timeliness.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of CDN content distribution, in particular, the present application relates to a bad debt risk detection method and device, electronic equipment and storage medium. BACKGROUND

[0002] The full name of CDN is Content Delivery Network, that is, content distribution network. Its basic idea is to avoid as much as possible the bottlenecks and links on the Internet that may affect data transmission speed and stability, so that data transmission is faster and more stable.

[0003] However, although CDN greatly facilitates enterprise users and individual users, it also faces a series of challenges, including CDN billing problems. CDN billing problems include the characteristics of the billing period and billing rules of users using CDN systems, malicious use of network resources such as traffic and bandwidth, and subjective malicious arrears or refusal to pay when the due date is deducted, resulting in the enterprise cannot receive the fees, causing the enterprise to suffer income losses.

[0004] At present, the means to find CDN billing problems mainly rely on manual judgment after CDN billing, resulting in poor processing timeliness, often causing irreparable losses. Therefore, how to improve the processing timeliness of risk detection needs to be solved urgently. SUMMARY

[0005] The embodiments of the present application provide a bad debt risk detection method and device, electronic equipment and storage medium, which can solve the problem of bad debt risk detection relying on manual implementation in related technologies, resulting in poor processing timeliness. The technical solution is as follows:

[0006] According to an aspect of an embodiment of the present application, a bad debt risk detection method comprises: obtaining user data of a content distribution network (CDN) billing user, the user data comprising CDN usage data; predicting potential risks of the CDN billing user according to the user data of the CDN billing user, and screening potential risk users from the CDN billing users; and performing a preliminary estimation on the consumption of the potential risk users in the CDN system according to the CDN usage data of the potential risk users, to obtain a bad debt risk detection result of the potential risk users.

[0007] According to an aspect of the embodiments of the present application, a bad account risk detection device comprises: a data acquisition module configured to acquire user data of a content distribution network (CDN) charging user, the user data comprising CDN usage data; a user screening module configured to predict potential risks of the CDN charging user according to the user data of the CDN charging user, and screen potential risk users from the CDN charging user; and a consumption estimation module configured to perform a pre-estimation process on consumption of the potential risk users in a CDN system according to the CDN usage data of the potential risk users, and obtain a bad account risk detection result of the potential risk users.

[0008] According to an aspect of the embodiments of the present application, an electronic device comprises at least one processor, at least one memory, and at least one communication bus, wherein the memory stores computer readable instructions, and the processor reads the computer readable instructions in the memory through the communication bus; and the computer readable instructions are executed by the processor to implement the bad account risk detection method.

[0009] According to an aspect of the embodiments of the present application, a storage medium stores a computer program, and the computer program is executed by a processor to implement the bad account risk detection method.

[0010] The technical scheme provided by the present application has the following beneficial effects:

[0011] In the above technical scheme, the potential risks of the CDN charging user are predicted through the user data of the CDN charging user, the potential risk users are screened from the mass of CDN charging users, the consumption of the potential risk users in the CDN system is pre-estimated according to the CDN usage data of the potential risk users, and the bad account risk detection result of whether the potential risk users are high-risk users is obtained. Thus, before the CDN charging is completed, the bad account risk is actively detected based on user mining and consumption pre-estimation, and the dependence on manual implementation is avoided, thereby solving the problem of poor processing timeliness of the bad account risk detection in the prior art. BRIEF DESCRIPTION OF DRAWINGS

[0012] In order to more clearly illustrate the technical schemes in the embodiments of the present application, the drawings needed in the description of the embodiments of the present application will be briefly introduced.

[0013] Figure 1 is a schematic diagram according to the implementation environment involved in the present application.

[0014] Figure 2 is a flowchart of a bad account risk detection method according to an exemplary embodiment.

[0015] Figure 3 isFigure 2 Step 201 in the corresponding embodiment is shown in a flowchart of one embodiment.

[0016] Figure 4 Figure 3 Step 2011 in the corresponding embodiment is shown in a flowchart of one embodiment.

[0017] Figure 5 Figure 2 Step 205 in the corresponding embodiment is shown in a flowchart of one embodiment.

[0018] Figure 6

[0019] Figure 7

[0020] Figure 8

[0021] Figure 9

[0022] Figure 10

[0023] Figure 11 DETAILED DESCRIPTION

[0024] Embodiments of the present application are described in detail below with reference to the attached drawing figures, wherein the same or like reference numerals are used throughout the figures to refer to same or like elements or elements having same or similar function. The embodiments described below are merely exemplary for the purposes of explanation and are not to be construed as limiting the application.

[0025] ​​​​​​​​Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this application means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. It should be understood that when we say an element is “connected” or “coupled” to another element, it can be directly connected or coupled to the other element, or there may be intermediate elements. Furthermore, “connected” or “coupled” as used herein can include wireless connections or wireless coupling. The term “and / or” as used herein includes all or any units and all combinations of one or more associated listed items.

[0026] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0027] The following is an introduction and explanation of several terms used in this application:

[0028] CDN stands for Content Delivery Network. Its basic idea is to bypass bottlenecks and points of failure on the internet that could affect data transmission speed and stability, making data transmission faster and more stable. A CDN system is an intelligent virtual network built on top of the existing network infrastructure. It relies on edge servers (also called edge nodes) deployed in various locations, and through the load balancing, content distribution, and scheduling modules of a central platform (also called an intermediate source node), users can access the nearest edge node and obtain the content they need from it, reducing network congestion and improving user access response speed and hit rate. Key technologies of CDN include content distribution, content routing, content storage, and performance management.

[0029] CDN billing issues may include CDN billing bad debts or other CDN billing anomalies; CDN billing bad debts: users use CDN-related products and incur related fees, but when it is time to deduct the fees, they deliberately delay or refuse to pay, resulting in the company being unable to receive the fees and causing revenue loss to the company.

[0030] As mentioned earlier, the main method for detecting bad CDN billing accounts is manual judgment after CDN billing is issued.

[0031] Currently, the CDN system usually has the feature of daily billing, specifically, the network resources such as traffic and bandwidth used by the user in the CDN system today will generate the corresponding billing invoice the next day, which may cause the user to try various means to break through the daily billing feature of the CDN system before the CDN billing is out, in order to achieve the purpose of maliciously using network resources such as traffic and bandwidth, and subjectively maliciously default or refuse to pay after the CDN billing is out, thereby causing the income loss of the enterprise and forming the CDN billing bad debts.

[0032] For the operation and maintenance personnel of the CDN system, they usually intervene after the CDN billing is out, that is, manually check the CDN billing bad debts, and rely on past established experience to make judgments and take a series of remedial measures for such users. This results in poor timeliness of handling CDN billing bad debts, often causing irreparable bad debt losses.

[0033] Therefore, the bad debt risk detection method, device, electronic equipment and storage medium provided by the present application aim to solve the above technical problems of the prior art.

[0034] In order to make the purpose, technical scheme and advantages of the present application clearer, the embodiments of the present application will be described in further detail below with reference to the drawings.

[0035] Figure 1 A schematic diagram of an implementation environment involved in a bad debt risk detection method. The implementation environment includes a user terminal 100 held by a user, a server end 200, and a CDN system 300 providing content distribution services.

[0036] Specifically, the user terminal 100 can access each node in the CDN system 300, which can be a desktop computer, a notebook computer, a tablet computer, a smart phone, or other electronic devices, which are not limited here.

[0037] The server end 200 can be a standalone physical server, or a server cluster or distributed system composed of multiple physical servers. The physical server is an electronic device that provides background services, for example, the background services include but are not limited to bad debt risk detection services.

[0038] The CDN system 300 is a cloud server that provides content distribution services for users. Of course, the cloud server can also provide cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, and basic cloud computing services such as big data and artificial intelligence platforms, which are not specifically limited here.

[0039] The user terminal 100 and each node 310 (including intermediate source nodes and edge nodes) in the CDN system 300 pre-establish a communication connection, and data transmission between the user terminal 100 and each node 310 in the CDN system 300 is realized through the communication connection. For example, the transmitted data includes but is not limited to: a domain name requested by the user terminal 100 to access the intermediate source node in the CDN system 300, and web page content returned by a certain edge node in the CDN system 300 to the user terminal 100 according to the domain name.

[0040] Meanwhile, the server end 200 and each node 310 in the CDN system 300 also pre-establish a communication connection, and data transmission between the server end 200 and each node 310 in the CDN system 300 is realized through the communication connection. For example, the transmitted data includes but is not limited to: log data of users in the CDN system 300.

[0041] For the server end 200, after the potential risk user is obtained from the massive CDN charging users according to the user data of the CDN charging user, the CDN usage data of the potential risk user can be obtained through the data interaction between the server end 200 and each node 310 in the CDN system 300, and then the consumption of the potential risk user in the CDN system 300 is estimated according to the CDN usage data of the potential risk user, so as to obtain the bad account risk detection result of whether the potential risk user is a high-risk user, thereby realizing the active detection of the bad account risk and avoiding the dependence on manual implementation, thereby effectively solving the problem of poor processing timeliness of the bad account risk detection.

[0042] Please refer to Figure 2 The embodiment of the present application provides a bad account risk detection method, which is suitable for Figure 1 The server end 200 of the implementation environment shown.

[0043] The method can be executed by the server end, and can also be understood as being executed by an application program running in the server end. In the following method embodiment, in order to facilitate description, the execution subject of each step is taken as the server end, but this does not constitute a limitation.

[0044] As Figure 2 shown, the method can include the following steps:

[0045] Step 201, obtaining user data of a content distribution network (CDN) charging user.

[0046] Among them, the user data includes CDN usage data.

[0047] Step 203, predicting potential risk of the CDN charging user according to the user data of the CDN charging user, and screening potential risk users from the CDN charging users.

[0048] Firstly, the CDN charging user refers to a user who uses CDN related products in the CDN system, for example, a user who accesses an edge node in the CDN system and uses network resources such as traffic and bandwidth provided by the edge node, that is, the CDN charging user. Accordingly, the user data of the CDN charging user is used to accurately describe the user characteristics of the CDN charging user.

[0049] The user data of the CDN charging user includes but is not limited to user label data, user behavior data and CDN usage data of the CDN charging user. The user data of the CDN charging user is obtained from log data about the CDN charging user in the CDN system.

[0050] The user label data is used to uniquely represent the CDN charging user, and further includes user registration information, user login IP, charging mode used in the CDN system, historical CDN prepayment package data, historical CDN postpayment payment data, yellow-related / banned records, VIP privileges and the like. The user behavior data is used to accurately describe the user behavior of the CDN charging user in the CDN system, and further includes deleting domain names, replacing accelerated domain names, domain name resolution, multiple times of changing domain name ownership between multiple accounts, switching charging modes and the like in the CDN system. The CDN usage data is used to represent the network resource usage of the CDN charging user in the CDN system, for example, for the node accessed by the CDN charging user in the CDN system, the network resource usage can be represented as the traffic provided by the node, or as the bandwidth provided by the node, to reflect the degree of bad account loss that the CDN charging user may cause to the enterprise.

[0051] The acquisition process of the user data of the CDN charging user is described below.

[0052] For example, the CDN charging user uses the CDN system to access the edge node, and uses the network resources provided by the edge node. The CDN system records the user label data, user behavior data and CDN usage data of the CDN charging user, and the CDN system can obtain the user data of the CDN charging user through the log data. Figure 1The illustrated implementation environment is used for illustration by way of example. With the data interaction between the user terminal 100 held by the CDN billing user and each node in the CDN system 300, the node in the CDN system 300 receives the log data of the CDN billing user in the CDN system 300 reported by the user terminal 100. The log data of the CDN billing user in the CDN system 300 reflects the user label, user behavior, use of CDN related products, and the like of the CDN billing user in the CDN system 300. For example, the user behavior can be that the CDN billing user deletes a domain name in the CDN system; the user label can be the registration information of the CDN billing user in the CDN system; and the use of CDN related products can be the amount of network resources such as traffic and bandwidth provided by the CDN system used by the CDN billing user.

[0053] As described above, the user data of the CDN billing user at least includes user label data, user behavior data, and CDN usage data of the CDN billing user. For the server side, the user data of the CDN billing user can be obtained from the log data pulled from each node in the CDN system in real time, or from the log data pulled from each node in the CDN system in a historical time period stored in the memory of the server side. The present embodiment does not limit this.

[0054] In other words, the server side can perform bad account risk detection based on the user data obtained in real time in real time to further improve the processing timeliness of bad account risk detection, or perform bad account risk detection based on the user data obtained in a certain historical time period at irregular times, for example, read the user data obtained in the historical time period to perform bad account risk detection when the CPU occupancy of the server side is low to improve the detection efficiency of bad account risk detection. The present embodiment does not limit this.

[0055] It is worth mentioning that the server side pulls the log data from each node in the CDN system, which can pull all the log data each time, i.e., perform full log data pulling, or pull updated log data each time, i.e., perform incremental log data pulling. This is not limited here.

[0056] Secondly, screening is essentially a mining process of potential risk users, that is, predicting the potential risk of CDN billing users by using the user data of CDN billing users, that is, finding CDN billing users who may cause bad debt losses to enterprises from a large number of CDN billing users. That is, the potential risk refers to the possibility of causing bad debt losses to enterprises, and the potential risk user refers to the CDN billing user who may cause bad debt losses to enterprises. For example, based on the user data of CDN billing user A, if it is found that the CDN billing user A attempts to resolve the IP address of the domain name to a node not specified by the CDN system, then through screening, the CDN billing user A can be determined as a potential risk user.

[0057] Through the above mining process of potential risk users, potential risk users can be preliminarily screened from a large number of CDN billing users, so as to reduce the complexity of subsequent bad debt risk detection, and thus facilitate the processing timeliness of bad debt risk detection.

[0058] Step 205, according to the CDN usage data of the potential risk user, the consumption of the potential risk user in the CDN system is estimated and processed, and the bad debt risk detection result of the potential risk user is obtained.

[0059] As described above, the CDN usage data is used to represent the network resource usage of the CDN billing user in the CDN system, so as to reflect the degree of bad debt losses that the CDN billing user may cause to the enterprise.

[0060] For example, assuming that the CDN usage data of potential risk user B indicates that the potential risk user B uses a large amount of network resources such as traffic and bandwidth in the CDN system, then the potential risk user B may cause greater bad debt losses to the enterprise, and it can also be considered that the potential risk user B has a greater risk of generating bad debts.

[0061] As described above, the user data of the CDN billing user includes but is not limited to user label data, user behavior data and CDN usage data, and the potential risk user is screened from the CDN billing user, so the CDN usage data of the potential risk user can be obtained according to the user data of the CDN billing user.

[0062] Secondly, the consumption of the potential risk user in the CDN system essentially refers to the billing amount corresponding to the CDN related products used by the potential risk user in the CDN system. For example, the billing amount corresponding to the network resources such as traffic or bandwidth used by the potential risk user in the CDN system.

[0063] The inventor finds that, based on the characteristics of the CDN system accounting by day, the CDN system operation and maintenance personnel usually intervene after the CDN billing is accounted, which leads to poor timeliness of the bad account risk detection processing. Therefore, in the embodiment, the estimated processing is to statistically estimate the consumption of the potential risk user in the CDN system according to the CDN consumption data of the potential risk user at the current time before the CDN billing is accounted.

[0064] Then, after the consumption of the potential risk user in the CDN system is statistically estimated, the bad account risk detection result of the potential risk user can be determined. The bad account risk detection result is used to indicate whether the potential risk user is a high-risk user.

[0065] For example, if the consumption of the potential risk user C in the CDN system is huge, the bad account risk detection result of the potential risk user C indicates that the potential risk user C is a high-risk user.

[0066] Of course, according to the actual needs of the application scenario, the high-risk user can also be divided into several levels, and different levels represent the degree of bad account risk caused by the high-risk user, so that the operation and maintenance personnel can make different control processing according to different levels of high-risk users. The embodiment is not limited specifically. For example, the high-risk user is divided into two levels A1 and A2, and the degree of bad account risk caused by the high-risk user of A1 level is higher than that of the high-risk user of A2 level. The operation and maintenance personnel can add the high-risk user of A1 level to the blacklist to prohibit the high-risk user from continuing to use the CDN system, and take the way of paying the late fees for the high-risk user of A2 level.

[0067] Through the above process, the bad account risk is actively detected, and the dependence on manual implementation is avoided, thereby effectively improving the timeliness of the bad account risk detection processing.

[0068] In addition, intervening in the bad account risk detection before the CDN billing is accounted can effectively avoid the bad account loss that is difficult for the enterprise to make up, thereby being beneficial to improving the operation profit of the enterprise.

[0069] Please refer to Figure 3 In the embodiment of the application, a possible implementation manner is provided, and step 203 can include the following steps:

[0070] Step 2031, calling an instantiation object created based on a user screening rule, predicting the risk level of the CDN billing user according to the user data of the CDN billing user, and obtaining the risk level of the CDN billing user.

[0071] Step 2033, taking the CDN billing user whose risk level exceeds the level threshold as a potential risk user.

[0072] In this embodiment, the instantiation object is created based on the user screening rule.

[0073] The user screening rule accurately describes how to screen the potential risk user from the CDN billing user from multiple dimensions. The multiple dimensions include but are not limited to behavior dimension, label dimension, usage data dimension, user channel dimension, etc. For example, from the behavior dimension, the user screening rule includes whether the domain name change is too frequent, or from the label dimension, the user screening rule includes whether the user is involved in pornography, or from the usage data dimension, the user screening rule includes the proportion of edge node usage and intermediate source node usage, etc.

[0074] Therefore, by calling the instantiation object, the risk level of the CDN billing user can be calculated by mining the user data of the CDN billing user according to the user screening rule, so as to realize that the risk level of the CDN billing user is returned when the user data of the CDN billing user is input, and thus the potential risk user, i.e. the CDN billing user whose risk level exceeds the level threshold, can be preliminarily screened from the massive CDN billing users. The level threshold can be flexibly adjusted according to the actual needs of the application scenario, which is not limited here.

[0075] It is supplemented here that in object-oriented programming, the user screening rule is regarded as a pre-constructed class, which is applicable to all CDN billing users, and its function is to screen the potential risk user from the CDN billing user. It should be understood that the class cannot be directly called, and after the object is instantiated, the function of the class can be realized by calling the instantiation object, i.e. the user data of a certain CDN billing user is input into the instantiation object, and the risk level of the CDN billing user is output by the instantiation object, and further, whether the CDN billing user is a potential risk user is determined according to the risk level of the CDN billing user.

[0076] Under the action of the above embodiment, on the one hand, the potential risk user mining based on the instantiation object is realized, which can preliminarily screen the potential risk user who may cause bad debt loss to the enterprise from the massive CDN billing users, and on the other hand, the user screening rule constructed from multiple dimensions can screen the CDN billing user from multiple dimensions, which is beneficial to improve the accuracy of potential risk user mining and thus the accuracy of bad debt risk detection.

[0077] Please refer to Figure 4 In the embodiment of the present application, a possible implementation manner is provided, and step 201 can include the following steps:

[0078] Step 2011, determine whether the log data of the CDN billing user in the CDN system is complete.

[0079] As described above, for the nodes in the CDN system, the log data of the CDN charging user in the CDN system reported by the user terminal will be received for the server side to pull.

[0080] Here, the inventor realizes that the memory resource of the server side is limited, and it is unnecessary to pull the log data of the CDN charging user in the CDN system every time, so in this embodiment, for the CDN charging user, before pulling the log data of the CDN charging user in the CDN system, the integrity of the log data of the CDN charging user in the CDN system is first determined, and then the full / incremental pulling of the log data is performed based on the integrity of the log data of the CDN charging user in the CDN system, so as to effectively improve the task processing efficiency of the server side, and further improve the processing timeliness of the bad debt risk detection.

[0081] The integrity of the log data of the CDN charging user in the CDN system is used to indicate whether the log data of the CDN charging user in the CDN system is complete.

[0082] If the log data of the CDN charging user in the CDN system is complete, the incremental pulling of the log data is performed, that is, jumping to step 2011c.

[0083] On the contrary, if the log data of the CDN charging user in the CDN system is not complete, the full pulling of the log data is performed, that is, jumping to step 2011e.

[0084] The determination process of the integrity of the log data of the CDN charging user in the CDN system is essentially achieved by counting the number of nodes reporting log data in the CDN system.

[0085] For example, it is assumed that the number of nodes in the CDN system actually interacting with the user terminal is 100, the number of nodes reporting log data at time A is 95, and the number of nodes reporting log data at time B is 75.

[0086] It is assumed that the integrity threshold is 95%, so at time A, the number of nodes reporting log data / the number of nodes actually interacting with the user terminal = 95 / 100 >= 95%, and at this moment, it is considered that the log data of the CDN charging user in the CDN system is complete.

[0087] At time B, the number of nodes reporting log data / the number of nodes actually interacting with the user terminal = 75 / 100 < 95%, so at this moment, it is considered that the log data of the CDN charging user in the CDN system is not complete.

[0088] Step 2013, requesting the incremental data in the log data to the CDN system.

[0089] It should be understood that the transmission of log data between the user terminal and the node in the CDN system is essentially the transmission of data packets carrying timestamps. In other words, the log data is encapsulated into a plurality of data packets carrying timestamps, and the timestamp represents the timestamping time of the corresponding data packet.

[0090] Based on this, for the server side, requesting the incremental data in the log data from the CDN system is essentially requesting the data packets with the timestamping time after a certain time from the CDN system. That is, the incremental data refers to the data packets with the timestamping time after a certain time.

[0091] For example, for the user terminal, at time C, the data packets completed encapsulation include data packets with timestamps B1, B2, and B3, and the data packets being encapsulated include data packets with timestamps B4 and B5.

[0092] Then, for the server side, at time C, the data packets with timestamps B1, B2, and B3 can be received from the CDN system, and the data packets with timestamps B4 and B5 are regarded as data packets with the timestamping time after time C, i.e., the incremental data in the log data.

[0093] Therefore, after time C, the server side sends an incremental data request to the CDN system, and after receiving the incremental data request, the CDN system returns the incremental data in the log data, i.e., the data packets with timestamps B4 and B5.

[0094] Step 2015, generating user data of the CDN charging user according to the incremental data.

[0095] Step 2017, requesting the log data from the CDN system.

[0096] Still taking the foregoing example as an example, in order to ensure the integrity of the log data of the CDN charging user in the CDN system, and further ensure the accuracy of the potential risk user mining, after time C, the server side sends a full data request to the CDN system, and after receiving the full data request, the CDN system returns the data packets with timestamps B1, B2, B3, B4, and B5, i.e., the server side performs full pulling of the log data, regardless of whether the server side has stored the data packets with timestamps B1 and B2.

[0097] Step 2019, generating user data of the CDN charging user according to the log data.

[0098] The generation process of the user data of the CDN billing user is consistent whether based on the log data or based on the incremental data in the log data. The generation process of the user data of the CDN billing user is described below by taking the log data as an example. The user data of the CDN billing user includes the user label data, the user behavior data and the CDN usage data of the CDN billing user, i.e., the user data = {user label data, user behavior data, CDN usage data}.

[0099] Firstly, the generation process of the user label data of the CDN billing user is described.

[0100] Specifically, the user information is found in the log data of the CDN billing user, and the user information is encapsulated as the user label data. The user information can include the user registration information, the user login IP, the billing mode used in the CDN system, the historical CDN pre-paid package data, the historical CDN post-paid payment data, the pornographic record, the ban record, the VIP privilege and the like.

[0101] For example, the CDN billing user = {‘user registration information’, ‘user login IP’, ‘billing mode used in the CDN system’, ‘historical CDN pre-paid package data’, ‘historical CDN post-paid payment data’, ‘pornographic record’, ‘ban record’, ‘VIP privilege’}.

[0102] Secondly, the generation process of the user behavior data of the CDN billing user is described.

[0103] Specifically, the behavior identifier uniquely representing the user behavior is found in the log data of the CDN billing user, and the user behavior data is generated from the behavior identifier according to the trigger time of the user behavior.

[0104] For example, it is assumed that the user deletes the domain name in the CDN system, which is represented as the behavior identifier 1, replaces the accelerated domain name, which is represented as the behavior identifier 2, performs the domain name resolution, which is represented as the behavior identifier 3, changes the domain name ownership between multiple accounts multiple times, which is represented as the behavior identifier 4, and switches the billing mode, which is represented as the behavior identifier 5. Of course, the behavior identifier can also be represented by one or a combination of letters, numbers and characters, which is not a specific limitation here.

[0105] It is further assumed that the log data of the CDN billing user includes the behavior identifier 4 with the trigger time 8:00, the behavior identifier 2 with the trigger time 9:00, the behavior identifier 1 with the trigger time 9:10, the behavior identifier 5 with the trigger time 10:00, and the behavior identifier 4 with the trigger time 10:30, and the like. Then, the user behavior data = [4, 2, 1, 5, 4, …].

[0106]

[0107] ​As mentioned above, the network resource usage can be represented by traffic or bandwidth. The following will take the traffic as an example to illustrate the generation of the CDN usage data.

[0108] Specifically, first, the traffic at the current time is obtained from the log data of the CDN billing user.

[0109] For example, for the log data obtained by the server, the time indicated by the timestamp of the log data is 10 o'clock, that is, the current time is 10 o'clock, and the traffic at the current time refers to the cumulative sum of the traffic from 0 o'clock to 10 o'clock.

[0110] Secondly, the configuration parameters for generating the CDN usage data are determined, and the CDN usage data is calculated according to the configuration parameters and the traffic at the current time. The configuration parameters include but are not limited to the billing mode, the floating ratio coefficient, the domain name peak-shaving, etc. Of course, in other embodiments, the configuration parameters can also include user screening rules, detection rules, detection thresholds, detection sensitivity levels, alarm-related thresholds, and operation parameters of the bad account risk detection device, etc. This is not a specific limitation.

[0111] For example, assuming that the billing mode is log billing, then in the log billing mode, assuming that the floating ratio coefficient is 5%, then the CDN usage data = traffic at the current time * (1+5%).

[0112] Or, assuming that there are multiple domain names for the user, then for the domain name peak-shaving, under the premise that the timestamps of the log data are aligned, then the CDN usage data = the sum of the traffic at the current time corresponding to the multiple domain names.

[0113] Of course, in other embodiments, if the network resource usage is represented by bandwidth, then the CDN usage data = the bandwidth peak value at the current time. Still taking the above example, the bandwidth peak value at the current time refers to the bandwidth peak value up to 10 o'clock.

[0114] Under the action of the above embodiments, the user data of the CDN billing user is obtained, which serves as the data basis for the preliminary screening of the potential risk user of the CDN billing user, and thus the bad account risk detection based on the potential risk user can be fully realized.

[0115] Please refer to Figure 5 In the embodiments of the present application, a possible implementation manner is provided, and step 205 can include the following steps:

[0116] Step 2051, calculating the to-be-estimated usage data according to the CDN usage data of the potential risk user based on the detection rule.

[0117] The detection rule is used to describe the way in which the potential risk user estimates the network resource usage in the CDN system. The detection rule includes but is not limited to: calculation of the overall network resource usage, calculation of the increasing network resource usage, calculation of the network resource usage of the newly accessed domain name, and calculation of the proportion of the network resource usage of the accessed edge node and the network resource usage of the accessed intermediate source node, and the like.

[0118] Correspondingly, the to-be-estimated data refers to the network resource usage of the potential risk user in the CDN system based on the detection rule. Since the network resource usage can be represented by traffic or bandwidth, the to-be-estimated data can also be represented by traffic or bandwidth, which is not limited here.

[0119] The calculation process of the to-be-estimated data is described below.

[0120] Specifically, first, the CDN usage data of the potential risk user in the CDN system on the day is estimated based on the CDN usage data of the potential risk user (i.e. the CDN usage data at the current time), i.e. the CDN usage data on the day.

[0121] For example, when the to-be-estimated data is represented by traffic, the CDN usage data on the day = the CDN usage data at the current time + the CDN usage data at the future time. Still taking the above example, assuming that the user terminal reports the log data at the whole hour, based on a number of the 11 traffics between 0 and 10, the average traffic is calculated and predicted as the 13 traffics between 11 and 23, and then the cumulative sum of the future traffic is estimated, and the CDN usage data at the future time is calculated in combination with the configuration parameter, so as to finally calculate the CDN usage data on the day.

[0122] Or, when the to-be-estimated data is represented by bandwidth, the to-be-estimated data is the bandwidth peak value up to the current time.

[0123] Then, the overall network resource usage is calculated, and the to-be-estimated usage data is the CDN usage data of the potential risk user in the CDN system on the day.

[0124] The increasing network resource usage is calculated, and the to-be-estimated usage data is the difference of the CDN usage data of the potential risk user, for example, the difference between the CDN usage data of the previous day and the CDN usage data on the day.

[0125] The to-be-estimated data is the CDN usage data of the potential risk user on the day when the potential risk user accesses the new domain name in the CDN system, and can also be understood as the CDN usage data of the potential risk user on the day when the potential risk user accesses the node where the new domain name is located.

[0126] The to-be-estimated data includes the CDN usage data of the potential risk user on the day when the potential risk user accesses the edge node in the CDN system and the CDN usage data of the potential risk user on the day when the potential risk user accesses the intermediate source node.

[0127] That is, the to-be-estimated data depends on the detection rule, and the detection rule can be flexibly configured by the operation and maintenance personnel according to the actual needs of the application scene. Correspondingly, the to-be-estimated data will also be different with the detection rule, which is not limited in the embodiment.

[0128] Step 2053, calculating the billing amount of the potential risk user in the CDN system according to the to-be-estimated data.

[0129] Specifically, the billing amount of the potential risk user in the CDN system is calculated according to the following formula: billing amount = Source * Money.

[0130] Wherein, Source represents the to-be-estimated data; Money represents the unit price of the network resources such as traffic and bandwidth specified in the charging mode of the CDN system, wherein the charging mode of the CDN system includes but is not limited to: log charging, network card charging, traffic charging, bandwidth charging, peak shifting charging, edge node traffic, intermediate source node traffic, request number, monthly minimum consumption, daily charging, monthly package, quarterly package, annual package, etc.

[0131] For example, if the to-be-estimated data Source represents the traffic used by the potential risk user in the CDN system, then Money represents the unit price under the traffic charging mode; or, assuming that the to-be-estimated data Source represents the bandwidth used by the potential risk user in the CDN system, then Money represents the unit price under the bandwidth charging mode.

[0132] It should be noted that the CDN system usually has the feature of daily billing, and in the embodiment, the billing amount specifically refers to the daily billing amount. Of course, according to the actual needs of the application scene, the billing amount can also refer to the half-daily billing amount, the hourly billing amount, etc., so as to further improve the processing timeliness of the bad debt risk detection, which is not limited in the embodiment.

[0133] Step 2055, if the bill amount exceeds the detection threshold, the bad account risk detection result of the potential risk user indicates that the potential risk user is a high risk user.

[0134] The detection threshold is related to the detection rule, and the detection threshold will also be different as the detection rule is different. The detection threshold includes a real-time cost threshold and a usage surge threshold. Further, the usage surge threshold includes a new domain access magnitude surge threshold, a percentage threshold of how much the surge exceeds, an overall usage magnitude surge threshold, and a percentage threshold of the proportion between the edge node usage and the intermediate source node usage.

[0135] For example, assuming that the detection rule is to estimate the overall network resource usage, the detection threshold is essentially a real-time cost threshold. If the consumption of the potential risk user in the CDN system represented by the bill amount has exceeded the real-time cost threshold, the potential risk user is considered to be a high risk user.

[0136] Of course, in other embodiments, detection sensitivity levels can also be set for different user groups, and a complete set of detection thresholds can be configured for each level of detection sensitivity level to further improve the accuracy of bad account risk detection. For example, for a user group that has caused bad account losses to the enterprise, a higher detection sensitivity level is set, that is, a set of smaller numerical detection thresholds are configured to minimize the potential risk of the potential risk customer to the enterprise. Bad account losses; or, for a user group that has never caused bad account losses to the enterprise, a lower detection sensitivity level is set, that is, a set of larger numerical detection thresholds are configured to avoid false detection of high-risk users, thereby fully guaranteeing the accuracy of bad account risk detection.

[0137] Through the above process, the estimation of bad account losses in bad account risk detection is realized, that is, the fees that can be generated on the current day are estimated according to the current trend of the fees that have been generated at the current moment, so that the bad account losses that the high-risk user may cause to the enterprise will be suppressed in the first time before the CDN billing account is charged. Not only effectively guarantees the timeliness of bad account risk detection, but also greatly reduces the amount and degree of bad account losses, thereby being beneficial to improving the operating profit of the enterprise.

[0138] In the embodiments of the present application, a possible implementation manner is provided. After step 205, the method can further include the following steps:

[0139] When the bad account risk detection result of the potential risk user indicates that the potential risk user is a high risk user, or when the bad account risk detection is abnormal, an alarm message is generated.

[0140] The alarm message is used to prompt the operation and maintenance personnel to timely control and process the high-risk potential risk user, or prompt the operation and maintenance personnel that the bad account risk detection is abnormal.

[0141] Here, the bad account risk detection abnormality includes but is not limited to that no log data of the CDN charging user in the CDN system is received, instantiation object calling is abnormal, estimated processing is abnormal, and alarm is abnormal.

[0142] Optionally, the notification type of the alarm message can include written notification and oral notification. Further, the written notification includes but is not limited to short message notification, WeChat notification, enterprise WeChat notification, and email notification. The oral notification includes but is not limited to telephone notification, voice notification, and video notification.

[0143] Optionally, the alarm message can be divided into several levels from low to high.

[0144] For example, the alarm message can be divided into several levels according to the notification type. For example, the alarm message of the written notification type is a low level, and the alarm message of the oral notification type is a high level.

[0145] Alternatively, the alarm message corresponding to the high-risk user is divided into several levels from low to high, and each level corresponds to a level of the high-risk user.

[0146] Through the cooperation of the above embodiments, the alarm in the bad account risk detection is realized, so as to comprehensively ensure that the bad account risk can be timely notified to the operation and maintenance personnel, and the accuracy and processing timeliness of the bad account risk detection are beneficially ensured.

[0147] As described above, the alarm message can be divided into several levels from low to high. Accordingly, please refer to Figure 6 In the embodiments of the present application, a possible implementation manner is provided. The generation process of the alarm message can include the following steps.

[0148] Step 301, when generating the alarm message of the first level, starting a timer.

[0149] Step 303, when the value of the timer exceeds the time threshold and no confirmation processing operation for the alarm message of the first level is detected, generating the alarm message of the second level.

[0150] Here, the second level is higher than the first level.

[0151] Then, for the high-risk user, a first-level alarm message can be sent to the operation and maintenance personnel first, and if the operation and maintenance personnel do not respond to the first-level alarm message, a second-level alarm message is sent to the operation and maintenance personnel, until the operation and maintenance personnel respond to the second-level alarm message, that is, the server end detects the confirmation processing operation for the second-level alarm message.

[0152] It is further explained that, for the server end, an alarm confirmation entry is provided in the bad account risk detection operation interface for the operation and maintenance personnel, so that the operation and maintenance personnel can trigger the confirmation processing operation for the alarm message of different levels through the alarm confirmation entry, so that the server end can detect the confirmation processing operation.

[0153] It is further explained that, according to different server end input components (such as touch layer on display screen, mouse, keyboard, etc.), the specific behavior of the confirmation processing operation triggered by the user at the control entry can also be different. For example, for a server end desktop computer input by a touch layer, the confirmation processing operation can be a gesture operation such as clicking and sliding, and for a server configured with a mouse, the confirmation processing operation can be a mechanical operation such as dragging, single clicking, double clicking, etc., which is not limited here.

[0154] In addition, the operation and maintenance personnel can not be in front of the bad account risk detection operation interface, at this time, the server end will interact with the operation and maintenance personnel's handheld terminal through the pre-established communication connection (such as mobile phone number binding, etc.) to realize the detection of the confirmation processing operation. Specifically, the operation and maintenance personnel's handheld terminal provides a corresponding alarm confirmation entry, for example, a short message reply channel is used as an alarm confirmation entry, when the operation and maintenance personnel replies to the short message notification type alarm message through the short message reply channel, it is considered that the operation and maintenance personnel triggers the confirmation processing operation for the alarm message, and then, for the server end, after receiving the reply short message sent by the operation and maintenance personnel's handheld terminal, it is considered that the confirmation processing operation for the alarm message is detected.

[0155] Of course, there is also a possible implementation way, generating an alarm message based on the level of the high-risk user, the specific process is as follows:

[0156] Determine the level of the high-risk user.

[0157] If the level of the high-risk user exceeds the level threshold, a second-level alarm message is generated, otherwise a first-level alarm message is generated.

[0158] At the same time, for the operation and maintenance personnel who cannot handle in time, the first-level alarm message can also be upgraded to the second-level alarm message, the specific process is as described above, which will not be repeated here.

[0159] For example, assuming that the high-risk users are divided into two levels A1 and A2, the high-risk users of the A1 level cause higher bad account risk than the high-risk users of the A2 level, and it can also be understood that the high-risk users of the A1 level are extremely high-risk users, and the high-risk users of the A2 level are super high-risk users.

[0160] Then, for the extremely high-risk users, the first-level alarm message can be sent to the operation and maintenance personnel first, if the operation and maintenance personnel do not respond to the first-level alarm message, the second-level alarm message is sent to the operation and maintenance personnel again, until the operation and maintenance personnel respond to the second-level alarm message, that is, the confirmation processing operation for the second-level alarm message is detected; and for the super high-risk users, the second-level alarm message is always sent to the operation and maintenance personnel.

[0161] Of course, in different application scenarios, multiple level thresholds can be set according to actual needs, and correspondingly, multiple levels of alarm messages are generated, that is, the level of the alarm message is gradually upgraded according to the timeliness of the response of the operation and maintenance personnel, and the embodiment is not specifically limited in this regard.

[0162] Through the cooperation of the above embodiments, the alarm escalation in the bad account risk detection is realized, the purpose of notifying the operation and maintenance personnel to handle the bad account risk in time is achieved, and the processing timeliness of the bad account risk detection is further effectively improved.

[0163] Please refer to Figure 7 In the embodiment of the present application, a possible implementation manner is provided, and after step 205, the method can further include the following steps:

[0164] Step 401: When the bad account risk detection result of the potential risk user indicates that the potential risk user is a high-risk user, a management and control processing operation for the high-risk user is detected.

[0165] Step 403: The high-risk user is managed and controlled according to the detected management and control processing operation.

[0166] The management and control processing includes but is not limited to banning the user, setting a white list, setting a black list, and the like.

[0167] Similarly, for the server side, the operation and maintenance personnel can be provided with a management and control processing entrance in the bad account risk detection operation interface, so that the operation and maintenance personnel can trigger the management and control processing operation for the high-risk user through the management and control processing entrance, and then the server side can know the management and control processing of the operation and maintenance personnel for the high-risk user.

[0168] For example, in the bad account risk detection operation interface, the server side is provided with an input dialog box for setting a blacklist, and the operation and maintenance personnel can input a high-risk user through the input dialog box. Here, the input dialog box is regarded as a control processing entrance provided in the bad account risk detection operation interface, and correspondingly, the input operation is regarded as a control processing operation of the operation and maintenance personnel on the high-risk user through the control processing entrance.

[0169] Then, the server side can detect the control processing operation, and further form a blacklist based on the high-risk user input by the operation and maintenance personnel.

[0170] Under the action of the above embodiment, real-time control of the high-risk user in the bad account risk detection is realized, that is, the operation and maintenance personnel can take effective control processing on the high-risk user in time to avoid the bad account loss caused by the high-risk user to the enterprise as soon as possible, thereby further effectively improving the processing timeliness of the bad account risk detection.

[0171] Figure 8 FIG. 1 is a specific implementation schematic diagram of a bad account risk detection method in an application scenario. In the application scenario, the bad account risk detection device 800 is used to mine potential risk users and estimate the consumption of the potential risk users in the CDN system before CDN charging is debited, so as to realize bad account risk detection.

[0172] Specifically, as shown in Figure 8 (a), the bad account risk detection device 800 includes a data processing module 801, a user model module 802, a real-time bad account detection algorithm module 803, an alarm module 804, an operation processing module 805, and a parameter information configuration module 806.

[0173] As shown in Figure 8 (b), on the one hand, before CDN charging is debited, the data processing module 801 generates user data of a CDN charging user according to log data of the CDN charging user in the CDN system, and sends the user data of the CDN charging user to the user model module 802.

[0174] After receiving the user data of the CDN charging user, the user model module 802 predicts the risk level of the CDN charging user by calling an instantiated object created based on a user screening rule, so as to complete mining of potential risk users, and further sends the mined potential risk users to the real-time bad account detection algorithm module 803.

[0175] The real-time bad account detection algorithm module 803 estimates the consumption of the potential risk user in the CDN system according to the CDN usage data of the potential risk user, to obtain a bad account risk detection result indicating whether the potential risk user is a high-risk user, and sends the bad account risk detection result to the alarm module 804.

[0176] When the bad account risk detection result indicates that the potential risk user is a high-risk user, the alarm module 804 generates an alarm message and notifies the operation processing module 805 to detect a confirmation processing operation for the alarm message, so that the operation processing module 805 can control and process the high-risk user according to the detected confirmation processing operation, for example, ban the high-risk user, and notify the parameter information configuration module 806.

[0177] It is worth mentioning that in the process of real-time detection of bad account risk, the instantiation object for potential risk user mining is updated in real time, so as to ensure the accuracy of potential risk user mining. On the one hand, it depends on data-driven, that is, the update of user data, for example, with the update of log data reported by the user terminal, the user label data, user behavior data and CDN usage data will be updated accordingly; on the other hand, it depends on artificial driving, with the update of the configuration parameters by the operation and maintenance personnel in the parameter information configuration module 806, the real-time bad account detection algorithm module 803 will notify the user model module 802 to update accordingly.

[0178] On the other hand, after the CDN billing is completed, the bills of the CDN billing users in the CDN system are manually checked, and corresponding control and processing is taken in time for the CDN billing users who maliciously use network resources such as traffic and bandwidth, for example, blacklisting, banning the user and the like. Therefore, through the mutual cooperation of real-time detection of bad account risk before and after CDN billing and manual checking, the bad account loss is effectively reduced.

[0179] In this application scenario, the bad account risk detection is changed from passive detection to active detection, which not only effectively improves the processing timeliness of bad account risk detection, but also intervenes in the bad account risk detection before the CDN billing is completed, so as to ensure that the bad account can be suppressed at the embryonic stage in the first time, greatly reducing the amount and degree of bad account loss, and thus being beneficial to improving the operation profit of the enterprise.

[0180] The following is an embodiment of the device of the present application, which can be used to execute the bad account risk detection method involved in the present application. For details not disclosed in the device embodiment of the present application, please refer to the method embodiment of the bad account risk detection method involved in the present application.

[0181] Please refer to Figure 9The embodiment of the application provides a bad account risk detection device 900, including but not limited to: a data acquisition module 901, a user screening module 903 and a consumption estimation module 905.

[0182] The data acquisition module 901 is used for acquiring user data of a content distribution network (CDN) charging user, wherein the user data includes CDN usage data.

[0183] The user screening module 903 is used for predicting potential risks of the CDN charging user according to the user data of the CDN charging user, and screening potential risk users from the CDN charging user.

[0184] The consumption estimation module 905 is used for performing pre-estimation processing on consumption of the potential risk user in the CDN system according to the CDN usage data of the potential risk user, and obtaining a bad account risk detection result of the potential risk user.

[0185] The embodiment of the application provides a possible implementation manner, and the user screening module 903 includes but is not limited to: an object creation unit and a user definition unit.

[0186] The object creation unit is used for calling an instantiation object created based on a user screening rule, predicting a risk level of the CDN charging user according to the user data of the CDN charging user, and obtaining the risk level of the CDN charging user.

[0187] The user definition unit is used for regarding the CDN charging user with a risk level exceeding a level threshold as a potential risk user.

[0188] The embodiment of the application provides a possible implementation manner, and the data acquisition module 901 includes but is not limited to: an integrity determination unit, an incremental data request unit and a first data generation unit.

[0189] The integrity determination unit is used for determining whether log data of the CDN charging user in the CDN system is complete.

[0190] The incremental data request unit is used for requesting incremental data in the log data from the CDN system if the log data is complete.

[0191] The first data generation unit is used for generating the user data of the CDN charging user according to the incremental data.

[0192] The embodiment of the application provides a possible implementation manner, and the data acquisition module 901 further includes but is not limited to: a log data request unit and a second data generation unit.

[0193] The log data request unit is used for requesting the log data from the CDN system if the log data is not complete.

[0194] The second data generation unit is configured to generate user data of the CDN charging user according to the log data.

[0195] In an embodiment of the present application, the consumption estimation module 905 includes, but is not limited to, a data determination unit, a data calculation unit, and a threshold detection unit.

[0196] The data determination unit is configured to determine the to-be-estimated consumption data of the potential risk user based on the detection rule and the CDN consumption data of the potential risk user.

[0197] The data calculation unit is configured to calculate the billing amount of the potential risk user in the CDN system according to the to-be-estimated consumption data.

[0198] The threshold detection unit is configured to indicate that the potential risk user is a high-risk user if the billing amount exceeds the detection threshold.

[0199] In an embodiment of the present application, the bad account risk detection device 900 includes, but is not limited to, an alarm module.

[0200] The alarm module is configured to generate an alarm message when the bad account risk detection result of the potential risk user indicates that the potential risk user is a high-risk user, or when the bad account risk detection is abnormal.

[0201] In an embodiment of the present application, the alarm message is divided into several levels from low to high. Accordingly, the bad account risk detection device 900 further includes an alarm module, which includes, but is not limited to, a timing unit and an alarm upgrade unit.

[0202] The timing unit is configured to start a timer when the alarm message of the first level is generated.

[0203] The alarm upgrade unit is configured to generate an alarm message of a second level when the value of the timer exceeds a time threshold and no confirmation processing operation for the alarm message of the first level is detected, the second level being higher than the first level.

[0204] In an embodiment of the present application, the bad account risk detection device 900 further includes a management and control processing module, which includes, but is not limited to, an operation detection unit and a management and control processing unit.

[0205] The operation detection unit is configured to detect a management and control processing operation for the high-risk user when the bad account risk detection result of the potential risk user indicates that the potential risk user is a high-risk user.

[0206] The control processing unit is configured to perform control processing on the high-risk user according to the detected control processing operation.

[0207] It should be noted that the above-mentioned embodiments provide a bad account risk detection device, when detecting the bad account risk, only the above-mentioned division of each functional module is exemplified, and in actual application, the above-mentioned functions can be distributed by different functional modules to complete, that is, the internal structure of the bad account risk detection device is divided into different functional modules to complete all or part of the above-described functions.

[0208] In addition, the embodiments of the bad account risk detection device and the bad account risk detection method provided by the above-mentioned embodiments belong to the same concept, and the specific way in which each module performs operations has been described in detail in the method embodiments, which will not be described here.

[0209] Therefore, before the CDN charges, the bad account risk detection is actively detected, so as to effectively improve the processing timeliness of the bad account risk detection.

[0210] Figure 10 According to an exemplary embodiment, a structure of a server is shown. The server is suitable for Figure 1 The server end 200 of the shown implementation environment.

[0211] It should be noted that the server is only an example suitable for the present application, and cannot be considered as providing any limitation on the use range of the present application. The server also cannot be interpreted as needing to depend on or must have Figure 10 One or more components in the shown exemplary server 2000.

[0212] The hardware structure of the server 2000 can have great differences due to different configurations or performances, such as Figure 10 As shown, the server 2000 includes a power supply 210, an interface 230, at least one memory 250, and at least one central processing unit (CPU) 270.

[0213] Specifically, the power supply 210 is configured to provide working voltage for each hardware device on the server 2000.

[0214] The interface 230 includes at least one wired or wireless network interface, which is configured to interact with external devices. For example, the Figure 1 The interaction between the CDN system 300 and the server end 200 in the shown implementation environment.

[0215] Of course, in the rest of the application adapted examples, interface 230 can further include at least one serial conversion interface 233, at least one input / output interface 235, and at least one USB interface 237, etc., as shown, which is not specifically limited here. Figure 10

[0216] Memory 250, as a carrier of resource storage, can be a read-only memory, a random access memory, a magnetic disk or an optical disk, etc., and the resources stored thereon include an operating system 251, an application program 253 and data 255, etc., and the storage mode can be temporary storage or permanent storage.

[0217] The operating system 251 is used to manage and control each hardware device on the server 2000 and the application program 253, so as to realize the operation and processing of the central processing unit 270 on the mass data 255 in the memory 250, which can be Windows ServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM, etc.

[0218] The application program 253 is a computer program that completes at least one specific work based on the operating system 251, which can include at least one module (not shown), and each module can contain a series of computer readable instructions for the server 2000. For example, the bad account risk detection device can be regarded as an application program 253 deployed on the server 2000. Figure 10 The data 255 can be photos, pictures, etc. stored in the disk, and can also be key-value pairs, etc. stored in the memory 250.

[0219] The central processing unit 270 can include one or more processors, and is configured to communicate with the memory 250 through at least one communication bus, to read the computer readable instructions stored in the memory 250, and to realize the operation and processing of the mass data 255 in the memory 250. For example, the bad account risk detection method is completed by the central processing unit 270 reading a series of computer readable instructions stored in the memory 250.

[0220] In addition, the present application can also be realized by hardware circuit or hardware circuit combined with software, therefore, the realization of the present application is not limited to any specific hardware circuit, software and combination of the two.

[0221] Please refer to

[0222] , the embodiment of the present application provides an electronic device 400, which includes at least one processor 4001, at least one communication bus 4002 and at least one memory 4003. Figure 11

[0223] ​​The processor 4001 and the memory 4003 are connected, for example, through a communication bus 4002. Optionally, the electronic device 4000 can further include a transceiver 4004, which can be used for data interaction between the electronic device 4000 and other electronic devices, such as data sending and / or data receiving. It should be noted that the transceiver 4004 is not limited to one in actual application, and the structure of the electronic device 4000 does not constitute a limitation to the embodiments of the present application.

[0224] The processor 4001 can be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array) or other programmable logic device, a transistor logic device, a hardware component or any combination thereof. It can implement or execute various exemplary logical blocks, modules and circuits described in combination with the disclosure. The processor 4001 can also be a combination of computing functions, such as one or more microprocessor combinations, combinations of DSP and microprocessor, etc.

[0225] The communication bus 4002 can include a channel for transmitting information between the above components. The communication bus 4002 can be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. The communication bus 4002 can be divided into an address bus, a data bus, a control bus, etc. For the convenience of representation, Figure 11 Only one thick line is used in the middle, but it does not mean that there is only one bus or one type of bus.

[0226] The memory 4003 can be a ROM (Read Only Memory) or other type of static storage device that can store static information and instructions, a RAM (Random Access Memory) or other type of dynamic storage device that can store information and instructions, an EEPROM (Electrically Erasable Programmable Read Only Memory), a CD-ROM (Compact Disc Read Only Memory) or other optical disk storage, a magnetic disk storage or other magnetic storage devices, or any other medium capable of storing desired program code in the form of instructions or data structures and that can be accessed by a computer, but is not limited thereto.

[0227] The memory 4003 stores computer readable instructions, and the processor 4001 reads the computer readable instructions stored in the memory 4003 through the communication bus 4002.

[0228] The computer readable instructions are executed by the processor 4001 to implement the bad account risk detection method in the above embodiments.

[0229] The electronic device 4000 includes, but is not limited to, a desktop computer, a notebook computer, a server, and the like.

[0230] In the embodiments of the present application, a storage medium is provided, and the storage medium stores a computer program. The computer program is executed by a processor to implement the bad account risk detection method in the above embodiments.

[0231] In the embodiments of the present application, a computer program product is provided, and the computer program product includes computer readable instructions stored in a storage medium. A processor of a computer device reads the computer readable instructions from the storage medium, and the processor executes the computer readable instructions to enable the computer device to execute the bad account risk detection method in the above embodiments.

[0232] Compared with the prior art, the bad account risk detection is actively performed before the CDN charging is debited, thereby effectively improving the processing timeliness of the bad account risk detection.

[0233] It should be understood that although the steps in the flowcharts of the drawings are shown in sequence according to the indication of the arrows, the steps are not necessarily executed in sequence according to the indication of the arrows. Unless explicitly stated herein, the execution of the steps is not strictly limited in sequence, and the steps can be executed in other sequences. Moreover, at least part of the steps in the flowcharts of the drawings can include multiple sub-steps or multiple stages, which are not necessarily executed at the same time, but can be executed at different times, and the execution sequence is not necessarily sequential, but can be executed in rotation or alternation with at least part of other steps or sub-steps or stages of other steps.

[0234] The above merely describes some embodiments of the present application, and it should be pointed out that for those skilled in the art, some improvements and refinements can be made without departing from the principles of the present application, and these improvements and refinements should also be considered as falling within the scope of protection of the present application.

Claims

1. A bad debt risk detection method, characterized by, The method comprises: obtaining user data of a content distribution network (CDN) charging user, the user data comprising user label data, user behavior data, and CDN usage data; wherein the user label data is used to represent the CDN charging user, and comprises at least one of a charging mode used by the user in the CDN system, historical CDN prepayment package data, historical CDN postpayment payment data, a ban record, or a VIP privilege; the user behavior data is used to describe user behavior of the CDN charging user in the CDN system, and comprises at least one of deleting a domain name, replacing an accelerated domain name, domain name resolution, multiple times of changing domain name ownership among multiple accounts, or switching a charging mode; predicting potential risks of the CDN charging user according to the user data of the CDN charging user, and screening potential risk users from the CDN charging user; before charging an account of the CDN charging user, calculating to-be-estimated usage data according to CDN usage data of the potential risk user based on a detection rule, calculating a bill limit of the potential risk user in the CDN system according to the to-be-estimated usage data and a unit price of network resources corresponding to a charging mode of the CDN system, and if the bill limit exceeds a detection threshold, a bad account risk detection result of the potential risk user indicates that the potential risk user is a high-risk user; wherein the detection rule is used to describe a way of estimating consumption of the potential risk user in the CDN system, and the detection rule comprises calculating a total network resource usage, calculating an increasing network resource usage, calculating a network resource usage of a newly accessed domain name, and calculating a proportion of network resource usage of an edge node and network resource usage of an intermediate source node; and the detection threshold is related to the detection rule.

2. The method of claim 1, wherein, The method further comprises: calling an instantiation object created based on a user screening rule, predicting a risk level of the CDN charging user according to the user data of the CDN charging user, and obtaining the risk level of the CDN charging user; regarding the CDN charging user whose risk level exceeds a level threshold as the potential risk user.

3. The method of claim 1, wherein, The method further comprises: determining whether log data of the CDN charging user in the CDN system is complete; if the log data is complete, requesting incremental data in the log data from the CDN system; generating the user data of the CDN charging user according to the incremental data.

4. The method of claim 3, wherein, The method further comprises: if the log data is not complete, requesting the log data from the CDN system; generating the user data of the CDN charging user according to the log data.

5. The method according to any one of claims 1 to 4, characterized in that, The method further comprises: When the bad account risk detection result of the potential risk user indicates that the potential risk user is a high risk user, or when the bad account risk detection is abnormal, an alarm message is generated.

6. The method of claim 5, wherein, The alarm message is divided into several levels from low to high. The alarm message generation includes: When the first level alarm message is generated, a timer is started. When the value of the timer exceeds a time threshold and no confirmation processing operation for the first level alarm message is detected, a second level alarm message is generated, which is higher than the first level.

7. A bad debt risk detection apparatus characterized by comprising: It includes: A data acquisition module is configured to acquire user data of a content distribution network (CDN) charging user, wherein the user data includes user label data and user behavior data, and CDN usage data; the user label data is used to represent the CDN charging user, and includes at least one of a charging mode used by the user in the CDN system, historical CDN pre-paid package data, historical CDN post-paid payment data, a ban record, or a VIP privilege; the user behavior data is used to describe the user behavior of the CDN charging user in the CDN system, and includes at least one of deleting a domain name, replacing an accelerated domain name, domain name resolution, multiple times of changing domain name ownership between multiple accounts, or switching a charging mode; A user screening module is configured to predict potential risks of the CDN charging user according to the user data of the CDN charging user, and to screen potential risk users from the CDN charging user; The consumption estimation module includes a data determination unit, a data calculation unit, and a threshold detection unit: The data determination unit is configured to determine to-be-estimated usage data of the potential risk user based on a detection rule before a CDN charging account is generated, according to CDN usage data of the potential risk user; The data calculation unit is configured to calculate a bill limit of the potential risk user in the CDN system according to the to-be-estimated usage data and a unit price of network resources corresponding to a charging mode of the CDN system; The threshold detection unit is configured to determine that the potential risk user is a high risk user if the bill limit exceeds a detection threshold. The detection rule is used to describe a way of estimating consumption of the potential risk user in the CDN system, and includes calculating an overall network resource usage, calculating an increasing network resource usage, calculating a network resource usage of a new domain name access, and calculating a proportion of network resource usage of an access edge node and network resource usage of an access intermediate source node; the detection threshold is related to the detection rule.

8. The bad debt risk detection apparatus of claim 7 wherein, The user screening module includes an object creation unit and a user definition unit: The object creation unit is configured to call an instantiated object created based on a user screening rule, to predict a risk level of the CDN charging user according to the user data of the CDN charging user, and to obtain the risk level of the CDN charging user; The user definition unit is configured to define the CDN charging user with a risk level exceeding a level threshold as the potential risk user.

9. The bad debt risk detection apparatus of claim 7, wherein, The data acquisition module comprises an integrity determination unit, an incremental data request unit and a first data generation unit: The integrity determination unit is configured to determine whether log data of the CDN charging user in the CDN system is complete; The incremental data request unit is configured to request incremental data in the log data from the CDN system if the log data is complete; The first data generation unit is configured to generate user data of the CDN charging user according to the incremental data.

10. The bad debt risk detection apparatus of claim 9, wherein, The data acquisition module further comprises a log data request unit and a second data generation unit: The log data request unit is configured to request the log data from the CDN system if the log data is incomplete; The second data generation unit is configured to generate user data of the CDN charging user according to the log data.

11. The bad debt risk detection apparatus according to any one of claims 7 to 10, wherein The bad account risk detection device comprises an alarm module: The alarm module is configured to generate an alarm message when a bad account risk detection result of the potential risk user indicates that the potential risk user is a high risk user, or when a bad account risk detection is abnormal.

12. The bad debt risk detection apparatus of claim 11, wherein, The alarm message is divided into several levels from low to high; The alarm module comprises a timing unit and an alarm upgrade unit: The timing unit is configured to start a timer when a first level alarm message is generated; The alarm upgrade unit is configured to generate a second level alarm message when a value of the timer exceeds a time threshold and no confirmation processing operation for the first level alarm message is detected, the second level being higher than the first level.

13. The bad debt risk detection apparatus according to any one of claims 7 to 10, wherein The bad account risk detection device further comprises a management and control processing module, and the management and control processing module comprises an operation detection unit and a management and control processing unit: The operation detection unit is configured to detect a management and control processing operation for a high risk user when a bad account risk detection result of a potential risk user indicates that the potential risk user is a high risk user; The management and control processing unit is configured to perform management and control processing on the high risk user according to the detected management and control processing operation.

14. An electronic device, comprising: Comprise: At least one processor, at least one memory, and at least one communication bus, wherein, The memory has computer readable instructions stored thereon, and the processor reads the computer readable instructions in the memory through the communication bus; The computer readable instructions are executed by the processor to implement the bad account risk detection method of any one of claims 1 to 6.

15. A storage medium having stored thereon a computer program, characterized in that The computer program is executed by the processor to implement the bad account risk detection method of any one of claims 1 to 6.

16. A computer program product, characterised in that, The computer program product comprises computer readable instructions stored in a storage medium; the processor of the computer device reads the computer readable instructions from the storage medium, and the processor executes the computer readable instructions, so that the computer device executes the bad account risk detection method of any one of claims 1 to 6.

Images