Method, device and equipment for realizing new business data dashboard

Abstract

The application relates to a new purchase business data board implementation method, device and equipment, and relates to the technical field of data processing. The method obtains multi-source data based on a preset adaptive interface, and based on a user identity multi-dimensional association algorithm (three types of features of a user account, a mobile phone number and a device identifier are bound and matched), automatically collects the same user data scattered in different platforms, generates unified user behavior data of each user, realizes automatic integration and unified management of multi-source heterogeneous data, does not need an operation personnel to cross-platform switching query and manual integration, significantly reduces data integration cost, and improves data calling efficiency.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and specifically to a method, apparatus, and equipment for implementing a new purchase business data dashboard. Background Technology

[0002] New customer acquisition (typically applied in online education, paid knowledge services, and live-streaming e-commerce) involves a long conversion path, diverse touchpoints, and high time sensitivity. It typically involves multi-source heterogeneous data, including user behavior data (payment link browsing, order generation), live-streaming interaction data (class attendance, online status), and outbound call follow-up data (coverage, connection, duration). Current technologies for new customer acquisition data dashboards generally face the following technical challenges:

[0003] Data fragmentation and high integration costs: Core data such as conversion, time period, and outbound calls are stored on different business platforms. Operations personnel need to switch between platforms to query and manually integrate data, which is cumbersome and time-consuming, and cannot achieve centralized management and rapid access to data.

[0004] Manual statistics are inefficient and inaccurate: Core business data relies on daily manual collection, calculation and summarization by operations staff, which not only consumes a lot of core energy, but is also prone to statistical errors due to formula errors, data omissions or caliber deviations, directly affecting the accuracy of business decisions.

[0005] Inconsistent indicator definitions and severe data silos between departments: Each department manually processes data based on its own business needs, resulting in multiple statistical definitions for the same business indicator, poor cross-departmental data consistency, high communication and coordination costs, and an inability to support overall business review and strategic decision-making at the enterprise level.

[0006] Therefore, there is an urgent need for a data statistics solution that adapts to the entire process of new education purchase business in order to solve the technical problems of fragmented multi-source data, inefficient manual statistics, and inconsistent indicator standards. Summary of the Invention

[0007] In view of this, the purpose of the present invention is to provide a method, apparatus and equipment for implementing a new purchase business data dashboard, so as to overcome the current problems of fragmented multi-source data, inefficient manual statistics and inconsistent indicator standards.

[0008] To achieve the above objectives, the present invention adopts the following technical solution: On the one hand, a method for implementing a new purchase business data dashboard includes: Based on a preset adaptation interface, multi-source data is acquired; the multi-source data includes data from different platforms. Based on a multi-dimensional association algorithm for user identity, the algorithm binds and matches three types of features: user account, mobile phone number, and device identifier. It aggregates the same user data scattered across different platforms and obtains user behavior data for each user. The user's current state is determined based on the user behavior data, and the current business scenario in which the user is located is determined based on the current state and the scenario boundary conditions; wherein, the scenario boundary conditions are pre-stored in a scenario boundary condition library; When a change in the current business scenario is detected, a scenario switching process is initiated. The scenario switching process includes: switching the calculation rule of the statistical data from a first indicator corresponding to a first scenario to a second indicator corresponding to a second scenario, wherein the first indicator is used to define the scope of users to be counted in the first scenario, and the second indicator is used to define the scope of users to be counted in the second scenario; switching the comparison benchmark from historical benchmark data of the first scenario to historical benchmark data of the second scenario; and switching the alarm rule from a first alarm rule corresponding to the first scenario to a second alarm rule corresponding to the second scenario. The first alarm rule includes a first set of monitoring indicators and a corresponding first threshold value, and the second alarm rule includes a second set of monitoring indicators and a corresponding second threshold value. Based on the switched second indicator and the predefined standardized indicator caliber, calculate various business indicators in the current scenario; wherein, the standardized indicator caliber predefines a unique value rule for each business indicator, and the standardized indicator caliber includes at least one of the following: number of payment link views, number of orders generated, number of successful payments, number of services activated, number of students attending classes, number of online students, number of outbound call coverage, and connection rate; The calculated business indicators are compared with the historical benchmark data after the switch to generate deviation analysis results; and when the fluctuation of any business indicator exceeds the corresponding second threshold value in the second alarm rule after the switch, an alarm message is generated. The various business metrics, deviation analysis results, and alarm information in the current scenario are output to the corresponding business dashboard.

[0009] Optionally, the user identity-based multi-dimensional association algorithm binds and matches three types of features: user account, mobile phone number, and device identifier, aggregating the same user data scattered across different platforms to obtain user behavior data for each user, including: A unified identity profile is constructed for each user, which includes three types of feature fields: user account, mobile phone number, and device identifier, as well as the corresponding credibility score for each field. When a user behavior record is obtained from any data source, one or more feature values ​​are extracted from the user account, mobile phone number, and device identifier carried in the user behavior record, and the feature values ​​are used as indexes to search in the existing unified identity profile. If a matching unified identity profile is found, the user behavior record will be aggregated under that unified identity profile, and the confidence score of each feature field in the unified identity profile will be dynamically updated according to the feature type and matching confidence of this match. If no matching unified identity profile is found, a new unified identity profile is created, and the currently extracted feature values ​​are used as the initial values ​​to assign initial confidence scores to each feature field in the new unified identity profile. When two user behavior records from different data sources are matched to two different unified identity profiles, but there is at least one common feature value between the two unified identity profiles and the confidence score of the common feature value exceeds a preset threshold, the two unified identity profiles are merged into one, and all user behavior records of the two are merged. All user behavior records aggregated under the same unified identity profile will be used as the user's user behavior data.

[0010] Optionally, determining the user's current state based on the user behavior data, and determining the user's current business scenario based on the current state and scenario boundary conditions, includes: The user behavior data of each user is arranged in chronological order of occurrence. The latest valid behavior records of the user are filtered, and the event type, occurrence timestamp and associated course or class identifier corresponding to the latest valid behavior records are extracted to determine the user's current status. The user's current state is matched with the scene boundary conditions in the scene boundary condition library to obtain the user's current business scene. Each scene boundary condition includes: boundary type, state before boundary, state after boundary, and the type and number of events required to trigger the boundary condition. The boundary type includes time boundary, behavior boundary, or state boundary.

[0011] Optionally, the process of switching scenarios when a change in the current business scenario is detected includes: Continuously monitor the boundary conditions related to the current business scenario in the scenario boundary condition library. Each scenario boundary condition includes the boundary type, the state before the boundary, the state after the boundary, and the triggering condition. When any boundary condition is triggered, it is determined whether the trigger condition meets the scene switching requirements. The trigger conditions include: time reaching a preset threshold, user behavior event type matching, or user state duration exceeding a preset value. If the scenario switching requirements are met, it is determined that the current business scenario has changed, and the scenario switching process is executed. If the scenario switching requirements are not met, the current business scenario will remain unchanged.

