High-speed rail ticket buying strategy simulation method and device, electronic equipment and storage medium

Abstract

The invention discloses a high-speed rail ticket buying strategy simulation method and device, electronic equipment and a storage medium, and relates to the technical field of high-speed rail ticket buying, and the method comprises the steps: generating train information of a specified train number in each scene; setting remaining tickets in the train information; in response to the login operation of the user, verifying whether the login information of the user allows login; sending an initial questionnaire to the user after the user logs in, and obtaining initial feedback data of the initial questionnaire filled by the user; the description information of each scene is displayed to the user, and ticket buying behavior information completed by the user in each scene according to the train information and the remaining tickets is acquired; sending a scene ticket buying feedback questionnaire to the user, and obtaining scene ticket buying feedback data of the scene ticket buying feedback questionnaire filled by the user; sending a final feedback questionnaire to the user, and obtaining final feedback data of the final feedback questionnaire filled by the user; and generating statistical analysis data according to the feedback data of each questionnaire and the ticket buying behavior information of the user. The method can provide a scientific basis for a ticket buying strategy.

Description

Technical Field

[0001] This application relates to the field of high-speed rail ticketing technology, and in particular to a high-speed rail ticketing strategy simulation method, device, electronic equipment and storage medium. Background Technology

[0003] In recent years, the railway authorities have introduced a waitlist ticketing mechanism and continuously optimized ticket allocation strategies, providing new solutions to alleviate the difficulty of purchasing tickets for passengers. The waitlist service dynamically acquires information on passengers' additional needs, providing data support for the railway authorities to adjust ticket allocation plans in real time. However, due to shortcomings in the current ticketing system's strategy design and implementation—such as a lack of detailed analysis of ticketing scenarios and timely response to dynamic changes in demand—the potential of the waitlist system has not been fully realized. Furthermore, the formulation of ticketing strategies often lacks scientific testing and verification tools, making it difficult for the current mechanism to achieve optimal results. Summary of the Invention

[0004] In view of this, embodiments of this application provide a method, device, electronic device and storage medium for simulating high-speed rail ticket purchase strategies, so as to simulate high-speed rail ticket purchase and provide a scientific basis for dynamic ticket allocation and fare synergistic optimization.

[0005] One aspect of this application provides a method for simulating high-speed rail ticket purchasing strategies, the method comprising the following steps:

[0006] Generate train information for specified train numbers in various scenarios;

[0007] Set the available tickets in the train information;

[0008] In response to a user's login request, verify whether the user's login information is allowed.

[0009] After a user logs in, an initial questionnaire is sent to the user to obtain initial feedback data from the user's completion of the initial questionnaire;

[0010] Display descriptive information of each scenario to the user, and obtain information on the user's ticket purchase behavior in each scenario based on the train information and the remaining tickets;

[0011] Send a scenario-based ticket purchase feedback questionnaire to users and obtain scenario-based ticket purchase feedback data filled in by users in the scenario-based ticket purchase feedback questionnaire;

[0012] Send the final feedback questionnaire to the user and obtain the final feedback data filled in by the user in the final feedback questionnaire;

[0013] Statistical analysis data is generated based on the initial feedback data, the ticket purchase behavior information, the scenario ticket purchase feedback data, and the final feedback data.

[0014] In some embodiments, displaying descriptive information of each scenario to the user and obtaining ticket purchase information completed by the user in each scenario based on the train information and the available tickets includes the following steps:

[0015] The descriptive information of multiple scenarios is displayed to the user in sequence;

[0016] The system sequentially acquires the ticket purchase information completed by the user in each of the aforementioned scenarios, based on the corresponding train information and the corresponding remaining tickets.

[0017] In some embodiments, verifying whether the user's login information is allowed to log in in response to the user's login operation includes the following steps:

[0018] Get the phone number entered by the user;

[0019] Generate a verification code and send the verification code to the mobile phone number;

[0020] Obtain the verification code input by the user;

[0021] In response to the user's login operation, verify the mobile phone number and verification code entered by the user;

[0022] After successful verification, a token is generated and returned to the user, the user's login information is saved, and the user is then allowed to log in.

[0023] In some embodiments, obtaining the ticket purchase behavior information completed by the user in each of the aforementioned scenarios based on the train information and the remaining tickets includes the following steps:

[0024] The train information can be retrieved based on the departure date, origin, and destination entered by the user in each of the aforementioned scenarios;

[0025] Determine the target train number selected by the user based on the train information;

[0026] Determine the passenger and seat type selected by the user based on the target train number;

[0027] Determine the remaining tickets used to measure whether seat selection requirements are met;

[0028] Determine whether the remaining tickets for the seat type of the target train are greater than or equal to the set number of tickets;

[0029] If the remaining tickets are greater than or equal to the set number of tickets, the user's seat selection is determined and the order is submitted;

[0030] If the remaining tickets are less than the set number of tickets, then submit the order.

[0031] In some embodiments, the method further includes the following steps:

[0032] If the number of remaining tickets is 0, then the seat selected by the user is marked as a waitlist.

[0033] The system determines that the user has submitted a waitlist order for a seat in the waitlist status and marks the user as having completed the ticket purchase.

[0034] The candidate orders are recorded in a unified order table.

[0035] In some embodiments, the method further includes the following steps:

[0036] If the user has not completed the initial questionnaire, the user will be prompted to complete the initial questionnaire and redirected to the page containing the initial questionnaire.

[0037] Redirecting the user to the corresponding scenario based on their current testing phase, and guiding the user to complete the ticket purchase within that scenario;

[0038] If a user fails to purchase a ticket in the corresponding scenario and attempts to access the questionnaire page for that scenario, the user will be prompted to complete the ticket purchase and redirected to the page for that scenario.

[0039] If the user completes the final feedback questionnaire, they will be redirected to the completion page.

[0040] In some embodiments, generating statistical analysis data based on the initial feedback data, the ticket purchase behavior information, the scenario-based ticket purchase feedback data, and the final feedback data includes the following steps:

[0041] Based on the initial feedback data, the ticket purchase behavior information, the scenario ticket purchase feedback data, and the final feedback data, a scenario ticket purchase preference analysis, a train selection distribution map, and a visual statistical data comparison of the frequency of waitlist ticket purchase behavior are generated.

[0042] Based on the initial feedback data, the ticket purchase behavior information, the scenario ticket purchase feedback data, and the final feedback data, differential analysis data between the user's initial preferences and actual ticket purchase behavior is generated.

