Privacy policy

3.1 Account and sign-in

An account stores an email address and a password. The password is held solely as a cryptographic hash and cannot be read by us. Sign-in via Google or Apple is available as an alternative; in that case the email address and the identifier supplied by the respective provider are processed. With “Sign in with Apple”, the email address can be hidden behind Apple’s relay service.

Two-factor sign-in can be set up optionally; it is mandatory for accounts of the Wanderer team. For this, a secret key is stored from which an authenticator app on the person's own device generates changing six-digit codes; at sign-in, the code entered is checked against this key. We do not learn which authenticator app is used. The key is deleted when two-factor sign-in is turned off or the account is deleted.

The time of registration and the times of sign-ins are logged so that misuse of accounts can be traced.

3.2 Profile

The profile holds a first name, a last name, an optional self-description and an optional profile picture, plus the balance of hiking points earned from completed challenges. A profile can be set to “private” in the settings; content and connections are then visible only to approved followers. Gender can also be stated voluntarily; it is visible to nobody and is used solely for group hikes open to women only (3.22).

First name, last name and profile picture become visible to other users as soon as posts are published, comments are written or connections are formed. Profile pictures are held in a publicly addressable storage area: anyone who knows a picture’s address can retrieve it without signing in.

3.3 Location data

The app accesses the device’s location once this has been permitted at operating-system level. Permission can be withdrawn in the system settings at any time; the app remains usable with a reduced feature set.

Location is used for four purposes:

• Map display: the current position is shown on the map and used to find trails and huts nearby. This position data is processed on the device only and is not transmitted to our servers. On the approximate location determined by Mapbox’s map library, see 3.12.
• Emergency view: the current coordinates are displayed so that they can be passed on to rescue services in an emergency. There is no automatic transmission to emergency services or to us. On request, the app hands the coordinates together with a map link to the device’s messaging app as a prepared text; the recipient and the sending are decided by the user alone. The emergency view is also accessible without signing in.
• Hike recording: once a recording is started, the app continuously captures position, altitude and timestamp (see 3.4). If you navigate on a walk with a stored route, the app continuously compares these positions with the route in order to show your progress and alert you to a deviation. This comparison takes place solely on the device; the only thing stored with the hike is which walk it belongs to.
• Sharing your live location: only if it is expressly started during a recording, the app reports your position to our servers about every two minutes so that people with the link can see it (see 3.21).

Once started, a recording continues while the app is in the background or the screen is locked — otherwise the hike would be captured only in part. This applies solely for the duration of a recording: where the map is merely being viewed, location updates stop as soon as the app moves to the background. An ongoing recording is always identifiable — on iOS by the blue location indicator, on Android by a persistent system notification.

3.4 Recorded hikes

Recording and saving a hike creates a movement profile of the route covered. The following is stored: the route as a sequence of coordinates with altitude and timestamp, start and end time, duration, distance, ascent and descent, and average speed.

This data is linked to the account and serves the user’s own review. It is not published unless it is actively shared as a post. Individual recordings can be deleted in the app at any time and exported individually as GPX files. The file is created on the device and passed on via the share menu of the operating system; where it goes is decided solely by the user. Any service to which the file is passed on is subject to that service’s own privacy policy.

A recording is first secured on the device and only then transmitted to our servers. If there is no connection when it is saved, it stays on the device and is transmitted as soon as one is available again; until then it is marked in the app as not yet uploaded and can also be discarded there. The same applies to a recording in progress that was interrupted by the app being terminated: it is preserved on the device and can be resumed or finished the next time the app starts. This safeguarding takes place solely on the device.

When a recording is shared as a post, everyone who can see the post sees its date, start and end time, distance, duration, elevation gain, elevation profile and the route on a map. The times of the individual points and the average speed remain visible only to the account itself. Routes can allow conclusions to be drawn about where someone lives or spends time. Before sharing a recording in the community, bear in mind that its start and end points become visible to others.

3.5 Community content

