Вы не можете произнести слово «персонализация» без слова «человек».
Цифровым маркетологам не привыкать к машинному обучению, особенно когда речь идет о персонализации. В конце концов, машинное обучение обеспечивает рекомендации по продуктам и контенту, кампании с лучшими предложениями, автоматизацию маркетинга и бесчисленное множество других задач, которые когда-то были утомительными и выполняемыми вручную. Это знакомство должно утешать нас, поскольку влиятельные лица наводняют LinkedIn контентом о ChatGPT, расширяющемся охвате искусственного интеллекта и стремлении руководителей заменить сотрудников новыми технологиями: мы уже знаем, что машины сами по себе могут не так много.
Да, программы искусственного интеллекта могут выдавать работающий веб-код HTML в ответ на простую текстовую подсказку, но настройка этого нового веб-сайта в качестве цели активации для кампаний персонализации по-прежнему требует человеческих знаний и руководства. В конце концов, боты, генерирующие код, (пока) не знают маркетинговой стратегии вашей организации, какие инструменты MarTech составляют стек вашей команды или даже сколько других веб-сайтов являются частью вашего маркетингового портфеля.
Применение этих знаний, наряду с некоторыми вспомогательными работами по веб-разработке, может помочь не допустить, чтобы недавно реализованный инструмент персонализации действовал по-своему, мешал другим программам и ухудшал работу в Интернете для ваших клиентов.
Не противопоставляйте свои инструменты друг другу
В основе персонализации лежит утверждение человеческой индивидуальности — идеи о том, что каждый потребитель действительно уникален в своем поведении и характеристиках. Чтобы воплотить это в жизнь с помощью HTML-документа в веб-браузере, требуется больше, чем просто подключить пиксель отслеживания и позволить алгоритмам творить свое волшебство. На самом деле это может привести к ощутимому конфликту между ИТ, маркетологами и клиентами.
Возьмем, к примеру, следующий сценарий: розничная компания тестирует главный баннер своей главной страницы, используя устаревший инструмент A/B-тестирования, экспериментируя с вариациями изображений и текста. Затем они решают запустить кампанию в своем новом инструменте персонализации, чтобы динамически обновлять тот же самый текст главного баннера на главной странице, добавляя текст, специально предназначенный для посетителей, привлеченных из платной медиа-кампании.
Сайт начинает вести себя странно. Некоторые из платных медиа-посетителей видят текст из кампании персонализации поверх изображения баннера, который является частью отдельного эксперимента A/B, создавая разрозненный опыт. Другие платные медиа-посетители видят только рендеринг A/B-тестирования без каких-либо персонализированных копий. Эксперименты пересекаются, и посетители видят разные комбинации контента, когда они попадают на главную страницу. Эта путаница еще больше расстраивает бизнес, поскольку показатели как для A/B-тестирования, так и для кампании персонализации теперь непонятны.
Какова основная причина? Отсутствие планирования использования конкурирующих технологий. С двумя разными инструментами, предназначенными для экспериментов с одними и теми же элементами сайта, неизбежно возникают конфликты с приоритетом и временем загрузки. Прежде чем заняться веб-персонализацией, крайне важно, чтобы ваша маркетинговая команда сначала провела инвентаризацию своего стека MarTech, определила пересекающиеся возможности и решила, какие инструменты будут предоставлять конкретные функции. Программное обеспечение для веб-персонализации может легко конфликтовать с продуктами A/B-тестирования, рабочими процессами электронного маркетинга и другими важными маркетинговыми функциями. При планировании новой реализации маркетологи должны согласовать свои цели тестирования и работать над тем, чтобы усилия по персонализации не мешали работе с клиентами и не расстраивали внутренних заинтересованных сторон.
Проведите инвентаризацию своих доменов
Независимо от того, включает ли процесс установки клиентскую или серверную реализацию, инструменты веб-персонализации обычно требуют владения веб-сайтами, на которых они работают. Это означает, что только разработчики и маркетологи, у которых есть некоторый уровень расширенных разрешений для данного веб-сайта, будут иметь возможность запускать там программное обеспечение для персонализации — либо завершая реализацию путем встроенной установки в кодовую базу, либо с помощью таких инструментов, как менеджеры тегов.
Это может показаться интуитивно понятным, но ограничения становятся более очевидными при рассмотрении сложных вариантов использования, охватывающих неаутентифицированные и аутентифицированные приложения. ИТ-отдел организации может иметь полный контроль над неаутентифицированным маркетинговым сайтом, но их опыт входа в систему может находиться в сторонней службе, которая отвечает за обслуживание аутентифицированного клиентского портала. В этом сценарии третья сторона может иметь ограничения на индивидуальную интеграцию и установку программного обеспечения, что потенциально ограничивает возможности персонализации.
Все инструменты персонализации по-разному относятся к междоменному отслеживанию. Даже если приложение организации на стороннем сервисе позволяет установить решение для персонализации, возможности программного обеспечения по отслеживанию посетителей в разных доменах могут быть ограничены. Использует ли инструмент персонализации сторонние файлы cookie? Требует ли разрешение идентификации пользователей для самоаутентификации в доменах с помощью согласованного уникального идентификатора? Встроено ли управление идентификацией непосредственно в инструмент персонализации или оно является отдельной службой?
Когда вы оцениваете возможности междоменного отслеживания инструмента, вы должны учитывать веб-ресурсы, на которых ваши кампании по персонализации будут наиболее эффективными, и требуют ли они точного междоменного отслеживания для успеха. Кроме того, вы можете использовать итеративный подход, который начинается с таргетинга на анонимных пользователей сайта на основе их поведения при посещении и постепенного перехода к персонализации для известных клиентов в разных доменах по мере устранения зависимостей.
Сделайте свои веб-страницы доступными для разработчиков персонализации
Экосистема интерфейсных веб-технологий обширна и граничит с пугающей. Нет недостатка в решениях для создания одностраничных приложений, написания масштабируемого CSS и объединения кода для производственных сред. Как бы ваша команда ни решала эти проблемы, есть одна простая вещь, которую интерфейсный веб-разработчик может сделать для поддержки персонализации в ваших приложениях: написать семантические классы и идентификаторы вручную в HTML-коде на стороне клиента.
Это не означает, что разработчики не должны использовать библиотеки CSS-in-JS и сборщики, такие как Webpack, которые часто создают HTML, полный машинно-генерируемых имен классов. Эти инструменты служат четкой цели, но ненадежные селекторы, которые они производят, могут навредить усилиям по персонализации. Программное обеспечение для персонализации может полагаться на согласованные селекторы CSS для выбора элемента для варианта использования в Интернете. Селекторы также могут быть необходимы для подключения прослушивателей событий, которые отслеживают кнопки и формы. Если каждая новая сборка веб-сайта или приложения повторно создает эти селекторы, персонализация сломается. Front-end разработчики должны помнить об этом и использовать в своем HTML-коде жестко запрограммированные, понятные человеку имена классов, особенно когда другие библиотеки и инструменты также генерируют свои собственные классы.
Кроме того, инструменты персонализации, которые полагаются на клиентский JavaScript для отслеживания взаимодействия пользователей в Интернете, в значительной степени будут ограничены отслеживанием только тех элементов, которые изначально существуют на странице. Стандартное использование кода JavaScript на стороне клиента предотвратит отслеживание в iframe, то есть в видео YouTube и встроенных формах. Если какие-либо KPI привязаны к взаимодействиям с определенными элементами страницы, эти элементы должны быть встроены непосредственно в веб-страницу, а не в iframe, чтобы обеспечить надежные возможности отслеживания.
Заключение
Да, ML и AI будут становиться все более важными для персонализации, поскольку технологии продолжают развиваться. Тем не менее, вы не можете написать «персонализация» без «личности», и это остается особенно верным, когда дело доходит до реализации. Хотя машины могут выполнять сложные расчеты и модели принятия решений, ничто не заменит реальных людей, которые думают и работают за кулисами, чтобы эти инструменты могли добиться успеха при тщательном планировании и обдуманном техническом выборе.
Slalom – это глобальная консалтинговая компания, которая помогает людям и организациям мечтать о большем, двигаться быстрее и строить лучшее будущее для всех. Узнайте больше и свяжитесь с нами сегодня.