Parking lot pricing method and device, electronic equipment and storage medium

Abstract

The invention provides a parking lot pricing method and device, electronic equipment and a storage medium, and the method comprises the steps: obtaining multi-source data related to parking space use in a past preset time period; inputting the multi-source data into a demand prediction model, and predicting a parking space demand prediction vector in a future preset time period; inputting the data containing the price change and the demand change into a price elasticity model to obtain a price elasticity prediction vector in a future preset time period; generating a plurality of candidate prices based on the parking space demand prediction vector and the price elasticity prediction vector; carrying out an online price experiment on the plurality of candidate prices at a flow rate not exceeding a preset proportion; and determining a final parking plan price according to a feedback result of the online price experiment. According to the method and the device, the final parking package price is automatically determined based on the feedback result, automatic pricing decision based on data and a model is realized, and the accuracy of demand prediction and price elasticity estimation is improved.

Description

Technical Field

[0001] This application relates to the field of intelligent algorithm technology, and more specifically, to a parking lot pricing method, device, electronic device, and storage medium. Background Technology

[0002] Currently, traditional parking lot package pricing methods mainly rely on the personal experience of managers and periodic market research, which are significantly lagging and inefficient. Pricing strategies are usually based on static factors (such as geographical location and fixed time periods), with update cycles lasting for weeks or even months. This makes it impossible to respond to real-time changes in supply and demand (such as sudden weather events and peak traffic periods) and differences in parking behavior among different users, resulting in the inability to achieve optimal parking space resource utilization efficiency and operational revenue.

[0003] Furthermore, traditional methods for validating new pricing strategies often employ A / B testing across all user traffic. This approach not only fails to effectively control individual variables, making accurate evaluation of test results difficult, but also risks triggering widespread user complaints due to inappropriate strategies, resulting in high trial-and-error costs and business risks. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide a parking lot pricing method, apparatus, electronic device and storage medium to overcome at least one of the above-mentioned defects.

[0005] In a first aspect, embodiments of this application provide a parking lot pricing method, the method comprising: acquiring multi-source data related to parking space usage over a preset past time period; inputting the multi-source data into a demand forecasting model to predict a parking space demand forecast vector over a preset future time period; inputting data including price changes and demand changes into a price elasticity model to obtain a price elasticity forecast vector over the preset future time period; generating multiple candidate prices based on the parking space demand forecast vector and the price elasticity forecast vector; conducting online price experiments with the multiple candidate prices at a flow rate not exceeding a preset proportion; and determining the final parking package price based on the feedback results of the online price experiments.

[0006] In one optional embodiment of this application, the candidate price is determined by: calculating the estimated revenue based on the parking space demand prediction vector and the price elasticity prediction vector under different price changes; with the goal of maximizing the comprehensive revenue index, searching and selecting the corresponding price change range through an optimization algorithm, and determining the candidate price based on the selected price change range.

[0007] In one optional embodiment of this application, the step of conducting online price experiments on the multiple candidate prices with a flow rate not exceeding a preset proportion includes: under the multi-armed gambling machine algorithm framework, each candidate price is treated as an arm for experimentation; based on the cumulative number of times each candidate price arm is selected and the fluctuation of cumulative revenue, the experimental strategy is automatically switched, including the following steps: when a first preset condition is met, the first strategy is adopted for experimentation, and candidate price arms are randomly selected with a preset exploration probability, and the candidate price arm with the best current revenue is selected with a complementary probability; when a second preset condition is met, the experiment is switched to the second strategy, and an upper confidence bound is calculated based on the mean revenue and uncertainty of each candidate price arm, and the candidate price arm with the largest upper confidence bound is selected; when a third preset condition is met, the experiment is switched to the third strategy, and probability sampling is performed based on the posterior distribution of revenue of each candidate price arm, and candidate price arms are selected according to the sampling results.

[0008] In one optional embodiment of this application, the first preset condition includes that the cumulative number of times any candidate price arm is selected is less than a first number threshold, and the first preset condition also includes that the standard deviation of the cumulative return is higher than a first volatility threshold; the second preset condition includes that the cumulative number of times all candidate price arms are selected reaches or exceeds the first number threshold, and the standard deviation of the cumulative return is less than or equal to the first volatility threshold; the third preset condition includes that the cumulative number of times all candidate price arms are selected reaches or exceeds a second number threshold, and the standard deviation of the cumulative return is less than or equal to a second volatility threshold within multiple consecutive preset time windows.

[0009] In one optional embodiment of this application, the method further includes: automatically reverting to restarting the experiment using the first strategy when the standard deviation of the cumulative return is detected to continuously exceed the first volatility threshold during the second strategy or third strategy phase; and immediately terminating the experiment and rolling back to the price before the experiment when the customer complaint rate is detected to exceed a preset complaint rate threshold during the experiment.

[0010] In one optional embodiment of this application, the final parking package price is determined as follows: based on the feedback results of the online price experiment, data on the actual revenue, parking space turnover rate, and customer complaint rate of each candidate price under the experimental traffic are collected; based on the collected data, the comprehensive revenue index of each candidate price is recalculated; and the candidate price with the highest comprehensive revenue index is selected as the final parking package price.

[0011] In an optional embodiment of this application, the method further includes: monitoring actual business indicators after the final parking package price is executed, the business indicators including total transaction volume, parking space turnover rate, and customer complaint rate; triggering a model update instruction when the decrease in total transaction volume exceeds a first preset threshold; triggering a model update instruction when the decrease in parking space turnover rate exceeds a second preset threshold; triggering a model update instruction when the customer complaint rate exceeds a third preset threshold; retraining the demand prediction model using newly added business data according to the triggered model update instruction; and retraining the price elasticity model using newly added transaction data and price change data.

[0012] In one optional embodiment of this application, the method further includes: extracting the original data fields when the abnormal scene occurs, the original data fields including time features, weather data, event data, price data and traffic flow data; filtering out a preset number of key features from the original data fields using a feature importance analysis algorithm; and writing the filtered key features into a feature warehouse for subsequent model training and optimization.

[0013] Secondly, embodiments of this application also provide a parking lot pricing device, the device comprising: a multi-source data acquisition module, used to acquire multi-source data related to parking space usage within a preset time period in the past; a parking space demand prediction vector prediction module, used to input the multi-source data into a demand prediction model to predict a parking space demand prediction vector within a preset time period in the future; a price elasticity prediction vector acquisition module, used to input data including price changes and demand changes into a price elasticity model to obtain a price elasticity prediction vector within a preset time period in the future; a candidate price generation module, used to generate multiple candidate prices based on the parking space demand prediction vector and the price elasticity prediction vector; an online price experiment module, used to conduct an online price experiment with the multiple candidate prices at a flow rate not exceeding a preset proportion; and a final parking package price determination module, used to determine the final parking package price based on the feedback results of the online price experiment.

