Scal-e: Маркетинговая облачная платформа для привлечения и удержания клиентов заходит на российский рынок

Генеральный директор Scal-e Кристоф Алвес (Christophe Alves)

Martech.cloud: Прежде чем говорить о своей стратегии, не могли бы вы рассказать нам, для чего используется платформа Scal-e?

Платформа Scal-e позволяет брендам B2B и B2C легко реализовывать стратегии привлечения и удержания клиентов, а также улучшать свои результаты.

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

Martech.cloud: Как именно ваша платформа способствует реализации стратегий привлечения или удержания клиентов?

С одной стороны, платформу можно настроить (используя подход без кода) для адаптации к контексту клиента. С другой стороны, платформа изначально интегрирована, она не требует интеграции между модулями: это снижает затраты на внедрение и упрощает для брендов совместную работу и повседневную навигацию.Игорь Лейпи, ГК Softline: Объем поставок российских операционных систем в ближайшие годы увеличится как минимум вдвое

Martech.cloud: Вы упомянули режим «без кода», что это такое? И какой интерес это представляет для ваших пользователей?

Платформа была разработана для использования бизнес-группами (маркетинг, аналитика данных, электронная коммерция, послепродажное обслуживание, точки продаж и т.д.) без ежедневной помощи ИТ-команд. Это то, что мы называем в словаре редакторов платформой «без кода» или «low code». Сначала это может показаться мелочью, но, как мы видели во время пандемии, рынок развивается с невероятной скоростью. Преимущество «без кода» в том, что это позволяет маркетинговым командам очень быстро реагировать и реализовывать идею в несколько кликов. Цель состоит в том, чтобы привлечь новых клиентов или создать новые продажи до того, как конкуренты успеют внедрить аналогичные маркетинговые инструменты.

Martech.cloud: Понятно. Вы говорили о изначально интегрированной платформе. Можете ли вы рассказать нам больше?

С самого начала платформа и ее различные модули изначально были интегрированы вокруг модуля CDP (Customer Data Platform) в одном облаке. Знаете ли вы, что Scal-e является побочным продуктом проекта Bouygues Telecom?

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

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

Martech.cloud: Можете ли вы привести примеры сотрудничества, которое стало возможным благодаря вашей платформе? Например, в нормативно-правовой базе, между работой сотрудника по защите данных, агентства и группы данных или бренда и его маркетинговой команды?

Да, конечно. Многие бренды вложили средства в маркетинговые инструменты, чтобы перейти от разрозненного обслуживания клиентов к глобальному опыту (маркетинг, продажи, послепродажное обслуживание и т. д.) и многоканальному подходу (онлайн и офлайн). Знаменитая фраза «свзязаться с нужным человеком правильным сообщением, услугой или наградой в нужное время». Тем не менее, по данным Gartner Institute, к 2025 году 80% компаний откажутся от своих усилий из-за отсутствия окупаемости инвестиций, опасностей, связанных с управлением данными о клиентах, или из-за того и другого.

Одной из причин, по которой так много брендов сдаются, является множество политик конфиденциальности (RGPD, CCPA, GDPR PIPL и другие законодательные акты), а также разрозненность, создаваемая предприятиями (по каналам, дочерним компаниям или подразделениям) или технологические разрозненности. (ERP, веб-сайт, сайт продавца, социальные сети, обмен сообщениями, мобильное приложение, точка продаж и т. д.). Эти два момента не помогают командам по маркетингу, которые поэтому должны уметь справляться с этими техническими и юридическими ограничениями, чтобы организовать свою деятельность.

Без подтверждения согласия (цель обработки, юридическое основание, срок хранения...) данные клиентов больше не имеют никакой ценности для брендов и не должны использоваться маркетинговыми группами в своей деятельности. Чтобы снизить такой риск в Scal-e, инженеры по данным могут централизовать данные клиентов, а DPO (сотрудник по защите данных) может установить свою политику конфиденциальности и проверить, соответствуют ли собранные данные политике бренда. Благодаря этому процессу всем маркетинговым командам не придется заботиться об этих ограничениях, поскольку приложение Scal-e позволит им использовать только те данные, которые соответствуют их политике конфиденциальности данных и настроены таким образом, чтобы получить согласие клиента.

