// context projectglobal

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 (default ingest.logu.ro). No tracking pixels, no Google Analytics, no Facebook.
  • No cross-site identity. visitor_id is per-origin (in localStorage) or per-domain (in cookie). It never leaves the origin you configured.

What the SDK does collect

FieldWhySensitivity
visitor_id (UUID)Distinguish visitors for analyticsNo PII; can be reset by user clearing site data
session_id (UUID)Funnels, “sessions per visitor”Resets every 30 min idle
url / path / referrerWhere they are, how they got thereCould contain query params with PII — see below
viewport / titleAggregate device class, page identificationPublic info
Geo (server-derived)Country / region / cityAggregated, not GPS precise
Custom event names + propsWhatever 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" → no localStorage, no cookies. Fresh ID per tab load.
  • respect-dnt="true" → opt-out via browser setting works.
  • No auto-events → only explicit Loguro.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.

Next

// related

See also