[0012] Optional, also includes: Predefined four-level unified drill-down dimension tree from L0 to L3; In response to a user's drill-down operation in any business scenario, the currently selected dimension anchor path is recorded. The dimension anchor path includes dimension identifiers from L0 to each level of the current layer. When a user switches from the current business scenario to another business scenario, the dimension anchor path is automatically inherited, and the inherited anchor path is used as the filtering condition in the new scenario to recalculate various business indicators in the new scenario. When the same dimension name has different business meanings in different business scenarios, the dimension nodes in the anchor path are converted into semantically equivalent nodes corresponding to the target scenario through the dimension mapping table.

[0013] Optional, also includes: Preset events under the same user ID are concatenated in order of timestamp; Label each event with its corresponding scene tag; Based on the concatenated behavior sequence, a user-level scene behavior view is generated. The contribution metrics of each scenario to the final transaction conversion are aggregated and calculated. These contribution metrics include: user retention rate, conversion rate improvement rate, and conversion decay rate between scenarios.

[0014] Optional, also includes: The user's filtering operations are obtained through multi-dimensional filtering and drill-down analysis interfaces; In response to user filtering operations on any dimension or combination of dimensions, dynamically update the calculation range of various business indicators in the current business scenario, and re-aggregate and display the data according to the filtered dimensions; Different default dimension views are preset for different roles, including: operations personnel, management personnel, and sales personnel. The default view for each role contains the core dimensions and indicator set that the role focuses on.

[0015] Optional, also includes: All processed business metrics, deviation analysis results, and alarm information are written to the memory cache in real time. The latest data is retrieved from the memory cache at a preset refresh frequency, and the content displayed on the dashboard is refreshed. It supports users from multiple departments or roles to view real-time business dynamics online simultaneously, and different users automatically load the corresponding dimension views and data ranges based on preset permissions; When the fluctuation of any business metric exceeds the alarm threshold, an alarm notification is pushed to the relevant business personnel, and the abnormal metric is highlighted to support users in adjusting their business strategies in a timely manner.

[0016] On the other hand, a new purchase business data dashboard implementation system includes: The acquisition module is used to acquire multi-source data based on a preset adaptation interface; the multi-source data includes data from different platforms. The aggregation module is used to bind and match three types of features—user account, mobile phone number, and device identifier—based on a multi-dimensional association algorithm of user identity, and to aggregate the same user data scattered across different platforms to obtain user behavior data for each user. The determination module is used to determine the user's current state based on the user behavior data, and to determine the current business scenario in which the user is located based on the current state and scenario boundary conditions; wherein, the scenario boundary conditions are pre-stored in a scenario boundary condition library; The switching module is used to perform a scenario switching process when a change in the current business scenario is detected. The scenario switching process includes: switching the calculation rule of the statistical data from a first indicator corresponding to a first scenario to a second indicator corresponding to a second scenario, wherein the first indicator is used to define the scope of users to be counted in the first scenario, and the second indicator is used to define the scope of users to be counted in the second scenario; switching the comparison benchmark from historical benchmark data of the first scenario to historical benchmark data of the second scenario; and switching the alarm rule from a first alarm rule corresponding to the first scenario to a second alarm rule corresponding to the second scenario. The first alarm rule includes a first set of monitoring indicators and a corresponding first threshold value, and the second alarm rule includes a second set of monitoring indicators and a corresponding second threshold value. The standardization module is used to calculate various business indicators in the current scenario based on the switched second indicator and the predefined standardized indicator caliber. The standardized indicator caliber predefines a unique value rule for each business indicator and includes at least one of the following: number of payment link views, number of orders generated, number of successful payments, number of services activated, number of students attending classes, number of online students, number of outbound call coverage, and connection rate. The analysis module is used to compare the calculated business indicators with the historical benchmark data after the switch and generate deviation analysis results; and to generate alarm information when the fluctuation of any business indicator exceeds the corresponding second threshold value in the second alarm rule after the switch. The output module is used to output various business indicators, deviation analysis results and alarm information in the current scenario to the corresponding business dashboard.

[0017] On another front, a device for implementing a new business data dashboard includes a processor and a memory, wherein the processor is connected to the memory. The processor is used to call and execute the program stored in the memory; The memory is used to store the program, which is at least used to execute the new purchase business data dashboard implementation method described in any of the above-mentioned methods.

[0018] The embodiments provided by the present invention have at least the following beneficial effects: This invention acquires multi-source data based on a preset adaptation interface and automatically aggregates user data scattered across different platforms using a multi-dimensional user identity association algorithm (binding and matching three types of features: user account, mobile phone number, and device identifier). This generates unified user behavior data for each user, achieving automated integration and unified management of multi-source heterogeneous data. It eliminates the need for operations personnel to switch between platforms and manually integrate data, significantly reducing data integration costs and improving data retrieval efficiency. Furthermore, by automatically determining the user's current state based on user behavior data and automatically identifying the current business scenario based on the current state and scenario boundary conditions, the invention automatically executes a scenario switching process (including simultaneous switching of statistical data, comparison benchmarks, and alarm rules) when a scenario change is detected. Then, based on the switched indicators and standardized indicator definitions, it automatically calculates various business indicators. The entire process requires no manual intervention, avoiding statistical errors caused by formula errors, data omissions, or caliber deviations during manual collection, calculation, and aggregation. This significantly improves data processing efficiency while ensuring statistical accuracy. In addition, by pre-defining standardized indicator criteria, a unique value rule was set for each business indicator (including the number of payment link views, the number of orders generated, the number of successful payments, the number of services activated, the number of students attending classes, the number of online students, the number of outbound call coverage, the connection rate, etc.). This standardized criterion is used as the unified basis for indicator calculation in all scenarios. Whether in the whole-link conversion, real-time monitoring during classes, or outbound call correlation analysis scenarios, the same value rule is used for the calculation of the same indicator. This eliminates the difference in criteria caused by the processing of data by different departments, realizes the consistency and comparability of cross-departmental data, and provides a reliable data foundation for the overall decision-making of the enterprise. Attached Figure Description

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

[0020] Figure 1 This is a flowchart illustrating a method for implementing a new purchase business data dashboard according to an embodiment of the present invention. Figure 2 This is a schematic diagram of the structure of a new purchase business data dashboard implementation system provided in an embodiment of the present invention; Figure 3This is a schematic diagram of the structure of a new purchase business data dashboard implementation device provided in an embodiment of the present invention. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be described in detail below. Obviously, the described embodiments are merely some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other implementation methods obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0022] As described in the background section, existing new purchase business data dashboards generally face the following technical challenges: Data fragmentation and high integration costs: Core data such as conversion, time period, and outbound calls are stored on different business platforms. Operations personnel need to switch between platforms to query and manually integrate data, which is cumbersome and time-consuming, and cannot achieve centralized management and rapid access to data.

[0023] Manual statistics are inefficient and inaccurate: Core business data relies on daily manual collection, calculation and summarization by operations staff, which not only consumes a lot of core energy, but is also prone to statistical errors due to formula errors, data omissions or caliber deviations, directly affecting the accuracy of business decisions.