[0043] Another aspect of this application embodiment provides a high-speed rail ticket purchase strategy simulation device, the device comprising:

[0044] The train number generation unit is used to generate train information for a specified train number in various scenarios;

[0045] The remaining ticket setting unit is used to set the remaining tickets in the train information;

[0046] The login verification unit is used to respond to the user's login operation and verify whether the user's login information is allowed to log in;

[0047] The initial feedback unit is used to send an initial questionnaire to the user after the user logs in and to obtain initial feedback data from the user's completion of the initial questionnaire.

[0048] The scenario-based ticketing unit is used to display description information of each scenario to the user and obtain information on the ticketing behavior completed by the user in each scenario based on the train information and the remaining tickets.

[0049] The ticket purchase feedback unit is used to send a scenario ticket purchase feedback questionnaire to the user and obtain scenario ticket purchase feedback data filled in by the user in the scenario ticket purchase feedback questionnaire;

[0050] The final feedback unit is used to send a final feedback questionnaire to the user and obtain the final feedback data filled in by the user in the final feedback questionnaire;

[0051] The statistical analysis unit is used to generate statistical analysis data based on the initial feedback data, the ticket purchase behavior information, the scenario ticket purchase feedback data, and the final feedback data.

[0052] Another aspect of this application embodiment provides an electronic device, including a processor and a memory;

[0053] The memory is used to store programs;

[0054] The processor executes the program to implement any of the methods described above.

[0055] Another aspect of this application provides a computer-readable storage medium storing a program that is executed by a processor to implement the method described in any of the above embodiments.

[0056] This application includes at least the following beneficial effects:

[0057] This application can generate train information for specified train numbers in various scenarios; set the remaining tickets in the train information; respond to user login operations and verify whether the user's login information is allowed; send an initial questionnaire to the user after login and obtain initial feedback data from the user's completed initial questionnaire; display descriptive information for each scenario to the user and obtain information on the user's ticket purchase behavior based on train information and remaining tickets in each scenario; send a scenario-based ticket purchase feedback questionnaire to the user and obtain scenario-based ticket purchase feedback data from the user's completed scenario-based ticket purchase feedback questionnaire; send a final feedback questionnaire to the user and obtain final feedback data from the user's completed final feedback questionnaire; and generate statistical analysis data based on the initial feedback data, ticket purchase behavior information, scenario-based ticket purchase feedback data, and final feedback data. This application, by constructing scenario-based ticket purchase tests and obtaining questionnaire feedback data, simulates and analyzes the performance of ticket purchase strategies in special scenarios, providing a scientific basis for dynamic ticket allocation and fare co-optimization. Attached Figure Description

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

[0059] Figure 1 A flowchart illustrating a high-speed rail ticket purchase strategy simulation method provided in this application embodiment;

[0060] Figure 2 This is a system architecture diagram of the high-speed rail ticket purchase strategy simulation platform provided in the embodiments of this application;

[0061] Figure 3 A login flowchart provided for an embodiment of this application;

[0062] Figure 4 A test flowchart provided for an embodiment of this application;

[0063] Figure 5 A flowchart of the ticket purchasing process provided for an embodiment of this application;

[0064] Figure 6 This is a diagram of the train selection and analysis interface provided in an embodiment of this application;

[0065] Figure 7 This is a diagram of the initial questionnaire analysis interface provided in an embodiment of this application;

[0066] Figure 8 The following are post-purchase feedback analysis diagrams provided for various scenarios in the embodiments of this application;

[0067] Figure 9 A diagram of the standby ticket purchase analysis interface provided in this application embodiment;

[0068] Figure 10 An initial questionnaire interface diagram provided for an embodiment of this application;

[0069] Figure 11 This is a diagram of the scenario remaining ticket query interface provided in an embodiment of this application;

[0070] Figure 12 A route station interface diagram provided for an embodiment of this application;

[0071] Figure 13 This is a diagram of the candidate order interface provided in an embodiment of this application;

[0072] Figure 14 This is a screenshot of the post-purchase feedback interface provided in an embodiment of this application.

[0073] Figure 15 The final feedback questionnaire interface diagram provided for the embodiments of this application;

[0074] Figure 16 A diagram showing the completed test interface provided in an embodiment of this application;

[0075] Figure 17 This is a structural block diagram of a high-speed rail ticket purchase strategy simulation device provided in an embodiment of this application. Detailed Implementation

[0076] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of this application.

[0077] Before providing a detailed description of the embodiments of this application, the terminology and some related technologies involved in the embodiments of this application will be explained as follows:

[0078] Terminology Explanation:

[0079] (1) SP (Stated Preference): Through questionnaires or experiments, it studies the individual's choice preferences in hypothetical scenarios, in order to predict future behavior, quantify potential demand, and assess policy feasibility.

[0080] (2) RP (Revealed Preference): Infers preferences by observing an individual's actual behavior (such as purchase records and travel data), and is used to explain historical behavior and analyze real market patterns.

[0081] (3) Token: A token is a credential used for authentication and authorization, representing that the user has been verified by the system and has obtained access rights.

[0082] (4) ER Diagram (Entity-Relationship Diagram): This is a visualization tool used in database design to describe real-world entities, attributes, and relationships between entities. It helps designers clarify data structures in a graphical way and is a core step in building a database model. It describes the number of relationships between entities, using common symbols: 1:1 (one-to-one), 1:N (one-to-many), and M:N (many-to-many). The relationships should be labeled with 1, N, or M.

[0083] (5) Logit model: one of the discrete choice models, belonging to the category of multivariate analysis, and is a commonly used method in statistical empirical analysis in sociology, biostatistics, clinical, quantitative psychology, econometrics, marketing and other fields.

[0084] (6) SQL (Structured Query Language): A standard programming language used to manage and manipulate relational databases.

[0085] (7) JWT (JSON Web Token): An open standard for a compact and self-contained way to securely transmit information between parties, often used for authentication and data exchange.

[0086] (8) API (Application Programming Interface): A set of predefined rules and protocols that allow different software applications to communicate and interact with each other.

[0087] (9) OpenFeign: Full name Spring Cloud OpenFeign, it is a declarative service invocation and load balancing component officially released by Spring. It allows for convenient method calls between different modules. Some related technical details:

[0088] Related technology 1 used SP questionnaires to investigate and analyze passenger choice behavior for different types of trains under passenger dedicated line conditions; Related technology 2, based on SP and RP survey data of residents along a suburban railway line, established three models through travel behavior analysis: a model based on RP data, a model based on SP data, and a joint RP / SP data model, revealing the travel characteristics and patterns of suburban railway residents, and the results showed that ticket price reductions can significantly increase the share of suburban railway travel; Related technology 3, based on SP surveys, studied travelers' preference for different high-speed rail transportation products; Related technology 4, designed SP questionnaires to study travelers' choice behavior regarding external travel connections to railway passenger hubs; Related technology 5, based on SP surveys... Five travel scenarios with different service levels for five different modes of transportation were designed, and a multinomial logistic regression model was used to analyze residents' preferences for choosing suburban railways. Related technique 6 used the RP / SP method to complete a questionnaire survey of passengers traveling on the Beijing-Shanghai High-Speed ​​Railway. Combining passenger flow questionnaire data and ticket data, a passenger flow structure profile for the Beijing-Shanghai High-Speed ​​Railway was created, and passenger ticketing behavior preferences were analyzed. Related technique 7 conducted SP and RP surveys on a certain high-speed rail line and civil aviation passengers to analyze the composition of passenger flow and passenger travel mode selection behavior characteristics of the high-speed rail line. Based on disaggregation theory, a model of passenger travel choices on this high-speed rail line was constructed to quantify the influence of various factors on passenger choices. Related technique 8 used data obtained from the RP / SP joint survey and a multinomial logit model to study the ticketing time choices of various types of passengers under different fare fluctuation strategies. Related technique 9, based on the analysis of individual heterogeneity and factors influencing passenger choice behavior, used train running time, ticket price, departure time, and onboard service level as attributes of the SP survey, and used orthogonal design to conduct a combined survey scenario design to study the travel choice behavior of high-speed rail passengers.

[0089] Significant progress has been made in the field of passenger ticket purchase behavior research using relevant technologies. Data acquisition primarily relies on two classic paradigms: Stated Preference (SP) surveys and Revealed Preference (RP) data analysis. The former uses questionnaires to obtain passengers' subjective choice tendencies under hypothetical scenarios, while the latter reveals patterns in actual consumption behavior based on historical ticket purchase data. Each has its advantages and limitations: the SP method allows researchers to explore extreme situations that haven't occurred (such as the peak travel season during the Spring Festival), offering flexibility and controllability, but it carries the risk of respondent cognitive bias and "choice-behavior disconnect." The RP method relies on real transaction data, objectively reflecting real-world choice patterns, but is limited by data availability and struggles to capture behavioral anomalies in special situations. Existing research often uses SP and RP methods alone. Therefore, this application constructs a high-speed rail ticket purchase strategy simulation platform that combines SP and RP methods. Researchers can set up numerous special scenarios and corresponding questionnaires, such as when there is a severe shortage of tickets during the Spring Festival travel season or when passengers need to purchase tickets on the same day due to unforeseen circumstances. In specific contexts, this application can record the characteristics of passengers' ticket purchase choices and behaviors, as well as whether the passengers' operations on the high-speed rail ticket purchase strategy simulation platform match the data from the questionnaires they filled out. This data can be comprehensively analyzed to support subsequent multi-stage integrated research on high-speed rail ticket prices and fares.

[0090] Reference Figure 1 This application provides a method for simulating high-speed rail ticket purchasing strategies, specifically including the following steps S100~S170:

[0091] S100: Generate train information for a specified train number in each scenario;

[0092] S110: Set the available tickets in the train information;

[0093] S120: In response to a user's login operation, verify whether the user's login information is allowed to log in;

[0094] S130: After the user logs in, send an initial questionnaire to the user and obtain initial feedback data from the user's completion of the initial questionnaire;

[0095] S140: Display description information of each scenario to the user and obtain information on the ticket purchase behavior completed by the user in each scenario based on the train information and the remaining tickets;

[0096] S150: Send a scenario ticket purchase feedback questionnaire to the user and obtain scenario ticket purchase feedback data filled in by the user in the scenario ticket purchase feedback questionnaire;

[0097] S160: Send the final feedback questionnaire to the user and obtain the final feedback data filled in by the user in the final feedback questionnaire;

[0098] S170: Generate statistical analysis data based on the initial feedback data, the ticket purchase behavior information, the scenario ticket purchase feedback data, and the final feedback data.

[0099] Optionally, the step of displaying descriptive information of each scenario to the user and obtaining ticket purchase information completed by the user in each scenario based on the train information and the remaining tickets includes the following steps:

[0100] The descriptive information of multiple scenarios is displayed to the user in sequence;

[0101] The system sequentially acquires the ticket purchase information completed by the user in each of the aforementioned scenarios, based on the corresponding train information and the corresponding remaining tickets.

[0102] Optionally, the step of verifying whether the user's login information is allowed to log in in response to the user's login operation includes the following steps:

[0103] Get the phone number entered by the user;

[0104] Generate a verification code and send the verification code to the mobile phone number;

[0105] Obtain the verification code input by the user;

[0106] In response to the user's login operation, verify the mobile phone number and verification code entered by the user;

[0107] After successful verification, a token is generated and returned to the user, the user's login information is saved, and the user is then allowed to log in.

[0108] Optionally, obtaining the user's ticket purchase behavior information based on the train information and the remaining tickets in each of the aforementioned scenarios includes the following steps:

[0109] The train information can be retrieved based on the departure date, origin, and destination entered by the user in each of the aforementioned scenarios;

[0110] Determine the target train number selected by the user based on the train information;

[0111] Determine the passenger and seat type selected by the user based on the target train number;

[0112] Determine the remaining tickets used to measure whether seat selection requirements are met;

[0113] Determine whether the remaining tickets for the seat type of the target train are greater than or equal to the set number of tickets;

[0114] If the remaining tickets are greater than or equal to the set number of tickets, the user's seat selection is determined and the order is submitted;

[0115] If the remaining tickets are less than the set number of tickets, then submit the order.

[0116] Optionally, the method further includes the following steps:

[0117] If the number of remaining tickets is 0, then the seat selected by the user is marked as a waitlist.

[0118] The system determines that the user has submitted a waitlist order for a seat in the waitlist status and marks the user as having completed the ticket purchase.

[0119] The candidate orders are recorded in a unified order table.

[0120] Optionally, the method further includes the following steps:

[0121] If the user has not completed the initial questionnaire, the user will be prompted to complete the initial questionnaire and redirected to the page containing the initial questionnaire.

[0122] Redirecting the user to the corresponding scenario based on their current testing phase, and guiding the user to complete the ticket purchase within that scenario;

