Marketing analytics and user privacy are often framed as opposing forces - that meaningful measurement requires collecting as much personal data as possible, and privacy compliance means accepting blindness. This framing is wrong, and it leads to two equally bad outcomes: teams building surveillance-grade tracking pipelines that create legal exposure, or teams flying completely blind on campaign performance.
Nimriz is built on a third path: privacy mode on by default, meaningful signal preserved, and no raw personal identifiers in the data pipeline. This post explains what that means in practice, what you can and cannot measure, and how to use the data you do have to make better marketing decisions.
Why "more data" is not always better data
Before diving into what Nimriz tracks, it is worth challenging the premise that raw IP addresses and full User-Agent strings are necessary for effective marketing analytics. They are not.
Raw IP addresses have two primary uses in analytics: coarse geographic segmentation and deduplication (distinguishing a returning click from a new one). Both of these can be approximated more safely. Geographic data is available from edge routing without storing the literal IP. Deduplication can be handled through time-windowed hashing without creating a long-lived user identity.
Full User-Agent strings - which expose not just device type but browser version, operating system version, and sometimes installed plugins - are far more data than marketers actually need. The signal that matters is: is this mobile or desktop? What browser family? Everything else is noise that creates unnecessary compliance risk.
Collecting data you do not need is not a neutral act. It creates obligations: consent flows, GDPR/CCPA data subject access requests, retention policies, breach disclosure risk. Every identifier you do not collect is infrastructure you do not have to maintain and legal risk you do not have to carry.
What privacy mode on means
For all new Nimriz accounts, privacy mode defaults to on. When privacy mode is on, analytics events exclude raw IP addresses and full User-Agent strings from storage. What gets captured is the set of marketing-useful dimensions that can be derived safely:
Referrer domain: Where did the click originate? This is one of the most actionable signals in link analytics. A referrer of twitter.com tells you a share is circulating on Twitter. l.facebook.com or t.co confirm the social platform. Direct traffic (no referrer) is a baseline. Referrer data does not require tracking an individual - it is a property of the HTTP request itself.
Country and region: Nimriz determines geographic data from edge routing context, not from the raw IP. You get country-level and in some cases region-level splits without storing the literal address. For an e-commerce brand running international campaigns or a SaaS team qualifying traffic by geo, this is the level of granularity that actually drives decisions.
Device category: Mobile, desktop, or tablet. This comes from a coarse parse of the User-Agent - enough to understand device context without storing the full string.
Browser and OS family: Safari or Chrome. iOS or Android. This is the actionable level for QA and landing page optimization. You do not need to know the exact browser version to know whether to investigate a mobile Safari rendering issue.
Bot classification: Nimriz flags likely automated traffic separately. This is critical for campaign measurement - bot clicks inflate totals and distort conversion rate calculations. With bot flags in the data, you can filter to human traffic only without discarding the data entirely.
Together, these dimensions give you enough to answer the questions that drive marketing decisions: Which channels are driving clicks? Which regions are most active? Is this campaign skewing mobile? Is bot traffic artificially inflating numbers? You can run effective channel optimization, geo-targeting adjustments, and device-specific landing page experiments with exactly these signals.
When privacy mode is off: hashing and deduplication
Some teams have legitimate operational reasons to enable coarser deduplication - the ability to count a single user clicking the same link five times as five clicks or as one unique click. This is a real analytical need, and raw IP + UA matching is the traditional approach.
Nimriz supports this without storing raw values. When privacy mode is off, the system computes a daily-salted hash derived from a combination of IP address and User-Agent. The process:
- Take the IP address and User-Agent string for the incoming request.
- Combine them with a salt that rotates every 24 hours.
- Hash the combined value with a one-way function.
- Store only the hash output - never the inputs.
The hash is used only to distinguish clicks that appear to come from the same device within the same day. Because the salt changes daily, the same real IP address will produce a completely different hash on Tuesday than it did on Monday. This means:
- You cannot build a cross-day behavioral profile from the hash.
- The hash cannot be reversed to recover the IP or UA.
- The data does not constitute personal data under most interpretations of GDPR and CCPA.
Details of what is stored and for how long match your workspace settings and the product documentation.
Bot detection and clean click reporting
Automated traffic is a persistent problem for link analytics. Bots come in many forms: search crawlers pre-fetching links in email, social network scrapers generating link previews, security scanners validating URLs, and in some cases adversarial click-inflation tools.
Nimriz applies bot classification at the edge before logging analytics events. Likely bot traffic is flagged in the data so you can filter or segment it in reports and exports. This matters because:
- Campaign performance measurement depends on human CTRs. Including bot clicks can make a campaign look more successful than it is, or distort device/channel breakdowns.
- Webhook integrations downstream (CRM triggers, conversion attribution pipelines) should be filtering bot events. Nimriz's bot flag lets your integration logic do this cleanly without inventing its own heuristics.
- Security investigations benefit from seeing bot traffic separately rather than discarded - sometimes unusual bot patterns indicate a link is being targeted for specific reasons.
Making decisions with privacy-safe data
The dimensions described above are sufficient for the full set of standard marketing decisions:
- Comparing click volume by channel and campaign to allocate budget.
- Identifying geographic regions with high click volume but low downstream conversion (a sign of either poor landing page localization or attribution mismatch).
- Spotting device skew to prioritize mobile landing page optimization.
- Diagnosing referrer anomalies that indicate unexpected link distribution (a link going viral in a community you weren't targeting).
- Filtering bot events before passing data to your CRM or warehouse.
None of these require knowing individual IP addresses. The signal that drives marketing decisions is almost entirely at the aggregate and segment level.
Compliance considerations
This article is a product overview, not legal advice. For questions about whether Nimriz's data model satisfies your specific compliance obligations under GDPR, CCPA, or other frameworks, read the Privacy Policy, the Trust page, and consult your legal counsel.
What we can say: the default privacy mode design is deliberately conservative. The instinct behind it is to collect what is useful for you and discard what creates risk.
Go deeper
- Analytics definitions - how each dimension is computed
- Analytics and privacy - developer-oriented documentation
- Trust - security, data handling, and compliance overview