Martech.cloud: Хорошо, давайте вернемся к вашему первоначальному комментарию о способности платформы улучшать результаты операций по приобретению или лояльному маркетингу. Что вы имели в виду?

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

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

Еще одним преимуществом является возможность общаться через все каналы, используемые клиентом. Каждое агентство и каждый бренд говорят о следовании пути клиента и персонализации клиентского опыта в каждой точке взаимодействия. Однако, если клиент находится в центре стратегии бренда, почему бы не интегрировать все каналы, выбранные его клиентами? Часто это технические ограничения, связанные с классическим послепродажным обслуживанием или инструментами автоматизации маркетинга, которые предлагают только определенные каналы связи: электронную почту, SMS и иногда push-уведомления. В Scal-e мы стремимся помочь брендам следовать за своими клиентами по всем каналам. Являются ли они реляционными или транзакционными каналами, такими как электронная почта, SMS, push-уведомления, печать, факс, мобильный кошелек, канал продавца (точка продажи или послепродажное обслуживание), а также каналы обмена сообщениями, которые более распространены в повседневной жизни. клиентов, таких как WhatsApp, Messenger, Telegram, WeChat и все социальные сети, такие как Instagram, Facebook (Instagram и Facebook признаны экстремистскими организациями и запрещены в РФ), Twitter, YouTube и т. д.

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

Martech.cloud: У вас много интересных тем, поздравляю с уже интегрированными 30 каналами. Что касается каналов связи, какой последний канал определили ваши команды?

Это будет Discord, я не знаю, используете ли вы его? Но в мире игр или криптографии (web3) это что-то вроде «must-have», в дополнение к Telegram, который мы уже интегрировали. У нас уже были вопросы на эту тему, но нет конкретных запросов. Вариант использования с агентством, ориентированным на web3 (токен, NFT, «DID» децентрализованной идентификации). Когда это будет подписано, это будет наш первый проект, использующий канал Discord.

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

Я понимаю, что существует слишком много аббревиатур и технических определений, а некоторые аббревиатуры используются неразумно, что может затруднить навигацию для брендов. Вот почему важно, чтобы Scal-e получила признание таких участников, как CDP Institute, Forrester и, надеюсь скоро Gartner. Для облегчения чтения нашего предложения, а также для участия в продвижении и развитии рынка.

Платформа данных клиентов предназначена для создания профилей клиентов B2B или B2C или также известна как обзор клиентов на 360°: это будет вся информация, которая у нас есть о клиенте, которая позволяет нам реализовывать стратегии привлечения и лояльности, основанные на знании клиентов. Бренд должен по-разному общаться с новым клиентом и клиентом-амбассадором; поэтому брендам нужен инструмент для объединения всех знаний о клиентах, который облегчает повседневное использование. Другими словами, CDP — это решение, которое позволяет легко собирать, очищать и унифицировать все данные о клиентах, которые нужны маркетинговым командам, а также позволяет компаниям легко обновлять данные и делиться этими данными с любыми инструментами, которые в этом нуждаются.

Martech.cloud: Хорошо, можете привести пример использования CDP? Может быть что то связанное с программой лояльности?

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

Это распространенный вопрос в эпоху социальных продаж; однако это не так просто реализовать. Для этого бренд должен:

Шаг 1: Создайте оценку RFM, позволяющую им узнать, кто является представителями их клиентов. CDP будет играть здесь важную роль, так как оценка будет основываться на всех элементах, объединенных в CDP. Я говорю об одном счете, но вам может понадобиться создать более одного. Поясню, если у бренда несколько линеек, с разной частотой покупок и количеством. В их интересах получить общую оценку RFM и несколько оценок RFM в зависимости от их ассортимента продукции, чтобы уточнить их классификацию клиентов и лучше понять потенциал перекрестных продаж.

