Operation activity multi-account cheating identification method and system based on graph propagation

Abstract

The invention provides an operation activity multi-account cheating identification method and system based on graph propagation. The method comprises the steps that a client side collects user behavior data and reports the data, a server side constructs a heterogeneous user relation graph based on the data and gives a cheating risk weight to an edge, the cheating probability is calculated by using a PageRank algorithm based on a seed blacklist user and is subjected to hierarchical disposal, and the client side dynamically adjusts operation activity interaction logic according to a hierarchical result; according to the system, the method is realized through cooperation of the client SDK module, the server graph construction and propagation module, the hierarchical decision module and the client anti-cheating execution module. According to the method, the defects that an existing supervision model is high in labeling cost, large in recognition delay and incapable of achieving front-end real-time intervention are effectively overcome, and the method is scientific, efficient and good in transverse transplantation capacity.

Description

A graph propagation-based method and system for identifying multi-account cheating in operational activities Technical Field

[0001] This invention relates to the field of anti-fraud technology for internet operations, and in particular to a method and system for identifying multi-account fraud in operations based on graph propagation. Background Technology

[0002] The internet industry needs to regularly activate and acquire new users through operational activities, but there are a large number of professional arbitrageurs and black market operators. Current technologies often employ supervised learning models such as the XGBoost algorithm for user anti-fraud identification. However, these models have significant drawbacks: firstly, they rely on a large amount of manually labeled data, leading to high identification costs; secondly, fraud and anti-fraud are adversarial processes, and once black market users change their cheating strategies, the model needs to be retrained for fraud identification. This introduces a delay in identifying new cheating behaviors, making it difficult to respond promptly and effectively to the rapid changes in black market activities, severely impacting the effectiveness of operational activities. Summary of the Invention

[0003] The purpose of this invention is to provide a method and system for identifying multi-account cheating in operational activities based on graph propagation, thereby solving the aforementioned problems existing in the prior art.

[0004] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0005] A method for identifying multi-account fraud in operational activities based on graph propagation includes the following steps:

[0006] a) Collect and report user behavior data in real time on the client side. User behavior data should include at least:

[0007] i) Historical active behavior vector, which is an N-dimensional integer array formed by the daily APP active time of the most recent N days after being separated and discretized in five ways;

[0008] ii) Historical activity participation vector, which is an M-dimensional 0 / 1 array representing whether a user participated in the most recent M operational activities;

[0009] iii) Basic environmental attributes, including at least device UUID, IP address, Wi-Fi BSSID, and LBS geographic location;

[0010] iv) Business attribute behavior, including at least the activity forwarding relationship, withdrawal bank card number, delivery address and mobile phone number;

[0011] b) After cleaning the data obtained in step a), the server constructs a heterogeneous user relationship graph with user accounts as vertices and various relationships as edges. These relationships include:

[0012] Edges are categorized into historically active similar edges, historically active similar edges, edges from the same device, edges from the same Wi-Fi network, edges from the same LBS network, edges that forward activity, edges from the same bank card, and edges from the same delivery address; and each type of edge is assigned a differentiated weight based on the risk of group cheating.

[0013] c) The server uses the confirmed blacklisted accounts as seed vertices and uses the weighted PageRank algorithm to iteratively propagate them on the heterogeneous user relationship graph until the PR values ​​of each vertex converge, thus obtaining the cheating probability of each account.

[0014] d) The server classifies all accounts in the current operation activity into tiers based on the probability of cheating and sends the tiering results to the client. The client dynamically adjusts the winning probability or task visibility of the account in the operation activity based on the tiering results, so as to realize real-time anti-cheating at the front end.

[0015] Preferably, in step b), the differentiated weights are pre-set by expert experience. The edge weights for the same device, the same bank card, and the same delivery address are 10; the edge weights for the same Wi-Fi are 5; the edge weights for the same LBS are 2; the edge weights for the same historical activity / similar activity are 1; and the edge weights for the activity forwarding are 2. When there are multiple relationships between two vertices, the edge weights are accumulated.

[0016] Preferably, in step c), the propagation matrix of the weighted PageRank is obtained by normalizing the outgoing edge weights of the heterogeneous user relationship graph, and the iteration stops when the change in PR value of each vertex is less than 0.000001 in two consecutive rounds; the initial PR value of the seed vertex is 1, and the initial PR value of the other vertices is 0.

[0017] Preferably, the hierarchical processing rule in step d) is:

[0018] Compare all converged PR values ​​with the minimum PR value of the seed vertex. The probability of cheating for accounts with a PR value greater than or equal to the minimum PR value of the seed vertex is standardized to 1. The probability of cheating for other accounts is equal to the PR value of this account / the minimum PR value of the seed vertex.

[0019] The client sets the winning probability of accounts with a cheating probability greater than the first threshold to 0, reduces the winning probability of accounts with a cheating probability between the first and second thresholds by a linear discount factor, and maintains the original winning probability of accounts with a cheating probability lower than the second threshold.

[0020] Preferably, in step a), the historical active behavior vector is calculated and encrypted in real time by the SDK on the client side and reported. The server side truncates and discretizes the abnormal duration before storing it in the database to prevent black market operators from forging continuous high-activity curves.

[0021] Preferably, in step b), the LBS edge is generated using Geohash with an accuracy of 200m. If the Geohash of two accounts is the same during the same activity period, a bidirectional edge is generated to capture geographically clustered groups.

[0022] Preferably, step d) further includes:

[0023] Before the lottery results are displayed, the client asynchronously requests the real-time cheating probability of the account from the server. The server returns a hierarchical identifier in JSON format within 50ms. The client decides whether to display the "Win" or "Thank you for participating" animation based on the hierarchical identifier, achieving a zero-latency anti-cheating experience on the front end.

[0024] Based on the same concept, a graph propagation-based multi-account cheating detection system for operational activities includes:

[0025] The client SDK module is used to collect and encrypt the user behavior data in step a) of claim 1;

[0026] The server-side graph construction module is used to perform step b) of claim 1 to construct a heterogeneous user relationship graph;

[0027] The server-side graph propagation module is used to execute step c) of claim 1 to complete the weighted PageRank iteration and output the cheating probability;

[0028] The server-side hierarchical decision module is used to execute step d) of claim 1 to generate hierarchical results;

[0029] The client-side anti-fraud execution module is used to receive tiered results and adjust the interactive logic of operational activities in real time;

[0030] The system implements the method of any one of claims 1-7 through the collaborative efforts of its various modules.

[0031] Preferably, the server-side graph propagation module adopts a distributed graph computing framework, which supports incremental updates of hundreds of millions of vertices and billions of edges per day, and completes full graph iterative convergence within 3 minutes.

[0032] Preferably, the client-side anti-cheating execution module is embedded in the lottery page as a React / Vue component. When the user clicks the "Draw Now" button, it first calls the locally cached layered identifier. If the cache expires, it initiates an HTTPS short connection request to achieve anti-cheating decision within 100ms and ensure user experience.

[0033] The beneficial effects of this invention are:

[0034] No need for extensive data labeling, strong generalization ability: This invention can perform graph propagation based on a limited seed blacklist of users, and calculate the cheating probability of each user, rather than a simple 0 or 1 judgment. It has strong generalization ability and can adapt to different operational activity scenarios and changes in cheating strategies.

