Quiz Email Consent and Suppression Matrix

What is a consent and suppression matrix?

A consent and suppression matrix is an operational table that turns a person's stated choice and later events into an allowed, blocked, or review-required action. It distinguishes a requested quiz result from promotional follow-up and prevents one generic subscribed flag from controlling unrelated messages.

Consent is not the only possible rule in every context, and this guide does not decide the applicable legal basis. The matrix records the basis and policy approved by the organization's qualified owner, then makes the resulting system behavior testable.

Related: Build an automatic result-email workflow · Run result-email QA

Keep three records separate

The completion record stores the quiz, result, supplied address, and request made in that interaction. The permission record stores the purpose, choice, source, notice version, timestamp, and applicable policy context. The suppression record stores a block reason, scope, source, timestamp, and whether a qualified owner may resolve it.

Do not erase suppression merely because a new completion arrives. Do not infer promotional permission from a request to receive a result. Do not treat a bounce as withdrawal, or a withdrawal as proof that the address is invalid; these states have different causes and remediation.

Related: Audit the CRM handoff record

Build the decision matrix

This implementation example is not a universal legal conclusion. Replace its policy labels with rules approved for the audience, jurisdiction, message content, and relationship.

Define precedence and reason codes

Evaluate the most restrictive active state at send time. A practical order is global safety or complaint block, permanent delivery failure, purpose-specific withdrawal, current permission evidence, then a review-required fallback. Return a reason code such as blocked_complaint, blocked_hard_bounce, blocked_marketing_withdrawal, or review_missing_evidence.

Never silently convert a blocked send into a different channel or message purpose. A correction request, service obligation, or legally required message needs its own approved rule and audit trail.

Capture permission evidence

W3C form guidance supports clear labels and instructions. A checkbox or choice should say what will happen in language the participant can understand; prefilled, bundled, or hidden choices create operational ambiguity even before legal review.

Sources: W3C, Form instructions ↗

Maintain suppression safely

Store the minimum information needed to prevent a prohibited repeat contact. A deletion workflow should consider whether a narrowly retained suppression token is necessary and permitted to honor an opt-out; that decision belongs to the organization's legal and privacy owner. Restrict access, document retention, and prevent suppression data from becoming a marketing segment.

The ICO says direct marketing should be collected fairly, explained clearly, and operated in a way that respects a person's right to object or opt out. Its data-minimisation guidance says information should remain adequate, relevant, and limited to what is necessary, but that page is under review following the Data (Use and Access) Act. The FTC explains that commercial messages need an opt-out mechanism and that transactional or relationship categories are narrow and depend on primary purpose. Requirements vary, so use these sources to brief qualified review rather than copy a universal rule.

Related: Review the broader data-privacy checklist

Sources: ICO, Direct marketing guidance ↗ · ICO, Data minimisation principle ↗ · FTC, CAN-SPAM compliance guide ↗

Run the state-transition tests

Use synthetic records to confirm that later, narrower, or more restrictive states win before real participants enter the workflow.

Worked example: result requested, marketing declined

A participant requests a result but leaves the separate product-updates choice unchecked. The system stores requested-result evidence and an unknown marketing state. It applies the approved result-delivery rule but blocks nurture. Later, the participant makes an approved affirmative marketing choice; the record stores the new purpose, notice version, and timestamp. A later unsubscribe creates a purpose-specific suppression that wins over the older permission.

This is a synthetic implementation example, not legal advice or evidence that any particular policy is lawful.

Release checklist

Block release until the policy owner, data model, interface, send-time evaluator, and recovery paths agree.

• Result delivery, service, and promotional purposes have separate states.
• Permission evidence includes purpose, source, notice version, and timestamp.
• Suppression includes reason, scope, source, and precedence.
• Every send evaluates current permission and suppression at send time.
• Unknown, conflicting, and stale states fail closed for marketing.
• Bounce, complaint, withdrawal, deletion, and address-correction paths pass.
• Controls and notices are clear, accessible, and not bundled ambiguously.
• Qualified legal or privacy owners approve the jurisdiction-specific rule.