Pricing Strategy and Model Evolution for Second‑Hand Phone Auctions in ZhaiZhai TOB Marketplace

1 What It Is – Scene Characteristics

The article introduces ZhaiZhai's TOB (business‑to‑business) auction platform, focusing on the "dark auction" where bids are hidden from other participants to prevent price manipulation and maximize profit.

Each day the auction runs two sessions; items are listed with a starting price, buyers submit hidden bids, and the highest bid wins after the session ends.

2 What to Focus On – Core Metrics

The key metric is the starting price. An example shows that a too‑low start (e.g., ¥1) guarantees a sale but yields zero profit, while a too‑high start (e.g., ¥5000) rarely sells. An appropriate start (e.g., ¥950) balances transaction probability and profit.

Three indicators guide the design:

Transaction rate (sale proportion)

Gross profit (sale price minus recovery cost)

Premium (difference between final sale price and starting price)

3 How to Do It – Preliminary Evaluation

To decide a suitable starting price, we define functions:

Let sp be the starting price, dp the final deal price, cp the cost price, F(sp) a quality score, η(sp) the premium rate, and γ(sp) the transaction rate. The relationship is expressed as:

Key insights:

Higher transaction probability indicates a better starting price.

When the starting price approaches the final price, the premium rate approaches zero.

Optimizing F(sp) means maximizing transaction rate while minimizing premium.

Assuming an ideal deal price dp0 and cost cp , the profit function G(dp) and its relation to sp are derived, leading to the optimization goal of making sp as close as possible to the true deal price.

4 Learning from Practice – Early Experiments and Pain Points

4.1 Practice Based on Recovery Cost

Setting the start price directly from the recovery cost is simple but suffers from unstable cost data, lack of unified profit expectations, high manual effort, and sub‑optimal profit capture.

4.2 Practice Based on Price‑List Logic

Using a maintained price list per SKU and adjusting for condition yields more accurate pricing but still requires heavy manual upkeep and struggles with granularity and timeliness.

4.3 Practice Based on Deal‑Price Strategy

Leveraging historical deal prices provides timely, data‑driven starting prices. The system is modular, separating first‑time listings from re‑listings (flow‑down), and includes coefficient control and risk‑control modules.

4.3.1 First‑Time vs. Flow‑Down

First‑time items receive model‑generated prices; flow‑down items are discounted from previous prices.

4.3.2 SKU Deal‑Price Benchmark

For each SKU, an aggregated benchmark price is computed by scaling and weighting historical deals, smoothing out outliers.

4.3.3 Coefficient Adjustment Module

Three layers of coefficients adjust SKU‑level, condition‑level, and global factors, reducing manual effort from O(N_sku×N_level) to O(1) for global tuning.

4.3.4 Risk‑Control Module

Risk control filters abnormal prices and ensures coverage for sparse data by falling back to coarse‑grained averages.

Key outcomes of this approach include higher transaction rates, lower premium rates, clearer debugging, and improved human‑efficiency, though challenges remain in granularity, condition classification, and coefficient complexity.

# Threshold set
thres_value_set = [tv1, tv2, tv3, tv4, tv5]
# Historical deal prices
historical_deal_price_set = [dp1, dp2, dp3, ...]
# Historical offer prices
historical_offer_price_set = [op1, op2, op3, ...]

# Initial final price is model price
final_price = model_price

if historical_deal_nums > thres_value_set[0] and historical_offer_nums > thres_value_set[1]:
    if model_price < min(historical_deal_price_set) * thres_value_set[2] or model_price > max(historical_deal_price_set) * thres_value_set[3]:
        final_price = (np.average(historical_deal_price_set) + np.average(historical_offer_price_set)) / 2
elif historical_offer_nums > thres_value_set[1]:
    if model_price < min(historical_offer_price_set) * thres_value_set[2] or model_price > max(historical_offer_price_set) * thres_value_set[3]:
        final_price = max(model_price, np.average(historical_offer_price_set)) * thres_value_set[4]

5 Building the Current Model

5.1 Existing Model Framework

The new framework retains the overall modular flow but upgrades the first‑price module from SKU‑level to item‑level pricing.

5.2 Main Module Design

5.2.1 Pricing Module

Moves from SKU‑level to inspection‑item granularity, using decision‑tree regression (or other regressors) on features such as SKU, inspection scores, and historical offers.

Inspection items are encoded by mapping severity words (e.g., "severe", "light") to numeric scores and weighting items by importance.

5.2.2 Coefficient Adjustment Module

Only global and flow‑down coefficients remain, reducing tuning complexity to O(1).

5.2.3 Risk‑Control Module

Upper‑ and lower‑bound checks now use historical deal prices (high confidence) and buyer offers (medium confidence) rather than recovery cost.

Historical Deal Price

Buyer Offer

Cost Price

Coverage & Quantity

Low

Medium‑High

High

Confidence & Accuracy

High

High

Low

The code snippet above implements the threshold‑based price correction.

5.2.4 Coverage (Fallback) Logic

When fine‑grained data is missing, a linear regression on model‑averaged price per model‑capacity‑grade is used to extrapolate prices, ensuring full coverage while preventing grade inversion.

5.3 Effectiveness and Future Optimization Space

5.3.1 Model Performance

AB tests on Apple and Android phones show the new model reduces premium rates while maintaining or improving transaction rates, especially for lower‑value Android devices.

The dual‑side optimization (higher transaction rate, lower premium) expands profit margins.

5.3.2 Future Work

Reduce latency of human feedback in the control loop for fully automated adaptation.

Apply reinforcement learning to dynamically adjust flow‑down discount factors.

Enhance risk‑control for higher accuracy and coverage.

Continue modular refinement of the overall architecture.

6 Final Thoughts

The article walks through a practical pricing problem, defines metrics first, iterates through several algorithmic ideas, and arrives at a production‑ready, modular solution that balances transaction rate and premium. It serves as a case study of systematic, data‑driven algorithm design.

About the author

Chen Ye, senior algorithm engineer at ZhaiZhai, responsible for B‑side search, ranking, and pricing systems.