Налаштування ризик-правил
Побудуйте правила за пріоритетом і починайте в тестовому режимі, щоб не блокувати реальних покупців помилковою умовою.
Створення правила
- Дайте правилу однозначну назву.
- Встановіть пріоритет.
- Оберіть AND або OR.
- Додайте мінімально необхідні умови.
- Увімкніть тестовий режим.
- Перевірте маскований журнал і лише потім активуйте OTP.
Недоступний OTP
Для кожного сценарію визначте бізнес-рішення: дозволити оформлення без OTP або блокувати замовлення до відновлення каналу.
Усі поля, варіанти та перевірки
Нижче наведено повний профільний розділ офіційної інструкції модуля, без скорочень і маркетингового переказу.
Ризикові замовлення: OTP лише коли це потрібно
Функція Ризикові замовлення потрібна, якщо магазин не хоче змушувати кожного покупця вводити OTP. Вона залишає звичайне оформлення швидким для безпечних замовлень і вимагає підтвердження тільки тоді, коли спрацювало активне правило ризику.
Вкладка OTP -> Ризикові замовлення показується одразу після ввімкнення сценарію OTP -> Налаштування OTP -> Оформлення замовлення. Якщо цей сценарій вимкнути, вкладка ховається, а перевірка правил не виконується.
Логіка роботи:
Оформлення замовленняувімкнено, аПідтвердження ризикових замовленьвимкнено - OTP вимагається для кожного оформлення замовлення;- обидва перемикачі увімкнено, режим
Тестовий- правила перевіряються і пишуться в журнал, але оформлення замовлення не зупиняється через збіг; - обидва перемикачі увімкнено, режим
Робочий- OTP вимагається тільки коли збіглося перше активне правило; - жодне правило не збіглося - покупець продовжує оформлення без OTP;
- правило збіглося, але номер уже підтверджено для того самого оформлення замовлення і строк підтвердження не минув - повторний код не потрібен.
Безпечне ввімкнення
- Переконайтеся, що
OTP СтатусіОформлення замовленняувімкнені. - Відкрийте
OTP -> Ризикові замовлення. - Увімкніть перемикач у блоці
Підтвердження ризикових замовлень. - Залиште
Режим роботи = Тестовий - лише журнал. - Виберіть поведінку
Якщо OTP неможливо надіслати. - Задайте строк підтвердження оформлення замовлення.
- Виберіть статуси замовлень, які магазин вважає успішними.
- Створіть правила й натисніть
Зберегти. - Зробіть кілька тестових оформлень: одне має збігтися з правилом, інше - ні.
- Перевірте блок
Останні спрацювання. - Лише після перевірки журналу перемкніть режим на
Робочий - вимагати OTP.
Основні налаштування
| Поле | Що робить | Рекомендація |
|---|---|---|
Підтвердження ризикових замовлень | Вмикає вибірковий OTP під час оформлення замовлення. | Увімкніть після створення правил. Якщо вимкнено, сценарій оформлення працює як звичайний OTP для всіх замовлень. |
Режим роботи | Тестовий тільки записує збіги; Робочий реально вимагає OTP. | Починайте з тестового режиму щонайменше на кількох реальних або тестових замовленнях. |
Якщо OTP неможливо надіслати | Визначає, чи пропускати покупця при помилці провайдера. | На старті використовуйте точний варіант інтерфейсу Дозволити checkout і записати попередження. Блокування вмикайте тільки після стабільної перевірки основного й запасного каналів. |
Строк підтвердження checkout, хвилин | Скільки діє успішне підтвердження для поточного стану оформлення замовлення. | 15 хвилин — нормальне стартове значення. Дозволено від 1 до 120 хвилин. |
Статуси успішних замовлень | Визначає, які попередні замовлення враховувати в історії покупця. | Виберіть статуси, які у вашому магазині означають реальне прийняте, оплачене або виконане замовлення. Не додавайте скасовані й помилкові статуси. |
Як перевіряються правила
Кожне правило має назву, перемикач Активне правило, пріоритет, логіку умов і одну або кілька умов.
- Менше число в полі
Пріоритетперевіряється раніше. Наприклад,10має вищий пріоритет за20. Усі умови (AND)означає, що мають виконатися всі умови правила.Будь-яка умова (OR)означає, що достатньо хоча б однієї умови.- Після першого збігу перевірка зупиняється. Саме назва цього правила потрапляє в журнал.
- Неактивне правило не впливає на оформлення замовлення.
- Кнопка копіювання створює копію правила, а червона кнопка видаляє його. Окрема червона кнопка в рядку умови видаляє тільки цю умову.
Показники правил
| Показник | Доступні порівняння | Що означає значення |
|---|---|---|
Сума замовлення | Більше, Більше або дорівнює, Менше, Менше або дорівнює, Між значеннями | Поточна підсумкова сума оформлення замовлення. Для Між значеннями заповніть нижню і верхню межу. |
Спосіб оплати | Дорівнює, Не дорівнює | Обраний покупцем спосіб оплати. Список формується автоматично з установлених та увімкнених способів оплати магазину. |
Тип покупця | Дорівнює | Гість, Авторизований клієнт або Клієнт без успішних замовлень. |
Кількість успішних замовлень | Дорівнює, Більше, Більше або дорівнює, Менше, Менше або дорівнює | Кількість попередніх замовлень у статусах, вибраних у блоці Статуси успішних замовлень. Для гостя історія шукається за нормалізованим телефоном. |
Телефон підтверджено | Дорівнює | Чи був номер поточного оформлення замовлення успішно підтверджений OTP у чинній сесії. Значення: Так або Ні. |
Вік підтвердження телефона, днів | Більше, Більше або дорівнює | Скільки повних днів минуло від останнього успішного підтвердження цього номера. |
Замовлень із телефона за період | Більше або дорівнює | Скільки замовлень уже створено з тим самим нормалізованим номером за попередній період. Поле Період, хвилин приймає від 1 хвилини до 7 днів (10080 хвилин). |
Тип покупця читається так:
Гість- покупець не авторизований;Авторизований клієнт- покупець авторизований і має хоча б одне замовлення в обраних успішних статусах;Клієнт без успішних замовлень- покупець авторизований, але ще не має замовлень у цих статусах.
Список для показника Спосіб оплати не зашитий у модуль. Він автоматично читає встановлені платіжні розширення та їхні статуси. Для OpenCart/ocStore 2.3 перевіряються старі ключі налаштувань, а для 3.x — нові ключі payment_*, із сумісною перевіркою в обидва боки. Якщо спосіб оплати встановлено, але він не з'явився у правилі, спочатку переконайтеся, що його статус справді Увімкнено, а потім перезбережіть сторінку модуля.
Рекомендований стартовий набір
Пороги нижче - приклад, а не універсальна істина. Суми треба адаптувати до середнього чека й валюти магазину.
| Пріоритет | Назва | Умови |
|---|---|---|
10 | Часті повторні замовлення | Замовлень із телефона за період >= 2, період 60 хвилин. |
20 | Гість із підвищеною сумою | Сума замовлення >= 1500 AND Тип покупця = Гість. |
30 | Новий клієнт із великою сумою | Сума замовлення >= 2500 AND Тип покупця = Клієнт без успішних замовлень. |
40 | Велика сума для будь-якого покупця | Сума замовлення >= 5000. |
Тримайте правила від вузьких до загальних. Правило масових повторів має бути вище за правило великої суми, інакше журнал показуватиме тільки загальне правило, а причина ризику буде менш зрозумілою.
Останні спрацювання
Журнал показує дату, назву правила, замаскований телефон, статус рішення та ID створеного замовлення, якщо воно вже існує. Відкритий номер у журналі ризику не зберігається.
| Елемент | Що робить |
|---|---|
Усього записів | Показує реальну кількість записів журналу. |
Зберігати журнал, днів | Автоматично видаляє старі записи під час відкриття налаштувань модуля. Допустимо від 1 до 365 днів; 30 днів - нормальний старт. |
Очистити журнал | Видаляє весь журнал після підтвердження. Дію неможливо скасувати. |
Типові статуси журналу: правило збіглося в тестовому режимі, OTP потрібен, OTP підтверджено, оформлення замовлення дозволено або оформлення замовлення пропущено через політику доступності провайдера.
Активні правила кешуються між запитами, а дані оформлення замовлення обчислюються тільки коли вони реально потрібні конкретній умові. Наприклад, для гостя модуль не читає історію успішних замовлень лише заради визначення Тип покупця = Гість; але якщо правило прямо використовує Кількість успішних замовлень, потрібний запит виконується. Це зменшує навантаження без зміни результату правила.