[0123] If a user fails to purchase a ticket in the corresponding scenario and attempts to access the questionnaire page for that scenario, the user will be prompted to complete the ticket purchase and redirected to the page for that scenario.

[0124] If the user completes the final feedback questionnaire, they will be redirected to the completion page.

[0125] Optionally, generating statistical analysis data based on the initial feedback data, the ticket purchase behavior information, the scenario-based ticket purchase feedback data, and the final feedback data includes the following steps:

[0126] Based on the initial feedback data, the ticket purchase behavior information, the scenario ticket purchase feedback data, and the final feedback data, a scenario ticket purchase preference analysis, a train selection distribution map, and a visual statistical data comparison of the frequency of waitlist ticket purchase behavior are generated.

[0127] Based on the initial feedback data, the ticket purchase behavior information, the scenario ticket purchase feedback data, and the final feedback data, differential analysis data between the user's initial preferences and actual ticket purchase behavior is generated.

[0128] The following section will provide a detailed introduction and explanation of the solutions in the embodiments of this application, using specific application examples.

[0129] Given the current technological landscape, how to leverage technology to deeply empower ticketing systems and design more intelligent and flexible ticket allocation and fare optimization schemes has become a pressing issue in the railway sector. Therefore, this application addresses the shortcomings of the current high-speed rail ticketing mechanism by proposing the design of a high-speed rail ticketing strategy simulation platform. By constructing a scenario-based ticketing test module, it simulates and analyzes the performance of ticketing strategies in specific scenarios, providing a scientific basis for dynamic ticket allocation and fare optimization. The research objectives include collecting and analyzing people's ticketing information to support the design and optimization of high-speed rail ticketing strategies, exploring the impact of waitlist ticketing, and improving ticket management from the perspective of dynamic ticket allocation; constructing targeted scenario-based test modules, such as those for Spring Festival travel rush ticketing and temporary ticketing needs, to simulate the effects of different ticketing strategies under these conditions; analyzing ticketing data through the platform to identify the deficiencies of the current ticketing mechanism and propose improvement suggestions to increase train occupancy rates and resource utilization efficiency; and providing technical support for the intelligent upgrade of the high-speed rail ticketing system, promoting the scientific and flexible management of the ticketing system.

[0130] 1. Overall technical solution.

[0131] This embodiment aims to simulate and evaluate high-speed rail ticket purchasing behavior, and expands upon the traditional high-speed rail ticket purchasing platform by adding process-oriented questionnaire surveys and data analysis capabilities.

[0132] 1.1.1 System functions.

[0133] This high-speed rail ticket purchase strategy simulation platform mainly includes user function modules and administrator function modules. The platform is designed as a streamlined scenario-based ticket purchase simulation system that includes a questionnaire function.

[0134] For users, in addition to the existing basic functions of high-speed rail ticketing platforms, such as searching for tickets, purchasing tickets, and viewing purchased tickets, a questionnaire function has been added. The questionnaire is divided into an initial questionnaire, a post-purchase feedback questionnaire, and a final questionnaire. The initial questionnaire is used to collect basic user information (including age, occupation, and high-speed rail ticketing preferences); the post-purchase feedback questionnaire includes scenario-related questions after each ticket purchase is completed; and the final questionnaire is used to collect user feedback and ratings for the platform.

[0135] For administrators, in addition to the basic functions of the existing high-speed rail ticketing platform, such as basic train schedule maintenance, daily train schedule maintenance, and ticket management, a ticketing data analysis function has been added. Administrators can intuitively view the questionnaire data filled in by users, the ticketing situation in various scenarios, and the analysis of the waitlist ticketing through a visual interface.

[0136] 1.1.2 System Overall Architecture.

[0137] This high-speed rail ticket purchase strategy simulation platform adopts a front-end and back-end separation architecture. The front-end is divided into the user end and the console end (i.e., the administrator end), while the back-end consists of multiple service modules, including the member management module, the business processing module, the task scheduling module, and the unified gateway module, which provide interface functions for the front-end interface to implement different functions.

[0138] exist Figure 2 In the application, the web module and admin module correspond to the user client and console client, respectively. The lower-level business client, member client, and batch client are different backend service modules, each with its own database for data storage. These modules are isolated from each other but have some data redundancy, facilitating direct access to data from other service modules within the same module. The gateway module is a crucial link between the frontend and backend. Its function is to route, intercept, and forward all requests from the frontend to the appropriate business, member, and batch modules for processing. Therefore, during production deployment, only the gateway module needs to be configured with an external IP address; other modules are only accessible via the internal network, preventing external access and ensuring application security. The common module mainly stores common utility classes, which can be called by all modules. The generator is a custom-designed code generator that uses the earliest developed member module project files as a template during development. This template is used to quickly generate code for subsequent modules, accelerating the development process.

[0139] 1.1.3 Process-oriented testing environment.

[0140] Based on the existing high-speed rail ticketing platform, this embodiment introduces a questionnaire system and a process control module to build a process-oriented testing environment, thereby simulating high-speed rail ticketing behavior and collecting data.

[0141] (1) User testing process control:

[0142] Upon first login, users are required to fill out an "Initial Questionnaire" to collect basic information and ticketing preferences. The process for each independent scenario follows the sequence of "Scenario Description → Simulated Ticket Purchase → Scenario Feedback Questionnaire," with a total of three ticketing scenarios. After all scenarios are completed, users fill out a "Final Questionnaire," and the system marks the process as complete. Each step is completed through a combination of front-end routing control and back-end status recording to ensure test integrity and data closure.

[0143] (2) Questionnaire data management and analysis:

[0144] Administrators can view various questionnaire data filled in by users through the system; the system provides visual statistics such as scenario-based ticket purchase preference analysis, train selection distribution map, and comparison of waitlist ticket purchase frequency; it provides a basis for analyzing the differences between initial preferences and actual ticket purchase behavior.

[0145] (3) Waiting list ticketing logic:

[0146] If there are no remaining tickets for a train, the system automatically marks the seat as "waitlist". Once the user clicks to place a waitlist order, it is considered a completed ticket purchase. Waitlist orders are recorded in a unified order table for subsequent analysis and processing.

[0147] (4) System data structure expansion:

[0148] A new "test" module database has been added to store user test status, questionnaire answers, and operation logs; the "test_user" table records test progress; multiple questionnaire answer tables are linked to "test_id" to ensure data consistency; and the "test_operation_log" table records each user's action, enabling the reconstruction of user behavior paths.