Posts, uploaded images, comments and likes are stored with a timestamp and a link to the account, and are visible to other users. Recommendations and ratings for walks are covered separately in section 3.20 — they are reviewed before publication and are not visible until then. The same applies to the social graph: who is followed and who follows. For private profiles this information is limited to approved followers; the corresponding check is performed server-side.

Anyone publishing content decides on its scope. Publishing special categories of personal data — health data, for instance — is inadvisable. Images showing other identifiable people should only be uploaded with their agreement.

Published content can be deleted in the app. Copies or screenshots already made by third parties are beyond our control.

Your own posts can also be edited afterwards, both text and photos; the linked hike stays as it is. An edited post is marked “edited”, and the time of the last change is stored. We do not keep the earlier version; removed photos are deleted from storage immediately. If the post was reported, the text at the time of the report remains with the report (3.6).

3.6 Reports and blocking

Posts, comments, profiles, messages and group hikes (3.22) can be reported. A report stores the reporting account, the account concerned, the selected reason, any explanatory text, the time, and the state of processing. It also records the reported text as it stood at the time of the report, so that the review remains traceable even if the content has since been deleted; where the report concerns an image in a message, the reference to the reported image file is recorded in its place. The identity of the reporting person is not disclosed to the reported person.

Every report is delivered to the mailbox info@wanderer-app.cc and reviewed there; delivery is handled by Resend (see section 4). Depending on the outcome, content is hidden or removed and accounts are suspended. Where several people independently report the same post, comment or group hike, it is provisionally hidden automatically until the review is complete. The person who wrote it continues to see their own content; the decision on final removal is always taken by a human.

In addition, individual accounts can be blocked. Who blocked whom is stored together with the time — this is the only way to keep both sides’ content apart. A block takes effect in both directions; the blocked person is not notified. Any existing follower connections between the two accounts are deleted in the process; if the blocked person was taking part in a group hike of the blocking person, or vice versa, that participation ends (3.22).

3.7 Direct messages

Messages exchanged via the chat feature are stored on our servers with content, sender and timestamp so that they are available on all devices of those involved. A message may also contain an image. It is chosen from the gallery or taken with the camera, scaled down on the device before it is uploaded, and stored separately from the text. Unlike images in posts, these images are held in a non-public storage area: they can only be retrieved from a signed-in session of the accounts taking part in the conversation, not via a generally accessible address. Access is technically restricted to the participants of the conversation concerned. There is no end-to-end encryption: access by us would be technically possible, but occurs only for cause — for example following a report under 3.6, upon reasonable suspicion of criminal conduct, or by order of a public authority.

Every group hike (3.22) has a group chat for the person who posted it and those who were accepted. It works like a one-to-one conversation but does not accept images, can be written in until three days after the hike and is deleted together with the hike. Anyone who leaves the hike or is removed from it also leaves the group chat and no longer sees its messages. Messages from a blocked person (3.6) are not shown in the group either.

3.8 Challenges, hiking points, rewards and giveaways

Every account takes part in challenges automatically; there is no separate opt-in. How a completion is established depends on the type of challenge.

Challenges evaluated from existing data: Depending on the task, this draws on recorded hikes (distance, elevation gain, duration, number, date as well as the assigned trail and its region) or on the number of your own posts, comments, reactions and follow connections. None of this data is created for challenges — it is stored for the purposes set out elsewhere in this policy and is additionally used here for the evaluation. The evaluation runs on our servers and is recalculated on every display; no separate progress figure is kept permanently.

Photo challenges: Anyone completing a photo task uploads an image, which our team reviews and either confirms or rejects. We store the image, any comment added by the user, the time of submission, the processing status, the team member who reviewed it, the time of review and any reason given for a rejection. To help assess the submission, we additionally record whether the image was taken directly with the camera or chosen from the gallery, whether a hike was recorded on the same day and — where the location has been released — the distance to the challenge target in metres. The location coordinates themselves are not stored. Releasing the location is voluntary; a submission is possible without it. On request, the image can at the same time become a post in the feed — that post is independent of the review and is processed in accordance with section 3.5.