[0035] Multi-relationship graph construction ensures high timeliness of anti-fraud measures: The user relationship network constructed by this invention covers the associations of various business forms, including historical active behavior, historical activity participation behavior, basic environmental attributes, and business behaviors, accurately depicting user relationships from multiple dimensions. Thus, even when a user has just logged into the app, the probability of that user cheating in the current operational activity can be promptly determined based on the existing user relationship network, greatly improving the timeliness of anti-fraud measures. Effective identification and intervention can be carried out in the early stages of fraudulent behavior, reducing losses in operational activities.

[0036] Tiered processing enhances the effectiveness of operational activities: This invention stratifies users based on calculated cheating probabilities, employing different business handling methods for users with varying cheating probabilities. Taking lottery-type operational activities as an example, by setting a formula that multiplies the winning probability by the cheating probability, the winning probability of users is reasonably adjusted. For users with extremely high cheating rates, their winning probability is brought close to zero, effectively isolating them from winning. This not only effectively combats cheating behavior but also avoids excessive interference with the rights of legitimate users. Simultaneously, this tiered processing approach can also serve as a honeypot strategy, inducing cheating users to further expose their behavioral patterns, providing a basis for more precise anti-cheating measures. Therefore, while protecting the rights of legitimate users, it effectively improves the actual effectiveness of operational activities and the rationality of resource allocation, ensuring that rewards are more fairly distributed to the genuine target user group, thereby enhancing the attractiveness and sustainability of operational activities. Attached Figure Description

[0037] Figure 1 is a schematic diagram of the system modules of the present invention;

[0038] Figure 2 is a flowchart of the method of the present invention;

[0039] Figure 3 is a schematic diagram of the user relationship network constructed according to the present invention;

[0040] Figure 4 is a schematic diagram of the graph propagation process of the present invention. Detailed Implementation

[0041] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0042] Referring to Figures 1, 2, 3, and 4, a method for identifying multi-account fraud in operational activities based on graph propagation includes the following steps:

[0043] a) Collect and report user behavior data in real time on the client side. User behavior data should include at least:

[0044] i) Historical active behavior vector, which is an N-dimensional integer array formed by the daily APP active time of the most recent N days after being separated and discretized in five ways;

[0045] ii) Historical activity participation vector, which is an M-dimensional 0 / 1 array representing whether a user participated in the most recent M operational activities;

[0046] iii) Basic environmental attributes, including at least device UUID, IP address, Wi-Fi BSSID, and LBS geographic location;

[0047] iv) Business attribute behavior, including at least the activity forwarding relationship, withdrawal bank card number, delivery address and mobile phone number;

[0048] b) After cleaning the data obtained in step a), the server constructs a heterogeneous user relationship graph with user accounts as vertices and various relationships as edges. These relationships include:

[0049] Edges are categorized into historically active similar edges, historically active similar edges, edges from the same device, edges from the same Wi-Fi network, edges from the same LBS network, edges that forward activity, edges from the same bank card, and edges from the same delivery address; and each type of edge is assigned a differentiated weight based on the risk of group cheating.

[0050] c) The server uses the confirmed blacklisted accounts as seed vertices and uses the weighted PageRank algorithm to iteratively propagate them on the heterogeneous user relationship graph until the PR values ​​of each vertex converge, thus obtaining the cheating probability of each account.

[0051] d) The server classifies all accounts in the current operation activity into tiers based on the probability of cheating and sends the tiering results to the client. The client dynamically adjusts the winning probability or task visibility of the account in the operation activity based on the tiering results, so as to realize real-time anti-cheating at the front end.

[0052] In this embodiment, the above steps are described in detail as follows:

[0053] I. Step a) Client-side data collection and real-time reporting

[0054] Collection timing

[0055] The client immediately calls the embedded SDK's data collection interface whenever key events such as App foreground activity, activity page exposure, or user clicks on "lottery / check-in / withdrawal" are triggered.

[0056] Construction of historical active behavior vectors

[0057] (1) Time window: Take the current date and advance it by N days, with N preferably being 7 to 14 days;

[0058] (2) Raw data: The SDK reads the system API to obtain the daily foreground duration of the App, in seconds;

[0059] (3) Abnormal correction: If the daily front desk duration exceeds 24 h × 3600 s, it is considered an abnormal value and truncated to 24 h × 3600 s;

[0060] (4) Discretization: After arranging the N-day durations in ascending order, divide them into five equal parts to obtain four critical values ​​q1 to q4;

[0061] (5) Vectorization: For each day, if the duration ∈ [0,q1), assign 1; if ∈ [q1,q2), assign 2; if ∈ [q2,q3), assign 3; if ∈ [q3,q4), assign 4; if ∈ [q4,∞], assign 5. Finally, an integer array of length N is formed, denoted as H.

[0062] Historical activity participation vector construction

[0063] (1) Time window: Take the M completed operations before the current date, with M preferably being 5 to 10;

[0064] (2) Participation indicator: If the user account has a "registration" or "prize collection" log in a certain activity, then this position is 1; otherwise, it is 0.

[0065] (3) Arrange them in reverse chronological order to obtain a 0 / 1 array of length M, denoted as P.

[0066] Basic environmental attribute collection

[0067] (1) Device UUID: First, read the VendorID / AdvertisingID provided by the system. If it cannot be obtained, generate a random UUID and persist it in KeyStore;

[0068] (2) IP address: Obtain the current egress IPv4 / IPv6 through DNS resolution;

[0069] (3) Wi-Fi BSSID: Read SSID and BSSID when connected to Wi-Fi. If not connected, record empty.

[0070] (4) LBS geographic location: After obtaining user authorization, read the latitude and longitude returned by the system location service, retain 6 decimal places, with an accuracy of about 0.1 m;

[0071] (5) Timestamp: All attributes carry a millisecond-level timestamp for subsequent timeliness verification.

[0072] Business attribute behavior collection

[0073] (1) Activity forwarding relationship: Record the log of user A sharing the activity page to an external platform, and the recipient B enters the activity through the shared link, forming a directed edge A→B;

[0074] (2) Withdrawal bank card number: Only the last 6 digits of the bank BIN and the hash value are collected. The complete card number is masked on the client side.

[0075] (3) Delivery address: Create strings for province, city, district, and street, and generate standard address codes;

[0076] (4) Mobile phone number: Only the first three and last four digits are retained, and the middle part is filled with *. An irreversible hash is generated at the same time.

[0077] Data Packaging and Reporting

[0078] The above four types of data are first serialized into JSON on the client side, and then encrypted using AES-256-GCM. The key is a one-time session key obtained through ECDHE negotiation. After encryption, the data is sent to the specified interface on the server via HTTPS / TLS1.3 connection. The interface returns 200 OK, which is considered a success and the data is immediately deleted from the local queue. Otherwise, the data will be backed up and retried up to 3 times.

[0079] II. Step b) Server-side data cleaning and heterogeneous graph construction

[0080] Data cleaning

[0081] (1) Timeliness verification: Discard data packets whose timestamps differ from the server's current time by more than 5 minutes to prevent replay;

[0082] (2) Outlier filtering: Elements in vector H that are greater than 5 or less than 1, and non-zero / 1 elements in vector P are directly discarded;

[0083] (3) IP location verification: Use the IP database to compare whether the IP and LBS latitude and longitude are in the same city. If the difference exceeds 200 km, it is marked as suspicious and the subsequent edge weight is halved.

[0084] (4) Address standardization: Call the address resolution service to convert free text addresses into standard administrative division codes.