[0014] Thirdly, embodiments of this application also provide an electronic device, including: a processor, a memory, and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the memory via the bus, and when the machine-readable instructions are executed by the processor, the steps of the method described above are performed.

[0015] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the method described above.

[0016] The parking pricing method, device, electronic equipment, and storage medium provided in this application acquire multi-source data related to parking space usage over a preset time period; input the multi-source data into a demand forecasting model to predict a parking space demand forecast vector for a future preset time period; input data including price changes and demand changes into a price elasticity model to obtain a price elasticity forecast vector for the future preset time period; generate multiple candidate prices based on the parking space demand forecast vector and the price elasticity forecast vector; conduct online price experiments with the multiple candidate prices at a flow rate not exceeding a preset proportion; and determine the final parking package price based on the feedback results of the online price experiments. This application automatically determines the final parking package price based on the feedback results, avoiding human decision-making bias and reducing customer complaint rates.

[0017] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating the parking pricing method provided in this application embodiment; Figure 2 A flowchart for determining candidate prices provided in an embodiment of this application; Figure 3 A flowchart for determining the final parking package price provided in an embodiment of this application; Figure 4 This is a schematic diagram of the parking pricing device provided in the embodiments of this application; Figure 5 The present application provides a schematic diagram of the structure of an electronic device. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. Based on the embodiments of this application, every other embodiment obtained by those skilled in the art without inventive effort falls within the scope of protection of this application.

[0021] First, the applicable scenarios for this application will be introduced. This application can be applied to the field of intelligent algorithm technology.

[0022] Research has revealed that traditional parking lot package pricing methods rely heavily on managers' personal experience and static market research, resulting in issues such as long update cycles, inability to respond to real-time supply and demand fluctuations, and neglect of individual user differences. Furthermore, the full A / B testing method used in the price verification phase not only struggles to accurately assess effectiveness but also carries a high risk of triggering large-scale user complaints.

[0023] Furthermore, traditional parking space package pricing typically relies on human experience and market research, lacking real-time responsiveness and flexibility. Traditional parking space package pricing suffers from three major drawbacks: 1) It relies on human experience and has a long update cycle (weekly or even monthly). 2) Only static factors (location, time of day) are considered, ignoring dynamic supply and demand fluctuations and individual customer differences; 3) Price testing often uses full A / B testing, which makes it impossible to control a single variable, and the test results are difficult to evaluate.

[0024] Based on this, embodiments of this application provide a parking lot pricing method, device, electronic device, and storage medium to solve the problems of traditional pricing relying on human experience, slow response, inability to adapt to dynamic supply and demand changes, and high trial-and-error costs and risks in price testing. It realizes the automation of pricing strategies, improves parking lot operating revenue and resource utilization efficiency, and reduces customer complaint rates.

[0025] Please see Figure 1 , Figure 1 A flowchart illustrating the parking pricing method provided in this application embodiment. Figure 1 As shown in the embodiments of this application, the parking lot pricing method includes: S101. Obtain multi-source data related to parking space usage within a preset time period in the past.

[0026] In this step, multi-source data related to parking space usage over a preset time period can be directly collected from the parking management system, including the number of remaining parking spaces (counted by parking space sensors or turnstiles), turnstile entry and exit flow (real-time vehicle entry and exit records), and real-time sales of packages (obtained from the sales system). For example, historical data from the past thirty days can be selected.

[0027] Customer profiles can be generated based on historical order data, with nearly 30 days of data updated every day at midnight.

[0028] Specific dimensions include: vehicle attributes (such as vehicle model and license plate number, which are processed by MD5+Salt hashing to protect privacy).

[0029] Single / cumulative parking duration, cumulative spending amount, number of parking sessions across days, and main parking periods (weekdays / non-weekday peak hours).

[0030] Price elasticity coefficient (calculated through historical price adjustment responses, such as user sensitivity to price changes).

[0031] External features can be obtained from third-party APIs or public data sources, including holiday identifiers (calendar data), weather data (meteorological services), information on surrounding events (such as schedules of large events), and traffic control notices (traffic management departments).

[0032] Supply constraints can be obtained from parking lot operation plans, including the number of parking spaces available for a given time period (based on parking space availability) and maintenance plans (regular maintenance arrangements).

[0033] These multi-source data are used to comprehensively capture the dynamic supply and demand of parking spaces, user behavior preferences, and the influence of the external environment, providing input features for the model.

[0034] By integrating multi-source data, the system can perceive the internal and external conditions of the parking lot in real time, avoiding reliance on static or manual experience and improving the accuracy and adaptability of pricing.

[0035] S102. Input multi-source data into the demand forecasting model to predict the parking space demand forecast vector within a preset time period in the future.

[0036] Preferably, the model can use an LSTM (Long Short-Term Memory) model, as it is good at handling time series data.

[0037] Input features include multidimensional features, including but not limited to time features (such as weekday, hour, whether it is a holiday), aggregation features (such as historical average traffic flow, average of the same period in the past 7 days, standard deviation, month-on-month, year-on-year), customer features, which can be RFM (most recent consumption, frequency, amount) + parking behavior sequence (LSTM encoding), interaction features, such as parking space occupancy rate, price elasticity, weather, and activity level, and external features (such as weather, activities).

[0038] Specifically, it includes: Time characteristics: such as day of the week, hour of the day, whether it is a holiday, or whether it is a day with a major event. These characteristics are used to capture cyclical demand patterns.

[0039] Historical demand sequence: Historical traffic flow data such as parking space occupancy rate and gate entry / exit flow during the same time period over a past period (e.g., 7 days). This is the most important input to the LSTM model, used to learn trends and sequence patterns.

[0040] Aggregated features: Statistical features calculated based on historical data, such as average demand, standard deviation, month-on-month growth rate, and year-on-year growth rate for the same period in the past 7 days, to provide richer contextual information.

[0041] Customer behavior characteristics: Aggregated user behavior representations obtained by encoding historical parking behavior sequences (such as user parking duration, arrival time, etc.) (e.g., using another LSTM encoder) are used to reflect the overall parking habits of users.

[0042] External characteristics, such as weather conditions (sunny, rainy, snowy, temperature), whether there are large-scale events nearby, and whether there is traffic control, can significantly affect traffic flow.

[0043] The output parameter is the predicted parking space demand vector D=[d0,d1,...,d] for each time period in the next 24 hours. 23 ], middle d i This represents the demand in the i-th hour (unit: number of vehicles). This forecast is an estimate of future demand based on the input features.

