Для чего настраивается cdp уц

Памятка для удостоверяющих центров и других участников PKI

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

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

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

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

В этом посте я хочу рассказать, с какими критическими проблемами и нарушениями в работе УЦ часто приходится сталкиваться, а также о том, как их избежать.

У полноправного участника Public Key Infrastructure, должна быть информационная система со встроенными СКЗИ, которая позволяет вести электронный документооборот с клиентами и партнерами, обмениваясь с ними документами с электронной подписью (ЭП) или зашифрованными данными.

Когда партнер присылает документы с ЭП, система выполняет ряд действий. Она проверяет электронную подпись на документе и партнерский сертификат открытого ключа проверки этой подписи.

В частности, для сертификата партнера строится путь сертификации — цепочка сертификатов, от его конечного пользовательского, на котором проверилась ЭП, до корневого центра сертификации.

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

Для квалифицированных сертификатов также выполняются проверки согласно 63-ФЗ «Об электронной подписи» и Приказа ФСБ РФ №795. Контролируется наличие и правильность заполнения всех необходимых атрибутов в сертификате пользователя.

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

Сбои и некорректная работа УЦ в части публикации CRL

В сертификатах есть атрибут CDP — CRL Distribution Points, в нем УЦ публикует ссылки на свой список отозванных сертификатов — Certificate Revocation List

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

CRL тоже подписан ЭП удостоверяющего центра, что дает дополнительную защиту от подмены и атак посредника «Man in the middle» при его загрузке по открытому каналу. Он содержит атрибуты с периодом своего действия и серийные номера отозванных сертификатов.

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

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

Такие документы будут отвергнуты до восстановления возможности проверить сертификат на отзыв.

То же самое касается контроля клиентских и серверных сертификатов, которые используются для построения защищенного канала связи TLS ГОСТ или TLS RSA по протоколу HTTPS. Если системам партнеров не удается проверить их на отзыв, то защищенное и 100% доверенное соединение партнеры установить между собой не смогут.

Какие сбои и нарушения здесь может допустить УЦ?

1. Перенаправление ссылок (Redirect)

УЦ опубликовал в сертификате конкретный URL, но на сервере, где этот ресурс опубликован, происходит перенаправление клиента на другой URL.

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

private static final String ATTENTION_CRL_REDIRECT_DETECTED = "Attention CRL redirect detected: "; private static final String LOCATION = "Location"; URL url = new URL(crlURL); InputStream crlStream = null; URLConnection connection = url.openConnection(); String redirect = connection.getHeaderField(LOCATION); if (redirect != null)

2. HTTPS в CDP атрибуте сертификата и ни одной общедоступной ссылки

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

Попадались сертификаты с https://, ldap:// или защищенный SFTP, также были просто URL с IP адресами из внутренней подсети. Все эти ссылки допустимы при наличии хотя бы одной ссылки HTTP или FTP (без логина и пароля) доступной из сети Internet всем.

Почему HTTPS к свободным не относится?

За списками отзыва могут обращаться далеко не только интернет-браузеры, имеющие обширное хранилище корневых доверенных сертификатов международных УЦ, которое позволяет им поднимать защищенное соединение по HTTPS-ссылке и принимать ресурс как доверенный.

Другие информационные системы могут не иметь такого хранилища с предустановленными корневыми сертификатами и не обязаны поднимать контекст защищенного соединения к HTTPS-ссылкам.

Просто невозможно во все системы установить все корни для всего многообразия УЦ, выпускающих SSL/TLS-сертификаты.

По понятным причинам информационные системы также не могут знать логин и пароль от FTP и не будут иметь доступ к внутренней службе Active Directory по LDAP-протоколу.

Поэтому принято, что CRL публикуется в свободном доступе.

3. HTTP перенаправление (redirect) на HTTPS

Это гибридная ситуация, с которой приходилось сталкиваться, состоящая из приведенных выше пунктов 1 и 2.

Как такое возможно?

Сайт компании, где УЦ публикует свои списки отзыва, или просто веб-сервер, который используется удостоверяющим центром для этих целей, запущен, например, на Nginx.

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

server < listen 80 default_server; listen [::]:80 default_server; server_name _; return 301 https://$host$request_uri; >

Получается, что в сертификате приведен URL с http://, а системы, которые чувствительны к такому факту подмены подписанной информации из сертификата и справедливо защищаются от атак посредников, перестают загружать списки отзыва данного УЦ, пока администратор не настроит на сайте исключения для CRL.

4. Фильтрация по User Agent

Данная проблема и нарушение доступа к спискам отзыва сильно перекликается с приведенной в пункте 3.

Тот же администратор сайта, на том же Nginx включает фильтрацию по User Agent. Например, все системы на Java будут получать ошибку HTTP 403 при обращении к ресурсу.

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

if ($http_user_agent = "Mozilla/5.0 (Linux; Android 4.2.2; SGH-M919 Build/JDQ39) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.169 Mobile Safari/537.22") < return 403; >if ($http_user_agent ~* "^Java")

Еще администратор сайта, где публикуются списки отзыва, может включить redirect на основе User Agent.

5. Просроченный CRL

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

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

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

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

Были случаи, когда по каким-то причинам УЦ своевременно не обновлял CRL.

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

6. Сбои на сетевом и транспортном уровне

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

В сертификате, выпущенном УЦ, может быть прописано два URL с http:// и разными host именами. Такой подход правильный, он позволяет иметь резерв и всегда держать одну ссылку в доступе, если требуется провести какие-то работы на другом сервере.

Но вот незадача. Вызывающая система вдруг начинает получать IOException: ConnectionTimeOut при попытке подключения к одной из ссылок. Вторая ссылка при этом работает и отдает CRL. А вызывающая система все равно начинает замедляться на настроенное в ней время, например, ConnectionTimeOut=15000 mSec, потому что проверяет обе ссылки, и ей приходится ждать ответа от недоступной в настоящий момент.