Challenges requiring a place: Where a hike is recorded, we compare its route with the challenge target on our servers. Alternatively, presence can be confirmed on site; the current position is transmitted to our server, compared with the target and not stored — only whether the target was reached is recorded.

Challenges with a code: We store the fact that the code was redeemed, not the code itself per person.

Hiking points: An account is kept for hiking points. Every credit and every debit is recorded with the amount, the reason, a reference to the relevant challenge or reward, and the time. This serves to make the points balance traceable — both for users, who can view the history in the app, and for us in the event of queries. Points are only credited once they are collected in the app. Where a badge is attached to a challenge, its award is recorded together with the time.

Redeeming a reward. Redeeming reduces the points balance by the cost of the reward and records the entry in the points account. In addition, a record of the redemption itself is created: which reward, at what cost, how it is handed over, the time and the processing status. The title and cost are recorded as they stood at the time of redemption. Where a voucher code is assigned from a pool or the code of a partner business is taken over, it is stored in the record; it is the proof of redemption and can be viewed in the app at any time. For a voucher shown on site, the time at which it was redeemed there is also recorded.

Delivery address. Only for rewards that are sent by post do we ask for name, street, postcode, town and country. These details are stored with the individual order only, not with the account. They are used for the delivery and deleted afterwards (period in section 6); on cancellation they are removed immediately.

No data is transmitted to partner businesses in the process — fulfilment is always handled by us.

For giveaways, participation, the time of entry and any accompanying entry comment are stored. Where an entry is excluded from the draw, we additionally record the reason, the time and the team member who decided.

The draw itself is recorded: the person drawn, their name at the time of the draw, the number of valid entries, the time and the team member who triggered it. Where a draw is voided, the reason is added. The record serves as evidence of a proper procedure and is visible only to our team; in the app, only who won is shown.

In the event of a win we notify the person drawn twice: with a notification in the app and with an email to the account’s address, sent via Resend. The time of the notification and the text sent are recorded with the draw. Any further details required for settlement are announced separately and deleted once the matter is settled, unless a retention obligation applies.

3.8a “Hiker of the week”

This contest is decided by the response of the community: per person, the post of a calendar week with the most likes is judged. No new data is collected for this — what is evaluated are the posts and likes that are stored under section 3.5 in any case; the evaluation takes place on our servers and is recalculated each time it is displayed.

Once a week has ended, our team reviews the result and closes the week. In doing so, the place, the name at that time, the number of likes, the reference to the post, the time and the team member closing it are recorded. These details do not change afterwards — not even where likes are withdrawn or the post is deleted. That is the purpose: an award whose basis shifts after the fact could not be verified.

Where a post is excluded from the judging, we additionally record the reason, the time and the team member deciding — the evidence that the exclusion took place before the week was closed and for an objective reason.

Whoever is on the podium is named in the app with their first and last name, profile picture and the post concerned, and remains so after the week has ended. Posts from accounts with a private profile do not take part in the judging; nobody is therefore named whose content is not public in any case.

Those placed are notified with a message in the app. Where a week carries a goodie, an email additionally goes to our team — it contains place, name and the number of likes and is the prompt to arrange despatch. It is sent via Resend (see section 4).

For despatch we get in touch with the person placed: with a message in the app and an email to the address of the account, likewise via Resend. We record the time and the text with the week. The details needed for despatch, in particular the address, are to be provided to us in reply; they then sit in our email inbox and are deleted once the matter is settled, unless a retention obligation applies. No address is created with the account or with an order — unlike when a reward is redeemed (section 3.8).

3.9 Support requests

Where a support request is submitted through the app, the category, subject, message text and account reference are stored. In the course of handling it, the processing status, an internal urgency rating, the team member responsible, our reply and any internal notes are added to the request. The same applies to details submitted when contacting us by email.