[0044] The model is trained based on historical traffic flow data, and the training samples include order data from the past 90 days (e.g., 1.2 million orders) and external features.

[0045] LSTM models can capture the temporal patterns of historical traffic flow, providing high-precision demand forecasts, laying the foundation for dynamic pricing, and reducing resource waste or congestion caused by demand fluctuations.

[0046] S103. Input the data containing price changes and demand changes into the price elasticity model to obtain the price elasticity prediction vector for the future preset time period.

[0047] In one optional embodiment of this application, the model may use an ensemble learning model such as XGBoost or NGboost, focusing on regression or classification tasks.

[0048] Input features include pairwise sample data from historical price adjustment records or online price experiments. Each sample represents a price change that occurred within a specific time period and its resulting market reaction, specifically including: Price change percentage: The percentage change in price relative to the benchmark price during historical price adjustment events (e.g., +10%, -5%).

[0049] Corresponding time-period characteristics: the hour, day of the week, and whether it is a holiday when the price change occurs. These characteristics are used to help the model learn the differences in price elasticity at different times (for example, the elasticity during the morning rush hour may be different from that at noon).

[0050] The output parameter is the price elasticity vector E=[ε0,ε1,...,ε] predicted for each period in the next 24 hours. 23 ], where ε i This represents the price elasticity coefficient in the i-th hour (i.e., the response of the rate of change in demand to the magnitude of a price change, such as a 10% price increase leading to a 5% decrease in demand).

[0051] The specific meaning of this coefficient is: under the current environmental conditions, the percentage change in quantity demanded that is expected to result from a unit price change (e.g., 1%) during time period i. For example, if ε i =-0.5 means that if the price increases by 10% during that period, the expected demand will decrease by 5% (calculation: 10%×(-0.5)=-5%).

[0052] The model is trained based on historical transaction data and price change data, and fits the relationship between price and demand through supervised learning.

[0053] The price elasticity vector E will be combined with the demand forecast vector D for revenue calculation and candidate price generation. The model will be updated periodically (the interval can be limited according to actual conditions) to reflect market changes.

[0054] S104. Based on the parking space demand forecast vector and the price elasticity forecast vector, generate multiple candidate prices.

[0055] For details, please refer to Figure 2 , Figure 2 The flowchart for determining candidate prices provided in the embodiments of this application is as follows: Figure 2 As shown, candidate prices are determined in the following way: S201. Calculate the estimated revenue based on the parking space demand forecast vector and the price elasticity forecast vector under different price changes.

[0056] The purpose of this step is to use the prediction results from the first two steps (price elasticity prediction vector D and price elasticity prediction vector E) to simulate the possible returns at different price levels through a return calculation model.

[0057] First, define the price fluctuation range and step size: Set a range for exploring price changes, such as within ±25% of the current standard price. Then generate a series of candidate price change ranges ΔP (e.g., -10%, -5%, 0%, +5%, +10%) with a set step size (e.g., 1% or 5%).

[0058] Then, perform the revenue calculation: For each candidate ΔP, the system iterates through each time period i in the next 24 hours and calculates the estimated return Ri for that time period under the price change.

[0059] The calculation formula used is as follows: Estimated revenue R = Price × Parking space demand forecast vector D × (1 + Price elasticity forecast vector E × Price change magnitude) Complaints result in fines.

[0060] Here, price refers to the standard price value. This is a benchmark price, usually derived from the statistical average of historical data or the standard package price set by the operator; forecasted demand D represents the predicted parking space demand for each time period in the next 24 hours; the price elasticity forecast vector E represents the sensitivity of demand to price changes (e.g., ε) for each time period in the next 24 hours. i =-0.5 indicates that a 1% increase in price corresponds to a 0.5% decrease in demand. The price change is ΔP, which is the difference between the current price and the standard price value. The complaint penalty is a configurable parameter that can be derived by modeling the relationship between historical customer complaint data and price changes.

[0061] For example, the larger the price increase, the higher the potential risk of complaints, and the higher the corresponding "fine".

[0062] Finally, calculate the total aggregate revenue: The estimated daily total return is obtained by summing the estimated returns Ri of a candidate ΔP over all 24 time periods.

[0063] Preferably, to make more robust decisions, the returns of ΔP over the next 30 days (using predicted demand and elasticity) are simulated and summed to obtain the estimated total monthly return, which serves as the basis for the final comparison.

[0064] Furthermore, all the calculated candidate ΔP and their corresponding estimated total revenue will form a "revenue-price" curve, which will serve as the input to the optimization algorithm in S202.

[0065] S202. With the goal of maximizing the comprehensive return index, the corresponding price change range is searched and selected through the optimization algorithm, and the candidate price is determined based on the selected price change range.

[0066] This step involves finding the most balanced price point that maximizes overall returns.

[0067] First, we define a comprehensive return metric and use a multi-objective function to comprehensively evaluate the performance of a price strategy: Objective = α × GMV + β × Turnover Rate - r × Customer Complaint Rate Among them, Objective (Comprehensive Revenue Index) is a comprehensive quantitative indicator used to measure the quality of pricing strategies; α, β, and r are all weighting coefficients used to adjust the importance of GMV, turnover rate, and customer complaint rate in the comprehensive index; GMV is the total transaction value of goods and services, which is the estimated price multiplied by the predicted demand D, and is directly related to revenue; turnover rate can be calculated based on the predicted demand D and the total number of parking spaces in the parking lot, measuring the efficiency of parking space utilization; customer complaint rate can be determined by the ratio of customer complaints to business order volume.

[0068] The configurable weighting coefficients α, β, and r are dynamically adjusted by the parking lot operator based on current business objectives. For example, if the current performance focus is on revenue, α is increased; if improving parking space utilization efficiency is needed to alleviate congestion, β is increased; if customer satisfaction has recently declined and stability needs to be maintained, r is increased.

[0069] Then, the search is performed using an optimization algorithm.

[0070] In an optional embodiment of this application, the algorithm may use Bayesian optimization.

[0071] Bayesian optimization treats the overall return metric Objective as a "black box" function of the price change magnitude ΔP.

[0072] It uses the results of a series of discrete candidate points calculated in S201 to construct a surrogate model (usually a Gaussian process) to predict the distribution of Objective throughout the entire ΔP search space.

[0073] Then, a sampling function (such as Expected Improvement) is used to determine the next ΔP point to be evaluated, which maximizes the search in areas of high predicted returns and areas of high uncertainty.

[0074] After several iterations, the algorithm will converge to an optimal price change range ΔP'.

[0075] Finally, the candidate prices were determined.

