Model-Based Conflict Resolution for City and County Home Page Switching in 58App

Background

58App provides two home pages—city and county—with a transition selection page allowing users to switch by clicking entries (e.g., clicking "Beijing" opens the city home page, clicking "Daxing" opens the county home page).

In addition to manual selection, the app can trigger a location‑based popup that prompts users to switch to the home page matching their current location. The popup is controlled by server‑side feature switches, and only one home page can exist at a time, leading to potential conflicts when both city and county switches are enabled.

Initial Handling (Product Perspective)

Product managers manually analyze possible popup scenarios.

They manually assess conflicts between scenarios.

Operations consider whether distributing different switch configurations will cause multiple popups.

Enabling a specific switch triggers the corresponding popup; disabling the switch temporarily blocks that scenario.

Initial Handling (Development Perspective)

Developers implement logic for each scenario identified by product managers.

Developers resolve conflicts identified in the product analysis.

Each scenario has its own switch, logic, popup, and copy.

Developers continuously address QA‑reported popup conflicts because product managers could not foresee all overlapping scenarios.

Model Design and Output

To systematically enumerate all city‑county switching scenarios and their conflicts, the author proposes a model based on object‑oriented thinking:

Represent city and county as variables X and Y.

Define exchange (switch) relations such as X→X', X→Y, Y→Y', Y→X.

Incorporate the hierarchical relationship (city is parent, county is child) by using XY to denote a county belonging to a city.

List all possible exchange items and identify those that contain or intersect each other; intersecting items indicate a conflict.

Derive a switch‑configuration protocol based on the conflict analysis.

Key exchange items include:

X→X' (city to another city)

X→XY (city to a county within the same city)

X→X'Y (city to a county in a different city)

XY→XY' (county to another county in the same city)

XY→X'Y' (county to a county in a different city)

XY→X (county to its parent city)

XY→X'Y (county to a county in a different city)

The analysis shows that among the seven exchange items, three are mutually conflicting, leaving at most four non‑conflicting scenarios that can be active simultaneously.

Switch Configuration Protocol

Using the model, the server can issue feature switches on demand rather than broadcasting all seven scenarios. When a conflict arises, the algorithm flags and eliminates the conflicting switches, ensuring that no more than four switches are active at once.

On the client side, popup logic is simplified to only compare the selected home page with the current location. If a relevant switch is enabled, a templated popup is shown (e.g., "You are viewing X city (county), switch to Y city (county)?").

Summary

The model produces a comprehensive scenario table for city‑county switching and identifies conflict items.

Applying the model‑driven switch protocol enables accurate, conflict‑free control of popup guidance.

The approach reduces manual analysis errors, lowers client‑side maintenance cost, and can be generalized to any hierarchical exchange logic.