Безопасность и мониторинг кампаний в SAP CRM

Ссылка на статью в формате PDF

Оглавление

  1. Введение.
  2. Создание МК. Пошаговая инструкция.
  3. Тестовый запуск.
  4. Боевой запуск. Проверки.
  5. Операционный Мониторинг.
  6. Устранение инцидентов.
  7. Заключение.

Введение

При работе с маркетинговыми кампаниями (далее МК) цена ошибки очень высока, а допустить ошибку можно довольно легко, например, разослать некорректное предложение или ошибочно начислить баллы. Думаю, многие сталкивались с EMAIL\PUSH\SMS-сообщениями, где начислялось 0 баллов или просто писали test.  Подобные ошибки приводят к репутационным и финансовым потерям для компании.

Обычна ситуация, когда при внедрении SAP CRM функции мониторинга ограничивается записью логов в SLG1 и разными ad hoc решениями. Понимание, что этого недостаточно обычно приходит только после инцидентов. Работая в консалтинге я не обращал на это большого внимания, однако работа in-house надежность вышла на первое место по приоритетам (новые фичи идут следующим пунктом)

Данный материал может быть полезен читателям, работающим не только в SAP CRM Marketing, но в более новых продуктах, таких как SAP Marketing и в других маркетинговых продуктах. Написан он с минимумом специфической технической терминологии.

Отдельно хочется поблагодарить Дмитрия Новикова, чьим abap-мастерством удалось реализовать данную систему и Светлану Пасько за организацию работы, которая позволила выработать данное решение, а также Петра Цветникова и Анастасию Чищанову за использование и ценные замечания по усовершенствование архитектуры.

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

В результате анализа опыта по настройке сложной механики МК, а также передаче функционала в эксплуатацию бизнесу пришли к следующей схеме работы с МК (Рис.1):

Рис.1. Схеме работы с МК

Рис.1. Схеме работы с МК

1. Создание МК. Пошаговая инструкция

Т.к. при создании маркетинговой кампании велик риск человеческой ошибки, то при создании МК сделали максимальное кол-во проверок для уменьшения вероятности ошибки по невнимательности.

Создание формуляра сообщения.

При создании формуляра указывается, для какого типа клиентов данный формуляр актуален, например, только для VIP-клиентов. Указывается, для какого типа сообщений используется данный формуляр SMS\PUSH\EMAIL, также есть возможность указания, что формуляр закрыт для использования.

При указании на элементе формуляра проверяется, что тип клиентов на формуляре соответствует типу на МК, что провайдер для отправки сообщений на элементе МК соответствует указанному на формуляре (SMS\PUSH\EMAIL) и формуляр не закрыт.

Указание максимального кол-ва клиентов.

На элементе обязательно указывается максимальное кол-во клиентов, планируемое для запуска.

Указание задания по сегментации данной МК.

Если МК планируется как периодическая, то нужно указать задание, которое отвечает за генерацию целевых групп. Подробности см. в разделе 4.Мониториг.

Указание типа клиентов, которые участвуют в данной МК.

На МК обязательно указывается для какого типа клиентов работает данная МК. Например, только для VIP-клиентов. Данный тип должен соответствовать типу на шаблоне и типу клиентов в целевой группе ( далее ЦГ).

Проверка на дубли.

Если есть понимание, что клиент не может попасть в МК несколько дней подряд. Например, у клиента не может быть 2 дня рождения подряд. То можно указать здесь проверку на дубли.

Проверка на дату запуска

Если дата и время запуска меньше текущей, то при попытке сохранения элемента система выдаст ошибку.

В интерфейс кампании добавили кнопку “Проверить”, пользователь перед запуском кампании нажимает её и сразу получает результат по проверкам, которые можно получить без запуска МК. Например, если превышено кол-во клиентов в ЦГ или не отработало указанное задание по сегментации, то ошибка отобразится сразу (Рис.2), что даст возможность пользователю исправить параметры МК. Дополнительно данная кнопка также запускает ренамберинг моделей сегментации, указанных в МК.

Например:

Рис 2 Экран обнаружения ошибки

Рис 2 Экран обнаружения ошибки

 

2. Тестовый запуск

Обычно этап проверки заключается в том, что:

  1. На тестовом ландшафте создаются клиенты, на которых должна отработать механика (так же со случаями, когда не должна).
  2. Если на тестовом ландшафте есть клиентская база, то кампания запускается и по ней.
  3. Производится запуск на продуктивном ландшафте на контрольной ЦГ.

