Three Phones, Three Prices: The Algorithmic Architecture and Compliance Boundaries of Dynamic Pricing Systems

The same room type at the same hotel, at the same moment, quoted three different prices on three phones: 298, 358, and 419, a price spread exceeding 40%. This is not an occasional glitch on an individual platform, but a real-world test case that pushed the issue of "big data price discrimination against returning customers" back onto trending searches in 2026. From a technical perspective, behind this is the result of a Dynamic Pricing System tuning parameters simultaneously across both the recommendation and pricing pipelines—it is not simply "identifying old users and raising prices," but an engineering system composed of feature engineering, real-time computation, and model iteration, whose complexity far exceeds outside imagination.

The Engineering Essence of Dynamic Pricing: Turning "Pricing" from Rules into Prediction

The pricing logic of traditional e-commerce is deterministic: cost price + fixed margin = selling price, and a product's price is static at the SKU dimension. A dynamic pricing system is completely different: it transforms "one price per product" into "one price per user," with the core being the use of predictive models to approximate each user's "Willingness to Pay" (WTP), and then inversely solving for a quote under the constraint of profit maximization.

To achieve this goal, the system needs to complete a full decision chain at the millisecond level. Data tracking collects the user's device model, App version, dwell time, browsing path, and historical order records on the front end; the feature platform processes these raw behaviors into computable vectors—whether the user is a member, order frequency over the past 90 days, price sensitivity, whether the device is a new device visiting for the first time, and so on are all key features determining the quote level. Taking "whether the device is visiting for the first time" as an example, it is essentially judging the user's "price comparison cost": new devices often correspond to users with stronger price comparison motives, and the system tends to offer more competitive prices to complete conversion.

Once a user request comes in, it simultaneously hits multiple strategies: real-time feature queries (Response Time is usually required to stay within 100ms), model inference (usually lightweight GBDT or wide-and-deep models, not large language models), and AB experiment traffic splitting. The quote is not given by a single model, but is the result of multiple layers stacked together: "crowd pricing model + posterior correction rules + business fallback price." This also explains why the price fluctuates when the same user refreshes the page several times—because the experiment group, cache version, and inventory level hit by each request may all differ.

Three Technical Links Easily Overlooked

The first link is real-time computation. Dynamic pricing has far higher requirements for "real-time" than ordinary recommendation systems. The decision window from search to order may be only a few minutes, and the price signal must complete collection, processing, and feedback within this window. Therefore, such systems generally use Flink or Spark Streaming for real-time feature aggregation, Redis or message queues for feature caching, and online inference clusters to handle high-concurrency inference requests. Any latency jitter in any link will directly manifest as the user experience of "prices jumping around."

The second link is the model's "self-proof of innocence." When determining whether price discrimination is constituted, regulators will require enterprises to prove that "quote differences come from reasonable cost differences rather than user profile discrimination." This requires the system, while predicting, to record the feature snapshot, model version number, and experiment group ID on which each quote is based—the so-called "pricing explainability audit." Without this audit chain, any complaint could leave the enterprise in the passive position of "the algorithm is a black box and cannot be used as evidence." After the 2022 "Provisions on the Administration of Algorithm Recommendations for Internet Information Services," algorithm filing and algorithm explainability have changed from "best practice" to "compliance necessity."

The third link is the ethical boundary of AB experiments. The optimization objective of dynamic pricing systems is usually "GMV maximization" or "gross margin maximization," but these two objectives produce completely different behaviors on specific groups—when pursuing gross margin maximization, the model naturally tends to quote high prices to old users who are insensitive to price. If no "price fairness" guardrail metric is set during experiment design, the algorithm will systematically slide toward "price discrimination against returning customers" without human intervention.

Beyond the Compliance Red Line, the Correct Engineering Posture

Dynamic pricing itself is a neutral technical tool, and the aviation, hotel, and ride-hailing industries have used it for decades. The problem lies in "the abuse of cross-platform user profiles"—when an e-commerce platform links the consumption capability tags you have accumulated in the WeChat ecosystem with its own App's device fingerprint, and then superimposes sensitive features such as real-time location and order time, the quote is alienated from "market pricing" into "individual pricing." This is also why the focus of regulation has never been to prohibit dynamic pricing, but to prohibit "using algorithms to implement unreasonable differential treatment of counterparties with the same transaction conditions in transaction terms."

For enterprises, a robust pricing system should have three built-in guardrails: first, the feature layer should perform "sensitive feature isolation," removing protected attributes such as gender, age, and permanent address, and using only consumption behavior and product attributes as the basis for pricing; second, the rule layer should set "price ceilings and same-price fallbacks" to prevent the model from quoting abnormal prices to a single user; third, the audit layer should implement "one-click export of quote explanations," so that every differentiated quote has a traceable basis. These three points are not opponents of the algorithm, but the guarantee that the algorithm can operate stably in the production environment over the long term.

Returning to the "three phones, three prices" at the beginning, what is truly worth being vigilant about is not the price difference itself, but the "unexplainable and untraceable" black-box decision behind the difference. When a system cannot answer "why this price is quoted to this user," it simultaneously loses the user's trust and the legitimacy of regulation. Technology itself is not the purpose; using technology to create real, sustainable business value is—and the premise of sustainability is precisely to let the algorithm, while creating profits, hold the engineering bottom line of explainability and fairness. This is exactly the proposition that every team doing e-commerce platform development and APP development cannot avoid in the process of big data analytics and enterprise digital transformation.