PortfolioPrice Range Filter Challenges
EC site price range filters seem simple but have several challenges:
- Management difficulty: Defining price ranges separately in filter UI and API processing causes inconsistencies
- Change impact: Modifying price ranges requires changes in multiple places
- Backward compatibility: Saved URLs stop working if URL format changes
Solution: Centralized Management (SSOT)
We adopted the SSOT (Single Source of Truth) approach. Price range definitions are consolidated in one file, and all processing references that file.
Example Price Range Definitions
Price ranges are set based on customer purchasing behavior:
| Range ID | Range | Display Label |
|---|---|---|
| range_1 | $0-$200 | Up to $200 |
| range_2 | $201-$400 | $201-$400 |
| range_3 | $401-$600 | $401-$600 |
| range_4 | $601-$800 | $601-$800 |
| range_5 | $801+ | $800+ |
Benefits of Centralized Management
1. Easy Changes
When you want to modify price ranges, just update one definition file. Filter UI, API processing, URL parameter parsing—everything automatically uses the new definitions.
2. No Inconsistencies
With definitions in only one place, issues like "selectable in UI but errors in API" don't occur.
3. Backward Compatibility
The system that auto-converts old URL formats (e.g., 0-200) to new formats (e.g., range_1) also references the definition file.
Processing Flow
Utility Functions
Price range processing is standardized so it can be used the same way everywhere:
- Get range from ID:
range_1→{ min: 0, max: 200 } - Convert old format:
0-200→range_1 - Check if price is in range:
$150is inrange_1
Summary
By centrally managing price range definitions, we achieved filter functionality that's easy to change and resistant to inconsistencies. Maintaining backward compatibility ensures saved URLs continue to work.