GDPR & KVKK Compliant Analytics: A Developer's Guide to Consent Management

Privacy regulations are multiplying. GDPR covers the EU, KVKK covers Turkey, CCPA covers California, LGPD covers Brazil, and new frameworks appear every year. For developers building analytics, the question is not whether to comply -- it is how to comply without destroying your data quality. The answer lies in a layered consent model that adapts data collection to the user's privacy preferences.

This guide covers the legal landscape, Gurulu's 4-level consent model, the technical implementation, and the practical steps to make your analytics stack compliant without losing the insights you depend on.

Legal Requirements Overview

GDPR and KVKK share a common principle: personal data cannot be processed without a lawful basis. For analytics, the two relevant bases are consent (the user explicitly agrees) and legitimate interest (the data processing is necessary for a purpose that does not override user rights). The catch is that what constitutes personal data is broader than most developers assume. IP addresses, device identifiers, cookies, and even behavioral patterns can qualify as personal data if they can be linked to an individual.

The practical implication is this: if your analytics tool uses cookies, stores IP addresses, or creates persistent identifiers, you need consent before collecting data in the EU and Turkey. If your tool does none of these things -- like Gurulu's default cookieless mode -- you can argue that no personal data is processed, and consent is not required for basic analytics. But the moment you enable identity resolution with PII, consent comes back into play.

The 4-Level Consent Model

Gurulu implements a 4-level consent model that lets you collect progressively more data as users grant broader consent. Each level is a superset of the previous one:

• Level 0: Anonymous -- Aggregate metrics only. Page views and events are counted but not linked to any session or identity. No personal data is processed. This level requires no consent under any framework.
• Level 1: Functional -- Session tracking enabled. Events are grouped into sessions using server-side heuristics (timing, navigation patterns), but no persistent identity is created. Session data is deleted after 24 hours. Typically covered by legitimate interest.
• Level 2: Analytics -- Full event tracking with pseudonymized identity. The identify() API is active, sessions are linked across visits, and the identity graph is built. All identifiers are stored as salted hashes. Requires explicit analytics consent under GDPR and KVKK.
• Level 3: Marketing -- Cross-site tracking, advertising attribution, and third-party data sharing enabled. UTM parameters, ad click IDs, and referral chains are stored and linked to identity profiles. Requires explicit marketing consent.

The key insight is that useful analytics does not require the highest consent level. Most product teams can answer their critical questions at Level 1 (functional), which typically does not require a consent banner. Levels 2 and 3 provide richer data for teams that have consent infrastructure in place.

SDK Integration

Integrating consent into the Gurulu SDK takes a few lines of code. You set a default consent level during initialization and update it when the user makes a choice through your consent UI.

// Initialize Gurulu with consent awareness
gurulu.init({
  siteId: 'YOUR_SITE_ID',
  consent: {
    default: 'anonymous',  // Level 0: aggregate only
    // Consent levels:
    // 'anonymous'    → aggregate metrics, no identity
    // 'functional'   → session tracking, no PII
    // 'analytics'    → full event tracking, pseudonymized
    // 'marketing'    → cross-site, ad attribution
  }
});

// Update consent when user makes a choice
gurulu.setConsent('analytics');

// Or revoke consent
gurulu.setConsent('anonymous');

The consent state is persisted server-side, not in a cookie. When the user returns, Gurulu checks the stored consent level and applies the appropriate data collection rules. If consent is revoked, the system stops collecting data at the revoked level immediately and can optionally delete previously collected data for that user.

Pseudonymized Identity Graph

At Level 2 (analytics consent), Gurulu builds an identity graph using pseudonymized identifiers. Emails are stored as SHA-256 hashes with a site-specific salt. Phone numbers are normalized to E.164 format and hashed the same way. User IDs are stored as-is because they are already opaque identifiers controlled by your application.

This pseudonymization means that even if the identity graph database were compromised, an attacker could not extract email addresses or phone numbers. The hashes are one-way and site-specific, so rainbow tables from other breaches are useless. For GDPR purposes, pseudonymized data is still personal data, but it significantly reduces the impact of a breach and demonstrates compliance with the data minimization principle.

The identity graph supports right-to-erasure requests. When a user requests deletion under GDPR Article 17, the API removes all identity nodes, claims, and associated event data for that canonical identity. The deletion propagates across all merged sessions, ensuring complete removal.

Practical Implementation Steps

Step 1: Audit your current tracking. Before implementing consent management, understand what data your analytics currently collects. If you are using Gurulu in cookieless mode with no identify() calls, you are likely already at Level 0-1 and may not need a consent banner at all.

Step 2: Choose your default level. Set the SDK default to the lowest level that provides useful data without consent. For most sites, this is 'anonymous' or 'functional'. Higher levels activate only when the user consents.

Step 3: Implement your consent UI. Build or integrate a consent banner that explains what each level enables. When the user makes a choice, call gurulu.setConsent() with the appropriate level. The SDK handles the rest: activating or deactivating features, updating the server-side consent record, and adjusting data collection in real time.

Step 4: Handle consent changes. Users can change their mind. Your consent UI should allow users to revoke consent at any time, and the SDK should respond immediately. Gurulu's setConsent() call is idempotent and takes effect within the current session.

The Bottom Line

Consent management is not a checkbox exercise. It is a fundamental part of your analytics architecture that determines what data you can collect, how long you can keep it, and what you can do with it. A well-implemented consent model gives you the maximum data allowed under the law while respecting user preferences.

Gurulu's 4-level model makes this practical by decoupling data collection from consent requirements. You do not have to choose between compliance and analytics quality -- you get both, scaled to the consent each user has granted.