Martech.cloud: не могли бы вы напомнить нам, что означает RFM?

RFM (Recency, Frequency, Monetary) — это простая система подсчета очков, которая позволяет вам настроить лучшие сегменты клиентов и идентифицировать их: с потенциальными, подверженными риску или зависимыми и т. д. Что позволяет вам общаться и вознаграждать клиентов по-разному.

Martech.cloud: можете ли вы объяснить причину нескольких оценок RFM и привести пример, чтобы мы могли лучше понять возможности перекрестных продаж и сегментацию населения (новые, подверженные риску, амбасадоры и т.д.)?

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

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

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

Martech.cloud: Теперь, когда стало понятнее, каким будет второй шаг использования CDP при реализации программы лояльности?

Шаг 2: будет состоять из загрузки CDP различными социальными сетями компании, чтобы получить все опубликованные комментарии и связать их с правильными контактами.

Шаг 3 будет заключаться в подключении механизма лояльности к CDP, чтобы механизм лояльности мог выделить ваучер в соответствии с установленными критериями, например, если они оставляли комментарии в Facebook и Instagram (признаны экстремистскими организациями и запрещены в РФ), то получали ваучер.

Martech.cloud: Спасибо, теперь стало понятнее. Если я понимаю изначально интегрированные возможности Scal-e, значит ли это, что бренд может заменить все свои решения на Scal-e?

Да и нет.

Да, в Scal-e у нас есть все необходимые модули, встроенные для их замены. Однако бренд не обязан заменять существующие решения.

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

Martech.cloud: Хорошо, можете привести пример использования CDP с другим модулем?

Конечно, я разговаривал с брендом, который продает украшения в магазинах и на своем веб-сайте электронной коммерции, они изо всех сил пытались объединить свои различные программы лояльности. Бренд не может предложить одинаковое качество обслуживания клиентов в магазине и на своем веб-сайте. Баллы, которые клиенты получают в магазине и на сайте, трудно привязать к одной и той же учетной записи лояльности, и иногда у участников есть 2 учетные записи лояльности: одна в магазине и одна онлайн. Хуже того, предоплаченные карты, промо-коды и купоны на скидку работают только в одном или другом магазине или в Интернете.

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

Короче говоря, компания просила нас объединить две их программы лояльности, не нарушая их текущую инфраструктуру. Мы предложили им возможность сохранить программу лояльности своего магазина и программу лояльности электронной коммерции и просто подключить их через нашу ETL к нашей CDP и нашей системе лояльности. Наш механизм лояльности будет централизовать все накопленные баллы и вознаграждения (карты, коды, купоны и т. д.) в магазине или в Интернете. Идея состоит в том, чтобы позволить участникам использовать свои вознаграждения как в магазине, так и в Интернете, чтобы стандартизировать свой опыт и позволить точкам продаж (POS) и веб-сайтам звонить нам в режиме реального времени, чтобы «сжечь вознаграждение.

Martech.cloud: Зная, что Forrester включил вас в свой отчет CDP, я думаю, вас часто спрашивают об этом, но чем CDP отличается от базы данных, CRM, озера данных или DMP?

Да. Дайте мне попробовать.

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

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

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

Martech.cloud: Не могли бы вы привести пример? Скажем - как персонализировать сообщение с возрастом контакта.

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

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

Если мы продолжим мой предыдущий пример, ориентированный на продажи в социальных сетях, если маркетинговая команда хочет начислить баллы за первые 5 комментариев, оставленных в социальных сетях, создание правила в программе лояльности, отражающего это, на традиционных платформах займет недели. Однако с таким решением, как Scal-e или рыночным аналогом, все, что вам нужно сделать, это создать агрегат, назовите его суммой, если хотите, который подсчитывает количество сообщений. Автоматически эта сумма рассчитает и прикрепит информацию к профилю клиента, без необходимости привлечения ИТ-команды для помощи. Эта сумма теперь будет использоваться в модуле лояльности, как правило, позволяя соответствующим образом распределять баллы. Например, за 5 комментариев вы не получаете баллов, за 5 и более комментариев вы получаете X баллов.

