GDPR Compliance with the RoLearn SDK

This is not legal advice; it is a practical engineering and privacy-operations guide that should give your legal team enough material to write a defensible policy. If your game has EU players (it does), the GDPR applies regardless of where your studio is headquartered. The same framing covers UK-GDPR, CCPA, Brazil's LGPD, and most other modern privacy regimes. The guide covers what the SDK collects, the lawful-basis framing we recommend, how to operate the data-deletion API end-to-end, retention semantics, PII redaction with before_send, and the disclosure language to bring to your privacy policy.

What the SDK actually collects

Per-event, every SDK platform sends a small, well-defined envelope plus your per-event payload. The envelope:

• event_id — random 8-40 char string for idempotency.
• ts — event timestamp in ISO 8601 UTC.
• platform — one of roblox / unity / steam / fortnite.
• game_id — your game's identifier (Roblox place ID, bundle ID, Steam app ID).
• player_id — optional. The platform-native player identifier you choose to send (Roblox UserId, SteamID64, your own backend ID). This is the field that turns SDK telemetry into personal data under GDPR. Without it, events are pseudonymous-bordering-on-anonymous.
• session_id — random 64-char session identifier, server-generated.
• type + payload — the event type discriminator and your payload object, validated against the schema for that type.

Auto-instrumented events additionally include:

• Country code (2-letter ISO). Resolved from the platform's localization service (Roblox GetCountryRegionForPlayerAsync, Unity RegionInfo, Steam GetIPCountry). The SDK does NOT collect IP addresses or fine-grained geolocation.
• Device class (mobile / console / pc) and OS string. For FPS bucketing and crash signature grouping. Not enough to fingerprint a device.
• SDK version + build identifier.

The SDK does NOT collect: IP address, email, name, phone number, payment card, exact location, photos, microphone data, voice recordings, contacts list. The server-side schema validator (backend/sdk/schema.py) explicitly rejects events with any payload key matching email,phone, ssn, or credit_card — if you accidentally include them, the event is rejected at ingest with a clear error.

The lawful-basis framing we recommend

Under GDPR you need a lawful basis for processing any personal data. For game analytics, the two viable bases areconsent and legitimate interest. We recommend legitimate interest with a documented Legitimate Interest Assessment (LIA), because:

• The data minimization story is strong — no IP, no email, country at country-level only, device class only.
• The purposes are tightly scoped — improve the game, calculate retention, debug crashes, measure feature adoption. Not used for advertising profiling, not sold, not joined with third-party data.
• The data is held by you under your privacy policy, not shared with RoLearn's other customers or used to train models that touch other tenants' data.

Studios with a higher risk tolerance (most B2C games) ship on legitimate interest. Studios in regulated verticals or targeting minors-only audiences sometimes choose consent instead — which means showing a consent banner before the first event is emitted. The SDK supports both flows; for consent-first studios, simply delay SDK.init() until your consent flow returns.

Operating the data-deletion API end-to-end

Under GDPR Article 17 (the "right to erasure"), an EU user can request that you delete all personal data you hold about them. The SDK provides a server-side endpoint to fulfill this for SDK telemetry:

DELETE /api/sdk/data/players/{player_id}
Authorization: Bearer <your_user_token>

On call, the endpoint:

• Hard-deletes every sdk_events row where player_id matches, within the calling user's team scope.
• Hard-deletes every sdk_dlq (dead-letter queue) row matching the same player.
• Returns a count of rows deleted.

Important: the endpoint does NOT delete from aggregate tables (DAU rollups, retention cohorts, geo daily). Those tables hold counts and rates, not per-player rows — there is nothing about the individual player in those tables to delete. They get re-computed nightly from the (now-deleted) event stream; within 24 hours of a deletion, the rollups also no longer reflect that player's data going forward. For periods before the deletion, the rollups continue to include aggregate counts of the player's prior activity — which is GDPR-safe because the data is no longer personal data once aggregated.

The end-to-end customer flow you need to set up:

1. Receive the request. Usually via email to a privacy mailbox; some studios run an in-game support form. GDPR allows you 30 days to respond.
2. Verify identity. Confirm the requester actually controls the account associated with the player_id. For Roblox, this typically means having them send the request from their Roblox-registered email. For Steam, comparable verification via their Steam-registered email.
3. Resolve player_id. Convert whatever identifier the user gives you (their in-game username, their email) to the player_id the SDK has been recording. Your backend should maintain this mapping.
4. Call the API. Single HTTP DELETE, authenticated with your team token. Save the response (row counts) to your compliance audit log.
5. Confirm to user. Reply confirming deletion. Include the date of action and a brief note that deletion takes 24 hours to propagate to aggregate views.
6. Delete from your own systems. The SDK delete only covers SDK telemetry. You still need to delete the user from your own backend, your support ticket system, any email lists, your payment processor's records (subject to financial-records retention exemptions), etc.

