Musinsa's Journey to Resolving Location Errors After Removing Tablets and Introducing GPS-Based Waiting
Key point
Resolved check-in failures caused by indoor GPS errors by customizing coordinates and radii per store.
Details
The Musinsa Store Commerce engineering team transitioned the offline store waiting service from an external solution to in-house development, introducing QR codes instead of tablets. During this process, GPS location data was used to verify whether customers had actually visited the store, but significant issues arose during field testing due to measurement errors in indoor environments and inaccuracies in geocoding coordinates.
Location Errors and Initial Response
Indoors, location measurement errors increased to tens of meters because Wi-Fi and base station information were used instead of satellite signals. In one store, a customer standing at the entrance was measured as being 29m away, or a 205m discrepancy was detected indoors, making check-in impossible. Additionally, issues emerged where address-based geocoding coordinates did not match the actual check-in location, or adjacent stores shared the same coordinates.
Initially, a temporary workaround was implemented by using feature flags in the frontend to override server coordinates. This allowed coordinate modifications without deployment, but created an operational burden where developers had to manage coordinates for all stores.
Introduction of Operator-Centric Customization
As a solution, check-in location and radius were changed to per-waiting configuration settings. Store operators could now directly register the coordinates of the actual check-in point, such as where the signboard is located, by selecting 'Current Location' on the admin screen. Furthermore, the check-in radius could be flexibly adjusted from 30m to 1km depending on the store environment, such as indoor depth or whether it was an outdoor pop-up.
In the frontend, the location verification logic was improved to re-verify whenever the reference value changed, and stale data handling using runId was applied to prevent issues with the order of asynchronous responses. This reduced dependency on developers and enabled accurate visit verification tailored to on-site conditions.
This summary was generated automatically by AI. Check the original for the author's claims and context. Copyright belongs to the original author.
Our guide explains how the AI works. Report summary errors, attribution issues, or removal requests via Contact.