What this site stores about your visit

The site records bounded daily aggregates for eligible public pages and editorial sections: page views, section views, landing-page visits, traffic channel, a reduced referring hostname, and limited campaign labels. It does not create a request-by-request journey, visitor profile, or unique-person count. The first eligible page in a 30-minute visit is its landing page. A section is counted once in that visit after at least half of it (or half of the viewport for a taller section) has been visible for one second.

For this limited visit measurement, the browser receives one encrypted, authenticated, first-party session cookie. It contains only timestamps, whether a landing page was recorded, and a bounded set of page and section markers so they are not counted twice in the same visit. It has no persistent browser expiry and does not contain a visitor ID. A visit expires after 30 minutes without activity; a tampered or expired cookie begins a new visit. Display choices such as units, color theme, and climate baseline use separate preference storage and can be cleared with browser controls.

A request address is checked against a local DB-IP City Lite database and then discarded. The site does not store a postal code, exact coordinates, address, address digest, or account-linked location. Daily aggregates can retain approximate country, state, province, or comparable first-level region, and city values. Location can be wrong, particularly for VPNs, mobile networks, and proxies. Named city aggregates are retained for 180 days; other analytics aggregates are retained for 400 days. In the private administration panel, cities with fewer than five page views in the selected date range are hidden. That is a display threshold, not a claim that those city aggregates were never stored.

The browser’s user-agent header is reduced immediately to a device class (phone, tablet, and computer), an operating-system family, and a browser family — each a fixed, non-identifying category. The request can also be classified as a person, likely automated, or a declared bot so aggregate reports can distinguish traffic types; this describes a request, not a person. Raw addresses, raw user-agent strings, device identifiers, and request-level records are not stored.

For a landing page only, an incoming referral is reduced to a validated hostname and a fixed channel such as search, social, email, campaign, referral, internal, or direct/unknown. The full referral URL is never stored. If present, only utm_source, utm_medium, and utm_campaign are read; each is normalized, restricted to letters, numbers, periods, underscores, and hyphens, and capped at 64 characters. Referral paths, queries, fragments, credentials, and invalid campaign values are discarded. A daily cap limits distinct source combinations; overflow is recorded in fixed “Other” buckets. These aggregates are never tied to a location, account, or individual visit.

Requests carrying Do Not Track or Global Privacy Control, first-party test markers, first-party test user agents, and authenticated administrator traffic are excluded before analytics processing. No analytics cookie is set for those requests.

Display choices such as units, color theme, and climate baseline are kept in a signed cookie and in browser storage. They can be cleared with your browser controls.

An account stores an encrypted email address, passkey public credentials, active sessions, display preferences, followed regions, and bounded security records. Weather & Vines does not store a password or the private half of a passkey. Analytics location and visit data are not linked to an account.

Sessions expire after seven days of inactivity and after 30 days in all cases. Expired challenges and email links are removed after 24 hours, revoked sessions after 30 days, and deidentified security events after 180 days.

Deleting an account revokes its passkeys and sessions, removes preferences and followed regions, and clears its encrypted email and lookup material. Encrypted backups are managed separately from analytics: public-data exports exclude all analytics and account data, and backup retention is described in the deployment record for the applicable environment.

SMTP2GO receives the address and message needed to deliver account verification, recovery, and security email. Reader feedback contains no contact field. Its category, message, and page path are stored here and copied to a private GitHub issue for review.

Request addresses are used only for short-lived abuse limits on account and feedback forms. They are reduced to keyed digests rather than stored as readable addresses.

You can use the atlas without signing in, change display settings at any time, revoke passkeys or sessions from the account page, and delete the account there.