Платформа даних клієнтів — це система, яка збирає дані про клієнтів з кількох джерел, об’єднує їх в уніфіковані профілі для окремих людей і робить ці профілі доступними для інших систем для сегментації, персоналізації та вимірювання. Вона відрізняється від сховища даних тим, що орієнтована на операційну активацію, а не на аналіз, а від системи управління взаємовідносинами з клієнтами тим, що побудована для обробки великих обсягів поведінкових даних, а не для управління взаємовідносинами та процесами продажів.
Проблема, яку вона вирішує, реальна та поширена. Інформація про клієнтів накопичується в ізольованих системах: комерційній платформі, інструменті електронної пошти, службі підтримки, рекламних акаунтах, аналітиці мобільних додатків, офлайн-точці продажу. Одна й та сама особа з'являється в кожній з них з різним ідентифікатором, і жодна система не має повного уявлення про ситуацію. Як наслідок, маркетинговий відділ зв'язується з клієнтами, які щойно подали скаргу, служба підтримки не має доступу до історії покупок, а аналіз цінності для клієнта неможливий без ручного узгодження, яке повторюється щоразу, коли це необхідно.
Розв’язання ідентифікації є центральною технічною функцією та найскладнішою частиною. Зіставлення облікового запису, в який увійшов користувач, з анонімним сеансом перегляду, з адресою електронної пошти, що використовувалася в інший час, зі встановленням програми та з покупкою в магазині вимагає детерміністичного зіставлення, де ідентифікатори існують, та ймовірнісного зіставлення, де їх немає. Якість цього розв’язання визначає цінність усього, що відбувається далі, а також саме там зосереджуються наслідки для конфіденційності, оскільки об’єднання наборів даних створює профілі, які є більш показовими, ніж будь-які вхідні дані.
Ця категорія розмилася через позиціонування постачальників, і оцінка варіантів вимагає врахування лише обмежень. Деякі продукти – це переважно інструменти активації маркетингу з можливістю отримання даних, деякі – інфраструктура даних з доданою активацією, а дедалі поширеніша схема створює ту саму функцію безпосередньо на хмарному сховищі даних, використовуючи спеціалізовані інструменти для розпізнавання ідентифікаційних даних та розподілу аудиторії, уникаючи дублювання даних клієнтів в окремому власному сховищі. Правильний вибір залежить від існуючої інфраструктури та від того, яка команда володітиме системою, і це питання власності зазвичай є вирішальним, ніж порівняння функцій.
Впровадження зазнають невдачі з передбачуваних причин. Організації купують платформу, перш ніж вирішити, які рішення вона покращить, і в результаті отримують уніфіковані профілі, які ніхто не використовує. Якість вихідних даних низька, а об'єднання створює консолідоване уявлення про ненадійну, а не надійну інформацію. Управління не визначене, тому ніхто не погоджується, яка система є авторитетною для якої сфери. А операційні команди, які повинні використовувати сегменти, не беруть участі в їх визначенні, тому сегменти не відповідають тому, як ці команди фактично працюють.
Будь-якій покупці має передувати чесна оцінка альтернатив, оскільки значна частина цінності, яку організації шукають від цих платформ, досяжна за допомогою інструментів, які вони вже мають. Добре змодельоване сховище даних із запланованим експортом до маркетингової платформи забезпечує більшість випадків сегментації та придушення без нової системи. Там, де дійсно потрібне реагування в режимі реального часу, і де кількість вихідних систем достатньо велика, що інтеграція "точка-точка" стала некерованою, аргументи на користь спеціалізованих інструментів значно посилюються. Формулювання рішення навколо того, яких конкретних можливостей бракує, а не навколо категорії, як правило, призводить до меншого та успішнішого проекту.
Успішна схема полягає в тому, щоб почати з невеликої кількості конкретних випадків використання з чіткою комерційною цінністю, таких як виключення нещодавніх покупців із кампаній із залучення або запуск активності утримання клієнтів на основі визначеної поведінки, і створювати лише ту інтеграцію, яка потрібна цим випадкам. Таке фреймування зазвичай встановлюється під час аналітика даних залучення, при цьому стратегія активації належить управління зростанням, і найчастіше це виправдано в підприємство середовища, де кількість відключених систем настільки велика, що ручне узгодження стало постійними витратами.