На этой странице
Развертывания Salesforce B2C Commerce (SFCC) редко терпят неудачу, потому что виджет не работает — они терпят неудачу, потому что никто не владеет путем от staging к production, и запрос на изменение лежит в изолированной среде шесть недель. Добавление рекомендации размера на витрину предприятия — это не проблема JavaScript, а проблема управления версионированием. Правильно установите управление, и техническая интеграция — это легкая часть.
Большинство брендов моды, работающих на Salesforce Commerce Cloud (ранее Demandware), имеют многоуровневую среду: разработка, staging и production, часто с отдельной sandbox для UAT для команд мерчендайзинга. Виджет рекомендации размера должен работать на всех уровнях, не нарушая зависимости картриджа, наследование шаблонов ISML или CSP-заголовки, которые SFCC применяет по умолчанию. Эта статья рассматривает два пути интеграции, контрольный список QA, который фактически используют команды предприятия, и кто должен одобрить перед тем, как код коснется production.
Картридж vs Встраивание: Два Законных Пути
SFCC предоставляет вам два реалистичных варианта для добавления виджета размеров третьей стороны, и правильный выбор зависит больше от цикла выпуска вашей команды, чем от самой технологии.
Пользовательский картридж — это «встроенный» способ SFCC: упакованный модуль, развертываемый через Business Manager, ссылающийся на контроллеры и шаблоны ISML, которые находятся в пути картриджа вашей витрины. Это дает вам более тесный контроль над поведением кэширования, данными на стороне сервера (SKU, таблица размеров, инвентарь), передаваемыми в виджет, и согласованностью с существующими моделями расширений. Компромисс — трение при развертывании — каждое изменение поведения или конфигурации виджета потенциально требует развертывания кода через ваш pipeline CI/CD и календарь выпусков.
Встраивание на стороне клиента — тег скрипта плюс точка монтирования в шаблон страницы с деталями товара (PDP) — это быстрее развертывать и легче повторять, потому что обновления виджета отправляются со стороны YourSizer без касания вашей кодовой базы SFCC. Компромисс — меньший контроль над данными, отображаемыми на стороне сервера, и зависимость от вашей конфигурации CSP и Page Designer, позволяющей использовать внешние скрипты и источники iframe.
| Фактор | Картридж | Встраивание |
|---|---|---|
| Время до первого развертывания | Недели (разработка → QA → конвейер выпуска) | Дни |
| Кто может выполнять итерации | Команда разработки SFCC | Маркетинг/мерчендайзинг, с одобрением разработки на CSP |
| Контроль данных на стороне сервера | Высокий | Ограничено тем, что раскрывается на стороне клиента |
| Частота обновления | Привязана к календарю выпусков | Независима от выпусков SFCC |
Большинство команд предприятия начинают со встраивания на подмножество шаблонов PDP для проверки влияния, затем мигрируют на картридж после доказательства бизнес-обоснованости — см. как построить внутреннее бизнес-обоснование для технологии примерки, чтобы узнать, как структурировать эту фазу доказательства.
Политика безопасности контента и ловушка CSP
Конфигурация CSP по умолчанию в SFCC более строгая, чем большинство продавцов понимают, пока виджет не перестанет молча отображаться. Если источник вашего скрипта или iframe не внесен явно в белый список в настройках CSP Business Manager (Merchant Tools > SEO > CSP или более новую конфигурацию безопасности Page Designer в зависимости от вашей версии SFCC), консоль браузера будет показывать ошибку заблокированного ресурса, в то время как сама PDP отображается нормально — это означает, что QA может легко это пропустить, если не проверяет devtools.
Перед любым развертыванием подтвердите три момента с администратором SFCC: директива script-src включает домен размещения виджета, директива frame-src или child-src разрешает источник iframe, если вы используете встраивание на основе iframe, и connect-src разрешает вызовы API, которые виджет делает для рекомендаций размеров. Это пятиминутная проверка, которая предотвращает откат в день запуска.
Дисциплина Staging: Что Тестировать Перед Запуском
Виджет размера касается PDP, которая является шаблоном с наибольшим трафиком и наибольшим доходом на сайте — рассматривайте развертывание с той же строгостью, как изменение оформления заказа, а не как добавление значка или баннера.
Контрольный список staging, который обычно запускают команды SFCC предприятия, включает:
- Отображение локали и валюты на всех витринах, которые касается виджет, поскольку многосайтовые установки SFCC часто обслуживают более пяти локалей из одной кодовой базы.
- Точность таблицы размеров по типу товара — виджет, который уверенно рекомендует, но читает неправильную таблицу размеров для категории, хуже, чем вообще нет виджета.
- Макет PDP для мобильных устройств, поскольку эталонная архитектура SFRA отображает компоненты PDP по-разному на разных контрольных точках, и неправильно ограниченное встраивание может сместить контент ниже линии сгиба.
- Влияние на скорость загрузки страницы, измеренное с помощью того же инструмента Core Web Vitals, который уже использует ваша команда SEO, потому что медленно загружаемый виджет может компенсировать рост конверсии, который он должен обеспечить — см. как Virtual Try-On увеличивает коэффициент конверсии для компромиссов между более богатыми виджетами и временем загрузки.
- Поведение при откате, когда API виджета истекает или товар не имеет сопоставления таблицы размеров, чтобы PDP корректно деградировала вместо отображения сломанного состояния.
Запустите это на инстансе staging с симуляцией трафика, подобного production, если ваша команда имеет такую возможность, а не только ручной клик — команды мерчендайзинга предприятия часто ловят ошибки локали только под реальной одновременной нагрузкой.
Управление: Кто Одобряет и Когда
Техническое развертывание — это самая короткая часть проекта виджета размера SFCC; цепь одобрения обычно является длинным полюсом. Типичная последовательность одобрения предприятия включает команду платформы электронной коммерции (CSP, производительность, проверка картриджа), команду мерчендайзинга или UX (точность сопоставления таблицы размеров, охват категорий), юридический отдел или конфиденциальность (если собираются какие-либо данные измерения тела, чего не должно быть для потока рекомендации размера на основе одежды) и менеджер выпуска, который вписывает развертывание в календарь выпусков SFCC.
Установите четкого владельца отката перед запуском — кого-то с доступом к Business Manager, кто может отключить картридж или удалить скрипт встраивания в течение нескольких минут, если что-то сломается. Возвраты и данные примерки — это нижестоящие сигналы, которые также важны для финансов; представление развертывания в терминах реальной стоимости возврата для брендов моды имеет тенденцию получать одобрение бюджета и юридических лиц быстрее, чем только UX питч.
Где YourSizer Вписывается
YourSizer поддерживает оба пути интеграции на Salesforce Commerce Cloud: легкое встраивание для команд, которые хотят проверить влияние на подмножество PDP в течение дней, и развертывание на основе картриджа для команд, которым нужен более тесный контроль над данными на стороне сервера и кэшированием после доказательства развертывания. Логика рекомендации размера работает независимо от цикла выпуска SFCC в любом случае, поэтому итерация по сопоставлению таблицы размеров или порогам рекомендации не требует развертывания кода через ваш конвейер выпуска. Для команд предприятия мы работаем непосредственно с заинтересованными сторонами платформы и мерчендайзинга во время staging для подтверждения конфигурации CSP, охвата локалей и поведения при откате перед тем, как что-либо попадет на production — тот же контрольный список, описанный выше, запускаемый совместно, а не передаваемый.
Часто задаваемые вопросы
Требует ли виджет рекомендации размера полный картридж SFCC или может работать как встраивание скрипта?
Оба работают, и правильный выбор зависит от того, сколько контроля на стороне сервера вам нужно и как быстро ваша команда хочет выполнять итерации. Встраивание быстрее запускается и легче обновляется независимо от вашего календаря выпусков SFCC, в то время как картридж дает вам больше контроля над данными, отображаемыми на стороне сервера, и подходит для команд, которые уже управляют большинством расширений через развертывания Business Manager. Многие команды начинают со встраивания для доказательства влияния, затем переходят на картридж после проверки бизнес-обоснованности.
Сколько времени обычно занимает развертывание виджета размера SFCC с начала до production?
Для встраивания на основе встраивания, проверенного на подмножестве PDP, команды часто достигают production в течение двух-четырех недель, большая часть которых — это конфигурация CSP, тестирование staging QA и одобрение заинтересованных сторон, а не фактическое кодирование. Развертывание на основе картриджа обычно занимает больше времени, потому что оно должно вписаться в ваш существующий конвейер выпусков SFCC, который может работать по ежемесячному или ежеквартальному графику в зависимости от процесса управления изменениями вашей организации.
Что происходит, если виджет не загружается на активной странице товара?
Правильно сконфигурированное встраивание должно корректно деградировать, что означает, что PDP отображается нормально без виджета, а не ломает страницу или блокирует добавление в корзину. Это один из проверок staging, который стоит преднамеренно протестировать — смоделируйте истечение времени API или отсутствие сопоставления таблицы размеров перед запуском, а не после, поскольку режим отказа становится видимым только в условиях, которые QA не всегда воспроизводит по умолчанию.
Нам нужно юридическое или конфиденциальное одобрение для добавления виджета рекомендации размера?
Рекомендация размера на основе одежды, которая полагается на данные товара и таблицы размеров, а не на сканирование тела или сохраненные биометрические измерения, обычно поднимает гораздо меньше вопросов о конфиденциальности, чем Virtual Try-On на основе камеры. Тем не менее, большинство процессов управления предприятия требуют проверки конфиденциальности как стандартного этапа для любого скрипта третьей стороны, добавленного на PDP, поэтому стоит вовлечь юридический отдел рано, а не рассматривать это как чисто инженерное решение — см. конфиденциальность данных тела в примерке: что ожидают покупатели для более широкого контекста о том, что на самом деле проверяют покупатели и регуляторы.
Заключение
Техническое различие между картриджем и встраиванием на Salesforce Commerce Cloud хорошо понимается; сложная часть — построить процесс развертывания, который выдерживает ваш фактический календарь выпусков, политику CSP и цепь одобрения организации без застревания на месяцы. Команды, которые рассматривают изменение PDP с требуемой строгостью оформления заказа — четкое владение откатом, дисциплина staging по локалям и согласованный путь управления перед началом — имеют тенденцию выпускаться неделями, а не кварталами, и эта дисциплина окупается в следующий раз, когда функция, связанная с примеркой, должна работать на той же платформе.