Standardization of Attributes
![](../__attachments/40761239/2022-07-14_12-45-36.png?inst-v=d7c833f8-8709-46dd-9a03-727c8f6a3bec)
“If you think of standardization as the best that you know today, but which is to be improved tomorrow- you get somewhere.” - Henry Ford
While we’re experiencing the golden age of data and technology and there is no sign of it slowing, organizations are increasingly attending to the new data trends of 2022 and the foreseeable future. Amid the changes that came in and stayed, something that hasn’t changed much over the decades is how data is still the most valuable when we have something to compare it to. In other words, it’s easier to draw clear conclusions about your data when you have other data to measure it against.
To make sure that your data set is comparable to other data sets, data standardization needs to be the first thing for you to consider as you collect or analyze your first data point. Data standardization helps in ensuring that data is internally consistent, with each data type having the same format and content. Additionally, it helps establish consistently defined attributes, providing a comprehensive meaning to the data at hand. While standardization techniques might vary from one to another, Zeta has its own way of standardizing its customer data.
Zeta Standard Properties
User data with the following naming conventions are treated by Zeta in a special way and helps deliver features and insights that may otherwise be not available.
For example, if you track the income of your customers as income, Zeta can help surface the income distribution of your customers at the segment level. Similarly, if you track postal code as zip, you will be able to get geographic distribution insights and the ability to segment based on a radius around a zip code. This helps with geo-targeting use cases, such as triggering an experience as soon as someone gets closer to your store.
Property | Description |
---|---|
age | A numeric property that represents the age of the person. For example, 65, 42, 21 |
first_name | A string property that represents the first name of the person. For example, John, Joe, Peter |
last_name | A string property that represents the last name of the person. For example, Doe, Smith, Parker |
gender | A string property that represents the sex of the person. The expected values are one of the following: M, Male, F, Female. |
income | A numeric property that represents the annual income of the person in the currency specified at the account level. The expected values are numbers without any prefix or separators. For example, 100000, 120000 |
marital_status | A string property that represents the marital status of the person. The expected values are one of the following: Single, Married, M, Unmarried, U |
date_of_birth | A date-type property that represents the date of birth of the person in a standard ISO-8601 format. For example, 2002-01-31, 2010-11-29T18:50:30+00:00 |
year_of_birth | A 4-digit numeric property that represents the year of birth of the person. For example, 1972, 2001 |
race | A string property that represents the racial identity of the person. For example, African American, Black, Asian, Hispanic, Latino, White, Non-Hispanic White. |
ethnicity | A string property that represents the cultural identity of the person. For example, Arab, French, Dutch |
address_line_1 | A string property that represents the first line of the address. For example, 3 Park Ave |
address_line_2 | A string property that represents the second line of the address. For example, 33rd Floor |
city | A string property that represents the city of the person. For example, New York, San Francisco |
state | A string property that represents the state or province of the person. The expected values are full names of US and international states and provinces, as well as the abbreviated versions of US states. For example, NY, California, Normandy |
county | A string property that represents the administrative or political subdivision of the state of the person. For example, Baldwin, Cherokee, Franklin |
dma | A string property that represents the designated market area of the person. For example, Charlotte, Pittsburgh, Albany-Schenectady-Troy |
zip | A string property that represents the US or International ZIP or Postal Code of the person. US ZIP codes may include a 4-digit extension as long as they are separated by a hyphen. For example, 95051, 94104-1207, E15 2PF |
country | A string property that represents the country of the person. The expected values are the full name of the country or ISO two-letter country code. For example, France, India, the US, and GB. |
Additionally, ZMP utilizes the following key Identifiers based on what the system is configured to capture, and standard/required fields:
Identifier | Description |
---|---|
BSIN | An alphanumeric unique identifier that our system creates per person per site-id. Every single person(known/anonymous) in ZMP gets a BSIN. BSIN are globally unique, but from a usage perspective: they are tied to a particular site-id, ie: for API calls, a site ID needs to be passed in along with BSIN. For example, doe578 |
user_id and email | An alphanumeric property that represents the account ID of the person. For example, johndoe112 |
An alphanumeric property that represents the email of the person. For example, johndoe@gmail.com user_id and email are unique per site-id. This allows our customers to use either unique user_ids as identifiers OR email addresses as identifiers OR both at the same time. | |
zync_id | A numeric unique ID that is generated by the Zync Container Tag and assigned to each person who is browsing the site. We can use that zync_id to match the Data Cloud ID Graph. Although the zync_id remains the same for one user, it can change if they change their device or in case they clear their browser cookies. In such a case, the reidentification process can help you link the new zync_id with the existing user. For example, 112 |
email_md5 | Zeta has the ability to capture email_md5 for any prospect or known user in the same way it utilizes the user_id for any list upload. |
Property Mapping
There are times when you may have other systems generating data in a format that may not necessarily align with the standard format of Zeta. For such cases, we provide a way to map a non-standard property name to a zeta standard property. Once mapped they are treated in the same manner as a standard property.
1. Navigate to Settings > Audiences > Customer Properties.
![](../__attachments/40761239/2022-09-14_13-25-19%20(1).gif?inst-v=d7c833f8-8709-46dd-9a03-727c8f6a3bec)
2. Click on the Edit icon against the desired customer property you wish to map to a preset Zeta property.
![](../__attachments/40761239/2022-09-14_13-26-42%20(1).gif?inst-v=d7c833f8-8709-46dd-9a03-727c8f6a3bec)
3. Select the Zeta property you’d like to map to the selected property and click on Update Property.
4. Your customer property will be mapped to the selected Zeta property. Or in other words, your customer property will be standardized.
![](../__attachments/40761239/2022-09-14_13-29-11.png?inst-v=d7c833f8-8709-46dd-9a03-727c8f6a3bec)
If you can directly ingest customer properties that are in line with Zeta standardization, there is no need for property mapping.
Points to Remember
1. Property mapping is one-to-one. ie. only one non-standard property can be mapped to a standard property. Once mapped, the standard property will no longer be available for mapping unless unmapped.
2. A directly tracked standard property will invalidate any existing mapping. e.g. if you had no standard property tracked for age and a property named time_on_planet was mapped to age. Subsequently, if you start tracking a property by the name age, the mapping (time_on_planet → age) will be invalidated.
3. Ensure that the data type of the standard property matches the specification, as an incorrect data type will not be able to generate the aggregated insights. e.g. tracking a number with commas may be treated as a String.
Enhanced Insights
There’s an enhanced visualization of insights (standard properties) during audience exploration:
![](../__attachments/40761239/2022-07-14_15-33-37%20(1).gif?inst-v=d7c833f8-8709-46dd-9a03-727c8f6a3bec)
Customer exploration also displays demographic insights based on standard attribute data. (was previously only available for prospects)
![](../__attachments/40761239/2022-07-14_15-59-49%20(1).gif?inst-v=d7c833f8-8709-46dd-9a03-727c8f6a3bec)
Syndication
All standard properties are automatically mapped to properties accepted by the data partners (Facebook, Google Ads). Additional data points available help maximize the match rate.
Zeta Standard Property | Property as interpreted by Meta (Facebook) |
---|---|
city | ct |
state | st |
country_code | country |
date_of_birth | dob |
year_of_birth | doby |
zip | zip |
gender | gender |
first_name | fn |
last_name | ln |
Contacts/ Phone | phone |
maid | madid |
Google Ads
Zeta Standard Property | Property as interpreted by Google Ads |
---|---|
first_name | fn |
last_name | ln |
country_code | country |
zip | zip |
Contacts/ Phone | phone |
Yahoo does not standardize attributes.
If you cannot see this functionality, reach out to your Client Services Representative to get this enabled.