[0076] Based on the found optimal price change range ΔP', the final candidate price is calculated using the formula: candidate price = standard price value + ΔP'.

[0077] Preferably, one or more candidate prices can be generated and sent to the S105's small-volume online pricing experiment (Multi-Armed Bandit framework) for real-world verification.

[0078] For example, the system can generate three candidate prices with the highest comprehensive return indicators as alternatives for online price experiments in S105.

[0079] This application employs a Bayesian optimization algorithm, which can search and obtain near-global optimal solutions on complex nonlinear revenue surfaces, avoiding getting trapped in local optima and thus maximizing the overall system revenue. Ultimately, the candidate prices generated through this offline optimization process are all options that have been verified through simulation. This provides high-quality input for subsequent small-scale online pricing experiments, improving the efficiency and success rate of online experiments and reducing business risks caused by testing ineffective strategies.

[0080] S105. Conduct online price experiments with multiple candidate prices using traffic not exceeding a preset ratio.

[0081] This step is performed within the Multi-Armed Bandit (MAB) algorithm framework. The system treats each candidate price generated by S104 as an "arm," and conducts online experiments by allocating a small portion of real user traffic (not exceeding a preset proportion, defaulting to 10%) to these candidate prices to observe their actual revenue performance. Based on the feedback data, the system intelligently adjusts the traffic allocation strategy.

[0082] Bandit strategy: ε-Greedy-UCB-Thompson Sampling three-stage progression to ensure a balance between convergence speed and returns.

[0083] The bandit strategy is a core method for solving the exploit-explore problem in recommendation systems. It optimizes recommendation performance by balancing the exploitation of users' known interests (exploit) with the exploration of potential interests (explore). In this scenario, it's similar to adding an "autopilot mode" to the system, automatically shifting between levels 1, 2, and 3 based on road conditions (data volume, confidence level, revenue fluctuations), as shown in Table 1 below. Table 1:

[0084] Experimental window: Start 48 hours in advance for holidays / large-scale events and roll every 4 hours during normal periods.

[0085] Risk threshold: Experimental traffic ≤ 10%. If the complaint rate > 0.5% (complaint rate = number of customer complaints / number of business orders, updated in real time based on system data, and the customer complaint rate threshold can be configured and adjusted), roll back immediately. After rollback, historical data and adjustment records are saved normally and re-enter model training.

[0086] Specifically, under the framework of the multi-armed bandit algorithm, each candidate price is used as an arm for experiments.

[0087] According to the fluctuations of the cumulative number of times each candidate price arm is selected and the cumulative revenue, automatically switch the experimental strategy, including the following steps: When the first preset condition is met, conduct experiments using the first strategy, randomly select a candidate price arm with a preset exploration probability, and select the candidate price arm with the optimal current revenue with a complementary probability.

[0088] The first preset condition includes that the cumulative number of times any candidate price arm is selected is lower than the first number threshold, and the first preset condition also includes that the standard deviation of the cumulative revenue is higher than the first fluctuation threshold.

[0089] Here, the first strategy (Level 1: ε-Greedy) - cold start exploration stage, trigger condition (the first preset condition): the cumulative number of times any candidate price arm is selected < N1: N1 is the first number threshold, with a default value of 100 times. This condition means that at least one manually set price option lacks sufficient data.

[0090] The standard deviation of the cumulative revenue > σ1: σ1 is the first fluctuation threshold. This condition indicates that the revenue performance of each price arm fluctuates greatly and the uncertainty is high, and the system is still in the "groping" stage.

[0091] Experimental strategy: The system randomly selects an arm for exploration with a probability of ε (exploration probability) = 0.2.

[0092] Select the arm with the highest current cumulative revenue mean for exploitation with a probability of 1 - ε = 0.8.

[0093] Furthermore, the system continuously monitors the cumulative number of times all arms are selected and the standard deviation of the revenue. Once all arms have been fully explored (i.e., reaching N1 times) and the revenue tends to be stable (standard deviation ≤ σ1), it automatically switches to the next strategy.

[0094] When the second preset condition is met, switch to the second strategy to conduct the experiment. Calculate the upper confidence bound based on the average return and uncertainty of each candidate price arm, and select the candidate price arm with the largest upper confidence bound.

[0095] The second preset condition includes that the cumulative number of times all candidate price arms are selected reaches or exceeds the first number threshold, and the standard deviation of the cumulative return is less than or equal to the first volatility threshold.

[0096] Here, the trigger condition (second preset condition) is: the cumulative number of times all candidate price arms have been selected is ≥ N1.

[0097] The standard deviation of cumulative returns is ≤σ1. This indicates that the preliminary data has stabilized and more refined decision-making can begin.

[0098] Experimental strategy: The system was switched to the UCB1 (Upper Confidence Bound) algorithm, which not only considers the historical mean return of the arm, but also adds a "confidence interval safety band" (i.e., uncertainty measure). Arms with less data have higher uncertainty and wider confidence intervals, and are therefore more likely to be selected.

[0099] Each time, select the arm with the largest UCB value (mean return + uncertainty compensation).

[0100] Furthermore, the system continues to collect data. When the number of times all arms are selected reaches a higher threshold (N2), and the returns are very stable over multiple consecutive time windows, the system switches to the final strategy.

[0101] When the third preset condition is met, switch to the third strategy to conduct the experiment. Probability sampling is performed based on the posterior distribution of the returns of each candidate price arm, and candidate price arms are selected based on the sampling results.

[0102] The third preset condition includes that the cumulative number of times all candidate price arms are selected reaches or exceeds the second threshold, and the standard deviation of the cumulative return is lower than or equal to the second volatility threshold within multiple consecutive preset time windows.

[0103] Triggering condition (third preset condition): The cumulative number of times all candidate price arms have been selected is ≥ N2: N2 is the second threshold number, for example, usually 500 times.

[0104] The standard deviation of returns for K consecutive rounds is ≤σ2: K (e.g., 20 rounds) is the number of consecutive preset time windows; σ2 is the second volatility threshold, a more stringent upper limit of volatility than σ1. This indicates that the system has collected a large amount of data and the returns of each price arm are very stable.

[0105] Experimental strategy: The system was switched to the Thompson Sampling algorithm.

[0106] It maintains a probability distribution (such as a Beta distribution) for the payoff of each arm. At each selection, it samples based on the posterior probability that each arm is the current best arm, and "the arm with the highest probability is most likely to be selected".

[0107] Subsequently, the optimal arm output at this stage will most likely become the final parking package price in S106. Meanwhile, the system continuously monitors fluctuations to prevent sudden changes in the external environment.