Martech.cloud: Интересно. Это ясно для озера данных, базы данных и витрины данных. А как насчет других решений CRM, DMP, ERP и т. д.?

Что касается других решений, цель CDP — разрушить хранилища данных, которые создают эти платформы. Цель CDP — централизовать все данные о клиентах, чтобы командам не приходилось использовать X решений для получения полного представления о клиентах. Аналогичным образом, если у вас есть 2 банковских счета, каждый счет предоставит вам данные вашей учетной записи. Однако, если вы хотите комбинированное представление ваших двух учетных записей, вам нужно будет их объединить. Для CDP и бизнес-инструментов (CRM, DMP, ERP, кассовая система и т. д.) это та же идея, что и с двумя банковскими счетами.

Итак, будь то платформа управления данными (DMP), инструменты управления взаимоотношениями с клиентами (CRM), ERP или другая транзакционная система, например: кассовая система, автоматизация маркетинга или инструменты маршрутизации. Эти инструменты могут быть важными источниками данных и удовлетворять потребности бизнеса, однако с их помощью невозможно создать единый профиль, содержащий все данные о клиентах.

У бренда, о котором я вам говорил, была точно такая же проблема; они хотят согласовать свою программу лояльности в магазине и в Интернете. У бренда уже есть другие бизнес-инструменты: POS-система для магазина и платформа электронной коммерции для сайта. Эти 2 инструмента уже содержат много информации, проблема в том, что они не содержат всей информации, и если вы хотите адаптировать их так, чтобы они содержали всю информацию, вы просто пытаетесь сделать еще один инструмент.

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

Martech.cloud: Спасибо, теперь я намного лучше понимаю ваш подход.

Институт Gartner отмечает, что рынок уже ищет инструменты 3-го поколения и что сбора и унификации данных уже недостаточно. Теперь необходимо иметь возможность идентифицировать происхождение данных и иметь возможность осуществлять права потребителя (забыть, стереть и т. д.) в любом месте и в любое время, а также иметь возможность обрабатывать данные клиента для клиентов (статистика, маркетинговые устройства или Сервисы).

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

Martech.cloud: Когда вы говорите о ETL, вы имеете в виду такие инструменты, как Zapier, Segment, Integromat, Leadsbridge или Mulesoft?

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

Martech.cloud: Итак, как и эти ETL или IPAAS на рынке, ваша CDP реализовала различные стандартные коннекторы?

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

Martech.cloud: Что вы подразумеваете под пользовательским коннектором?

Итак, когда мы говорим о стандартном разъеме, мы имеем в виду разъем, с которым мы можем подключиться за несколько минут. Так же, как пользователь, которому нужен логин и пароль для входа и заполнения настроек для использования решения.

Многие инструменты позволяют модифицировать их модель данных, например, большинство CRM на рынке позволяют добавлять объекты или поля в исходную модель данных. Проблема в том, что через свой API эти CRM не всегда позволяют восстанавливать данные из объектов или полей, добавленных впоследствии, поэтому мы называем наш API в Scal-e полиморфным API.

Martech.cloud: Что вы подразумеваете под полиморфным API?

Наша CDP позволяет внедрять настраиваемые модели данных B2B, B2C или даже B2B2C, поскольку мы хотели упростить работу бизнес-команд. Как только объект или поле настроены в CDP без какого-либо вмешательства, они будут доступны в формате чтения или записи через наш API. Отсюда идея полиморфизма, поскольку API адаптируется к модели данных, реализованной в CDP.

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

Martech.cloud: Итак, подход заключается в том, чтобы вы создавали индивидуальные коннекторы, которые будут реализованы или адаптированы в ходе проекта.

Именно так, как многие другие редакторы программного обеспечения анонсируют стандартные коннекторы и при этом указывают, что на его внедрение уйдет X дней.

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

Martech.cloud: Вы имеете в виду в дополнение к вашим коннекторам?

