MetroPing, iOS bundle ID and Android package com.gaurav.MetroAlertApp, is developed and provided by its independent developer. In this policy, MetroPing is also referred to as “the Application.” It provides metro journey assistance, destination alarms, interchange guidance, route planning, and related transit features.

MetroPing is designed to process as much information as reasonably possible on your device. Network-connected features, required pre-release testing and optional features may, however, transmit information to MetroPing and its service providers. This Privacy Policy explains what information is processed, why it is used, when it leaves your device, and the choices available to you.

MetroPing is provided as a free service and is intended for use “AS IS.”

Which Build Are You Using?

This policy covers publicly released MetroPing builds and pre-release builds distributed through Apple TestFlight, Google Play testing, or direct internal testing. The distribution mode is fixed when the build is created and determines which testing collection is enabled.

Production Build

App Store and Google Play production builds use the reviewed store-safe surface. After Terms acceptance they send the limited first-party startup/foreground operational check-in described in section 2.2. Tester journey telemetry and remote activation of experimental features are disabled. After notification permission has been granted, a production build may register a Firebase Cloud Messaging or Apple Push Notification service token with MetroPing for operational notification delivery. Registration includes the token, a random installation identifier, platform, distribution and app-variant labels, the selected service-city scope, and notification-preference flags. Marketing delivery remains off until you separately opt in through the in-app marketing prompt. After that consent, marketing categories start enabled, can be adjusted individually in notification settings, and can all be disabled by withdrawing marketing consent there. MetroPing does not use the token for advertising or cross-app tracking, and production promotional account-credit surfaces remain disabled. Optional product analytics is off unless you turn it on; if you do, first-party analytics may receive the station, route, journey and reliability events described below, Firebase Analytics may receive filtered product events, Microsoft Clarity may receive screens viewed and tap interactions with on-screen text masked, Sentry may receive crash, error and performance reports with personal fields filtered before sending, and automatic diagnostic uploads may run. Station-level event context can reveal or infer precise physical location even though the analytics event does not contain raw GPS coordinates. Advertising storage remains denied and you can withdraw optional-analytics consent at any time in the app's analytics settings. Limited server request, security, and failure logs may still be processed when necessary to secure or operate a network feature you deliberately request.

Internal Testing

Invited internal builds require detailed first-party tester telemetry after the tester accepts the in-app disclosure. The current internal profile also enables Firebase Analytics, Microsoft Clarity and Sentry after acceptance. Clarity receives screens viewed and tap interactions with on-screen text masked; Sentry receives crash, error and performance reports with personal fields filtered before sending. A narrow PostHog pilot may receive only a server-side allowlisted subset of semantic internal-tester events with one-way pseudonymous installation and event identifiers. PostHog autocapture, session replay, person profiles and GeoIP enrichment are disabled, and the pilot payload excludes station names, raw GPS coordinates, account identity, free text and arbitrary event properties. Advertising storage remains denied.

Apple TestFlight External Testing

External TestFlight builds require first-party tester telemetry after the tester accepts the in-app beta disclosure. The current external profile also enables Firebase Analytics, Microsoft Clarity and Sentry after acceptance. Clarity receives screens viewed and tap interactions with on-screen text masked; Sentry receives crash, error and performance reports with personal fields filtered before sending; advertising storage remains denied. If you do not agree, do not continue using the TestFlight build.

Google Play Closed Testing

Closed-testing builds use the reviewed store-safe rider surface. They transmit no tester analytics or automatic diagnostics before acceptance. The prominent Closed Beta flow requires the tester to separately select “I agree to required tester diagnostics” before “Accept terms and start testing” becomes available. Only after both actions succeed does the build enable the required high-detail tester-diagnostics tier described in section 2.1. This includes a first-party operational heartbeat plus station, route, journey, alert, background-reliability, connectivity, interaction, crash and performance events. Station-level context can reveal or infer precise physical location even though raw GPS coordinates and continuous location trails are excluded. Firebase Analytics, Microsoft Clarity and Sentry process only their disclosed subsets of the testing data; advertising storage remains denied. Remote experimental activation remains disabled. After notification permission is granted, the build may register a distribution-scoped token for operational notifications. Marketing delivery remains off until the tester separately opts in through the in-app marketing prompt; after consent, categories start enabled and remain adjustable or fully withdrawable in notification settings.

Google Play Open Testing