А если в CDP сертификата четыре, пять разных ссылок на CRL и при этом две или три из них оказываются недоступны с ConnectionTimeOut?

В этом случае время проверки сертификата возрастает до неприличной величины, равной времени таймаута, умноженному на количество таких ссылок.

А что, если обмен нашей информационной системы идет с этим УЦ или партнером, организацией, аффилированной с данным УЦ? И система партнера имеет свой таймаут на вызов нашей информационной системы, который заведомо меньше того времени, которое наша система тратит на проверку их сертификата?

Партнеры говорят нам, что не получают ответ от нашей системы и отключаются по таймауту, а происходит это на самом деле из-за регламентных работ на их УЦ.

Почему может происходить ConnectionTimeOut?

Как вариант, это регламентные работы, сетевая атака или повышенная нагрузка на сайт УЦ, что привело к неконсистентному состоянию:

какой-то брандмауэр, файрвол на пути, который просто начал съедать сетевые пакеты, не сообщая отправителю такие вещи, как «No Route to host»
началась потеря пакетов из-за неправильной конфигурации сети или перегрузки линии
слишком много запросов, перегружающих сервер
небольшое количество одновременно доступных потоков / процессов на сервере, что приводит к их блокировке. Это происходит особенно с запросами, выполнение которых занимает много времени и может сочетаться с предыдущим пунктом

Как с этим справляться?

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

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

Если точка публикации будет корректно отключена, то вызывающая система, мгновенно получив от этой ссылки, например, IOException Connection Refused: connect, сразу перейдет к загрузке по следующему URL.

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

Чем должны руководствоваться УЦ при публикации CRL

Спецификацией RFC 5280 IETF и стандартом X.509 ITU-T, разработанными Инженерным советом Интернета и Международным консультационным комитетом по телефонии и телеграфии.

В частности, пунктом 8. Security Considerations из RFC 5280

When certificates include a cRLDistributionPoints extension with an https URI or similar scheme, circular dependencies can be introduced. The relying party is forced to perform an additional path validation in order to obtain the CRL required to complete the initial path validation! Circular conditions can also be created with an https URI (or similar scheme) in the authorityInfoAccess or subjectInfoAccess extensions. At worst, this situation can create unresolvable dependencies.

CAs SHOULD NOT include URIs that specify https, ldaps, or similar schemes in extensions. CAs that include an https URI in one of these extensions MUST ensure that the server’s certificate can be validated without using the information that is pointed to by the URI. Relying parties that choose to validate the server’s certificate when obtaining information pointed to by an https URI in the cRLDistributionPoints, authorityInfoAccess, or subjectInfoAccess extensions MUST be prepared for the possibility that this will result in unbounded recursion.

УЦ не должны включать HTTPS или LDAP-ссылки для публикации своих списков отзыва.

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

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

Другими словами, клиент и сервер будут пытаться поднять защищенное HTTPS-соединение друг с другом. Для этого им потребуется проверить сертификаты на отзыв. А чтобы это сделать, тоже нужно поднять защищенное соединение по HTTPS-ссылке к CRL, которую УЦ неосмотрительно опубликовал в атрибуте сертификата.

Следует упомянуть, что существует иной способ проверки сертификата на отзыв.

Протокол онлайн-проверки статуса сертификата OCSP — Online Certificate Status Protocol.

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

А для работы с сервером OCSP они должны включать еще и расширение OCSP Server Client.

Но это материал для отдельной статьи.

Обязательные атрибуты квалифицированных сертификатов

Состав квалифицированного сертификата регулируется Федеральным законом «Об электронной подписи» от 06.04.2011 N 63-ФЗ и Приказом ФСБ РФ от 27 декабря 2011 г. N 795 «Об утверждении Требований к форме квалифицированного сертификата ключа проверки электронной подписи».

Несколько раз встречались квалифицированные сертификаты проверки подписи юридических лиц, выпущенные аккредитованным УЦ, в которых в поле Subject — субъект сертификации отсутствовал атрибут L – Местоположение.

Контроль квалифицированных сертификатов нашей системы отвергал данный сертификат и документы с ЭП партнера.

Удостоверяющий центр данную ситуацию комментировал так:

атрибут L для юридических лиц, зарегистрированных в г. Москве, не проставляется согласно 63-ФЗ и Приказа №795

На конкретный пункты Закона и Приказа в УЦ не ссылались.

Собственный повторный анализ юридических аспектов показал:

63-ФЗ от 06.04.2011 «Об электронной подписи»

Статья 14. Сертификат ключа проверки электронной подписи

2. Сертификат ключа проверки электронной подписи должен содержать следующую информацию:

2) фамилия, имя и отчество (если имеется) — для физических лиц, наименование и место нахождения — для юридических лиц или иная информация, позволяющая идентифицировать владельца сертификата ключа проверки электронной подписи;

Статья 17. Квалифицированный сертификат

2. Квалифицированный сертификат должен содержать следующую информацию:

2) фамилия, имя, отчество (если имеется) владельца квалифицированного сертификата — для физического лица, не являющегося индивидуальным предпринимателем, либо фамилия, имя, отчество (если имеется) и основной государственный регистрационный номер индивидуального предпринимателя — владельца квалифицированного сертификата — для физического лица, являющегося индивидуальным предпринимателем, либо наименование, место нахождения и основной государственный регистрационный номер владельца квалифицированного сертификата — для российского юридического лица, либо наименование, место нахождения владельца квалифицированного сертификата, а также идентификационный номер налогоплательщика (при наличии) — для иностранной организации (в том числе филиалов, представительств и иных обособленных подразделений иностранной организации);

Приказ ФСБ РФ от 27 декабря 2011 г. № 795

III. Требования к порядку расположения полей квалифицированного сертификата

5) stateOrProvinceName (наименование штата или области).

