Составные CDP: чем они отличаются от пакетных решений?

«Составной CDP — это не вещь. Компонуемая архитектура — это», — написал мой коллега Крейг Ховард ранее во внутреннем письме. Он объяснил, что платформы клиентских данных (CDP) стали популярными, когда организации не могли внедрить собственное облачное хранилище данных клиентов и могли приобрести готовое коммерческое решение — «упакованный» CDP — которое могло бы помочь им реализовать преимущества. облачных технологий, управляя данными своих клиентов.

Но совсем недавно все изменилось:

• ИТ-организации развили и приобрели навыки работы с облачными технологиями.
• Потребности в интеграции данных часто превосходят возможности CDP. Многим CDP сложно управлять сложными структурами данных или отвечать на сложные вопросы о данных.
• Политики и набор глобальных законов усложнили вопросы конфиденциальности, согласия и местонахождения данных.

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

Упакованный против составного

Компонуемая CDP основана на архитектуре, привязанной к облачному хранилищу данных для данных клиентов. В компонуемой CDP становится платформой оркестрации — управление аудиторией и поездками и активация данных о клиентах.

Тем не менее, решение о выборе составного или упакованного CDP не так просто. Во-первых, если вы покупаете любой из них, ваша голова находится в правильном месте. Будущее за активацией собственных данных по каналам. Если ваше решение является составным, а не автономным, вам нужно многое распаковать.

Конвергенция

В 2021 году нужно было выбирать между обратным ETL (составным) или CDP. Сегодня этот выбор не однозначен. Многие CDP и маркетинговые технологии могут запрашивать базу данных.

Например, Lytics, ActionIQ, mParticle, Blueshift и другие добились больших успехов в нативном подключении к клиентскому хранилищу данных и хранящимся в нем ценным данным. Можно эффективно практиковать компонуемость с некоторыми CDP, ранее считавшимися упакованными.

Выполнение

Звучит просто — добавьте обратный ETL к существующему хранилищу данных. Да, «составной» может быть проще реализовать. Время окупаемости обычно быстрее, если у вас есть следующее:

• Все ключевые потоки данных легко доступны в вашем хранилище данных.
• Разработана стратегия разрешения личности.
• Вовлеченная команда аналитиков или корпоративных данных.

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

Кроме того, обычные коннекторы для почтовых платформ и других маркетинговых технологий могут предоставлять клиенту наборы данных, которые он ранее не сохранял. Эти новые данные и стратегия разрешения идентичности дают многим клиентам «клиент 360» в качестве дополнительной ценности.

Копните глубже: какое место в вашем стеке маркетинговых технологий должен занять CDP?

Сценарии использования компонуемого и пакетного CDP

Сценарии использования, достигнутые при компонуемом подходе, принципиально не отличаются от пакетного CDP. Есть исключения — CDP, такие как Lytics и BlueConic, предлагают простую персонализацию сайта.

Если данные, лежащие в основе сегмента, надежны для маркетинговых целей, а стратегия разрешения идентификации допускает активацию в данном канале, варианты использования ограничены только возможностями команды, использующей инструмент. Тем не менее, пакетные CDP могут иметь встроенное машинное обучение (ML), отчетность и поддержку в режиме реального времени, которые компонуемым практикам, возможно, придется решать отдельно.

Разрешение личности

Компонуемое решение не будет создавать разрешение идентификации. Компонуемые архитектуры опираются на уже существующие ключи соединения, собственное облачное разрешение удостоверений для разрозненных наборов данных или уже существующую таблицу клиентов со всеми соответствующими критериями сегментации.

CDP могут работать с уже существующей стратегией разрешения идентичности, аналогичной компонуемым архитектурам, или они могут создать стратегию разрешения идентичности для клиента как часть своей реализации. Часто используется гибридный подход, при котором CDP использует ранее существовавшую стратегию разрешения идентичности клиента, а затем сопоставляет новые каналы и потоки данных с этой стратегией разрешения идентичности.

Копните глубже: Путеводитель по странному новому миру разрешения идентичности

Сегментация

Многие упакованные CDP предлагают внешние интерфейсы без SQL, и компонуемые обратные ETL-решения добились прогресса в этом направлении. Точно так же не все CDP создаются одинаково, и некоторые из них создают дополнительную техническую нагрузку для конечного пользователя.

Некоторым CDP необходимо выравнивать или сопоставлять данные, чтобы ограничить сложные соединения. Это необходимо для ограничения размерности данных и предоставления ответов в режиме реального времени.