Conversely, our team may approach an account on its own initiative — about a report, a reward redemption or a maintenance arrangement, for instance. This happens by one of two routes. As a message in the app, an ordinary conversation is created between the team member’s account and the account addressed; it is stored like any other direct message (see 3.7), and a reply travels back the same way. As an email to the account’s address, the text is transmitted to our email service provider (see section 4) and additionally created as an entry in the app’s notification area, so that it remains traceable there as well; replies go to info@wanderer-app.cc. We keep no separate log of these contacts — what remains is the conversation, or the entry in the notification area.

3.10 Notifications

Push notifications are only sent once permission has been granted at operating-system level. For delivery, a device identifier (push token) is obtained from Firebase Cloud Messaging and stored against the account together with the device platform. Identifiers that have become invalid are removed automatically.

Every notification also creates an entry in the app’s notification area so that it remains accessible afterwards. Triggers include new followers, reactions to a user’s own posts, messages, completed challenges, requests, acceptances, changes and reminders for group hikes, and messages from our team about matters concerning the account. Permission can be withdrawn in the system settings at any time.

Under “Settings → Notifications” you can additionally choose which triggers are delivered to your device — either altogether or per category. This choice is stored against the account so that it is retained on further devices and after a reinstallation. It concerns delivery only: the entry in the app’s notification area is still created, so that the account keeps a record of what happened.

3.11 Usage analytics and crash reports

The app can collect usage statistics via Google Analytics for Firebase. What is currently recorded:

• the areas of the app opened
• sign-in and registration together with the method used (email, Google or Apple)
• the start and completion of a recording — on completion, additionally the distance, duration and ascent of the hike
• the opening of a detail page, stating the type of content concerned (hike, hut, region, partner business, post, prize draw, challenge, signpost or reward) and its internal identifier
• the sharing of such content, with the same two details
• the search term entered, together with the tab it was entered in. Only searches for hikes, huts, regions and partner businesses are recorded; searches for people and searches within posts are excluded
• contacting a partner business from within the app, with that business's identifier and whether it was called, emailed, or its website opened
• the display and the tapping of an advertising banner, with the banner's identifier and its position in the app

What is additionally transmitted: the account identifier in the form of the internal user ID, an instance identifier assigned by the SDK, device type, operating-system version, app version, and the approximate location at country level. Names, email addresses and recorded routes are not transmitted.

Deliberately not transmitted to Google are actions that already create an entry in our own database — posts and comments written, hiking points awarded and redeemed, challenges completed, entries to prize draws, and follow relationships. We evaluate those figures directly in our own database; transmitting them to an analytics service as well would serve no further purpose.

These statistics are pseudonymised, not anonymised. The events carry neither a name nor an email address, but remain attributable to an account and an app installation via the user and instance identifiers. They therefore continue to constitute personal data, and the rights set out in section 8 extend to them.

With the same consent, the app sends reports of crashes and of errors it does not catch itself to Firebase Crashlytics. A report contains the error message and the point in the program where the error occurred, the time, the app version, device model, operating system and its version, free storage and memory, and a random installation identifier assigned by the SDK. The IP address is processed as a technical necessity of the transmission. Reports are not linked to the account; name, email address, user ID and location are not included.

Both are disabled by default and takes place only after explicit consent. Consent is requested at first sign-in and can be withdrawn at any time with effect for the future under “Settings → Privacy & analytics” in the app. After withdrawal the SDKs send neither events nor crash reports and discard locally cached data; crash reports not yet transmitted are deleted. The choice made is stored against the account so that it persists across further devices and after a reinstallation.

3.12 Map display and maps without a connection

Map material comes from Mapbox, a service of Mapbox, Inc., established in the United States; it is displayed with Mapbox’s map library, which is built into the app. When map tiles, the map style and fonts are loaded, the device’s IP address is transmitted to Mapbox’s servers; without this transmission the map cannot technically be displayed. The tiles requested reveal which part of the map is being shown. Also sent along are the access key of our account, by which Mapbox attributes the request to us, and a randomly generated identifier with which Mapbox counts the devices on which a map was opened during the month — this is what Mapbox bills us for. No account, recording or community data is transmitted. The app determines the position shown on the map and in a recording itself and does not transmit it to Mapbox; on the map image of the live location page, see 3.21. The map data is based on OpenStreetMap.