[0085] Vertex creation

[0086] Each user account corresponds to a unique vertex, and the vertex attributes store the latest H and P vectors and the most recent environment attributes. If the account already exists, only the attribute values ​​are updated and the version number is recorded.

[0087] Edge relation definition and weight assignment

[0088] (1) Historically active similar edges: Calculate the cosine similarity of the H vectors of the two accounts. If the result is ≥0.95, then establish an undirected edge with a weight of 1.

[0089] (2) Historical activity similarity edge: Calculate the cosine similarity of the P vectors of the two accounts. If the result is ≥0.95, then establish an undirected edge with a weight of 1.

[0090] (3) Edges on the same device: If two vertices have the same UUID, a bidirectional edge is established with a weight of 10;

[0091] (4) Same Wi-Fi edge: If the BSSIDs of the two vertices are equal, a bidirectional edge is established with a weight of 5;

[0092] (5) Same as LBS edge: The latitude and longitude are accurate to 200 m via Geohash. If the Geohash strings are equal, a bidirectional edge is established with a weight of 2.

[0093] (6) Activity forwarding edge: If there is a sharing entry record of A→B in the log, then establish a directed edge of A→B with weight=2; at the same time, establish a reverse "forwarded" edge of B→A with weight=2;

[0094] (7) Same as bank card edge: If the hash values ​​are equal, a bidirectional edge is established with a weight of 10;

[0095] (8) Edge with the same delivery address: If the standard address codes are equal, a bidirectional edge is established with a weight of 10;

[0096] If any two vertices satisfy multiple edges simultaneously, then the weights are accumulated to form a composite edge.

[0097] Graph storage and indexing

[0098] An attribute graph model is used, with the account string as the primary index for vertices; each edge has a bidirectional adjacency index, storing its weight and update time. The graph database supports distributed sharding, and the in-memory index for each shard uses a CSR structure to ensure sequential access during subsequent iterations.

[0099] III. Step c) Weighted PageRank Iterative Propagation

[0100] Seed vertex settings

[0101] Accounts that have been manually verified by operations, risk control, and customer service will be added to the "seed blacklist" with an initial PR value of 1, while the initial PR value of the remaining vertices will be set to 0.

[0102] Construction of propagation matrix

[0103] The weights of outgoing edges from each vertex in the graph are summed to obtain W_out. If W_out = 0, it is considered a dangling node, and its weight is evenly distributed among all vertices in the graph. Define the transition probability matrix element P_ij = w_ij / W_out_j, where w_ij is the weight of edge j→i.

[0104] Damping coefficient selection

[0105] A damping coefficient d, preferably 0.85, is introduced to simulate random jumps. The iterative formula is as follows:

[0106] PR_i(t+1) = (1–d) / N + d · Σ_j PR_j(t) · P_ij

[0107] Where N is the total number of vertices and t is the number of iterations.

[0108] Convergence conditions

[0109] Set the maximum number of iterations T_max = 100, and terminate when all vertices |PR(t+1) – PR(t)| < ε, with ε preferably 1 × 10^-6. If convergence is not achieved by T_max, force termination and record an alarm.

[0110] Normalization of cheating probability

[0111] Take the minimum value of the final PR of all seed vertices as the base PR_base. For any vertex i, the cheating probability is...

[0112] P_cheat_i = min(1, PR_i / PR_base).

[0113] This ensures that at least one account in the seed group has a cheating probability of 1, while the probabilities of other accounts monotonically increase between 0 and 1.

[0114] IV. Step d) Layered processing and real-time front-end anti-cheating

[0115] Layered strategy

[0116] Three threshold values, α and β, are set for high, medium, and low levels, with α=0.8 and β=0.4 being preferred.

[0117] High risk: P_cheat ≥ α

[0118] Medium risk: β ≤ P_cheat < α

[0119] Low risk: P_cheat < β

[0120] The tiered results, along with the expiration time (preferably 60 seconds), are written to Redis. The key is the account, and the value is the risk tier and P_cheat.

[0121] Distribution and Inquiry

[0122] Before the campaign page loads or the user clicks the "Lottery" button, the client requests the risk control interface via an HTTPS short connection, carrying the account token. The interface directly queries Redis through the API gateway, with a target response time of ≤50 ms. If Redis is unavailable, a real-time graph query is triggered, but the interface timeout is guaranteed to be ≤200 ms; if it times out, a medium-risk response is returned by default.

[0123] Front-end dynamic adjustment

[0124] (1) Adjustment of winning probability: For lottery-type activities, the standard winning probability is denoted as P_std, then the actual winning probability is...

[0125] P_actual=P_std×(1–P_cheat);

[0126] When P_cheat ≥ 0.95, P_actual is directly set to 0 to achieve "winning isolation".

[0127] (2) Task visibility control: For task reward activities, high-risk users directly hide the high-value task entry and only show low-value tasks; medium-risk users add SMS or graphic verification codes; low-risk users maintain the original experience.

[0128] (3) Honeypot strategy: High-risk users can still see the lottery button, but the probability of it has been set to 0 in the background, in order to delay the black market's perception time and record further behavior logs.

[0129] Results Feedback and Closed Loop

[0130] The client sends the end-user behavior (whether they won a prize or completed a task) back to the server to calculate the false positive rate and the false negative rate. It also performs periodic manual checks to compensate falsely identified accounts with a whitelist and to add newly added cheating accounts to the seed blacklist, thus achieving the rolling update of the graph propagation model.

[0131] Through the above four steps, this invention completes the entire closed loop of "collection → mapping → dissemination → layering → real-time front-end intervention" without relying on large-scale annotation, significantly reducing the risk of operational activities being exploited by a large number of accounts, while ensuring the experience and reward fairness of normal users.

[0132] Furthermore, in step c), before the weighted PageRank iteration, "edge weight time decay" is first performed on the heterogeneous user relationship graph. Based on the last update time of each edge, the old edge weights are dynamically reduced according to the exponential decay function w(t)=w0·e^(−λt), where λ∈[0.05,0.2] (days⁻¹), and t is the number of days since the current date. The total outgoing edge weights after decay are renormalized before entering PageRank calculation. Thus, without retraining the model, the historical clustering relationships naturally weaken over time, significantly improving the timeliness of identifying black market activities such as "silent attacks after account nurturing".

[0133] In step d), after receiving a high-risk tier, the client does not immediately block the lottery. Instead, it activates a "probability ladder honeypot" mechanism—the front end still displays the normal spinning wheel animation, but the back end sets the actual winning probability to zero and continues to record the user's subsequent behavior. At the same time, the real-time behavior of the high-risk account is sent back to the server and used as a "soft seed" vertex in the next round of graph propagation, with an initial PR of 0.5. This achieves a closed-loop amplification of "first identification → honeypot verification → second reinforcement propagation," effectively expanding the coverage of the blacklist.

[0134] In step b), when constructing the heterogeneous graph, a "spatial-temporal co-occurrence check" is added to edges of the same device, the same Wi-Fi, and the same LBS. Only when two edges appear simultaneously within a time window Δt≤30 min are they merged into a "high-confidence composite edge", and its weight is calculated as w=10×(1+ln(30 / Δt)), where Δt is in minutes. If Δt>30 min, the original weight remains unchanged. This dynamic weighting method uses short-term co-occurrence to significantly increase the weight of the edge where the group gathers, so that the cheating group obtains a higher propagation priority in the early stage of PageRank iteration, further reducing the false alarm rate.

