Product Spec — Country-Aware Marketing Consent & Preferences

Owner: (TBD) · Status: Draft for review · Date: 2026-07-29

This is a product/eng spec, not legal advice. The country rules in §4 need privacy counsel sign-off before they drive real sends.

1. Why we're doing this

We sent a marketing email to a user who never agreed to receive marketing — because today we don't ask for marketing consent at all. There was no consent to show, and nothing stops a marketing email from going out to someone who never opted in.

The rules for marketing email also change by country, and we're moving toward country-specific products. So we need one system that:

1. Asks for marketing consent at sign-up (today we don't).
2. Keeps a clear record of what each user agreed to, and when.
3. Checks that record before every marketing send, and follows the right country's rules.

Get those three right and this kind of problem doesn't happen again.

2. Goals / Non-goals

Goals

• Record marketing consent for each user, per type of message, per country.
• Check consent automatically before any marketing email goes out.
• Be able to answer "what did this user agree to?" instantly.
• Adding a new country is a settings change, not new code.

Core idea: build one consent system where the country is just a setting. Don't build a separate version per country — that's how one country quietly ends up missing a safeguard.

3. How it fits together

Sign-up / Preferences screen ─┐
                              ├─► Consent events (fields in §5, history kept)
Country lookup ───────────────┘            │
                                           ▼
                          Set Customer.io subscription = Yes / No
                                           │
                                           ▼
              Customer.io sends marketing only when subscription = Yes

Data-request tool ──► Consent events + vendor list + retention settings

4. Country rules (the country-aware part)

4.1 Rules by country (counsel to confirm each row)

4.2 Which country's (or state's) rules apply

• Decide from one clear signal, and save it with the record. Suggested order: country the user picked at sign-up → billing country → location from IP.
• Resolve to state, not just country, in the US. US privacy law is state-by-state (California, and a growing list of others), so the engine needs a region/state level below country. Treat the strictest applicable state (California today) as the US baseline until we can target more precisely.
• Handle the messy cases (VPN, someone moves, EU resident signs up on the .com site). When unsure, use the stricter rule.
• Save the country/state and how we decided it on each record. Never rewrite it later.

4.3 Rules can change

• Rules are versioned. When a country's law changes, we bump the version and, if needed, re-ask affected users for consent.

5. What we need to capture

We already have an events system, so this isn't a new store to build — it's making sure each consent action fires an event that captures the fields below. Every consent change (agreed, withdrew, confirmed) is its own event, so the full history is preserved and we can always reconstruct "what did this user agree to?"

Each consent event needs to capture:

• Who — the user.
• What message type — marketing email, product updates, SMS marketing, etc.
• What happened — agreed / withdrew / confirmation sent / confirmed.
• How — sign-up checkbox / confirmation email / preferences screen / support.
• Country and state/region — and how we decided it (picked / billing / IP). State matters for the US.
• Which wording they saw — the version of the consent text.
• Where — sign-up form / settings / unsubscribe link.
• IP address and device (browser/app info).
• When — timestamp.
• Expiry — optional, only for countries where consent expires.

6. Enforcing it (via Customer.io)

We already send marketing through Customer.io (CIO), and CIO won't send to anyone whose subscription is off. So we don't build a separate gate — we enforce consent by keeping the user's CIO marketing subscription in sync with their consent:

• No consent on record → subscription = No (unsubscribed). CIO won't email them.
• User opts in → subscription = Yes.
• User withdraws / unsubscribes → back to No.
• Default for anyone without a clear "yes" → No.

That default is the key change: today, users with no consent aren't marked "No," so they can still be emailed. Under this spec, no consent means the CIO subscription is No — which is exactly what would have stopped the bad email.

Our job is to keep that flag correct (set it from the consent events in §5) and let CIO do the blocking. For countries where consent expires (§4), an expired consent flips the subscription back to No.

7. Asking the user (sign-up UX)

Today we don't ask at all, so the biggest new experience is a clear marketing choice at sign-up. Ground rules:

• Separate from Terms/Privacy. The marketing choice is its own thing — not bundled into "I agree to the Terms," and never pre-checked in opt-in countries.
• Plain about what they'll get ("tips, offers, and product news").
• Declining never blocks sign-up. Saying no (or ignoring it) still lets them create the account.
• Show it at the point of sign-up — that's the moment that has to carry a clear yes/no, not a setting buried later.

Two patterns, chosen by country (§4):

On "show a message vs. explicitly ask": in the opt-in markets we should explicitly ask (the unticked box), because a passive notice doesn't count as agreement there. In pure opt-out markets like the US we have a choice — show a notice (option A) or ask nothing and rely on unsubscribe (option B, the least protective, closest to today's behavior). Which markets sit in the "no ask" row is a decision we can make later, per country; it must never include an opt-in market.

Also: every marketing email keeps an easy unsubscribe, and the preferences screen (below) lets users change their mind anytime.

8. Supporting pieces

• Tag every email as marketing or transactional. Marketing rules apply only to marketing; service emails aren't accidentally blocked (or accidentally treated as marketing).
• Unsubscribe / "do not email": handled by the Customer.io subscription state (§6) — stays off until the user opts back in. Add one-click unsubscribe. If anything sends marketing outside CIO, it must respect the same state.
• Preferences screen: let users opt out by category (not all-or-nothing), linked from every marketing email.
• Vendor list: keep an up-to-date list of who touches user data (email provider, analytics, hosting) so we can answer data requests accurately.
• Retention settings: define how long we keep each kind of data, and be able to state it.
• Data-request tool: export a user's data and consent history quickly, with a built-in deadline reminder.

9. Rollout in phases

Phase 1 — stop it happening again

1. Ask for marketing consent at sign-up (a separate, unticked box — not bundled with Terms).
2. Fire a consent event capturing the fields in §5 on every consent change.
3. Sync consent to the Customer.io subscription flag; default to No for anyone without a clear yes (§6).

Phase 2 — country rules
5. Country rules engine (§4), starting with Germany / EU / UK.
6. Country detection + messy-case handling.
7. Confirmation-email opt-in flow for the strict countries.
8. Versioned wording + ability to re-ask for consent.

Phase 3 — polish & operations
9. Preferences screen + one-click unsubscribe.
10. Marketing-vs-transactional tagging across all emails.
11. Vendor list + retention settings.
12. Data-request tool + simple dashboards (consent rate by country, unsubscribe speed).

10. How we'll know it's working

• Every marketing email goes through the check.
• Every new sign-up creates a consent record.
• "What did this user agree to?" is answerable the same day.
• Zero marketing emails to people who opted out or never opted in (watched and alerted).

11. Open questions

• Which country signal wins — confirm with counsel and growth.
• Confirmation-email opt-in everywhere, or only strict countries? (Fewer sign-ups vs. safer.)
• Canada's consent-expiry window — confirm the number.
• Do we go back and ask existing users for consent, and by when?
• US states: which states do we handle explicitly vs. cover with a California baseline, and how do we detect state reliably?
• Who signs off on the rules for each country?