Privacy policy for gc.mw links, pages and accounts

gc.mw is operated by Growcord. The registered entity name, address and the contact for privacy questions are being confirmed and will appear here before this page is published.

This policy covers three surfaces: short links on gc.mw and on customer domains, bio pages at gc.mw/@name, and the dashboard and API. Where a workspace uses gc.mw to process data about its own visitors, that workspace is the controller and we are the processor acting on its instructions.

What a redirect records

Following a short link produces one analytics event. The event holds the day and time, the link and domain it belongs to, a coarse country, region and city taken from headers the network edge adds, the device type, operating system and browser parsed from the user agent, the language preference, the referring hostname and its category, any UTM values, whether the visit came from a QR code, and a visitor identifier.

It does not hold the visitor's IP address. It does not hold the full user-agent string, an email address, a name, an advertising identifier, or anything a workspace has not itself attached to the link.

The visitor identifier

The identifier is a SHA-256 hash of three things: a rotating salt, the visitor's IP address and the user-agent string, truncated to 32 hexadecimal characters. The address and the user agent exist only in memory for the microseconds it takes to compute the hash; neither is written anywhere.

The salt is derived from a server secret and a time period that advances every 24 hours. When it rotates, every previously computed identifier becomes uncomputable and unmatchable. The consequence is deliberate and worth stating plainly: we cannot link a visitor's activity across two days, we cannot build a profile, and we cannot answer a request to identify who clicked a link — including one from a workspace that owns the link.

The identifier is used for two things: counting unique visitors per link per day, and keeping an A/B split stable so one person is not shown two different destinations within the same day.

Where events are stored, and for how long

Events are written to a MongoDB time-series collection with a time-to-live of 400 days, after which the database removes them without anyone asking. Alongside them we keep a daily aggregate per link — counters for clicks, scans, bots, and totals by hour, country, city, referrer, referrer type, device, operating system, browser, language, campaign and A/B variant. Aggregates hold counts, never rows about people.

Unique-visitor counts come from a probabilistic counter in Redis that stores a sketch rather than the identifiers themselves, expiring after three days. The number it returns is an estimate, which is the honest trade for not keeping a list.

What a workspace can see is shorter than what exists, and is set by its plan: 30 days on Free, 365 days on Pro, 1,095 days on Business and Team. Queries are clamped to that window; there is no interface that reaches further back.

Cookies and browser storage

Redirects set no cookies. The redirect response carries a Location header, Cache-Control: private, no-store, X-Robots-Tag: noindex and a referrer policy — no Set-Cookie, no script, nothing written to the visitor's browser. The same is true of the QR image endpoint, the link preview page and the blocked and expired notices.

Bio pages record their view on the server, through the same pipeline and the same daily identifier, with no script and no cookie. Search-engine crawlers are recognised and not recorded at all.

The dashboard sets a session cookie once you log in, because a login is not possible without one. That cookie is not used for analytics.

Third parties

Nothing in the link and bio analytics pipeline is sent to a third party. Country, region and city come from request headers the network edge adds; we do not run an IP-geolocation lookup on the redirect path and we do not send addresses to a geolocation service from it.

The processors we do use are named by what they do: MongoDB and Redis for storage, our hosting provider for compute, a network edge provider for TLS and bot scoring, Resend for transactional email, and Razorpay for payments. Card details are entered on the payment provider's side and never reach us; we store the provider's customer and subscription identifiers, the last payment reference, a billing country and — where a customer supplies one for tax invoices — a GSTIN.

Legacy eCard card pages

Digital business cards inherited from eCard, served at /c/…, post interaction events to an older endpoint that resolves an approximate location. When the deployment does not supply geolocation headers, that resolution sends the visitor's IP address to a third-party lookup service over an unencrypted connection. No address is stored, and the events themselves hold only card, organisation, event type, referrer and the resolved country, region and city. This transfer is a defect, it does not exist on any gc.mw link or bio page, and it is scheduled for removal. It is written here because a privacy policy that omits a transfer is worse than one that admits it.

Account, link and abuse data

An account holds a name, an email address, a bcrypt hash of the password if one is set, an optional phone number and avatar, a Google identifier if you signed in that way, and — if you enable two-factor authentication — its secret and recovery codes. Session records hold a session id, timestamps, a truncated user-agent string and a hashed IP address, so you can review and revoke your own sessions without us keeping a log of where you have been.

A link holds its destination, title, tags, UTM defaults, and a salted hash of the address that created it, which exists so anonymous abuse can be rate limited without a log of addresses.

An abuse report holds the reported link, the reason, any details and email address the reporter chose to give, and a salted hash of the reporter's address, which is used only to count distinct reporters. The hash is never returned by any endpoint, and the reporter is never shown to the link's owner.

Administrative and billing actions are written to an append-only audit log with the actor, the action, the target, a request identifier, a hashed address and a truncated user agent. Application logs are structured JSON with a redaction list covering passwords, hashes, tokens, secrets, API keys and one-time codes.

Rate limiting is the one place a raw address is held outside a request: it forms part of a counter key in Redis, which expires with the rate-limit window — typically 60 seconds. The counter is a number. No history is kept.

Your rights

Under India's Digital Personal Data Protection Act, 2023 and under the GDPR, you can ask for access to the personal data we hold about you, correction of it, deletion of it, and — under the GDPR — a portable copy and an objection to processing. Write from the address on the account and we will answer within the period the applicable law sets.

Two honest limits. First, analytics data cannot be tied to you: there is no identifier in it that survives a day or maps to a person, so a request to delete "my clicks" has no rows to act on. Second, where a workspace is the controller — its links, its visitors — we forward the request to that workspace rather than acting on our own.

Deleting a workspace removes its links, bio pages, and their aggregates. Raw events reach their 400-day expiry independently; the design target is to remove a deleted workspace's events and aggregates within 30 days, and the job that enforces that is not yet built.

What is designed but not yet in the product

Stated separately so nothing here is read as a description of current behaviour.

• Returning-visitor tracking on pages. The design allows a workspace to switch on a first-party script that sets a consent-aware cookie, off by default and per workspace. It is not implemented; today no page in the analytics path sets a cookie of any kind.
• Third-party forwarding. The design allows a workspace to switch on server-side forwarding to analytics and advertising platforms, with credentials encrypted at rest and nothing sent unless the workspace enables it. It is not implemented; today no click or page view is forwarded anywhere.
• Privacy mode. A per-workspace switch that would disable city-level geography and any third-party forwarding. Not implemented.

Changes

Material changes will be announced to account holders by email before they take effect, and the date at the top of this page will change. Superseded versions stay available in the repository's history.