Privacy & Consent
The SDK is built to be deployable without a cookie banner in most jurisdictions, while still providing all the features needed for product + marketing analytics. This page documents the privacy posture and the levers you have for stricter modes.
What the SDK does not do
- No fingerprinting. No canvas, audio, WebGL, font enumeration, plugin probing.
- No IP storage. Server reads IP from request headers for geo lookup, then discards it. Only the country/region/city derived from it is stored.
- No User-Agent storage. Same — read from header, parsed to browser/OS, discarded.
- No third-party requests. Everything goes to your configured
data-endpoint(defaultingest.logu.ro). No tracking pixels, no Google Analytics, no Facebook. - No cross-site identity.
visitor_idis per-origin (inlocalStorage) or per-domain (in cookie). It never leaves the origin you configured.
What the SDK does collect
| Field | Why | Sensitivity |
|---|---|---|
visitor_id (UUID) | Distinguish visitors for analytics | No PII; can be reset by user clearing site data |
session_id (UUID) | Funnels, “sessions per visitor” | Resets every 30 min idle |
url / path / referrer | Where they are, how they got there | Could contain query params with PII — see below |
viewport / title | Aggregate device class, page identification | Public info |
| Geo (server-derived) | Country / region / city | Aggregated, not GPS precise |
| Custom event names + props | Whatever you pass to Loguro.track() | You control this. Don’t pass email, names, passwords |
Watch out for PII in URLs
url and path are sent verbatim. If your app routes like /users/john@acme.com/settings, that email lands in analytics. Sanitize at the framework level (/users/:id/settings) or strip query params before navigation.
The SDK does not automatically strip query params — that’s an app decision (some sites need ?utm_source=... for attribution).
Do Not Track (DNT)
data-analytics-respect-dnt="true" When set, the SDK checks navigator.doNotTrack. If it’s "1", all analytics features are disabled — no visitor_id is generated, no events are sent, no listeners are installed.
Logs (errors, console.error, etc.) continue to flow, because those help you fix bugs, not track users.
DNT is widely ignored by other vendors, but it’s a free signal. Default is false because most regulators don’t recognize DNT as legally binding consent.
GDPR-style cookie consent
If your jurisdiction (or your legal team) requires opt-in for analytics, you have two patterns:
Pattern 1: Load SDK, disable until consent
Load the script normally, but call setEnabled(false) immediately. Re-enable after user accepts:
<script src="https://app.logu.ro/loguro.js" data-api-key="brk_..." data-analytics="all"></script>
<script>
window.Loguro.setEnabled(false); // off until consent
document.getElementById('consent-accept').addEventListener('click', () => {
window.Loguro.setEnabled(true);
window.Loguro.pageview(); // record the missed initial pageview
});
</script> Pro: SDK is ready to go the moment consent is granted — no extra round-trip. Con: SDK file is loaded even for users who decline. Initial visitor_id is generated.
Pattern 2: Don’t load SDK until consent
Don’t include the script tag at all until consent:
<script>
document.getElementById('consent-accept').addEventListener('click', () => {
const s = document.createElement('script');
s.src = 'https://app.logu.ro/loguro.js';
s.setAttribute('data-api-key', 'brk_...');
s.setAttribute('data-analytics', 'all');
document.head.appendChild(s);
});
</script> Pro: Zero footprint for declining users. Con: SDK load takes a few hundred ms after consent; you miss the entry pageview unless you fire Loguro.pageview() manually after load.
“Reject all” — what to clean up
If the user originally accepted then withdraws consent:
window.Loguro.reset(); // wipe visitor / session / user
window.Loguro.setEnabled(false); // stop new events reset() removes the localStorage keys (loguro_v, loguro_s, loguro_u) and clears the identity cookie if you’re using cookie storage.
Cookie-less mode
For the strictest setups, combine:
<script
src="https://app.logu.ro/loguro.js"
data-api-key="brk_..."
data-analytics="pageviews,events"
data-analytics-id-storage="memory"
data-analytics-respect-dnt="true"
></script> id-storage="memory"→ nolocalStorage, no cookies. Fresh ID per tab load.respect-dnt="true"→ opt-out via browser setting works.- No
auto-events→ only explicitLoguro.track()calls fire events (you control what’s collected per-page).
This mode gives you per-pageload aggregates (page popularity, error rates, vitals) without any persistent identifier. Sessions and funnels won’t be meaningful — that’s the tradeoff.
Data residency
Default data-endpoint is https://ingest.logu.ro (EU-hosted infrastructure). If you need data to stay in a specific region or on your own infrastructure, self-host the ingest server and point data-endpoint at it.
Data retention
Retention is controlled by your plan, not the SDK. Logs and web events follow the same retention rules as the rest of your Loguro data. See your project’s billing settings.
What to include in your privacy policy
Suggested boilerplate (consult your legal team for jurisdiction-specific language):
Analytics. We use Loguro to understand how visitors use our site. Loguro stores a randomly generated identifier (
visitor_id) in your browser’s local storage to recognize return visits, and aggregates page views, custom interactions, and performance metrics. We do not use this data for cross-site tracking or advertising. Loguro respects the Do Not Track browser signal. You can clear the identifier at any time by clearing your browser’s site data.
If you use data-analytics-id-storage="cookie", swap “local storage” for “cookie” in the above.