Privacy Policy

Live it UP ("we", "our", or "us") is committed to protecting your privacy. This Privacy Policy explains how our mobile application and related web services collect, use, and safeguard your information when you use our services.

1. Information We Collect

Device Location: When permitted, we collect approximate location data from your device — never a precise position, and never in the background — to calculate distance, estimate flight and travel costs to concert venues, and display relevant local events — and, only if you switch on “Share usage data”, to record the two‑letter region described in section 4. You may refuse or revoke location permissions at any time and select a manual departure city instead.

Device and Usage Information: The app sends a currency code, which may be derived from your device's regional settings, so that prices can be shown in your own money, and a version header, which the server requires on the app’s requests. It does not send your device language, your operating system version, or any diagnostic data.

Favorites and Preferences: Your saved favorite artists and search settings are stored locally on your device (using on-device storage) and are not linked to your personal identity.

What you type into search: an artist name you search for is sent to our server to be looked up, and, when we do not already have the answer, our server passes that text on to MusicBrainz, the open music database we identify artists against, so MusicBrainz sees the words you typed — not your IP address, because the request is ours rather than your phone’s. Our server also keeps the normalised text of that lookup in a cache so the next person asking the same thing costs no upstream call. Nothing identifying you is stored beside it — there are no accounts and no device identifier — but the text itself does leave your phone, and a policy that only said your settings stay local left that unsaid.

Launch notification list (website only): If you submit the Android waitlist form (the "Notify me" button) on our website, we store the email address you enter and the platform, which is always Android (earlier sign-ups could also choose iOS). We store nothing else in that record except an internal id and the time you signed up — no name and no browser fingerprint. Your IP address is not stored with it, and we do not join the two; but so that a script cannot flood the form or the API, our server keeps a short-lived rate-limiting counter keyed on the caller's IP address, deleted by an hourly clean‑up once 24 hours have passed since the last request from it. Beyond that key, the counter holds only a number and a timestamp. The lawful basis for the list is your consent, given by submitting that form; the counter rests on our legitimate interest in keeping the service available, and applies to every request, whether or not you submit anything.

We use that address for exactly one message: a single email when the Android app is released. We do not add you to a newsletter, we do not share the list, and we delete your entry as soon as you ask. Once the launch email has gone out, the whole list is deleted with it — that is a thing we do, by hand, not a scheduled job. To be removed at any time, email partner@liveitup.events.

This list is collected by the website. The mobile application itself does not ask for or transmit an email address.

Shared shows: The app's Share button hands a message and a link to your phone's own share sheet. You choose who receives it and can edit it first; it names the show and, when it carries a flight price, the city the estimate starts from. Nothing is sent to our server when you share. A shared link (liveitup.events/e/…) opens a page our server builds from its own listing of that show: who plays, where and when. Opening it sends our server the show's id and, as every request does, your IP address, which reaches only the rate‑limiting counter described above, and your browser's user‑agent string, which is read only to choose what the page's button offers — Google Play, or the launch form on an iPhone and until the app is on Google Play — and is not stored. The page sets no cookies, runs no scripts and loads nothing from anyone else. When the show has not started it can also list the show’s ticket sellers as plain links, one per listing. Nothing is loaded from a seller until you tap one; the seller then sees your IP address and that the visit came from our page, and has its own privacy policy. We record nothing about the tap. When its button offers Google Play, it adds a tag to the store link saying that the visit came from a shared page and, when the page shows a show, which one, so Google Play's reports can count the store visits that came from shared pages. On the first launch after you install, the app reads that tag once, on your phone, to open the show it names — unless the app was opened from a link, which it opens instead — and keeps a note there that the first launch has passed, so the tag is never read again. It does not send the tag anywhere, and opening the show asks our server for it as any other show does.

The map on our website: The page liveitup.events/map shows what is on today and in the next two days on a map. It asks our server for the list of shows (whether you choose today or today and the next two days, and nothing else), and your browser then fetches the map — the style, the tiles, the lettering and the symbols — from our own server too. The base map is built from OpenStreetMap data and served by us, so no third party sees your visit, your IP address or which part of the world you are looking at. The map library is served from our own site and nothing else on the page comes from anyone else. The page asks for no location, sets no cookies, keeps nothing in your browser, runs no analytics and records no clicks. Opening a show takes you to its page on our site (see “Shared shows”). Some pins are announcements that ticket sellers publish (Shotgun, Showpass or Megatix) rather than shows in the app: we keep each one’s title, venue, date and ticket link while the seller lists it and for at most three days after, and opening one takes you to its page on our site (liveitup.events/a/…), which like a shared show runs no scripts and sets no cookies, shows the seller’s link as a plain link, loads nothing from the seller until you tap it, and records nothing about the tap. Our server sees the requests like any web server does. The lawful basis is our legitimate interest in showing you the map you asked for.

2. Third-Party Data & Affiliate Links

