Стоит ли использовать хранилище данных в качестве CDP?

Появление облачных хранилищ данных (DWH) упростило развертывание, увеличило масштаб и повысило производительность для растущего набора сценариев использования, управляемых данными. DWH стали более распространенными в корпоративных технологических стеках, включая стеки martech.

Неизбежно возникает вопрос: следует ли использовать существующую DWH в качестве платформы клиентских данных (CDP)? В конце концов, когда вы повторно используете существующий компонент в своем стеке, вы можете сэкономить ресурсы и избежать новых рисков.

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

DWH как CDP может вам не подойти

Существует несколько неотъемлемых проблем с использованием DWH в качестве CDP. Первый очевиден: не во всех организациях есть СХД. Иногда у корпоративной команды DWH нет времени или ресурсов для поддержки вариантов использования, ориентированных на клиента. Другие предприятия эффективно развертывают CDP как квазихранилище данных. (Не все CDP могут это сделать, но вы поняли.)

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

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

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

Наконец, помните, что данные и возможность доступа к ним не составляют CDP. Большинство CDP предлагают некоторые дополнительные возможности, которых нет в DWH, например:

• Подсистема событий с запуском.
• Анонимное разрешение личности.
• Удобный для рынка интерфейс для сегментации.
• Сегментируйте профили активации с помощью коннекторов.
• Потенциально тестирование, персонализация и рекомендательные сервисы.

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

Неудивительно, что сейчас много говорят о «компонуемых CDP» и потенциальной роли DWH в этом контексте. Ранее я утверждал, что компонуемость — это спектр, и вы начинаете терять преимущества после определенного момента.

С учетом всех этих предостережений DWH может играть роль части стека данных о клиентах, в том числе:

• Отказ от CDP путем активации непосредственно из DWH.
• Использование DWH в качестве квази-CDP с платформой обратного ETL.
• Сосуществование с CDP.

Давайте посмотрим на эти три шаблона проектирования.

1. Подключение маркетинговых платформ напрямую к вашей СХД

Это, пожалуй, самый крайний случай, который я критиковал выше, но некоторые предприятия справились с этой задачей, особенно в эпоху до CDP, и платформы (такие как Snowflake с ее широкой экосистемой) пытаются решить эту проблему.

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

Представьте, что у вас есть другая платформа для маркетинга или взаимодействия, персонализированный веб-сайт или платформа для электронной коммерции. Вы снова получаете данные из DWH, а затем используете платформу веб-приложений для создания другого набора сегментов для более целенаправленного взаимодействия.

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

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

2. Используйте DWH с инструментами обратного ETL

Этот подход решает несколько проблем с первым шаблоном выше. Примечательно, что это позволяет (теоретически) специалисту, не связанному с DWH, создавать универсальные сегменты практически поверх DWH и активировать несколько платформ. Благодаря преобразованию и улучшенной структуре соединителя вы можете применять различные сопоставления меток и удобные для маркетинга структуры данных к различным конечным точкам.

Вот как это работает. Платформы обратного ETL извлекают данные из DWH и отправляют их на маркетинговые платформы после любого преобразования. Вы можете выполнять несколько преобразований и отправлять эти данные в несколько пунктов назначения одновременно. Вы даже можете автоматизировать его и регулярно запускать экспорт по заранее определенному расписанию.

Но копия этих данных (или их подмножество) на самом деле копируется на целевые платформы, поэтому у вас действительно не будет единственной копии данных. Поскольку платформа обратного ETL не имеет копии данных, требуемые сегменты или аудитории всегда генерируются во время запроса (обычно пакетами). Затем вы экспортируете их в пункты назначения.

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

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

3. DWH сосуществует с CDP

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

Существуют различные варианты сосуществования этих CDP с DWH. Большинство CDP синхронизируют и дублируют данные в своем репозитории, в то время как другие (включая поставщиков обратного ETL) не делают копии. Тем не менее, могут быть компромиссы, которые вам необходимо рассмотреть, прежде чем завершить то, что работает для вас.

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

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

Заворачивать

Платформы DWH играют все более важную роль в стеках martech. Однако у вас по-прежнему есть несколько архитектурных вариантов выбора сервисов, которые вы предоставляете в своей экосистеме данных.

Я думаю, преждевременно исключать CDP в вашем будущем. У каждого шаблона есть свои компромиссы, которые следует учитывать при оценке вариантов.