ブログに戻る
Technical

SaaS Privacy: Managing User Consent in Multi-Tenant Apps

Alex Kowalski, Platform ArchitectMay 12, 202613分で読めます
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

GetCookiesの寄稿ライター。プライバシー準拠、同意管理、デジタルマーケティング最適化を専門。

自分のサイトを無料でスキャン

無料プランでは1つのサイトでバナーを表示でき、Cookieスキャンは月3回まで。カード登録も営業電話もありません。