Tillbaka till bloggen
Technical

SaaS Privacy: Managing User Consent in Multi-Tenant Apps

Alex Kowalski, Platform ArchitectMay 12, 202613 min läsning
SaaSMulti-TenantArchitectureB2B
SaaS Privacy: Managing User Consent in Multi-Tenant Apps
# SaaS Privacy: Managing User Consent in Multi-Tenant Apps **Date:** May 12, 2026 **Author:** Alex Kowalski, Platform Architect **Category:** Technical **Reading Time:** 13 min --- Building a SaaS application? You have a unique privacy challenge: **Multi-Tenancy**. You are not just managing consent for *your* users; you might be managing consent for *your users' users*. Or, you have a marketing site (`.com`) and an app (`.app`), and you need to bridge consent between them. ## Scenario 1: The Marketing-to-App Bridge User lands on `www.yoursaas.com`. Accepts cookies. Signs up. lands on `app.yoursaas.com`. * **Bad Experience:** Asking for consent again. * **Good Experience:** Passing the consent state. **Implementation:** Use **Cross-Domain Consent**. When the user clicks "Sign Up", append `?gc_consent=token` to the URL. On the app side, read this token and initialize the CMP in the "Accepted" state silently. ## Scenario 2: Product Analytics (Mixpanel/Amplitude) Inside the app, you use analytics to improve the product. * **GDPR:** You usually need consent for this, unless you can argue "Legitimate Interest" (strictly necessary for product improvement, aggregated data only). * **Best Practice:** Ask for "Product Improvement" consent during Onboarding, *not* via a cookie banner. Save this preference to the User Profile in your database (Postgres/SQL), not just a browser cookie. ## Scenario 3: B2B vs. Users In B2B SaaS, your customer is the "Company." * **The Nuance:** The *Company* might sign a DPA (Data Processing Agreement) allowing you to process their employees' data. * **The User:** The individual employee still has rights. You generally don't need a "Do Not Sell" link for B2B app usage data (since you aren't selling it), but you do need transparency. ## Implementing "Identity-Based" Consent For SaaS, relying on cookies is fragile (users switch devices). **The Architecture:** 1. **DB Schema:** Add `consent_preferences` (JSONB) to your `users` table. 2. **Login:** When user logs in, fetch these preferences. 3. **Init:** Initialize GetCookies with these saved preferences. 4. **Update:** If user changes settings in the banner, sync it back to the API/Database. ```javascript // On Login const userPrefs = await api.getConsent(); GetCookies.init({ savedPreferences: userPrefs }); // On Change window.addEventListener('getcookies:consent_updated', (e) => { api.updateConsent(e.detail); }); ``` ## Conclusion For SaaS, consent should travel with the User ID, not the Browser ID. Treat privacy preferences as a first-class profile setting, just like "Dark Mode" or "Notification Settings."
A

Alex Kowalski, Platform Architect

Skribent på GetCookies, specialiserad på integritetsefterlevnad, samtyckeshantering och optimering av digital marknadsföring.

Redo att förenkla cookiesamtycke?

GetCookies gör GDPR, CCPA och global integritetsefterlevnad enkelt. Kom igång idag.