Customer Data Integration — объединение информации о клиентах, изначально разбросанной по множеству приложений/баз данных. Результат объединения, как единый профайл, будет уже Single Customer View.

Предпосылки к это в том что в большинстве крупных компаниях данные о клиентах и взаимодействии с ними в данный момент разбросаны по множеству баз данных, от Outlook’а отдельных менеджеров до бухгалтерии и истории в call-центре.

Это для предприятий, если на другом примере, для веба, то это можно представить как информацию разбросанную по множеству соц-сетей (одноклассники, вконтакте, мойкруг, пикаса, жж и т.д.) и объединение всего это с помощью идей заложенных в Google Social Graph, Open Social API, DataPortability и пр.

В корпоративном секторе, при объединении клиентских данных, обычно выделяют 3 этапа:

Основа на CRM

За основу берется готовая CRM (Siebel, SAP и пр.), в которую полностью переливаются все данные, и далее все существующие системы переключаются на данную CRM, так чтобы тянуть все данные из нее.
Тут, к сожалению, полной интеграции практически никогда не получится, так или иначе часть информации все равно остается во внешних (хоть и связанных) системах. Т.е. работает это лишь в редких случаях, на практике сложно перевести все внешние приложения на единую CRM. Ну или еще работает если изначально компания организует всю эту инфраструктуру, подписывается на одного вендора и пр. Но этот случай сомнителен по причине того что потребность в Single Customer View обычно возникает уже после того как компания разрослась.

Поэтому появляется следующий вариант:

Виртуальная модель данных

CRM становится не только хранилищем данных о клиенте, но также выполняет роль внешнего интерфейса к существующим сторонним базам данных. Для этого реализуется какая-то система обмена данными, и CRM устанавливает внутренние связи, дополняя самостоятельно хранимые данные внешними. Это в общем-то менее рискованно, чем полная замена всех баз на одну CRM. К тому же позволяет значительно сгладить процесс перехода на новую инфраструктуру, т.к. позволяет старому ПО работать как оно работало, и постепенно, по мере обновления ПО, делать замену.
Здесь уже начинаются проблемы с тем как учитывать возможную недоступность отдельных баз данных, как учитывать транзакции (т.е. атомарность обновления и непротиворечивость данных суммарно для нескольких баз участвующих в процессе), как объединять данные имеющие различия в разных БД (из-за «нечистоты» данных) и пр.

В результате приходит третий вариант, который с одной стороны объединяет эти подходы, а с другой выворачивает их наизнанку:

Основа на клиентских данных

В этом случае создается единый центр клиентских данных, и уже его используют сторонние БД, CRM и пр. приложения. Это собственно и является Customer Data Integration (CDI)

Вообще это на самом деле некоторая концепция, и может включать как подходы предыдущих пунктов, так и как упомянутый центр на который все переключаются, не храня у себя никакой дополнительной информации. Здесь отличие больше заключается в идеологическом вынесении центральной точки, отвечающей за данные клиента, называемой в данном случае Customer Data Hub. Этот хаб может и объединять данные, и ссылаться на них во внешних источниках, устанавливать связи между данными из разных источников, и передавать дальше внешним приложениям и пр. Технически потом все системы связывается через SOA/ESB, и все довольны.

Это все некие «шарообразные кони в вакууме», на практике чаще будет некоторая смешанная модель. Тем более что востребовано это в компаниях широко распределенных географически, да и весь процесс за один раз организовать не получится, будет долгий и постепенный путь миграции. Реализация тоже может быть какая угодно, во-первых каждый вендор видит это по своему, во-вторых каждой отрасли и компании нужны индивидуальные особенности. Но суть примерно такая.