Working with the data
On this page
Understanding the data
Each download contains identifiers provided by consumers as part of their deletion requests via DROP. These identifiers are standardized, hashed and then provided as part of a consumer deletion list.
When you download data from DROP, you receive a ZIP file containing one CSV file for each selected consumer deletion list.
Every row in the CSV includes an Id column that identifies a single work item. The corresponding Hash column contains the hashed identifier you will compare against your own records.
Work item Ids are case-sensitive, and contain 12 alphanumeric characters (Base62). Work item Ids are unique across consumer deletion lists. Work item Ids are permanently tied to a single work item. Please find example work item IDs below in Consumer deletion list file schema.
When you upload via DROP, your response file must include that same work item identifier in the Id column alongside the status code you assign based on the outcome of your matching, whether for a first-time upload or an amendment.
Consumer deletion lists
DROP delivers consumer deletion request data organized by list type. There are six list types, and each list includes one or more consumer identifiers. To generate your API key, you must select which list(s) you will process.
Your download in DROP will contain one CSV file per selected list. If a selected list has no identifiers available, the download will include an empty CSV file for that list with headers only.
After initial download and completed upload, future downloads will include only new identifiers since previous list download.
If any previously delivered identifiers have been removed, for example if a consumer cancels their deletion request, the download will also include a file containing those removed identifiers across all selected lists.
Data brokers must select every consumer deletion list containing a consumer identifier corresponding to personal information about that consumer within the data broker’s own records. However, a data broker may select fewer lists if the consumer identifiers used across multiple lists would lead to matches with the exact same set of consumers in the data broker’s records.
Data brokers are not required to respond with status for an empty file or for removed identifiers.
The identifiers provided in the consumer deletion lists are hashed. There is no option to download raw consumer identifiers from DROP.
Consumer deletion lists
| Code | Identifier | Type |
|---|---|---|
NDZ | First Name + Last Name + Date of Birth + ZIP | Composite hash |
Email | Email address | Single-field hash |
Phone | Phone number | Single-field hash |
MAID | Mobile advertising ID | Single-field hash |
NameVIN | First Name + Last Name + VIN | Composite hash |
CTVID | Connected TV identifier | Single-field hash |
Consumer data properties
| Property | Format | Details |
|---|---|---|
| Name | Separate First Name and Last Name fields | Names are collected, standardized, and hashed separately |
| Date of Birth | YYYYMMDD | Eight digits, four-digit year |
| ZIP Code | Up to 5 alphanumeric characters | Strip non-alphanumeric characters, remove leading zeros, and use the first five characters |
| String | Validated as a valid email address | |
| Phone | Last 10 digits only | Strip non-numeric characters, then keep the last 10 digits |
| MAID | 32 hexadecimal characters | Mobile Advertising ID |
| VIN | 17 alphanumeric characters | Vehicle Identification Number |
| CTVID | 8 to 32 alphanumeric characters | Unique device identifier for smart TVs, streaming players, and gaming consoles |
Endpoints
GET /data/downloadPOST /data/-uploadPOST /data/-amend
File naming convention
Downloaded CSV files follow a standard naming convention. Response CSV files are strongly encouraged to use the corresponding downloaded file name. This makes files easier to match, review, troubleshoot, and reconcile. If you upload multiple response files for the same downloaded list, add a suffix to the file name using an underscore followed by up to 10 alphanumeric characters.
<YYYYMMDD>_<DataBrokerId>_<DataType>[_<OptionalSuffix>].csv
| Field | Description |
|---|---|
YYYYMMDD | File date |
DataBrokerId | Your short broker identifier, currently 4 digits. This ID is provided in the file name you download |
DataType | List type code: NDZ , Email , Phone , MAID , NameVIN , or CTVID. For removed identifiers, the file type is Removed |
OptionalSuffix | Optional. Up to 10 alphanumeric characters to differentiate uploads |
Example file names:
20260312_4821_NDZ.csv
20260312_4821_Email.csv
20260312_4821_NameVIN.csv
20260312_4821_Email_part01.csv
20260312_4821_Removed.csv
File encoding and formats
- CSV encoding: UTF-8
- Hash input encoding: UTF-8
- Hash output format: Base64
- Download format: ZIP archive containing CSV files
- Upload format: Individual CSV files sent via
multipart/form-data
Consumer deletion list file schema
Deletion list files use the same schema. The list type determines how the Hash value was generated.
| Column | Description |
|---|---|
Id | Work item identifier |
Hash | SHA-256 Base64 hash |
For Email, Phone, MAID, and CTVID lists, the Hash value is generated from a single standardized identifier.
For NDZ and NameVIN lists, the Hash value is the final hash generated through composite hashing.
Example:
Id,Hash
A7kP2xQ9Lm4R,KA18MT/ph6IHYjzT9zwETySDQyvSh87YuoSBpOQtkhE
Removed identifiers file schema
If previously delivered identifiers have been removed, the download will include a separate “Removed” CSV file.
| Column | Description |
|---|---|
Id | Work item identifier |
Hash | SHA-256 Base64 hash |
ListType | List type code: NDZ, Email, phone, MAID, NameVin, or CTVID |
Example:
Id,Hash,ListType
A7kP2xQ9Lm4R,KA18MT/ph6IHYjzT9zwETySDQyvSh87YuoSBpOQtkhE=,Email
Upload file schema
Your response file must use the header Id,Status.
Single-field lists (Email, Phone, MAID, CTVID)
| Column | Description |
|---|---|
Id | Work item identifier from the downloaded file |
Status | Numeric status code |
Example:
Id,Status
A7kP2xQ9Lm4R,2
bK8rT3nV6pZa,5
x92LmQ8Zp3Rt,4
Status codes
| Code | Label | Meaning |
|---|---|---|
| 2 | Exempted | Match found and personal information is exempt |
| 3 | Deleted | Match found and non-exempt personal information was deleted |
| 4 | Opted out | Multiple consumers are linked to the same identifier and all were opted out of sale or sharing |
| 5 | Not found | No match found after completing the matching process |
For more information on the legal requirements based on match outcomes, see California Civil Code section 1798.99.80 et seq. and CCR, title 11, section 7600 et seq.
Hashing and standardization
DROP provides consumer identifiers in hashed form. To match DROP identifiers against your own records, you must standardize and hash the identifiers in your records using the same rules. If your records are already standardized and hashed according to the rules below, you do not need to standardize and hash again.
General rules
- Apply the identifier-specific standardization described below.
- Hash with SHA-256 using UTF-8 input encoding.
- Output as Base64.
Tip: A SHA-256 Base64 hash is typically 44 characters and commonly ends with =.
Name standardization
Names are stored as separate First Name and Last Name values.
- Use lowercase values
- Replace accented Latin characters with plain ASCII equivalents, such as å is a, ö is o, and ñ is n.
- Replace supported special Latin characters with common plain ASCII equivalents. ß is ss, æ is ae, œ is oe, ø is o, and ł is l.
- Transliterate Greek and Cyrillic characters to Latin equivalents using a common transliteration library or method. For closest alignment with DROP, use or compare against the DROP Transliteration Mapping.
- Leave Chinese, Japanese, Korean, Arabic, and Hebrew characters unchanged.
- Treat compound first names as a single unit (e.g., “Juan Pablo” is juanpablo)
- Remove hyphens, apostrophes, spaces, punctuation, symbols, and other non-letter/non-digit characters.
DROP Transliteration Mapping:
Greek
| Greek letter | Latin letter |
|---|---|
| α | a |
| β | v |
| γ | g |
| δ | d |
| ε | e |
| ζ | z |
| η | i |
| θ | th |
| ι | i |
| κ | k |
| λ | l |
| μ | m |
| ν | n |
| ξ | x |
| ο | o |
| π | p |
| ρ | r |
| σ | s |
| ς | s |
| τ | t |
| υ | y |
| φ | f |
| χ | ch |
| ψ | ps |
| ω | o |
| ά | a |
| έ | e |
| ί | i |
| ή | i |
| ύ | y |
| ό | o |
| ώ | o |
| ϊ | i |
| ΐ | i |
| ϋ | y |
| ΰ | y |
Cyrillic
| Cyrillic letter | Latin letter |
|---|---|
| а | a |
| б | b |
| в | v |
| г | g |
| д | d |
| е | e |
| ё | yo |
| ж | zh |
| з | z |
| и | i |
| й | y |
| к | k |
| л | l |
| м | m |
| н | n |
| о | o |
| п | p |
| р | r |
| с | s |
| т | t |
| у | u |
| ф | f |
| х | kh |
| ц | ts |
| ч | ch |
| ш | sh |
| щ | shch |
| ъ | [removed] |
| ы | y |
| ь | [removed] |
| э | e |
| ю | yu |
| я | ya |
| є | e |
| і | i |
| ї | i |
| ґ | g |
| ў | u |
Special Latin
| Special Latin letter | Latin letter |
|---|---|
| ß | ss |
| æ | ae |
| œ | oe |
| ø | o |
| ð | d |
| þ | th |
| ł | l |
| đ | d |
| ħ | h |
| ŋ | n |
| ı | i |
| ij | ij |
| ŀ | l |
Hashing example:
| Input | Standardization | SHA-256 Base64 |
|---|---|---|
| Juan Pablo | juanpablo | 91hIbrbzNeqHs3o81O5yNrXUj7wDd2shvZ6THKi9qz8= |
| Martinez | martinez | 2wRPGbwBNxhShjRczx8GfS2c4cjvs4NJskeWloUNtp8= |
Date of birth standardization
Convert to YYYYMMDD format. Use a four-digit year.
| Input | Standardization | SHA-256 Base64 |
|---|---|---|
| July 4, 1776 | 17760704 | skXYXxBER6HQTZ3rXSZH1wVGLQ054mS5rbR/bwvzy4I= |
ZIP code standardization
Keep alphanumeric characters only, For ZIP+4, drop the +4. Convert to lowercase, remove leading zeros, and use the first five characters present.
| Input | Standardization | SHA-256 Base64 |
|---|---|---|
91790-3771 | 91790 | 2FPZucR4x7U8KlM+SFAX4LPGhwNz/PIZUCSUdDh0o/s= |
M1B 1A1 | m1b1a | n8L9q8mVeT6Xt9/EeUNiTukGDrkbPJ3DvOEx14uElxk= |
00712345 | 71234 | aeNUYKh7Xw5sqpxSbSP9eOHsj6iXewbUyavv89DIuhQ= |
00300-9999 | 300 | mDvWFLta/s5as7YCP3EUfNe2vCMU+dJ690IlQcZVg4k= |
Email standardization
Remove whitespace and convert to lowercase. Do not remove dots, plus signs, or other characters.
| Input | Standardization | SHA-256 Base64 |
|---|---|---|
Anna.Smith@Domain.com | anna.smith@domain.com | KA18MT/ph6IHYjzT9zwETySDQyvSh87YuoSBpOQtkhE= |
danielle.johnson12@example.com | danielle.johnson12@example.com | mKDnDvwF2inxrKcK1hJN2TRkxPfL6kzNNTtU12eH8Bw= |
Phone standardization
Strip all non-numeric characters. Use the last 10 digits, or all digits if fewer than 10 are present.
| Input | Standardization | SHA-256 Base64 |
|---|---|---|
+1(415)555-9317 | 4155559317 | vGM7y5n+hBXRSEAklhHDPCbysyNgYTmXdMcagGUOY8E= |
+84(90)123 4567 | 4901234567 | ptzVkgbv9DonwvPCHmXmJ2SEOaolSh37z3ZzY/Gmm+U= |
+354(123)4567 | 3541234567 | Btrzydf5K6ALAKKXJGFHSx7u5bDzHC9WlVYtpq1n2rY= |
5551273811 | 5551273811 | jr/RAWYVN+ODBf2vRxwBASPwiO4x27OGI1y3IDhcwLo= |
VIN standardization
Keep only alphanumeric characters and convert to lowercase.
| Input | Standardization | SHA-256 Base64 |
|---|---|---|
1HGCM82633A004352 | 1hgcm82633a004352 | iNswy1m+0VSt8jAfFrvaiQ1R/0HAbgSwNGkwqo6QBss= |
MAID standardization
Keep only hexadecimal characters ( 0–9 , a–f ) and convert to lowercase. The standardized value must be 32 characters.
| Input | Standardization | SHA-256 Base64 |
|---|---|---|
a3f1c2d4-5678-90ab-cdef-1234567890ab | a3f1c2d4567890abcdef1234567890ab | 250KY6lOgzYUB3EHrkbDCE2kMEZQE69SF38muhoDudI= |
CTVID standardization
Keep only alphanumeric characters and convert to lowercase. The standardized value must be between 8 and 32 characters.
| Input | Standardization | SHA-256 Base64 |
|---|---|---|
SmartTV_9F8E7D6C | smarttv9f8e7d6c | d9fxuTIrKksBXYDlaWsvQbcyUUfCbUx7v78gd+KP+tc= |
Composite hashing
The NDZ and NameVIN list types use composite hashing. This means each field is standardized and hashed first, then the resulting Base64 hashes are concatenated and hashed again.
NDZ: Name + Date of Birth + ZIP
- Standardize and hash each field separately (SHA-256, UTF-8, Base64).
- Concatenate the four Base64 hashes in this order:
FirstName + LastName + DOB + ZIP - Hash the concatenated string using SHA-256, UTF-8, and Base64.
Example: Danielle Johnson, DOB July 4, 1985, ZIP 91790.
| Field | Standardized | SHA-256 Base64 |
|---|---|---|
| First Name | danielle | 5dUD1FgiKcTJq+JQ5JZUdlyIXrSbtJ338YYbt5/HNG4= |
| Last Name | johnson | K+TjOqPiH2/3rRRPj9WCKKHM47UDQLSAX/DGNIDuxIg= |
| DOB | 19850704 | IWi7qxOAbBJe0fNciDj76Eg84gmj40rB7aNMK/VnFOI= |
| ZIP | 91790 | 2FPZucR4x7U8KlM+SFAX4LPGhwNz/PIZUCSUdDh0o/s= |
Concatenated string: 5dUD1FgiKcTJq+JQ5JZUdlyIXrSbtJ338YYbt5/HNG4=K+TjOqPiH2/3rRRPj9WCKKHM47UDQLSAX/DGNIDuxIg=IWi7qxOAbBJe0fNciDj76Eg84gmj40rB7aNMK/VnFOI=2FPZucR4x7U8KlM+SFAX4LPGhwNz/PIZUCSUdDh0o/s=
Final hash: PQOfn1RffEKmqMmNAzDKKaoZCwxWbQZkQzPWmQo9REA=
NameVIN: Name + VIN
- Standardize and hash each field separately (SHA-256, UTF-8, Base64).
- Concatenate the three Base64 hashes in this order:
FirstName + LastName + VIN - Hash the concatenated string using SHA-256, UTF-8, and Base64.
Example: Eve Genesis, VIN, 1HGCM82633A004352.
| Field | Standardization | SHA-256 Base64 |
|---|---|---|
| First Name | eve | hSYq33RRi7twx8uUzWFZ2RZp5age3x7+vVQ+rb2p+is= |
| Last Name | genesis | ruutSnlvzC4V3ExgYbRe2bNz8mrfx5jKfS2MxYGCcY4= |
| VIN | 1hgcm82633a004352 | iNswy1m+0VSt8jAfFrvaiQ1R/0HAbgSwNGkwqo6QBss= |
Concatenated string: hSYq33RRi7twx8uUzWFZ2RZp5age3x7+vVQ+rb2p+is=ruutSnlvzC4V3ExgYbRe2bNz8mrfx5jKfS2MxYGCcY4=iNswy1m+0VSt8jAfFrvaiQ1R/0HAbgSwNGkwqo6QBss=
Final hash: rtnDuXIe63jXYQQXW5r07GJ7lSsrib8+46QuKFwkOmk=
Use the Standardization and Hashing Tool in the DROP Sandbox to verify your implementation of the standardization and hashing requirements.