Consent Revocation vs. Historical Reports
A healthcare-adjacent retailer uses CJA for marketing analytics. A customer exercises a right-to-be-forgotten request. The privacy team removes the customer's rows from the source dataset in Platform and expects CJA to reflect the deletion immediately. Two weeks later, a Workspace dashboard still shows the customer's purchase in a 'Top Customers' table and in an audience that was exported to a destination. The dataset has a 90-day connection window and daily refresh. The customer's crm_id was used as the person namespace for stitching.
1. Explain the gap between the Platform deletion and the CJA dashboard still showing the customer, and what must happen for CJA to reflect it.
Read the worked answer
Deleting rows in the source dataset does not instantly rewrite CJA's processed data. CJA reads from the connection and maintains its own processed representation; the deletion propagates only when the affected data is re-read and reprocessed on a subsequent refresh, and only within the connection's data window.
Key mechanics:
- Refresh cadence: daily refresh means the deletion should be picked up on the next refresh if the affected dates are inside the 90-day window. Two weeks later, if the dashboard still shows the customer, either the refresh hasn't reprocessed those dates, or the deletion didn't propagate to the connection.
- Stitching: the
crm_idwas the person namespace. Deleting the CRM ID row doesn't necessarily un-stitch previously stitched anonymous events; the stitched person record may persist until reprocessing. - Exports/audiences: an audience already exported to a destination is outside CJA's control - the destination must be told to delete. CJA can't reach into a third-party system.
- Cached/derived components: saved filters, calculated metrics, and published projects may hold derived state; verify the underlying data first, then the derived layer.
So the gap is expected: deletion is a source action; CJA reflection requires reprocessing, and downstream exports require separate action.
2. What concrete steps should the developer take to close the gap and prevent recurrence?
Read the worked answer
Close the gap now:
- Confirm the deletion actually reached the connection's source (row count for that CRM ID in the dataset = 0).
- Trigger/await a refresh covering the affected dates; verify the customer no longer appears in raw (non-derived) views.
- Re-check stitched person records - if the CRM ID was the person namespace, confirm the person record is gone, not just the raw row.
- Identify every destination/audience export containing the customer and issue deletion requests to each downstream system.
- Rebuild or refresh any calculated metrics/filters that may have cached the customer.
Prevent recurrence:
- Document that source deletion ≠ CJA reflection; add a step to the privacy runbook to trigger a targeted refresh and verify in CJA.
- Map all downstream exports so deletion requests fan out automatically.
- For right-to-be-forgotten, consider whether the person namespace should be a non-PII surrogate so deletion is cleaner.
- Add a monitoring check: after a deletion request, assert the customer's ID returns zero rows in CJA within the SLA window.
- Confirm the 90-day window doesn't leave older data outside reprocessing scope - if the customer's data is older than 90 days, it may already be outside the window and need a different deletion path.