[0024] Inconsistent indicator definitions and severe data silos between departments: Each department manually processes data based on its own business needs, resulting in multiple statistical definitions for the same business indicator, poor cross-departmental data consistency, high communication and coordination costs, and an inability to support overall business review and strategic decision-making at the enterprise level.

[0025] Therefore, there is an urgent need for a data statistics solution that adapts to the entire process of new education purchase business in order to solve the technical problems of fragmented multi-source data, inefficient manual statistics, and inconsistent indicator standards.

[0026] Based on this, embodiments of the present invention provide a method, system, and device for implementing a new purchase business data dashboard to solve the technical problems of fragmented multi-source data, inefficient manual statistics, and inconsistent indicator definitions.

[0027] Figure 1 This is a flowchart illustrating a method for implementing a new purchase business data dashboard according to an embodiment of the present invention. Please refer to [link / reference]. Figure 1 This embodiment may include the following steps: Step S101: Obtain multi-source data based on a preset adaptation interface; the multi-source data includes data from different platforms.

[0028] It should be noted that the execution subject of the technical solution provided in this embodiment can be any controller with data and instruction processing functions, such as a PLC, a microcontroller, etc.; the controller can be set in any electronic device, such as a smart terminal, a smartwatch, a calculator, a server, etc.

[0029] A server can be an electronic device with a certain computing power. It may include a network communication module, a processor, and memory. Alternatively, a server can refer to software running on an electronic device. A server can also be a distributed server, a system with multiple processors, memory, network communication modules, etc., operating collaboratively. Or, a server can be a server cluster formed by several servers. Furthermore, with the development of science and technology, a server can also be a new technological means capable of realizing the corresponding functions of the embodiments described in the specification. For example, it could be a new form of "server" based on quantum computing.

[0030] When acquiring multi-source data, you can use preset adaptation interfaces to collect multi-source data in real time from user behavior tracking systems (such as Volcano Engine), live interactive reporting systems (such as XXAPP), outbound call business management systems (such as CRM), etc.

[0031] Step S102: Based on the multi-dimensional association algorithm of user identity, bind and match three types of features: user account, mobile phone number, and device identifier, and collect the same user data scattered across different platforms to obtain user behavior data for each user.

[0032] For example, after obtaining multi-source data, the data of the same user can be aggregated by three types of features: user account, mobile phone number, and device identifier, to obtain the aggregated user behavior data for each user.

[0033] Step S103: Determine the user's current state based on the user behavior data, and determine the current business scenario in which the user is located based on the current state and the scenario boundary conditions; wherein, the scenario boundary conditions are pre-stored in the scenario boundary condition library.

[0034] The current status of a user is determined based on the collected user behavior data. Specifically, the user behavior data for each user is arranged in chronological order of occurrence, the latest valid behavior records are filtered, and the event type, timestamp of occurrence, and associated course or class identifier are extracted.

[0035] For example, if user A generates an "enter live broadcast room" event at 16:05, then user A's current state will be determined as "live broadcast during class".

[0036] Then, the current state is matched against scene boundary conditions in the scene boundary condition library. The scene boundary condition library pre-stores multiple boundary conditions, each of which includes: boundary type (time boundary, behavior boundary, or state boundary), state before boundary, state after boundary, and triggering condition.

[0037] For example, a time boundary condition is: when the time reaches 16:30, switch the user from the "live class period" to the "post-class conversion period". A behavior boundary condition is: when the user generates an "order generation" event, switch the user from the "post-class conversion period" to the "order conversion period".

[0038] Step S104: When a change in the current business scenario is detected, a scenario switching process is initiated. The scenario switching process includes: switching the calculation rule of the statistical data from a first indicator corresponding to a first scenario to a second indicator corresponding to a second scenario, wherein the first indicator is used to define the scope of users to be counted in the first scenario, and the second indicator is used to define the scope of users to be counted in the second scenario; switching the comparison benchmark from historical benchmark data of the first scenario to historical benchmark data of the second scenario; and switching the alarm rule from a first alarm rule corresponding to the first scenario to a second alarm rule corresponding to the second scenario. The first alarm rule includes a first set of monitoring indicators and a corresponding first threshold value, and the second alarm rule includes a second set of monitoring indicators and a corresponding second threshold value.

[0039] Continuously monitor the boundary conditions related to the current scene in the scene boundary condition library. When any boundary condition is triggered, determine whether the trigger condition meets the scene switching requirements.

[0040] For example, when the time reaches 16:30, the time boundary condition of "live broadcast during class → conversion period after class" is detected to be triggered, and it is determined that the scene switching requirement is met, and the scene switching process is executed.

[0041] The scene switching process includes three synchronous switching operations: Statistical data switching: The calculation rule for statistical data is switched from "number of students attending class" in the first scenario to "number of students attending class but not paying" in the second scenario; where statistical data can be the statistical denominator, and after calculating the statistical denominator, it is used as the denominator of the statistical data.

[0042] Comparison benchmark switching: Switch the comparison benchmark from the historical benchmark data of the first scenario (such as the in-class conversion rate of the same period last week) to the historical benchmark data of the second scenario (such as the post-class conversion rate of the same period last week).

[0043] Alarm rule switching: Switch the alarm rule from the alarm rule corresponding to the first scenario (such as the fluctuation of online users exceeding 20% ​​during the monitoring class) to the alarm rule corresponding to the second scenario (such as the fluctuation of order generation rate exceeding 15% after the monitoring class). Step S105: Based on the second indicator after switching and the predefined standardized indicator caliber, calculate various business indicators under the current scenario; wherein, the standardized indicator caliber predefines a unique value rule for each business indicator, and the standardized indicator caliber includes at least one of the following: number of payment link views, number of orders generated, number of successful payments, number of services activated, number of students attending classes, number of online students, number of outbound call coverage, and connection rate.

[0044] For example, based on the second indicator after the switch (such as "number of students who attended class but did not pay") and the predefined standardized indicator caliber, calculate various business indicators in the current scenario.

[0045] The standardized metrics predefine a unique value rule for each business metric. For example, "Successful Payments" is defined as the number of users whose payment system callback returns a success status code and whose amount is greater than 0; "Attendance" is defined as the number of users who enter the live broadcast room and whose heartbeat reporting duration exceeds 1 minute.

[0046] Using "number of students who have attended classes but have not paid" as the denominator, the scope of users to be counted is determined to be "users who have attended classes but have not paid". Then, the corresponding indicator values ​​are extracted from the collected user behavior data and aggregated for calculation to obtain business indicators such as conversion rate and coverage in the current scenario.

[0047] Step S106: Compare the calculated business indicators with the historical benchmark data after the switch to generate deviation analysis results; and generate alarm information when the fluctuation range of any business indicator exceeds the corresponding second threshold value in the second alarm rule after the switch.

[0048] For example, the calculated business metrics are compared with the historical baseline data after the switch to generate deviation analysis results. For instance, if the current after-school conversion rate is 8%, while the historical baseline is 10%, the deviation is -2%, and the deviation level is "warning".

