Telephone number authenticity judgment method based on power grid artificial intelligence platform

Abstract

The invention discloses a telephone number authenticity judgment method based on a power grid artificial intelligence platform. According to the method, a unified analysis data set is constructed, so that deep fusion and efficient treatment of multi-source heterogeneous data are realized; through preset first static consistency comparison, the technical problem that a traditional method cannot automatically identify the number use state in batches is solved; by introducing the second dynamic time sequence comparison, the technical bottleneck that the authenticity of the number cannot be evaluated only depending on static data is broken through. According to the invention, the technical span of telephone number authenticity judgment from artificial experience decision making to data intelligent driving is finally realized, and the automation level of the judgment process and the accuracy of the result are remarkably improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of telephone number authenticity determination, and particularly relates to a telephone number authenticity determination method based on a power grid artificial intelligence platform. BACKGROUND

[0002] With the development of economic society, every family and every industrial enterprise cannot do without power, so power supply enterprises have a large number of users. For power supply enterprises, how to keep in touch with users in the process of power consumption is crucial to accurately convey key information such as power-off and power-on information and electricity fee information to actual power consumers. With the full popularization of the energy internet marketing service system (marketing 2.0 system) of State Grid Corporation of China, key information such as power-off and power-on information and electricity fee information is delivered to the mobile phone numbers of user account contacts through short message service. However, due to various reasons such as house buying and selling, user changing of telephone numbers, and non-entry of mobile phone numbers during early filing, there are a large number of abnormal mobile phone numbers of account contacts or inconsistent with actual power consumers in the marketing 2.0 system, and it is urgent to manage the correctness and authenticity of the telephone numbers.

[0003] The current management method is: in terms of correctness, the mobile phone numbers that do not belong to the mobile, Unicom and other operator communication function number segments, are not 11 digits, and have non-numeric types and other abnormalities are simply determined according to the rules, and then the customer manager visits the customers one by one to obtain the correct number, but often cannot contact the customers due to the user going out for work or the user moving, etc. In terms of authenticity, there is no determination rule at present, and the customer can only modify the telephone number or dial the service number through the online State Grid App, but this often occurs when the customer has already generated a bad perception. In general, the current telephone number management method has the following deficiencies: first, the management is very passive and it is difficult to predict the authenticity of the number before the customer generates a bad perception; second, the management efficiency is very low, the management work lacks guidance and planning, and the collection of numbers through visits consumes a lot of manpower and the effect is difficult to guarantee.

[0004] In related technologies, the management of power grid user telephone numbers has the technical problems of lagging management timing and being unable to batch determine authenticity. SUMMARY

[0005] The technical problem to be solved by the present application is that, in related technologies, the management of power grid user telephone numbers has the technical problems of lagging management timing and being unable to batch determine authenticity. The purpose is to provide a telephone number authenticity determination method based on a power grid artificial intelligence platform, which solves the technical problems of lagging management timing and being unable to batch determine authenticity in the management of power grid user telephone numbers in related technologies.

[0006] This invention is achieved through the following technical solution:

[0007] In a first aspect, the present invention provides a method for determining the authenticity of telephone numbers based on a power grid artificial intelligence platform, comprising:

[0008] Acquire user profile data, historical online payment behavior data, and electricity bill SMS interaction data of the target user group;

[0009] Using user identifiers as association keys, the user profile data, historical online payment behavior data, and electricity bill SMS interaction data are associated and preprocessed to construct a unified analysis dataset;

[0010] Based on the unified analysis dataset, a preset first comparison process is performed to obtain the result of the first comparison; wherein, the first comparison process means comparing the consistency of the billing contact person's phone number with at least one historical payment contact phone number;

[0011] If the result of the first comparison indicates inconsistency, a preset second comparison process is performed based on the unified analysis dataset to obtain the result of the second comparison; wherein, the second comparison process refers to comparing the order of the sending time of the electricity balance warning SMS and the payment success time.

[0012] Based on the results of the first comparison and / or the second comparison, a result is generated to determine the authenticity of the contact phone number of the accountant and corresponding governance strategy information.

[0013] Furthermore, the step of using the user identifier as the association key to associate and preprocess the user profile data, historical online payment behavior data, and electricity bill SMS interaction data to construct a unified analysis dataset includes:

[0014] A first cleaning process is performed on the user profile data to exclude user data that has been deactivated.

[0015] A second cleaning process is performed on the historical online payment behavior data to remove invalid payment records and mark the payment on behalf of multiple users.

[0016] From the historical online payment behavior data, identify a subset of users with no valid online payment records;

[0017] Using the user identifier as the association key, the cleaned user profile data, the cleaned historical online payment behavior data, and the corresponding electricity bill SMS interaction data are linked and integrated to generate the unified analysis dataset.

[0018] Furthermore, the step of performing a second cleaning process on the historical online payment behavior data to remove invalid payment records and mark the payment on behalf of multiple users includes:

[0019] Records with zero payment amount or prepayment offset type are removed to obtain valid payment records;

[0020] Based on the valid payment records, count the number of associated users corresponding to each payment contact number;

[0021] Phone numbers associated with more than a preset threshold for payment contact information will be marked as payment on behalf data.

[0022] The step of identifying a subset of users with no valid online payment records from the historical online payment behavior data includes:

[0023] Users who have no valid payment records within a preset historical time period are selected to form the user subset;

[0024] The step of linking and integrating the cleaned user profile data, cleaned historical online payment behavior data, and corresponding electricity bill SMS interaction data using the user identifier as the association key to generate the unified analysis dataset includes:

[0025] Using user profile data as the main table and user identifier as the association key, historical online payment behavior data and electricity bill SMS interaction data are associated with the main table through a left join to form the unified analysis dataset.

[0026] Further, the step of performing a preset first-level comparison process based on the unified analysis dataset to obtain the result of the first-level comparison includes:

[0027] Extract a preset number of historical payment contact phone numbers from the unified analysis dataset, arranged in descending order of payment time.

[0028] The account contact person's phone number is compared one by one with a preset number of historical payment contact phone numbers. If at least one historical payment contact phone number matches the account contact person's phone number, the result of the first comparison is determined to be consistent. If all preset number of historical payment contact phone numbers do not match the account contact person's phone number, the result of the first comparison is determined to be inconsistent.

[0029] Further, the step of extracting a preset number of historical payment contact phone numbers from the unified analysis dataset, arranged in reverse chronological order by payment time, includes:

[0030] Grouping historical online payment behavior data based on user identifiers;

[0031] Within each group, use database window functions to sort payment records in descending order of payment success time and generate a sort number for each record;

[0032] From each group, extract the historical payment contact phone numbers corresponding to payment records whose sorting number is less than or equal to a preset number.

[0033] Further, the step of performing a preset second alignment process based on the unified analysis dataset to obtain the second alignment result when the result of the first alignment indicates inconsistency includes:

[0034] From the unified analysis dataset, extract the sending time of the target user's electricity balance warning SMS and power outage SMS for overdue payment, as well as the payment success time;

[0035] Based on the order of the sending time and the payment success time, a risk level determination result is generated as the second comparison result; wherein: if the payment success time is after the time of sending the electricity balance warning SMS and before the time of sending the power outage SMS due to overdue payment, it is determined to be a low risk level; if the payment success time is after the time of sending the power outage SMS due to overdue payment, it is determined to be a high risk level.

[0036] Further, the step of generating a result determining the authenticity of the account contact person's phone number and corresponding governance strategy information based on the results of the first comparison and / or the second comparison includes:

[0037] In response to the inconsistency of the first comparison result, a preliminary authenticity judgment result and a first governance sub-strategy including the first verification priority are generated;

[0038] Based on the risk level determination result obtained from the second comparison, the preliminary authenticity determination result and the first verification priority are corrected to generate the final authenticity determination result and the final verification priority.

[0039] The final authenticity determination result, the final verification priority, and the first governance sub-strategy are combined to form the authenticity determination result and the corresponding governance strategy information; wherein, when the risk level determination result is a high-risk level, the final authenticity determination result is corrected to be untrue and the final verification priority is set to the highest level.

[0040] Secondly, the present invention provides a device for determining the authenticity of a telephone number, comprising:

[0041] The acquisition module is used to acquire user profile data, historical online payment behavior data, and electricity bill SMS interaction data of the target user group.

[0042] The module is used to associate and preprocess the user profile data, historical online payment behavior data, and electricity bill SMS interaction data with the user identifier as the association key, so as to build a unified analysis dataset.

[0043] The first comparison processing module is used to perform a preset first comparison processing based on the unified analysis dataset to obtain the result of the first comparison; wherein, the first comparison means comparing the consistency of the billing contact person's contact number with at least one historical payment contact number.

[0044] The second comparison processing module is used to perform a preset second comparison processing based on the unified analysis dataset when the result of the first comparison indicates inconsistency, and obtain the result of the second comparison; wherein, the second comparison refers to comparing the order of the sending time of the electricity balance warning SMS and the payment success time.

[0045] The generation module is used to generate a result determining the authenticity of the contact number of the account contact person and corresponding governance strategy information based on the results of the first comparison and / or the second comparison.