Open-testing builds use the reviewed store-safe rider surface and transmit no tester analytics or automatic diagnostics before acceptance. The prominent Open Testing flow requires the tester to separately select “I agree to required tester diagnostics” before “Accept terms and start testing” becomes available. Only after both actions succeed does the build enable required medium-high tester diagnostics. Open uses the same disclosed categories as Closed while coarsening connectivity sampling and time buckets. Station and route progress can reveal or infer precise physical location even though raw GPS coordinates and continuous location trails are excluded. Firebase Analytics, Microsoft Clarity and Sentry process only their disclosed subsets of the testing data; advertising storage remains denied. After notification permission is granted, the build may register a distribution-scoped token for operational notifications. Marketing delivery remains off until the tester separately opts in through the in-app marketing prompt; after consent, categories start enabled and remain adjustable or fully withdrawable in notification settings. If you do not agree to required testing collection, do not join the open test. To withdraw from that collection, leave the open test and uninstall the build.

Required pre-release telemetry applies to invited internal builds, Google Play closed/open-testing builds and external TestFlight builds only after the corresponding disclosure is accepted. It helps MetroPing identify failures in journey progress, destination and interchange alerts, background execution, underground fallback, notifications, updates, and journey completion. Closed and Open are required testing tiers rather than optional analytics tiers; the Closed heartbeat is only one component of its broader required tester collection. The production check-in remains limited to its separate operational purpose below.

Required tester telemetry can include a random installation identifier, session identifiers and timestamps, app/build and operating-system versions, device model, tester classification, screens, buttons and features used, selected source, destination and current station names, route and interchange information, service-city tags, station-segment durations, journey lifecycle and progress events, tester-participation counts, alert and notification delivery or open status, location-availability and accuracy status, permission and background-task status, coarsened connection and carrier-class observations, update status, errors and crash context. Because a current metro station identifies a small physical area, current-station and station-segment context is treated as precise location information even when no latitude or longitude is sent. Testing profiles may also register a distribution-scoped notification-delivery token with the installation identifier after notification permission and any applicable tester disclosure. Production registration is described separately above.

This required tester telemetry does not include passwords, verification codes, contacts, messages, advertising identifiers, typed private content, raw GPS coordinates or a continuous location trail. Photos, videos, files and support text leave the device only when you deliberately submit them through support or use an enabled sharing feature. Station and route location context is different: it is included in the required tester events described above after acceptance. Account identity and synced travel data are handled separately when you choose to sign in.

After tester acceptance, the first-party telemetry service receives the detailed tester event fields described above. Firebase Analytics receives filtered product events and relevant app, platform, operating-system and general device context, without station names or MetroPing's installation identifier. Microsoft Clarity receives screens viewed and tap interactions with on-screen text masked. Sentry receives crash, error and performance reports with personal fields filtered before sending. Advertising storage, ad personalization, and ad user data remain denied. MetroPing does not authorize a provider to use tester data for advertising or unrelated cross-app tracking.

If you do not agree to required collection in an internal, Google Play closed/open-testing or external TestFlight build, do not continue using that build. You may leave the testing programme, uninstall the build, and request deletion of server-side tester information using the methods below. Production releases use the separate store-safe rules described above.

1. Information Processed on Your Device

1.1 Precise and Approximate Location

MetroPing may request access to your device’s precise or approximate location to provide features such as:

  • Detecting nearby metro stations;
  • Monitoring progress during an active journey;
  • Estimating when your destination or interchange is approaching;
  • Triggering destination and interchange alerts;
  • Detecting possible wrong-direction movement;
  • Supporting journey progress while the screen is off or the Application is in the background.

In closed-testing, open-testing and production builds, tracking begins only after you tap Start for a selected journey. When background location permission is enabled, MetroPing may continue receiving location updates during that Active Journey Alert. This keeps destination and interchange alerts working when the Application is not open on screen and helps an already-active journey recover after an app or device restart. Tracking stops when the active journey ends.

Automatic journey start and Smart Boarding reminders are available only in internal or external testing profiles. They are disabled in closed-testing, open-testing and production builds.

For normal route tracking and destination-alarm functionality, location coordinates and station-proximity calculations are primarily processed locally on your device.

If you sign in and use account sync, current builds remove latitude, longitude, and fix accuracy from the current-station snapshot before it is sent to MetroPing. The central raw-coordinate switch is off in every current distribution, so the station-coordinate correction prompt is also hidden and its upload endpoint is blocked by the app. Route or station context may still leave the device when you deliberately include it in a support submission.

