Privacy Policy — YatriK Rail

Version 2.9 · in effect from 27 October 2026
What changed, and when

YatriK Rail ("the app," "we," "us") is operated by Cloudnbots Solutions, a sole proprietorship owned by Kumar Prabhakar ("the developer"). This policy explains what data the app collects, why, and how it's handled.

YatriK Rail is a companion app for Indian Railways travel — PNR status, live train tracking, and station/route search. It is not affiliated with, endorsed by, or operated by Indian Railways, IRCTC, or any Indian government body.

1. What we collect

Information you provide directly

• PNR numbers you enter to check booking status. We send the PNR to our data provider to fetch the official status; we never store or log the PNR itself on our servers.
• Survey responses if you vote in an in-app poll.

Information saved on your device

When you check a PNR, the journey details returned (train number/name, stations, date, class, chart status, quota, and per-passenger booking status/coach/berth/quota/nationality/food preference — never passenger names, which the official data source doesn't provide to us) are saved on your device in encrypted local storage, so you can see your saved trips later. With one stated exception, this stays on your device — we don't keep a copy on our servers. The exception is the travel class, described under "Information collected automatically" below: we keep a count of it, and nothing else from the booking. It's deleted if you remove the trip in the app, or if you uninstall the app.

Information collected automatically

• A random device identifier — generated on first use, stored only on your device, not linked to your name, email, or phone number. Used to apply fair usage limits, avoid duplicate poll votes, and understand which features and routes are actually used.
• Approximate location (city/region only) — derived from your IP address by our hosting provider. The app does not currently request GPS location — see "Planned features" below for a future, entirely opt-in exception. Used to show regionally relevant content (e.g., a Mumbai-specific survey) and in aggregate usage statistics.
• IP address — inherently visible to our servers while handling your requests, as with any online service. Logged specifically when a request is blocked or rate-limited, to help us investigate abuse.
• Which trains, routes, and stations are looked up — tied to your device identifier, not your identity, used to understand what's popular so we can improve the app.
• How many tries a search took — if finding a train or station takes you more than one attempt, we keep the train or station you ended up finding, how many attempts it took, and how many of those attempts were spoken rather than typed. For this record, not one word you spoke or typed is stored — it keeps only how many goes a name needed, never what the microphone heard. (Separately, and only when a search matches nothing at all, we keep the words themselves — see the next point.) It is kept with no device identifier, so it is a count against a station name and not a record of your searching. For the PNR field we keep only that it took more than one attempt; the PNR itself is never stored. It exists so we can find the names our search and our voice input handle badly, and fix them.
• Searches that found nothing, and requests we could not understand — when you look for a train or a station and we have no match at all, or you ask Ask Yatrik something it cannot make sense of, we keep the words you typed or spoke, the day, and a count of how many times anyone sent them. Only when we failed: if we found your train, or understood your request, the words are not kept. There is no device identifier, so two people searching the same thing are one number and not two records — and because the search matched nothing, it names no train, station or journey. A PNR can never appear here: this is written only from the train and station search boxes, which a PNR is never typed into. It exists for one reason — speech recognition mishears Indian railway names, and the only way we can correct a word is to know it came back wrong.
• An anonymous, device-level usage profile — built from the same lookups above (e.g., whether you mostly look up local or long-distance trains, how often, and your general region), used to make in-app content like surveys more relevant and to guide what we build next. Never tied to your name or identity, and never shared outside the uses described in this policy.
• When you report how crowded a train is — this is the only thing in this app that uses your location, and it is optional: nothing happens unless you tap to report. When you do, we take one reading, at that moment, while the app is open, to check you are really on that train — a number anyone could type is worth nothing. Android will call this a “precise” location permission, and that is accurate: we need a precise fix to tell which stop you are nearest, because stops can be only a few kilometres apart. Your exact position never reaches us. Your phone works out which stop you are nearest, how far along you are and how accurate the reading was, and sends only that. We store your report — the train, the date, that stop, the hour, how crowded you said it was, and the coach you picked — against a one-way code made from your device identifier, the train and the date together. That code cannot be turned back into your device, and a different journey makes a different code, so your reports cannot be joined into a trail of where you travel. Reports are kept 90 days. We never ask for background or always-on location, and we do not record your location at any other time.
• Which travel class you book — when you check a PNR, we read one field from the result, the class (for example 3A or SL), and keep a running count of it against your device identifier. Nothing else from that result reaches our servers: not the PNR number, not any passenger, not a coach or berth. The count tells us whether this device books mostly premium, mid or budget travel, which is used to choose which in-app content and ads to show.
• A single "home city" for your device — worked out from the approximate location above, as the city your device is seen in on the most separate days over the last month. It lets an advertiser reach people who live in a place, or people who are visiting it. We do not keep a history of where your device has been: this is one city, overwritten when it changes, and it is recalculated at most once a week.
• How long an ad was on your screen — a duration in seconds, recorded against the ad slot, not against what you were reading. It exists so we can tell an advertiser whether a placement holds attention long enough for a video or only for a still image. It is not a record of how long you used the app, and it is not tied to any particular screen’s content.
• Ad topic preferences, if you set them — the categories you pick yourself in the app are stored against your device identifier so the ads you see can follow them, and they expire on their own after a set period. We never infer categories about you; you either choose them or there are none. Health, religion, political and financial-situation categories are refused outright.
• Smart alert settings, if you set one — the train, station, and timing you chose, tied to your device identifier so we can check that train's status and notify you. Deleted when you cancel the alert.
• Crash reports — if the app crashes, we receive a technical report (what happened, device/OS info) via Firebase Crashlytics, to help us fix bugs. No personal data is deliberately included in these reports.
• Basic app usage (screen views) — via Firebase Analytics, to understand how the app is used overall.
• A push-notification token, once notification permission is granted or requested — see "Notifications" below for an important detail on what declining actually does and doesn't do.

What we do NOT collect

We do not collect your name, phone number, email address, precise GPS location, payment/financial information, contacts, or photos. There is no account or login system — nothing in the app is tied to a real-world identity.

2. Notifications — an important detail

Notifications now have a real, visible purpose: Smart alerts, which you set explicitly on a train, notify you as its live status changes. If you decline the notification permission, you won't receive these — including any alert you've already set — and the app will not show you visible notifications of any kind. However, declining does not prevent your device from being registered to receive silent, invisible messages (used for a background technical check that confirms the app installation is genuine, not for anything visible to you). If you want to stop this entirely, you can disable it from your phone's system settings for the app, or uninstall the app.

3. Who we share data with

• Our data providers (for PNR status, live train tracking, and station/route information) — receive the specific PNR number or train/station identifiers needed to answer your request. They do not receive your device identifier or any other data about you.
• Google Firebase (Analytics, Crashlytics, Remote Config, App Check, Cloud Messaging) — standard infrastructure services; Google processes the data described above (crash reports, usage analytics, push tokens) under its own data-handling terms.
• Cloudflare — our hosting and content-delivery provider; as with any hosted service, it inherently processes network traffic (including IP addresses) to deliver our service.
• Advertising networks (e.g., Google AdMob, and potentially direct advertising partners) — see "Planned features" below. Not yet active as of this policy's last update; disclosed here in advance so the policy doesn't need a surprise rewrite the day it launches.

We do not sell your data, and we do not share data with anyone for their own independent marketing purposes beyond what's described in this policy.

3b. Advertising — live

This is no longer a planned feature. The Google AdMob SDK is built into the app and the slot on the home screen is live. Ads shown there may come from AdMob or from campaigns we run ourselves.

When AdMob serves an ad, Google may collect an advertising identifier, approximate location and app usage data to select and measure it, under Google's own privacy policy rather than this one. When we serve our own campaign, the choice is made on our servers from the device-level signals listed in section 1 — approximate location, the home city described in section 1, whether the device books mostly premium, mid or budget travel, local versus long-distance usage, and any ad topics you picked yourself. No advertiser receives your device identifier, your journeys, or anything else about you; they receive counts of how their ads performed.

You can see why an ad was chosen, and set or clear your ad topics, from the small information button beside the ad.

4. Planned features (disclosed in advance)

The item below is not live yet. We're describing them now, before they ship, so this policy stays accurate on day one rather than needing an update the moment they do — this section will be revised to reflect reality once either actually launches (and the "not live yet" language removed at that point).

Optional, consented location sharing for live crowdsourced train tracking. We're planning a future feature where you can choose to share your live GPS location while tracking a specific train, to help build a more accurate, crowdsourced picture of train positions and locals crowding for other users — similar in spirit to how some of our own train-position data is itself already crowdsourced by our data providers. This will always be opt-in per session, off by default, and limited to the specific journey you enable it for — the app does not request background or always-on location access, and does not currently request any location permission at all. When this ships, this section will describe exactly what's collected, for how long, and how you can review or revoke access at any time.

5. How long we keep data

• Data saved on your device (trips, device identifier) stays until you delete it or uninstall the app.
• Data on our servers tied to your device identifier is deleted automatically on the following schedule, by a job that runs once a day:
  • Security logs (records of blocked or rate-limited requests, including the IP address involved): 180 days.
  • Lookup counts (how often each train, route or station was looked up — not who looked it up): kept as daily totals with no device identifier. The per-device lookup history this replaced on 4 October 2026 is no longer recorded, and the last of it is deleted within 180 days.
  • Ad and survey interaction records (impressions, clicks, poll votes): 400 days — kept longer because advertisers may need to audit the figures we report to them.
  • How many tries a search took (a station or train name, a count of attempts, and a day — no device identifier and no text you entered): 180 days.
  • Which search words we could not answer (the words, two counts and a date — no device identifier, so two people typing the same word are one row): 180 days. It stops us asking our data provider the same unanswerable thing over and over.
  • Searches that found nothing, and requests we could not understand (the words, a day, and a count — no device identifier): 90 days.
  • Smart alert history (alerts that have already fired or been skipped): 14 days. An alert you cancel is deleted immediately, not kept for 14 days.
  • Your device's usage profile (how many trains, routes, stations and PNRs were looked up from your device, the city and state we infer from them, and your ad topics): 400 days from the last time the app was used — the same period as the ad records above, because the two are read together when an advertiser audits the figures we reported. Using the app again keeps it current; stop using it and the whole profile is deleted.
• You don't have to wait for these periods to elapse — see "Your rights" below for how to request deletion directly.

6. Your rights

You can:

• Delete your on-device data at any time, from within the app or by uninstalling it.
• Request deletion of server-side data tied to your device by contacting us (below) — since there's no account system, we'll need you to describe what to look for (e.g., approximate dates of use); we'll remove what we can identify.
• Ask us what data we hold about your device by contacting us.

7. Children's privacy

YatriK Rail is not directed at children, and we do not knowingly collect data from children. If you believe a child has provided us data, contact us and we'll remove it.

8. Security

We use encrypted on-device storage for saved trip data, and server-side protections (rate limiting, abuse detection, and app-integrity verification) to protect the service. No method of storage or transmission is 100% secure, but we take reasonable, industry-standard steps to protect what we hold.

9. Changes to this policy

We update this policy when what we actually do changes, and we publish a new version number and effective date each time — the full record is below. A version takes effect on the day the change itself goes live, not on the day a new app version reaches the Play Store, because most of what this policy describes runs on our server and changes for everyone at once. Continued use of the app after a change means you accept the updated policy.

Change history

Every version of this policy, newest first, and what actually changed in each.

Version 2.9 — 27 October 2026

• Disclosed crowding reports, and the single location reading that confirms one. The app asks for location for the first time: once, when you tap to report, while the app is open. Your exact position never reaches us — the phone works out which stop you are nearest and sends only that. A report is stored against a one-way code made from your device identifier, the train and the date together, which cannot be turned back into your device and differs for every journey, so reports cannot be joined into a trail. Kept 90 days.

Version 2.8 — 22 October 2026

• Disclosed a new, small record: the search words we could NOT answer, with two counts and a date and NO device identifier, kept 180 days. Two people typing the same word are one row. It exists so we stop asking our data provider the same unanswerable thing over and over.

Version 2.7 — 20 October 2026

• Gave your device's usage profile an explicit retention period: 400 DAYS from the last time the app is used, deleted automatically, where before it had none. 400 days matches the ad and survey records, because an advertiser auditing the figures we reported reads the two together — a shorter period on the profile would have left us holding records we could no longer explain.
• Added the usage profile to the automatic deletion schedule in section 5, where it had been missing. ⚠ Version 2.3 said plainly that it was NOT on that schedule. That is no longer true, and this entry supersedes it.
• Confirmed that searches which found nothing, and requests we could not understand, really are deleted at 90 days. That period had always been published and NOTHING ENFORCED IT until now.

Version 2.6 — 12 October 2026

• Widened the previous entry by a few hours. Ask Yatrik can hear you clearly and still not understand, and that left no trace anywhere — it is not a search that found nothing, because no search ran. Same words, same 90 days, same absence of any device identifier, and still kept only when we failed.

Version 2.5 — 12 October 2026

• Disclosed that when a train or station search matches NOTHING AT ALL we keep the words searched, the day, and how many times anyone searched them — with no device identifier. Only searches that found nothing: if we found your train, the words are not kept. A search that matches nothing names no train, station or journey, and a PNR can never appear because this is written only from the search boxes a PNR is never typed into.
• Added because speech recognition mishears Indian railway names and we had no way to learn which words came back wrong — the record we already kept counts attempts on searches that eventually worked, and keeps no text.
• Stated the deletion schedule for those words: 90 days.

Version 2.4 — 8 October 2026

• Disclosed that when a search takes more than one attempt we keep the train or station you ended up finding, how many attempts it took, and how many of them were spoken — with no device identifier, and without storing a single word you spoke or typed. Added alongside voice input, so the disclosure and the feature ship together rather than the policy catching up afterwards.
• Stated the deletion schedule for that count: 180 days.

Version 2.3 — 2 October 2026

• Stated that we read how you found the app from the Google Play Store once, at install, and keep only which of four groups it falls into — a shared trip, an advert, a Play Store search, or anything else. The link itself is never stored.
• Said plainly that your device's usage profile is not on the automatic deletion schedule, and is kept while the device keeps using the app. That was already the case; the previous wording listed four retention periods under a heading that read as though it covered everything, and it did not.

Version 2.2 — 17 September 2026

• Stated that we measure how long an ad was on your screen. It tells advertisers whether a placement can carry a video or only a still image. It is a duration, attached to the ad — not to what you were reading, and not to anything else you did.

Version 2.1 — 17 September 2026

• Stated that we work out a single “home city” for your device — the city it is most often seen in — so that advertisers can reach people who live somewhere, or people who are visiting. It is worked out from the approximate location we already describe below, and it is one city, not a history of where you have been.

Version 2.0 — 17 September 2026

• Stated that we keep a count of which travel classes you book (from PNR checks), which we had been doing since 9 September without saying so. The class only — never a passenger, a berth, or the PNR number.
• Added the ad-category preferences you can set yourself, which are stored against your device.
• Corrected the advertising section: AdMob is integrated in the app, not merely planned.
• Started versioning this policy, with the change record you are reading.

Version 1.0 — 4 September 2026

• First published.

10. Contact us

Questions about this policy or your data: yatrikrail@gmail.com