[0046] Thirdly, the present invention provides an electronic device, comprising: a memory, and one or more processors communicatively connected to the memory; the memory stores instructions executable by the one or more processors, the instructions being executed by the one or more processors to cause the one or more processors to implement the method described above.

[0047] Fourthly, the present invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0048] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0049] This invention achieves deep fusion and efficient governance of multi-source heterogeneous data by constructing a unified analysis dataset. Through a pre-defined first-level static consistency comparison, it solves the technical challenge of traditional methods' inability to batch and automatically identify the usage status of phone numbers. By introducing a second-level dynamic time-series comparison, it overcomes the technical bottleneck of relying solely on static data to assess the authenticity of phone numbers. Ultimately, this invention represents a technological leap from manual experience-based decision-making to data-driven intelligence in determining the authenticity of phone numbers, significantly improving the automation level of the determination process and the accuracy of the results. Attached Figure Description

[0050] To more clearly illustrate the technical solutions of the exemplary embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of the present invention and should not be considered as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort. In the drawings:

[0051] Figure 1 A flowchart illustrating a method for determining the authenticity of telephone numbers based on a power grid artificial intelligence platform, as provided in the embodiments of this specification;

[0052] Figure 2 This is an architecture diagram of a telephone number authenticity determination method based on a power grid artificial intelligence platform provided in the embodiments of this specification;

[0053] Figure 3 This is a block diagram of an electronic device provided in the embodiments of this specification. Detailed Implementation

[0054] To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the embodiments and accompanying drawings. The illustrative embodiments and descriptions of the present invention are only used to explain the present invention and are not intended to limit the present invention.

[0055] In related technologies, critical service information such as electricity bill reminders and power outage / restoration notices are primarily sent via SMS to the mobile phone number of the account contact person registered in the user's file. Ensuring the accuracy of this number is crucial for improving the quality of power supply services and protecting users' right to know. However, due to various reasons such as property sales, changes in user mobile phone numbers, and incomplete or incorrect historical registration information, a large number of inaccurate or expired phone numbers exist in relevant systems (e.g., energy internet marketing service systems), resulting in important SMS messages not being delivered. This not only leads to user complaints but also increases the service risks for power supply companies.

[0056] In related technologies, the management of user phone numbers mainly relies on two methods. The first method is based on simple rules from telecommunications operators for verification, such as checking if the number is 11 digits long or if the number range belongs to a mainstream operator. This method can only identify numbers with obviously abnormal formats and cannot determine whether a correctly formatted number is still being used by the current user (i.e., the authenticity issue).

[0057] The second approach involves a reactive intervention by account managers when SMS delivery fails or users complain about not receiving notifications. This involves manually calling or visiting the user's home to verify and update the number. This reactive approach has significant drawbacks: First, it's reactive, as problems are only discovered after negative consequences (user complaints) have occurred, by which time service risks have already materialized. Second, it heavily relies on manual labor; manually verifying data from millions of users is extremely inefficient, costly, and difficult to cover all users. Third, it lacks precise guidance; manual management cannot prioritize or customize strategies for a massive user base, leading to significant uncertainty and inefficiency.

[0058] The root causes of these technical problems lie primarily in the following reasons: First, the data from different business segments (user profiles, online payments, SMS sending) are independent, forming data silos and lacking effective data fusion and correlation analysis methods (this data exists in the Marketing 2.0 system, but has never been correlated or utilized). Second, traditional technical methods cannot deeply mine and analyze historical user behavior data (e.g., payment records, SMS interaction records), thus failing to infer the true status of the phone number from user behavior patterns. Ultimately, this results in governance efforts remaining in a state of passive response and inefficient operation.

[0059] Therefore, in related technologies, the management of telephone numbers used by power grid users suffers from technical problems such as delayed management timing and inability to conduct batch verification of authenticity.

[0060] This implementation plan aims to solve the above-mentioned technical problems. Its core inventive concept is to integrate multi-source heterogeneous data through the power grid artificial intelligence platform and adopt dual comparison processing including static consistency comparison and dynamic time-series comparison to achieve proactive, batch and accurate determination of the authenticity of telephone numbers, thereby transforming the governance mode from passive remediation to proactive early warning.

[0061] like Figure 1 and Figure 2 As shown, this embodiment provides a method for determining the authenticity of phone numbers based on a power grid artificial intelligence platform. The method is executed by the power grid artificial intelligence platform. Specifically, the power grid artificial intelligence platform can be configured in a server or server cluster within the power grid company's internal data center. The power grid artificial intelligence platform may include:

[0062] The data access and computing layer may specifically include a distributed data warehouse and a distributed computing engine. Specifically, the power grid AI platform may have a built-in or interfaced distributed data warehouse or data lake, such as a Hadoop / Spark-based distributed data lake. This can be used to store and efficiently process massive amounts of data accessed from various power grid business systems (e.g., the Marketing 2.0 system). The distributed computing engine can support ETL (Extract, Transform, Load) operations and SQL queries on large-scale datasets.

[0063] The artificial intelligence and algorithm layer can specifically include a programmable analysis environment and machine learning libraries. Specifically, the platform can provide a visual programming interface and support Python and SQL as core programming languages. Users (e.g., data analysts or algorithm engineers) can write, debug, and execute decision rules and logic such as first-level and second-level alignment processing within this environment. The platform can also integrate mainstream machine learning libraries such as Scikit-learn, TensorFlow, or PyTorch.

[0064] The workflow scheduling and service layer can specifically include a workflow scheduling engine and an API service gateway. Specifically, the platform can integrate a workflow scheduling engine to orchestrate multiple steps in this method into automated workflow tasks. For example, this task can be configured to execute automatically once a month, enabling periodic batch verification of phone number authenticity. The platform can then publish the verification results (governance strategy information) through the API service gateway for downstream systems (e.g., mobile applications used by account managers or business ticketing systems) to access, thereby translating the analysis results into actual business actions.

[0065] The method may include:

[0066] Step S10: Obtain user profile data, historical online payment behavior data, and electricity bill SMS interaction data of the target user group.

[0067] In this embodiment, the executing entity (a power grid AI platform configured on a server or server cluster) can extract user profile data, historical online payment behavior data, and electricity bill SMS interaction data from the power grid company's business system through its data interface (e.g., via scheduled structured query language tasks or application programming interface calls). The business system can be a Marketing 2.0 system.

[0068] Specifically, the user profile data can be derived from the user profile data of the Marketing 2.0 system. It may include: a unique user identifier, electricity address, user category (e.g., low-voltage residential, high-voltage user), account status (e.g., normal electricity usage, closed account), and contact phone numbers for one or more account management contacts.

[0069] The historical online payment data can be represented as transaction records generated after a user completes electricity bill payment through online channels. Specifically, it may include: user identifier, payment success time, payment amount, payment channel (e.g., WeChat, Alipay), and the contact phone number associated with the payment account (i.e., the historical payment contact phone number).

[0070] The electricity bill SMS interaction data can be represented as a record of SMS messages sent by the system to the user and their status receipts. Specifically, it may include: user identifier, SMS type (e.g., electricity balance warning, power outage notice for overdue payment, payment settlement notice), SMS content, target mobile phone number, sending time, and sending status (e.g., success, failure).

[0071] Step S12: Using the user identifier as the association key, associate and preprocess the user profile data, historical online payment behavior data, and electricity bill SMS interaction data to construct a unified analysis dataset.

[0072] In this embodiment, the executing entity can perform a connection and merging operation on data tables (raw data) from different sources based on a common user identifier field, and clean, transform and normalize the raw data to improve data quality and make it suitable for analysis.

[0073] In this embodiment, the user identifier can be represented as a uniquely identified electricity user code within the power grid system.

[0074] In this embodiment, the preprocessing can be described as eliminating data noise and invalid records. Specifically, firstly, user profile data can be cleaned to exclude user records where the account status is closed. Secondly, historical online payment behavior data can be cleaned to remove invalid transaction records with zero payment amount or prepaid electricity fee offset, and the number of unique users associated with each payment contact number can be counted. Numbers with more than a preset threshold (e.g., 5) of associated users are marked as payment on behalf of others. Finally, users who have no valid online payment records within a preset historical time period (e.g., the most recent year) can be identified, forming a subset of users to be verified offline.

[0075] In this embodiment, constructing a unified analysis dataset can be represented as creating a wide table that includes all necessary fields. Specifically, through database join operations (e.g., left join), the cleaned user profile data can be used as the main table, and the cleaned historical online payment behavior data and electricity bill SMS interaction data can be associated with the main table according to user identifiers, ultimately forming a dataset where each record represents a user and all related information, which can be used for subsequent analysis.

[0076] Step S14: Based on the unified analysis dataset, perform a preset first comparison process to obtain the result of the first comparison; wherein, the first comparison means comparing the billing contact person's phone number with at least one historical payment contact phone number for consistency.

[0077] In this embodiment, the first comparison process can be represented as a consistency check based on static data. The historical payment contact phone number can be represented as the contact phone number carried in the payment records of each user, extracted from the unified analysis dataset, arranged in reverse chronological order by payment time, and within the most recent preset number (e.g., 6 times).