При этом возникают следующие проблемы:

  1. На составление возможных успешных и неуспешных сценариев уходит много времени, причем это не гарантирует, что будут покрыты все возможные сценарии. При этом обычно МК нужно запускать как можно быстрее т.к. они уже в планах бизнеса, то времени на полноценное тестирование недостаточно.
  2. Не все возможные сценарии можно проверить, возможно, в данную выборку не попадут клиенты с данными, на которых сценарий сломается. К тому же практически нигде не бывает актуальных клиентских данных на тестовом ландшафте.
  3. При запуске на продуктивном ландшафте на контрольной ЦГ возникают аналогичные проблемы рассмотренные выше.
  4. Сложно заранее протестировать событийные кампании, которые отрабатывают в режиме онлайн.

Поэтому было принято следующее решение:

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

Получился отдельный тестовый контур внутри продуктива, идеологически наверно не совсем корректный, однако практичный и надежный.

Данная архитектура хорошо помогает также в тестировании событийных кампаний, когда можно запустить кампанию по определенной ЦГ и в онлайн-режиме проверять корректность начисления тестовых данных в течении необходимого времени.

Также при тестовом запуске запускаются все проверки, как и при боевом запуске, поэтому все ошибки по сообщениям\начислению и т.д. будут сразу доступны для анализа на данном этапе.

3. Боевой запуск. Проверки.

Проверка на максимальное кол-во клиентов на элементе.

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

При планировании и запуске кампании пользователи всегда имеют представление о примерном кол-ве клиентов, которые попадут в данную кампанию, поэтому они могут указать на элементе верхний предел, превышение которого свидетельствует об ошибке.

Данный параметр обязателен и пользователь не сможет сохранить элемент МК, если не укажет его. Проверка осуществляется в момент запуска элемента, рассчитывается общее кол-во клиентов по всем ЦГ в элементе МК, и при превышении производится запись в таблицу ошибок об отмене запуска элемента МК.

Проверка на корректную генерацию модели сегментации.

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

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

Проверка на 3-сигма.

Т.к. в проверке на максимальное кол-во клиентов пользователь вводит значение вручную, то есть вероятность ошибиться. Данная проверка идет как дополнительная проверка к максимальному кол-ву.

Проверка работает автоматически и не требует от пользователя каких-либо действий, работает только для периодических МК.

При запуске элемента МК проверяются последние N запусков и смотрится на кол-во клиентов, после чего рассчитываются показатели для формулы по 3-сигмы (т.е. вероятность того, что любая случайная величина отклонится от своего среднего значения больше чем на 3-сигмы очень мала).

В случае, если кол-во клиентов на элементе больше чем предполагаемое в 3-сигмах, то производится запись в таблицу ошибок об отмене запуска элемента МК.

Данная проверка некорректно работает на маленьких кол-вах клиентов, например, если у вас в среднем попадает 10 клиентов, а в один день попало 20, то это обычно означает ложное срабатывание. Поэтому используется специальный параметр в TVARV, который указывает, при каком кол-ве клиентов в ЦГ необходимо осуществлять данную проверку. В нашем случае эмпирическим путем было найдено кол-во порядка 10.000.

Проверка на корректный тип клиента.

Пользователь при запуске кампании указывает тип клиента, например, данная МК только для VIP-клиентов.

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

Проверка на наличие пустых атрибутов в формулярах сообщений.

При формировании сообщения email\sms\push проверяется, что атрибут не равен пусто или 0. Например, невозможна отправка сообщения, что клиенту начислено 0 бонусов.

Если какая-то проверка на атрибут не прошла, то данное сообщение помечается как ошибочное и не отправляется клиенту. Данная ошибка отображается в часовом мониторинге.

Запрет множественного запуска

При работе столкнулись с проблемой, что если указать время запуска в прошлом и запустить МК, то она будет отрабатывать каждые n минут (зависит от настройки соответствующего JOB), поэтому при запуске МК проверяем, что если период кампании день, то за сегодня не должно быть запуска МК.  В противном случае, производится запись в таблицу ошибок об отмене запуска МК.

Проверка на максимальное кол-во начисляемых бонусов

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

4. Операционный Мониторинг

Каждый час команде поддержки SAP приходит email с отчетом о состоянии системы, возникших ошибках, запусках МК и т.д. Ниже приведено общее описание такого отчета.

Проверки на ошибки ZERR_LOG

Все ошибки по запуску МК или работе программа записываются в таблицу ZERR_LOG. Формат этой таблицы:

  • Код
  • Подкод
  • Описание
  • Таймстемп

Например: Код 121 Подкод 2 Для клиента %номер клиента% в МК %ид. кампании% пустой атрибут.

В мониторинге выводятся все новые ошибки за последний час.

Функциональные проверки

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

Например, у клиента не может быть двух промокодов с одним типом или в настройках TVARV некорректно заполнен один из параметров настройки, или у клиента нет приветственного бонуса и т.д.

Проверка на дампы (ST22)

