What a Fitness Social App Changed When It Realised Precise Location Was the Wrong Trust Decision

The fitness social app had a sensible idea at its core: find people nearby who want to run or cycle at the same time as you, and connect them. Location was the whole point. Without knowing where someone was, the product had nothing to offer. So the team built a map, placed users on it, and let people see who was around. It seemed logical. It also quietly destroyed the trust of a large part of the user base before they ever had a chance to form a connection.

The map worked fine. The problem was a design decision made earlier than anyone had noticed, at the moment the product asked for something users were not yet ready to give.

We worked on this product through a period of significant redesign, and what we found was not a technical failure. The underlying map worked fine. The problem was a design decision made earlier than anyone had noticed, at the exact moment the product asked users to do something they were not yet ready to do. Location-sharing drop-off was the symptom. Premature disclosure of personal data was the cause.

What followed was a set of changes that touched the product's core flow, its trust architecture, and the sequence in which it asked people to act. The conversion rate from sign-up to actually meeting another user went from around 20% to 60-70%. That shift came from a single structural change to how and when the product asked for location data.

The Original Product: A Map That Showed You Who Was Nearby

The original product placed users as pins on a map in real time. The idea was social fitness discovery: if you could see that someone was 400 metres away and also wanted to run at 7am, you could reach out and go together. The core product loop depended on knowing where people were. That dependency shaped every design decision, including the decision to surface precise location data early and openly.

From a product logic standpoint, this made sense. Proximity was the value. Without it, the match was meaningless. If someone was in another part of the city, knowing their preferred pace and favourite routes was not useful. So the team built the location layer in first, assuming users would understand the necessity and accept it.

What they had not fully accounted for was the gap between product logic and human psychology. The product understood why location mattered. The user, arriving at the app for the first time, had no particular reason to trust it or the strangers on its map. The decision to share precise location with unknown people was not one most users were ready to make after a few minutes of browsing.

What the Drop-Off Data Was Actually Saying

The analytics showed a clear pattern. Users were signing up and exploring the map, but a large proportion were dropping off at a specific moment: the point where the app asked them to share their precise location with a potential match. The funnel was leaking in one place, and that place was the highest-trust action in the entire product.

A drop-off at a single point in a product flow is almost always a signal that the product is asking for something the user does not feel ready to give. The question is not why users refused, but why the product was asking at that moment. On this fitness social network, we found that users were being asked to share their location before they had had any opportunity to converse with or learn about the other person.

That sequencing problem was the actual issue. The data showed a leaky funnel. What it was really communicating was a trust gap: the product was moving faster than users were willing to follow. Fixing the rate meant fixing the sequence, not the map.

Why Female Users Were Disproportionately Affected

Our research into the user base showed a high proportion of female users, which changed the security calculus of the product significantly. Precise real-time location data shared with strangers carries a different weight for different people, and for women using a social fitness app, that weight was considerable.

The concern was not abstract. Knowing exactly where someone is, in real time, is a level of access that has real personal safety implications. For a woman arranging to meet an unknown person for an early morning run, having her precise location visible to that person before any conversation had taken place was a barrier that felt, to her, like a reasonable one. The product was treating location as a neutral data point. Many users were experiencing it as a safety risk.

Precise location felt like a neutral data point to the product team. To many female users, it felt like a genuine safety risk.

This is the kind of gap that analytics alone does not close. The drop-off numbers told us something was wrong. Understanding why it was disproportionately affecting female users required looking at who the product was actually serving and what those specific people needed to feel safe enough to engage. Security had to become a design priority, not a legal footnote.

The Psychology of Premature Disclosure

Trust between people does not appear all at once. It builds through a sequence of smaller interactions, each one establishing enough confidence to make the next step feel reasonable. In a face-to-face context, nobody meets a stranger and immediately tells them where they live. A conversation happens first. A sense of the person's character develops. Then, if things feel right, more is shared.

Products that ask for high-trust disclosures before this sequence has had a chance to develop are working against the grain of how people actually operate. The fitness app was asking users to share precise real-time location before they had exchanged a single message with another person. That is the equivalent of a stranger on the street asking for your home address before saying hello.

According to research by Boutet and Morel, 2025, 57% of participants were surprised by the extent of information that could be inferred from their location data, which suggests that users frequently underestimate how much they are giving away when they share it. The product was not just asking early. It was asking for something users did not fully understand the implications of, which made the trust gap wider still.

Map the trust-build sequence in your product before setting permissions. If a high-stakes disclosure is required at step two, ask what trust-establishing interactions could reasonably sit between step one and that moment.

The Fix: Approximate Proximity and Randomised Offsets

We redesigned the location feature so that the app no longer showed a user's precise position on the map. Instead, it displayed an approximate area, a fuzzy zone rather than a precise pin, with a randomised offset applied so the exact coordinates were never visible. A potential match could see that someone was nearby, within a broad radius, but could not pinpoint where they were.

This is what the change looked like in practice, comparing the original and redesigned approaches.

The core product value was preserved. A user could still see that a potential running partner was in their general area, close enough to make a meetup practical. By displaying only the vague area someone was in, the app gave enough data to judge whether a connection was feasible without allowing anyone to pinpoint exactly where another person was. The decision about whether to share a precise location was returned to the user, as an explicit opt-in step, at a point when they had more information to base it on.

Sequencing Conversation Before Location

Alongside the approximate proximity change, we restructured the flow so that users could view a potential match's profile and message them through the app's built-in chat before location was ever disclosed precisely. The sequence became: see that someone is nearby, review their profile, start a conversation, then decide whether to share exact location and arrange a meetup.

