Пользовательские условия WooCommerce для разработчиков

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

#10003; GT BOGO Engine PRO включает 30-дневную гарантию возврата денег.

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

Почему пользовательские правила важны для архитектуры

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

Исследование McKinsey по анализу цен и рекламных акций последовательно выявляет, что ритейлеры недооценивают ценность скоординированной рекламной аналитики. Та же недооценка влияет на то, как разработчики WooCommerce подходят к расширяемости правил — предположение, что «плагин обрабатывает стандартные случаи» скрывает реальность того, что производственные магазины обычно нуждаются в условной логике, которая выходит за рамки стандартных случаев. Архитектурная гибкость для пользовательских условий является основой, которая определяет, может ли разработчик расширяться чисто или должен бороться с плагином для удовлетворения требований клиентов.

Данные об отказе от корзины из Baymard Institute, основанные на 50 отдельных исследованиях отказа от корзины, ставят средний мировой показатель в 70,22%. Условия пользовательского правила имеют значение для отказа от корзины, потому что неправильные условия могут привести к отказу от корзины, когда клиент ожидал скидку, которая не применялась. Клиент B2B, который ожидал оптовую скидку, но не получил ее, потому что механизм правил не проверял свое оптовое соглашение, отказывается от корзины. Абонент, который ожидал только сделку с абонентом, но не видел ее, потому что механизм правил не понимал отказ от состояния подписки. Логика условий влияет на реальные результаты конверсии.

Как выглядят современные архитектуры пользовательских правил WooCommerce

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

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

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

Что GT BOGO Engine предоставляет для пользовательских условий

GT BOGO Engine - первая в мире система автоматизации корпоративного класса Buy X Get Y, построенная специально для WooCommerce. Платформа включает в себя 48 суперспособностей, работающих внутри WooCommerce автоматически, плюс 200 предварительно построенных пакетов кампаний в 19 отраслях, а также чистую поверхность расширения для пользовательских условий правил через документированные крючки и фильтры. Разработчики могут расширить механизм правил, не разветвляя плагин или встроенные элементы. Для использования, ориентированного на разработчиков, в частности, четыре возможности имеют значение для операционной реальности построения пользовательской логики правил на платформе.

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

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

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

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

Как разработчики реализуют пользовательские правила на практике

Паттерн реализации для пользовательского условия правила следует стандартному рабочему процессу разработки WordPress. Разработчик создает пользовательский плагин или добавляет код к клиентскому плагину MU, регистрирует пользовательское условие через документированный крюк фильтра, реализует логику состояния в качестве вызова, который возвращает булеву, и тестирует логику состояния против ожидаемых сценариев корзины и клиента. Пользовательский плагин живет отдельно от GT BOGO Engine, что означает, что обновления плагина не влияют на пользовательскую логику.

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

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

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

Сравнение: Стандартные двигатели правил против расширяемых двигателей правил

| Способность | Механизмы стандартных правил | Расширяемые механизмы правил (GT BOGO Engine) | |----------- | Встроенные условия | Ограниченные примитивы | Всеобъемлющие примитивы | Вилки или фиксация обезьян | Документированные крючки для фильтров | Документированные крючки для фильтров | Документированные крючки для фильтров | Документированные крючки для фильтров | Документированные крючки для фильтров | Документированные крючки для фильтров | Документированные крючки для фильтров | Документированные крючки для фильтров | Документированные крючки для фильтров | Документированные крючки для фильтров | Документированные крючки для фильтров | Документированные крючки для фильтров | Документированные крючки для фильтров | Документированные крючки для фильтров | Документированные крючки для фильтров | Документированные крючки для фильтров | Документированные крючки для фильтров | Сохраняемые пользовательские работы | Обычная работа | Обы

Примеры условий реального мирового пользовательского правила