Да, точно. Иногда для подключения к одному источнику данных необходимо использовать соединитель и иметь возможность выполнять запросы к базе данных.

Martech.cloud: У вас есть пример?

Не для запроса к базе данных с использованием коннектора. Однако для Shopify, если бренд хочет собирать поведенческие данные, такие как просмотры страниц или просмотры продуктов, этот тип данных не может быть получен через API Shopify. Таким образом, все инструменты, такие как Scal-e, которые имеют коннектор Shopify, будут использовать свой коннектор для получения информации о контактах и транзакциях, и им придется использовать другой коннектор для инструмента тегирования, такого как Piwikpro, Mattomo или Google Analytics, для получения данных о поведении.

Итак, для веб-сайта продавца вам понадобятся 2 разных инструмента. Это одна из причин, по которой мы хотели разработать ETL, изначально интегрированный в нашу CDP. ETL, который предлагает различные стандартные опции, такие как полиморфный API, коннекторы, возможность запрашивать внешние базы данных или даже импортировать потоки CSV, чтобы облегчить сбор данных для сопоставления в CDP.

Martech.cloud: Разве это не относится ко всем CDP на рынке? Разве не все они предлагают встроенный ETL и такую гибкость?

Нет, с одной стороны, многие CDP поставляются «с полки». Они готовы к использованию, но только для одного типа использования, и мы видим множество CDP, ориентированных на электронную коммерцию. По сути, их модель позволяет им собирать данные о поведении или транзакциях с платформ электронной коммерции, таких как Shopify. Это хорошие решения, проблема заключается в том, что бренд хочет собрать больше знаний о клиентах, объединив свою CDP с другими инструментами, например, с POS-инструментом, или если бренд решит перейти с Shopify на Prestashop, Magento или любые другие подобные инструменты. В лучшем случае это будет очень сложно, требующее большой доработки, а в худшем — повод изменить CDP. И я вам даже больше скажу: большую часть времени они будут настаивать на использовании другой ETL или IPAAS, поскольку они не разработали свою собственную ETL. Риск будет заключаться в стоимости объединения различных технологий.

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

Martech.cloud: Значит, с Scal-e CDP нельзя использовать такие решения, как Didomi, Axeptio или OneTrust?

Нет, это не так.

Наша философия заключается в том, чтобы не предлагать нашим клиентам менять инструменты, особенно если они довольны существующими решениями. Такие решения, как Didomi или Axeptio, очень хороши и подходят для других вариантов использования. Если у бренда есть X веб-сайтов и оффлайн-активность (например, магазин), ему в любом случае потребуется подключить свои CMS, такие как Axeptio, Didomi, к CDP.

Для One Trust это то же самое, даже если их предложение немного более развито, поскольку они предлагают больше, чем предлагает CMS. Наш модуль конфиденциальности можно использовать как в режиме master, так и в режиме slave. Если у клиента есть такое решение, как OneTrust, он сможет воспользоваться нашей возможностью восстановить его настройки. В противном случае он может воспользоваться нашим модулем. Часто проблема заключается в том, чтобы настроить политику конфиденциальности и обеспечить ее соблюдение всеми инструментами ИТ-системы. Именно здесь наш изначально интегрированный подход предлагает множество преимуществ. Даже если наш модуль конфиденциальности используется в ведомом режиме из основного инструмента, разработанного внутри компании или вне ее, например OneTrust, наша платформа изначально интегрируется со всеми этими механизмами (удаление, анонимизация, блокировка, переносимость и т. д.), потому что мы также знаем, как ими управлять.

Martech.cloud: Отлично! Вы часто говорите о концепции «Единого облака». Означает ли это, что вы конкурируете с такими решениями, как Snowflake или BigQuery, или гиперскейлерами, такими как AWS, Azure или OVH?