Проверяется наличие новых дампов в системе, если есть, то в отчете приходит сообщение со списком дампов.

Проверка на отмененные задания (SM37)

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

Проверка на размер очередей (SMQ1\2)

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

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

Проверка интеграции

Сделана отдельная настройка, в которой указаны таблицы и время мониторинга по каждой из них в минутах. Например, but000 – 10 минут, это значит. что в момент запуска мониторинга в данной таблице должна быть хоть одна новая или обновленная запись за последние 10 минут. Если новых или обновленных данных нет, это в отчете отображается как ошибка в интеграции.

Проверка на дубли в МК

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

 

Проверка на запущенные МК

Отображается список МК запущенных за последний час.

Проверка на наличие в МК не деблокированных элементов

 Обычно МК выглядит следующим образом (Рис.3):

Рис 3 Структура МК в графическом дизайнере.

Рис 3 Структура МК в графическом дизайнере.

 

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

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

5. Устранение инцидентов

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

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

6. Дальнейшее развитие

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

Для планирую ввести на каждую МК ряд дополнительных параметров для контроля и проверок такие как:

  • Минимальное и максимальное кол-во, отправляемых сообщений;
  • Минимальное и максимальное кол-во, начисляемых бонусов;
  • Проверка на максимальную сумма бонуса по МК

Скорее всего для этого необходимо делать отдельную настроечную таблицу.

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

Заключение

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

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

 

Концепт личной системы управления

Ссылка на статью в формате PDF

Ссылка на репозиторий в github

Ссылка статьи на habr.ru

Мотив:

Современное развитие технологий движется в сторону предсказания поведения человека, на основании отслеживания всего массива его активностей в виртуальной и физической реальности (big data).

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

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

Итак, что может сделать отдельный customer, чтобы усложнить задачу по формированию собственного предсказуемого поведения? Для меня ответ заключается в следующей фразе – чтобы научиться чем-то управлять необходимо научиться это измерять.

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

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

Итак, какими свойствами может обладать идеальный дневник:

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

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

Если интересна техническая реализация, то прошу пожаловать под кат

Continue Reading →

Схема таблиц для SAP CRM Loyalty.

Ссылка на схему в png.

Ссылка на документ в scn.sap.com

Задача:

Составить схему таблиц лояльности SAP CRM Loyalty Tables, для лучшего понимания архитектуры Loyalty в SAP CRM.

Схема была сделана мной где-то 4 года назад, но в целом не потеряла актуальности и на текущий момент.

Решение:

Loyalty tables SAP CRM

Loyalty tables SAP CRM

Continue Reading →

Отображение полного имени (ФИО) в SAP CRM.

Ссылка на статью в формате PDF

Задача:

Отобразить полное имя клиента (ФИО), сотрудника и т.д. в интерфейсе оператора КЦ. Т.е. необходимо, чтобы имя отображалось в виде:

Пример отображения полного имени в Web интерфейсе SAP CRM

Пример отображения полного имени в Web интерфейсе SAP CRM

Решение:

display_null_name

  1. Настройка правила отображения (rule name) имени в транзакции SA13
  2. Настройка указания правила для страны в транзакции OY07.
  3. На пользователе в SAP CRM (в транзакции SU01), необходимо указать страну, которая автоматически подставляется, когда данный пользователь создает клиента. Для этого необходимо добавить параметр NAMEFORMAT_COUNTRY со значением RU во вкладке “Параметры”
  4. После выполнения данных настроек видно, что при создании клиента автоматически (например, в транзакции BP) подставляется параметр “Страна для редактирования”, что решает проблему с отображением полного ФИО.
  5. Теперь полное имя клиента отображается в контактных лицах, создавший сотрудник, инфопанель оператора и т.д.

Примечание:

В случае, если клиенты были заведены ранее, с другим значением «Страна для редактирования», то после проведения настройки данные на клиентах не изменятся. Необходимо для данных клиентов проставить «Страна для редактирования» в нужное значение.

Публикация сайта с помощью Git.

Ссылка на статью в формате PDF

Задача

Необходимо выложить сайт (сделать деплойт) с локального компьютера (системы разработки) на сервер (web server) используя инструментарий GIT.

Это позволит достичь следующих целей:

  1. Упрощается выгрузка данных на сайт, не нужно копировать по ftp, забывая какие-то файлы, теперь для выгрузки достаточно выполнить команду push (если настроен хук см. ниже).
  2. Появляется возможность быстро откатить изменения на предыдущую версию.
  3. Можно быстро увидеть, не взломали ли ваш сайт, выполнив в директории с проектом, команду git status, которая покажет все несанкционированные изменения (конечно нужно исключить папки с кэшем и т.д.)

Решение

Деплойт сайта с помощью git

Деплойт сайта с помощью git

Continue Reading →