[0049] An alarm is generated when the fluctuation of any business metric exceeds the corresponding threshold value in the alarm rule. For example, the alarm rule stipulates that an alarm is triggered when the post-class conversion rate drops by more than 3%. If the current drop is 2%, which does not exceed the threshold, no alarm is triggered. If the drop exceeds 3%, an alarm is generated, which includes the alarm metric name, the current value, the threshold value, the extent of the exceedance, and the trigger time.

[0050] Step S107: Output the various business indicators, deviation analysis results and alarm information under the current scenario to the corresponding business dashboard.

[0051] For example, a real-time streaming engine can be used to process user behavior data with a second-level delay, writing the processing results to an in-memory cache in real time. The business dashboard uses a long-lived connection to fetch the latest data from the cache every 5 seconds, automatically refreshing the displayed content. Personnel from multiple departments can simultaneously view real-time operational dynamics online, and when key indicators show abnormalities, the system pushes alert notifications to relevant personnel within seconds.

[0052] It is understood that by adopting the technical solution provided in this embodiment of the invention, multi-source data is acquired based on a preset adaptation interface, and a multi-dimensional association algorithm based on user identity (binding and matching three types of features: user account, mobile phone number, and device identifier) ​​is used to automatically aggregate the same user data scattered across different platforms, generating unified user behavior data for each user. This achieves automated integration and unified management of multi-source heterogeneous data, eliminating the need for operations personnel to switch between platforms and manually integrate data, significantly reducing data integration costs and improving data retrieval efficiency. Furthermore, by automatically determining the user's current state based on user behavior data, and automatically determining the current business scenario based on the current state and scenario boundary conditions, a scenario switching process is automatically executed when a scenario change is detected (including simultaneous switching of statistical data, comparison benchmarks, and alarm rules). Then, various business indicators are automatically calculated based on the switched indicators and standardized indicator definitions. The entire process requires no manual intervention, avoiding statistical errors caused by formula errors, data omissions, or caliber deviations during manual collection, calculation, and aggregation, significantly improving data processing efficiency while ensuring statistical accuracy. Furthermore, by pre-defining standardized indicator criteria, a unique value rule was set for each business indicator (including the number of payment link views, the number of orders generated, the number of successful payments, the number of services activated, the number of students attending classes, the number of online students, the number of outbound call coverage, and the connection rate). This standardized criterion serves as the unified basis for indicator calculations across all scenarios. Whether in end-to-end conversion, real-time monitoring during classes, or outbound call correlation analysis scenarios, the same value rule is used for calculation of the same indicator, eliminating the differences in criteria caused by departmental processing and achieving consistency and comparability of cross-departmental data, providing a reliable data foundation for enterprise-wide decision-making. In addition, by constructing a scenario boundary condition library (including time boundaries, behavioral boundaries, and state boundaries) and a user behavior state machine, automatic identification and fine-grained classification of core scenarios in the new education purchase business (online entry period, in-class live streaming period, in-class pseudo-live streaming period, post-class conversion period, and outbound call interference period) were achieved. When changes in business scenarios are detected, the system automatically switches statistical calibers, comparison benchmarks, and alarm rules, enabling refined statistical functions such as minute-level time-segment analysis of live classes, differentiation of in-class / post-class conversions, and multi-time-segment follow-up of outbound calls. This provides operations personnel with real-time and accurate basis for adjusting business strategies, effectively making up for the shortcomings of existing general data statistics systems in terms of scenario-based support.

[0053] Based on a general inventive concept, and building upon the above embodiments, this embodiment provides a detailed explanation of the process for acquiring user behavior data for each user.

[0054] Optionally, the user identity-based multi-dimensional association algorithm binds and matches three types of features: user account, mobile phone number, and device identifier, aggregating the same user data scattered across different platforms to obtain user behavior data for each user, including: A unified identity profile is constructed for each user, which includes three types of feature fields: user account, mobile phone number, and device identifier, as well as the corresponding credibility score for each field. When a user behavior record is obtained from any data source, one or more feature values ​​are extracted from the user account, mobile phone number, and device identifier carried in the user behavior record, and the feature values ​​are used as indexes to search in the existing unified identity profile. If a matching unified identity profile is found, the user behavior record will be aggregated under that unified identity profile, and the confidence score of each feature field in the unified identity profile will be dynamically updated according to the feature type and matching confidence of this match. If no matching unified identity profile is found, a new unified identity profile is created, and the currently extracted feature values ​​are used as the initial values ​​to assign initial confidence scores to each feature field in the new unified identity profile. When two user behavior records from different data sources are matched to two different unified identity profiles, but there is at least one common feature value between the two unified identity profiles and the confidence score of the common feature value exceeds a preset threshold, the two unified identity profiles are merged into one, and all user behavior records of the two are merged. All user behavior records aggregated under the same unified identity profile will be used as the user's user behavior data.

[0055] Optionally, when there is a conflict among the three types of feature values—user account, mobile phone number, and device identifier—in the same user behavior record, the user behavior record is aggregated under the corresponding unified identity profile according to the feature value with the highest confidence score, and the reason for the conflict is recorded in the form of a comment.

[0056] For example, new purchase data for an online education platform is scattered across three systems: System A (Volcano Engine Data Tracking System): records user browsing and clicking behaviors, using device identifier (device_id) as the primary key; System B (Fairsoft Live Streaming System): records user attendance and online time, using user account (user_id) as the primary key; System C (CRM Outbound Calling System): records outbound call follow-up records, using mobile phone number (phone) as the primary key. The user identifiers in the three systems are completely different, requiring aggregation using the method of this invention. The specific execution process can be as follows: Step 1: Process the first record of the tracking system. Retrieve records from the event tracking system: {device_id: "DEV_001", event: "Browsing payment link"}; Searching the image database with "DEV_001" → Not found; Create a new profile USER_001 and record the device identifier = DEV_001 (credibility 0.5). Collect this record.

[0057] Step 2: Process the first record of the live streaming system Retrieve record from live streaming system: {user_id: "zhang_san", event: "Entered live streaming room"}; Searching for "zhang_san" → No results found; Create a new profile USER_002 and record the user account = zhang_san (credibility 0.9); Collect this record.

[0058] Step 3: Process the first record in the CRM system Retrieve record from CRM system: {phone: "13800138000", event: "Outbound call connected"}; Searching for "13800138000" → No results found; Create a new profile USER_003 and record the phone number = 13800138000 (credibility 0.8). Collect this record.

[0059] At this point, the three portraits are independent of each other and cannot be linked.

[0060] Step 4: Key related records appear Retrieve record from live streaming system: {user_id: "zhang_san", device_id: "DEV_001", event: "Online report"}; Searching for "zhang_san" → Matches USER_002; Searching with "DEV_001" → Matches USER_001; If the same record is associated with two profiles, a merge decision will be triggered.