[0135] Preferably, in step b), the differentiated weights are pre-set by expert experience. The edge weights for the same device, the same bank card, and the same delivery address are 10; the edge weights for the same Wi-Fi are 5; the edge weights for the same LBS are 2; the edge weights for the same historical activity / similar activity are 1; and the edge weights for the activity forwarding are 2. When there are multiple relationships between two vertices, the edge weights are accumulated.

[0136] Preferably, in step c), the propagation matrix of the weighted PageRank is obtained by normalizing the outgoing edge weights of the heterogeneous user relationship graph, and the iteration stops when the change in PR value of each vertex is less than 0.000001 in two consecutive rounds; the initial PR value of the seed vertex is 1, and the initial PR value of the other vertices is 0.

[0137] In this embodiment, the first step is to set differentiated weights and accumulate composite edges.

[0138] Weighted grading approach

[0139] Using "whether it can directly target the same natural person" as the primary metric, and "the concentration of large-scale black market operations" as a secondary metric, the following optimal weighting values ​​were formed based on years of risk control case statistics and expert experience:

[0140] Same device, same bank card, same delivery address: weight = 10;

[0141] Same as Wi-Fi (same BSSID): Weight = 5;

[0142] Similar LBS (same as Geohash-7, approximately 200 m × 200 m): Weight = 2;

[0143] Historical similarity (cosine similarity ≥ 0.95): weight = 1;

[0144] Historical activity participation similarity (cosine similarity ≥ 0.95): weight = 1;

[0145] Activity forwarding (there is a sharing-entry chain from A to B): weight = 2.

[0146] Composite edge weight accumulation rule

[0147] If any two vertices simultaneously satisfy multiple of the above relationships, their corresponding weights are algebraically added together to form a "composite edge". For example, if account A and account B are on the same device and the same Wi-Fi network and have a forwarding relationship, then the edge weight w_AB = 10 + 5 + 2 = 17. This accumulation method can significantly amplify the propagation capability of high-confidence associations without increasing the size of the graph vertices, allowing the cluster to be "contaminated" more quickly in subsequent iterations.

[0148] Weight hot update mechanism

[0149] The aforementioned weights are encapsulated into an "edge weight strategy table" in the configuration center. Operators can adjust the weights of any relationship in real time in the web console. After adjustment, the weights are pushed to the graph building engine via a long connection within 30 seconds. Newly written or updated edges take effect immediately without restarting the service, ensuring that the adversarial process can be dynamically upgraded.

[0150] II. Construction and Normalization of Propagation Matrix

[0151] Seeking a balance on the outbound side

[0152] For each vertex v in the heterogeneous user relationship graph, calculate the sum of all its outgoing edge weights W_out(v) = Σ_uw(v→u), where w(v→u) represents the composite edge weight from vertex v to vertex u. If a vertex has no outgoing edges (dangling vertex), then its outgoing edge weights are evenly distributed among all vertices in the graph according to the standard PageRank approach, which is equivalent to adding a virtual self-loop with a weight of 1 to ensure random matrix rows.

[0153] Transition probability calculation

[0154] Define the elements of the transition probability matrix

[0155] P_uv = w(v→u) / W_out(v)

[0156] The matrix has a column sum of 1, which satisfies the column randomness property and can be directly used for power iteration.

[0157] III. Weighted PageRank Iteration Details

[0158] Damping coefficient and random jump

[0159] A damping coefficient d is introduced, preferably 0.85, representing the probability that the user will continue browsing along the edge; 1–d = 0.15 represents the probability of a random jump. The iterative formula is as follows:

[0160] PR_i(t+1) = (1–d) / N + d·Σ_j PR_j(t)·P_ij

[0161] Where N is the total number of vertices, t is the iteration number, and PR_i(t) is the PageRank value of vertex i in the tth round.

[0162] Seed vertex initialization

[0163] Let S be the set of vertices corresponding to all confirmed blacklisted accounts. For ∀i∈S, let PR_i(0) = 1, and for ∀k∉S, let PR_k(0) = 0. This "single-source" initialization method ensures that all contamination signals flow out of the blacklist only during the first round of propagation, and gradually spread to adjacent vertices through edge weights in subsequent rounds, which conforms to the assumption of "one is influenced by one's surroundings".

[0164] Convergence criterion

[0165] Set the L1-norm difference threshold ε = 0.000001. Calculate after each iteration.

[0166] Δ(t)=Σ_i|PR_i(t)–PR_i(t–1)|

[0167] If Δ(t) < ε, convergence is determined and iteration stops; otherwise, the next round continues. A hard upper limit T_max = 100 rounds is set to prevent infinite iterations caused by extreme graph structures.

[0168] Incremental iterative optimization (optional)

[0169] When only local edge weight updates occur in the graph database, the PR vector from the previous round can be reused as the initial value to perform "incremental iteration" on the affected vertices and their 2-hop neighborhoods. It has been verified that in scenarios with tens of millions of vertices, the computation time can be reduced to less than 30% of the full-scale mode, and the PR value error is <1×10^-5, which meets the production accuracy requirements.

[0170] IV. Normalization of cheating probability

[0171] After convergence, the minimum PR value in the seed vertex set is taken as the baseline PR_base = min{PR_i | i∈S}. For any vertex k, its cheating probability...

[0172] P_cheat_k = min(1, PR_k / PR_base)

[0173] This normalization ensures that:

[0174] All seed accounts have at least one cheating probability of 1, maintaining the "full confidence" characteristic of the blacklist;

[0175] The probability of non-seed accounts is linearly correlated with PR value, which facilitates subsequent stratified processing.

[0176] V. Effect Verification

[0177] Through testing on a real production graph with 1 billion edges, the average number of convergence rounds under the above parameter settings was 37, with a single round taking 18 seconds (100 instances with 16 cores). The normalized cheating probability and the accuracy of subsequent manual review reached 92.7%, and the recall rate was 89.4%, meeting the real-time anti-cheating requirements of operational activities.

[0178] Preferably, the hierarchical processing rule in step d) is:

[0179] Compare all converged PR values ​​with the minimum PR value of the seed vertex. The probability of cheating for accounts with a PR value greater than or equal to the minimum PR value of the seed vertex is standardized to 1. The probability of cheating for other accounts is equal to the PR value of this account / the minimum PR value of the seed vertex.

[0180] The client sets the winning probability of accounts with a cheating probability greater than the first threshold to 0, reduces the winning probability of accounts with a cheating probability between the first and second thresholds by a linear discount factor, and maintains the original winning probability of accounts with a cheating probability lower than the second threshold.

[0181] Preferably, in step a), the historical active behavior vector is calculated and encrypted in real time by the SDK on the client side and reported. The server side truncates and discretizes the abnormal duration before storing it in the database to prevent black market operators from forging continuous high-activity curves.

[0182] Preferably, in step b), the LBS edge is generated using Geohash with an accuracy of 200m. If the Geohash of two accounts is the same during the same activity period, a bidirectional edge is generated to capture geographically clustered groups.

[0183] Preferably, step d) further includes:

[0184] Before the lottery results are displayed, the client asynchronously requests the real-time cheating probability of the account from the server. The server returns a hierarchical identifier in JSON format within 50ms. The client decides whether to display the "Win" or "Thank you for participating" animation based on the hierarchical identifier, achieving a zero-latency anti-cheating experience on the front end.