[0149] (5) System function optimization:

[0150] The system automatically fills in the origin, destination, and date during the ticket purchase process to prevent user errors; it also enhances the ability to configure ticket availability information, allowing for batch settings of ticket availability strategies for different scenarios.

[0151] Through the above implementation methods, this embodiment constructs a high-speed rail ticketing strategy testing platform that integrates simulated ticketing process, user behavior recording, and data analysis. It breaks through the limitation of traditional ticketing systems that can only provide ticketing services but cannot study ticketing behavior, and provides powerful tool support for the evaluation and optimization of high-speed rail ticketing strategies.

[0152] 1.2 More specific embodiments are as follows:

[0153] 1.2.1 Simulation process for key system scenarios.

[0154] In this embodiment, the three key scenarios simulate user login, testing, and ticket purchase.

[0155] (1) Login scenario.

[0156] The user clicks the button, enters their mobile phone number, and clicks "Send Verification Code." The backend generates a verification code and sends it to the user. The user enters the verification code and clicks "Login." The backend verifies the mobile phone number and verification code. If the verification is successful, a token is generated and returned to the frontend, and the user's login information is saved. The user logs in successfully. The login scenario flowchart is as follows: Figure 3 As shown.

[0157] (2) Test scenario.

[0158] After successful login, users first complete an initial questionnaire. Upon submission, they are redirected to the scenario description for simulated ticket purchase scenario one. After reading and understanding the ticket purchase task, they click "Go to Purchase Tickets" to be redirected to the ticket availability page to purchase tickets. After successful purchase, they are redirected to the scenario feedback questionnaire. Submitting this questionnaire redirects them to the next scenario. After completing all the scenarios, they are redirected to the final questionnaire, which they complete and then exit the system. The test scenario flowchart is as follows. Figure 4 As shown.

[0159] (3) Ticket purchase scenario.

[0160] Users enter the date, origin, and destination, click "Search," view train schedules matching their criteria, select a suitable train, and click "Book." They are then redirected to the passenger selection screen, where they choose the passenger and seat type, click "Confirm," and are redirected to the order confirmation screen. If the selected seat type has more or more available tickets than the set number, they can select their seats. Finally, they submit the order confirmation to successfully purchase the ticket. The ticket purchase process flowchart is shown below. Figure 5 As shown.

[0161] 1.2.2 Functional module design.

[0162] Based on the existing high-speed rail ticketing platform, this embodiment designs a system that combines user-side questionnaire surveys and administrator-side data analysis functions.

[0163] (1) Administrator (admin) function module.

[0164] The administrator module, building upon the existing functions of the high-speed rail ticketing platform—including basic high-speed rail data management, daily operation data management, batch processing management, and order and ticketing management—adds a test data statistical analysis function. The existing functions of the high-speed rail ticketing platform's administrator module and the newly added functions in this embodiment are shown in Tables 1 and 2, respectively.

[0165]

[0166] Table 1

[0167]

[0168] Table 2

[0169] (2) User (web) function module.

[0170] The existing high-speed rail ticketing platform user function module includes the functions of remaining ticket inquiry and ticket booking. This embodiment adds a series of related functions on the high-speed rail ticketing strategy simulation platform for questionnaire filling and scenario-based ticket purchase, specifically including: 1) Initial questionnaire collection: answering the questionnaire to collect basic information of users. 2) Description of each scenario: describing the hypothetical ticket purchase scenarios to guide users to make targeted ticket purchases later. 3) Post-purchase feedback for each scenario: answering scenario-specific questions to collect user answers. 4) Final questionnaire: filling in feedback on the high-speed rail ticketing strategy simulation platform. (3) Gateway function module.

[0171] The gateway module is the entry point of the entire system, responsible for handling all requests from the front end and routing them to the corresponding backend service modules. Its main functions include: 1) Unified entry point and routing: As the unified access entry point of the system (listening on port 8000), it routes requests to the corresponding backend business, member and batch modules according to the request path (such as / member / **, / business / **, / batch / **). 2) Access control and authentication (JWT): It implements a global filter to intercept most requests (excluding login, registration, verification code, administrator interface, etc.). It obtains the token parameter from the request header. It uses the JWT utility class (JwtUtil) to verify the validity of the token (signature, validity period). Requests with invalid or missing tokens will be intercepted and return a 401 unauthorized status. Only requests that pass the verification will be allowed to the downstream business service. 3) Cross-domain processing: It handles cross-domain request issues in the front-end and back-end separation architecture, allowing front-end applications (which may come from different domains) to call the backend API. (4) Business function module.

[0172] The business function modules are the core of the system, responsible for handling business logic related to high-speed rail ticket purchases. Main functions include: 1) Station Management: Managing high-speed rail station information, including adding, deleting, modifying, and querying station information. 2) Train Number Management: Managing high-speed rail train number information, including adding, deleting, modifying, and querying train numbers. 3) Carriage Management: Managing high-speed rail carriage information, including adding, deleting, modifying, and querying carriage information. 4) Seat Management: Managing high-speed rail seat information, including the configuration and status maintenance of different seat types. 5) Train Stop Management: Managing train stop information, including time and sequence. 6) Remaining Ticket Inquiry: Providing remaining ticket inquiry functions for different dates and origin / destination points. 7) Order Processing: Processing user ticket purchase orders, including seat selection, order confirmation, and remaining ticket updates. 8) Waiting List Order Processing: Processing user waitlist ticket purchase requests.

[0173] The business module interacts closely with the membership module and batch processing module. Communication between services is achieved through OpenFeign microservice components to ensure data consistency and business integrity.

[0174] (5) Member function module.

[0175] The membership module is responsible for managing user information and user-related services within the system. The existing high-speed rail ticketing platform functions mainly include: 1) User Management: Managing basic user information, including registration, login, and information modification. 2) Passenger Management: Managing passenger information added by users, including adding, deleting, modifying, and querying passenger information. 3) Ticket Management: Managing ticket information purchased by users, including viewing and refunding tickets.

[0176] The additional functions added to this embodiment include: 1) Questionnaire survey: collecting initial questionnaires filled out by users, feedback questionnaires after purchasing tickets, and final questionnaire data. 2) User behavior analysis: analyzing users' ticket purchasing behavior and preferences to provide data support for research.

[0177] The membership module provides user-related information and services to other modules and serves as a crucial interface for user interaction with the system. By encapsulating user-related business logic, the system architecture becomes clearer and easier to maintain.