[0078] In this embodiment, the consistency comparison can be expressed as determining whether two phone number strings are completely equal. The result of the first comparison is also the final comparison result. Specifically, if any billing contact person's phone number matches any historical payment contact number, the result is consistent. If all billing contact person's phone numbers do not match all historical payment contact numbers, the result is inconsistent.

[0079] Step S16: If the result of the first comparison indicates inconsistency, a preset second comparison process is performed based on the unified analysis dataset to obtain the result of the second comparison; wherein, the second comparison refers to comparing the order of the sending time of the electricity balance warning SMS and the payment success time.

[0080] In this embodiment, the sending time of the electricity balance warning SMS can be represented as the specific moment when the system sends a reminder SMS to the user's account contact when the user's electricity balance is insufficient. The payment success time is the moment when the user completes the online electricity payment and the system confirms the payment.

[0081] In this implementation, the executing entity can analyze the temporal logic relationship between the two time points mentioned above. Specifically, the executing entity can extract relevant timestamps from the unified analysis dataset and compare them. For example, it can determine whether the successful payment time is after the last electricity balance warning SMS message was sent and before the power outage SMS message for overdue payments was sent.

[0082] Step S18: Based on the results of the first comparison and / or the second comparison, generate the authenticity determination result of the telephone number of the account contact person and the corresponding governance strategy information.

[0083] In this embodiment, the authenticity determination result can be true or false, or it can be low risk, medium risk, or high risk, etc.

[0084] In this embodiment, the governance strategy information can be information representing specific operational suggestions corresponding to different judgment results. Specifically, for users whose first comparison result is consistent, a conclusion can be generated that the number is genuine and no governance is needed. For users whose first comparison result is inconsistent, different verification priorities (e.g., high, medium, low) and specific action suggestions can be generated based on the second comparison result (e.g., risk level).

[0085] In this embodiment, the governance strategy information can be output in a structured data format and can be called and executed by downstream business systems.

[0086] In one possible and specific implementation, the governance policy information can be in a lightweight data exchange format, such as JSON (JavaScript Object Notation) or XML (eXtensible Markup Language). The executing entity can generate a separate record for each user being processed, which may include multiple predefined key-value pairs or tags.

[0087] Specifically, the governance strategy information may include the following fields:

[0088] The user identifier field is used to uniquely identify the electricity user corresponding to this policy, and its value comes from the user's unique identifier code in the user profile data.

[0089] The authenticity determination result field stores the final determination of the account contact person's phone number. Its value can be an enumeration type, for example, it can be represented by the string "authentic" or "inauthentic" or the numeric code 1 or 0.

[0090] The risk level field stores the risk level information obtained after the second comparison process. Its value can be high, medium, low, or the corresponding level code.

[0091] The verification priority field stores the system's recommended priorities for governance efforts. Its values ​​can be associated with or set independently of the risk level, such as highest, high, medium, and low.

[0092] The governance guidance field stores specific and actionable recommendations, whose values ​​can be structured text or predefined instruction codes. For example, "Recommend updating the account number to payment number 1" or "Recommend prioritizing the verification of payment number 1 and payment number 3".

[0093] The Recommended Number field stores a list of one or more contact phone numbers recommended by the system based on payment behavior analysis.

[0094] In one possible and specific implementation, after the executing entity completes the batch judgment of all users, it can store the generated structured data file (e.g., a JSON array file containing multiple JSON records) including all user governance policies on a pre-set file server or database. Simultaneously, the executing entity can send requests to the API via an application programming interface, such as a RESTful API based on the HTTP protocol. Downstream business systems, such as customer relationship management systems (CRM) or mobile ticketing applications, can initiate requests according to a predetermined schedule or triggered by events. Upon receiving the request, the executing entity returns the structured governance policy information through the API interface. After obtaining this information, the downstream business system's built-in business logic parsing module can parse the data, sort tasks according to the verification priority field, and automatically generate pending work orders for the corresponding regional account managers. The generated work orders can directly include the governance guidelines and recommended number fields, allowing account managers to conduct targeted customer contact and number verification work based on the explicit guidance on the work order, thus completing the closed loop from data analysis to business execution.

[0095] This embodiment achieves deep fusion and efficient governance of multi-source heterogeneous data by constructing a unified analysis dataset. Through a pre-defined first-level static consistency comparison, it solves the technical challenge of traditional methods' inability to batch and automatically identify the usage status of phone numbers. By introducing a second-level dynamic time-series comparison, it overcomes the technical bottleneck of relying solely on static data to assess the authenticity of phone numbers. This embodiment ultimately achieves a technological leap from manual experience-based decision-making to data-driven intelligence in determining the authenticity of phone numbers, significantly improving the automation level of the determination process and the accuracy of the results.

[0096] In some implementations, the step of associating and preprocessing the user profile data, historical online payment behavior data, and electricity bill SMS interaction data using the user identifier as the association key to construct a unified analysis dataset includes:

[0097] Step S122: Perform a first cleaning process on the user profile data to exclude user data that has been cancelled.

[0098] In this embodiment, the first cleaning process can be represented as filtering user records that are currently in a valid power consumption state from the original user profile data. The purpose is to focus the analysis on active users and avoid unnecessary processing of invalid users.

[0099] In one possible and specific implementation, when querying user profile data, a filter condition for the user account status field can be added. The account status field may include a code indicating the user's account closure status (e.g., using the character 09 to represent a closed account). By executing a structured query language statement, including conditions (e.g., a WHERE clause), all records whose account status field value is not equal to the closed account status code can be filtered out. After this processing, the user profile data set operated on in subsequent steps will only include users with valid statuses such as normal electricity use and suspended electricity use.

[0100] Step S124: Perform a second cleaning process on the historical online payment behavior data to remove invalid payment records and mark the payment behavior data on behalf of multiple users.

[0101] In this embodiment, the second cleaning process can be represented as purifying payment behavior data, removing records that do not reflect real user payment behavior, and identifying situations where payments may be made on behalf of someone other than the user.

[0102] In one possible and specific implementation, the removal of invalid payment records may include two scenarios: removing records with a payment amount of zero, which typically originate from internal system adjustments or testing and are not actual transactions; and removing records where the payment type is prepaid electricity bill offset, which represents the deduction process for prepaid electricity fees and not a new payment behavior. Valid payment records reflecting actual payment behavior are obtained through conditional filtering (e.g., using a WHERE clause in an SQL query to exclude records that meet the above conditions).

[0103] In one possible and specific implementation, the data identifying payment-on-behalf behavior for multiple users can be achieved as follows: First, based on the aforementioned valid payment records, grouping and aggregation operations can be performed using the payment contact phone number as the grouping key, counting the number of unique user identifiers associated with each phone number. Then, this number is compared with a preset threshold (e.g., 5). If the number of unique users associated with a certain phone number exceeds this threshold, it is determined that the number has high-frequency payment-on-behalf characteristics, and is highly likely to belong to internal personnel such as business hall staff or area managers. The number and its corresponding payment records are then labeled with a payment-on-behalf behavior tag. This label is used to avoid misidentifying such internal numbers as the user's real number in subsequent analysis.

[0104] Step S126: Identify a subset of users with no valid online payment records from the historical online payment behavior data.

[0105] In this embodiment, a subset of users without valid online payment records is identified in order to determine the user group that relies entirely on offline channels (cash payment) for electricity bill payment.

[0106] In one possible and specific implementation, the valid payment records after cleaning in step S124 can be grouped using user identifiers as the grouping key, and the number of valid payment records for each user within a preset historical time period (e.g., one year prior to the data extraction point) can be counted. An aggregate query is then used to filter out all user identifiers with zero valid payment records within that time period. This set of user identifiers constitutes the subset of users with no valid online payment records. This subset of users can be output separately for offline telephone number verification.

[0107] Step S128: Using the user identifier as the association key, link and integrate the cleaned user profile data, the cleaned historical online payment behavior data, and the corresponding electricity bill SMS interaction data to generate the unified analysis dataset.

[0108] In one possible and specific implementation, firstly, the user profile data table processed in step S122 can be used as the base master table. Then, using the user identifier as the association key, the historical online payment behavior data table processed in step S124 (which may include multiple payment records for each user) can be associated with the users with online payment records not excluded in step S126 through a left join. Simultaneously, the user identifier can also be used as the association key to associate the electricity bill SMS interaction data table (which may include multiple SMS records for each user) with the master table through a left join. This association operation ensures that even if a user does not have a corresponding record in some tables (e.g., a user has no SMS records), their information in the master table will not be lost, guaranteeing data integrity. The final unified analysis dataset can be a wide table structure, where each record represents a unique user and includes the user's basic profile information, all relevant historical payment behavior details (e.g., the most recent payment times and numbers), and all their electricity bill SMS interaction details.

[0109] This implementation method effectively eliminates invalid and interfering data by systematically cleaning, labeling, and integrating multi-source heterogeneous data, and constructs a high-quality unified analysis dataset. This provides an accurate and reliable data foundation for subsequent dual comparison processing, thereby ensuring the accuracy and effectiveness of the final judgment results and governance strategies from the source.

[0110] In some implementations, the step of performing a second cleaning process on the historical online payment behavior data to remove invalid payment records and mark payment on behalf of multiple users includes:

[0111] Step S1241: Remove records with a payment amount of zero or a payment type of prepayment offset to obtain valid payment records.

[0112] In this embodiment, the record with the charge type "prepaid offset" can be represented as an internal transfer record generated when the system directly deducts the electricity fee from the prepaid account after the user has pre-deposited electricity funds. It is understood that no new funds flow into the system during the above process. To implement the removal operation, the executing entity can execute a data query statement (e.g., a Structured Query Language SELECT statement) and set logical judgment conditions in the WHERE clause of the statement to filter out records that do not simultaneously meet the conditions of a payment amount of zero and a charge type of "prepaid offset". In other words, only transaction records with a payment amount greater than zero and a charge type other than "prepaid offset" can be retained.

[0113] Step S1242: Based on the valid payment records, count the number of associated users corresponding to each payment contact number.

[0114] In this embodiment, the executing entity can use the payment contact phone number as the grouping key to group the valid payment record dataset obtained in step S1241 (e.g., using the SQL GROUP BY clause). Then, within each group consisting of the same payment phone number, the number of unique user identifiers appearing can be counted. This calculation process can generate a statistical value for each payment contact phone number, namely the number of unique users associated with that number.

[0115] Step S1243: Mark the payment contact phone numbers with more than a preset threshold as payment proxy behavior data.

[0116] In this embodiment, the executing entity can compare the number of associated users for each payment contact number obtained in step S1242 with a pre-set threshold (this threshold can be preset based on business experience, for example, 5). This comparison operation can be implemented through a conditional statement (e.g., the CASE WHEN statement in SQL). If the number of associated users for a payment contact number is greater than the preset threshold, it is determined that the number exhibits high-frequency payment-on-delivery characteristics and is likely used by internal personnel such as business hall staff, electricity bill collection points, or area managers. Then, the executing entity can set a special flag bit or add a field (e.g., set the value of a field named is_agent_payment to 1 or ) in the record corresponding to the number to complete the marking of the payment-on-delivery behavior data.

[0117] The step of identifying a subset of users with no valid online payment records from the historical online payment behavior data includes:

[0118] Step S1261: Select users who do not have any valid payment records within a preset historical time period to form the user subset.

[0119] In this embodiment, the preset historical time period can be a time window set for analysis, the purpose of which is to limit the analysis scope to recent user behavior to ensure the timeliness of the judgment results. The specific length of this time period can be set according to business needs, for example, it can be twelve months or twenty-four calendar months tracing back from the data extraction point.

[0120] The step of linking and integrating the cleaned user profile data, cleaned historical online payment behavior data, and corresponding electricity bill SMS interaction data using the user identifier as the association key to generate the unified analysis dataset includes:

[0121] Step S1281: Using user profile data as the main table and user identifier as the association key, the historical online payment behavior data and electricity bill SMS interaction data are associated with the main table through a left join to form the unified analysis dataset.

[0122] In this embodiment, the user profile data table obtained after cleaning in step S122 can be set as the left table, i.e., the main table. Then, using the user identifier as the association key, the historical online payment behavior data table after cleaning and marking in step S124 is set as the first right table, and the electricity bill SMS interaction data table is set as the second right table. These are then sequentially associated with the main table through a left join operation. When performing the first left join, each user record in the main table can be traversed, and all records with the same user identifier can be found in the historical online payment behavior data table. If a matching record is found, all fields of the matching payment behavior data (which can be multiple records) are appended to the right side of the user record in the main table. If no matching record is found, the fields related to the payment behavior data will be filled with null values.

[0123] Based on the results of the first join, a second left join operation is performed with the electricity bill SMS interaction data table, using the user identifier as the join key. The logic is the same as the first operation. The final unified analysis dataset can be a wide table.

[0124] In some implementations, the step of performing a preset first alignment process based on the unified analysis dataset to obtain the result of the first alignment includes:

[0125] Step S142: Extract a preset number of historical payment contact phone numbers from the unified analysis dataset, arranged in reverse chronological order of payment time.

[0126] In this embodiment, the reverse order of payment time can be expressed as arranging the most recently occurring payment records at the beginning of the sequence based on the order of successful payment times. The preset number can be expressed as the upper limit of the number of payment records set before the analysis begins according to business needs, used to limit the scope of the analysis. It can be any positive integer, such as 6 or 12 times.

[0127] Step S144: Compare the account contact person's phone number with the preset number of historical payment contact phone numbers one by one; wherein, if at least one historical payment contact phone number is consistent with the account contact person's phone number, the result of the first comparison is determined to be consistent; if all the preset number of historical payment contact phone numbers are inconsistent with the account contact person's phone number, the result of the first comparison is determined to be inconsistent.

[0128] In one possible and specific implementation, for each user, one or more billing contact phone numbers are read from their user profile data. Then, each billing contact phone number is sequentially compared with each number in the time-sorted phone number sequence extracted for the user in step S142 using a string-complete match. The statement that if at least one historical payment contact phone number matches the billing contact phone number means that if any billing contact phone number is found to be completely identical to any historical payment contact phone number in the sequence during the current comparison, all subsequent unnecessary comparisons for that user are immediately terminated, and the user's first comparison result is recorded as consistent. Conversely, the statement that if all preset number of historical payment contact phone numbers are inconsistent with the billing contact phone number means that if, and only if, after performing all possible comparisons with all historical payment contact phone numbers in the sequence, no match is found, the user's first comparison result is recorded as inconsistent.

[0129] In some implementations, the step of extracting a preset number of historical payment contact phone numbers from the unified analysis dataset, arranged in reverse chronological order of payment time, includes:

[0130] Step S1422: Group the historical online payment behavior data based on user identifiers.

[0131] Step S1424: Within each group, use a database window function to sort the payment records in descending order of payment success time, and generate a sort number for each record.

[0132] In one possible and specific implementation, sorting payment records in descending order of payment success time can be achieved by calling a preset window function (e.g., the ROW_NUMBER() function). In this function, the partitioning criterion can be specified as the user identifier using the PARTITION BY clause to ensure that the sorting operation is performed independently within each user group formed by step S1422. Simultaneously, the sorting criterion can be specified as the payment success time DESC (DESC stands for descending order, meaning the most recent time is listed first) using the ORDER BY clause. When executing this query, the database administrator can calculate and generate a unique and consecutive sequence number for each payment record within each user group. This sequence number indicates the record's position in the sequence arranged from most recent to oldest payment time (e.g., the most recent payment record has a sequence number of 1, the second most recent one is number 2, and so on).

[0133] Step S1426: Extract the historical payment contact phone numbers corresponding to payment records whose sorting sequence number is less than or equal to the preset number from each group.

[0134] In one possible and specific implementation, corresponding filtering conditions can be added to the database query statement (e.g., in the WHERE clause of the query or by carrying the query result from step S1424 in the outer query). This filtering condition can determine whether the value of the sort number field of each record is less than or equal to the preset number (e.g., 6). The executing entity can filter according to this condition, retaining only records whose sort numbers are within the specified range. Then, the value of the historical payment contact phone number field can be selected from the retained records. Finally, for each user, the executing entity can obtain a set including up to N phone numbers (N being the preset number).

[0135] In some implementations, the step of performing a preset second alignment process based on the unified analysis dataset to obtain the second alignment result when the result of the first alignment indicates inconsistency includes:

[0136] Step S162: Extract the sending time of the target user's electricity balance warning SMS and power outage SMS for overdue payment, as well as the payment success time, from the unified analysis dataset.

[0137] In this embodiment, the target user can be represented as a user group that has undergone a first comparison process and whose result is inconsistent.

[0138] In one possible and specific implementation, for each target user, the executing entity can perform data reading operations. From the user's corresponding record, it reads the value of the sending time field of their electricity balance warning SMS, which corresponds to the specific time the system sends the electricity balance reminder SMS to the user's account contact's mobile phone number. Simultaneously, it reads the value of the sending time field of their overdue power outage SMS, which corresponds to the specific time the system sends the power outage notification SMS to the user after they have defaulted on their payment but before executing the power outage operation. It can also read the value of the payment success time field.

[0139] Step S164: Based on the order of the sending time and the payment success time, generate a risk level determination result as the second comparison result; wherein: if the payment success time is after the time of sending the electricity balance warning SMS and before the time of sending the power outage SMS due to overdue payment, it is determined to be a low risk level; if the payment success time is after the time of sending the power outage SMS due to overdue payment, it is determined to be a high risk level.

[0140] In one possible and specific implementation, the implementing entity can first compare the time of successful payment with the time of the electricity balance warning SMS message. If the successful payment time is later than the warning SMS message sending time, it initially indicates that the user may have made payment after receiving the warning. Then, the implementing entity can further compare the time of successful payment with the time of the power outage SMS message sent due to overdue payment.