[0185] In this embodiment, I. Detailed Explanation of Layered Processing Rules

[0186] PR value normalization

[0187] After the iteration converges, perform the following for each account i:

[0188] P_cheat(i) = PR(i) / PR_base

[0189] Where PR_base is the minimum PR value among all blacklisted vertices in the seed population. If PR(i) ≥ PR_base, then P_cheat(i) is set to 1, ensuring that there is at least one full confidence sample in the seed population, and the remaining accounts are mapped to the interval [0,1] in a linear proportion.

[0190] Dual threshold settings

[0191] The first threshold (high-risk line) is preferably 0.8, and the second threshold (low-risk line) is preferably 0.4, forming three levels:

[0192] High risk: P_cheat ≥ 0.8

[0193] Medium risk: 0.4 ≤ P_cheat < 0.8

[0194] Low risk: P_cheat < 0.4

[0195] The two thresholds are stored in the configuration center, allowing operations to dynamically adjust them within 30 seconds and make them effective in real time.

[0196] Formula for adjusting winning probability

[0197] Let the original winning probability of the promotional activity be P_std, then the actual winning probability is P_actual:

[0198] High-risk level: P_actual = 0 (complete insulation)

[0199] Medium risk level: P_actual = P_std × (1 − P_cheat) (linear discount)

[0200] Low-risk level: P_actual = P_std (remain unchanged)

[0201] Linear discounts ensure that medium-risk users still have a chance to receive rewards, but expected returns decrease monotonically as the probability of cheating increases, reducing the incentive for black market operators to continue investing.

[0202] Task visibility synchronization control

[0203] For non-lottery tasks such as "earn points by checking in" and "earn coupons by browsing," the client reads the data points before the page is rendered.

[0204] High-risk tasks hide the entry points for high-value tasks, only displaying low-value tasks;

[0205] Medium-risk areas will retain entry points but will add SMS or graphic verification codes;

[0206] Fully open with low risk.

[0207] The entry point is hidden through conditional rendering of front-end components, avoiding additional network requests.

[0208] II. Anti-forgery processing of historical active behavior vectors

[0209] Client-side computation process

[0210] The SDK calculates the number of seconds the App remained in the foreground on the previous day at midnight every day, and immediately performs five-level separation and decomposition. The results are stored only in memory variables and not written to local files to prevent tampering.

[0211] Abnormal duration truncation

[0212] If the daily front-end duration is ≥ 24 h × 3600 s, it will be forcibly truncated to 24 h × 3600 s; data packets exceeding 48 h will be directly discarded to prevent "time dilation" attacks.

[0213] Encryption and Integrity Verification

[0214] The discrete 7-dimensional integer array is serialized into JSON and then encrypted using AES-256-GCM. The key is a one-time symmetric key negotiated through an ECDHE session. A 16-byte MAC is appended to ensure that the transmission process is non-replayable and non-tamperable.

[0215] Server-side secondary discretization

[0216] After receiving the array, the server truncates the elements with a duration of more than 24 hours in a single day and re-executes the five-part division logic. The results are then cross-validated with the client's results. If the inconsistency rate exceeds 5%, a risk control alarm is triggered to prevent black market operators from increasing the similarity by forging continuous high-activity curves.

[0217] III. 200 m Grid Strategy with the Same LBS Edge

[0218] Geohash Precision Selection

[0219] Using 7-bit Geohash, the theoretical grid size is approximately 152 m × 152 m, which meets the requirement of "within 200 m"; accounts within the same grid are considered to co-occur in geolocation.

[0220] Time window co-occurrence check

[0221] Bidirectional edges are only generated when two accounts fall into the same Geohash grid during the same activity period (default ±30 min) to prevent normal users who live in the same community for a long time from being overly associated.

[0222] Mesh roaming filter

[0223] If an account switches between more than 3 grids within 30 minutes and the distance between grid center points is greater than 1km, it is judged as being in a "roaming" state and will no longer participate in LBS edge generation that day, in order to prevent black market operators from creating false clusters by rapidly jumping around using virtual locations.

[0224] IV. Zero-latency anti-cheating experience on the front end

[0225] Asynchronous prefetch

[0226] The client immediately initiates a backend HTTP / 2 request when the activity page's onResume event is completed, carrying the account token and activity ID, with the request header appended with Accept: application / json, and expects the following fields to be returned: {"level":"high|mid|low","pcheat":0.xx}.

[0227] Server-side 50ms guarantee

[0228] The API gateway layer uses a local memory cache (Caffeine) to store the results of the most recent 100,000 accounts, with a hit rate of >95%.

[0229] When a cache miss occurs, the locator hash is directly retrieved from the pre-established Redis connection pool, with a single RTT of <5 ms;

[0230] If Redis still has no data, a real-time graph query is triggered (only the 1-hop neighborhood PR value of this account is retrieved and normalized), with the query time controlled within 30 ms;

[0231] The overall P99 response time is ≤50 ms. If the timeout occurs, the system will default to the medium-risk level to ensure a good front-end experience.

[0232] Animation and Results Display

[0233] After the client receives the response:

[0234] High: The wheel continues to spin, but the result is predetermined as "Thank you for participating," and the corresponding text is displayed after the animation ends;

[0235] mid: Normal rotation, the backend draws the prize according to the discounted probability, and if you do not win, it will still display "Thank you for participating";

[0236] low: Follows the original probability exactly, displays "Congratulations on winning" and guides the player to claim the prize when they win.

[0237] Guarantee of consistent experience

[0238] To avoid animation stuttering caused by network jitter, the client uses a placeholder animation to delay for 100 ms before the request returns. If no response is received within 100 ms, the placeholder continues until the desired position is obtained before rendering the actual result, ensuring that the user does not perceive any extra waiting.

[0239] Through the above detailed measures, this invention achieves multiple blocking mechanisms, including front-end zero-awareness anti-cheating, back-end high concurrency and low latency, and black market forgery paths, while maintaining the accuracy of normalized cheating probability.

[0240] Based on the same concept, a graph propagation-based multi-account cheating detection system for operational activities includes:

[0241] The client SDK module is used to collect and encrypt the user behavior data in step a) of claim 1;

[0242] The server-side graph construction module is used to perform step b) of claim 1 to construct a heterogeneous user relationship graph;

[0243] The server-side graph propagation module is used to execute step c) of claim 1 to complete the weighted PageRank iteration and output the cheating probability;

[0244] The server-side hierarchical decision module is used to execute step d) of claim 1 to generate hierarchical results;

[0245] The client-side anti-fraud execution module is used to receive tiered results and adjust the interactive logic of operational activities in real time;

[0246] The system implements the method of any one of claims 1-7 through the collaborative efforts of its various modules.

[0247] Preferably, the server-side graph propagation module adopts a distributed graph computing framework, which supports incremental updates of hundreds of millions of vertices and billions of edges per day, and completes full graph iterative convergence within 3 minutes.

[0248] Preferably, the client-side anti-cheating execution module is embedded in the lottery page as a React / Vue component. When the user clicks the "Draw Now" button, it first calls the locally cached layered identifier. If the cache expires, it initiates an HTTPS short connection request to achieve anti-cheating decision within 100ms and ensure user experience.

[0249] I. Overall Architecture and Module Division

[0250] The system consists of five modules, each deployed on a regular Linux server or container cluster. They interact through standard network protocols to form a closed loop of "collection → mapping → propagation → layering → front-end intervention".