MetroPing does not include raw GPS coordinates or a continuous GPS history in required tester-telemetry or optional usage-analytics events. However, a current station, station segment or station-level journey-progress event can reveal or infer precise physical location and is treated as precise location information for disclosure purposes.

Location information may leave your device in the limited circumstances described below: current builds do not send raw coordinates; route or station context can be sent when you deliberately include it in support or sharing; required station-level tester events are sent in Internal, Closed, Open and External builds after the corresponding tester disclosure is accepted; and production station or route analytics events are sent only after you separately choose optional analytics. The required production operational check-in contains no location, station or route data. A future build must not enable raw-coordinate transmission without first updating its prominent disclosure, this Policy, and the applicable store privacy declarations.

1.2 Route, Journey and Travel History

MetroPing may store the following information locally:

  • Selected source and destination stations;
  • Calculated routes and interchange information;
  • Current and previously detected stations;
  • Completed journey history;
  • Destination-alarm settings;
  • Smart Commute preferences and frequently used route patterns;
  • Notification, appearance and performance preferences.

Local travel history can be removed through the Trips or History section using the available deletion controls.

Uninstalling MetroPing normally removes information stored locally by the Application. Uninstalling does not automatically delete information that you separately chose to transmit to MetroPing’s servers.

1.3 Motion & Fitness and Device Motion

During an active journey, MetroPing may use Motion & Fitness activity and device-motion readings from the accelerometer and gyroscope to detect train movement and estimate journey progress when GPS is weak underground.

MetroPing processes these readings on your device for journey tracking and does not use them for advertising or cross-app tracking. If you explicitly submit a support diagnostic, it may include coarse sensor-health results, but not raw sensor samples.

1.4 Voice, Speech and Vibration Alerts

MetroPing may use your device’s text-to-speech, vibration, haptic and notification functions to alert you about an approaching destination or interchange.

MetroPing does not require microphone access to generate text-to-speech alerts. It does not record your voice through these features.

1.5 Device Health and Performance State

MetroPing processes coarse battery level, charging state, low-power mode, memory class, and available-storage status on your device to recommend reliable tracking settings and Lite Mode. These readings are not uploaded, linked to your account, used for advertising, or included in analytics. The latest coarse state remains on your device until app data is cleared or the app is uninstalled.

2. Store-Safe Analytics Policy and Testing Telemetry

Production builds show a separate optional analytics-consent prompt after legal acceptance and do not transmit optional product analytics or automatic diagnostics unless you choose “Share usage and diagnostics”. Internal, Google Play Closed, Google Play Open and External TestFlight builds enable their required testing collection only after acceptance of the corresponding prominent tester disclosure. Android and iOS production builds send the smaller required operational check-in described below after acceptance of the Terms.

2.1 Required Pre-Release Tester Telemetry

Before tester acceptance, these pre-release builds do not transmit tester analytics or automatic diagnostics. After acceptance, Internal, Closed, Open and External builds send the required tester data listed above to validate journeys, alerts, underground behavior and application reliability. The unchecked “I agree to required tester diagnostics” control provides the separate affirmative telemetry choice; the “Accept terms and start testing” action remains disabled until it is selected. Successful completion authorizes the required testing collection and the disclosed Firebase Analytics, Microsoft Clarity and Sentry processing.

The PostHog pilot applies only to invited Internal testing and does not apply to Closed, Open, External TestFlight or Production distributions. MetroPing's backend selects a small set of semantic onboarding, route-planning, journey-lifecycle, alert and reliability events, removes fields outside a fixed allowlist, buckets values such as route length and duration, replaces installation and event identifiers with one-way keyed pseudonyms, disables GeoIP enrichment and sends the result to PostHog without person profiles. The app does not embed a PostHog client and the pilot does not use autocapture or session replay.

Closed additionally sends a first-party operational heartbeat when the app starts or returns to the foreground and periodically while it remains active. The heartbeat itself contains only a random app-scoped installation identifier, a random session identifier, timestamps, app/build, Android/platform, general device model/type and release/distribution information. The heartbeat payload excludes location, station, route, journey, search, screen, tap and user-entered data and is not forwarded to Firebase Analytics, Microsoft Clarity or Sentry. It is only one part of Closed's broader required tester collection; separate tester events include the station, route, journey and diagnostic fields described above.

