Precise and approximate location must be requested separately

What it is

Location permission comes in at least two grades: precise (meter-level coordinates) and approximate (city or neighborhood). The grades should be requested and granted separately. A single "Allow location" must not treat precise as the default. Allowing "use location to find nearby stores" is often consent to approximate; navigating to the door needs precise. This entry is only about precision as a separable grant. It is not about choosing one-shot versus ongoing authorization, and not about the stronger case required for background location—that is a different scope.

Why it happens

Coordinate precision decides how much of a life can be inferred: approximate supports "stores in this district"; precise supports "whether I am inside this shop, which street I take home." If the system offers one switch, apps read at the highest precision because it is easier to engineer. People consent at the lowest precision the task needs. When the grades are merged, someone who refuses precise also kills approximate, and nearby features die; or they allow precise without knowing it can be stepped down. Separate asks align risk with use: approximate first, precise as a later, refusable upgrade.

Studying it

Give the same "nearby" task three authorization structures: approximate only, precise only, and the two grades in sequence. Measure completion and later understanding.

Independent variables: whether the system exposes a precision switch, the default grade, whether stepping up to precise is a second dialog. Dependent variables: task completion, precision actually read, judgment of "does the app know my street," rate of turning location off entirely.

Simulated lab locations make approximate and precise look similar on a map; use real city-scale tasks (find a shop across districts versus find the entrance). Do not report a single location-allow rate—it collapses two grades into one number.

Where it stops holding

When the platform has no approximate grade (some older systems only grant precise), the app should downsample before upload and say "we only use district-level"; that is implementation reduction, not a system grant split. Emergency calling, or navigation already in motion as a precise task, gains nothing from offering a step-down to approximate. Indoor positioning and AR measuring that physically need meters should request precise and say why—do not pretend approximate is enough.

Applying it

• The first location request asks for approximate only. Bind precise to the action that truly needs meters (the last hundred meters of navigation, a store check-in) as its own dialog.
• Purpose copy must name which grade this ask wants. Do not let the word "location" cover both.
• If precise is already granted, Settings must offer a step-down to approximate without turning the whole permission off.
• Verify by enabling only approximate in system Settings and running "nearby list" versus "navigate to the entrance." The list should still work; navigation that needs precise should ask at that action, not blank the whole map. Check that the precision API actually requested matches the grade the UI claimed.

Related

• Within the group: H4.06.2 Approximate location is enough for most tasks · H4.06.3 Background location needs its own, stronger reason
• Adjacent: H4.07 One-time vs Ongoing Authorization · O1.02 Data Minimization · O2.01 Permission-Prompt Information Design
• Search terms: precise location · approximate location · location granularity