В качестве значения данного атрибута имени следует использовать текстовую строку, содержащую наименование соответствующего субъекта Российской Федерации. Объектный идентификатор типа атрибута stateOrProvinceName имеет вид 2.5.4.8;

6) localityName (наименование населенного пункта).

В качестве значения данного атрибута имени следует использовать текстовую строку, содержащую наименование соответствующего населенного пункта. Объектный идентификатор типа атрибута localityName имеет вид 2.5.4.7;

7) streetAddress (название улицы, номер дома).

В качестве значения данного атрибута имени следует использовать текстовую строку, содержащую часть адреса места нахождения соответствующего лица, включающую наименование улицы, номер дома, а также корпуса, строения, квартиры, помещения (если имеется). Объектный идентификатор типа атрибута streetAddress имеет вид 2.5.4.9;

В сертификате партнера в имени субъекта сертификации были указаны: stateOrProvinceName (наименование штата или области), streetAddress (название улицы, номер дома).

И не указано localityName (наименование населенного пункта).

locality — Местонахождение

В Законе 63-ФЗ и Приказе №795 нет информации, что для города Москва не нужно заполнять атрибут locality — Местонахождение.

Наоборот в обоих документах на русском языке применяется термин место нахождения, чему соответствует атрибут localityName ( 2.5.4.7)

Согласно части 2.2 статьи 18 Закона об ЭП для заполнения квалифицированного сертификата в соответствии с частью 2 статьи 17 Закона об ЭП аккредитованный удостоверяющий центр запрашивает и получает из государственных информационных ресурсов, в том числе, выписку из единого государственного реестра юридических лиц в отношении заявителя ‑ юридического лица.

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

На основании изложенного в качестве значения атрибута имени «localityName» поля «subject» в структуре квалифицированного сертификата следует указывать текстовую строку, содержащую наименование соответствующего населенного пункта или соответствующего муниципального образования.

Данное извещение с разъяснениями регулятора, как правильно заполнять атрибут L в квалифицированном сертификате юридического лица, также было направлено в аккредитованный УЦ.

Прошу использовать данную информацию в работе.

Желаю всем участникам PKI удачи и успехов!

удостоверяющий центр
pki
public key infrastructure
инфраструктура открытых ключей
rfc
rfc5280
ietf
x.509
электронные сертификаты
электронная подпись

Для чего настраивается cdp уц

Какой смысл в том, что CRL с красивым именем «Имя службы сертификации.crl» (. \WINNT\system32\CertSrv\CertEnroll) при публикации в папку CDP виртуального каталога CA Web-узла ЦС переименовывается в «идентификатор ключа субъекта.crl»? Хотел настроить задачу переноса CRL c RA (или напрямую с CA) на внешнюю CDP, но оказывается его еще и переименовывать надо, а стандартная задача этого не делает. Зачем это и как попроще вернуть файлу его первоначальное имя?

Или расскажите как обычно делают эту публикацию именно на внешнюю CDP (не CA и не RA)?

Эти файлы переименовывать не надо, а настройка задачи переноса CRL на внешний ресурс ничем принципиальным не отличается от переноса в ресурс RA. Просто в папке-приемник надо прописать новое, нужное вам, значение — сетевой путь — \\computer\folder, или даже http://a.b.ru/cdp

Давайте вернемся к понятиям (УЦ :-)) — CDP в сертификате (поле 2.5.29.31) — это должно быть указание на папку или на конкретный CRL?
Если на папку, то ДА, вопроса нет, я буду складывать туда тот самый «идентификатор ключа субъекта.crl», который к тому же при плановой смене сертификата УЦ тоже сменит имя.
Если же в этом поле надо указать местонахождение конкретного CRL, тогда таки придется переименовывать. Иначе как а пропишу в выдаваемые сертификаты имя файла CRL, которое может меняться?

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

Значит сделал следующее: Перемотал на машинах CA, RA и АРМах время на дату издания сартификата СА + 1 год и 2 дня с желанием провести плановую смену сертификатов.

Первое, что выяснилось — это что сертификат на Web-сервер CA был издан ровно на 1 год, а не на 1 год и 3 месяца, как сертификаты на RA и его Web-сервер. Это так и должно быть?

Отмотал время везде на 3 дня назад, перезагрузился, сменил по инструкции сертификат и ключи СА. Всё, теперь у меня на CA лежат 2 сертификата и 2 CRL. Отзываю старый сертификат какого-нибудь клиента — он появляется в старом CRL, новый — в новом, все OK! Захожу на RA, вручную запускаю задачу переноса CRL с CA на RA и получаю сообщение, что задача выполнена, но в процессе ее выполнения произошли ошибки. Заглядываю в папку CDP на RA, там лежит только один CRL — первый (предварительно руками очистил эту папку), смотрю журнал, там написано, что один CRL перенесен нормально, а дальше десяток сообщений об ошибках суть которых в том, что система не смогла доставить какие-то сообщения (ну да, так наверное и надо — я не настраивал рассылку сообщений). А почему у меня не перенеслись другие CRL’и?

И еще: на днях я настроил CA, чтобы он прописывал в выдаваемые сертификаты CDP. Так вот, при переиздании сертификата CA в нем тоже появилось это поле, правда certutil говорит, что оно «EMPTY», а при просмотре этого поля виндовым просмотрщиком сертификатов выскакивает ошибка и просмотрщик закрывается. Это так тоже надо? Убрал галочку, заставляющую вписывать в сертификаты CDP, еще раз переиздал сертификат CA — он издался как и самый первый раз — вообще без поля CDP. Что, при смене сертификата CA эти галки надо снимать?
Теперь у меня уже 3 сертификата CA и 3 CRL. Хорошо, что УЦ тестовый. 🙂 Но и с тремя CRL’ями на RA переносится только один. 🙁