Required tester collection cannot be turned off while continuing to use that testing build. To withdraw and stop future required testing collection, leave the applicable testing programme and uninstall the testing build. You may also request deletion of first-party tester records that MetroPing can locate, as described in sections 12 and 13. Information already processed by service providers remains subject to their applicable retention and deletion controls.

2.2 Required Production Operational Check-In

After a user accepts the Terms, Android and iOS production builds send one first-party operational check-in when the app starts or returns to the foreground. We use it to verify service and release compatibility, identify app or operating-system versions affected by an operational problem, and maintain first-seen and last-seen service status.

The production check-in contains a random app-scoped installation identifier, a random session identifier, timestamp, app version and build number, platform, operating-system version and general device model/type. It excludes account identifiers, advertising identifiers, location, stations, routes, journeys, searches, screens, taps, feedback and user-entered content. It is sent only to MetroPing's first-party backend and is not forwarded to Firebase Analytics, Microsoft Clarity or Sentry. It is not a periodic background heartbeat.

The production operational check-in is required while using the network-connected production app. Uninstalling the app stops future collection. Optional product analytics and automatic third-party diagnostics remain separate choices.

Depending on the distribution and consent stage, required tester telemetry or optional production analytics may transmit:

  • Application version and build information;
  • Platform and operating-system information;
  • General device or capability information;
  • A randomly generated installation identifier;
  • A randomly generated session identifier;
  • Feature-engagement events;
  • Session start, heartbeat and end events;
  • Journey started, live, completed or stopped events;
  • Selected source, destination and current station names;
  • Route length and number of stations remaining;
  • Coarse service-city, state or country tags derived from the supported metro area, without raw coordinates;
  • Station-to-station segment duration used to understand crowding and journey reliability;
  • During an active journey, a one-way hashed station-segment key, coarse connection availability, duration buckets and, only in testing tiers, a normalized carrier class or cellular generation;
  • Destination-alert or journey-feature status;
  • Notification delivery, open and action status;
  • Tester tags in authorized testing builds.

The random installation identifier is pseudonymous. It is not an advertising identifier, but it can allow multiple analytics events from the same installation to be associated with one another.

MetroPing does not copy your provider name or email address into product-analytics events. When you are signed in, however, first-party events may include or be associated with your internal account identifier, installation identifier, session identifier, or journey identifier. Those events are therefore not necessarily anonymous even when they omit your name and email address.

Required tester-event and optional product-analytics payloads do not include:

  • Your name;
  • Your phone number;
  • Your email address;
  • Advertising identifiers;
  • Contacts;
  • Photos or files;
  • Message content;
  • Raw GPS coordinates;
  • A continuous location trail.
  • Call content, call history or phone numbers contacted;
  • Wi-Fi names, router identifiers, IP addresses or browsing activity.

We use optional analytics to:

  • Understand whether journey and alert features are functioning;
  • Identify unreliable alerts and technical problems;
  • Improve route and station handling;
  • Build privacy-thresholded aggregate travel-time guidance for other riders;
  • Understand feature usage;
  • Prioritize Application improvements;
  • Measure performance and stability.

Internal, Closed, Open and External testers can leave the applicable testing programme and uninstall the testing build to withdraw and stop future required tester collection. Production users can uninstall to stop future required operational check-ins. Information already transmitted may remain until it is deleted or aggregated under our retention practices and applicable provider controls. Optional production analytics remains off unless the user grants consent and stops again when consent is withdrawn in the Application's analytics settings.

MetroPing does not use optional analytics for third-party advertising or cross-app tracking.

3. Optional Persona and Commute Survey

This optional survey and its sharing prompt are disabled in closed-testing, open-testing and production builds. The following description applies only when the feature is enabled in an internal or external testing profile.

MetroPing may offer an optional personalization survey. The survey may ask about:

  • Whether you are a student, working professional or transit explorer;
  • Gender, including a “Prefer not to say” option;
  • How frequently you use the metro;
  • Whether you normally use the same or varying routes;
  • Commute challenges such as sleeping during travel, missing stops, missing meetings or missing interchange connections.

The gender question is optional.

Survey answers can be used locally to adjust settings such as destination-alert timing and Smart Commute suggestions.

At the final survey step, MetroPing provides separate choices:

  • Save on Device: The answers remain stored locally and are not submitted to the admin panel.
  • Save & Share Insights: The selected answers are transmitted to MetroPing’s service so that they can be viewed in the admin panel and used to improve alert defaults, product decisions and commute features.

