Skip to Content
DevelopersCompliance & securityGDPR & deletion

GDPR / DPDP & data deletion

Active Reach supports GDPR right-to-erasure (Article 17), data subject access requests (Article 15), and the equivalent rights under India’s DPDP Act. The same substrate handles both frameworks — the rights surface is the same; the legal basis and notice text differ.

Right to erasure (deletion)

When a contact requests deletion of their data:

Via the UI

  1. Go to People → Contacts → [contact] → Delete
  2. Confirm the deletion
  3. The system queues deletion of:
    • Contact profile and all properties
    • All events attributed to this contact
    • Segment memberships
    • Delivery records
    • Any active journey enrollments

Via the API

DELETE /api/v1/contacts/{contact_id}

Or for GDPR-specific deletion with audit trail:

POST /api/v1/compliance/tenant-deletion

Processing timeline

  • Contact is immediately marked as deleted and excluded from all campaigns/journeys
  • Profile data is purged within 24 hours
  • Event data is purged within 72 hours
  • Downstream systems (ClickHouse, data warehouse exports) are purged on their next compaction cycle

What’s NOT deleted

  • Aggregate analytics (campaign-level metrics) are retained because they don’t contain PII
  • Audit log entries about the contact are anonymized (contact ID replaced with a hash)
  • Data already exported to your own warehouse via data pipes is your responsibility to delete

Data subject access request (DSAR)

To export all data Active Reach holds about a contact:

  1. Go to People → Contacts → [contact] → Export data
  2. The system generates a JSON file containing:
    • Contact profile (all properties)
    • Complete event history
    • Delivery records
    • Segment memberships
    • Consent preferences

The export is available for download within minutes.

See Web SDK consent & privacy for implementing consent collection and management.

Cookie-consent state in localStorage is invisible to the CDP. Every consent UI in your app — including custom banners and toggles — must mirror channel consent to the contact graph so segmenters, playbook channel pickers, and the DPDP audit can see it.

Web SDK 1.13.0 onward exposes aegis.user.setOptIn(channel, granted) for this purpose:

// in your acceptAll / acceptEssential handler
for (const ch of ['email', 'sms', 'whatsapp', 'webpush']) {
  aegis.user.setOptIn(ch, granted);
}

The platform’s useCommerceEvents().recordMarketingConsent(granted) helper runs this loop automatically and is the recommended path on storefronts. Writing only to localStorage is not sufficient — the contact’s opt_in_<channel> traits remain stale and the contact will continue to receive sends that should have been suppressed.

What’s next

Data retentionData governance