[0251] Client SDK module

[0252] Embedded in the App and H5 page, responsible for collecting the behavioral data listed in step a) of claim 1 without the user's awareness;

[0253] After the data is vectorized and discretized in memory, it is immediately encrypted using AES-256-GCM. The key is negotiated once through ECDHE to prevent man-in-the-middle forgery.

[0254] Encrypted packets are added to a local circular queue with a maximum length of 200 packets. If the queue exceeds the limit, the oldest packet is discarded to ensure that memory usage is less than 5MB.

[0255] The reporting timing adopts a dual-trigger strategy of "application switching to the background + Wi-Fi availability", which saves power and avoids sudden increases in cellular network traffic.

[0256] Server-side graph construction module

[0257] On the consumer side, Kafka-Partition-Key is used to distribute data by account hash, ensuring that all actions of the same account fall into the same partition and achieve sequential processing.

[0258] The cleaning submodule performs real-time rule filtering on abnormal duration, abnormal IP, and virtual location drift, and the filtered edge records are immediately written to the graph database.

[0259] The graph database uses an engine that supports attribute graphs and distributed storage. The vertex primary key is the account string, and the edge stores a 5-tuple of source account, target account, relation type, composite weight, and last update time.

[0260] To support hot updates of weights, edge weights are not fixed when written, but are dynamically associated with the latest weights when read, using "relationship type + configuration version number" as a foreign key, thus achieving second-level policy changes.

[0261] Server-side graph propagation module

[0262] It adopts a distributed graph computing framework, with vertex cutting mode storage and edge information stored physically contiguously, which satisfies the requirements of sequential scan friendliness;

[0263] New edges and edges with weight changes are first entered into the "incremental edge set". The system compares the snapshot of the previous day and only recalculates the PR of the affected vertices and their two-hop neighborhoods. The PR values ​​of the remaining vertices are directly reused.

[0264] The iterative process uses a damping coefficient of 0.85 and a convergence threshold of 1×10⁻. 6 The maximum number of rounds is 100; in a production environment with 10 billion edges, the first iteration of the entire graph takes about 170 seconds, and subsequent incremental iterations take an average of 180 seconds, with the overall update completed within 3 minutes.

[0265] The calculation results are written in batches to the distributed key-value store in the form of "account-PR value-cheating probability" triples, and a CRC check file is generated simultaneously to prevent bit flipping during transmission.

[0266] Server-side layered decision-making module

[0267] After reading the PR value from the KV storage, P_cheat is obtained according to the normalization formula, and then compared with the double threshold to generate three levels: high, medium and low.

[0268] The module has a built-in "grayscale whitelist" interface, which allows operators to manually reset the whitelist of mistakenly deleted accounts to zero. The whitelisting record is synchronized to the key value (KV) in real time and takes effect within 30 seconds.

[0269] The tiered results are written to a global multi-replica Redis instance, with a single record TTL of 60 seconds, ensuring real-time read access from the front end while avoiding the retention of outdated data.

[0270] Client-side anti-cheating execution module

[0271] The lottery page is embedded as a React / Vue component, and the component pre-fetches the layered results during the mount phase.

[0272] The local cache uses an LRU strategy with a maximum capacity of 1000 entries. The cache key is "account + activity ID", and the cache duration is 45 seconds to avoid duplicate requests.

[0273] When a user clicks "Draw Now," the component prioritizes reading from the local cache.

[0274] – If the cache is hit and has not expired, the gear selection will be completed within 100 milliseconds.

[0275] – If the cache is missing or expired, the server is requested via an HTTP / 2 short connection. The server-side link layer enables local memory caching + Caffeine, with a hit rate of >95%, P99 response time ≤50 milliseconds, and overall decision-making time is stable within 100 milliseconds.

[0276] After the tier is determined, the front end continues to display the spinning wheel animation, but the back end has already executed the lottery draw with different probabilities:

[0277] High risk: The animation will inevitably end with "Thank you for participating";

[0278] Medium risk: The draw is based on a discounted probability; if you don't win, you'll still receive a "Thank you for participating" message.

[0279] Low risk: The lottery will be drawn normally according to the original probability.

[0280] A random delay of 80-120 milliseconds is inserted between the animation and the result display to ensure that users cannot deduce the gear level from the time difference, further enhancing the strategy's concealment.

[0281] II. Incremental Updates and Performance Guarantees

[0282] During the early morning off-peak period each day, the system first completes a full snapshot backup, and then starts incremental edge detection. Incremental detection only scans new logs with "behavior time ≥ previous snapshot time", and the scanning range can be accurate to the hour level, avoiding full table scanning.

[0283] The graph propagation task is divided into thousands of partitions, each running in an independent container. Failed tasks are automatically retried three times by the scheduler, and if they still fail, manual intervention is required to ensure convergence within 3 minutes.

[0284] To prevent sudden traffic surges from overwhelming the API, the API gateway layer is configured with token bucket rate limiting: a maximum of 10 requests per account per second and a maximum of 200 requests per IP per second. Requests exceeding the limits will return a 429 status code, and the front-end component will automatically downgrade the request to "medium risk" to ensure uninterrupted user experience.

[0285] Through the above system modules and processes, this invention can still complete the full graph iteration within 3 minutes and complete the anti-cheating decision within 100 milliseconds on the front end, even with a scale of hundreds of millions of vertices and billions of edges per day, thus achieving the closed-loop goal of "real-time identification - real-time intervention - seamless user experience" in operational activities.

[0286] In another embodiment, Figure 1 shows five logical partitions from top to bottom: "client side - access layer - computing layer - data layer - control layer".

[0287] ① The client SDK module and the anti-fraud execution module are placed side by side on the client side: the SDK is responsible for collecting the historical activity vector, activity participation vector, environmental attributes, and business behavior mentioned in step a) and encrypting and reporting them; the anti-fraud execution module corresponds to the React / Vue component of claim 10, is embedded in the lottery page, and realizes the tier decision within 100ms.

[0288] ②The API gateway and Kafka form the access layer: After the gateway completes authentication and rate limiting, it delivers the logs to Kafka, realizing the "real-time reporting" in step a) of claim 1 and the above-mentioned "billion-level concurrency" buffer.

[0289] ③ The computation layer consists of Flink cleaning, graph building engine, graph propagation engine and hierarchical decision engine: corresponding to the “server-side graph building module”, “server-side graph propagation module” and “server-side hierarchical decision module” of claim 8, respectively, and completes all computation logic in steps b)-d).

[0290] ④ JanusGraph, HDFS, and Redis constitute the data layer: JanusGraph stores heterogeneous graphs, HDFS stores PR snapshots, and Redis provides 50 ms caching, which together support the above-mentioned timeliness requirements of "3-minute full graph iteration" and "50 ms return".

[0291] ⑤ The configuration center and monitoring alarms constitute the control layer: the edge weight table and threshold table are hot-updated to the graph construction and layering module to realize the above-mentioned "differentiated weights" and "dual threshold layering" dynamic adjustment; the monitoring link ensures that the iteration task will automatically retry if it fails, and guarantees the 3-minute convergence commitment.

[0292] Figure 2 shows the five main steps from left to right in the flowchart.

[0293] ① The “Client collects multi-dimensional behavioral data” box corresponds to sub-items i)-iv) of step a): historical active vector five-equal separation, activity participation 0 / 1 array, device UUID / IP / BSSID / LBS, forwarding / bank card / address / mobile number.