Sharing survey answers is optional. Refusing to share does not remove local personalization features.

Unless clearly stated in the survey disclosure, a persona submission does not include your name, phone number, email address, account ID, precise GPS coordinates, contacts, photos, messages or advertising identifier.

Survey submissions are not used for third-party advertising or cross-app tracking.

4. Optional Account and Cloud Sync

MetroPing offers optional Google and Apple sign-in. Firebase Authentication verifies the provider identity token and MetroPing creates or restores the linked MetroPing account.

When you use this feature, MetroPing may process:

  • Your Google, Apple or Firebase account identifier, sign-in provider, verification status and any name or email address the provider makes available;
  • An internal account identifier;
  • The installation identifier and general device record linked to the account;
  • Account status;
  • Account configuration and feature-eligibility fields;
  • Synced current-station or active-journey state, with latitude, longitude, and fix accuracy removed from outbound snapshots in current builds;
  • Technical information required to prevent abuse and maintain account security.

While you are signed in, MetroPing can sync supported completed-journey records, recent destinations, station-visit timeline, current station state and related travel-history fields to the server. The sync merges the server copy with supported data on signed-in devices so it can be restored after app data is cleared or the Application is reinstalled.

You are not required to create an account to use the core local destination-alarm and route features unless the Application clearly states otherwise.

Signing out does not by itself delete the server copy. “Deactivate beta account” is also not deletion: it blocks sign-in but keeps the account and linked beta data so the tester may return. “Delete account permanently” removes the active server-side account, Firebase Authentication identity, sessions, installation links, and raw account-linked data as described in Sections 12 and 13. Local journey history may remain on your device until you delete it separately or uninstall the Application.

Production builds present permanent deletion as the primary account-removal action. External TestFlight and other pre-release builds may additionally offer beta deactivation, but that supplementary choice never replaces permanent deletion: the permanent-deletion action remains separately available to the signed-in tester.

5. Meet and Location-Sharing Features

Meet, friend-coordination, and journey-sharing actions are not available in closed-testing, open-testing or production builds. The following description applies only if such a feature is enabled in an internal or external testing profile.

When you deliberately activate such a feature, MetroPing may process or transmit information such as:

  • A meetup or sharing code;
  • Your selected route;
  • Source and destination stations;
  • Current station or journey progress;
  • Approximate or precise location where required by the feature;
  • Timestamps and sharing-session status;
  • Information necessary for the invited participant to view your progress.

Location or journey information is shared only after you deliberately start the relevant feature. You should share meetup codes only with people you trust.

End the sharing session when coordination is complete. MetroPing does not use Meet-session location information for advertising or cross-app tracking.

6. Feedback, Support and Corrections

When you contact MetroPing, report a problem or submit feedback, we may receive:

  • Your name or preferred contact details when you enter them;
  • Feedback text;
  • Suggested station or route corrections;
  • Your email address when you contact us by email;
  • Current station, journey phase or diagnostic context included in the submission;
  • Application version, device information and technical diagnostics;
  • Submission timestamps and support correspondence.

Closed-testing, open-testing and production builds support text-based submissions and do not offer photo, screenshot, or file attachments. Internal or external testing builds may offer a user-initiated attachment picker after a separate disclosure.

Do not include sensitive information in feedback unless it is necessary for us to handle your request.

Feedback information is used to investigate problems, respond to support requests, correct route data, improve the Application and prevent abuse.

7. Operational Diagnostics and Security Information

MetroPing and its hosting providers may process limited operational information necessary to operate and secure network services, including:

  • Request date and time;
  • Internet Protocol address;
  • General browser, operating-system or device information;
  • Server request and error logs;
  • Security events;
  • Rate-limit information;
  • Crash or failure information;
  • Information necessary to prevent fraud, abuse or unauthorized access.

This information is not intended for advertising or cross-app tracking.

Strictly necessary diagnostics are separate from optional usage analytics and may be processed when required to secure or operate the service. We aim to minimize this information and avoid including raw location coordinates, survey answers or unnecessary personal information in diagnostic logs.

When Vercel or Cloudflare does not provide coarse country, region or city headers for an analytics request, MetroPing may send the request's public Internet Protocol address to ipapi.co to obtain that coarse location. MetroPing uses the returned country, region or city for the disclosed analytics context and does not add the raw address to the application analytics event. The lookup result is temporarily cached to reduce repeat requests.