[0141] If the successful payment time occurs after the time the electricity balance warning SMS is sent and before the time the power outage SMS is sent, this time sequence indicates that the system sent a balance warning SMS, and the user completed the payment after receiving the warning and before the system executed the power outage operation. This behavior pattern indicates that the user successfully received the warning SMS, therefore their account contact number was highly likely to be valid at that time. Even if this number is different from the number used for recent payments, there may be a reasonable reason (e.g., using a family member's number to pay). Therefore, this situation can be classified as low-risk.

[0142] If the successful payment occurs after the power outage SMS message was sent, this time sequence indicates that the system not only sent a balance warning SMS but also a power outage SMS message, and the user only completed the payment afterward. This behavior pattern suggests that the user failed to receive the previous warning SMS message and only discovered the outstanding payment after the power outage occurred. This directly proves that their account contact number has expired, resulting in a service interruption. Therefore, this situation is classified as high-risk.

[0143] In some implementations, the step of generating a verification result of the authenticity of the account contact person's phone number and corresponding governance strategy information based on the results of the first comparison and / or the second comparison includes:

[0144] Step S182: In response to the inconsistency of the first comparison result, generate a preliminary authenticity determination result and a first governance sub-strategy including a first verification priority.

[0145] In this embodiment, "preliminary" can refer to a determination that the time logic information of the second comparison has not yet been integrated, and therefore it is only a preliminary authenticity determination result. This preliminary authenticity determination result may indicate an abnormal state of the number, for example, that it is not authentic.

[0146] In one possible and specific implementation, the first governance sub-policy, which includes a first verification priority, can be generated in the following manner:

[0147] Step S1821: For the historical payment contact phone number sequence extracted for the user in step S142 and sorted by time, perform the preset behavioral feature extraction and analysis process to obtain feature values.

[0148] Specifically, it can perform number consistency pattern analysis to determine whether all numbers in a sequence are completely identical (e.g., AAAAAA pattern), or whether there are partial variations (e.g., ABAAAA pattern) or all different numbers (e.g., ABCDEF pattern). It can perform payment behavior stability analysis; for example, it can count the number of different phone numbers in a sequence and calculate the frequency of the most frequent phone number. It can perform behavior time span analysis; for example, it can calculate the time interval between the first and last payment in a sequence.

[0149] Step S1822: Match the analyzed feature values ​​with the preset rule base to output the priority level.

[0150] Specifically, the rule base can include multiple conditional judgment logics. For example, if the sequence of historical payment contact phone numbers shows high consistency (e.g., all numbers are the same) and the time span of the behavior is greater than a first preset time period (e.g., 90 days), a medium priority rule is generated. This pattern implies that the user may be using a new number stably for a long period, and the anomaly is clear but not urgent. If the phone numbers in the sequence are disorganized (e.g., all numbers are different) or the time span of the behavior is less than a second preset time period (e.g., 60 days), a high priority rule is generated. This pattern implies that the user's behavior is unstable, the number anomaly is complex, or it may be a short-term problem that needs to be verified as soon as possible.

[0151] Step S1823: Combine to form the first governance sub-strategy.

[0152] The first governance sub-strategy can be a structured data object, which includes at least the first verification priority field generated in the above steps. Additionally, it may include preliminary governance guidelines derived from the analysis of similar behavioral characteristics, such as suggesting priority verification of number X (X being the most frequent number in the sequence) or suggesting verification of all different numbers appearing in the three most recent payments.

[0153] Step S184: Based on the risk level determination result obtained from the second comparison, the preliminary authenticity determination result and the first verification priority are corrected to generate the final authenticity determination result and the final verification priority.

[0154] In this embodiment, the correction can be expressed as reviewing and revising the preliminary authenticity determination result and the first verification priority, so that the final output result more accurately reflects the true risk status of the business.

[0155] In this embodiment, the correction process can be implemented through predefined correction rule logic, which can perform different correction operations based on different risk level determination results:

[0156] Step S1841: If the risk level assessment result is high-risk, regardless of the initial assessment result, the executing entity can forcibly correct the final authenticity assessment result to be false. This is because a high-risk level often indicates direct evidence (the user paying after a power outage) showing that an incorrect number has caused service interruption, and its weight is far higher than the static inconsistency conclusion of the first comparison. This correction ensures the accuracy of the final conclusion. Correspondingly, regardless of whether the initial verification priority was originally high, medium, or low, the execution entity can forcibly set the final verification priority to the highest level. This is because a high-risk level is directly related to existing negative user experiences and potential complaints, and must be handled with the highest priority to mitigate service risks.

[0157] Step S1842: If the risk level determination result is low risk, since a low risk level indicates normal user behavior (payment after warning, before power outage), it suggests that the user may still receive SMS messages, meaning the original number may still be valid. Therefore, the "inauthentic" result generated in step S182 is maintained as the final authenticity determination result, or it is corrected to an intermediate state such as "suspected inauthentic." This is because although the static comparison is inconsistent, the temporal behavior does not show any abnormalities, reducing the urgency of the risk. Correspondingly, the executing entity can downgrade the first verification priority according to preset rules. For example, if the original first verification priority was high, it can be downgraded to medium; if it was medium, it can be downgraded to low. Because a low-risk situation allows for a more relaxed response time, governance resources can be released to higher-priority tasks.

[0158] Step S186: Combine the final authenticity determination result, the final verification priority, and the first governance sub-strategy to form the authenticity determination result and the corresponding governance strategy information; wherein, when the risk level determination result is a high-risk level, the final authenticity determination result is corrected to be untrue and the final verification priority is set to the highest level.

[0159] This implementation method introduces a dynamic correction mechanism based on risk levels, which integrates the preliminary conclusions of the first comparison with the time logic depth analysis results of the second comparison. This achieves precise optimization and intelligent decision-making regarding the determination of the authenticity of phone numbers and governance priorities. As a result, it ensures that limited governance resources can be prioritized for user groups who have experienced power outages or other negative impacts due to incorrect phone numbers, effectively improving the accuracy, initiative, and efficiency of the governance work and business loop.

[0160] In one specific implementation plan, a method for determining the authenticity of customer contact phone numbers based on a power grid artificial intelligence platform is provided.

[0161] This implementation plan addresses the passive and inefficient nature of current methods for managing abnormal phone numbers in power supply company user files. It proposes a new method: a customer contact phone number authenticity determination method based on a power grid AI platform. This new method utilizes the platform to determine the authenticity of the current account phone number by comparing the consistency between the online payment number and the account contact person's mobile phone number, and the order of the user's payment time and the time of the power outage SMS message. In terms of language modeling, it employs Python + SQL, fully leveraging the big data analysis and machine learning capabilities of the intelligent analysis platform to intelligently correct the algorithm logic.

[0162] The new method can solve the following problems: First, it combines multi-data elements from the Marketing 2.0 system (such as billing contact information, online payment information, SMS reminders, etc.) with actual business experience to conduct a comprehensive assessment of the authenticity of the billing contact's phone number in advance; second, it prioritizes the management of users identified as abnormal to improve management efficiency; and third, it tailors a management strategy for each user identified as abnormal to guide the district manager in carrying out management work.

[0163] A method for determining the authenticity of customer contact phone numbers based on a power grid artificial intelligence platform may include:

[0164] Step 1: Business Research

[0165] First, an analysis of payment methods at multiple power supply stations within the jurisdiction of a State Grid power company revealed that online payments, such as those made through State Grid's website, WeChat, and Alipay, accounted for a staggering 96.57%. However, a small number of payments were made on behalf of customers by area managers or business hall staff. Second, analysis of user payment times showed that, under normal circumstances, users are highly likely to pay their bills after receiving a balance warning and before their power is cut off due to unpaid bills. Third, statistics on user profiles in the current Marketing 2.0 system revealed that there are generally 1-2 designated account contact persons.

[0166] Step 2: Data Integration and Preprocessing

[0167] The power grid AI platform leverages machine learning, cluster computing, and programmability to enable anomaly analysis of basic data in power grid user profiles via Python and SQL. This achieves end-to-end intelligent processing from data processing to anomaly identification, providing crucial technical support for data governance. Distributed cluster computing supports the efficient processing of tens of millions of user profile data points. Built-in machine learning modules for classification and anomaly detection adapt to quality dimensions such as data integrity and consistency. Open interfaces are compatible with Python and SQL, allowing technicians to customize analysis logic and achieve end-to-end automation. Machine learning models identify explicit and implicit anomalies such as missing values, format errors, and logical conflicts (e.g., mismatch between electricity address and transformer area affiliation). Cluster computing enables a full scan of user profiles across the province, completing tens of millions of data points verification within hours. It supports Python scripts and SQL-based verification, quickly converting algorithm logic into reusable tasks. Local deployment ensures sensitive data privacy and complies with power safety regulations. It balances low-code drag-and-drop operation with deep programmability, addressing efficiency and customized needs. Analysis results are directly integrated with the data governance system, automatically generating rectification work orders and forming a closed-loop "discovery-resolution" process.

[0168] Data is retrieved from the power grid artificial intelligence platform, including:

[0169] (1) Obtain the "User Table" for user file account contact information. Key fields include: power supply unit, account number, name, address, and transformer area. User types are limited to low-voltage residential, low-voltage non-residential, and high-voltage.

[0170] (2) Obtain the payment information in the "payment form". Key fields include: the user's most recent N online payment records (based on workload, tentatively set at 6 times; for those with less than 6 times since account establishment, the actual number shall prevail).

[0171] (3) Obtain the "SMS table" of electricity bill SMS sending information. Key fields include: the type of the user's last 10 SMS messages, electricity bill balance, and receiving time.

[0172] Data Preprocessing: Remove closed accounts from the user profile's account contact information. Remove records with a payment amount of 0 and a payment type of "prepaid electricity bill offset" from the payment records, and compile the payment time, payment mobile phone number, etc., for the remaining records. If the same mobile phone number has been used to pay for 5 different electricity accounts, it is determined that the payment was made on behalf of the business hall staff or the area manager, and the mobile phone number should be marked separately. Compare the user table and payment table to identify users who have no recent online payment records. These users are determined to have paid in cash through the business hall or offline electricity bill collection agency and cannot be managed using the methods of this implementation plan. Their details are distributed to the respective business halls or offline electricity bill collection agencies according to the power supply area, and the staff will verify the phone number with the user when the user comes to pay.

[0173] Step 3: Establishing rules for determining authenticity

[0174] The authenticity of the account contact number is determined primarily by the consistency between the user's payment number and the account contact person's mobile phone number, the user's payment and settlement time and balance warning, and the order of power outage due to arrears. Governance suggestions and priority levels are then provided.

[0175] The first rule for determining authenticity may include:

[0176] 1. Perform data processing; exclude closed accounts, and mark payment numbers that have been used to pay more than 5 accounts. It is not recommended to fill these numbers into the account contact person. Remove online payment records where the system charge amount is 0, the charge type is prepaid to offset electricity fees, and for users with no online payment records, the business hall or offline electricity bill collection agency should verify the number.

[0177] 2. The mobile phone number of the account contact person was compared with the mobile phone numbers of the last 6 payments.

[0178] 2.1 If the comparison result is "Yes": Note: If either the billing mobile number or the payment number matches, the comparison result is "Yes". There is no need to verify the number with the user again.

[0179] 2.1.1 Scenario 1: The user has two mobile phone numbers for account contact.

[0180] If a billing mobile number matches one or more of the mobile numbers used in the last six payments, that mobile number will be retained without verification. If a billing mobile number does not match any of the last six payments, it is recommended to delete that mobile number.

[0181] 2.1.2, Scenario 2: The user has only one account contact person's mobile phone number.

[0182] The phone number used for this account will be retained and does not need to be verified.

[0183] 2.2. If the comparison result is negative: Note: If the account mobile number and the payment number do not match one by one, the comparison result is "no". The number needs to be verified with the user.

[0184] 2.2.1 Scenario 1: The mobile phone number used for the most recent 1 to 6 payments is the same.

[0185] 2.2.1.1 For cases with 3 or more payment records: (1) If the time span between the first and last payments is >= 90 days, it is recommended that the payment number be replaced with the account number. Verification priority is low. (2) If the time span between the first and last payments is < 90 days (possibly a short-term tenant), it is recommended that the payment number be replaced with the account number after verification with the user. Verification priority is medium.

[0186] 2.2.1.2 For cases with 2 or fewer payment records: (1) If the time span between the first and last payment records is <= 60 days, it is recommended to verify with the user and replace the account number with the payment number. Verification priority is high. (2) If the time span between the first and last payment records is 61 to 150 days, it is recommended to verify with the user and replace the account number with the payment number. Verification priority is medium. (3) If the time span between the first and last payment records is > 150 days, it is recommended to verify with the user and replace the account number with the payment number. Verification priority is low.

[0187] 2.2.2, Scenario 2: The mobile phone number used for the last 1 to 6 payments is inconsistent.

[0188] (1) 4 or more payment records. If a mobile number has been paid more than 3 times, it indicates a high payment frequency. It is recommended to replace the billing number with the payment number. Verification priority is medium. (2) 4 or more payment records. If there is no mobile number with a high payment frequency, verify the number with the most recent payment. Verification priority is high. (3) 3 or fewer payment records. If there is no mobile number with a high payment frequency, verify the number with the most recent payment. Verification priority is high.

[0189] The second rule for determining authenticity may include:

[0190] 1. Perform data processing; retrieve the most recent ten SMS records sent to users by the Marketing 2.0 system. The SMS types are: electricity balance warning, power outage notice for overdue payment, and payment settlement notice; extract users whose mobile phone numbers for the account contact in the previous step are compared with the mobile phone numbers for the most recent six payments and the result is "no".

[0191] 2. Compare user payment time and power outage SMS sending time. Scenario 1: After the warning SMS is sent, the user pays within 3 days and the system does not send a power outage SMS. This indicates the account holder's mobile phone number is correct. The user proactively paid after receiving the electricity balance warning SMS. Verification of the number with the user is required, but this has the highest priority. It is recommended to prioritize verifying numbers with higher frequency of recent online payments. Scenario 2: The user pays only after both the warning and power outage SMS have been sent. This indicates the account holder's mobile phone number is incorrect. The user did not receive the electricity balance warning SMS and only paid after the power outage. Verification of the number with the user is required, and this has the highest priority. It is recommended to prioritize verifying numbers with higher frequency of recent online payments. Note: 1. Electricity balance warnings, power outage notifications for overdue payments, and payment / reimbursement notifications are all sent to the account holder's mobile phone number. 2. Because an incorrect account holder's number affects power outage notifications and may cause negative user perception, this verification priority is set to the highest.

[0192] Step 4: Construct a structured language analysis model

[0193] (1) Model architecture design driven by multi-dimensional data association

[0194] The structured language model algorithm design framework for determining the accuracy of power grid user phone numbers is constructed as follows:

[0195] With "user identification entityization, behavioral data featureization, and benchmark information standardization" as its core, a three-dimensional data model architecture for determining electricity user telephone calls is constructed. This architecture utilizes SQL structured language to achieve the organic integration and mapping of cross-domain data.

[0196] Subject dimension anchoring: Using the user's unique identifier (cust_no) as the entity association key, the user's basic attribute domains (electricity management unit MGT_ORG_CODE, user category cust_cls, account status ecc_stat) are integrated to construct the user subject feature vector. The business semantics of the categorical variables are realized through CASE WHEN encoding conversion, providing the model with an accurate baseline of analysis objects.

[0197] Behavioral dimension aggregation: Introducing the user payment behavior data domain (electricity price table PAY_ORDER) and the SMS type frequency data domain (SMS table MSC_MSG_SEND_REC), a behavior sorting identifier (px) is generated in reverse order of payment time (charg_date) using the ROW_NUMBER() window function. The vertical payment records and SMS records are then transformed into a horizontal "sequence of the most recent N payment behaviors" (payment number 1-6, payment time 1-6, SMS type 1-10, SMS number 1-10, SMS content balance) using the MAX(CASE WHEN) conditional aggregation function, forming a dynamic user behavior feature matrix.

[0198] Benchmark Dimension Adaptation: Associate customer touchpoint information domain (phone table CONTACT_REC), extract the pre-registered mobile phone number for billing and the real mobile phone number for tagging as the benchmark reference system, and realize the association and alignment of the three-dimensional data of "subject-behavior-benchmark" through multi-table JOIN, providing a complete data support link for subsequent accuracy determination.

[0199] (2) Algorithmic implementation of structured feature engineering and decision logic

[0200] Leveraging the computational capabilities of the SQL structured language, an end-to-end model algorithm pipeline is constructed, encompassing feature extraction, rule validation, and result output, enabling the engineering implementation of decision-making logic.

[0201] Behavioral Feature Engineering Extraction: By combining SQL aggregation functions and window functions, user behavior is quantified and structured. Unstructured, discrete payment records and SMS records are transformed into engineered features containing dimensions such as "recent payment number, payment frequency, time span, SMS type, and SMS call," forming feature vectors that can be directly used for algorithmic judgment, solving the pain points of traditional data being scattered and difficult to analyze directly.

[0202] Multi-level judgment rule algorithm: A tiered judgment logic is constructed using a CASE WHEN conditional branch structure. The first layer realizes the baseline consistency verification of "the pre-registered mobile phone number for billing and the real mobile phone number for the tag". The second layer reserves an interface for correlation comparison of "payment behavior sequence and baseline mobile phone number". The third layer realizes the comparison of "settlement SMS with warning and power outage SMS in terms of time dimension". The matching degree between behavioral features and baseline information is calculated through logical operators such as IN / EXISTS, and a structured consistency judgment result (consistent / inconsistent / to be verified) is output.

[0203] Data cleaning rule embedding: Data quality preprocessing logic is integrated into the algorithm layer. Invalid sample filtering (ecc_stat<'09' excludes closed users) and target group screening (cust_cls limits user types) are implemented through WHERE clauses to ensure the validity and accuracy of the model input data and improve the signal-to-noise ratio of the algorithm.

[0204] (3) Adaptability design of model iteration and engineering implementation

[0205] Design a scalable, iterative, and high-performance model engineering architecture using the SQL structured language:

[0206] Dynamic feature dimension expansion: The behavior ranking identifier (px) adopts a parametric design. By adjusting the ORDER BY and PARTITION BY parameters of ROW_NUMBER(), the time window for behavior analysis can be flexibly expanded (e.g., from "last 6 times" for payment number to "last 12 times", and from "last 10 times" for SMS type to "last 15 times"), or user grouping dimensions can be added (e.g., partitioned by electricity management unit MGT_ORG_CODE) to adapt to the analysis needs of different scenarios.

[0207] Standardized Judgment Rule Interface: The model output fields (such as payment numbers 1-6, consistency results of billing mobile phone numbers) adopt standardized naming and data types, forming the input interface for rule calculation. When adding new judgment rules (such as "weight judgment of high-frequency payment numbers") in the future, they can be directly extended through SQL logic based on existing feature fields without reconstructing the underlying data model.

[0208] Platform computing power adaptation and optimization: Utilizing the capabilities of the distributed computing engine, the processing efficiency of tens of millions of user data is improved through SQL optimization techniques such as GROUP BY parallel computing and temporary table (TT) pre-aggregation; the platform supports the periodic automatic operation of model algorithms through the platform task scheduling mechanism, completing incremental data updates and real-time output of judgment results, and realizing full-process automation of model engineering implementation.

[0209] (4) Key implementation code examples of the structured model:

[0210] To retrieve the payment number and payment time:

[0211] Retrieve the following information from the user table "yx.ODS_CMS20_EMSS_CUC_ELEC_CONS_CUST CONS" and the electricity price table "yx.ODS_CMS20_EMSS_PFC_PAY_ORDER": [Electricity Management Unit, User Number, Payment Time, Payment Number]. The corresponding codes for these fields are [MGT_ORG_CODE, cust_no, charg_date, contact_tel].

[0212] The user types are limited to [low-voltage residential, low-voltage non-residential, high-voltage], and users who have cancelled their accounts are excluded. The corresponding codes are [CONS.cust_cls ='03'THEN'Low-voltage residential', "CONS.cust_cls ='02'THEN'Low-voltage non-residential', "CONS.cust_cls ='01'THEN'High-voltage'] and [CONS.ecc_stat < '09'].

[0213] Output the user's payment records from 1 to 6, with the corresponding codes as follows:

[0214]

【MAX(CASE WHEN px = 1 THEN Payment Number END) AS Payment Number 1,

[0215] MAX(CASE WHEN px = 1 THEN Payment Time END) AS Payment Time 1,

[0216] MAX(CASE WHEN px = 6 THEN Payment Number END) AS Payment Number 6,

[0217] MAX(CASE WHEN px = 6 THEN Payment Time END) AS Payment Time 6;

[0218] To retrieve SMS type and time:

[0219] Retrieve the user's [SMS type, unit number, user number, mobile number, and SMS reception time] from the SMS table "yx.ADS_CST_EMSS_MSC_MSG_SEND_REC". The corresponding codes for these fields are [busi_obj_name, MGT_ORG_CODE, cust_no, REGEXP_SUBSTR(chan_cont, '[0-9]+'), rcv_time]. Specify the SMS messages as [Sent successfully, SMS has taken effect], with the corresponding codes being [rec.send_Rslt = '01', rec.valid_flag = '02'].

[0220] Output the user's SMS records from 1 to 10, the corresponding code is:

[0221]

MAX(CASE WHEN LV= 1 THEN SMS type||'Mobile number:'||Mobile number END) AS Last type

[0222] MAX(CASE WHEN LV= 1 THEN SMS Receive Time END) AS Last SMS Receive Time

[0223] MAX(CASE WHEN LV= 1 THEN Balance END) AS Last Balance

[0224] MAX (CASE WHEN LV= 1 THEN SMS type||'Mobile number:'||Mobile number END) AS Last 10 types,

[0225] MAX(CASE WHEN LV= 1 THEN SMS Reception Time END) AS the time of the last 10 SMS messages.

[0226] MAX(CASE WHEN LV= 1 THEN Balance END) AS Balance of the last 10 transactions;

[0227] To retrieve the mobile phone number of the account contact person pre-registered in the user's electronic profile:

[0228] Using the user table "yx.ODS_CMS20_EMSS_CUC_ELEC_CONS_CUST CONS" and the telephone table "yx.ODS_CMS20_EMSS_CUC_CONTACT_REC B", the user types are limited to "CONS.cust_cls ='03'THEN'Low-voltage Resident'", "CONS.cust_cls ='02'THEN'Low-voltage Non-resident'", "CONS.cust_cls ='01'THEN'High-voltage'", and "CONS.cust_cls ='00'THEN'Assessment'". Users who have cancelled their accounts are excluded, "CONS.ecc_stat < '09'", and the customer's reserved account mobile phone number is output.

[0229] To verify the accuracy of the mobile phone number used for billing, the following steps are required:

[0230] After obtaining the payment number and the account mobile number, a temporary table is created through the Sophon platform. The corresponding code is:

SELECT TT.*, (CASE WHEN TT.Account Mobile Number 1 = TT.Label Customer's Own Mobile Number THEN 'Account Mobile Number 1 matches Customer's Own Mobile Number' WHEN TT.Account Mobile Number 2 = TT.Label Customer's Own Mobile Number THEN 'Account Mobile Number 2 matches Customer's Own Mobile Number' ELSE '' END)

[0231] =IF(MID(INDEX(D:AG,ROW(),MATCH(TRUE,INDEX((D2:AG2<>"")),0),0)),1,4)="SMS Reply Stopped",INDEX(D:AG,ROW(),MATCH(TRUE,INDEX((D2:AG2<>"")),0),0)+1),IF(MID(INDEX(D:AG,ROW(),MATCH(TRUE,INDEX((D2:AG2<>"")),0),0)+3),1,4)="SMS Reply Stopped".

