How Gym Occupancy Data Privacy Actually Works

What a gym needs operationally is narrow: how many people are inside right now, which hours run busiest, how check-ins are distributed across the day. What it doesn’t need is any single member’s weight, body composition, or nutrition history. The boundary between those two data sets isn’t actually protected by a promise not to look — it’s protected by the gym’s account never being able to query that data in the first place.

What does a gym actually need, operationally?

A gym’s operational needs are specific and bounded: total occupancy at a given moment (say, 34 people), the peak-hour pattern across the day, the zone breakdown (free weights, cardio, functional training), and check-in counts. These are aggregate figures that help a gym plan capacity, schedule staff, and decide on equipment — none of them point back to one individual.

These numbers translate directly into operational decisions: if the peak-hour pattern shows a recurring spike between 6 and 8 p.m., the gym can staff up for those hours; if the zone breakdown shows the cardio floor consistently full while the free-weight area sits underused, the next equipment purchase can reflect that. None of those decisions require knowing who, specifically, was on any given machine.

What does a gym never need?

A member’s weight, body composition, meal logs, training performance, or sleep data belong to a completely different purpose — generating a personalized nutrition or training recommendation for that member. None of it has anything to do with a gym correctly counting who walked through its turnstile. Both data sets can exist in the same product without one flowing into the other.

Should that boundary be a policy, or an architecture?

Here’s the actual distinction: “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 never having read access to the health-data collection in the first place is a different kind of boundary — breaking it requires someone to deliberately grant a new permission. This is what data protection law calls data minimization: GDPR Article 5(1)(c) requires personal data to be “adequate, relevant and limited to what is necessary” for the purpose it’s 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 shouldn’t be reachable by default for a different one.

How does that separation actually get enforced?

The security-engineering term for this is the principle of least privilege — as NIST defines it, a system should be designed so each component is granted only the minimum access it needs to do its job. In practice, a gym-business account is scoped to read only its own aggregate occupancy and peak-hour figures; access to individual member data — or to another gym’s data — isn’t part of what that account type can request in the first place. That’s a different guarantee than hiding a tab in a dashboard: the restriction sits at the data layer, independent of whatever the interface happens to show.

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

In practice: a member scans a QR code, that check-in is logged with a timestamp, and the gym’s aggregate occupancy counter increments by one. What shows up on the gym’s dashboard is a total (say, 34 people) and an hour-by-hour distribution — never which specific member checked in, what they ate that day, or which direction their weight has moved. The same check-in can separately show up on the member’s own side, in a squad or a progress record — but that’s a completely separate data path.

Does this boundary extend to infrastructure providers too?

The gym account’s data boundary can’t just be an in-app rule — it has to hold at the level of whatever infrastructure actually stores the data. 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 can’t 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’s processing what stays answerable from a single page rather than 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
Check-in count	Yes — a gym-level total
A member’s weight or body composition	No — never
Meal or nutrition history	No — never
Squad or streak status	No — stays among squad members only

Frequently asked questions

Can a gym see which specific member checked in and when? The gym’s dashboard shows an aggregate number, not an individual name-and-time record. A check-in shows up on the member’s own account, and in their squad if they’re in one — on the gym’s side, it’s only ever a unit added to the overall count.

Is location data shared with the gym too? No. Location-based features, like nearby gym and coach ranking, are computed on the device itself; the coordinate is never sent to a server, so there’s no location data to share with a gym in the first place.

Could a gym ever request access to individual member data? Because the boundary is defined at the account-type level, a gym asking to see individual data would mean defining a new permission that doesn’t exist in the current architecture — the gym account type simply isn’t built for it. Full details are kept in the Privacy Policy.

The full technical rundown of how this separation is enforced is kept on the security page. Cookrange is currently at v0.9.6 internal alpha — join the waitlist for early access.