Сегодня перематывал дату с 2005 года обратно на настоящее время. При этом перевыпустил все сертификаты. Нормальный capolicy.inf как лежал, так и лежит в нужном месте. Результаты схоны со вчерашними:
Если в настройках CA стоит указатель на CDP (причем _НЕВАЖНО_, стоит перед ним галочка или нет) — при перевыпуске сертификата CA в него попадает пустое поле 2.5.29.31, на котором стандартный просмоторщик сертификатов Windows ведет себя неадекватно. Это поле _НЕ_ появляется только если перед перевыпуском сертификата CA _ПОЛНОСТЬЮ_ очистить окошко с CDP. Поэтому перед сменой сертификата CA наверное надо сначала очистить это окно (что логично — при смене сертификата поменяется и имя файла), затем переиздать сертификат, а затем приписать новую CDP в настройки CA. По крайней мере у меня это вариант сработал нормально, а другие нет.

Настройку задачи переноса CRL’ей с CA на RA сделал — действительно надо было просто вручную довавить в список новый CRL. Кстати, эту процедуру тоже надо не забыть сделать после смены сертификата CA.

Я что-то недочитал в документации? Смену сертификата CA можно провести какими-нибудь другими средствами?

> А чем вам не нравится CRL по URL .
> Там версия ЦС 0.0 — значит плановой смены ключей уполномоченного лица УЦ еще не было.
> CRL должен быть один.

Для чего настраивается cdp уц

Программно-аппаратный комплекс «Удостоверяющий Центр «КриптоПро УЦ» версии 2.0 (сокращённо – ПАК «КриптоПро УЦ 2.0») обеспечивает автоматизацию деятельности удостоверяющего центра и может использоваться как в качестве средства удостоверяющего центра в нотации 63-ФЗ «Об электронной подписи», так и в качестве центра управления сертификатами.

ПАК «КриптоПро УЦ» является первым в Российской Федерации специализированным программно-аппаратным комплексом, успешно прошедшим сертификационные испытания и получившим сертификат соответствия ФСБ России. С момента получения первого сертификата соответствия в 2003 году ПАК «КриптоПро УЦ» неоднократно модернизировался.

Качество и защищённость новых версий комплекса подтверждалось ростом числа инсталляций продукта и новыми сертификатами соответствия ФСБ России.

Свидетельством отличных эксплуатационных характеристик ПАК «КриптоПро УЦ» является его широкое применение как органами государственной власти и местного самоуправления, так и субъектами малого, среднего и крупного бизнеса всех отраслей.

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

ПАК «КриптоПро УЦ» версии 2.0 вобрал в себя весь продолжительный опыт эксплуатации средств удостоверяющих центров и на настоящий момент является наиболее оптимальным средством автоматизации деятельности удостоверяющих центров.

ПАК «КриптоПро УЦ» версии 2.0 представляет собой программный комплекс, состоящий из следующих логических компонент:

Серверные компоненты, включающие в себя:
- Центр сертификации (ЦС) – обеспечивает изготовление сертификатов и списков отозванных сертификатов в соответствии с настраиваемой политикой PKI. На одном физическом сервере может быть размещено несколько Центров сертификации. Каждый Центр сертификации взаимодействует только с Центром регистрации;
- Центр регистрации (ЦР) – обеспечивает реализацию всей логики работы комплекса по назначению, осуществляет ведение всех реестров УЦ. На одном физическом сервере может быть размещён только один Центр регистрации. Взаимодействует как с одним или несколькими Центрами сертификации (размещёнными на одном физическом сервере), так и с АРМ ОП и АРМ пользователя, фактически являясь посредником (брокером) между ними;
- CDP — обеспечивает функционирование автономного Пункта распространения CRL в соответствии с настраиваемой политикой PKI. На одном физическом сервере может быть размещен только один компонент «CDP». Компонент «CDP» взаимодействует с Центром сертификации и/или с Центром регистрации.
- Автоматизированное рабочее место (АРМ) обслуживающего персонала (АРМ ОП) – толстый клиент, который предоставляет графический пользовательский интерфейс для удалённого управления сотрудникам из числа обслуживающего персонала Удостоверяющего центра (администраторам, операторам и т.д.). На одном компьютере может быть размещено несколько АРМ ОП. АРМ ОП взаимодействует только с Центром регистрации;
- АРМ разбора конфликтных ситуаций (АРМ РКС) – предназначен для оборудования рабочего места эксперта, в случае необходимости проведения экспертизы по подтверждению подлинности электронной подписи в документе или сертификате. На одном компьютере может быть размещён только один АРМ РКС. АРМ РКС не взаимодействует ни с какими компонентами и предназначен только для автономной работы;
- АРМ пользователя — комплекс программ, который предоставляет пользователям через веб-браузер графический интерфейс для взаимодействия с УЦ. С помощью этого АРМ пользователи формируют ключи, создают и отправляют запросы на Центр регистрации, получают необходимую информацию из реестров УЦ. АРМ пользователя взаимодействует с Центром регистрации и/или с CDP.
Все компоненты ПАК «КриптоПро УЦ» взаимодействуют друг с другом с использованием защищенного транспортного протокола Transport Layer Security (TLS) с двухсторонней аутентификацией.

Что такое Customer Data Platform (CDP)?

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

Определение customer data platform

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

Платформа централизует сбор данных из разных источников, отслеживает поведение каждого пользователя в реальном времени во всех подключенных каналов. Она объединяет эту информацию в единый 360-градусный профиль клиента и поддерживает его актуальность. Так, в одной системе бизнес имеет доступ к данным о каждом клиенте и может использовать их сполна: создавать гиперцелевые сегменты и автоматизированно взаимодействовать с покупателями через персонализированные триггерные кампании. Customer data platform гарантирует компании доступ в режиме реального времени к профилям клиентов, транзакционным событиям, аналитическим атрибутам.

Чем отличается CDP от DMP, CRM, DWH, Analytics System, Marketing Automation System