[0294] ② The “Server-side cleaning - building heterogeneous graph” box corresponds to step b): After Flink completes the abnormal duration truncation, Geohash-200m meshing, and address standardization, it writes the data into JanusGraph, and the edge weights are accumulated according to claim 2.

[0295] ③ The box for “Seed Blacklist + Weighted PageRank Iteration” corresponds to step c): Only 68,000 seeds have an initial PR of 1, the rest have 0, the damping is 0.85, and ΔPR < 10⁻ 6 That is, convergence, producing the PR value of the entire image.

[0296] ④ The box “PR normalization → high / medium / low three levels” corresponds to the first half of step d): PR_base takes the minimum seed PR, P_cheat=PR / PR_base, and then the layers are divided according to the double threshold of 0.8 / 0.4.

[0297] ⑤ The “Decision within 100 ms in the front end” box corresponds to the second half of step d): The React component pre-fetches the tier, caches it locally for 45 seconds, and immediately adjusts the winning probability or task visibility according to the tier when clicking to draw a prize, achieving a “zero-latency” anti-cheating experience.

[0298] Figure 3 uses five account vertices as an example to visually demonstrate the cumulative effect of the weights of the eight types of edges described in step b) above.

[0299] ① Connect AB to the same device side (10): This reflects the high-risk scenario of "one machine with multiple numbers", with a weight of 10.

[0300] ②The forwarding edge (2)A→C and the forwarded edge (2)C→A form a bidirectional 2-weight relationship, recording the relationship between new users.

[0301] ③ Same as Wi-Fi (5)BC: Capture shared networks in home or studio.

[0302] ④ Similar active edges (1) CD: build an edge if cosine ≥ 0.95, weight 1.

[0303] ⑤ Same as LBS edge (2)CD: Geohash-7 and time period overlap, weight 2.

[0304] ⑥ Same bank card edge (10)DE: Reflects the aggregation of "same payee", right 10.

[0305] Example of a composite edge: If C and D simultaneously satisfy the conditions of similar activity and the same LBS, then the edge weight = 1 + 2 = 3, which is indicated by a single line labeled "Weight 3" in the diagram. This graph directly supports the aforementioned "200m Geohash bidirectional edge" and the aforementioned "weight accumulation" technical features.

[0306] Figure 4 uses three columns to show the numerical changes from "Initial PR → First Round → Convergence Result", which vividly explains the normalization logic mentioned above.

[0307] ① Initial column: Only seed vertex 1 has PR=1, the rest are 0, corresponding to the starting point of "single source pollution".

[0308] ② First round column: PR value flows quickly to vertex 3 along the high weight edge (weight 12), and slowly to vertex 2 along the weight 1 edge, reflecting "the larger the weight, the faster the pollution".

[0309] ③ Convergence Column: After the PR value stabilizes, the minimum seed PR = 0.25 is taken as PR_base, and normalized to obtain P_cheat: Vertices 1 and 3 ≥ PR_base → probability 1; Vertices 2, 4, and 5 are proportionally converted to 84.6%, 23.1%, and 7.7%, respectively. This column directly maps to the "PR / PR_base standardization" and "high, medium, and low three-tier" hierarchical rules of claim 4, allowing examiners to intuitively see the final effect of "high-risk insulation, medium-risk discount, and low-risk retention".

[0310] Example: Anti-cheating practice in the Autohome "818 100 Cities Auto Show" lucky draw event

[0311] Event Background

[0312] In August 2023, Autohome launched the "818 100-City Auto Show" online lucky draw simultaneously in 100 cities across China, with a prize pool including one-year usage rights to 100 cars and 10 million yuan in cash prizes. The event lasted for 10 days, with an average daily page view of 230 million and approximately 28 million participating accounts. The platform needed to identify and dynamically reduce the probability of winning in bulk during peak traffic while ensuring a smooth experience for normal users.

[0313] System Deployment

[0314] Client-side: App 11.8.0 includes this patented SDK, covering both iOS and Android platforms;

[0315] Access layer: The API gateway uses 80 instances of 32-core, 128GB containers, with a rate limiting threshold of 10 qps per account;

[0316] Message queue: Kafka 100 Partitions, peak throughput 1.2 million messages / second;

[0317] Graph storage: JanusGraph+HBase cluster, with a total of 240 nodes and 4 GB of memory per shard;

[0318] Graph propagation: Spark GraphX ​​on Yarn, 500 Executors, 4 cores and 8 GB per Executor;

[0319] Caching: Global multi-replica Redis 60 nodes, single shard read QPS of 50,000, P99 latency of 8 ms.

[0320] Data Acquisition and Mapping

[0321] During the off-peak period from 0:00 to 2:00 on the first day of the event, the system retrieved historical data from the past 7 days to complete the initial graph construction.

[0322] Peak: 26 million accounts;

[0323] Edges: 110 million edges on the same device, 80 million edges on the same Wi-Fi, 150 million edges on the same LBS, 90 million similar active edges, 60 million similar activity edges, 30 million forwarding chains, and a total of 420 million edges after weighting the composite edges.

[0324] Seed Blacklist: Imported 68,000 cheating accounts verified from January to July 2023, with an initial PR of 1.

[0325] Graph Propagation and Stratification

[0326] First full iteration: took 167 seconds, converged in 39 rounds, ΔPR < 10⁻ 6 ;

[0327] Incremental update: Subsequent daily updates will process new behaviors added the previous day at midnight, with an average of 9 million incremental edges and an incremental iteration time of 142 seconds.

[0328] Normalization: Taking the seed minimum PR=0.182, the probability of cheating for all accounts is distributed between 0 and 1;

[0329] Layering: High ≥ 0.8, Medium 0.4-0.8, Low < 0.4. The results are written to Redis with a TTL of 60 seconds.

[0330] Real-time intervention at the front end

[0331] Component pre-fetch: The gear query is triggered when the user enters the activity page, and the local cache is cached for 45 seconds;

[0332] When clicking "Lottery", if the local cache is valid, the decision is completed within 100 milliseconds; if the cache is invalid, HTTPS / 2 is used, the server-side Redis cache hit rate is 97%, and the P99 response time is 42 milliseconds.

[0333] Adjustment of winning probability:

[0334] High-risk accounts (21,000): P_actual=0, all marked "Thank you for participating";

[0335] Medium-risk accounts (4.2 million): Discounted according to P_actual=P_std×(1-P_cheat), with an average discount rate of 0.37;

[0336] 23.78 million low-risk accounts: maintain the original probability.

[0337] Results data

[0338] During the 10-day event, the amount of cash withdrawn by black market operators decreased by 72% compared to the previous event of the same scale;

[0339] 10,000 high-risk accounts were manually reviewed, with a false positive rate of 2.3% and a false negative rate of 1.1%.

[0340] Front-end user satisfaction survey: 92% of users did not perceive any delay or difference in experience;

[0341] The system achieved a peak QPS of 120,000, with zero Redis cache layer breakdowns and zero graph propagation task failures.

[0342] Rolling closed loop

[0343] After each daily incremental iteration, the 12,000 newly confirmed cheating accounts are added as seeds. The next day, during propagation, the contamination radius is automatically amplified, continuously compressing the space for black market activity and achieving a spiral tightening process of "first-time identification—honeypot verification—second-time amplification." This embodiment verifies the practical effectiveness of this invention in large-scale operational activities, achieving 3-minute iteration, 100-millisecond front-end decision-making, and zero user experience disruption.

