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.

For page analytics, a request address is checked against a local DB-IP City Lite database and discarded after deriving location. The analytics database stores no 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. Traffic is classified as unknown, likely human, suspected automation, or recognized automation; these are estimates about requests, not identities. Browser headers alone do not establish a human visitor. Earlier browser-like counts keep their original classification.

When JavaScript is available, a page can report at least five seconds of visible reading time, whether a scroll, touch, pointer, or keyboard interaction occurred, and whether the browser reports automation. The encrypted session cookie also carries bounded visibility and engagement markers and a short request-count window. Cookie continuity, visible reading, and interaction or continued navigation can strengthen human confidence. Daily aggregates store fixed decision reasons, engaged page counts, and a comparison with the earlier header-only classifier. These signals do not block access. No interaction text, key values, pointer coordinates, raw addresses, raw user-agent strings, device identifiers, or request-level records are stored.

For recognized and suspected automation, GET requests are reduced to a fixed bot name and family, verification result and method, broad destination category, response-code group, and burst-evidence category. These daily counts include unsuccessful requests and files, so they overlap page analytics rather than adding extra visitors. A claimed crawler identity can be checked locally against its operator’s published IP ranges, downloaded periodically from fixed official URLs. No visitor address is sent to those operators. Missing or stale ranges leave verification unavailable; a failed match is not proof of impersonation.

To detect bursts from clients that discard cookies, a random key reduces request addresses to temporary tokens held only in server memory. The key and usable count window rotate after 60 seconds; expired tokens are cleared on the next request or periodic flush, at most five minutes later. No token enters the analytics database, logs, cookies, or account records. Static-file requests do not advance this count. Shared addresses can represent multiple people, so a burst alone does not establish automation. These signals do not block access.

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, authenticated administrator traffic, and health or readiness checks 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.