Основные отличия платформы клиентских данных от других систем:
1. Организовывает единое место для сбора клиентских данных:
  - первичных – из онлайна, офлайна, мобильного приложения, директ-каналов, соцсетей, программ лояльности;
  - из посторонних систем – сервисы автоматизации маркетинга, CRM, DMP и других, а также баз данных типа BigQuery, PostgreSQL, Google Sheets, Firebase;
  - разного форматам – структурированных, частично структурированных, неструктурированных
2. Организовывает единое место для обработки клиентских данных – консолидирует информацию о пользователях, при необходимости удаляет дубликаты, создает унифицированные клиентские профили, которые обогащаются новой информацией в режиме реального времени. Так CDP обеспечивает постоянную единую базу клиентских данных.
3. Позволяет управлять клиентскими данными:
  - использовать их внутри платформы для сегментации, персонализации на основе AI;
  - создавать автоматические омниканальные рассылки;
  - передавать структурированные данные в другие системы;
  - хранить данные (идентификаторы, поведение и атрибуты) столько времени, сколько нужно бизнесу.
Каждая из систем – DMP, CRM, DWH, Analytics System, Marketing Automation System – имеет свою сущность и собирает данные разного типа и для конкретных бизнес-потребностей:
- DMP (платформа управления данными) собирает поверхностные анонимные данные через посторонние источники и использует их для краткосрочной точной рекламы. Система имеет ограниченные сроки хранения данных, поскольку таргетинг не может строиться на устаревшей информации.
  В отличие от DMP, CDP собирает первичные данные пользователей, обогащает их и сохраняет столько времени, сколько требуется бизнесу. Платформа улучшает маркетинг и управляет долгосрочными отношениями с клиентами.
  Customer data platform может передавать данные в DMP для создания сегментов аудитории и более эффективного таргетинга рекламных кампаний.
- CRM (customer relationship management) помогает организовывать и управлять отношениями с клиентами. В систему данные чаще вручную вносят работники отдела продаж, которые непосредственно общаются с клиентами.
  В отличие от CRM, CDP собирает поведенческие данные клиента (включая период предшествующий первому заказу). Также платформа предоставляет маркетологам удобные инструменты для сегментации, персонализации и автоматизации взаимодействия с большим количеством людей.
  Одновременное использование CDP и CRM обеспечивает качественную и всестороннюю аналитику, которая необходима для понимания клиентов, выявления паттернов их поведения, прогнозирования будущих действий и, наконец, оптимизации бизнеса.
- DWH (data warehouse) извлекает структурированные данные и сохраняет их в статическом состоянии неограниченное время. Их структура позволяет использовать информацию в соответствии с конкретными целями (чаще всего для исторического и финансового анализа). Для настройки и эффективного использования DWH требуется технический специалист.
  В отличие от DWH, CDP – это решение для хранения, анализа и использования маркетинговых данных в режиме реального времени. Понятный интерфейс не нуждается в специализированных знаниях, что позволяет маркетологу самостоятельно использовать платформу.
  Customer data platform может обеспечить гибкость данных DWH, чтобы использовать их дальше для развития бизнеса.
- Аналитическая система импортирует данные из разных источников, баз данных, файлов Excel, CSV, API. Она может унифицировать данные, но этот процесс сложен, особенно когда информация поступает в разных форматах и разных структурах. Система предоставляет широкий спектр инструментов для анализа, в частности, статистические методы, AI. Для обработки больших объемов данных такая система требует много времени.
  В отличие от аналитической системы, CDP обеспечивает централизованное хранение данных, создание профилей, имеет более высокий уровень унификации данных и идентификации клиентов. Платформа предоставляет функциональность для управления данными, в частности для сегментирования, персонализации (на основе данных, поступающих в систему в режиме реального времени) координации между разными каналами коммуникаций.
  Customer data platform может обогатить аналитическую систему, предоставляя ей более полные, актуальные, более точные и связные данные о клиентах для анализа и извлечения ценных инсайтов о них, исследования поведения и понимания их потребностей.
- Система автоматизации маркетинга обычно работает с данными, собранными внутри системы, и сосредоточена на автоматизации маркетинговых процессов, таких как отправка электронных писем, управление кампаниями и т.д.
  В отличие от системы МА, CDP с функциональностью автоматизации коммуникаций предоставляет возможности для сбора данных из разных источников, их унификации, анализа и визуализации.
  МА может использовать полные и консолидированные данные customer data platform для персонализации коммуникаций.
Зачем нужна CDP

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

О преимуществах и возможностях CDP свидетельствуют:
1. Forrester Research в исследовании «The State of Customer Data Platforms», 2022 г., пишет, что благодаря CDP бизнес может:
  - увеличить привлечение новых клиентов на 15%;
  - увеличить привлечение существующих клиентов на 20%;
  - удерживать 85% клиентов;
  - увеличить LTV клиентов на 30%;
  - увеличить свои доходы до 25%.
2. Econsultancy в отчете “The CDP Report 2022” отмечает, что компании, использующие customer data platform, наблюдают увеличение:
  - количества потенциальных клиентов на 30%,
  - посещаемости сайта на 20%;
  - удовлетворенности клиентов на 15%.
3. Исследование IDC показывает, что инвестировать в платформу клиентских данных рентабельно: CDP является второй лучшей инвестицией в технологии клиентского опыта в течение двух лет подряд. Способность контекстуализировать взаимодействие и предоставить потребителям интеллектуальный опыт – конкурентное преимущество в цифровую эру.
Как работает CDP eSputnik

Сбор данных