Нисколько. У нас много клиентов, которые используют Snowflake, BigQuery, Databrics и т. д. для создания озер или даже киосков данных. Наша функция будет заключаться в подключении к этим инструментам и получении данных, которые позволят командам самостоятельно реализовывать свою маркетинговую стратегию. Эти решения очень хороши, о чем свидетельствует их успех. Однако Snowflake или Bigquery больше подходят для ИТ-консультанта, чем для менеджера по маркетингу.

Из гиперскейлеров вы упомянули AWS, Azure и OVH и другие. Мы начинаем видеть суверенные облака, и есть много других интересных компаний, зависящих от страны, таких как облако Alibaba в Китае. В Scal-e мы используем эти компании либо для размещения данных клиентов, либо для размещения нашей платформы.

Таким образом, мы больше дополняем друг друга, чем конкурируем!

Martech.cloud: Итак, единая база данных со всеми данными о бренде может размещаться у заказчика (локально) или на хостинге по его выбору?

Все верно.

Каждый клиент будет связан с сервером данных (изоляция арендатора) по соображениям безопасности, чтобы избежать риска утечки данных. Этот сервер данных может находиться у клиента, на хосте по его выбору или управляться командой Scal-e.

Martech.cloud: Влияет ли выбор хостинга на стоимость? Более того, каков минимальный бюджет CDP?

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

Martech.cloud: Мне показалось, что я увидел на вашем сайте стандартное частное облако.

Все верно.

Martech.cloud: А каков бюджет CDP?

Лицензия стоит 1000 евро в месяц. Что касается части реализации, вопреки тому, что говорят некоторые компании, для установки не требуется минимум 100 000 евро.

Это, конечно, зависит от нескольких факторов: количества источников данных, качества данных, количества алфавитов (связанных с разными языками) и количества серверов данных, которые необходимо настроить для соблюдения различных правил. и т.д. Это также зависит от типа проекта: например, проекты, которыми мы управляем в режиме реального времени или в режиме проекта редактора, это означает, что мы управляем 80/90% всего проекта, а оставшиеся 10% — это нагрузка клиента. Мы реализовали индивидуальные проекты CDP на несколько десятков тысяч евро с потоками и коннекторами для различных источников данных об импорте и экспорте.

Тем не менее, я думаю, что анализ затрат является плохим анализом.

Martech.cloud: Вы имеете в виду, что предпочитаете думать о рентабельности инвестиций, а не о бюджете необходимом например, для внедрения CDP?

Не обязательно.

Все бренды, с которыми я сталкивался, тратят больше своего коммуникационного бюджета на Meta (признана в РФ экстремистской организацией, её деятельность запрещена на территории России), Google, Twitter, Tencent, Alibaba и т.д., чем они вкладывают средства в инструменты, позволяющие им извлекать выгоду из своих отношений со своими клиентами. Я не говорю, что мы больше не должны использовать эти сети для привлечения новых клиентов. Но нормально ли, что бренд продолжает вкладывать такие бюджеты в получение информации о собственных покупателях?

Зачем платить в X раз больше за информацию о клиенте? Объединив все эти данные в CDP или обогатив эту информацию с помощью программы лояльности, мы можем продемонстрировать рентабельность инвестиций через несколько недель/месяцев, не тратя в X раз один и тот же бюджет на одни и те же контакты.

Martech.cloud: Подводя итог, вы говорите, что просто рационализируя расходы на рекламу, бренд выигрывает от централизации и унификации своих знаний о клиентах в CDP?

Именно.

Теперь мы склонны рассматривать это как положительный побочный эффект.

Чтобы построить наши ROI, мы предпочитаем сравнивать среднюю корзину бренда и ежемесячную стоимость (CPM) для управления 1000 клиентов в Scal-e.

Martech.cloud: Можете ли вы привести пример сравнения средней корзины с ценой за тысячу показов платформы Scal-e для расчета рентабельности инвестиций?

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

Это означает, что если из 1000 клиентов Scal-e будет заключать 1 дополнительную сделку каждые 62 месяца, благодаря нашим возможностям таргетинга, персонализации и рекомендаций, клиент получит возмещение своих инвестиций!

