--- title: "Validation and standardization" date: "2024-02-14T06:18:38+00:00" summary: "Discover how CDP validates and standardizes postal addresses, email addresses, and phone numbers. Learn about country-specific processes, data cleaning techniques, and validation statuses to ensure accurate customer information." image: type: "page" url: "/customer-data-platform/validation-and-standardization" id: "8e0c14aa-8a08-409f-9413-7628cd7b2a94" --- CDP applies the following standardization on data: * [Postal address validation and standardization](#postal-address-validation-standardization) * [Email address validation and standardization](#email-address-validation-standardization) * [Phone number validation and standardization](#phone-number-validation-standardization) Postal address validation and standardization --------------------------------------------- This data processing is done through a third-party component called Melissa Data. CDP supports the following countries: * `US` * `CA` * `UK` * `TR` ### Melissa Data validation for US addresses Melissa Data ingests the following information from the [Address feed](/customer-data-platform/data-integration/sftp/address-feed) shared by customers: * `Address1` * `Address2` * `Zip` * `City` * `State` * `CountryCode` It standardizes the data, processes the data against the USPS database, and provides the following information: * If the `CountryCode` is not provided, CDP defaults to `US` and tries to standardize and validate accordingly. * If the provided `CountryCode` is invalid, CDP does not validate the address and returns the result as invalid. * If the `CountryCode` is valid but not supported, CDP does not validate the country. CDP sends the data through as it is. * If Melissa Data is unable to validate the combination of `Address1`, `Zip`, `City`, `State`, and `Country`, it tries to revalidate the address by using the combination of `Address2`, `Zip`, `City`, `State`, and `Country`. This is called field shuffling or swapping. If the updated combination is validated, Melissa Data returns the address as `Address2`, `Address1`, `Zip`, `City`, `State`, and `Country` in the same order. Therefore, CDP swaps `Address1` and `Address2` in DW. * **Certified**: This field indicates whether the address is Coding Accuracy Support System (CASS) certified. CASS specifies that the street exists and the street number falls in the range of street numbers on that street. It does not necessarily mean that this is a deliverable address, but the address meets the standards and can be standardized by the USPS software. In addition, if you provide CASS certification to USPS, you are eligible for postage discounts. However, few CASS-certified addresses can be undeliverable. * **DPVConfirm**: This field indicates whether the street exists or the street number falls in the range of street numbers on that street. It also indicates whether this is an actual stop for the postal carrier. As USPS verifies the postal carrier’s stop at the location, Delivery Point Verified (DPV) increases the chances of delivering the mail. However, if an address is not **DPVConfirm**, it does not mean that the address is not deliverable. For example, an address can be a non **DPVConfirm** because it does not include an apartment number, or the apartment number on the address cannot be verified by USPS. Mailers mail these records assuming that the postal carrier knows how to deliver the mail to the person in the apartment building. * For a given address, the combination of **Certified** and **DPVConfirm** ensures the best deliverability for the client’s campaigns. However, a few such certified addresses might be undeliverable. Alternatively, a few non-certified addresses might be deliverable, as the USPS certification system does not cover all cases. * **ZipExt** or **ZIP+4**: This field is applicable to the US addresses only. This is a precise version of the zipcode, which ensures easier delivery route planning and reduced mailing cost. This is returned only when **DPVConfirm** for the address is `true`. ### Melissa Data validation for UK addresses The processing is identical for every tenant. However, Melissa Global Data for `UK` addresses can be used only in the EU data center. CDP uses the same process for validating `UK` addresses as is used to validate `US` and `CA` addresses. This is done by populating **Certified** and **DPVConfirm** attributes in UDM with their `UK` equivalent. ### Melissa Data validation for TR addresses The processing is identical for every tenant. However, Melissa Global Data for `TR` addresses can be used only in the EU data center. CDP uses the same process for validating `TR` addresses as is used to validate `US` and `CA` addresses. This is done by populating **Certified** and **DPVConfirm** attributes in UDM with their `TR` equivalent. Email address validation and standardization -------------------------------------------- This data processing is done through a third-party component called Melissa Data. To process email addresses through this component, email addresses must have valid syntaxes with known domains. Additionally, email addresses must not be in the list of known spam-traps. After processing the data, Melissa Data returns: * The following values or email statuses in UDM+: * **V**: Indicates that the email address is verified. The syntax is valid, and `DatabaseLookup` or `MXLookup` confirmed the validity of the domain name of the submitted email address. * **U**: Indicates that the email address is not verified. The syntax is valid, but `DatabaseLookup` did not confirm the validity of the domain name of the submitted email address. However, the domain is not found in the list of invalid domain names. * **X**: Indicates that the email address is incorrect. The syntax is invalid. For example: * The address does not contain `@`, domain, or mailbox. * The address belongs to a known spam-trap. * `MXLookup` did not locate the domain name of the submitted email address. * The list of invalid domains contains the domain name. * **NULL**: No email was sent to Melissa Data. * Email addresses that contain obvious errors and forbidden characters are often cleaned up. For example, `sue.gore.@leeaudio.net` is corrected as `sue.gore@leeaudio.net`. Additional examples: Input Output Email Status `erisa85d@hotmail.com` `erisa85d@hotmail.com` `V` `erisa85d@homtail.com` `erisa85d@homtail.com` `U` `erisa85d@@hotmail.com` `erisa85d@hotmail.com` `V` `erisa85d@whatever.com` `erisa85d@whatever.com` `X` `erisa85d@hotmailcom` `erisa85d@hotmail.com` `V` `erisa85d@hotmail.co` `erisa85d@hotmail.co` `U` CDP analyzes your most occurring values and ignores dummy values such as `none@none.com`. While surveying your data, CDP might come across a few high occurring values with a valid format. The values might be linked to marketing tests, resellers, or bulk buyers. In such cases, Acquia works with you to confirm the proper course of action based on what suits your business needs. Phone number validation and standardization ------------------------------------------- This data processing is done through a third-party component called Melissa Data. Important This feature is available only for the US and Canada. CDP cannot check the actual country of the customer. You must use this feature only for the US and Canada phone numbers. However, if you use this feature for non-US numbers, international formats and numbers are not corrected properly. * Validation: When validation is enabled, it returns the following in the `validity` UDM column: * `V` for valid numbers * `X` for invalid numbers The validation process provides the following results: * The `primaryphone`, `secondaryphone`, and `mobilephone` are formatted. * The `primaryphone`, `secondaryphone`, and `mobilephone` use the default input number if invalid (unformatted). * The `primaryphonevalidity`, `secondaryphonevalidity`, and `mobilephonevalidity` are populated with `V` if valid and `X` if invalid. * Standardization occurs only when the phone number is considered valid. Standardization: * Separates the area code, whenever applicable * Splits the prefix, suffix, and extensions, whenever applicable CDP analyzes your most occurring values and ignores dummy values such as `0000000000`. While surveying your data, CDP might come across a few high occurring values with a valid format. The values might be linked to marketing tests, resellers, or bulk buyers. In such cases, Acquia works with you to confirm the proper course of action based on what suits your business needs.