Клиенту B2B-дистрибуции нужна промо-логика, зависящая от порогов объема, специфичных для учетной записи клиента. Разработчик реализует пользовательское условие, которое запрашивает уровень учетной записи клиента из мета-уровня пользователя и расчета объема, специфичного для уровня корзины. Условие возвращается истинным, когда объем корзины соответствует порогу уровня учетной записи клиента, что означает, что клиенты уровня A видят разные пороги объема, чем клиенты уровня B. Пользовательское условие составляет примерно 25 строк кода, живет в плагине для конкретного клиента и протестировано на единицу против репрезентативных сценариев корзины и клиента.

Клиенту, основанному на подписке, нужна промо-логика, которая исключает продукты подписки из широких скидок при применении специальных предложений к клиентам подписки на дополнительных продуктах. Разработчик реализует пользовательские условия, которые проверяют как содержимое корзины (исключая продукты подписки из расчета скидки), так и состояние клиента (идентифицируя активных подписчиков для специальных предложений). Условия интегрируются с возможностью обнаружения подписки платформы и добавляют логику, специфичную для клиента, которую платформа не предоставляет из коробки. Для получения дополнительной информации об обработке подписки см. Сделки WooCommerce подписки BOGO.

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

Миграционный путь к существующей логике таможенных правил

Миграция неразрушительна, поскольку GT BOGO Engine сосуществует с существующими промо-плагинами без конфликтов. Разработчики могут устанавливать GT BOGO Engine вместе с текущей промо-системой, постепенно портировать логику пользовательских правил в новую архитектуру и проверять поведение перед выходом на пенсию устаревшей системы. Это решает стандартную озабоченность разработчика по поводу риска сбоев во время переходов платформы.

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

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

Структура цен и лицензий для использования разработчиками

GT BOGO Engine PRO составляет 499 долларов в год на один магазин клиентов без уровней ценообразования на каждую функцию. Нет никакой платы за возможность расширения правил, API для анализа клиентов, API контекста корзины, тестовые утилиты или любую из функций платформы, ориентированных на разработчиков. Индивидуальные отраслевые PRO-пакеты стоят 79,99 долларов каждый. Три уровня пакетов предлагают экономию для клиентов с несколькими отраслями: Starter Bundle (299 долларов за 5 пакетов, экономия 100,95 долларов), Growth Bundle (299 долларов за 9 пакетов, экономия 220,91 долларов) и Complete Arsenal (799 долларов за 15 пакетов, экономия 400,85 долларов).

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

Часто задаваемые вопросы от разработчиков WooCommerce

Что такое задокументированный фильтр-хук для регистрации пользовательских условий?

Платформа выставляет фильтр-хуки для регистрации условий, которые следуют стандартным моделям WordPress. Точные имена и подписи крючков документированы в руководстве для разработчиков. Модель следует соглашению WordPress названных фильтр-хуков, против которых пользовательские плагины регистрируют вызывающие вызовы, с платформой, вызывающей зарегистрированные крючки во время расчета корзины. Документированные крюки остаются стабильными в версиях плагинов, с обратно совместимым поведением, сохраненным при развитии крючков. Для получения дополнительной информации об архитектуре разработчика см. руководство для разработчиков GT BOGO Engine.

Как платформа справляется с конфликтами между пользовательскими условиями и встроенными условиями?

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

Могут ли пользовательские условия получить доступ к данным плагинов третьих сторон?

Да. Пользовательские условия выполняются в стандартном контексте запроса WordPress, что означает, что они могут получить доступ к любым данным, доступным через стандартные API WordPress и WooCommerce. Данные подписки WooCommerce, пользовательские метаданные пользователя, сторонние данные плагина и внешние вызовы API доступны из пользовательских условий. Разработчики должны помнить о последствиях производительности, когда пользовательские условия делают внешние вызовы API, поскольку условия выполняются во время расчета корзины.

Как платформа обрабатывает обратную совместимость для пользовательских условий?

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

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

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

GT BOGO Engine построен GRAPHIC T-SHIRTS, настоящим магазином WooCommerce с более чем 1200 оригинальными проектами, работающими в масштабе. Посетите gtbogoengine.com, чтобы загрузить бесплатный плагин ядра, оценить архитектуру расширения правил и API, ориентированные на разработчиков, и решить, оправдывает ли расширяемость платформы миграцию на вашей временной шкале. Для более широкого контекста см.