Separately, provided location access has been granted, the map library itself requests an approximate location of the device (accurate to about one kilometre) and uses it for a configuration request to Mapbox. Mapbox does not disclose in detail in what form it is transmitted; we therefore assume that an approximate location is transmitted to Mapbox.

In addition, the map library can send usage and diagnostic data to Mapbox (telemetry). In the app, this is switched off by default; it can be switched on, and off again, via the ⓘ symbol in the map.

Mapbox determines the processing of this data as a controller in its own right; there is accordingly no data processing agreement under Art. 28 GDPR. According to its privacy statement, Mapbox deletes IP addresses after 30 days. The provider’s privacy statement is available at mapbox.com/legal/privacy.

Maps without a connection: hikes and freely chosen areas can be saved on the device for use without a connection. This loads the area’s map tiles via Mapbox — with the same connection data as above — and, for a hike, its description, route and elevation profile, the huts along the way and individual images from our servers. What is saved stays on the device; which hikes or areas someone has saved is not transmitted to us.

3.13 Weather data

Weather forecasts for trails, huts and regions are retrieved server-side at regular intervals and cached. The retrieval is performed per location, not per user; no personal reference arises.

3.14 Partner content and advertising space

The app displays references to partner businesses and offers. This content is served from our own servers; third-party advertising networks, tracking pixels and identifiers used for advertising purposes are not employed. Content is not selected on the basis of personal interests.

3.15 App store rating

Under “Settings → Rate the app”, the app opens its page in the App Store or on Google Play; the rating takes place there. We do not learn whether or what was rated. Any further processing is the responsibility of the respective store operator.

3.16 Saved trails and huts

Trails and huts can be marked as favourites. This stores the entry marked, the link to the account, and the time. This list is not visible to other users; a marking can be removed again in the app at any time.

3.17 Maintenance of huts, regions and partner businesses

Mountain huts, regions and partner businesses can be maintained by the businesses responsible for them. To that end we invite the responsible person by email. The invitation stores the email address, the hut, region or partner business concerned, the team member issuing the invitation, and the time.

Where the invited person signs in with an account carrying that same email address, the invitation is redeemed automatically: an assignment between the account and the business is created, recorded with the time and the inviting team member, and the invitation is marked as accepted. That assignment alone determines which content may be edited; it does not create a separate type of account — it remains an ordinary user account that can use the app as before. The account is additionally marked as maintaining a business. That marker follows from the assignments, lapses with the last of them, and serves only to give an overview within our administration: it is not visible in the app, and it confers no further rights. The maintenance itself takes place not in the app but in a separate web administration area.

An invitation can be revoked, and an existing assignment removed again. Invitations that were not accepted, and revoked ones, are deleted automatically twelve months afterwards. Accepted invitations and the assignments themselves remain for as long as the arrangement lasts — they evidence who granted a permission and who exercises it.

3.18 Sharing content

Posts, the signpost of the day, hikes, mountain huts, regions, giveaways, challenges, partner businesses and group hikes can be passed on using the operating system’s share function — to a messenger, by email, or to a social network. What is passed on is an address of the form wanderer-app.cc/s/… Anyone opening it who has the app installed lands directly in the app; everyone else sees a page on our website that displays the shared item and offers the app. For the signpost of the day, the image is attached as a file as well, because there the image is the content.

Whoever shares makes the item accessible to every person who receives the link — including people without an account. For posts, one restriction applies and is enforced server-side: they are only displayed on that page if the profile of the person who wrote them is public. Posts from private profiles, as well as hidden or deleted posts, are not displayed; the link then leads to a notice without content. For group hikes the page shows the trail, time, place, pace and free spots; who is inviting and the accompanying text only for a hike posted by our team or a partner business, or if the profile of the person who posted it is public. Participants are never shown, and hidden group hikes are not displayed (3.22). The pages carry a search engine exclusion and will therefore not appear in search results.

