Consent Arrives After the Data
A healthcare-adjacent marketer ingests appointment-booking events into a profile-enabled dataset. Consent is captured separately via a preference center and written to a consent field on the profile using the platform's consent policy framework. The booking events often arrive before the consent record for new patients, sometimes by several hours. Marketing has an active audience of 'recent bookers' activated to an email destination. During a privacy review, it emerged that some patients who later declined marketing consent received at least one campaign email because they were in the audience at export time. Additionally, a data-retention policy is supposed to delete booking events after 18 months, but the team cannot confirm it is running.
1. Explain how patients who declined consent ended up receiving email, and what enforcement point failed.
Read the worked answer
The failure is a timing and enforcement-point mismatch, not a missing consent record.
Sequence:
- Booking event arrives → profile qualifies for 'recent bookers' → audience membership set.
- Consent record arrives hours later and sets marketing consent to declined.
- The email destination export runs on its schedule.
If the destination/audience does not evaluate consent at export time, the profile's audience membership (set before consent arrived) is what drives the send. The consent field alone does nothing unless something checks it at the moment of activation.
The enforcement point that failed is the activation-time consent check. Correct design requires that the destination (or the audience's activation config) evaluates the consent policy against the profile at export, so a decline that arrived after qualification still suppresses the send. A consent value stored on the profile is inert unless a policy is bound to the destination and evaluated at send time.
Secondary contributor: the booking event qualified the profile before any consent existed. Profiles with no consent record should be treated as non-consented (deny by default) for marketing, not as implicitly permitted.
2. Recommend how to make consent enforcement durable and how to verify the retention policy.
Read the worked answer
Consent enforcement
- Bind a consent policy to the destination, evaluated at activation/export time, so declines suppress sends regardless of when the audience qualified.
- Set the default for missing consent to deny for marketing purposes.
- Add a re-evaluation trigger: when a consent record changes to declined, the profile should be removed from marketing audiences and suppressed at the destination, not just flagged.
- Audit the audience for profiles with no consent record and confirm they are excluded.
- Consider a hold-back: delay activation for new profiles until a consent record is present, closing the hours-long window.
Retention verification
- Confirm the 18-month retention policy is actually attached to the dataset and enabled, with the correct timestamp field (event time vs. ingestion time - pick deliberately and document it).
- Verify it is running by checking for deletion job records and by spot-checking that records older than 18 months are absent from profile and from the dataset.
- Note that retention on the dataset does not automatically purge already-merged profile attributes; confirm profile-level retention/deletion is also configured, or the 'deleted' data persists in profiles.
- Add monitoring/alerting on retention job success so silent failure is caught.