Profile Basics

profile union schema remember that the view of any real time customer profile is built using the schema's you defined and enabled for the profile this is what adobe refers to as the union schema of the profile you can see the union schema of the profile by doing the following click on profiles in the left rail click on union schema in the top nav remember that profile creates a union view for every xdm class you utilize this view to see what schema's contributed to what class, the identities within each class and any relationships review the union schema for the xdm individual profile class and expand out the tenant namespace you should see a number of items here that came from various schemas you defined the lid methodology and xdm modeling labs click on the account object and notice what appears in the right rail of the screen you can now see the details around object, what schema(s) and dataset(s) contributed to its formation and other relevant information the union schema is a great tool for understanding why certain elements exist within a profile and where they came from keep in mind that the union schema is observable meaning profile will only show fields that contain data when viewing an actual real time customer profile profile lookup click on profiles in the left rail and then in the top navigation select browse select the identity namespace of email enter the identity value of depeche mode\@dep com click on the view button to lookup the profile click on the link to the profile to see the profile's details you should see this now! take a minute to explore the profile, depeche mode, by looking at each tab in the top nav these are the tabs that you will use detail displays customize cards that show various aspects for the given profile attributes displays all the associated attributes for the given profile coming from the union schema events displays all the associated events for the given profile coming from the union schema audience membership displays the audiences that the profile is currently a member of view attributes navigate to the attributes tab and click view json let’s see how fields show up that came from the field groups you added to the customer account schema look for the parent node titled entity note the child object billingaddress (this came from personal contact details field group) "billingaddress" { "postalcode" "11355", "city" "new york city", "state" "ny", "street1" "108 ruskin terrace" } compare this to what the profile union schema has and you should lightbulb on what obserable means 😄 "billingaddress" { " repo" { "createdate" "datetime", "modifydate" "datetime", }, " schema" { "description" "string", "elevation" "double", "latitude" "double", "longitude" "double" }, " id" "string", "city" "string", "country" "string", "countrycode" "string", "createdbybatchid" "string", "dmaid" "integer", "label" "string", "lastverifieddate" "date", "modifiedbybatchid" "string", "msaid" "string", "postofficebox" "string", "postalcode" "string", "primary" "boolean" "region" "string", "repositorycreatedby" "string", "repositorylastmodifiedby" "string", "state" "string", "stateprovince" "string", "status" "string", "statusreason" "string" "street1" "string", "street2" "string", "street3" "string", "street4" "string" } observable schema literally means to only show the fields where data exists and hide the fields that do not contain data very different then traditional relational database! next look for consents object (this came from consent and preference details field group) "consents" { "marketing" { "sms" { "val" "y" }, "email" { "val" "y" } } } scroll down to tenant namespace, devbc , and look for plan object (this came from a custom created field group named 'dep plan details') "plan" { "planid" "m3", "type" "mobile", "name" "pro" } notice the aggregates object you defined to for the upsell use case those fields are also under the tenant namespace devbc they came from a different schema (dep customer aggregates) and a custom field group (dep aggregates) "aggregates" { "rollingsixmonthavgmonthlydatausage" 30, "rollingsixmonthtotaldatausage" 200 } view identity map you can also see a profile's associated identities as they are stored within a map based object named identitymap look for identitymap near the bottom of the json document this is a representation of all the identities you have passed in regardless if you used the identitymap field or marked a field using an identity descriptor "identitymap" { "ecid" \[{ "id" "34537751351243145301122536487445728054" }, { "id" "66385443304271800137026604878870723316" }, { "id" "34537751351243145301122536483456723542" } ], "email" \[{ "id" "dave gahan\@dep com" }, { "id" "depeche mode\@dep com" } ], "customerid" \[{ "id" "266242885" }], "gaid" \[{ "id" "266242 9013" }, { "id" "266242 9012" } ] } note there is no reference to the concept of “primary identity" within the identitymap the reason for is two fold the identitymap you see in profile attributes is created for each profile utilizing the identity service's graph the identity graph only cares about relationships between identities each identity is treated the same a is related to b and it does not matter if it was via a primary identity, person identity, etc if no identity graph is used the identitymap is composed of only the identity requested in the lookup when you built the customer account schema you only had one email field marked as an identity (i e personalemail address) did you notice though the identitymap has two email addresses! what is going on? identity graph is constantly recording new relationships and the values within those relationships as data flows into its service profile's behavior is to overwrite existing field values with new values as data is ingested into its service when you flag a field with an identity descriptor it is still a field for profile identity graph navigate back to the detail tab in the top nav and click on the view identity graph link found at the bottom of the linked identities card you should now see this screen the view above is the identity graph of the depeche mode profile and is broken up into a three (3) key areas identity graph visualizer shows the identities and their associated relationships within the profiles identity cluster identity graph details provides specific details around the overall identity graph namespaces, values and data sources that created all the relationships seen within the identity graph visualizer selected identity details displays detailed information on the selected identity along with the last five (5) batches where that identity was processed in a relationship the identity graph viewer displays both the relationships between all the identities as well information around the last time the identity relationship was seen and from what dataset lets view the identity graph of depeche mode using the customerid identity instead perform the following actions copy and save the customerid somewhere change the namespace value in the identity namespace box to customerid paste in the customerid value you saved from the previous step click the view button to see the identity graph that contains this identity using the new identity value notice how you see the exact same identity graph! any identity you use from this graph will always result in the same result changing identities go back to the profile viewer and lookup depeche mode using the customerid now change the identity namespace to customerid update the identity value using the customerid value you saved in the last section click the view button you should see the same profile you just viewed previously! the identity graph ensures that any identity you use results in the same profile when assembling the various profile fragments