[0108] Specifically, it also includes: When the standard deviation of the cumulative return is detected to exceed the first volatility threshold continuously during the second or third strategy phase, the experiment will automatically revert to the first strategy and restart; and during the experiment, when the customer complaint rate is detected to exceed the preset complaint rate threshold, the experiment will be terminated immediately and rolled back to the price before the experiment.

[0109] Here, in the second or third strategy phase, if external conditions change abruptly (such as holidays or extreme weather), resulting in a standard deviation of returns > σ1 for three consecutive rounds, the system will immediately and automatically downgrade back to the first strategy (ε-Greedy), reset the counter to zero, and restart the exploration to adapt to the new environment.

[0110] Furthermore, during the experiment, if the customer complaint rate exceeds 0.5% (the preset complaint rate threshold) in real time, the experiment is immediately terminated and rolled back to the price before the experiment. After the rollback, historical data and adjustment records are saved normally, and the system re-enters the model training phase.

[0111] Unlike full A / B testing, which wastes a lot of traffic on potentially bad prices, this application guides most traffic to the best-performing price while exploring, maximizing the cumulative benefits during the experiment. The progressive strategy and automatic downgrading mechanism can automatically select the most suitable experimental strategy based on the amount of data, confidence level, and degree of environmental fluctuation, without manual intervention, ensuring stability throughout the entire process from cold start to stable operation.

[0112] Furthermore, small-scale experiments can limit the impact of the experiment to less than 10% of the total traffic, keeping potential negative impacts within a controllable range; the automatic rollback mechanism based on real-time complaint rates can quickly respond to negative feedback and prevent the situation from escalating.

[0113] S106. Based on the feedback from the online price experiment, determine the final parking package price.

[0114] After the final parking package price is determined, the system can send the price instruction to hardware devices such as parking space status indicator screens and gate billing terminals through the parking management system for execution.

[0115] Optionally, to enhance user experience, the system can also proactively push price change information to users' mobile terminals located within a certain geofence of the parking lot or those who have previously used the parking lot through technical interfaces with mobile application (APP) servers or message push services, thus completing the entire service chain from decision-making to notification.

[0116] This application constructs a complete automated technology closed loop from data acquisition, intelligent prediction, strategy generation, online experimentation to decision execution. This closed loop can automatically sense environmental changes (data input), autonomously perform model reasoning and strategy calculation (model processing), verify and adjust strategies in a controlled manner in a real environment (experiment execution), and finally automatically output optimized control commands (pricing decision), realizing continuous technical optimization and control of the dynamic system of parking lot pricing.

[0117] Specifically, please refer to Figure 3 , Figure 3 The flowchart for determining the final parking package price provided in the embodiments of this application is as follows: Figure 3 As shown, the final parking package price is determined in the following way: S301. Based on the feedback results of the online pricing experiment, collect data on the actual revenue, parking space turnover rate, and customer complaint rate of each candidate price under the experimental traffic.

[0118] This step aims to obtain real and reliable business data from small-scale online experiments.

[0119] All data can be derived from real business records generated by the online pricing experiment system during the experiment period (such as a few days or a week).

[0120] The specific parameters collected, their meanings, and calculation methods are as follows: Actual revenue is the total revenue actually generated for each candidate price under experimental traffic.

[0121] The actual profit is obtained by summing the amounts of all executed orders at this price, reflecting the liquidity of this pricing strategy.

[0122] Parking space turnover rate is an indicator of the utilization efficiency of parking spaces using the candidate price during the experiment.

[0123] During the experimental period, the total number of times these parking spaces were used was the quotient of the number of available parking spaces. A high turnover rate indicates that parking space resources are being fully utilized.

[0124] The customer complaint rate is used to measure the negative impact of the candidate price on customer satisfaction.

[0125] Calculation method: Complaint rate = Number of customer complaints ÷ Number of business orders.

[0126] For example, if a certain price generates 1,000 orders and receives 5 complaints during the experiment, the complaint rate is 0.5%.

[0127] S302. Based on the collected data, recalculate the comprehensive return index for each candidate price.

[0128] This step is used to substitute the actual business data collected by S301 into a preset multi-objective function for quantitative evaluation.

[0129] The calculation formula used is: Objective = α × GMV + β × Turnover Rate - r × Customer Complaint Rate Substitute the "actual revenue" of a candidate price collected in S301 into the formula as GMV; substitute the "parking space turnover rate" of that price collected in S301 into the formula; substitute the "customer complaint rate" of that price collected in S301 into the formula.

[0130] The weighting coefficients (α, β, and r) are preset, configurable weighting coefficients. Their specific values ​​are determined by the parking lot operator based on current strategic objectives.

[0131] After the calculations are complete, each candidate price will receive a quantified comprehensive revenue score. This score comprehensively reflects the price's overall performance across three dimensions: revenue, efficiency, and user experience.

[0132] S303. Select the candidate price with the highest comprehensive benefit index as the final parking package price.

[0133] The comprehensive revenue index scores of all candidate prices are sorted, and the candidate price with the highest score is selected as the final parking package price to be released to all users.

[0134] This decision does not solely pursue the highest revenue (GMV) or the lowest complaint rate, but rather selects the price point that achieves the optimal balance of overall performance under the given strategic objectives (represented by α, β, and r).

[0135] Subsequently, incremental releases will be conducted. The final parking package price will not be launched immediately across all platforms, but will be released gradually using a canary release strategy. For example, the traffic will be gradually released in the proportion of 5% → 15% → 50% → 100%, and core business indicators (GMV, turnover rate, complaint rate) will be closely monitored at each stage.

[0136] Customer notification: If the final parking package price changes by more than ±10% compared to the original price, a triple notification will be sent via SMS, App Push, and parking lot LED screen to ensure price transparency and improve customer experience.

[0137] The final pricing of the parking packages is determined entirely by real data from online experiments, completely avoiding the subjective decision-making biases of traditional pricing, making the pricing strategy more scientific and reliable.

[0138] In this application, decision-making based on comprehensive revenue indicators ensures that the final parking package price does not solely pursue maximum revenue, but also takes into account operational efficiency (turnover rate) and customer satisfaction (complaint rate), achieving the best balance between commercial value and user experience. Through an incremental release strategy, even when the final parking package price is rolled out to the full user base, the system still retains risk control capabilities, and can detect and roll back any issues at any gray-scale stage, ensuring a smooth and safe transition of the business from the experimental state to the stable operation state.

[0139] Specifically, it also includes: Monitor the actual business metrics after the final parking package price is implemented. These metrics include total transaction volume, parking space turnover rate, and customer complaint rate.