This mirrors how trust actually develops between people. Each step gives the user something to base a judgment on. After reading a profile, they know more. After exchanging a few messages, they know more still. By the time the question of sharing a precise location arises, the user has had the chance to form a view about the other person, and the decision feels less like a leap into the unknown.

As Simon Lee noted during the redesign process: "It enabled you to see their profile, have a conversation over the inbuilt messaging and then once you decided that you were happy and confident enough to share, then you could say okay, let's meet up." That ordering respects the user's pace. It does not eliminate the location-sharing step. It just positions it where it belongs, at the end of a trust-building sequence, not the beginning.

Look at every permission request in your product and ask what the user knows about the product and about other users at the moment you ask. If the answer is "very little", move that request further along the flow.

What the Numbers Looked Like After: 20% to 60-70%

Before the redesign, we were seeing around a 20% conversion rate from sign-up to users actually meeting another person through the app. That figure reflects how many people made it through the full intended product loop: sign up, find a match, converse, share location, arrange a meetup. Four in five users were dropping out somewhere along that path, and the data showed the biggest single leak was at the location-sharing step.

After introducing approximate proximity, randomised offsets, and the sequenced conversation flow, that figure rose to around 60-70%. The change represents a roughly threefold improvement from a set of adjustments that involved no new features, no new technical infrastructure, and no change to the fundamental product proposition. The map was still there. Location was still the mechanism. What changed was the order of events and the granularity of what was shown when.

A jump of that scale from a flow restructure, rather than a new feature, is worth paying attention to. The product had not been missing a capability. It had been sequencing the capabilities it already had in the wrong order, at a cost of roughly half its potential user base completing the core loop.

Asking Permission Rather Than Demanding Access

The redesign also changed the language around location requests. The original flow told users what they needed to provide. The new flow asked. The distinction sounds small and is not. Phrasing a data request as a question rather than an instruction shifts the user's psychological relationship with the product. They are no longer being processed. They are being consulted.

Asking "is it okay if we share your location once you're ready to meet up?" produces a different response than a prompt that simply says "share your location." Both arrive at the same technical outcome if the user agrees. But the framing of the first makes the user feel they have control, and people who feel in control of a product engage with it more and stay with it longer.

This is a tone-of-voice and framing change, not a technical one. The permission system underneath does not change. What changes is whether the user experiences the product as something happening to them or something they are choosing. That difference in experience, at the moment of a high-trust request, is large enough to move the numbers measurably.

Review the language on every permission and data request in your product. Rewrite each one as a question. "Is it okay if we..." or "Can we connect your..." creates a sense of control that a flat instruction cannot.

Where the Same Pattern Appears in Other Products

The fitness app is a clear example, but the underlying pattern appears wherever a product asks for high-trust information before the user has any basis for trusting it. The sequence problem is the same whether the product is asking for location, payment details, health data, or contact book access.

Health apps are a common place to see it. A wellness or supplements app that opens with a diagnostic questionnaire is asking users to disclose personal health information to a product they encountered 90 seconds ago. Headspace is a useful contrast: its opening screen removes both the sign-up gate and the diagnostic prompt, asking nothing of the user upfront and building confidence through the experience itself before asking for anything meaningful in return.

The pattern also appears in travel and hospitality products that ask for payment details or passport information early in the flow, before users have had any meaningful engagement with the brand. And in beauty and skincare apps that ask for skin condition data at first launch, before a user has any sense of how the product will use that information. In each case, the ask comes before the trust exists to support it. The result is the same one the fitness app saw: drop-off at the moment of highest disclosure.

What Any Product Team Can Take From This

The fitness app story produces a clear set of principles that apply to any product asking users for sensitive data, and the steps below reflect the sequence we worked through on that project.

1. Identify the highest-trust action in your product flow and map exactly when you are asking for it.
2. Ask what trust-establishing interactions sit before that moment. If the answer is "none", the sequencing needs work.
3. Explore whether the information you are asking for can be offered at a lower granularity initially, with full disclosure becoming an opt-in at a later point.
4. Change every permission request from an instruction to a question, and check that the language around it gives users a genuine sense of choice.
5. Segment your drop-off data by user group. A problem that affects one demographic more than another is almost always a trust or safety signal, not a usability one.

The changes the fitness app made were not cosmetic. Restructuring the flow and adjusting the granularity of location data required product and engineering decisions. But none of those decisions involved adding new features or capabilities. The product already had everything it needed. The work was in reordering and reframing what was already there.

Conclusion

What the fitness social app discovered was that a product can be technically sound and behaviourally broken at the same time. The map worked. The matching logic worked. The messaging system worked. What did not work was the moment the product chose to ask for something users were not ready to give, and the way it asked for it.

Moving from 20% to 60-70% conversion was not the result of a new feature. It was the result of understanding that location is not a neutral data point for everyone who uses a social product, that trust builds in a sequence, and that the job of design is to match product flow to that sequence rather than override it in favour of technical convenience.

The same question applies to any product that handles sensitive data. At the moment you ask users for something significant, what do they know about you? What have they had the chance to decide? Research from Boutet and Morel, 2025 found that 47% of participants intended to reduce app access to their location data after understanding what could be inferred from it. Users are not naive about privacy, but they are often asked to act before they have enough information to make a good decision. Designing the sequence so that disclosure comes after confidence is, as the numbers showed, both a trust strategy and a growth strategy.

If your product is losing users at a single point in the flow, the question worth asking is what you are asking for at that moment, and whether the user was ever given a reason to say yes. Let's talk about your product's trust architecture and where the sequence might need to change.

Frequently Asked Questions