Merge Policies

what is it? you see merge policies in the profile viewer every time you search for a profile (you probably just didn't realize it did something) a merge policy does two things provides the instructions for how to assemble the fragments within the profile store (i e identity stitching) there are two options use the identity graph (i e identity service) do not use the identity graph (i e rely on only the identity provided to find similarly stored profile fragments) tells the profile service how to resolve field conflicts within the xdm individual profile class based datasets when a field may come from multiple datasets (i e merge method) there are two options timestamp precedence use the most recent record from all datasets as the truth set and let all other records fill in the gaps in order of recent to oldest dataset precedence pick what xdm individual profile datasets are allowed to be used to form the profile and in what order to assemble them when the merge method of dataset precedence is chosen you can choose which xdm individual profile and xdm experience event datasets are allowed to be used in the profiles formation the timestamp precedence merge method always utilizes all datasets every sandbox requires at least one merge policy marked as the default merge policy in order for segmentation and profile to function many times we design so that we don’t need to use a custom merge policy that uses dataset precedence rather than having multiple datasets record the same field, we give them unique names, e g first name crm first name loyalty first name web form this allows a marketer to choose which datasource+field rather than the system choosing one based on a ruleset they may not understand and possibly choosing fields of the profile from one source and other fields from another without understanding it is happening for our data model we do not need to resolve any field conflicts, so no custom merge policy is needed to best understand how merge policies work with the identity graph you will create one that does not utilize the identity graph for id stitching create a no stitch merge policy let’s create a merge policy that doesn’t use the id graph so you can see its behavior with profile formation create click on profiles in the left rail click on merge policies in the top navigation click on create merge policy near the far right of your screen configure you now need to configure the merge policy settings enter the following information setting value name no id stitching id stitching none default merge policy disabled active on edge merge policy disabled when you are done click next select profile datasets for the merge method select timestamp ordered click next select experience event datasets remember that if you select timestamp ordered for the merge method you are telling the profile service that all xdm individual profile and experience event class based datasets will participate in the formation of the profile therefore you can simply click next as there nothing to do in this step review in the final step you'll see a preview of the settings you've chosen and sample profiles showing you the merge policy in action click the finish button to create the merge policy merge methods in action remember the identity graph of the profile, depeche mode, looked like the below screenshot to understand how profile service works its best to ignore using this identity graph during the assembly process compare using email go ahead and open the profile viewer following the below steps 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 do another search for the depeche mode profile but this time using the no id stitching merge policy right click on profiles in the left rail and then select open in a new tab in the top navigation select browse select the merge policy of no id stitching 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 comparing both views of the profile you should notice they are very different some attributes and identities are missing from the version that uses the "no id stitching" merge policy if you look at each profile's events you will notice that the profile using the no id stitching merge policy only contains a single event whereas the other version contains all the events the single event on the no id stitching version of the profile is because that event is stored using the primary identity of "personalemail address" remember that when using a merge method that does not use the identity graph profile will rely on only the identity provided to find similarly stored profile fragments compare using customerid you can look at the various fragments of the depeche mode profile using some of the other identities from the graph try looking up the same profile again with the no id stitching merge policy but this time using the customerid namespace and value provided below identity namespace value customerid 266242885 question's to ask yourself question notice anything about the attributes? there are none, why? answer you loaded attributes using email as your primary identity question notice anything about the events? answer the only events that show up are the ones that have customerid as the primary identity compare using gaid try looking up the same profile again with the no id stitching merge policy but this time using the gaid namespace and value provided below namespace value gaid 266242 9013 question to ask yourself question no profiles were found! what is going on? why are no profiles found? answer there are no profile fragments that are stored using that gaid value as a primary identity profile + identity quick synopsis profile store contains profile fragments stored using the primary identity identity graph contains the relationships between two (2) or more person based identities when the identity graph is used with the profile store you can think of it as giving directions for how to find the right profile fragments treating each identity value in the identity graph as primary identities without the identity graph the profile store can only retrieve profile fragments using a single identifier (i e primary identity) have some extra time and want to experiment search for other profiles in the ui you know of that have two identities see how some events are stored against one fragment but not the other see how some profile attributes are stored against one fragment but not the other go to a profile you already have looked up and re lookup it up using the no id stitching merge policy note the difference