Zenovay treats IP addresses as personal data and is built to never store them in raw form. This article explains exactly what happens to an IP when it reaches our servers.
How IPs Are Handled
When a tracking request arrives, the visitor's IP is used briefly during processing and then discarded. Nothing in this flow is configurable: it is the default, privacy-first behaviour for every website on every plan.
- Geolocation: Determine country, region, and (approximate) city.
- Visitor ID: Generate a daily-rotating, irreversible identifier.
- Bot detection: Help filter out automated and malicious traffic.
- Discarded: The raw IP is never written to the database.
The Process
Incoming Request
↓
IP Address (e.g., 203.0.113.50)
↓
┌─────────────────────────────┐
│ Geolocation Lookup │
│ → Country: United States │
│ → Region: California │
│ → City: San Francisco │
└─────────────────────────────┘
↓
┌─────────────────────────────┐
│ Visitor ID Generation │
│ Daily-salted SHA-256 hash │
│ → v_abc123def456 │
└─────────────────────────────┘
↓
IP Address Discarded
(Only the hash and geo data are stored)
Why Raw IPs Are Never Stored
Zenovay does not keep raw IP addresses. Before anything is written to the database, the IP is run through a daily-salted SHA-256 hash:
- The hash is irreversible: you cannot recover the original IP from it.
- The salt changes every day, so a returning visitor produces a different hash tomorrow than today. This deliberately prevents long-term, cross-day tracking of a single IP.
- Only the resulting hash and the resolved geolocation are stored. The raw IP exists only in memory during the request.
This is the behaviour on every plan, and there is no setting that turns it off.
Geolocation Accuracy
Geolocation is derived from the IP at request time. Accuracy decreases as you move from country to city level:
Full IP (203.0.113.50):
└── Country: United States
└── Region: California
└── City: San Francisco (approximate)
City-level results are best-effort and can be imprecise, especially for mobile carriers, corporate networks, and VPN traffic. Country-level data is the most reliable.
Server-Side Tracking
Forwarding the Visitor IP
When you send events from your own backend rather than the browser, Zenovay sees your server's IP unless you forward the original visitor IP. Pass it along with the standard X-Forwarded-For header so geolocation reflects the real visitor:
// Express.js example
app.post('/track', async (req, res) => {
const clientIP = req.headers['x-forwarded-for'] || req.socket.remoteAddress;
await fetch('https://api.zenovay.com/e/YOUR_TRACKING_CODE', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'X-Forwarded-For': clientIP // Forward for geolocation
},
body: JSON.stringify({
type: 'page_view',
url: 'https://yoursite.com/page'
})
});
res.sendStatus(204);
});
Whatever IP you forward is hashed and discarded just like a browser request: Zenovay never stores the value you send.
Compliance Considerations
GDPR
IP addresses are personal data under GDPR. Zenovay's daily-salted hashing and same-request discard are designed so that no raw IP is retained. You should still document your analytics processing in your own privacy policy.
CCPA
IP addresses count as personal information under CCPA. Disclose your use of analytics in your privacy policy. Because Zenovay never stores raw IPs, the data you retain is limited to a non-reversible hash and coarse location.
Technical Details
Visitor ID Hash
The visitor identifier is built like this:
Visitor_ID = SHA-256( Daily_Salt + ":" + IP_Address )
Where Daily_Salt is the current calendar date (e.g. "2026-06-13").
Example:
SHA-256("2026-06-13:203.0.113.50") = "a3b8c9d4e5f6..."
Properties:
- Irreversible: you cannot get the IP back from the hash.
- Consistent within a day: the same visitor on the same day produces the same hash.
- Rotates daily: the salt is the date, so the hash changes every day and is not a permanent identifier.
Geolocation Source
Zenovay resolves country and approximate location at request time using Cloudflare's edge geolocation, with a geo-IP lookup as a fallback. Accuracy varies by region and is most reliable at the country level.
Troubleshooting
No Geographic Data
If geolocation isn't working:
- Make sure the visitor IP is being forwarded when tracking server-side (behind a proxy or load balancer).
- Confirm you aren't testing from a localhost or internal IP, which is skipped.
Inaccurate Location
Geolocation can be wrong due to:
- VPN usage
- Mobile carriers
- Corporate proxies
- Geo-IP database lag