[0061] Both USER_001 and USER_002 contain “DEV_001” and their credibility exceeds the threshold (0.5). Perform a merge: merge all features and records of USER_001 into USER_002 and delete USER_001.

[0062] At this time, USER_002 contains: user_id=zhang_san(0.9), device_id=DEV_001(0.5), and the number of collected records is 3.

[0063] Step 5: Re-associate Retrieve record from CRM system: {phone: "13800138000", user_id: "zhang_san", event:"Added WeChat after outbound call"}; Searching by "phone" → Matches USER_003; Searching by "user_id" → Matches USER_002; The same record is associated with two profiles, triggering a merge.

[0064] USER_003 is merged into USER_002. USER_002 adds a new mobile number = 13800138000 (0.8), and the number of collected records increases.

[0065] Final result All records from the three systems are aggregated under the same profile USER_002 (see Table 1): Table 1

[0066] It is understood that by adopting the technical solution provided in this embodiment, the system automatically aggregates the same user data scattered across three platforms into a unified profile, eliminating the need for manual cross-platform stitching and providing a complete and accurate data foundation for subsequent status determination, scene switching, and indicator calculation.

[0067] Based on a general inventive concept, and building upon the above embodiments, this embodiment provides a detailed explanation of the process for determining the current business scenario in which the user is located.

[0068] Optionally, determining the user's current state based on the user behavior data, and determining the user's current business scenario based on the current state and scenario boundary conditions, includes: The user behavior data of each user is arranged in chronological order of occurrence. The latest valid behavior records of the user are filtered, and the event type, occurrence timestamp and associated course or class identifier corresponding to the latest valid behavior records are extracted to determine the user's current status. The user's current state is matched with the scene boundary conditions in the scene boundary condition library to obtain the user's current business scene. Each scene boundary condition includes: boundary type, state before boundary, state after boundary, and the type and number of events required to trigger the boundary condition. The boundary type includes time boundary, behavior boundary, or state boundary.

[0069] The current state refers to the business stage in the entire process of a user purchasing a new service. The business stages include: the inbound call period, the live broadcast period during the course, the pseudo-live broadcast period during the course, the post-course conversion period, and the outbound call interference period.

[0070] For example, a live-streamed course on an online education platform is scheduled as follows: Course Title: English Learning for Beginners; Class: 3rd session; Live broadcast time: 16:00-16:30 (first live broadcast class period); Pseudo-live broadcast time: 19:00-19:30 (second non-real-time live broadcast class period).

[0071] User identification has been completed, and user behavior data for each user has been obtained. Now, based on the user behavior data, we will determine the user's current status and the business scenario they are in.

[0072] The following set of states was defined first: Entering the live stream: The user has not yet entered the live stream, but has only browsed the relevant pages; During the live class: The user is participating in the 16:00 live class; Pseudo-live class period: Users are participating in a pseudo-live class at 19:00; Post-class conversion period: The user has not yet paid after the live class ends; Outbound call interference: The outbound call team is following up on this user.

[0073] The following boundary conditions are pre-stored in the scene boundary condition library (see Table 2): Table 2

[0074] In the specific implementation process: User A: From entering the live stream to attending the class, sort User A's behavior data by time, and filter the latest valid behavior data records as: {Event Type="Browsing Payment Link", Time="15:50:00"}; extract the event type "Browsing Payment Link", no live stream entry records; determine the current state = entering period; based on the current state "entering period", match the scenario boundary condition library: query the boundary conditions (such as B01) starting from "entering period", and the current unmet trigger condition (not entering the live stream), to determine the current business scenario = entering period.

[0075] It is understood that by adopting the technical solution provided in this embodiment, whenever a user generates a new behavior record, the system immediately determines the current status based on the latest behavior, without the need for manual judgment.

[0076] Based on a general inventive concept, and building upon the above embodiments, this embodiment provides a detailed explanation of the scene switching process.

[0077] Optionally, the process of switching scenarios when a change in the current business scenario is detected includes: Continuously monitor the boundary conditions related to the current business scenario in the scenario boundary condition library. Each scenario boundary condition includes the boundary type, the state before the boundary, the state after the boundary, and the triggering condition. When any boundary condition is triggered, it is determined whether the trigger condition meets the scene switching requirements. The trigger conditions include: time reaching a preset threshold, user behavior event type matching, or user state duration exceeding a preset value. If the scenario switching requirements are met, it is determined that the current business scenario has changed, and the scenario switching process is executed. If the scenario switching requirements are not met, the current business scenario will remain unchanged.

[0078] It is understood that by using the technical solution provided in this embodiment, no manual clicking is required to switch, and the system automatically detects boundary conditions.

[0079] Based on a general inventive concept, and building upon the above embodiments, this invention also provides another embodiment to illustrate the unified dimension tree and anchor point inheritance steps.

[0080] Optional, also includes: A four-level unified drill-down dimension tree is predefined, from L0 to L3, where: L0 is the overall business line level, L1 is the course level, L2 is the class level, and L3 is the channel or department level. In response to a user's drill-down operation in any business scenario, the currently selected dimension anchor path is recorded. The dimension anchor path includes dimension identifiers from L0 to each level of the current layer. When a user switches from the current business scenario to another business scenario, the dimension anchor path is automatically inherited, and the inherited anchor path is used as the filtering condition in the new scenario to recalculate various business indicators in the new scenario. When the same dimension name has different business meanings in different business scenarios, the dimension nodes in the anchor path are converted into semantically equivalent nodes corresponding to the target scenario through the dimension mapping table.

[0081] For example, a dimension structure tree can be pre-built, with level L0 and the dimension name being business line, such as English line and math line; level L1 and the dimension name being course, such as English enlightenment course and phonics course; level L2 and the dimension name being class, such as the 3rd session and the 4th session; and level L3 and the dimension name being channel / department, such as Douyin, Kuaishou, Sales Department 1 and Sales Department 2.

[0082] Based on this, operations staff member Xiao Wang performed the following operations on the end-to-end conversion dashboard: Step 1: Select the business line. Xiao Wang clicks to filter "English line"; the system records the anchor path: L0=English line; the dashboard displays the overall conversion data for the English line.

[0083] Step 2: Drill down to the course. Xiao Wang clicks on "English Learning Course"; the system updates the anchor path: L0 = English Line, L1 = English Learning Course; the dashboard displays the conversion data for the English Learning Course.

[0084] Step 3: Drill down to the class. Xiao Wang clicks "Phase 3"; the system updates the anchor path: L0=English Line, L1=English Enlightenment Course, L2=Phase 3; the dashboard displays the conversion data for Phase 3.

[0085] Step 4: Drill down to the channel. Xiao Wang clicks on "Douyin"; the system updates the anchor path: L0=English Line, L1=English Learning Course, L2=Phase 3, L3=Douyin; the dashboard displays the conversion data of the Douyin channel in Phase 3.

