Privacy policy

Unolink is operated by Marin Capranov (sole trader), United Kingdom. We are the controller for the account data described below. For the click analytics you collect on your own links, you decide what to link to and who sees the numbers; we process those clicks on your behalf.

When a visitor opens a Unolink redirect, we read the request’s IP address and User-Agent header in order to decide which destination to send them to and to tell real traffic from bots. Both are used in memory for the duration of that request.

The IP address is never written to a database and never written to a log. Once the request is answered it is gone. We do not operate a GeoIP database; when country and region are shown in analytics, they come from headers our CDN adds to the request.

The redirect domain sets no cookies and reads no cookies. There is no device fingerprinting, no tracking pixel and no third-party analytics script in the redirect path. A visitor receives an HTTP redirect and nothing else.

To report a rough measure of distinct traffic without identifying anyone, each click is reduced to a hash: SHA-256 over a daily secret salt, the app identifier, the IP address and the User-Agent, truncated to 16 bytes. The original inputs are discarded.

Every day has its own salt, so the same visitor’s hash on one day does not match their hash on any other day. The salts are never stored: each one is computed from a secret key that is kept only in our server’s configuration, outside the database, so neither the database nor its backups contain them. This is why the metric is labelled “Unique visits (daily)” rather than “People”: it cannot follow anyone over time, and it is not a count of individuals.

For each click we retain the link it used, a timestamp, the classified platform, operating system, browser and device type, whether it looked like a bot, the referrer and any UTM parameters present on the URL, and the coarse location described above. On its own, a click record carries no identifier that persists beyond the day. If the visit leads to an install of an app that uses the Unolink SDK, that install’s record keeps which link and campaign it came from (see below). Click records are deleted after 13 months, and clicks from bots (such as link previews) after 30 days.

If the developer shows a landing page on a link, the page is served from our domain with no third-party scripts, fonts or cookies. Its images (uploaded by the developer or copied from the app’s App Store listing) are re-encoded by us, with any embedded metadata such as camera or location data removed, and served from our domain. When the developer deletes an image, we remove it immediately; copies held by our CDN expire within a day. If the visitor taps a store button on it, we also record when and which store, on the same click.

A click is never treated as, or reported as, an app install.

Developers can add the Unolink SDK to their app. For the people who use that app, the developer is the controller and we process the data on their behalf. The SDK does not read advertising identifiers, does not fingerprint devices, and does not use Apple’s App Tracking Transparency.

On first open the SDK creates a random install ID that identifies no person or device, and sends the platform, operating system and app version, device class (phone or tablet), language setting and, on Android, the referrer Google Play passes to the app. Country comes from our CDN’s header; the IP address is used in memory only and never stored. After that the SDK sends the events the app reports, such as onboarding completed, paywall viewed, sign-up, trial and purchase, with any properties and amounts the developer attaches, plus automatic first-open, session and background events.

If the app sets a user ID, we store only a one-way keyed hash of it (HMAC-SHA256 with a key per app), never the ID itself. Each app’s key is stored encrypted, and the keys that decrypt it are themselves encrypted with a certificate kept only in our server’s configuration, so the database or a backup alone cannot be used to compute these hashes. If the developer connects RevenueCat, RevenueCat sends us purchase, trial, renewal and refund events for that app, which we match to the install by the same hash. Test builds are marked as test data. App events, including purchase events from RevenueCat, are deleted after 13 months. The install record itself (the random install ID, the details sent on first open, the link and campaign it came from, and the hashed user ID) is kept until the developer deletes the app or their account, and is deleted with it.

Apple does not tell iPhone apps which link someone tapped before installing. Unless the developer switches it off, we match an iPhone install to a link click using only data described on this page that we already hold for analytics. We never use device details, the IP address or advertising identifiers for this, and the match is never sent to the app.

If you create an account we store your email address, a password hash (or, if you sign in with Google, the identifier Google gives us for your account), and the apps, links, QR codes and settings you create. If you subscribe, we store your Stripe customer reference and your plan and its status; card details go directly to Stripe and never reach us.

We send emails about your account: confirming your address, resetting your password, and warning you before anything on your plan pauses (a plan change, the end of the 14 days after a downgrade, the monthly SDK event allowance). We also send a short welcome and, if an app’s SDK hasn’t sent anything a few days after you made its key, one note about it; you can turn these tips off in Settings. We do not send marketing emails.

Signing in sets two strictly necessary cookies: a short-lived session token and a refresh token, both inaccessible to page scripts. If you pick a language, a cookie remembers it so pages open in that language. Your light or dark theme choice, and a few dashboard preferences such as unsaved drafts, are kept in your browser’s local storage. There are no analytics or advertising cookies. The live chat sets its own cookies, but only after you open it (see below). The round cookie button at the bottom of the page lists all of this.

The sign-up, login and password-reset forms are protected by Cloudflare Turnstile, which checks your browser for signs of automation so that bots can’t create accounts or guess passwords.

Our website and dashboard offer a live chat run by Crisp (Crisp IM SAS, France). Nothing from Crisp loads until you click the chat button or “Chat with us”: it doesn’t load by itself, and never on links, landing pages or developer pages. When you open it, Crisp receives your IP address and browser details, and stores cookies and local storage in your browser so the conversation continues across pages and visits. If you write to us, Crisp stores your messages, and in the dashboard also your account email address and the ID of the app you were viewing, so we can answer. We use these conversations only to help you. “Forget the chat” in the cookie panel removes Crisp’s cookies from your browser, and you can ask us at any time to delete the conversations.

Account data, apps, links and settings are kept for as long as your account exists. Click records and app events are deleted automatically after 13 months, and clicks from bots after 30 days, so analytics go back 13 months at most. When you delete an app, we keep only a one-way hash of its SDK keys and the app’s name, plus the time and platform (iOS or Android) of the last request made with those keys, for 90 days and with no data about anyone, solely to tell you when an old build of the app still sends data with them; deleting your account removes this at once. When you delete your account, from Settings in the dashboard, it is removed immediately, together with everything under it, and any subscription is cancelled.

We keep database backups for disaster recovery: daily copies on our server for 14 days, readable only by its administrator, and an encrypted off-site copy for 90 days. Deleted data disappears from backups as they expire. Payment records are kept by Stripe for as long as tax and accounting law requires.

We use a small number of providers, each only for the purpose listed:

• Hetzner Online (Germany): the server and database that run Unolink.
• Cloudflare: DNS, CDN and network protection, visitor country headers, and Turnstile.
• Stripe: payments and subscription billing.
• Resend: delivery of account emails.
• Google: “Sign in with Google” if you choose it, and storage of our encrypted backups.
• Sentry: error reports, which can include your account ID or email address when an error concerns your account.
• Crisp: the live chat on our website and dashboard, and the messages you send through it.

Some of these providers process data outside the UK and the EEA; they do so under their data processing terms. We do not sell data, and we do not share click data with advertising networks.

You can access and correct your account data in the dashboard, delete your account at any time from Settings, and ask us for a copy of your data or about anything on this page. Because click records contain no stable identifier for a visitor, we cannot locate or delete the records of an individual visitor on request: there is nothing in them that could be used to find them. For people who use an app with the Unolink SDK, an install, with the link and campaign it came from, can be found by its install ID or by the user ID the app sets; the app’s developer, as controller, handles those requests.

If you think we have handled your data wrongly, please tell us first. You can also complain to the Information Commissioner’s Office (ICO) at ico.org.uk.

For anything on this page, write to [email protected].