[0140] After the system fully implements the final parking package price, it continuously tracks the following three core business metrics: Gross Merchandise Volume (GMV): the total revenue generated after the full price adjustment; Parking Space Turnover Rate: the efficiency of parking space utilization after the full price adjustment; and Customer Complaint Rate.

[0141] This real-time data is collected directly from the production environment logs of the parking lot business system (order system, parking space management system, customer service work order system).

[0142] A model update command is triggered when the total transaction volume of goods decreases by more than the first preset threshold; a model update command is triggered when the parking space turnover rate decreases by more than the second preset threshold; and a model update command is triggered when the customer complaint rate exceeds the third preset threshold.

[0143] The system will compare the monitored indicators with preset thresholds in real time, and will automatically trigger a model update command as soon as any of the following conditions are met: When the decline in GMV exceeds a first preset threshold (e.g., 20%), it indicates that the current pricing strategy may be severely damaging revenue.

[0144] When the parking space turnover rate decreases by more than the second preset threshold (e.g., 15%), it indicates that the pricing strategy may lead to parking space idling and reduced resource utilization efficiency.

[0145] When the customer complaint rate exceeds the third preset threshold (e.g., 0.5%), it indicates that the pricing strategy has caused user dissatisfaction and requires immediate intervention.

[0146] All thresholds can be determined based on actual circumstances, ensuring the consistency of business rules.

[0147] Based on the triggered model update instruction, the demand forecasting model is retrained using the newly added business data; the price elasticity model is retrained using the newly added transaction data and price change data.

[0148] Here, once an update command is received, the system automatically starts the offline training pipeline.

[0149] Retraining demand forecasting models (such as LSTM): The training data can use newly added business data, namely all new parking space occupancy data, traffic flow data and corresponding multi-source features (time, weather, events, etc.) from the last training deadline to the current time.

[0150] The goal is to enable the model to learn the latest market demand patterns and trends, and correct for "model drift anomalies" caused by changes in data distribution (data drift).

[0151] Retraining of price elasticity models (such as XGBoost): Training data can use newly added transaction data and price change data, that is, all price-demand correspondence data generated by this full price adjustment and any small-scale experiments that may be conducted in between.

[0152] The aim is to recalibrate users' price sensitivity and ensure the accuracy of the price elasticity prediction vector so that it can reflect users' real behavior in the current market environment.

[0153] The mechanism of this application enables the system to proactively perceive the negative impact of changes in the external market environment or its own strategic errors, and automatically initiate the correction process, so that the model always remains in the best state and has strong environmental adaptability.

[0154] This application sets a safety red line for business operations by establishing hard thresholds directly linked to core KPIs (such as a 20% drop in GMV). Once triggered, the system can automatically roll back strategies and initiate model optimization without waiting for manual analysis and decision-making, thus shortening fault response time.

[0155] Furthermore, it also includes: First, extract the original data fields when the abnormal scenario occurs. The original data fields include time features, weather data, event data, price data, and traffic flow data.

[0156] This process is automatically triggered when the system detects an "abnormal scenario" during business operations.

[0157] The system performs automatic offline training daily, updating feature importance. The policy library is manually reviewed every 7 days, and anomalous cases are accumulated as new features. The definition and identification of anomalous scenarios are shown in Table 2 below. Table 2:

[0158] These abnormal scenarios include: Business rules are triggered if, during the price experiment, the complaint rate is greater than 0.5%, GMV decreases by more than 20%, or turnover rate decreases by more than 15%; or if "abnormal pricing gap" or "abnormal supply shortage" occurs during daily operations.

[0159] Data consistency trigger: "Model drift anomaly" such as a deviation of >30% between predicted demand and actual demand (for 4 consecutive time periods).

[0160] User feedback triggers: such as "perceived abnormality" in online customer service work orders with ≥3 "price question" or "mischarge" tags per hour.

[0161] The system will automatically capture all raw data from the abnormal period and the related periods before and after it, and package them into a data snapshot.

[0162] These fields include: Time features: day of the week, hour, whether it is a holiday (from the data layer). Weather data: weather conditions (from external features). Event data: whether there are large-scale events in the vicinity, traffic control (from external features). Price data: pricing strategies that take effect at abnormal times, candidate prices (from the experiment and execution layers). Traffic flow data: actual parking space occupancy rate, gate entry and exit flow, predicted demand (from the data layer and model layer).

[0163] Then, a preset number of key features are selected from the original data fields using a feature importance analysis algorithm.

[0164] The system combines data snapshots from abnormal periods (as negative samples) with a large amount of data from normal periods (as positive samples) into a temporary dataset.

[0165] Training this dataset using a model like LightGBM, which has built-in feature importance evaluation capabilities, allows for the initial screening of which fields contribute most to distinguishing between "normal" and "abnormal" based on their "feature importance gain" metric.

[0166] To further ensure business interpretability, the system will simultaneously run SHAP (SHapley AdditiveexPlanations) analysis scripts. SHAP values ​​can quantify the specific contribution and direction (positive or negative correlation) of each feature to each anomaly prediction.

[0167] Based on the importance ranking of LightGBM and the SHAP analysis results, the system automatically selects the Top-K (such as the top 5 or top 10) key features.

[0168] Finally, the selected key features are written into a feature repository for subsequent model training and optimization.

[0169] Here, the system automatically generates new feature combinations or labels based on the selected Top-K key features. For example, if "severe weather" and "large-scale event" are both key factors, the system may generate a new boolean feature named is_bad_weather_with_event.

[0170] These new feature names and their computational logic have been officially written into the feature repository, becoming part of the official feature set.

[0171] In subsequent daily automatic offline training, the demand forecasting model (LSTM) and the price elasticity model (XGBoost) will incorporate these new features into the input range, thereby learning the patterns under abnormal scenarios and improving the robustness and prediction accuracy of the model.

[0172] The system generates a Top-K feature list weekly, which undergoes approximately 5 minutes of manual review at the strategy meeting. Once experts confirm its business interpretability, it can be officially launched. This ensures a combination of automated processes and human experience.

[0173] Treatment of abnormal feature precipitation: 1) Automated Feature Engineering The system automatically packages the original fields (time, weather, event, price, traffic) of abnormal periods into vectors; and uses LightGBM's built-in "feature importance gain" + "SHAP zero-code script" to select the Top-K fields; Generate new feature names (such as is_price_gap_empty, weather_event_interaction) and write them to the feature repository.

[0174] 2) Manual review The weekly strategy meeting only requires a 5-minute human review of the Top-K features; once the business interpretability is confirmed, the product can be launched.

