Оглавление

Введение

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

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

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

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

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

Заключение

Введение

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

Обычна ситуация, когда при внедрении SAP CRM функции мониторинга ограничивается записью логов в SLG1. Понимание, что этого недостаточно обычно приходит только после инцидентов.

Последние 2 года работаю in-house в «Лига Ставок», в основном, занимаюсь настройкой механик и запуском маркетинговых кампаний, вследствие чего накопился большой опыт по предотвращению инцидентов, мониторингу и тестированию маркетинговых кампаний.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Указание проверки на дубли.

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

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

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

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

Например:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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