Our app aggregates event, ticket, and flight information from third-party SOURCES (Ticketmaster, Showpass, Shotgun, Megatix, MusicBrainz, setlist.fm and Travelpayouts) and, where the app offers a price for a ground transfer, gets that price from GetTransfer, only when you tap for it. Our server contacts all of those. Some requests go from your phone directly to other parties, and none of them is in that list. When you search for a departure city in Settings, the text you type is sent to Open-Meteo's geocoding service to turn it into a place, so Open-Meteo sees that request and your IP address. When an event page shows a map, the first version of the app (1.0) fetches the tiles from MapTiler — those tiles cover the venue, never your own position, so what MapTiler sees is your IP address and which venue you opened. Later versions show instead a picture of the venue's surroundings that we make from OpenStreetMap data and serve from our own server, so no third party sees that request. Tapping the © OpenStreetMap credit on the picture opens openstreetmap.org in your browser. When you tap a flight link, your browser opens Aviasales with the departure and destination codes, the date and our affiliate marker in its address, so Aviasales sees those and your IP address. And to name the city you are in, the app asks your phone’s own location service, which your operating system provides. Everything else goes through our server, which sends the airline search two three-letter codes for metro areas — one for where your trip starts, and one for the venue’s or, when the venue’s airport is a small one with no fare near the date, a larger city within reach — the month of the show (and the month before, for a show in the first days of a month), and the currency we ask prices in: the euro, or your own currency when we cannot convert to it. Never your position: the starting code is the metro area of the airport our server matches to your starting point (the nearest one, or a main airport a little further out), and that starting point is the phone’s approximate location or the city you chose in Settings.

When our server asks Ticketmaster and Showpass for events near you, it sends the centre of a map square around your position, rounded to between about 1 and 11 km depending on how far you are looking, with a radius — never your exact position; Megatix is only asked about its own venues near that centre. When our server asks LiteAPI for a hotel price near a venue, it sends the venue’s coordinates, the night of the show, the same currency code, an occupancy of two adults and a two-letter nationality — the country of your departure airport, or US when the trip has none — nothing that identifies you or your phone.

What our server sends GetTransfer for a ground-transfer price is the coordinates of the pickup airport and of the venue, an assumed pickup date and time, the currency you see prices in and a passenger count of one — nothing that identifies you or your phone, and, because our server sends it, not your IP address. The pickup airport is the one the trip card measures the transfer from: the airport we match to the venue from the venue’s location alone (the nearest one, or a larger or main airport not much further away), or, when that airport is a small one with no fare from your departure city near the show date, a large airport in another city that we hold a fare to — so that choice can reflect where you fly from. Your own position is never sent.

When you click outbound links to purchase tickets or book travel:

• You will be redirected to the official third-party website or app.
• These third-party platforms have their own independent privacy policies and terms of service.
• We may receive affiliate attribution parameters to earn referral commissions when an order is completed.

3. How We Use Information

We use the collected information to:

• Provide concert schedules, price ranges, and travel cost estimates. They are served from a cache, so a figure can be hours old, and some days old when a source has not answered or published since; the app says when it is estimating rather than quoting. A ground-transfer price, where the app offers one, is the exception: it is requested only when you tap for it, it is never served from a cache, and it is stored neither by our server nor on your phone — the app shows it for at most five minutes and then asks you to tap again.
• Maintain, monitor, and optimize backend server performance.
• Comply with legal obligations and protect against fraudulent activity.
• Only if you switch on “Share usage data”: learn which kinds of outbound links are opened, as described in section 4.

4. Data Retention and Security

We implement standard industry encryption (HTTPS/TLS) for all data in transit. We do not sell, rent, or trade your personal data to third parties. Your exact position is never stored, and nothing we keep carries an account or a device identifier — there are no accounts, no device id and no advertising id. What we do keep, and it is worth stating plainly, is the artist‑search cache described above and three more caches — each of which exists so that the next person asking the same question costs no upstream call — the rate‑limiting counter described above, and, only with your consent, the outbound‑link record described below. The nearby feed stores its results against a coarse grid square — your coordinates rounded to about eleven kilometres at the fifty-kilometre radius the app asks for — for twelve hours. Flight fares are stored against the two airport codes and the month, never a date and never a position: an airport code is a metro area. Accommodation rates, where the app shows one, are stored against the venue's coordinates rounded to about a kilometre with the two dates of the stay — the venue's position, which is public, not yours. The last two expire after twelve hours as well. Everyone asking the same question shares one row in each, which is the point: a row that serves everybody cannot be traced back to anybody, even by us.

And since September 2026, one thing more, only if you switch it on. In Settings, under Privacy & Data, there is a control called “Share usage data”. It is off when you install the app and nothing below happens until you turn it on. With it on, when you open a ticket, flight or airport‑transfer link — a ticket seller’s page, a flight search, a transfer booking — the app sends us one record: which kind of link it was, which ticket source or travel programme it goes through, which screen you were on, which event, the event’s country, and how the app placed you — from your phone’s location, from a city you typed, or not at all. Only when your phone’s location placed you does the record also carry a two‑letter code for your region — the country your position resolves to, or, when that lookup fails, the country of the nearest city the app knows, which can be another country, even on another continent: never the position itself, never taken from a city you typed, and never from your phone’s language settings. If you choose No Location in Settings, no region is recorded at all. If you switch location off on the phone itself, the app may keep using the last position it had until it next asks the phone, which may not be until the app is restarted.

