Privacy Policy

The short version

• We never store a short-link visitor’s IP address. It is absent from click data and redirect logs, and exists only while we compute the privacy-preserving values described below.
• We set no tracking cookie, no visitor token, and no identifier of any kind that follows you between links or between sites.
• We deliberately cannot tell whether the same person clicked two different links, or whether the person who clicked today is the person who clicked yesterday. That is a property of how the system is built, not a promise about how we behave.
• We do not sell or share personal information, and we run no advertising or third-party analytics on the redirect path.

Information customers give us

When you create an account we store your name, your email address, and—depending on how you sign in—a one-way hash of your password or the public credentials for your passkey. We never store a password in a form we can read. If you create API keys for programmatic or MCP access, we store a hash of each key alongside its label.

When you sign in, our authentication system stores the IP address and user-agent associated with the session. We use them to secure customer accounts and prevent abuse. This is customer session data; it is not recorded for visitors who follow short links.

An organization record holds its name, its subdomain slug, its members and their roles, its pending invitations, and its timezone. The timezone is not cosmetic: it determines the day boundary used throughout the analytics described below.

Information about your links

For each link we store the destination URL, its slugs, any name you give it, and any UTM or additional query parameters you configure for us to attach on redirect. We also store the settings you choose: expiration time, click cap, and—for password-protected links—a one-way hash of the password.

Where URL safety screening is enabled, we send the destination URL to Google Safe Browsing when a link is created or its destination changes and cache the result for twenty-four hours. Google does not receive click rows or visitor fingerprints as part of that check.

What a redirect records

When someone clicks a short link, we write one row describing that click. That row contains exactly the following, and nothing else:

• the time of the click;
• which link and alias was clicked, and which organization owns it;
• an approximate location—country, region, and city—which our hosting provider derives from the request at its edge and passes to us as request headers. We receive the place, not the address it was derived from;
• the referring URL, if your browser sent one, and the user-agent string your browser sent;
• a 16-byte visitor fingerprint, described in the next section.

Your IP address is not in that list, and never will be. We read it from the incoming request to do two things—compute the fingerprint below, and enforce a per-IP rate limit so a single source cannot flood a link—and in both cases it is transformed into a keyed one-way hash before it leaves the scope of the function that read it. The rate limiter stores the hash, not the address. Redirect handling does not log the raw address.

How the visitor fingerprint works

To report how many distinct visitors a link received, rather than only a raw click count, we need something that repeats when the same person clicks twice. We use a fingerprint that is built to repeat in exactly one narrow circumstance and to be uncorrelatable everywhere else.

The construction, precisely:

• We derive a daily salt by taking an HMAC-SHA256 of the current calendar date—in the timezone of the organization that owns the link—under a secret key that is never exposed.
• We then take an HMAC-SHA256 of your IP address, your user-agent string, and the identifier of the specific link, keyed by that daily salt, and keep the first 16 bytes.

Two consequences follow, and they are the entire point:

• Per link. Because the link identifier is an input, the same person clicking two different links produces two values with no discoverable relationship. We cannot answer “did this visitor also visit that other link?”
• Per day. Because the salt rotates at the owning organization’s local midnight, the same person clicking the same link on two days also produces two unrelated values. We cannot answer “did this visitor come back?”

We do not store the source IP address or a lookup table mapping fingerprints back to visitors. Because the link and day are cryptographically part of the computation, stored fingerprints from different links or days cannot be matched directly to one another. We use the secret only to create fingerprints during redirect handling; we do not use it to test candidate addresses or reconstruct visitor activity.

What “unique visitors” means here

Because the fingerprint is rebuilt each day, a unique-visitor count over any window longer than a day is a sum of daily uniques—visitor-days, not people. Someone who clicks the same link on three different days counts three times. Someone who clicks either side of the organization’s local midnight counts twice. We label these numbers as rolling windows rather than as distinct-person counts, and customers should read and report them the same way.

This is a real cost of the design, and we accept it. Producing an accurate count of distinct people over a month would require an identifier that persists across days, which is precisely the thing we have chosen not to have.