[0232] Step 5: Model Execution and Output

[0233] Run the SQL model and output the analysis results, including:

[0234] User Basic Information: District / County, Power Supply Station, User Number, Substation Number, Substation Name, Electricity Address, User Category; User Phone Number: Accounting Contact Number 1, Accounting Contact Number 2, Payment Number 1-6; Whether the Payment Numbers of the Last 1-6 Times are Consistent: Yes or No; Pattern of the Payment Numbers of the Last 1-6 Times: For example, if all are consistent, output AAAAAA; if the second is inconsistent with the others, output ABAAAA, etc.; Time Span of the Last 1-6 Times (Days): Calculated based on the time span of the first and sixth times; Comparison Result between Accounting Contact Number and Payment Number: Yes or No (Yes -- no need to verify the user's mobile phone number, No -- need to verify the user's mobile phone number); Last Warning SMS Time; Last Power Outage Time; Last Account Closure Time; Whether Payment Numbers 1-6 are Internal Employee Mobile Phone Numbers: Yes / No; Verification Priority: High / Medium / Low; Governance Guidelines: For example, for a user whose comparison result between the Accounting Contact Number and Payment Number is "No", provide a number replacement suggestion and explanation based on the frequency of payment number repetition;

[0235] Step 6: Effectiveness Evaluation and Optimization