8. Notifications and Advanced Alarms

MetroPing may request notification permission so it can deliver local destination, interchange, and active-journey notifications.

Closed-testing, open-testing and production builds do not request Android full-screen-intent access, Android notification-policy access, or the iOS Critical Alerts entitlement. On iOS, a destination or urgent interchange alert may use the Time Sensitive interruption level when the operating system permits it.

These capabilities are controlled by the operating system and may require separate permission or platform approval. MetroPing should use stronger interruption capabilities only for a journey you started and an urgent final destination or interchange warning.

Notification permission can be changed through your device settings.

Every distribution may register a distribution-scoped Firebase Cloud Messaging or Apple push token after notification permission has been granted and, for applicable testing builds, the relevant tester disclosure has been accepted. Registration uses the random installation identifier and operational scope described above so requested service or update notifications can reach the device. Marketing topics remain separately consent-gated, and clients reject destinations for another distribution track.

8A. Apple App Privacy Category Mapping

Apple uses standardized App Privacy labels that can be broader than MetroPing’s feature names. To report conservatively, MetroPing maps the information described throughout this policy as follows:

  • Search History: route or station search terms, source and destination selections, and recent-destination activity transmitted to provide route results or cloud sync and, when the applicable telemetry is enabled, to understand route-feature use. This means searches inside MetroPing, not web-browser history;
  • Customer Support: support or feedback messages, route corrections, correspondence, contact details, or diagnostic context that you deliberately include in a support submission; internal or external testing builds may also accept a user-selected attachment;
  • Other Usage Data: session, journey, alert, notification, testing-participation, and other app-use events that are not fully described by Apple’s narrower Product Interaction category; and
  • Other Data Types: optional commute-survey answers, beta or app-service submission fields, and other information described in this policy that does not fit a narrower Apple category.

Search History, Other Usage Data, and Other Data Types are used for Application Functionality and analytics as described above. Customer Support information is used for Application Functionality, including responding to and investigating the request. Depending on the feature and sign-in state, these records may be associated with an internal account, installation, session, journey, email address, or another locator needed to provide the feature. MetroPing does not use any of these categories for advertising or cross-app tracking.

9. Information We Do Not Sell or Use for Advertising

MetroPing does not sell your personal information.

MetroPing does not use your information for:

  • Third-party targeted advertising;
  • Creating advertising profiles;
  • Data-broker activities;
  • Cross-app or cross-website tracking;
  • Selling precise location information.

MetroPing does not request access to contacts, messages, microphone recordings or the advertising identifier for its core journey-alert service.

10. Service Providers

MetroPing may use contracted service providers to operate network-connected features. Depending on the current build and enabled features, these may include:

  • Google Firebase Authentication, Google Sign-In and Sign in with Apple, for optional identity verification;
  • Google Firebase or Firestore, for optional account and travel-data sync, database, feedback, or Application-service functionality;
  • Firebase Cloud Messaging and Apple Push Notification service, for permission-gated operational notification delivery in every distribution and for separately consented marketing delivery where offered, as described above;
  • Google Firebase Analytics, for filtered product and feature events: in Internal, Closed, Open and External builds after the required tester disclosure is accepted, and in Production only after separate optional-analytics consent;
  • PostHog, only for the server-filtered, pseudonymous semantic-event pilot in invited Internal testing described in section 2.1; it is not used for Closed, Open, External TestFlight or Production distributions;
  • Microsoft Clarity, for screens viewed and tap interactions with on-screen text masked: in Internal, Closed, Open and External builds after the required tester disclosure is accepted, and in Production only after separate optional-analytics consent;
  • Sentry, for crash, error, or performance diagnostics with personal fields filtered before sending: in Internal, Closed, Open and External builds after the required tester disclosure is accepted, and in Production only after separate optional-analytics or crash-diagnostics consent;
  • Better Stack, when operational logging is configured, for limited backend failure and service-health logs needed to investigate outages and secure the service;
  • MongoDB, for MetroPing-controlled account, application-service, support and analytics records; and Upstash Redis or QStash, for short-lived caching, rate limiting, request coordination, queues and scheduled processing;
  • Supabase Storage, only when the bounded object-storage pilot is enabled, for administrator-uploaded promotion artwork held in a private bucket and fetched through MetroPing's backend. This pilot does not store tester telemetry, account records, journey data, feedback text or feedback attachments in Supabase;
  • ipapi.co, only as a fallback when hosting headers do not provide coarse geography, to convert a request's public Internet Protocol address into country, region or city information;
  • Vercel, for hosting APIs, web pages, analytics endpoints, admin services or related infrastructure;
  • Apple and Google platform services, for notifications, application distribution, device permissions and operating-system functionality.