Характер этой архитектуры, работающий в режиме реального времени, может быть преимуществом для некоторых. Однако это накладывает реальные ограничения на возможность задавать сложные вопросы по данным. Если важен режим реального времени, пакетные CDP могут иметь преимущество. Если сложные вопросы и менее обременительное отображение данных в реализации имеют решающее значение, компонуемый может работать лучше для вас.

Управление данными

Сложные юридические требования в отношении согласия, хранения данных, резидентности данных и прав на доступ/удаление являются главными для многих лиц, принимающих решения, при выборе компонуемой архитектуры по сравнению с пакетным решением CDP. В этой области компонуемый имеет преимущество.

Composable ставит хранилище данных в центр маркетинговой вселенной. Облачные хранилища данных предлагают гибкие элементы управления для согласия и местонахождения данных. Компонуемые решения могут работать в уже существующей структуре управления, включая поддержку нескольких регионов, истечение срока действия данных и защиту на уровне столбцов.

Пакетные CDP часто воссоздают ключевые аспекты данных клиентов в среде, управляемой CDP. Это создает проблемы с обработкой таких вещей, как запросы, связанные с GDPR и CCPA. Они также вынуждены работать с предоставленными клиентом атрибутами согласия или интегрироваться со сторонними платформами согласия. Некоторые CDP пытаются смягчить это, устанавливая свои CDP «на месте».

Время окупиться

Время окупаемости слишком сильно варьируется в зависимости от клиента. Как упоминалось выше, теоретически время окупаемости быстрее с компонуемым, если соблюдаются определенные организационные критерии. Если эти критерии не выполняются, пакет CDP имеет некоторые структурные преимущества.

Однако CDP не всегда могут претендовать на успех. Мы видели, что время окупилось всего за 30 дней, и, к сожалению, нас призвали спасать многолетние усилия с небольшой ценностью. Тем не менее, если у вас есть многолетняя проблема без успеха, проблема, вероятно, заключается не столько в технологии, сколько в вашей стратегии использования, вашем процессе внедрения новой технологии или в отсутствии навыков, доступности или преемственности вашего персонала.

Наука о данных и машинное обучение

Компонуемый подход основан на том, что предприятие привносит в набор данных собственный интеллект или лучшее в своем классе решение. Многие CDP предлагают готовую науку о данных. По нашему опыту, возможности, предоставляемые CDP, ограничены командой, использующей платформу. Если команда является продвинутой, они могут извлечь выгоду из функций науки о данных.

Мы считаем, что наука о данных должна быть хорошо интегрирована в маркетинговую деятельность. Если ваша команда не нашла применения в имеющихся у них возможностях машинного обучения, у вас не та команда или не тот процесс. Если у вашей команды нет возможностей машинного обучения, обратитесь к эксперту, который поможет вам модернизировать ваши маркетинговые процессы.

Копнем глубже: Измерение принятия CDP: комплексная структура

Ключевые вопросы, которые следует рассмотреть перед переходом на составную CDP

Решение о переходе на компонуемый или упакованный CDP зависит от множества нюансов. Различия пересекаются, и существуют определенные зависимости хранилища данных бренда, дополняющих технологий (BI, машинное обучение и т. д. и т. д.) и желаемых вариантов использования.

Прежде чем принять решение о подходе, бренды должны задать себе некоторые из следующих вопросов:

• Какие варианты использования я пытаюсь решить? Необходимо учитывать соображения, связанные с удалением сторонних файлов cookie, необходимостью использования в режиме реального времени и подключением к существующему стеку martech.
• Все ли ключевые данные уже находятся в моем хранилище данных? Например, есть ли у меня доступ к электронной почте, веб-сайту и ключевым данным из магазинов или других каналов на уровне клиента? Могу ли я объединить эти наборы данных вместе, чтобы получить достаточно надежное представление о клиентах?
• Насколько развиты мои возможности отчетности и аналитики? Могут ли они легко поддерживать отчеты об аудиториях, которые я намереваюсь создать, вариантах использования, которые я намереваюсь развернуть, и окупаемости инвестиций, связанных с этими усилиями?
• Есть ли у меня инструменты, необходимые для поддержки принятия решений на основе машинного обучения в моей аудитории?

Когда мы работаем с компаниями, развертывающими CDP, наша команда, как правило, берет на себя организационные обязательства по развертыванию собственных данных в масштабе. Это неотъемлемое обязательство помогло скорости и успеху развертывания CDP.

Пока рано говорить о том, как реверсивные ETL-решения повлияют на развертывание собственных данных клиентов в масштабе. Тем не менее, будущее у приложений с быстрой окупаемостью и возможностью учитывать проблемы с хранением данных и конфиденциальностью.