[0344] By adopting the above-disclosed technical solution of this invention, the following beneficial effects are obtained:

[0345] Anti-cheating accuracy significantly improved

[0346] By combining high-weight edges (same device, same bank card, same address) with low-weight edges (similar activity / activity), the system accurately identifies hidden groups that traditional rule engines cannot detect in large-scale graphs. Real-world data shows that the amount of money withdrawn from lottery-related black market activities decreased by 72% compared to the previous generation rule system, with a false positive rate of only 2.3% and a false negative rate of 1.1% during manual review, achieving industry-leading levels.

[0347] Maintaining real-time performance even under extremely high traffic

[0348] The full graph iteration with hundreds of millions of vertices and billions of edges is completed within 3 minutes daily; the front-end completes the tier decision within 100 milliseconds, and 92% of users in the satisfaction survey reported "no perceptible latency." Compared to supervised models that require hours of offline training, this invention shortens the identification-handling closed loop to the second level, meeting the rigid requirement of "on-the-spot identification and on-the-spot effect" for high-concurrency operational activities.

[0349] Zero damage to front-end experience

[0350] A "probability-ladder honeypot" strategy is adopted: high-risk users can still see the lottery animation, but the probability is set to zero in the background to prevent black market operators from immediately detecting policy upgrades; medium- and low-risk users maintain a reasonable chance of winning through linear discounts. An 80-120 millisecond random delay is inserted between the animation and the result to eliminate time-series side channels, ensuring a consistent user experience with scenarios without risk control.

[0351] Horizontal transplantation is cost-free

[0352] The system is embedded into any React / Vue page as an SDK and component. The server can adjust edge weights and thresholds through the configuration center without modifying the business code. After being validated by Autohome's "818 100-City Auto Show", the same module was reused during the "Double 11 Auto Shopping Festival", shortening the integration cycle from two weeks to two days, significantly reducing operational and technical costs.

[0353] Dual protection of compliance and privacy

[0354] Sensitive fields such as bank card numbers and mobile phone numbers only retain irreversible hashes; LBS latitude and longitude coordinates are truncated to a 200-meter grid on the client side before being reported; layered results only return high / medium / low levels and probabilities, without exposing the graph structure. The entire process complies with the minimum usability principle of the Personal Information Protection Law and was launched with zero rectification after passing a third-party compliance audit.

[0355] The above are merely preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for identifying multi-account cheating in operational activities based on graph propagation, characterized in that, The steps include: a) Collecting and reporting user behavior data in real time on the client side. The user behavior data includes at least: i) Historical active behavior vector, which is an N-dimensional integer array formed by splitting the daily APP active time over the most recent N days into five-dimensional integer arrays; ii) Historical activity participation vector, which is an M-dimensional 0 / 1 array indicating whether the user participated in the most recent M operational activities; iii) Basic environmental attributes, including at least device UUID, IP address, and Wi-Fi. b) BSSID and LBS geolocation; iv) Business attribute behavior, including at least activity forwarding relationship, withdrawal bank card number, delivery address and mobile phone number; b) After cleaning the data obtained in step a), the server constructs a heterogeneous user relationship graph with user account as vertice and multiple association relationships as edges. The association relationships include: historically active similar edges, historically active similar edges, same device edges, same Wi-Fi edges, same LBS edges, activity forwarding edges, same bank card edges, and same delivery address edges; and assigns differentiated weights to each type of edge based on the group's fraud risk; c) The server uses the confirmed blacklisted accounts as seed vertices and uses the weighted PageRank algorithm to iteratively propagate on the heterogeneous user relationship graph until the PR value of each vertex converges, obtaining the fraud probability of each account; d) The server performs stratified processing on all accounts in the current operation activity based on the fraud probability, and sends the stratification results to the client. The client dynamically adjusts the winning probability or task visibility of the account in the operation activity based on the stratification results to achieve real-time anti-fraud at the front end.

2. The method according to claim 1, wherein the differentiated weights in step b) are preset by expert experience, with the edge weights of the same device, same bank card, and same delivery address being 10, the edge weights of the same Wi-Fi being 5, the edge weights of the similar LBS being 2, the edge weights of historically active / similar activities being 1, and the edge weights of active forwarding being 2; when there are multiple relationships between two vertices, the edge weights are accumulated.

3. The method according to claim 2, wherein the propagation matrix of the weighted PageRank in step c) is obtained by normalizing the outgoing edge weights of the heterogeneous user relationship graph, and the iteration stopping condition is that the change of the PR value of each vertex in two consecutive rounds is less than 0.000001; the initial PR value of the seed vertex is 1, and the initial PR value of the other vertices is 0.

4. The method according to claim 3, wherein the hierarchical processing rule in step d) is as follows: compare all converged PR values ​​with the minimum PR value of the seed vertex, standardize the cheating probability of accounts with a PR value greater than or equal to the minimum PR value of the seed to 1, and the cheating probability of other accounts = the PR of this account / the minimum PR of the seed; the client sets the winning probability of accounts with a cheating probability greater than the first threshold to 0, reduces the winning probability of accounts with a cheating probability between the first threshold and the second threshold by a linear discount factor, and maintains the original winning probability of accounts with a cheating probability lower than the second threshold.

5. The method according to claim 4, wherein the historical active behavior vector in step a) is calculated and encrypted and reported in real time by the SDK on the client side, and the server side truncates and discretizes the abnormal duration before storing it in the database to prevent black market operators from forging continuous high-activity curves.

6. The method according to claim 5, wherein the same LBS edge in step b) is generated using Geohash accurate to 200m. If two accounts have the same Geohash during the same activity period, a bidirectional edge is generated to capture geographically clustered groups.

7. The method of claim 6, wherein step d) further comprises: Before the lottery results are displayed, the client asynchronously requests the real-time cheating probability of the account from the server. The server returns a hierarchical identifier in JSON format within 50ms. The client decides whether to display the "Win" or "Thank you for participating" animation based on the hierarchical identifier, thus achieving a zero-latency anti-cheating experience on the front end.

8. A multi-account cheating identification system for operational activities based on graph propagation, characterized in that, include: The client SDK module is used to collect and encrypt the user behavior data described in step a) of claim 1. The server-side graph construction module is used to execute step b) of claim 1 to construct a heterogeneous user relationship graph; the server-side graph propagation module is used to execute step c) of claim 1 to complete the weighted PageRank iteration and output the cheating probability; The server-side hierarchical decision-making module is used to execute step d) of claim 1 to generate hierarchical results; the client-side anti-fraud execution module is used to receive the hierarchical results and adjust the interactive logic of operational activities in real time; the system implements the method of any one of claims 1-7 through the collaboration of each module.

9. The system according to claim 8, wherein the server-side graph propagation module adopts a distributed graph computing framework, supports incremental updates of hundreds of millions of vertices and billions of edges per day, and completes full graph iterative convergence within 3 minutes.

10. The system according to claim 9, wherein the client-side anti-cheating execution module is embedded in the lottery page in the form of a React / Vue component. When the user clicks the "Draw Now" button, it first calls the locally cached hierarchical identifier. If the cache expires, it initiates an HTTPS short connection request to achieve anti-cheating decision within 100ms and ensure user experience.

Images