These providers may process information on our behalf under their own security and privacy obligations. We require service providers that receive MetroPing personal information to provide the same or equal protection described in this policy and to process that information only under MetroPing's instructions for the disclosed purposes.

We do not authorize service providers to use MetroPing information for their own advertising or unrelated independent purposes.

Information may be processed in countries other than the country where you live, depending on the infrastructure used by these providers.

10A. MetroPing Website and Beta-Access Form

The MetroPing website works without optional behavioural analytics. If you choose “Allow analytics,” the website may use first-party analytics, Vercel Analytics, Vercel Speed Insights, Microsoft Clarity, Google Analytics, and website Sentry when it is configured. These services may process page views, clicks, web-performance measurements, website errors, blog-reading progress, form and conversion events, coarse device/browser and country information, referral or campaign parameters, an A/B-test variant, and randomly generated visitor and session identifiers. Blog-reading progress is limited to the public article path, public title, and 25%, 50%, 75%, or 100% milestones; it does not collect selected text or typed content. Advertising storage is denied. These website services load only after you allow analytics.

The optional visitor identifier and analytics-consent choice may remain in first-party cookies or browser storage for up to one year; an A/B-test assignment cookie may remain for up to 30 days. MetroPing hashes the randomly generated event, visitor, and session identifiers before its first-party backend stores them. Raw first-party website-event records use a configurable retention window whose default is 400 days and whose maximum is 730 days. If the primary analytics store is temporarily unavailable, a bounded retry queue may hold the same privacy-filtered event for a configurable period whose default is seven days and whose maximum is 30 days. Derived visitor and session records, unique daily visitor/session records, daily dimension aggregates, and hashed per-article reader-milestone records are retained longer for trend and readership reporting and do not currently have an automatic expiry. Copies processed by Vercel, Microsoft, Google, or Sentry follow the applicable provider retention and deletion controls configured for MetroPing.

If you request Android beta access on the website, MetroPing receives your Google Play email address, optional phone number, selected platform and city, request source, status, and timestamps. These details are used to manage beta access and contact you about the request. The iPhone TestFlight link does not require the website beta form. You may request removal of a beta-access record by contacting us.

11. Legal Disclosure

We may preserve or disclose information when reasonably necessary to:

  • Comply with applicable law, legal process or a valid government request;
  • Protect the rights, security or property of MetroPing, its users or others;
  • Investigate fraud, misuse, security incidents or violations;
  • Respond to an emergency involving a risk of harm;
  • Establish, exercise or defend legal claims.

We will disclose only the information reasonably necessary for the relevant purpose.

12. Data Retention

We retain information only for as long as reasonably necessary for the purpose for which it was collected, including operation, analytics, support, security, dispute resolution and legal compliance.

Retention depends on the type of information:

  • Local journey history and settings remain on your device until you delete them, reset the Application or uninstall it;
  • An active optional account and its synced travel data remain until you choose permanent deletion;
  • A beta account you only deactivate remains stored with its linked beta data; deactivation blocks access but is not a deletion request;
  • Notification tokens registered by any distribution build remain while needed to address authorized notifications to that installation and may be replaced when the platform rotates the token or removed when they are no longer operationally required;
  • Tester analytics collected by an Internal, Closed, Open or External testing build may be retained while needed for product analysis and may later be deleted or converted into irreversibly de-identified aggregate statistics; optional persona submissions apply only where that feature is enabled. Internal-pilot semantic events already sent to PostHog follow the retention and deletion controls configured for that provider;
  • Raw tester telemetry may be retained for the relevant test and a reasonable defect-investigation period, then deleted or irreversibly de-identified; permanent account deletion removes raw records that MetroPing can locate through the deleted account, installation, session, or journey identifiers;
  • Feedback and support correspondence may be retained while the issue is being investigated and for a reasonable period afterward;
  • Any sharing-session record created by an internal or external testing feature expires after its documented sharing period and is removed when linked to an account that is permanently deleted;
  • Security and server logs may be retained for a limited operational period or longer where required to investigate abuse or comply with law.