The single most common mistake we see studios make is forgetting that the SDK delete is one step in a longer process. Your privacy policy must accurately describe every system that holds user data and the timeline for deletion from each. The SDK part is easy; the documentation part is what takes work.

Retention policy

Raw sdk_events rows are retained for 90 days by default on all SDK plans. After 90 days, raw event rows age out via partition drop, leaving only the aggregated rollup tables (DAU, retention cohorts, revenue, geo, etc.). Aggregated rollups are retained indefinitely because they hold no per-player information.

Studios with stricter retention requirements (some EU titles, children's-game targets) can request shorter retention windows — contact support. The 90-day floor is a balance between retention-cohort meaningfulness (you need at least 30 days of raw events to compute D-30 retention) and minimizing personal data held. For most studios 90 days is the right tradeoff.

PII redaction with before_send

Despite the server-side guards, the right place to keep PII out of the SDK is in your client code — never let it be emitted in the first place. The SDK's before_send hook runs synchronously on every event before it leaves the client, giving you a last-line guard. Roblox Lua:

SDK.init({
    api_key  = "rk_live_…",
    endpoint = "https://rolearn.dev/api/sdk/events",
    game_id  = tostring(game.PlaceId),
    before_send = function(event)
        if event.payload then
            -- Strip anything that looks like an email
            for k, v in pairs(event.payload) do
                if type(v) == "string" and string.find(v, "@") then
                    event.payload[k] = nil
                end
            end
        end
        return event  -- return nil to drop the event entirely
    end,
})

Unity C#:

RoLearnSDK.Init(new RoLearnConfig {
    ApiKey = "rk_live_…",
    Endpoint = "https://rolearn.dev/api/sdk/events",
    GameId = Application.identifier,
    BeforeSend = (payload) => {
        var keysToStrip = payload.Keys.Where(k =>
            payload[k] is string s && s.Contains("@")
        ).ToList();
        foreach (var k in keysToStrip) payload.Remove(k);
        return payload;  // return null to drop entirely
    }
});

Use before_send for three things:

• Strip accidental PII inclusions. Defense in depth.
• Drop events you do not want sent (return null from the hook). Useful for sampling, debug filtering.
• Normalize payload values (lowercase enums, trim whitespace).

Don't use before_send for: HTTP calls, database queries, or anything else that blocks. The hook runs on the SDK's hot path; a slow hook slows your game.

Children's games (COPPA / GDPR-K)

Roblox's modal user is under 13, so this section applies to nearly every Roblox studio. COPPA in the US and GDPR-K in the EU require additional protections for users under 13. Recommended posture:

• Do not pass player_id for users under 13. Emit events without identity. You lose per-player retention cohorts (rollups still work), gain regulatory comfort.
• Country-only geolocation. Already the SDK default — never collect city or coordinates.
• No behavioral profiling. The SDK is not a behavioral-profiling tool; do not build segments designed to identify and target individual under-13 users for monetization purposes.
• Roblox-specific: Roblox's own platform ToS prohibits collecting PII from users under 13, and enforces it at the platform level. Following Roblox's policies gets you ~90% of the way to GDPR-K compliance for the Roblox surface; the remaining work is in your privacy policy and operational response to deletion requests.

Disclosure language for your privacy policy

Below is a starter paragraph your legal team can adapt. We do not warrant it; have your lawyer review.

We use the RoLearn analytics SDK to measure how players engage with our game and to debug technical issues. The SDK collects: a session identifier; your platform's user identifier (e.g. your Roblox user ID); your country (country-level only, no IP address stored); your device class (mobile/console/PC) and OS; your in-game actions relevant to measuring game features (level completions, purchases, errors); and crash reports when the game fails. The SDK does not collect your name, email, phone number, precise location, photos, or microphone data. This data is held for 90 days, after which raw records are deleted; only aggregate counts are retained beyond 90 days. To request deletion of your data, email [your privacy address].

Compliance audit checklist

1. Privacy policy includes a paragraph describing RoLearn SDK data collection (use the above as a starting point).
2. A documented Legitimate Interest Assessment (LIA) lives in your compliance folder, or you use consent and have a consent banner before SDK.init().
3. A privacy email address is published in-game and on your marketing site.
4. Your backend maintains a mapping from user-facing identifiers (username, email) to SDK player_id so you can resolve deletion requests.
5. Your support team has a documented runbook for handling GDPR deletion requests, including the SDK API call.
6. A before_send hook is configured in your SDK init to strip accidental PII as defense in depth.
7. For Roblox studios: under-13 users emit events without player_id.
8. Compliance audit log captures every deletion request, the date actioned, and the row counts returned by the SDK delete endpoint.

Where to go next

• SDK integration reference — full event schema, validation rules, ingest response codes.
• Custom Event Tracking Patterns — designing your event taxonomy so deletion requests are easy to fulfill.
• Roblox SDK Quickstart — covers before_send setup as part of init.
• Building Custom Dashboards — describes how dashboards behave when player data is deleted (aggregate rollups continue, per-player tiles empty).