[0086] Step 5: Switch to the Outbound Call Analysis Dashboard. Xiao Wang clicks to switch to the "Outbound Call Analysis" dashboard. The system automatically performs anchor point inheritance: reads the current anchor point path: English Line → English Beginner Course → Phase 3 → Douyin; and automatically applies it as the filtering criteria for the Outbound Call Analysis dashboard. Through the dimension mapping table, "Douyin" is converted to "Douyin Sales Group" in the outbound call scenario. Outbound call data is directly displayed without the need for re-filtering.

[0087] It is understandable that by adopting the technical solution provided in this embodiment, a single drilling operation can be used across different scenarios with zero repetitive operations.

[0088] Based on a general inventive concept, and building upon the above embodiments, this embodiment provides a detailed explanation of the process of timeline event splicing and scene contribution analysis.

[0089] Optional, also includes: Preset events under the same user identifier are concatenated in timestamp order; for example, preset events can be: incoming call event, payment link browsing event, class attendance event, online time recording event, in-class outbound call event, order generation event, payment success event, and post-class outbound call event.

[0090] Automatically label each event with its corresponding scene tag; Based on the concatenated behavior sequence, a user-level scene behavior view is generated. The contribution metrics of each scenario to the final transaction conversion are aggregated and calculated. These contribution metrics include: user retention rate, conversion rate improvement rate, and conversion decay rate between scenarios.

[0091] It is understandable that by using the technical solution provided in this embodiment, it is possible to analyze the complete behavioral path of a user on an online education platform from initial contact to transaction, and identify which link contributes the most to the final conversion and which link suffers the most loss.

[0092] All events for the same user are concatenated in timestamp order to form a complete behavioral timeline. Each event is labeled with a scenario tag, which can correspond to a business stage, such as: inbound call period, in-class live broadcast period, in-class pseudo-live broadcast period, post-class conversion period, and outbound call interference period. Based on the concatenated behavioral sequence, the contribution index of each scenario is aggregated and calculated. The calculated contribution index is stored for analysts to review; alternatively, it can be displayed directly on a dashboard.

[0093] The technical solution provided by the embodiments of the present invention can stitch together scattered events into a complete timeline to see the user's behavior throughout the entire process; each event is automatically tagged with a scenario for easy scenario-based analysis; the contribution of each scenario to the final transaction can be quantified by conversion rate and decay rate; and the link with the most severe loss can be quickly identified to guide strategy optimization.

[0094] Based on a general inventive concept, this embodiment also provides another embodiment based on the above embodiments.

[0095] Optionally, it also includes: obtaining user filtering operations through multi-dimensional filtering and drill-down analysis interfaces; the multi-dimensional filtering includes at least: class, course, department, and channel; In response to user filtering operations on any dimension or combination of dimensions, dynamically update the calculation range of various business indicators in the current business scenario, and re-aggregate and display the data according to the filtered dimensions; Different default dimension views are preset for different roles, including: operations personnel, management personnel, and sales personnel. The default view for each role contains the core dimensions and indicator set that the role focuses on.

[0096] For example, an operations staff member checks the data. Xiao Li logs into the system, and the system automatically loads the default view for operations staff: displayed by "Course + Class". Xiao Li sees that the conversion rate for the third phase of the English learning course is 8%, lower than the target value. Xiao Li adds a filter: Channel = Douyin (TikTok). The system dynamically updates: only data from the Douyin channel is displayed, and the conversion rate changes to 12%. Xiao Li drills down to the detailed data for "Phase 3" and finds significant user dropout during the course. Conclusion: The Douyin channel has high-quality users, but insufficient in-class interaction; the in-class communication needs optimization.

[0097] For example, a manager views the data. Manager Wang logs into the system, and the system automatically loads the default view for managers: displayed by "department + channel". Manager Wang sees that Sales Department 1 has a completion rate of 120%, while Sales Department 2 only has 75%. Manager Wang drills down to "Sales Department 2" and examines the data by channel. He discovers that Sales Department 2's connection rate on the Douyin channel is only 30%, far below the average. Conclusion: Sales Department 2 needs to strengthen its outbound calling training for the Douyin channel.

[0098] For example, a salesperson reviews the data. Salesperson Zhang logs into the system, which automatically loads the default view for salespeople: displayed by "Individual + Channel". Zhang sees that his outbound call connection rate for the day is 45%, lower than the team average. Zhang then filters and reviews the data for the Douyin channel he is responsible for. He finds that call durations on Douyin channels are generally shorter. Conclusion: Zhang needs to optimize his opening remarks for Douyin channels.

[0099] It is understandable that, by adopting the technical solution provided in this embodiment, different roles can automatically see the data view they are interested in after logging in; it supports single-dimensional or multi-dimensional combination filtering and updates the calculation results in real time; after the filtering conditions change, the data is re-aggregated and displayed according to the new dimensions.

[0100] Based on a general inventive concept, and building upon the above embodiments, the present invention also provides another embodiment.

[0101] Optionally, it also includes: writing the processed business indicators, deviation analysis results and alarm information into the memory cache in real time; The latest data is retrieved from the memory cache at a preset refresh frequency, and the content displayed on the dashboard is refreshed. It supports users from multiple departments or roles to view real-time business dynamics online simultaneously, and different users automatically load the corresponding dimension views and data ranges based on preset permissions; When the fluctuation of any business metric exceeds the alarm threshold, an alarm notification is pushed to the relevant business personnel, and the abnormal metric is highlighted to support users in adjusting their business strategies in a timely manner.

[0102] For example, in this application, real-time data refresh is performed. The live class starts at 16:00, and the system processes user behavior data in real time. The latest business indicators are written to the memory cache every 5 seconds. The dashboard of operations staff member Xiao Wang automatically pulls the latest data from the cache every 5 seconds. Xiao Wang sees that the number of online users has increased from 120 to 150, and the conversion rate has increased from 5% to 8%. The data is updated automatically without the need to manually refresh the page.

[0103] Multiple departments online simultaneously: Three people can log in to the system at the same time, each seeing real-time data within their own permission scope, without interfering with each other.

[0104] Alarm Triggering and Push Notifications: The system has a preset alarm rule: an alarm is triggered if the number of online users drops by more than 20% within 5 minutes during class. At 16:10, there were 150 online users. At 16:12, the number of online users was 120 (a 20% decrease). At 16:13, the number of online users was 100 (a 33% decrease). The system detected that the fluctuation exceeded the threshold and immediately triggered an alarm.

[0105] Anomaly indicator highlighted: Xiao Wang noticed the "Online Users" indicator on the dashboard was highlighted in red. Next to it was a "-33%" decrease and an alarm icon. Xiao Wang clicked on the indicator to view details and discovered it was a network issue in a certain area. He immediately notified the technical team, and the online user count recovered within 5 minutes.

[0106] It is understandable that by adopting the technical solution provided in this embodiment, data can be written to the cache in seconds, the dashboard can be refreshed automatically without manual operation, and abnormal indicators can be displayed prominently to detect problems in a timely manner.

[0107] Based on a general inventive concept, embodiments of the present invention also provide a system.

