How Gym Occupancy Data Privacy Actually Works

Corrected — 28 August 2026. An audit of this article against the code found four claims wrong, and they were the load-bearing ones: it said a gym sees only aggregate figures and never an individual check-in, and that no location coordinate ever reaches a server. Both are false. A gym does see its own members’ individual check-ins, and GPS check-in does send a coordinate to a server function. The article’s own argument was that the test is what the data layer allows — so it is only fair to apply that test to the article. Rewritten around what the rules actually say. The corrected version is, if anything, a stronger claim, because it is one you can check.

What a gym needs operationally is narrower than what a gym is often given: who trained and when, how busy each hour runs, how many people are inside right now. What it never needs is any member’s weight, body composition, or nutrition history. The boundary between those two sets is not protected by a promise not to look. It is protected by the gym’s account having no way to read the second set at all.

What does a gym actually see?

Two things, and it is worth being exact because the vague version of this answer is how the previous draft of this article went wrong.

Its own members’ attendance. A gym reads its own member list and its own check-in records. Each check-in record carries the member’s display name, their photo, the timestamp, and how they checked in (QR, GPS, geofence). This is individual data, it is not aggregated, and the gym owner can read it. That is not an oversight — a gym that cannot tell whether a member came in this month cannot run a membership.

Its own aggregate figures. Current occupancy, the peak-hour pattern, check-in totals. These help plan capacity, schedule staff and decide on equipment: if the peak-hour curve spikes between 6 and 8 p.m., the gym can staff those hours.

Both are scoped to that gym. A gym cannot read another gym’s members or another gym’s check-ins.

What does a gym never see?

A member’s weight, body composition, meal logs, or nutrition history. Those exist for a different purpose — generating a personalised nutrition or training plan for that member — and nothing connects one purpose to the other. A member can separately turn on a tiered, default-off permission that shares a narrow derived summary with their gym or coach (check-in frequency, logging consistency, or the direction their weight is moving); each tier is turned on individually, raw data never travels that path, and it can be switched off at any time.

So the honest line is not “the gym sees nothing individual”. It is: the gym sees attendance, and only attendance, unless you decide otherwise.

Should that boundary be a policy, or an architecture?

Here is the distinction that still holds, and it is the reason this article exists. “We won’t look at that data” is an operational promise, and a promise can be broken by one misconfigured setting or one future decision made without full context. A gym account having no read path to the nutrition collection is a different kind of boundary: breaking it requires someone to deliberately write a new rule, in a file that is reviewed and version-controlled.

This is what data protection law calls data minimisation: GDPR Article 5(1)(c) requires personal data to be “adequate, relevant and limited to what is necessary” for the purpose it is processed for, and Turkey’s KVKK (Law No. 6698) sets out the equivalent requirement — enforced directly by the country’s data protection authority — that data stay “connected to, limited to, and proportionate to” its purpose. Both frameworks describe the same thing: data collected for one purpose should not be reachable by default for a different one.

How is the separation actually enforced?

The security-engineering term is the principle of least privilege — as NIST defines it, each component is granted only the minimum access it needs. In practice the rule for a gym’s check-in records grants a read to exactly two parties: the gym that owns the record, and the member the record is about. Nobody else, including another gym. The rule for a member’s nutrition data grants a read to the member alone, and no gym appears in it at any point.

That is a different guarantee from hiding a tab in a dashboard: the restriction sits in the data layer, independent of whatever any interface happens to show. It is also checkable, which is the part that matters — a claim about an interface is a claim about a screenshot, while a claim about a rule is a claim about a file.

What actually happens at the moment of a check-in?

A member scans the gym’s QR code. A check-in record is written with their name, photo, the timestamp and the method, readable by that gym and by that member. The gym’s occupancy counter increments. The same check-in separately appears on the member’s own side, in their streak and in their squad if they have one.

Checking in by GPS instead of QR involves one thing worth naming. Nearby gym and coach ranking is computed on the device and that coordinate never leaves the phone. GPS check-in is the exception: your coordinate goes to a server function whose whole job is to confirm you are actually at the gym, by recomputing the distance server-side rather than trusting the app. The coordinate itself is not stored — only the rounded distance is written to a server log. That is a deliberate trade: the alternative is trusting a client-supplied “I’m here”, which is not a check-in, it is an honour system.

Does the boundary extend to infrastructure providers too?

It has to, or it is not a boundary. Cookrange’s hosting and data store run on Vercel and Firebase (Google Cloud); the data-processing terms with those providers require that data only be processed for the purpose it was collected for — a provider cannot repurpose it for its own marketing or analytics. Which third party can access which category of data is kept in an updated sub-processors list, so the question of who processes what stays answerable from a single page rather than from a promise.

What a gym sees vs. what it never sees

Data	Does the gym see it?
Current total occupancy	Yes — an aggregate number
Peak-hour pattern	Yes — an aggregated, time-based curve
Its own members’ individual check-ins (name, photo, time, method)	Yes — attendance for its own members
Another gym’s members or check-ins	No — never
A member’s weight or body composition	No — unless the member turns on that sharing tier, and then only as a direction, never a figure
Meal or nutrition history	No — never, by any route
Your location coordinate	No — it is not shared with the gym at all
Squad or streak status	Not by default — your streak reaches a gym only if you grant tier 1

Frequently asked questions

Can a gym see which specific member checked in and when? Yes, for its own gym: a check-in is written into that gym’s records with the member’s display name and a timestamp, and the gym owner can read it. What a gym cannot read is anything beyond attendance — no nutrition history, no weight history — and it can never see another gym’s records.

Is location data shared with the gym? No. Nearby gym and coach ranking is computed on the device and that coordinate never leaves the phone. GPS check-in sends your coordinate to a server function that confirms you are at the gym; the coordinate is not stored, only the rounded distance, and it is not shared with the gym either way.

Could a gym ever get access to individual health data? Not by asking. A gym already reads its own attendance records; what it cannot reach is nutrition and weight data, and that line sits in the security rules rather than behind a hidden dashboard tab. Widening it would mean writing a new rule, not filing a support request. The one path that exists is the member’s own tiered sharing permission, which is off by default and reversible. Full details are in the Privacy Policy.

The full technical rundown of how this separation is enforced is kept on the security page. Cookrange is at v0.9.6, a pre-launch internal alpha; beta access opens when the time is right and the first invitations go to the waitlist.