[0175] This application collects real-time data on parking space occupancy, package sales, customer profiles, and external events. It utilizes an LSTM / XGBoost hybrid model to predict demand and price elasticity, and conducts small-scale online experiments within the Multi-Armed Bandit framework, ultimately achieving minute-level price adjustments and closed-loop optimization. Compared to traditional manual pricing, this application increases revenue while reducing customer complaint rates, making it suitable for parking lots in various scenarios such as commercial complexes, office buildings, and hospitals.

[0176] This application proposes a four-stage framework: "data-model-experiment-closed loop". Data layer: integrates real-time parking space occupancy, package sales, multi-dimensional customer profiles, and external events (weather, holidays, large-scale events).

[0177] Model layer: A hybrid architecture of ensemble learning (XGBoost / LightGBM / NGboost) + deep learning (LSTM / DNN) is adopted to predict the demand elasticity and revenue curves for each period in the next 1-24 hours.

[0178] Experimental layer: Based on the Multi-Armed Bandit algorithm, conduct small-volume online pricing experiments to achieve "learning while earning money".

[0179] Closed-loop layer: Using GMV, turnover rate, and customer satisfaction as KPIs, it automatically triggers model retraining and strategy updates.

[0180] In one optional embodiment of this application, an underground parking lot of a CBD commercial complex is taken as an example: Training sample: 1.2 million orders from the past 90 days + 2,000 external features related to weather / events; Model performance: 24-hour demand forecast MAPE = 6.8%, price elasticity AUC = 0.82; Experimental results: After 4 weeks of dynamic pricing, GMV increased by 15.3%, parking space turnover rate increased by 22%, and the complaint rate was 0.9%.

[0181] Ideally, a scenario-differentiation strategy should be implemented first.

[0182] This application can be quickly reused and adaptively fine-tuned in the following three typical scenarios (where the categorized scenarios are manually uploaded and maintained as system configuration files): a) Hospital parking lot A new "Estimated Visit Duration" feature has been added: It combines the registered department and appointment time to predict peak parking demand. The "tiered price cap + discount coupon" model is set up: patients with a consultation time of ≥4 hours will automatically trigger the price cap and receive discount coupons to reduce complaints.

[0183] b) Airport / High-speed rail P+R hubs By incorporating external features such as "flight / train timetables", we can predict arriving traffic flow 6 hours in advance. The price of the "long-term parking package" is dynamically adjusted to achieve "low-price customer acquisition at distant locations and high-price customer retention at nearby locations".

[0184] c) Community shared parking spaces at night A dedicated LSTM sub-model was trained using the residents' travel patterns (leaving at 8:00 PM and returning at 7:00 AM). The "Owner Profit Sharing" interface displays real-time changes in profits resulting from price adjustments, thereby increasing participation rates.

[0185] Secondly, implement lightweight edge deployment.

[0186] Hardware: An edge box with an ARM Cortex-A72 quad-core processor and 4 GB of RAM; Model compression: The 23 MB XGBoost+LSTM fusion model was compressed to 3.8 MB using Knowledge Distillation, with an inference latency of <30 ms after INT8 quantization; Offline caching: When the network is interrupted, the most recent policy is continued to be executed using a local 7-day rolling cache, and the logs are automatically transmitted back after the network is restored.

[0187] Then, enhance privacy compliance.

[0188] The customer's license plate number is hashed using MD5+Salt and then entered into the model; the original plaintext is stored only in the local encrypted partition. Training data is uploaded daily in a differentially encrypted manner, in accordance with the principle of minimum sufficiency under the Personal Information Protection Law.

[0189] Finally, API and ecosystem openness.

[0190] It provides RESTful & MQTT dual protocol interfaces, supporting third-party navigation and charging operators to call real-time prices.

[0191] SDK / API security mechanisms: 1) Authentication includes: HTTPS + TLS 1.3 mandatory; mutual authentication: client certificate + server certificate; supports OAuth 2.0 / JWT (expiring 1 hour, automatically refreshed).

[0192] 2) Call frequency limit, default: 50 QPS per IP; enterprise packages can be increased to 1000 QPS; exceeding this limit will return a 429 + Retry-After header.

[0193] 3) To prevent replay attacks, each request carries an 8-byte nonce, and the server caches it for 5 minutes; the timestamp window is ±60 seconds, and requests are rejected if the timeout period expires.

[0194] 4) Encryption and integrity: Transmission: AES-256-GCM; Optional: Payload is further encrypted using ChaCha20-Poly1305; Response body includes SHA-256 checksum for client verification.

[0195] All of the above mechanisms are implemented uniformly at the gateway layer, and can be used out of the box without additional coding.

[0196] Through the aforementioned differentiated strategies, edge deployment, privacy compliance, and open ecosystem, this application can be rapidly deployed in diverse scenarios such as hospitals, airports, and communities while maintaining high precision and robustness.

[0197] The technical solutions provided in this application, through the aforementioned technical closed loop, bring significant technical effects, including but not limited to: It improves the automation and real-time performance of data processing and decision-making: shortening the pricing decision-making cycle from the weekly / monthly level of manual processing to the minute / hour level of system automation.

[0198] The system's adaptability and robustness to dynamic and complex environments have been enhanced: through continuous model learning and closed-loop feedback, the pricing system can automatically adapt to changes in external conditions such as holidays and sudden weather changes.

[0199] Improved the utilization efficiency of resources (computing resources and traffic resources): Through a low-traffic, intelligent exploration experimental mechanism, reliable strategy verification results were obtained with minimal trial and error costs.

[0200] Improved accuracy and reliability of prediction models: By integrating multi-source data and continuously mining and retraining anomalies, demand forecasting and price elasticity forecasting are made closer to real-world patterns.

[0201] The parking pricing method, apparatus, electronic device, and storage medium provided in this application include: acquiring multi-source data related to parking space usage over a preset past time period; inputting the multi-source data into a demand forecasting model to predict a parking space demand forecast vector over a preset future time period; inputting data including price changes and demand changes into a price elasticity model to obtain a price elasticity forecast vector over the preset future time period; generating multiple candidate prices based on the parking space demand forecast vector and the price elasticity forecast vector; conducting online price experiments with the multiple candidate prices at a flow rate not exceeding a preset proportion; and determining the final parking package price based on the feedback results of the online price experiments. This application automatically determines the final parking package price based on the feedback results, avoiding human decision-making bias and reducing customer complaint rates.