[0108] Figure 2 This is a schematic diagram of a new purchase business data dashboard implementation system provided in an embodiment of the present invention. (See attached diagram.) Figure 2 The system described in the embodiments of the present invention may include the following structure: The acquisition module 21 is used to acquire multi-source data based on a preset adaptation interface; the multi-source data includes data from different platforms. The aggregation module 22 is used to bind and match three types of features—user account, mobile phone number, and device identifier—based on a multi-dimensional association algorithm of user identity, and to aggregate the same user data scattered across different platforms to obtain user behavior data for each user. The determination module 23 is used to determine the user's current state based on the user behavior data, and to determine the current business scenario in which the user is located based on the current state and scenario boundary conditions; wherein, the scenario boundary conditions are pre-stored in a scenario boundary condition library; The switching module 24 is used to perform a scenario switching process when a change in the current business scenario is detected. The scenario switching process includes: switching the calculation rule of the statistical data from a first indicator corresponding to a first scenario to a second indicator corresponding to a second scenario, wherein the first indicator is used to define the scope of users to be counted in the first scenario, and the second indicator is used to define the scope of users to be counted in the second scenario; switching the comparison benchmark from historical benchmark data of the first scenario to historical benchmark data of the second scenario; and switching the alarm rule from a first alarm rule corresponding to the first scenario to a second alarm rule corresponding to the second scenario. The first alarm rule includes a first set of monitoring indicators and a corresponding first threshold value, and the second alarm rule includes a second set of monitoring indicators and a corresponding second threshold value. The standardization module 25 is used to calculate various business indicators in the current scenario based on the switched second indicator and the predefined standardized indicator caliber; wherein, the standardized indicator caliber predefines a unique value rule for each business indicator, and the standardized indicator caliber includes at least one of the following: number of payment link views, number of orders generated, number of successful payments, number of services activated, number of students attending classes, number of online students, number of outbound call coverage, and connection rate; Analysis module 26 is used to compare the calculated business indicators with the historical benchmark data after the switch and generate deviation analysis results; and to generate alarm information when the fluctuation range of any business indicator exceeds the corresponding second threshold value in the second alarm rule after the switch. Output module 27 is used to output various business indicators, deviation analysis results, and alarm information in the current scenario to the corresponding business dashboard. Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0109] Understandably, this invention acquires multi-source data based on a preset adaptation interface and automatically aggregates user data scattered across different platforms using a multi-dimensional user identity association algorithm (binding and matching three types of features: user account, mobile phone number, and device identifier). This generates unified user behavior data for each user, achieving automated integration and unified management of multi-source heterogeneous data. It eliminates the need for operations personnel to switch between platforms and manually integrate data, significantly reducing data integration costs and improving data retrieval efficiency. Furthermore, by automatically determining the user's current state based on user behavior data and automatically determining the current business scenario based on the current state and scenario boundary conditions, the invention automatically executes a scenario switching process (including simultaneous switching of statistical data, comparison benchmarks, and alarm rules) when a scenario change is detected. Then, based on the switched indicators and standardized indicator definitions, it automatically calculates various business indicators. The entire process requires no manual intervention, avoiding statistical errors caused by formula errors, data omissions, or caliber deviations during manual collection, calculation, and aggregation. This significantly improves data processing efficiency while ensuring statistical accuracy. In addition, by pre-defining standardized indicator criteria, a unique value rule was set for each business indicator (including the number of payment link views, the number of orders generated, the number of successful payments, the number of services activated, the number of students attending classes, the number of online students, the number of outbound call coverage, the connection rate, etc.). This standardized criterion is used as the unified basis for indicator calculation in all scenarios. Whether in the whole-link conversion, real-time monitoring during classes, or outbound call correlation analysis scenarios, the same value rule is used for the calculation of the same indicator. This eliminates the difference in criteria caused by the processing of data by different departments, realizes the consistency and comparability of cross-departmental data, and provides a reliable data foundation for the overall decision-making of the enterprise.

[0110] Based on a general inventive concept, the present invention also provides a new purchase business data dashboard implementation device for implementing the above-described method embodiments.

[0111] Figure 3 This is a schematic diagram of a device for implementing a new purchase business data dashboard, provided as an embodiment of the present invention. Figure 3 As shown, the new purchase business data dashboard implementation device in this embodiment includes a processor 31 and a memory 32, with the processor 31 connected to the memory 32. The processor 31 is used to call and execute the program stored in the memory 32; the memory 32 is used to store the program, which is at least used to execute the new purchase business data dashboard implementation method described in the above embodiment.

[0112] The specific implementation schemes provided in this application can be referred to the implementation methods of any of the above embodiments, and will not be repeated here.

[0113] It is understood that the same or similar parts in the above embodiments can be referred to each other, and the contents not described in detail in some embodiments can be referred to the same or similar contents in other embodiments.

[0114] It should be noted that in the description of this invention, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Furthermore, in the description of this invention, unless otherwise stated, "a plurality of" means at least two.

[0115] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which embodiments of the invention pertain.

[0116] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0117] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0118] Furthermore, the functional units in the various embodiments of the present invention can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0119] The storage media mentioned above can be read-only memory, disk, or optical disk, etc.

[0120] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0121] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A method for implementing a new purchase business data dashboard, characterized in that, include: Based on a preset adaptation interface, multi-source data is acquired; the multi-source data includes data from different platforms. Based on a multi-dimensional association algorithm for user identity, the algorithm binds and matches three types of features: user account, mobile phone number, and device identifier. It aggregates the same user data scattered across different platforms and obtains user behavior data for each user. The user's current state is determined based on the user behavior data, and the current business scenario in which the user is located is determined based on the current state and the scenario boundary conditions; wherein, the scenario boundary conditions are pre-stored in a scenario boundary condition library; When a change in the current business scenario is detected, a scenario switching process is initiated. The scenario switching process includes: switching the calculation rule of the statistical data from a first indicator corresponding to a first scenario to a second indicator corresponding to a second scenario, wherein the first indicator is used to define the scope of users to be counted in the first scenario, and the second indicator is used to define the scope of users to be counted in the second scenario; switching the comparison benchmark from historical benchmark data of the first scenario to historical benchmark data of the second scenario; and switching the alarm rule from a first alarm rule corresponding to the first scenario to a second alarm rule corresponding to the second scenario. The first alarm rule includes a first set of monitoring indicators and a corresponding first threshold value, and the second alarm rule includes a second set of monitoring indicators and a corresponding second threshold value. Based on the switched second indicator and the predefined standardized indicator caliber, calculate various business indicators in the current scenario; wherein, the standardized indicator caliber predefines a unique value rule for each business indicator, and the standardized indicator caliber includes at least one of the following: number of payment link views, number of orders generated, number of successful payments, number of services activated, number of students attending classes, number of online students, number of outbound call coverage, and connection rate; The calculated business indicators are compared with the historical benchmark data after the switch to generate deviation analysis results; and when the fluctuation of any business indicator exceeds the corresponding second threshold value in the second alarm rule after the switch, an alarm message is generated. The various business metrics, deviation analysis results, and alarm information in the current scenario are output to the corresponding business dashboard.