[0236] The output results are applied to actual work, comparing the judgment conclusions based on the rules with the actual situation, and collecting data on users whose judgment results do not match the actual situation, facilitating further rule optimization. Additionally, parameters can be customized according to different power supply units based on actual needs, such as expanding payment records to the most recent 12 times.

[0237] This implementation plan adopts different management methods for users with different situations. For example, users who have no online payment records since their account was opened are screened out at the beginning. These users usually pay in cash through business halls or offline electricity bill collection agencies. They cannot be managed using the methods of this implementation plan. Instead, they can be distributed to various business halls or offline electricity bill collection agencies according to the power supply area. When users come to pay, their phone numbers will be verified.

[0238] This implementation plan verifies the authenticity of the billing contact's phone number before users experience any negative feedback. For example, it compares the user's six most recent payment numbers with the billing contact's phone number in the current Marketing 2.0 system file. If all six matches, the number in the current file is considered authentic and requires no intervention. This comparison can be conducted multiple times per month as needed, verifying authenticity before users call the service hotline.

[0239] This implementation plan can determine governance priorities. For example, it compares the consistency of the user's most recent 6 payment numbers with the billing contact phone number in the current Marketing 2.0 system file, and combines this with the user's payment time. If all 6 payments are inconsistent and the payment was made after the overdue payment and power outage notice was sent, the number in the current file is determined to be authentic, and the governance priority is placed first.

[0240] This implementation plan tailors a governance strategy for each user identified as requiring remediation. For example, it compares the user's six most recent payment numbers with the billing contact phone number in the current Marketing 2.0 system file. Considering the payment time, if all six payments are inconsistent and the payment was made after the overdue payment and power outage notification was sent, the number in the current file is considered inaccurate. Further analysis of the six payment numbers provides a remediation strategy. For example, if all six payment numbers are the same, the suggestion is "the payment number can replace the billing number"; if a maximum of four payment numbers are the same, it is suggested to prioritize verifying that number, then verify numbers with lower frequency of occurrence; if all six numbers are different, it is suggested to prioritize verifying the most recent payment number. The output strategy can guide the area manager in collecting phone numbers, reducing the frequency of user visits and improving efficiency.