Sharing is not limited to the person who wrote a post: anyone who can see it in the app can share it. A link that has been passed on cannot be recalled; if the post is deleted or the profile is set to private, however, the page stops displaying the content within fifteen minutes at the latest. Copies that recipients have already made are beyond our influence — the same applies within the app (see 3.5).

When such a page is requested, we process the IP address, the time, the address requested and the browser’s details, in order to serve the page and to detect faults. These logs arise at Firebase Hosting and Cloud Functions (see section 4); the page itself is generated in a data centre in Belgium.

3.19 Newsletter

Anyone who consents when creating their account, or later in the settings, receives a few emails a year with pointers to new trails, huts, regions and giveaways. For this we process the account's email address and first name, together with the time and the place of consent — whether it was given when the account was created or in the settings. The first name serves only as a form of address.

Without consent no such email is sent. Consent is not preselected and is not required in order to use the app. It can be withdrawn at any time with effect for the future: with one tap on the unsubscribe link at the foot of every such email — no sign-in required — or in the app under Settings → Notifications. After withdrawal no further mailing is delivered, not even one that was already prepared at that point.

For every mailing we record which address it was delivered to and whether delivery succeeded. This is necessary in order to prevent duplicate delivery and to be able to follow up a complaint. No measurement of whether an email was opened or a link in it clicked takes place — the mailings contain no tracking pixels and no rewritten links.

The time and place of every consent and every withdrawal are logged separately. Without such evidence, consent is deemed not to have been given under Art. 7(1) GDPR; the log serves that purpose alone and is deleted together with the account.

Delivery runs via Resend (see section 4), the same service used for the emails about your account.

3.20 Recommendations and suggestions for walks

A walk can be recommended in the app. Stored for this purpose are the reason given, an optional rating from one to five stars, any photos, the timestamp and the link to the account. If the recommendation concerns a walk that the app does not yet cover, the details of that walk are added: name, starting point, starting place, and optionally a description, length, walking time, elevation and difficulty. If one of your own recordings is chosen as the basis, its route is copied into the suggestion — the recording itself is unaffected and is not published as a result.

Every submission is reviewed by a human before publication. Until then it is visible only to the person submitting it and to our team. For each decision, the timestamp, the deciding account and — in the case of a rejection — the reason are recorded. This review record is at the same time the evidence that negative ratings are not withheld (section 2(4)(2) of the Austrian Unfair Competition Act).

Once approved, the recommendation appears publicly on the walk concerned — with first name, surname, profile picture, rating, text and photos, including for visitors to a shared page who are not signed in. Anyone who does not want this does not submit a recommendation; the feature is optional and not necessary in order to use the app. A recommendation can be withdrawn at any time in the app under Profile → My recommendations, which deletes the text, the rating and the photos.

On the photos: they are scaled down and re-encoded on the device when selected. The additional information carried in the file is lost in the process, in particular the time of capture and any GPS coordinates. What remains of a photo is the image.

If a photo is submitted with separate consent, it may be taken over as an image of the walk. It thereby becomes editorial content of the app, appears independently of the recommendation, and remains after the recommendation is withdrawn or the account deleted. This consent is not pre-selected, is not a condition for publication, and can be withdrawn at any time via privacy@wanderer-app.cc; we then remove the image.

A points entry is created for a published recommendation and for a suggestion taken over (section 3.8). A notification in the app informs you of the decision (section 3.10). When a submission arrives, an email is sent to our mailbox info@wanderer-app.cc; it contains the submitted text, the display name and a link to the submission, but no email address.

3.21 Sharing your live location

During a recording, you can share your location with people you choose — for example with family who want to know where you are. The app creates a link of the form wanderer-app.cc/live/… and hands it to the operating system’s share menu; who receives it is decided by the user alone. No position is shared without this express step.

While sharing, the app reports the most recently determined position and its time to our servers about every two minutes; if there is no reception, the next one as soon as a connection is available again. Reporting continues while the screen is locked, as long as the recording is running (3.3). The recording screen shows that you are sharing and when the last position arrived.