2. The method according to claim 1, characterized in that, The user identity-based multidimensional association algorithm binds and matches three types of features: user account, mobile phone number, and device identifier. This aggregates user data scattered across different platforms to obtain each user's behavior data, including: A unified identity profile is constructed for each user, which includes three types of feature fields: user account, mobile phone number, and device identifier, as well as the corresponding credibility score for each field. When a user behavior record is obtained from any data source, one or more feature values ​​are extracted from the user account, mobile phone number, and device identifier carried in the user behavior record, and the feature values ​​are used as indexes to search in the existing unified identity profile. If a matching unified identity profile is found, the user behavior record will be aggregated under that unified identity profile, and the confidence score of each feature field in the unified identity profile will be dynamically updated according to the feature type and matching confidence of this match. If no matching unified identity profile is found, a new unified identity profile is created, and the currently extracted feature values ​​are used as the initial values ​​to assign initial confidence scores to each feature field in the new unified identity profile. When two user behavior records from different data sources are matched to two different unified identity profiles, but there is at least one common feature value between the two unified identity profiles and the confidence score of the common feature value exceeds a preset threshold, the two unified identity profiles are merged into one, and all user behavior records of the two are merged. All user behavior records aggregated under the same unified identity profile will be used as the user's user behavior data.

3. The method according to claim 1, characterized in that, The step of determining the user's current state based on the user behavior data, and determining the user's current business scenario based on the current state and scenario boundary conditions, includes: The user behavior data of each user is arranged in chronological order of occurrence. The latest valid behavior records of the user are filtered, and the event type, occurrence timestamp and associated course or class identifier corresponding to the latest valid behavior records are extracted to determine the user's current status. The user's current state is matched with the scene boundary conditions in the scene boundary condition library to obtain the user's current business scene; wherein, each scene boundary condition includes: boundary type, state before boundary, state after boundary, and the type and number of events required to trigger the boundary condition; the boundary type includes time boundary, behavior boundary or state boundary.

4. The method according to claim 1, characterized in that, The scenario switching process when a change in the current business scenario is detected includes: Continuously monitor the boundary conditions related to the current business scenario in the scenario boundary condition library. Each scenario boundary condition includes the boundary type, the state before the boundary, the state after the boundary, and the triggering condition. When any boundary condition is triggered, it is determined whether the trigger condition meets the scene switching requirements. The trigger conditions include: time reaching a preset threshold, user behavior event type matching, or user state duration exceeding a preset value. If the scenario switching requirements are met, it is determined that the current business scenario has changed, and the scenario switching process is executed. If the scenario switching requirements are not met, the current business scenario will remain unchanged.

5. The method according to claim 1, characterized in that, Also includes: Predefined four-level unified drill-down dimension tree from L0 to L3; In response to a user's drill-down operation in any business scenario, the currently selected dimension anchor path is recorded. The dimension anchor path includes dimension identifiers from L0 to each level of the current layer. When a user switches from the current business scenario to another business scenario, the dimension anchor path is automatically inherited, and the inherited anchor path is used as the filtering condition in the new scenario to recalculate various business indicators in the new scenario. When the same dimension name has different business meanings in different business scenarios, the dimension nodes in the anchor path are converted into semantically equivalent nodes corresponding to the target scenario through the dimension mapping table.

6. The method according to claim 1, characterized in that, Also includes: Preset events under the same user ID are concatenated in order of timestamp; Label each event with its corresponding scene tag; Based on the concatenated behavior sequence, a user-level scene behavior view is generated. The contribution metrics of each scenario to the final transaction conversion are aggregated and calculated. These contribution metrics include: user retention rate, conversion rate improvement rate, and conversion decay rate between scenarios.

7. The method according to claim 1, characterized in that, Also includes: The user's filtering operations are obtained through multi-dimensional filtering and drill-down analysis interfaces; In response to user filtering operations on any dimension or combination of dimensions, dynamically update the calculation range of various business indicators in the current business scenario, and re-aggregate and display the data according to the filtered dimensions; Different default dimension views are preset for different roles, including: operations personnel, management personnel, and sales personnel. The default view for each role contains the core dimensions and indicator set that the role focuses on.

8. The method according to claim 1, characterized in that, Also includes: All processed business metrics, deviation analysis results, and alarm information are written to the memory cache in real time. The latest data is retrieved from the memory cache at a preset refresh frequency, and the content displayed on the dashboard is refreshed. It supports users from multiple departments or roles to view real-time business dynamics online simultaneously, and different users automatically load the corresponding dimension views and data ranges based on preset permissions; When the fluctuation of any business metric exceeds the alarm threshold, an alarm notification is pushed to the relevant business personnel, and the abnormal metric is highlighted to support users in adjusting their business strategies in a timely manner.

9. A new purchase business data dashboard implementation system, characterized in that, include: The acquisition module is used to acquire multi-source data based on a preset adaptation interface; the multi-source data includes data from different platforms. The aggregation module is used to bind and match three types of features—user account, mobile phone number, and device identifier—based on a multi-dimensional association algorithm of user identity, and to aggregate the same user data scattered across different platforms to obtain user behavior data for each user. The determination module is used to determine the user's current state based on the user behavior data, and to determine the current business scenario in which the user is located based on the current state and scenario boundary conditions; wherein, the scenario boundary conditions are pre-stored in a scenario boundary condition library; The switching module is used to perform a scenario switching process when a change in the current business scenario is detected. The scenario switching process includes: switching the calculation rule of the statistical data from a first indicator corresponding to a first scenario to a second indicator corresponding to a second scenario, wherein the first indicator is used to define the scope of users to be counted in the first scenario, and the second indicator is used to define the scope of users to be counted in the second scenario; switching the comparison benchmark from historical benchmark data of the first scenario to historical benchmark data of the second scenario; and switching the alarm rule from a first alarm rule corresponding to the first scenario to a second alarm rule corresponding to the second scenario. The first alarm rule includes a first set of monitoring indicators and a corresponding first threshold value, and the second alarm rule includes a second set of monitoring indicators and a corresponding second threshold value. The standardization module is used to calculate various business indicators in the current scenario based on the switched second indicator and the predefined standardized indicator caliber. The standardized indicator caliber predefines a unique value rule for each business indicator and includes at least one of the following: number of payment link views, number of orders generated, number of successful payments, number of services activated, number of students attending classes, number of online students, number of outbound call coverage, and connection rate. The analysis module is used to compare the calculated business indicators with the historical benchmark data after the switch and generate deviation analysis results; and to generate alarm information when the fluctuation of any business indicator exceeds the corresponding second threshold value in the second alarm rule after the switch. The output module is used to output various business indicators, deviation analysis results and alarm information in the current scenario to the corresponding business dashboard.

10. A device for implementing a new purchase business data dashboard, characterized in that, It includes a processor and a memory, wherein the processor is connected to the memory: The processor is used to call and execute the program stored in the memory; The memory is used to store the program, which is at least used to execute the new purchase business data dashboard implementation method according to any one of claims 1-8.

Images