[0178] (6) Batch processing module.

[0179] The batch processing module is responsible for tasks that need to be executed regularly in the system. Its main functions include: 1) Daily train schedule generation: Based on basic train schedule data, it generates train operation plans for future dates on a regular schedule. 2) Daily train stop generation: Based on basic train stop data, it generates stop information for future dates on a regular schedule. 3) Daily carriage generation: Based on basic carriage data, it generates carriage information for each train on a regular schedule for future dates on a regular schedule. 4) Daily seat generation: Based on basic seat data, it generates seat information for each train on future dates. 5) Task scheduling management: It manages scheduled tasks in the system, including task creation, modification, pause, and resumption. 6) Task execution status monitoring: It monitors the execution status of scheduled tasks and records execution logs to facilitate troubleshooting.

[0180] The batch processing module uses Quartz as its task scheduling framework, defining task execution times and frequencies through Cron expressions. The module is designed for high availability and scalability, meeting the system's needs for scheduled tasks.

[0181] 1.2.3 System database design.

[0182] To enhance data security, dedicate databases for specific purposes, avoid coupling, and improve system maintainability and data storage reliability, this embodiment implements reasonable redundancy for key data content in the database tables. Separate databases are created for the three modules: business, member, and batch. The business module is divided into two parts: the first part records basic high-speed rail data, and the second part, a daily data table, is generated based on the basic data and different conditions (such as train cancellations on different dates, or a train not stopping at a certain station on a certain day). This embodiment builds a high-speed rail ticketing strategy simulation platform based on the existing high-speed rail ticketing platform, constructing a dedicated database table to store data from user-completed questionnaires simulating ticket purchases within the system; this is called the test module.

[0183] 1.2.4 Complete system function process.

[0184] This embodiment designs a complete functional flow based on the existing high-speed rail ticketing platform, as follows:

[0185] (1) Administrator module.

[0186] 1) Daily train schedule information generation.

[0187] In the existing high-speed rail ticketing system, administrators can only generate information on all trains for a certain day with one click. However, in the high-speed rail ticketing strategy simulation platform of this embodiment, since the train data is different for each scenario, it is necessary to add a function to the train information generation interface to select specific trains for generation.

[0188] 2) Modify remaining ticket information.

[0189] To enable administrators to better configure the remaining ticket information for trains in various scenarios for testing, the high-speed rail ticketing strategy simulation platform in this embodiment has added the function of batch modifying the number of remaining tickets and the ticket price in the remaining ticket information module.

[0190] 3) Data analysis module.

[0191] This embodiment of the high-speed rail ticket purchase strategy simulation platform administrator terminal adds a data analysis module, which can perform statistical analysis on the data of users filling out questionnaires and simulating ticket purchases in the system. The train selection analysis interface, initial questionnaire analysis interface, post-purchase feedback analysis for various scenarios, and waitlist ticketing analysis interface are respectively shown below. Figure 6 , Figure 7 , Figure 8 and Figure 9 As shown.

[0192] (2) User module.

[0193] After completing the basic high-speed rail ticketing system, it will be based on Figure 5The process involves establishing a streamlined simulation platform for high-speed rail ticket purchasing strategies, incorporating a questionnaire function to simulate a real-world scenario.

[0194] 1) Log in.

[0195] Users enter their mobile phone number, obtain and enter the verification code, and click the "Login" button to enter the system.

[0196] 2) Initial questionnaire interface.

[0197] After logging into the system, users first need to complete an initial questionnaire to collect basic information. The initial questionnaire interface is as follows: Figure 10 As shown, information was collected regarding user gender, age, occupation, frequency of travel, number of times the waitlist ticketing function was used, the impact of high-speed rail ticket price fluctuations on travel time selection, and ticket purchasing preferences. Some of the collected information on users' preferences and frequency of high-speed rail ticket purchases can be used to verify and analyze subsequent users' actual ticket purchasing behavior.

[0198] 3) Interfaces for each test scenario.

[0199] After completing and submitting the initial questionnaire, users will enter various simulated scenarios to simulate ticket purchases. Upon entering a scenario, users must first browse the scenario description interface to understand the ticket purchase task. For example, in the scenario of "Limited Tickets for Spring Festival + Multiple Routes Available," the scenario description is as follows:

[0200] "The alarm clock blares, jolting you awake—tickets for New Year's Eve are on sale! You rush to your computer; the screen is still lit, the high-speed rail ticketing page is already open. Your fingers tremble as you type: City 1 → City 2, New Year's Eve. The page refreshes—all second-class tickets for popular trains are gone, and even first-class and business-class tickets are scarce. Trains departing later will be past their New Year's Eve dinner by then. Which train should you buy a ticket for…?" After reading the scenario description, click the "Buy Tickets" button below, and the system automatically redirects to… Figure 11 The scenario-based ticket availability query interface automatically fills in dates that match the user's ticketing needs. The origin and destination do not require manual selection by the user, ensuring that the user purchases a train ticket for the correct date and allowing them to focus more on train selection. This embodiment of the high-speed rail ticketing strategy simulation platform emphasizes the waitlist function. When there are zero available tickets, the number of available tickets is changed to waitlist and highlighted in red. Furthermore, passing stations are added next to the booking button, allowing users to easily find information on the train's stops, such as... Figure 12 As shown.

[0201] The subsequent non-waitlist ticketing process uses the same interface. When selecting a seat for which you wish to waitlist, a waitlist order interface will pop up, as shown below. Figure 13 As shown, clicking "OK" confirms the purchase. After the purchase is complete, the system automatically redirects to the post-purchase feedback screen, as shown below. Figure 14 As shown, users need to complete some post-purchase questions here, such as their reaction when there are insufficient tickets, whether they are willing to accept standing-room-only tickets to ensure their travel, and the factors they care about most during the ticket purchase process. At this point, they cannot return to the scenario description and post-purchase feedback interface, but they can return to the initial questionnaire to modify their answers and resubmit. After submitting the post-purchase feedback, they will be automatically redirected to the next scenario description.

[0202] 4) Final feedback and test completion interface.

[0203] After completing ticket purchases for all scenarios, users will be redirected to the final feedback questionnaire page. Here, users can fill in feedback and ratings for the high-speed rail ticket purchase strategy simulation platform, such as... Figure 15 As shown. After submitting the final feedback, you will be redirected to the test completion screen, as shown. Figure 16 As shown, the test is now complete.

