CustomerId Backstamping with D365 Customer Insights - Data

Thomas_CI

Like ( 1 )

Report

Introduction

CustomerId Backstamping is the foundational feature from Dynamics 365 Customer Insights - Data (CI-D) that enables the link from a Dynamics 365 Contact (or Account, or Lead) back to its corresponding CI-D Customer Profile (and by extension to the associated CI-D insights, such as Measures).

This article will guide you through the mandatory prerequisites when setting-up your CI-D instance so that CustomerId Backstamping is operational and will also detail a step-by-step and end-to-end example of what CustomerId Backstamping concretely looks like in the different screens of the products.

This article is also part of a broader blog post series that explains how to surface CI-D information in other Dynamics 365 apps such as Dynamics 365 Sales (Sales) through customization of a Model-Driven App form to embed an ad hoc Canvas App.

CustomerId Backstamping also allows other scenarios, such as powering an end-to-end insight and segmentation strategy across CI-D and CI-J as described in this excellent blog post,

Note that a specific integration mechanism exists to allow surfacing CI-D activities in the Dynamics 365 timelines. This relies on a specific solution to be installed and doesn’t leverage CustomerId Backstamping, but it relies on similar prerequisites.

Context and Prerequisites

CI-D Customer Profiles and Dataverse Contacts

A critical aspect to understand relates to the tables CI-D and other Dynamics 365 apps respectively use to represent a customer:

CI-D, through the profile unification process, creates a Customer table in its primary storage with a system-assigned primary key, the CustomerId. The schema for this table is completely flexible and defined when configuring the profile unification. This table is then hydrated to the secondary storage as the CustomerProfile table in Dataverse (or msdynci_customerprofile)
CI-J, by default, uses Dateverse Contact or Lead tables as the audience for marketing campaign journeys. Other Dynamics 365 apps, such as Sales, can also use the Dataverse Account table in addition to Contact and Lead, depending on the type of audience at play.

To reconcile these concepts and allow to navigate from a Contact in a Dynamics 365 App to its corresponding CustomerProfile from CI-D, a link must exist between the two. The process that creates this link - a lookup column in the Contact table - is what we call the "CustomerId Backstamping".

For the sake of conciseness in this article, we’ll simply refer to the Contact table from this point on, but what will be described would equally apply for the Lead or Account tables

CI-D Storages

We have mentioned in the previous section that CI-D uses two storages, let's look at what they are and how they are used:

The primary storage is used to support at scale batch processing (e.g. profile unification, segment and measure calculation, etc.) and as such contains all tables CI-D creates as part of those processes as well as some system tables.
The secondary storage - also known as the “profile store” - corresponds to a subset of tables generated by CI-D and targeted for low latency access on a per-record basis. This “profile store” is what supports the “Customer 360” view in the CI-D portal and materializes itself as elastic tables in Dataverse, which CI-D populates or “hydrates” from the primary storage when the corresponding batch processes are finished. In addition to those tables natively hydrated by default, you can opt-in to also hydrate specific measures as their own elastic tables.

When installing CI-D the default for the primary storage is a Dataverse Managed Data Lake (also known as “Customer Insights storage” or "DV MDL") and this is the de-facto choice when working with any other Dynamics 365 Apps as it's the only option that supports CustomerId Backstamping.

Other Prerequisites and Overall Flow

The additional prerequisites for CustomerId Backstamping relates to how you ingest and unify Dynamics 365 Contacts in CI-D. Those are summarized in this overall diagram and will be illustrated in the following section.

Fig. 1. - CustomerId Backstamping end-to-end process

CustomerId Backstamping Example

Thanks to the CustomerId Backstamping process a direct link (or “lookup”) is created from a Contact record to its corresponding CustomerProfile record, this section details the steps involved to achieve this.

Let’s consider “Brett Bear”, a Contact in Dataverse:

Fig. 2. - Contact form, here in Dynamics 365 Customer Insights - Journeys

You start by ingesting the Contact table in CI-D with either:

After that, you configure the profile unification and set up the proper primary key for the Contact table.
Note that in our example a second table, Member, from an external loyalty system, is also ingested and brought to profile unification. This second table provides the additional attributes that we ultimately want to surface in the Contact form in Dataverse. A simple matching condition is set between the two tables on a common email address field.

Fig. 3. - Setting up profile unification

Once profile unification has run, and CustomerId Backstamping is finished, the CustomerProfile for “Brett Bear” is created and linked from its Contact.

Fig. 4. - customer profile in CI-D portal with its system generated CustomerId, primary keys from the two tables that contributed to it, and additional fields such as the “Loyalty Tier” or “Loyalty Score”.

In this example above, contactid and contactid_Alternate are the same, and only one value. This is because no duplicates were found for “Brett Bear” in the Contact table based on CI-D deduplication configuration.

If one or more duplicates had been found, all their primary keys would have been accumulated in the contactId_Alternate field as a comma-separated list, and each corresponding Contact record would link back to the same CustomerProfile.

Fig. 5. - CustomerId Backstamping hydration job successful completion

Fig. 6. - CustomerProfile record in Dataverse

Fig. 7. - Corresponding backstamped Contact record in Dataverse

Fig. 8. - Details of the created lookup, a Many:1 relationship between Contact and CustomerProfile. Indeed, several Contacts can be identified as duplicates and unified to the same CustomerProfile

Comments

*This post is locked for comments