Зная этот вид товара можно продавать несколько раз в год. На мой взгляд, ничего не делать дороже, чем что-то делать.

Martech.cloud: А если у заказчика несколько видов продукции?

Интересный вопрос. Ничто не мешает вам сделать этот расчет для продукта с наименьшей средней корзиной, чтобы следить за его рентабельностью.

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

Martech.cloud: наше интервью подходит к концу. Вы говорили о спин-оффе, если я правильно понял, вы купили компанию со своими единомышленниками. Не могли бы вы рассказать нам больше?

Да, конечно. Мы вместе стали соучредителями маркетингового агентства в 2008 году и развили его деятельность в Европе, Азии и США. Со временем, с развитием местного законодательства, нам пришлось адаптировать и использовать различные маркетинговые решения. Мы были ограничены в своем развитии из-за этих инструментов и решили разработать свой собственный инструмент. Перед запуском проекта мы столкнулись с файлом передачи Scal-e, который уже реализовал более 200 проектов напрямую или через сеть своих партнеров. Достаточно сказать преимущество стартапа вкупе с опытом, полученным благодаря многочисленным проектам.

Martech.cloud: Расскажите, чем платформа Scal-e отличалась от продуктов, которыми вы пользовались?

Я и мои коллеги работаем над проектами Fintech или Martech уже более 20 лет. Мы видели, как агентства, интеграторы, ИТ-команды и даже наши команды повторяли одни и те же разработки для каждой отрасли. Каждый бренд хочет адаптировать свои решения для продажи в магазинах. К нам пришла идея; возможно, нам следует упростить пользователям настройку платформы самостоятельно, не прибегая к чрезмерно техническим разработкам или продуктам.

Необходимо было понять необходимость развития брендов и то, что даже два конкурирующих бренда не хотят заниматься одним и тем же. Мы подумали, что вместо того, чтобы сосредоточиться на одном варианте использования или одном секторе, например, иметь CDP, посвященный B2B, B2C, сайтам электронной коммерции, или решение для лояльности, которое позволяет вам управлять только определенными типами вознаграждений или распределять баллы/награды только в транзакционных событиях. Мы хотели предложить бизнес-командам (маркетинг, данные, DPO, IT) возможность 100% персонализации платформы без необходимости переделывать продукт и позволить им предлагать своим клиентам 100% персонализированный опыт.

И это то, что нам понравилось во время первой презентации.

Модульная сторона платформы позволяет каждому бренду и даже каждому пользователю использовать только те модули или функции, которые им нужны. Сторона «единого облака» избавляет ИТ-специалистов от необходимости связывать между собой различные облака/решения. Тот факт, что платформа сосредоточена на CDP, позволяет настраивать 100% индивидуальные модели данных, даже не прикасаясь к серверу базы данных. Функциональная сторона ETL предлагает различные методы взаимодействия, например: наличие полиморфного API, который автоматически адаптируется к моделям, реализованным в CDP. Возможность использовать любое поле CDP для создания сегмента, совокупности, персонализации контента, рекомендации продукта или даже создания отчета, даже если это поле было только что создано или рассчитано.

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

Martech.cloud: Это хороший переход к моему последнему вопросу. Можете ли вы поделиться с нами некоторыми темами, над которыми вы работаете?

Есть десятки!

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

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

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

Когда мы знаем, что у некоторых наших клиентов есть миллионы контактов, к которым привязаны миллионы транзакций и других данных, такой расчет может занять несколько часов на стандартных решениях. На Scal-е это несколько минут.

Теперь появляются темы, которые начинают появляться, например, возможность собирать данные из разных блокчейнов, чтобы больше не просто объединять офлайн и онлайн-данные, а офлайн, онлайн и ончейн! Либо иметь 360-градусное видение любой среды, либо распределять токены или NFT среди участников в соответствии с их обязательствами как в магазине, так и на сайте электронной коммерции и в Интернете!

Но я предлагаю вам сохранить это для следующего разговора, зная, что мы собираемся делать объявления об этом.