Cookies

We set no cookie when you click a short link, and we run no advertising network, no third-party analytics, and no social pixels on the redirect path. Redirect measurement uses only the per-request fingerprint above, which is not stored on your device.

Two cookies exist on the service, and both are functional:

• A session cookie, set only after a customer signs in, which keeps that customer signed in.
• An unlock cookie, set only when a visitor enters the correct password for a password-protected link. It lasts fifteen minutes, applies to that one link alias, and holds a signed proof that the password was entered plus the time it stops being valid. It contains no identifier for you and cannot be read as one.

How we use information

We use customer account information to operate the service, authenticate you, respond to support requests, and send transactional email such as verification, password resets, and organization invitations. We use click data to produce the analytics shown to the organization that owns the link, and in aggregate to keep the service running and to detect abuse.

We do not sell personal information, and we do not share it for cross-context behavioral advertising. We do not sell click data in any form, aggregated or otherwise.

Who we share information with

We disclose information to service providers who process it on our behalf, under contract, and only to deliver the service: our hosting and content-delivery provider, our database host, the provider that backs our rate limiting, our transactional email provider, and Google Safe Browsing when URL safety screening is enabled. Google receives a destination URL for that check, but not click rows or visitor fingerprints. Click rows never leave our database for these purposes; the rate limiter receives only a keyed hash of an IP address, as described above.

We may also disclose information if required by law, to enforce our Terms of Service or Acceptable Use Policy, or to protect the rights and safety of others. If we are ever compelled to produce click data, what exists to produce is what is listed under what a redirect records— there is no IP log to hand over.

If we are involved in a merger, acquisition, or sale of assets, we will give notice before personal information becomes subject to a different policy.

Retention and deletion

Click rows are deleted when the alias, link, or organization they belong to is deleted—the deletion cascades, so removing a link removes its click history with it. We also keep daily aggregate rollups, which contain counts rather than individual clicks and follow the same deletion path.

Account information is retained while your account is open. Ask us at privacy@aka.to to close it and we will delete or anonymize your personal information, except where we are required to keep records.

Your rights

Depending on where you live, you may have the right to access, correct, export, or delete personal information we hold about you, to object to or restrict certain processing, and to withdraw consent. Write to privacy@aka.to and we will respond within the period the applicable law allows. We will not discriminate against you for exercising these rights.

For residents of California: we do not sell and do not share personal information as those terms are defined by the CCPA as amended by the CPRA, and we have not done so in the preceding twelve months.

For visitors in the European Economic Area and the United Kingdom: we process click data on the basis of our legitimate interest in measuring the reach of a link, an interest we have narrowed as far as we know how by making the measurement non-identifying by construction. We process customer account data to perform our contract with you.

A practical limit worth stating plainly: because we hold no identifier for a visitor, we usually cannot locate a particular visitor’s click rows in response to an access or deletion request. We cannot single you out in our own data, which is the same property that protects you.

Security

We encrypt data in transit, hash credentials and every value derived from an IP address, and keep the secret keys behind those hashes separate per purpose, so that exposure of one does not compromise the others. No system is perfectly secure; if you believe you have found a vulnerability, write to support@aka.to.

International transfers

We operate in the United States, and information we hold is processed there and in other locations where our service providers operate. Where required, we rely on appropriate safeguards for those transfers.

Children

The aka.to Service is not directed to children under 13, and we do not knowingly collect personal information from them. If you believe a child has given us personal information, write to privacy@aka.to and we will delete it.

Changes to this policy

We may revise this policy. If a change is material—in particular any change to the guarantees in the short version above—we will give notice through the service or by email before it takes effect. The effective date at the top of this page always reflects the current revision.

Contact

Privacy questions and rights requests: privacy@aka.to. Legal notices: legal@aka.to, or Aka To, Inc., 1 Example Street, Suite 100, Los Angeles, CA 90012. To report a link being used for abuse, see our Acceptable Use Policy.