Платформа данных клиентов организовывает сбор первичных данных бизнеса – это самый ценный тип данных, которым владеет компания. В CDP передается статическая информация (имя, возраст, пол, город, профессия и т.п.) и поведенческие данные пользователей из:
- сайта – доступны интеграции с конструкторами сайтов, лендингов, интернет-магазинов через API, в частности система имеет уже встроенную интеграцию с сайтами на платформе «Хорошоп»;
- мобильного приложения – обмен информацией между приложением и CDP происходит через SDK;
- direct-каналов – в системе доступно 8 каналов для рассылок: email, web и mobile push, in-app, app inbox, виджеты, Viber, SMS;
- офлайн – данные транзакций розничных магазинов передаются в CDP через POS-терминал, также сотрудники могут вручную вносить данные о просмотре товаров посетителями.
В зависимости от конкретных задач бизнеса CDP может интегрироваться с различными источниками данных для обеспечения максимальной полноты и точности анализа данных клиентов. Customer data platform позволяет организовать обмен информацией с такими системами:
- платформы сбора, хранения и работы с данными – CRM, DMP, DWH и другие;
- аналитические системы – Google Analytics, Power BI и другие;
- базы данных – BigQuery, PostgreSQL, Google Sheets, Firebase.
CDP можно интегрировать с другими сервисами благодаря онлайн-коннекторам Zapier и ApiX-Drive.

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

Унификация профиля

Все данные о клиентах (и/или пользователях сайта или приложения) поступают в систему разными методами: CSV, JSON, SQL, API-вызовы, HTTP-запросы, и в разных форматах: структурированные, неструктурированные, частично структурированные. Customer data platform обрабатывает их, приводит к единому виду, идентифицирует информацию с картой соответствующего контакта. eSputnik привязывает профили к конкретному человеку, даже если он пользуется разными устройствами, система сочетает атрибуты с идентификаторами. С первого визита человека на сайт или в мобильное приложение она присваивает ему уникальный идентификатор и фиксирует каждое взаимодействие.

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

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

Узнать как работает CDP

Сегментация

По данным Litmus (Email Marketing Benchmarks Report 2023), сегментированные рассылки имеют коэффициент открытий 20% и 3,5% кликов, несегментированные – 15% и 2,5% соответственно. Сегментированные эмейлы приносят на 10% больше дохода, чем несегментированное. Эти показатели могут быть значительно больше, если бизнес строит группы на основе полной актуальной информации о своих клиентах и сегментирует аудиторию более чем по 3 условиям.

eSputnik позволяет проводить продвинутую сегментацию клиентов на основе всей доступной информации о них, в частности поведенческих данных. Количество условий для формирования сегмента не ограничено. В системе доступны следующие расширенные функции:
- RFM-сегментация. На основе собранных данных формируется RFM-анализ по продажам и активности в рассылках. Система прогнозирует, когда клиент перейдет из одного сегмента в другой. На основе этого анализа можно настроить триггеры: кампания будет автоматически отправляться пользователю, когда он перейдет в соответствующий сегмент. Например, это помогает раньше времени реактивировать малоактивных пользователей или выделить VIP-сегмент и разработать стратегию для работы с ним.
- Сегментация по событиям. Любое событие, например заказ, его параметр, например сумму, или их комбинацию можно назначить условием формирования группы. Такая технология позволила украинской службе доставки еды управлять продажами в каждом городе из региона доставки. Компания реализовала стратегию удержания, с помощью сегментации по ивентам и персональных рекомендаций. За пол года использования функциональности: LTV стал выше на 12%, количество заказов выросло на 40%, средний чек увеличился на 16%, после реактивационных триггеров 25% клиентов снова начали заказывать, а окупаемость инвестиций составляет 152%.
- Параметрическая сегментация. Этот инструмент экономит время на подготовку рассылок для однотипных групп, отличающихся только значением параметра, по которому строится сегмент. К примеру, чтобы анонсировать акции в разных категориях, нужно делать отдельные сегменты и сценарии для каждой из них. С параметрической сегментацией достаточно сделать только один. Вместо конкретного значения (раздела товаров) в условиях запуска будет переменная. Как только в систему поступит событие с акцией, она автоматически подберет контакты и запустит кампанию.
- Предиктивная сегментация. Это мощный инструмент для повышения CLV, поскольку позволяет предвидеть особенности поведения клиентов и в соответствии с этим корректировать стратегии. В системе есть набор готовых алгоритмов для формирования сегментов, прогнозирующих вероятность покупки или оттока клиентов. В такие технологии вкладывают средства 74% опрошених маркетологов. Они могут быстро настраивать кампании, основываясь на предиктивной модели, а не более простых решениях типа «не покупал Х дней». Это помогает вовремя удержать тех, кто может уйти, и с большей вероятностью извлечь прибыль от потенциальных покупателей.
Обработанные и структурированные данные можно сразу использовать в CDP для создания персонализированного взаимодействия на сайте, в мобильном приложении, директ-каналах. Дополнительно, эти данные можно передавать в другие системы.

Хотите строить гиперцелевые сегменты и получать высокие конверсии?

Активация данных

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

Персонализация

80% клиентов склонны покупать у тех компаний, которые предлагают персонализированный опыт (Epsilon). По исследованию Accenture, 91% потребителей вероятно выберут бренд, предлагающий персонализированные предложения.

Персональные рекомендации решают для бизнеса следующие задачи:
- Активация аудитории. Благодаря полноте данных и всестороннему анализу бизнес может подтолкнуть своих пользователей к действиям благодаря персонализированному взаимодействию с учетом их потребностей, предпочтений, выбранных каналов, языка, времени коммуникации.
- Улучшение пользовательского опыта. Предложения товаров, соответствующие предпочтениям и интересам человека, делают пользование сайтом и мобильным приложением привлекательным и удобным, способствуют росту доверия к бренду. Рекомендации создают впечатление, что бизнес понимает потребности покупателя и может предлагать оптимальные решения.
- Повышение коэффициента конверсии. Персональные товарные рекомендации формируются на основе данных и поведения клиентов. Такие предложения упрощают юзерам поиск нужных продуктов, а компании наращивают количество клиентов и заказов.
- Увеличение средней стоимости заказа через кросс-сейл и апсейл. Когда бизнес сталкивается с низкой маржинальностью основной категории продукции, продажи сопутствующих товаров и аксессуаров могут повлиять на общий доход. Использование персональных рекомендаций увеличивает количество позиций в чеке и продажи позиций из кросс-категорий. А предложения комплектов, где к основному предлагается сопутствующий товар со скидкой, стимулируют импульсивные покупки.
  Рекомендации более дорогих продуктов, похожих на те, которые клиент уже рассматривает, стимулируют к покупке товаров высшей категории. Они также способствуют увеличению объемов продаж и росту среднего чека.