[0241] This implementation plan, for the first time in the scenario of determining the accuracy of telephone numbers in the power grid, integrates multi-source big data analysis, machine learning optimization, and low-code programmable technology to construct a fully intelligent governance system. First, relying on a distributed big data engine, it achieves real-time association and automated behavioral feature engineering of heterogeneous data such as "accounting contact data, payment behavior data, and SMS interaction data," extracting multi-dimensional time-series features such as user payment frequency, time span, and SMS reach rate. Second, it introduces a semi-supervised machine learning model to perform hierarchical learning on features such as "matching degree between account numbers and payment numbers" and "payment behavior patterns," dynamically optimizing the threshold values ​​for the judgment rules of "matching → number of payments → time span," improving the accuracy of abnormal number identification. Finally, through the platform's Python programmable capabilities and the collaboration of low-code components, the multi-branch business judgment logic is transformed into an automated algorithm pipeline, achieving fully engineered delivery from "data association - intelligent judgment - one-click work order generation," breaking through the efficiency and accuracy bottlenecks of traditional manual governance.

[0242] By dynamically identifying and categorizing anomalies, the system first outputs scenario-based conclusions such as "requires manual verification" and "no verification required." Secondly, for users requiring "manual verification," it further determines their governance priority. Finally, based on this priority, it provides guidance on which phone numbers to prioritize for verification for each user category, considering factors such as recent online payment frequency and the time span between the first and last payments. This innovative output addresses the shortcomings of traditional governance methods, which often lack comprehensive or limited governance suggestions. Frontline staff can quickly begin work upon receiving the output, reducing the workload of analysis and comparison and significantly improving efficiency.

[0243] According to statistics from January to March 2025, approximately 18.18% of the mobile phone numbers of account contact persons in SS Company's user electronic files were abnormal. The success rate of sending power outage SMS messages to users was only 56.32%. The abnormality of account contact person mobile phone numbers increases the service risk of SS Company and urgently needs to be addressed. Given the large volume of abnormal data, the inefficiency of manually identifying anomalies and collecting correct numbers through visits to users, and the inability to determine the authenticity of mobile phone numbers in the current system in advance, after business research and thorough discussion, an innovative method for determining the authenticity of customer contact phone numbers based on a power grid artificial intelligence platform was invented.

[0244] After a round of remediation using the methods described above, SS Company's core indicators improved as follows:

[0245] Power outage SMS messages are accurately delivered to the account contact person's mobile phone, and the delivery success rate of pre-outage notification SMS messages has increased from 56.32% to 87.14%. The authenticity of mobile phone numbers has improved, and users receiving balance warnings and overdue payment reminders from accounts other than their own has decreased significantly. The number of work orders for user complaints about misdelivered SMS messages has decreased by 46.15%. At the same time, the timely and accurate delivery of electricity bill SMS messages encourages users to pay on time, and the on-time payment rate has improved.

[0246] According to an embodiment of the present invention, an electronic device is provided; please refer to... Figure 3 The electronic device in this embodiment may include one or more of the following components: a processor, a network interface, memory, non-volatile memory, and one or more application programs, wherein the one or more application programs may be stored in non-volatile memory and configured to be executed by one or more processors, and the one or more programs are configured to perform the methods as described in the foregoing method embodiments.

[0247] According to embodiments of the present invention, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a computer, causes the computer to perform the method described in any of the above embodiments.

[0248] According to embodiments of the present invention, a computer program product comprising instructions is also provided, which, when executed by a computer, cause the computer to perform a method in any of the above embodiments.

[0249] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for determining the authenticity of phone numbers based on a power grid artificial intelligence platform, characterized in that, include: Acquire user profile data, historical online payment behavior data, and electricity bill SMS interaction data of the target user group; Using user identifiers as association keys, the user profile data, historical online payment behavior data, and electricity bill SMS interaction data are associated and preprocessed to construct a unified analysis dataset; Based on the unified analysis dataset, a preset first comparison process is performed to obtain the result of the first comparison; wherein, the first comparison process means comparing the consistency of the billing contact person's phone number with at least one historical payment contact phone number; If the result of the first comparison indicates inconsistency, a preset second comparison process is performed based on the unified analysis dataset to obtain the result of the second comparison; wherein, the second comparison process refers to comparing the order of the sending time of the electricity balance warning SMS and the payment success time. Based on the results of the first comparison and / or the second comparison, a result is generated to determine the authenticity of the contact phone number of the accountant and corresponding governance strategy information.

2. The method according to claim 1, characterized in that, The step of using user identifiers as association keys to associate and preprocess user profile data, historical online payment behavior data, and electricity bill SMS interaction data to construct a unified analysis dataset includes: A first cleaning process is performed on the user profile data to exclude user data that has been deactivated. A second cleaning process is performed on the historical online payment behavior data to remove invalid payment records and mark the payment on behalf of multiple users. From the historical online payment behavior data, identify a subset of users with no valid online payment records; Using the user identifier as the association key, the cleaned user profile data, the cleaned historical online payment behavior data, and the corresponding electricity bill SMS interaction data are linked and integrated to generate the unified analysis dataset.

3. The method according to claim 2, characterized in that, The step of performing a second cleaning process on the historical online payment behavior data to remove invalid payment records and mark payment on behalf of multiple users includes: Records with zero payment amount or prepayment offset type are removed to obtain valid payment records; Based on the valid payment records, count the number of associated users corresponding to each payment contact number; Phone numbers associated with more than a preset threshold for payment contact information will be marked as payment on behalf data. The step of identifying a subset of users with no valid online payment records from the historical online payment behavior data includes: Users who have no valid payment records within a preset historical time period are selected to form the user subset; The step of linking and integrating the cleaned user profile data, cleaned historical online payment behavior data, and corresponding electricity bill SMS interaction data using the user identifier as the association key to generate the unified analysis dataset includes: Using user profile data as the main table and user identifier as the association key, historical online payment behavior data and electricity bill SMS interaction data are associated with the main table through a left join to form the unified analysis dataset.

4. The method according to claim 1, characterized in that, The step of performing a preset first-level comparison process based on the unified analysis dataset to obtain the result of the first-level comparison includes: Extract a preset number of historical payment contact phone numbers from the unified analysis dataset, arranged in descending order of payment time. The account contact person's phone number is compared one by one with a preset number of historical payment contact phone numbers. If at least one historical payment contact phone number matches the account contact person's phone number, the result of the first comparison is determined to be consistent. If all preset number of historical payment contact phone numbers do not match the account contact person's phone number, the result of the first comparison is determined to be inconsistent.

5. The method according to claim 4, characterized in that, The step of extracting a preset number of historical payment contact phone numbers from the unified analysis dataset, arranged in reverse chronological order by payment time, includes: Grouping historical online payment behavior data based on user identifiers; Within each group, use database window functions to sort payment records in descending order of payment success time and generate a sort number for each record; From each group, extract the historical payment contact phone numbers corresponding to payment records whose sorting number is less than or equal to a preset number.

6. The method according to claim 4, characterized in that, The step of performing a preset second alignment process based on the unified analysis dataset to obtain the second alignment result when the result of the first alignment indicates inconsistency includes: From the unified analysis dataset, extract the sending time of the target user's electricity balance warning SMS and power outage SMS for overdue payment, as well as the payment success time; Based on the order of the sending time and the payment success time, a risk level determination result is generated as the second comparison result; wherein: if the payment success time is after the time of sending the electricity balance warning SMS and before the time of sending the power outage SMS due to overdue payment, it is determined to be a low risk level; if the payment success time is after the time of sending the power outage SMS due to overdue payment, it is determined to be a high risk level.

7. The method according to claim 6, characterized in that, The step of generating a verification result for the authenticity of the account contact person's phone number and corresponding governance strategy information based on the results of the first comparison and / or the second comparison includes: In response to the inconsistency of the first comparison result, a preliminary authenticity judgment result and a first governance sub-strategy including the first verification priority are generated; Based on the risk level determination result obtained from the second comparison, the preliminary authenticity determination result and the first verification priority are corrected to generate the final authenticity determination result and the final verification priority. The final authenticity determination result, the final verification priority, and the first governance sub-strategy are combined to form the authenticity determination result and the corresponding governance strategy information; wherein, when the risk level determination result is a high-risk level, the final authenticity determination result is corrected to be untrue and the final verification priority is set to the highest level.

8. A device for determining the authenticity of a telephone number, characterized in that, include: The acquisition module is used to acquire user profile data, historical online payment behavior data, and electricity bill SMS interaction data of the target user group. The module is used to associate and preprocess the user profile data, historical online payment behavior data, and electricity bill SMS interaction data with the user identifier as the association key, so as to build a unified analysis dataset. The first comparison processing module is used to perform a preset first comparison processing based on the unified analysis dataset to obtain the result of the first comparison; wherein, the first comparison means comparing the consistency of the billing contact person's contact number with at least one historical payment contact number. The second comparison processing module is used to perform a preset second comparison processing based on the unified analysis dataset when the result of the first comparison indicates inconsistency, and obtain the result of the second comparison; wherein, the second comparison refers to comparing the order of the sending time of the electricity balance warning SMS and the payment success time. The generation module is used to generate a result determining the authenticity of the contact number of the account contact person and corresponding governance strategy information based on the results of the first comparison and / or the second comparison.

9. An electronic device, characterized in that, include: A memory, and one or more processors communicatively connected to the memory; The memory stores instructions that can be executed by the one or more processors to cause the one or more processors to implement the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The readable storage medium stores a computer program that, when executed by a processor, implements the method of any one of claims 1 to 7.

Images