![](\"/images/guides/composable-audiences/data-models-create-user-model-1.png\")
User Data Models define the core user dataset that Composable Audiences uses for segmentation. You must create at least one user data model in order to create a composable audience. Like all data models, they are built from a SQL query that selects user records and attributes from your cloud data warehouse, with a required primary ID column to uniquely identify each user. This model forms the foundation for all audiences and can be linked to other models, such as events or subscriptions, for richer targeting.
\nHere is a simple SQL query you might use to define a user data model for your customers:
\nSELECT\n user_id,\n email,\n first_name,\n last_name,\n signup_date,\n country,\n marketing_opt_in,\n loyalty_tier\nFROM ecommerce.usersuser_id is the primary ID for each record (each user must be unique).signup_date helps you identify new versus long-standing users.country lets you segment users by geography.marketing_opt_in is useful for filtering users who have consented to marketing communications.loyalty_tier can be used to group customers into Bronze, Silver, or Gold segments.With this model in place, you could build an audience such as “new users who signed up in the past 30 days and have opted into marketing emails.”
\nThis example focuses on who the user is (attributes and profile information). When combined with an Event Data Model (which captures what the user does) and a Generic Data Model (which adds extra context), you can build more powerful audiences.
\n\n
user_id or customer_id) retrieved from your SQL query to serve as the unique identifier for each user.![](\"/images/guides/composable-audiences/data-models-create-user-model-2.png\")
![](\"/images/guides/composable-audiences/data-models-create-user-model-3.png\")
Click Save Data Model to continue.
\nMappings control how your warehouse data is interpreted in mParticle and by downstream partners.
\nUser identifiers should be mapped to the correct user identifier type (like Email Address or Customer ID) so audiences can be matched and activated within downstream destinations. Descriptive fields, like a loyalty status or signup date, should be mapped to “User Attributes” to make them easier to find and use in the Audience Builder.
\nAlthough mappings are optional, you will likely need them to make sure your downstream integrations can effectively use your audience data. Downstream partners usually require identifiers for accurate matching, and mapped attributes make important fields easier for marketers to discover when building marketing campaigns.
\n![](\"/images/guides/composable-audiences/data-models-create-user-model-4.png\")
After completing your column mapping settings, confirm the identity settings for your user data model. These settings control whether this data model can be used in a hybrid audience and, if so, which identities mParticle will use to match warehouse users to mParticle profiles.
\nEnable this Data Model for Hybrid Audiences must be turned on if you want any composable audience built on this model to support hybrid audience membership or profile enrichment. Without this toggle enabled, audiences built on this model will operate in warehouse-only mode and cannot write membership to user profiles.
\n![\"screenshot](\"/images/guides/composable-audiences/data-models-create-user-model-identity-settings-1.png\")
Under Choose identities to match on, review and enable the user identifiers that mParticle should use to match user records from your warehouse with user profiles in mParticle.
\n![\"screenshot](\"/images/guides/composable-audiences/data-models-create-user-model-identity-settings-2.png\")
These are the identities mParticle will look up when a hybrid-enabled audience runs. For each user record in the warehouse result, mParticle searches for an mParticle profile that shares one of these identity values. Choose identities that are reliably present in both your warehouse and your mParticle profiles — for example, an email address or a customer ID — to maximize the number of users that can be successfully matched.
\nThe table lists each identifier retrieved from your warehouse and shows:
\nIn order for the identifiers in your warehouse to appear in this list, they must be correctly mapped to their corresponding mParticle identifiers in the mapping settings.
\nThe Identity Control column shows how the mParticle identifiers that your warehouse identifiers are mapped to are configured for identity resolution.
\nWhile these are referred to as “Identity Controls,” they are not modifiable here. These are read-only values that reflect how these identifiers are configured in mParticle. You should use this column to help verify that you are mapping your warehouse identifiers to the correct mParticle identifiers
\nThe Mapping Cardinality column describes how identifiers in your warehouse relate to their corresponding identifiers in mParticle. You may see the following patterns:
\nOne-to-One: Each warehouse identifier value maps to exactly one mParticle identifier value, and each mParticle identifier value maps to exactly one record in your warehouse. This occurs when:
\nOne-to-Many: Each warehouse identifier value maps to one mParticle identifier value, but the same mParticle identifier value may map to multiple records in your warehouse. This occurs when:
\nMany-to-One: Multiple warehouse identifier values can map to the same mParticle identifier value. Each warehouse identifier value still maps to a single mParticle identifier value. This occurs when:
\nMany-to-Many: Multiple warehouse identifier values can be mapped between multiple mParticle identifier values. This occurs when:
\n