[0204] (3) Test process control business logic implementation.

[0205] The high-speed rail ticketing strategy simulation platform is a process-oriented and scenario-based testing platform. How to systematically constrain users to complete the test step-by-step through routing control within the platform is a challenge. The following section introduces the process control logic, which is mainly implemented in the front-end routing file:

[0206] 1) Scene access control:

[0207] ① Initial Questionnaire: If the user has not completed the initial questionnaire, the system will prompt the user to complete the initial questionnaire and redirect the user to the initial questionnaire page.

[0208] ②Scene Access: Based on the user's current testing status, the system will allow or deny access to specific scene pages. For example:

[0209] If the user's status is "Initial Questionnaire," the system will prompt the user to complete the initial questionnaire and redirect them to the initial questionnaire page. If the user's status is "Scenario 1," the system will allow access to Scenario 1. If the user's status is "Scenario 2," the system will allow access to Scenario 2. If the user's status is "Scenario 3," the system will allow access to Scenario 3. If the user's status is "Final Questionnaire," the system will allow access to the final questionnaire. If the user's status is "Completed," the system will prompt the user and redirect them to the completion page.

[0210] 2) Scenario Questionnaire Access Control:

[0211] ①Scenario Questionnaire: The system will check whether the user has completed the ticket purchase in the corresponding scenario.

[0212] Incomplete Ticket Purchase: If a user attempts to access the questionnaire page for a specific scenario without completing the purchase, the system will prompt the user to complete the purchase and redirect them to the corresponding scenario page. Completed Ticket Purchase: If a user completes the purchase in a specific scenario and attempts to access the questionnaire page for that scenario, the system will allow access. Redirected After Successful Purchase: If a user is redirected directly from the ticket purchase page to the scenario questionnaire page (e.g., redirected to the scenario 1 questionnaire after successful ticket purchase), the system will grant access.

[0213] 3) Completion of status access control:

[0214] ① Test Completed: If a user's status is "Completed" and they attempt to access a non-complete page, the system will prompt the user and redirect them to the completed page.

[0215] ② Allow access: If a user's status is "Completed" and they attempt to access the completion page or the initial questionnaire page, the system allows access.

[0216] 4) Summary.

[0217] Through the above process control logic, the system ensures that users complete the test in the following order: ① Complete the initial questionnaire. ② Access the scenario and complete the ticket purchase. ③ Access the scenario questionnaire. ④ Complete the final questionnaire. ⑤ Access the completion page.

[0218] The innovations of this embodiment include: constructing a high-speed rail ticketing strategy simulation platform that combines SP and RP methods. It can set up numerous special scenarios and corresponding questionnaires, recording and analyzing the characteristics of passengers' ticketing choices and behaviors under these special scenarios.

[0219] The beneficial effects of this embodiment include:

[0220] Through in-depth analysis of ticket purchase data and strategy optimization, this implementation method can not only improve the economic benefits of railway enterprises, but also effectively alleviate the problem of passengers having difficulty purchasing tickets.

[0221] Research on optimizing high-speed rail ticketing strategies not only has significant theoretical value but also substantial practical implications and social impact. At the theoretical level, this embodiment takes passenger ticket selection and waitlisting as its starting point, exploring passenger ticketing behavior in diverse scenarios, thus deepening the content of ticketing strategy research. Simultaneously, the development of a ticketing strategy simulation platform and the construction of multi-scenario, multi-dimensional ticketing behavior analysis models not only enrich the research methods for ticketing strategies but also open up new directions for research on intelligent transportation systems.

[0222] In practice, this embodiment provides railway companies with highly operable tools and solutions to address ticket purchasing difficulties. By analyzing ticket purchasing data and scenario-based test results, railway departments can more accurately grasp passengers' ticket purchasing habits, thereby better adjusting ticket allocation and pricing strategies, effectively alleviating supply and demand imbalances, and optimizing ticket management strategies, especially during peak periods such as the Spring Festival travel rush and other holidays. The simulation platform not only helps railway companies reduce resource waste and improve transportation efficiency, but also supports the development of more flexible control measures during periods of surging passenger flow, ensuring improved passenger ticket purchase success rates and travel experience.

[0223] This embodiment also has significant social implications. By rationally allocating ticket quotas and optimizing the ticket purchasing process, and through repeated iterations of testing, feedback, and further optimization on the high-speed rail ticket purchasing strategy simulation platform constructed in this embodiment, railway companies can ultimately provide a more reasonable ticketing strategy and high-speed rail resource scheduling plan.

[0225] Reference Figure 17 This application provides a high-speed rail ticket purchase strategy simulation device, including:

[0226] The train number generation unit is used to generate train information for a specified train number in various scenarios;

[0227] The remaining ticket setting unit is used to set the remaining tickets in the train information;

[0228] The login verification unit is used to respond to the user's login operation and verify whether the user's login information is allowed to log in;

[0229] The initial feedback unit is used to send an initial questionnaire to the user after the user logs in and to obtain initial feedback data from the user's completion of the initial questionnaire.

[0230] The scenario-based ticketing unit is used to display description information of each scenario to the user and obtain information on the ticketing behavior completed by the user in each scenario based on the train information and the remaining tickets.

[0231] The ticket purchase feedback unit is used to send a scenario ticket purchase feedback questionnaire to the user and obtain scenario ticket purchase feedback data filled in by the user in the scenario ticket purchase feedback questionnaire;

[0232] The final feedback unit is used to send a final feedback questionnaire to the user and obtain the final feedback data filled in by the user in the final feedback questionnaire;

[0233] The statistical analysis unit is used to generate statistical analysis data based on the initial feedback data, the ticket purchase behavior information, the scenario ticket purchase feedback data, and the final feedback data.

[0234] It is understood that the content of the above method embodiments is applicable to the present device embodiments. The specific functions implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0235] In some alternative embodiments, the functions / operations mentioned in the block diagrams may not occur in the order shown in the operation diagrams. For example, depending on the functions / operations involved, two consecutively shown blocks may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order. Furthermore, the embodiments presented and described in the flowcharts of this application are provided by way of example to provide a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented herein. Alternative embodiments are contemplated in which the order of various operations is changed and sub-operations described as part of a larger operation are executed independently.