Permanent in-app deletion removes the active account, Firebase Authentication identity, account sessions, installation links, and raw account-linked application data from active stores. MetroPing may keep an opaque, non-reversible deletion receipt for up to seven days so retries do not recreate the account. Data removed from active stores may remain in isolated disaster-recovery backup snapshots until those snapshots are retired under the configured backup lifecycle; these backups are not used for normal product or analytics access. If recovery from a backup is required, MetroPing will use reasonable operational checks to review and reconcile deletion state before returning restored data to normal service. This is an operational review, not a guarantee of automatic per-record deletion replay.

This in-app confirmation applies to MetroPing-controlled account and first-party records. It does not itself guarantee immediate erasure of every pseudonymous event already held by Firebase Analytics, Microsoft Clarity, Sentry or, for invited internal testers included in the narrow pilot, PostHog. Provider-held records follow the applicable retention and deletion controls configured for MetroPing. Where a provider offers a suitable record-level deletion tool and the record can be reliably located, MetroPing will use that tool or handle a verified manual request as applicable.

MetroPing may retain statistics only after they have been irreversibly de-identified so they can no longer be associated with your account, installation, sessions, journeys, or other identifiers. We may also retain the minimum information required by law, to investigate security or fraud, or to establish or defend a legal claim, and will restrict it to that purpose. We otherwise delete or de-identify information when it is no longer required.

13. Your Choices and Deletion Rights

Depending on the feature and platform, you may:

  • Deny or revoke location permission;
  • Deny or revoke notification permission;
  • Use foreground location without granting background location where supported;
  • Use a Production build without optional analytics by declining the prompt or turning it off later; the Production operational check-in remains required until you uninstall;
  • Decline a tester disclosure and not enter the Internal, Closed, Open or External testing build;
  • Withdraw from required tester collection by leaving the applicable testing programme and uninstalling its testing build, which stops future collection;
  • Save persona answers locally without sharing them;
  • End a sharing session when using an internal or external testing feature that provides one;
  • Delete local Trips or History records;
  • In an external beta build, choose “Deactivate beta account” to block sign-in while retaining the account and beta data;
  • Choose “Delete account permanently” to erase the optional account and raw account-linked server data;
  • Sign out to stop future account synchronization from that session;
  • Open the Application’s “Delete account & data” page;
  • Uninstall the Application;
  • Contact us to ask about, correct or request deletion of server-side information.

Some server-side information may be associated only with a random installation identifier rather than your name. We may need reasonable information from you to locate the relevant records.

A deletion request may not apply to the minimum information that we are legally required to retain, information temporarily restricted for a documented security, fraud-prevention, or legal-claim purpose, or information that was already irreversibly de-identified before the request.

14. Security

MetroPing uses reasonable technical and organizational safeguards intended to protect information against unauthorized access, alteration, disclosure or destruction.

Network-connected MetroPing services should use encrypted HTTPS connections. Service providers may apply additional access controls, authentication, monitoring and infrastructure protections.

No electronic storage or transmission system can be guaranteed to be completely secure. You should protect your device, account credentials, verification codes, and any testing-only sharing codes.

15. Children’s Privacy

MetroPing is not directed toward children under the age of 13, or a higher minimum age where required by local law.

We do not knowingly use the Application to solicit personal information from children for advertising. If you are a parent or guardian and believe a child has submitted personal information to MetroPing without appropriate permission, contact us so that we can investigate and delete the information where required.

Students may use local transit features, but optional account creation and other network-connected features should be used with appropriate consent and supervision where legally required.

16. Third-Party Links and Other Applications

MetroPing contains links to websites, application-store pages, support pages, privacy pages or other applications.

MetroPing is not responsible for the privacy practices of an external service after you leave the Application. Review the external service’s privacy policy before providing information.

17. Changes to This Privacy Policy

We may update this Privacy Policy when MetroPing’s features, service providers, legal requirements or information practices change.

The updated policy will show a revised effective date. Where a change introduces a new material collection or use that requires consent, MetroPing will request the appropriate permission rather than treating changed use alone as consent.

18. Contact Us

For privacy questions, support requests, account deletion or data-deletion requests, contact:

Email: business24guru@gmail.com

Please include enough information for us to understand and process your request, but do not send passwords, verification codes or unnecessary sensitive information.