Anyone with the link can see, without an account and without the app: the first name, the walk if the recording was started on one, the last position with coordinates and time, and the route of the last few hours on a map image. The page does not show the last name, profile picture or any other account details. The link contains a random string, is not derived from account or device identifiers and cannot be guessed; it is, however, not tied to a person — anyone it is forwarded to sees the same. The page is blocked for search engines.

Sharing ends with the recording — when it is finished, saved or discarded —, manually in the recording, and at the latest after 24 hours. When it ends, all reported positions are deleted; the link then only shows that sharing has ended. If there is no connection when sharing ends, the app catches up on the deletion as soon as there is one; independently of this, sharing ends on the server after 24 hours.

Our server generates the map image of the page via Mapbox (3.12): to do so, it transmits the most recently reported positions, without a name, the link or any other identifier. The IP address of the person viewing the page does not reach Mapbox. The buttons “Open in Google Maps” and “Open in Apple Maps” pass the last position to the respective service — only when tapped; that service’s privacy policy then applies.

When the page is accessed, we process the IP address, time, requested address and browser details, as for shared items (3.18), in order to serve the page and detect faults.

This feature does not replace an emergency call. Whether a position arrives depends on reception, battery and the device settings; it does not enable emergency services to locate anyone.

3.22 Hike together

Under “Hike together” you can post a date on one of the app’s trails that others can join. We store the trail, date and time, the number of free spots, the intended pace, a freely written text and the meeting point, together with who posted it and when. Anyone who wants to come along sends a request; we store the request together with any short message, its time, and whether it was accepted, declined or withdrawn.

Group hikes can also be posted by our team and by partner businesses (“official hikes”). A hike posted by the team names the team member who posted it — with first name, last name, profile picture and team badge —, a hike posted by a partner business names the business; it is posted through the account of a team member or of a person who manages the business in the app, and that account is a member of the group chat. Official hikes have up to 30 spots and can accept requests immediately while spots are free — the request then counts as accepted.

Visible to everyone who is signed in are the hike with its trail, time, pace, free spots and text, and the first name, last name and profile picture of the person who posted it together with the number of tours they have recorded in the app — even if their profile is private (3.2). The app points this out before posting. People who have blocked each other (3.6) do not see each other’s hikes.

A group hike can be shared as a link (3.18). The page for it shows the trail, time, place, pace and free spots even without signing in — but the name and text of the person who posted it only if their profile is public. For official hikes the text is always shown, together with the name of the business or “Wanderer team”, with the team member’s first name if their profile is public. The page never names participants. We may additionally feature official hikes in the app.

Only the person who posted it and those accepted see the exact meeting point, who has joined, and the group chat (3.7). The person who posted it additionally sees open requests with first name, last name, profile picture, number of recorded tours and the message sent with the request — here too regardless of whether the requesting person’s profile is private. Other participants do not see that message. The number of tours is calculated from the stored tours each time it is requested and is not recorded separately; the feature does not disclose routes, times or places of those tours.

The app notifies those involved of requests, acceptances, declines, changed times or meeting points and cancelled hikes (3.10), and once with a reminder between 24 hours and one hour before the start. The hike, requests, participations, meeting point and group chat including its messages are deleted automatically 90 days after the hike (section 6).

A group hike can count towards challenges (3.8): it counts for whoever posted the hike or was accepted, provided the hike was not cancelled and they recorded a tour on exactly that trail on the same day. This is evaluated on our server from the existing data; nothing is stored separately for it.

Hikes for women only. A group hike can be marked “women only”. Only those who have stated “female” as their gender can post one or request to join. Stating gender is voluntary — during onboarding, under “Settings → Account” or at the first women-only hike — and the options are “female”, “male”, “non-binary” or “prefer not to say”. In the app and in our administration area it is visible to nobody, not even to the person who posted the hike; it appears neither on the profile nor on the page of a shared link. It is evaluated only on our server when someone posts a women-only hike, requests to join one or is accepted. It is not verified. Choosing “prefer not to say” deletes it; it is also deleted with the account.

We only put people in touch. Whether and how they meet is up to them; the rules are set out in section 8c of the terms of use.