Скрываем от конкурентов количество заказов в нашем магазине с помощью триггера RetailCRM

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

Чтобы усложнить данную задачу, до уровня практической невозможности вычисления (почему практической, напишу в объяснении), можно формировать номер заказа исходя из текущего timestamp. То есть каждую следующую секунду, номер заказа будет отличаться на +1 от предыдущего. В месяце от 2419200 до 2678400 секунд. Если все ваши заказы отражают каждую секунду, в которую мог быть сделан заказ, то определить сколько у вас в действительности было заказов, имея номер заказа, будет невозможно. Их мог быть как один в месяц, так и 2678400 за этот же месяц.

Проделать такую операцию можно триггером внутри RetailCRM и вместо номеров заказов 1234, 1235, 1236 получать 100-741-353, 100-746-007, 100-882-116, по которым вычислить, что у вас за это время произошло только три заказа, уже нельзя.

Название: Обфускация номера заказа

Символьный код: order_number-obfuscate

Событие: Изменение заказа

Условие:

// Определяем, что переделывать номер необходимо только во время создания заказа
changeSet.isCreate
// Установите здесь значения магазинов, для которых требуется переделывать номера заказов
and order.site.code in ['my-first-shop-code', 'my-second-shop-code']

Действие:

Изменить данные заказа > Номер заказа
Выражение:

((date("now").format("U") + order.id~((order.id)%(date("now").format("s")) + date("now").format("g") + 13) - 1570000000) matches '/^..........$/' ? ((date("now").format("U") + order.id~((order.id)%(date("now").format("s")) + date("now").format("g") + 13) - 1570000000) - ((date("now").format("U") + order.id~((order.id)%(date("now").format("s")) + date("now").format("g") + 13) - 1570000000)%100000000))/100000000)~
(((date("now").format("U") + order.id~((order.id)%(date("now").format("s")) + date("now").format("g") + 13) - 1570000000)%1000000000 - (date("now").format("U") + order.id~((order.id)%(date("now").format("s")) + date("now").format("g") + 13) - 1570000000)%1000000)/1000000)~
'-'~
(((date("now").format("U") + order.id~((order.id)%(date("now").format("s")) + date("now").format("g") + 13) - 1570000000)%1000000 - (date("now").format("U") + order.id~((order.id)%(date("now").format("s")) + date("now").format("g") + 13) - 1570000000)%1000)/1000 matches '/^.$/' ? '00')~
(((date("now").format("U") + order.id~((order.id)%(date("now").format("s")) + date("now").format("g") + 13) - 1570000000)%1000000 - (date("now").format("U") + order.id~((order.id)%(date("now").format("s")) + date("now").format("g") + 13) - 1570000000)%1000)/1000 matches '/^..$/' ? '0')~
(((date("now").format("U") + order.id~((order.id)%(date("now").format("s")) + date("now").format("g") + 13) - 1570000000)%1000000 - (date("now").format("U") + order.id~((order.id)%(date("now").format("s")) + date("now").format("g") + 13) - 1570000000)%1000)/1000)~
'-'~
((date("now").format("U") + order.id~((order.id)%(date("now").format("s")) + date("now").format("g") + 13) - 1570000000)%1000 matches '/^.$/' ? '00')~
((date("now").format("U") + order.id~((order.id)%(date("now").format("s")) + date("now").format("g") + 13) - 1570000000)%1000 matches '/^..$/' ? '0')~
((date("now").format("U") + order.id~((order.id)%(date("now").format("s")) + date("now").format("g") + 13) - 1570000000)%1000)

Особенности:

В условие необходимо будет вставить символьные коды ваших магазинов, номера заказов которых надо переделывать. Это необходимо для того, чтобы если вы работаете с интеграциями маркетплейсов, где прилетают свои номера заказов, чтобы они не изменялись. Так как архитектура RetailCRM на данный момент не поддерживает определение с какого id API-ключа пришел заказ, то достоверно вычислять это можно только если только привязывать каждую интеграцию к отдельному магазину. При необходимости работы с одним магазином можно потом изменять магазин заказа на требуемый, а псевдомагазины использовать исключительно для мониторинга того, с какого конкретно API-ключа в действительности пришел заказ.

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

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