That record carries no account, no device identifier, no advertising identifier, no session, no IP address and no coordinates, so nothing in it points at a person or a device. Its time is stored only to the hour in which our server received it, so it cannot be matched to anything else by its exact time; records are still kept in the order they arrived, and taps in the same hour share it. Your IP address reaches our server with the request, as it does with every request the app makes, and is kept apart from the record, in the rate‑limiting counter described above, until an hourly clean‑up finds that 24 hours have passed since the last request from it; until then, a single tap in a quiet hour could be lined up with that counter by its hour. Nothing we run makes that match. Because no record carries an identifier, there is no record we could find by who you are and delete on request; instead every record is deleted after 90 days, by a job that runs daily; if the job cannot complete that for a month, that month’s records wait, and the job reports it as a failure until they are dealt with. Before that, once a month is over, its records are added into monthly counts — how many links of each kind were opened, by ticket source or travel programme, screen, the event’s country, the two‑letter region and how the app placed the reader. The counts keep no event and no time finer than the month, and we keep them with no deletion date; they are what lets us say, a year from now, how many times a partner’s links were opened. You can stop new records being sent at any time with the same control that started them. Turning it off stops new records; it does not erase the ones already written — those are deleted on the same 90‑day schedule as the rest, and are added to the monthly counts like every other record.

Why we ask at all: we are paid a commission when somebody books through some of those links, and without this we cannot tell which of them anybody uses. It is the difference between guessing what to build next and knowing.

Backups. Once a day our server makes a copy of its database, encrypts it before it leaves the server, and stores it with our hosting provider, nic.ua, a Ukrainian company. The key that opens these copies is kept neither on our server nor at nic.ua. Each copy is deleted once it is 30 days old, by the same daily job; if that job cannot run, the older copies wait until it does, and the job reports it as a failure. Our provider also keeps its own backups of its servers for a period it sets, so an encrypted copy we have deleted can remain in them for that long. A copy holds everything in the live database except the rate‑limiting counter and the caches described above, so those are never kept longer than stated here; anything else deleted from the live database — a launch‑list address you asked us to remove, a usage record past its 90 days — can remain inside an encrypted copy until that copy is deleted. If we ever have to restore a copy, we repeat the deletion requests we have received since that copy was made.

5. Data Deletion & User Control

Live it UP does not require user registration and maintains no personal user accounts. Your favorite artists, your list of recent searches, and your departure settings are stored on your device (via AsyncStorage) and are deleted with the app. What does reach our server, and what of it is kept, is set out in sections 1 and 4.

The first of three exceptions, and it lives on our servers: if you submitted the Android waitlist form (or its earlier "Notify me at launch" version) on our website, we hold the email address and platform you gave us, as described in section 1. To have that entry deleted at any time, email partner@liveitup.events and we will remove it. It goes from our live database at once, and from the encrypted backups described in section 4 as they expire. The whole list is deleted once the launch email has been sent.

The second, and for this one there is nothing we could delete on request even if you asked. If you switched on “Share usage data” in Settings, we hold a record for each outbound link you opened — described in full in section 4. Those records carry no account, no device identifier, no advertising identifier, no session, no IP address and no coordinates, so there is no field by which we could find the ones that came from you. What you can do instead is switch the control off, which stops new records immediately, and every existing record is deleted after 90 days by a job that runs daily; what remains after that is the monthly counts described in section 4, which hold no event and no time finer than the month. If you would rather none had ever been written, the control was off until you turned it on.

A third lasts about a day: the rate‑limiting counter described in section 1, keyed on your IP address and deleted by an hourly clean‑up once 24 hours have passed since your last request. Beyond that key it holds only a number and a timestamp, and there is nothing to ask us to delete, because it deletes itself.

You can delete all stored data at any time by:

• Removing individual artists from your Favorites screen in the app.
• Clearing application storage in your device settings (Android Settings → Apps → Live it UP → Storage & Cache → Clear Storage, or deleting/reinstalling the app on iOS).
• Uninstalling the mobile application.

When you email us. Mail sent to partner@liveitup.events stays in that mailbox and is also stored in our database — your address, the name your mail program sends, the subject and the text — and its sender, subject and first lines are passed to our team's Telegram chat so that someone sees it quickly. Nothing deletes these messages automatically: we keep them until we delete them. When you ask, we delete your messages from the mailbox and the database as soon as we can, and their copies in the encrypted backups described in section 4 go as those expire; the notification in our Telegram chat stays there. The exception is a request to delete your data: it is the record we repeat if we ever restore a backup, so we keep it at least until every backup made before it has expired.

For any privacy or data inquiries, you may also email us at partner@liveitup.events.

6. Contact Us

If you have any questions or requests regarding this Privacy Policy or our practices, please contact us at partner@liveitup.events.