[0202] Based on the same inventive concept, this application also provides a parking pricing device corresponding to the parking pricing method. Since the principle of the device in this application is similar to the parking pricing method described above in this application, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0203] Please see Figure 4 , Figure 4 This is a schematic diagram of the parking pricing device provided in an embodiment of this application. Figure 4 As shown, the parking pricing device 400 includes: The multi-source data acquisition module 401 is used to acquire multi-source data related to parking space usage within a preset time period in the past. The parking space demand prediction vector prediction module 402 is used to input the multi-source data into the demand prediction model and predict the parking space demand prediction vector within a preset time period in the future. The price elasticity prediction vector acquisition module 403 is used to input data including price changes and demand changes into the price elasticity model to obtain the price elasticity prediction vector for a future preset time period. The candidate price generation module 404 is used to generate multiple candidate prices based on the parking space demand prediction vector and the price elasticity prediction vector. The online price experiment module 405 is used to conduct an online price experiment on the multiple candidate prices with a flow rate not exceeding a preset ratio. The final parking package price determination module 406 is used to determine the final parking package price based on the feedback results of the online price experiment.

[0204] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of the electronic device provided in an embodiment of this application. Figure 5As shown, the electronic device 500 includes a processor 510, a memory 520, and a bus 530.

[0205] The memory 520 stores machine-readable instructions executable by the processor 510. When the electronic device 500 is running, the processor 510 and the memory 520 communicate via the bus 530. When the machine-readable instructions are executed by the processor 510, they can perform the operations described above. Figure 1 The specific implementation of the parking lot pricing method in the illustrated method embodiment can be found in the method embodiment, and will not be repeated here.

[0206] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can perform the above-described actions. Figure 1 The specific implementation of the parking lot pricing method in the illustrated method embodiment can be found in the method embodiment, and will not be repeated here.

[0207] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0208] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the shown or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0209] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0210] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0211] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, 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.

[0212] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The scope of protection of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A parking lot pricing method, characterized in that, include: Acquire multi-source data related to parking space usage within a preset time period in the past; The multi-source data is input into the demand prediction model to predict the parking space demand vector within a preset time period in the future. By inputting data containing price changes and demand changes into the price elasticity model, a price elasticity prediction vector for a future preset time period is obtained. Based on the parking space demand prediction vector and the price elasticity prediction vector, multiple candidate prices are generated; The multiple candidate prices are used to conduct online price experiments with a flow rate not exceeding a preset ratio; The final parking package price is determined based on the feedback from the online pricing experiment.

2. The method according to claim 1, characterized in that, Candidate prices are determined in the following ways: Calculate the estimated revenue based on the parking space demand forecast vector and the price elasticity forecast vector under different price changes; With the goal of maximizing the overall return index, the corresponding price change range is searched and selected through an optimization algorithm, and the candidate price is determined based on the selected price change range.

3. The method according to claim 2, characterized in that, The step of conducting an online price experiment with the multiple candidate prices using a traffic volume not exceeding a preset ratio includes: Within the framework of the multi-armed gambling machine algorithm, each candidate price is used as an arm for experimentation; Based on the cumulative number of times each candidate price arm has been selected and the volatility of its cumulative returns, the experimental strategy is automatically switched, including the following steps: When the first preset condition is met, the first strategy is adopted to conduct the experiment, and the candidate price arm is randomly selected with a preset exploration probability and the candidate price arm with the best current return is selected with a complementary probability. When the second preset condition is met, switch to the second strategy to conduct the experiment. Calculate the upper confidence bound based on the average return and uncertainty of each candidate price arm, and select the candidate price arm with the largest upper confidence bound. When the third preset condition is met, switch to the third strategy to conduct the experiment. Probability sampling is performed based on the posterior distribution of the returns of each candidate price arm, and candidate price arms are selected based on the sampling results.

4. The method according to claim 3, characterized in that, The first preset condition includes that the cumulative number of times any candidate price arm is selected is less than a first number threshold, and the first preset condition also includes that the standard deviation of the cumulative return is higher than a first volatility threshold; the second preset condition includes that the cumulative number of times all candidate price arms are selected reaches or exceeds the first number threshold, and the standard deviation of the cumulative return is lower than or equal to the first volatility threshold; the third preset condition includes that the cumulative number of times all candidate price arms are selected reaches or exceeds a second number threshold, and the standard deviation of the cumulative return is lower than or equal to a second volatility threshold within multiple consecutive preset time windows.

5. The method according to claim 4, characterized in that, The method further includes: When the standard deviation of the cumulative return is detected to exceed the first volatility threshold continuously during the second or third strategy phase, the experiment will automatically revert to the first strategy and restart. Furthermore, during the experiment, if the customer complaint rate exceeds the preset complaint rate threshold, the experiment will be terminated immediately and the price will be rolled back to the price before the experiment.

6. The method according to claim 3, characterized in that, The final parking package price will be determined in the following ways: Based on the feedback results of the online pricing experiment, data on the actual revenue, parking space turnover rate, and customer complaint rate of each candidate price under the experimental traffic were collected. Based on the collected data, the overall return index for each candidate price was recalculated. The candidate price with the highest overall benefit index will be selected as the final parking package price.

7. The method according to any one of claims 1-6, characterized in that, The method further includes: Monitor the actual business metrics after the final parking package price is implemented, including total transaction amount, parking space turnover rate, and customer complaint rate; When the decrease in the total transaction amount of the commodity exceeds a first preset threshold, a model update instruction is triggered; When the decrease in the parking space turnover rate exceeds the second preset threshold, a model update command is triggered; When the customer complaint rate exceeds a third preset threshold, a model update instruction is triggered; Based on the triggered model update instruction, the demand prediction model is retrained using the newly added business data; The price elasticity model was retrained using the newly added transaction data and price change data.

8. The method according to claim 7, characterized in that, The method further includes: Extract the original data fields when the abnormal scenario occurs. The original data fields include time features, weather data, event data, price data, and traffic flow data. A preset number of key features are selected from the original data fields using a feature importance analysis algorithm; The selected key features are written into a feature repository for subsequent model training and optimization.

9. A parking lot pricing device, characterized in that, include: The multi-source data acquisition module is used to acquire multi-source data related to parking space usage over a preset time period in the past; The parking space demand prediction vector prediction module is used to input the multi-source data into the demand prediction model and predict the parking space demand prediction vector within a preset time period in the future. The price elasticity forecast vector acquisition module is used to input data including price changes and demand changes into the price elasticity model to obtain the price elasticity forecast vector for a future preset time period. The candidate price generation module is used to generate multiple candidate prices based on the parking space demand prediction vector and the price elasticity prediction vector. The online price experiment module is used to conduct online price experiments on the multiple candidate prices with a flow rate not exceeding a preset proportion. The final parking package price determination module is used to determine the final parking package price based on the feedback results of the online price experiment.

10. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is in operation, the processor communicates with the memory via the bus, and the processor executes the machine-readable instructions to perform the steps of the method as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the method as described in any one of claims 1 to 8.

Images