Выражение позволит вам иметь всегда уникальные номера заказов, в ближайшие 25 лет они будут 9-значные, а затем превратятся в 10 значные в формате NNNN-NNN-NNN и смогут генерироваться уникальными еще 250 лет, что в рамках современного мира может трактоваться практически как навсегда.

Объяснение:

Timestamp — это количество секунд, прошедших с 1 января 1970 года. На текущий момент значение одной из секунд равняется 1670741353. С таким номером работать не очень удобно и поэтому мы его сокращаем, отнимая от значения 1570000000 и получаем 100741353, а затем дополнительно форматируем в вид 100-741-353. Такой номер заказа воспринимается уже гораздо лучше.

Однако могут происходить ситуации, которые на самом деле не редки, когда у вас в одну секунду пришло сразу два заказа, которые точно не должны быть оба 100-741-353. Значит нам необходимо сделать такое вычисление, которое при любых обстоятельствах будет делать номера заказов уникальными. Для этого нам необходимо некое уникальное цифровое значение, которое при осуществлении математического действия никогда не будет давать полностью аналогичный результат, например значение с автоинкрементом (это когда новое значение всегда на 1 больше предыдущего).

В нашей ситуации это id заказа в CRM системе. Поэтому складывая Timestamp + order.id у нас всегда будет получаться число, которое больше предыдущего на 1 секунду или на 1 id заказа. Но, так как теперь в вычислении снова присутствует номер заказа, он становится уязвимым к вычислению. Поэтому, для того чтобы усложнить задачу, нам необходимо добавить какое-то значение, вычисление которого будет неочевидно.

Посмотрим на базу из которой мы собираемся вычислить номер заказа и формулы, которые усложнят вычисление, так как формула известна только вам:

date("now").format("U")

Показывает текущий timestamp, возьмем за пример значение 1670741353

order.id

Текущий id заказа в системе, возьмем за пример значение 7515

Как выше написано, если использовать только id заказа, то он становится уязвимым, поэтому нам необходимо, чтобы с одной стороны у нас всегда присутствовал id заказа, с другой, чтобы наша эта цифра, всегда была больше чем эта же цифра от предыдущего заказа. Для этого присоединим к значению ещё два разряда, чтобы получить что-то типа 751533. Так как следующий id будет 7516, то в присоединенной цифре нам нужно некое арифметическое значение в диапазоне от 11 до 99. Разберем ниже как это может работать.

(order.id)%(date("now").format("s"))

Указанное выражение выведет остаток от деления номера заказа на текущую секунду. Так как timestamp 1670741353 соответствует секунде 13, то мы будем вычислять остаток от деления номера заказа 7515 на 13 и получим 1. В текущем примере, остаток от деления может быть от 0 до 59. То есть присоединение только данного значения не даст нам возможность всегда получать двухзначное число.

date("now").format("g")

Указанное значение выведет номер часа в 12-часовом формате. Значение может быть от 1 до 12.

(order.id)%(date("now").format("s")) + date("now").format("g")

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

(order.id)%(date("now").format("s")) + date("now").format("g") + 13

Мы прибавили 13 и такое выражение теперь дает диапазон значений от 14 до 85, а в нашем случае 1 + 12 + 13 = 26. На этом этапе, догадаться способом перебора об алгоритме формирования номера заказа становится уже очень сложно. 

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

Осталось соединить наш id заказа 7515 и полученную цифру 26, чтобы получилось 751526.

order.id~((order.id)%(date("now").format("s")) + date("now").format("g") + 13)

Это выражение даст необходимую нам цифру для вычисления 751526.

(date("now").format("U") + order.id~((order.id)%(date("now").format("s")) + date("now").format("g") + 13) - 1570000000)

Теперь возьмем всё это за базу для формирования номера заказа и 1670741353 + 751526 - 1570000000 = 101492879. Это и есть неформатированный номер заказа. Нам осталось его только отформатировать и привести к виду 101-492-879, что и делаем в итоговом варианте выражения, которое описано выше.

#триггер #хак

__________________________

❤️ Поблагодарить автора 💸

__________________________

✍️ Предложить тему публикации
__________________________

Настройка RetailCRM / Триггеры RetailCRM / Валидации RetailCRM / Примеры RetailCRM / Хаки RetailCRM / Секреты RetailCRM

Оригинальный пост https://t.me/retailcrm_tips/15

Подписывайте на канал RetailCRM Tips and Tricks

Список статей по настройке RetailCRM