Sample Delete requests
With a delete request using the API values in the first row of the table, the hit table will be updated to look something like this:
Only columns on rows containing
AAID=77
and a DEL-DEVICE
label are impacted.Only celcolumnsls on rows containing
user=Mary
and a DEL-PERSON
label are impacted. Also, in practice, the variable containing A_ID
would probably be a prop or an eVar. Its replacement value would be a string starting with Privacy-
, followed by a random number (GUID), rather than replacing the numeric value with a different, random numeric value.Note the following:
- Cells on rows containing
user=Mary
and aDEL-PERSON
label are impacted. - Because of ID expansion, cells on rows containing
AAID=77
,AAID=88
orAAID=99
(which are the AAID values on rows containinguser=Mary
) and aDEL-DEVICE
label are impacted. This includes cells with aDEL-DEVICE
label on rows whereuser=Mary
. This causes cells in rows 4 and 5 (as well as rows 1-3) withDEL-DEVICE
labels (AAID, MyEvar2 and MyEvar3) to be obfuscated. - The expandIDs setting does not expand to the call to include values present in MyEvar3 (
X
,Y
andZ
), which has an ID-DEVICE label, whenuser=Mary
. ExpandIDs only expands to include Visitor IDs (AAIDs in this example, but also the ECID) on rows whereuser=Mary
. Thus the last two rows, which contain MyEvar3 values ofX
andZ
are not impacted. MyEvar2
in the fourth and fifth rows are updated because these rows contain the same Visitor ID values (77
and88
) as those on the first and second rows. As a result, ID expansion includes them for device-level deletes.- The values of
MyEvar2
in rows two and five match both before and after the delete. However, after the delete they no longer match the valueN
that occurs in the last row, because that row was not updated as part of the delete request. MyEvar3
behaves very differently than it did without ID expansion, because without ID expansion, noID-DEVICES
matched. Now,AAID
matches on the first five rows.