По информации Econsultancy, компании, использующие расширенную персонализацию, сообщают возврате 20 долларов на каждый потраченный доллар.

По нашей статистике, персональные товарные рекомендации генерируют около 20% онлайн-выручки магазинов.

Как формируются рекомендации

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

AI строит прогнозы на основе:
- предварительного поведения большого количества клиентов;
- данных о товарах и их характеристиках.
В eSputnik алгоритмы наполняют блоки на основе данных:
1. Клиента – AI учитывает поведение конкретного пользователя, анализирует предыдущие покупки, поведение на страницах категорий и товаров, добавление в избранное и т.д.
2. Товара – AI учитывает просмотры, клики пользователей, категорию, описание, название и цену товара.
3. Общих – AI учитывает популярные товары среди других покупателей.
Так, для ритейлера «Фокстрот» реализовано более 10 блоков персональных товарных рекомендаций. Они размещены на сайте, в рассылках, они также доступны менеджерам в call-центрах и оффлайн. Рекомендации создаются благодаря синергии AI и data science-специалистов. Алгоритмы eSputnik могут прогнозировать, какие товары приобретут клиенты, с точностью до 60%. А чтобы в подборку попадали только правильные товары, этот процесс контролирует аналитик: настраивает и обучает систему.

Благодаря этой функциональности «Фокстрот» увеличил продажи аксессуаров на 16% при том же трафике, конверсию – на 5%, а глубину просмотра и вовлеченность на сайте – на 10%.

Настроить рекомендации маркетолог может самостоятельно без посторонней помощи программистов. За долгие годы тестирования и работы с разными бизнесами команда eSputnik выбрала наиболее эффективные алгоритмы и сделала их доступными в интерфейсе системы. Теперь в CDP есть 180 алгоритмов формирования рекомендаций. Один из востребованных алгоритмов – рекомендации в массовых рассылках. Система способна обрабатывать огромные объемы данных и вычислять, какие товары каждый пользователь захочет купить с наибольшей вероятностью на основе предыдущих покупок и кликов. Этот алгоритм увеличивает CTR и конверсию после клика и приносит клиентам дополнительные 14% заказов из кампании.

Персонализировать коммуникацию с каждым клиентом

Триггеры

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

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

За годы анализа команда выделила 15 самых прибыльных pro-сценариев для e-commerce: «Снижена стоимость на товары в корзине», «Регулярный спрос», «Товар не в наличии», «Лучшее предложение», «Триггеры по событию WishList», «Брошенный поиск», «Реактивация» и другие.

Так, Аптека АНЦ, Лидер среди фармацевтических ритейлеров Украины, запустила 5 персонализированных триггеров. Они разрешили увеличить продажи в онлайне на 3% за первые 2 месяца работы, в то же время прибыль от внедрения кампаний в Viber выросла на 87%, в email – на 38%.

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

Омниканальность

Омниканальность предполагает возведение в единую систему всех каналов коммуникации с ЦА. Каждый из них обогащает единый профиль и имеет доступ к полному набору данных в системе. Когда каналы согласованы и дополняют друг друга, обеспечивается качественное и непрерывное взаимодействие с клиентом. Благодаря объединению данных из разных источников и каналов, постоянному обогащению информации и анализу, бизнес может составить портрет клиента и построить customer journey map.

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

На сегодняшний день в eSputnik для рассылок доступно 8 каналов: email, web и mobile push, in-app, app inbox, виджеты, Viber, SMS, в процессе интеграции: WhatsApp и Telegram.

Широкий выбор каналов позволяет создать омниканальные сценарии, которые:
- максимально охватят аудиторию – использование разных каналов увеличивает вероятность доставки сообщения;
- улучшат взаимодействие с пользователями – клиент получает сообщения в том канале, где он наиболее активно взаимодействует с брендом;
- увеличат релевантность взаимодействия – каждый канал имеет свою сущность и контекст использования; в сочетании они позволяют комплексно охватывать клиентов, обеспечивать им последовательное сопровождение.
Поскольку функциональность платформы клиентских данных систематизирует и анализирует данные по каналам, то бизнес может точно определить влияние каждого из них на конверсию. Это особенно важно для компаний, аудитории которых присуща ROPO-модель поведения: с товаром знакомятся и решают приобрести благодаря коммуникации через direct-каналы, а непосредственная покупка проходит в оффлайн-магазине. Благодаря customer data platform бизнес может атрибутировать покупки конкретным клиентам. В результате это позволяет компании отследить путь клиента и узнать ценную информацию:
- обнаружить слабые места, через которые клиенты могут покинуть заказ,
- знать количество взаимодействий предшествующих конверсии,
- отслеживать связь между сообщениями и заказами,
- знать поведение аудитории в разных каналах.
Внедрить омниканальные комуникации с вашими клиентами

Как клиенты используют CDP eSputnik

Топовые украинские ecommerce-бизнесы используют customer data platform eSputnik для улучшения маркетинговых кампаний:

Dnipro-M получил +1000% ROI благодаря App Inbox и рекомендациям

Украинский производитель инструментов для строительства Dnipro-М отслеживает действия своих пользователей, объединяет данные клиента в единый профиль, сегментирует потребителей по поведению и предлагает товарные рекомендации в рассылках и на сайте.

Омниканальные сценарии с email и push-уведомлениями недополучали охват из-за небольшого количества емейл-адресов в базе. Customer success менеджер eSputnik предложил добавить канал App Inbox в массовые и триггерные коммуникации.