[0236] Furthermore, although this application is described in the context of functional modules, it should be understood that, unless otherwise stated, one or more of the described functions and / or features may be integrated into a single physical device and / or software module, or one or more functions and / or features may be implemented in a separate physical device or software module. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding this application. Rather, given the properties, functions, and internal relationships of the various functional modules in the apparatus disclosed herein, the actual implementation of the module will be understood within the scope of conventional technology for an engineer. Therefore, those skilled in the art can implement the application set forth in the claims using ordinary techniques without excessive experimentation. It is also understood that the specific concepts disclosed are merely illustrative and not intended to limit the scope of this application, which is determined by the full scope of the appended claims and their equivalents.

[0237] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0238] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-including system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device.

[0239] More specific examples of computer-readable media (a non-exhaustive list) include: electrical connections (electronic devices) having one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which the program can be printed, because the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0240] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using 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.

[0241] In the description of this specification, the 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 this application. 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.

[0242] Although embodiments of this application have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of this application, the scope of which is defined by the claims and their equivalents.

[0243] The above is a detailed description of the preferred embodiments of this application, but this application is not limited to the embodiments described. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this application, and these equivalent modifications or substitutions are all included within the scope defined by the claims of this application.

Claims

1. A method for simulating high-speed rail ticket purchasing strategies, characterized in that, The method includes the following steps: Generate train information for specified train numbers in various scenarios; Set the available tickets in the train information; In response to a user's login request, verify whether the user's login information is allowed. After a user logs in, an initial questionnaire is sent to the user to obtain initial feedback data from the user's completion of the initial questionnaire; Display descriptive information of each scenario to the user, and obtain information on the user's ticket purchase behavior in each scenario based on the train information and the remaining tickets; Send a scenario-based ticket purchase feedback questionnaire to users and obtain scenario-based ticket purchase feedback data filled in by users in the scenario-based ticket purchase feedback questionnaire; Send the final feedback questionnaire to the user and obtain the final feedback data filled in by the user in the final feedback questionnaire; Statistical analysis data is generated based on the initial feedback data, the ticket purchase behavior information, the scenario ticket purchase feedback data, and the final feedback data.

2. The high-speed rail ticket purchase strategy simulation method according to claim 1, characterized in that, The process of displaying descriptive information for each scenario to the user and obtaining ticket purchase information completed by the user in each scenario based on the train information and available tickets includes the following steps: The descriptive information of multiple scenarios is displayed to the user in sequence; The system sequentially acquires the ticket purchase information completed by the user in each of the aforementioned scenarios, based on the corresponding train information and the corresponding remaining tickets.

3. The high-speed rail ticket purchase strategy simulation method according to claim 1, characterized in that, The process of responding to a user's login operation and verifying whether the user's login information is allowed includes the following steps: Get the phone number entered by the user; Generate a verification code and send the verification code to the mobile phone number; Obtain the verification code input by the user; In response to the user's login operation, verify the mobile phone number and verification code entered by the user; After successful verification, a token is generated and returned to the user, the user's login information is saved, and the user is then allowed to log in.

4. The high-speed rail ticket purchase strategy simulation method according to claim 1, characterized in that, The process of obtaining user ticket purchase information based on train information and available tickets in various scenarios includes the following steps: The train information can be retrieved based on the departure date, origin, and destination entered by the user in each of the aforementioned scenarios; Determine the target train number selected by the user based on the train information; Determine the passenger and seat type selected by the user based on the target train number; Determine the remaining tickets used to measure whether seat selection requirements are met; Determine whether the remaining tickets for the seat type of the target train are greater than or equal to the set number of tickets; If the remaining tickets are greater than or equal to the set number of tickets, the user's seat selection is determined and the order is submitted; If the remaining tickets are less than the set number of tickets, then submit the order.

5. The high-speed rail ticket purchase strategy simulation method according to claim 1, characterized in that, The method further includes the following steps: If the number of remaining tickets is 0, then the seat selected by the user is marked as a waitlist. The system determines that the user has submitted a waitlist order for a seat in the waitlist status and marks the user as having completed the ticket purchase. The candidate orders are recorded in a unified order table.

6. The high-speed rail ticket purchase strategy simulation method according to claim 1, characterized in that, The method further includes the following steps: If the user has not completed the initial questionnaire, the user will be prompted to complete the initial questionnaire and redirected to the page containing the initial questionnaire. Redirecting the user to the corresponding scenario based on their current testing phase, and guiding the user to complete the ticket purchase within that scenario; If a user fails to purchase a ticket in the corresponding scenario and attempts to access the questionnaire page for that scenario, the user will be prompted to complete the ticket purchase and redirected to the page for that scenario. If the user completes the final feedback questionnaire, they will be redirected to the completion page.

7. A high-speed rail ticket purchase strategy simulation method according to any one of claims 1 to 6, characterized in that, The step of generating statistical analysis data based on the initial feedback data, the ticket purchase behavior information, the scenario ticket purchase feedback data, and the final feedback data includes the following steps: Based on the initial feedback data, the ticket purchase behavior information, the scenario ticket purchase feedback data, and the final feedback data, a scenario ticket purchase preference analysis, a train selection distribution map, and a visual statistical data comparison of the frequency of waitlist ticket purchase behavior are generated. Based on the initial feedback data, the ticket purchase behavior information, the scenario ticket purchase feedback data, and the final feedback data, differential analysis data between the user's initial preferences and actual ticket purchase behavior is generated.

8. A high-speed rail ticket purchase strategy simulation device, characterized in that, The device includes: The train number generation unit is used to generate train information for a specified train number in various scenarios; The remaining ticket setting unit is used to set the remaining tickets in the train information; The login verification unit is used to respond to the user's login operation and verify whether the user's login information is allowed to log in; The initial feedback unit is used to send an initial questionnaire to the user after the user logs in and to obtain initial feedback data from the user's completion of the initial questionnaire. The scenario-based ticketing unit is used to display description information of each scenario to the user and obtain information on the ticketing behavior completed by the user in each scenario based on the train information and the remaining tickets. The ticket purchase feedback unit is used to send a scenario ticket purchase feedback questionnaire to the user and obtain scenario ticket purchase feedback data filled in by the user in the scenario ticket purchase feedback questionnaire; The final feedback unit is used to send a final feedback questionnaire to the user and obtain the final feedback data filled in by the user in the final feedback questionnaire; The statistical analysis unit is used to generate statistical analysis data based on the initial feedback data, the ticket purchase behavior information, the scenario ticket purchase feedback data, and the final feedback data.

9. An electronic device, characterized in that, The electronic device includes a processor and a memory; The memory is used to store programs; The processor executes the program to implement the method as described in any one of claims 1 to 7.

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

Images