Благодаря этому ритейлер получил увеличение доли от суммы заказов:
- в 3 раза на схожие товары;
- в 5 раз на товары из корзины;
- в 20 раз на товары из просмотра.
Также Dnipro-M ввел товарные рекомендации на сайте. Они сгенерировали рост доли от общей суммы заказов в октябре по сравнению с сентябрем 2022 года:
- на главной странице сайта – в 2,4 раза;
- на странице товара – в 2,2 раза.
Так, благодаря усовершенствованию алгоритмов и оптимизации триггеров удалось повысить ROI товарных рекомендаций на 23,5%.

COMFY внедрил кастомный алгоритм рекомендаций с персональными фильтрами

Ритейлер бытовой техники и электроники COMFY, усилил массовые и триггерные имейл-рассылки персональными товарными рекомендациями.

Команда eSputnik помогла настроить алгоритмы и кастомизировала выдачу по приоритетным признакам товаров. Функциональность рекомендаций eSputnik позволяет в первую очередь показывать клиентам конкретную группу товаров, а именно – товары с пометкой “Кращ” (“Лучшие”) как приоритетные товары и регулировать их количество.
- 13% дохода с триггеров с участием рекомендаций;
- 20% количества заказов из триггеров приходится на персонализированные блоки.
- 49% общего количества заказов в промо рассылках дают персонализированные блоки;
- 41% – средняя доля кликов по блокам с рекомендациями по массовым рассылкам;
Сейчас алгоритм, разработанный специально для COMFY, стал доступным для всех пользователей тарифа PRO.

Prom.ua увеличил продажи на 10% благодаря персонализированным триггерным пуш-уведомлениям

Самый большой маркетплейс Украины Prom.ua отказался от массовых рассылок и персонализировал взаимодействие с миллионами клиентов. Бизнес использует триггерные кампании с учетом жизненного цикла клиента, дает персональные товарные рекомендации в рассылках.

Prom.ua – это mobile first компания, позиционирующая себя как «маркетплейс в кармане». Поэтому основным каналом для коммуникаций были выбраны пуши (они генерируют 90% продаж от direct-каналов), дополнительным – email. Маркетплейс разработал более 70 автоматизированных кампаний. Самые интересные из них: триггеры, основанные на брошенных действиях (просмотры, корзины, товары, поиск), онбординг, списки желаний, запрос на отзыв, cross-sell, отмена заказа, уменьшение цены, рекомендации лендингов и т. д.

Благодаря такому комплексному подходу к маркетингу команда Prom.ua достигла значительных результатов:
- доля дохода direct-каналов выросла в 5 раз;
- персонализированные триггеры увеличили продажи на 10%, самые эффективные триггеры – «брошенный просмотр» и «списки желаний»;
- персональные рекомендации продуктов в сообщениях принесли дополнительные 3% продаж;
- омниканальные кампании обратной связи приносят до 70% всех отзывов клиентов и помогают продавцам развивать свои магазины.
CDP предоставляет бизнесу всю необходимую функциональность для создания такого клиентского опыта, который разрешает повышать конверсии и увеличивать прибыль.

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

eSputnik всегда готов помочь компаниям получить максимум от нашей платформы, поэтому каждый клиент может ожидать необходимой поддержки support-отдела.

Чем масштабнее бизнес, тем сложнее постичь все задачи и решения для его продвижения. У некоторых компаний возникают трудности с определением целей: что будет соответствовать «360-градусному профилю» клиента, какие данные для чего собирать, как использовать. eSputnik заинтересован в устойчивом развитии своих клиентов, поэтому для пользователей pro-функциональности CDP предоставляет персонального success-менеджера. Он участвует в улучшении эффективности бизнеса: помогает формировать цели, сопровождает интеграцию и настройку системы, дает советы по оптимизации кампаний и т.д.

Выбирайте время, и наша команда с удовольствием подскажет, как CDP eSputnik может усилить именно ваш бизнес.

Персональная консультация для вашего бизнеса

Выводы

CDP eSputnik – это платформа для сбора, унификации, сегментирования и активации данных клиентов с целью управления пользовательским опытом и увеличения прибыли бизнеса. Это передовой маркетинговый инструмент, помогающий лучше понимать своего клиента и создавать лучшее взаимодействие с ним. В отличие от других систем, customer data platform создает единый профиль клиента, в котором фиксирует всю полученную и обработанную информацию. Данные обновляются в режиме реального времени и доступны для формирования групп аудитории на основе большого количества детализированных условий, в том числе по событиям и их параметрам.

Платформа клиентских данных имеет встроенный AI, который прогнозирует будущие действия клиентов: вероятность их оттока или покупок, а также детализацию их вероятных заказов – определяет какие именно товары приобретут покупатели. Чтобы каждый тип бизнеса мог в полной мере использовать товарные рекомендации, в системе доступно 180 готовых алгоритмов, а также есть возможность кастомной разработки. Такой возможностью воспользовался “Фокстрот” и повысил продажи сопутствующих товаров на 16%.

Чтобы правильно и своевременно реагировать на поведение аудитории, используются триггерные рассылки. Так, крупнейший украинский маркетплейс Prom.ua благодаря персонализации триггерных пушей увеличил продажи на 10% с директ-каналов и увеличил удержание клиентов на 4%.

Благодаря customer data platform можно реализовать омниканальный маркетинг: в системе для этого доступно 8 директ-каналов. Поэтому каждый бизнес может протестировать и определить наиболее конверсионные из них и качественно дополнить свою стратегию. К примеру, Dnipro-M охватил аудиторию с помощью app inbox и получил увеличение доли от суммы заказа в разы, а ROI составил +1000%.

Если вы хотите иметь лояльных, постоянных и довольных клиентов, которые будут увеличивать ваш доход – выбирайте комплексное решение CDP eSputnik и вместе мы выведем маркетинг вашей компании на новый уровень!
Похожие публикации: