AR Weekly репорт составляется каждую неделю к Analytics weekly synch по средам к 12:00. После представления репорта/презентации публике, его складываем в гугл драйв https://drive.google.com/drive/u/0/folders/1Sl5o4C1m8ERIsJ8Ue_1p12mEOzuXoZT8

О графиках и проверке АР

Основу репорта составляет динамика изменения поюзерного Approve Ratio (AR) в разрезе по брендам и странам. Таких графиков 6: все пользователи, первичка (before FTD - все транзакции до совершения первого успешного депозита пользователем, включительно) и вторичка (after FTD - все транзакции пользователя после совершения первого успешного депозита).

Основная идея этих графиков в отслеживании изменения АР со временем, на них видны как “недельные“ просадки, так и общее падение.

Следующими обязательными частями являются графики со сравнением АР на текущей неделе с прошлой. Их используем для детектирования конкретных просадок. Например, по скрину ниже нужно обратить внимание на вторичку Германии на Слото. Далее нужно определить есть ли вообще проблема и, если есть, попытаться найти причину, уведомить СС и контролировать её решение. Необходимо проверять каждый красный квадрат.

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

Если возникшее падение выглядит проблемным, то чтобы его проверить проще всего создать кастомную страницу AR reporta в режиме редактирования и там проверять основные поля. Главные поля, на которые нужно обращать внимание это:
1) BrandName - название бренда;
2) CasinoCountry - страна игрока;
3) Card_type - тип карты игрока: Виза/Мастер/Другая/Не карта;
4) before_ftd_status_user - тип депозита игрока, был ли он совершен до (включительно) или после ФТД;
5) CreatedAt - время попытки;
6) issuerInfoName (и модификации) - название банка (от СС);
7) bin_bank - название банка (по нашим данным);
8) psp_issuerCountry - страна карты (от СС);
9) bin_country_iso - страна карты (по нашим данным);
10) psp_issuerInfoNumber - бин карты (от СС);
11) bin_number - бин карты (по нашим данным);
12) initiatedPsp - провайдер, на котором транзакция инициировалась;
13) psp - провайдер, на котором транзакция закончилась;
14) Info - ошибка.

Числовые метрики:
1) calc_AR Total (user) - AR по юзерам (кол-во юзеров с хоть 1 успешной попыткой/Кол-во юзеров с любой попыткой);
2) calc_trans_count (user) - Кол-во юзеров с любой попыткой;
3) calc_success_trans_count (user) - Кол-во юзеров с успешной попыткой;
4) calc_AR Total (trans) - AR по транзакциям (кол-во успешных транзакций/Кол-во транзакций);
5) calc_success_trans_count (trans) - Кол-во успешных транзакций;
6) calc_trans_count (trans) - Кол-во транзакций.

Перетаскивая поля в разные положения мы можем находить проблемные места при просадках АР.

Детектирование проблем

Проблемы могут возникать со всеми вышеперечисленными разрезами/колонками. Самое главное это последовательно двигаться к конкретной причине. Она не всегда будет очевидной. Рассмотрим пример, который послужил причиной создания тикета на СС https://jira.softswiss.net/servicedesk/customer/portal/42/PAM-2101 .

Предположим мы столкнулись с такой ситуацией: -7% AR по сравнению с предыдущей неделей на вторичке Стея по Германии. Настраиваем фильтры в репорте по этим параметрам и начинаем применять разные разрезы.

Одним из основных разрезов является Card_type, строим график и замечаем странное выделяющиеся транзакции по Мастеркарду. В данном случае эти транзакции лишь частично являются причиной просадки с 89% до 82%, так как просадку фиксируем в неделю 3.03, а АР Мастеркарда упал еще 24.02. По графику видно, что в трёх из пяти недель АР находился недалеко от 82% и глобально проблемы нет. Но мы также видим явное падение АР и кол-ва пытающихся пользователей по Мастеркарду. Добавляем Мастеркард в фильтры и разбиваем график на поле issuerInfoName.

Перед нами становится виден нулевой АР по нескольким банкам пользователей. Да, на таком объеме нельзя со 100% уверенностью утверждать, что проблема присутствует, транзакций и пользователей действительно очень мало. Но у нас это продолжается 2 недели подряд, при этом ранее таких ситуаций не возникало. Дополнительно мы смотрим и на другие банки, например G24, на нём всё хорошо. Это тоже подчеркивает странность ситуации. На данном этапе мы видим возможную проблему, значит нужно подключать СС.

Создание тикета на СС

Тикет создается на отдельном портале поддержки СС (https://jira.softswiss.net/servicedesk/customer/portal/42 ). Доступ можно получить следуя вот этому гайду https://sgink.atlassian.net/wiki/spaces/ITOps/pages/1038712888 . В заявке указываем ссылку на сам портал поддержки и аргументируем выдачу тем, что нам нужен доступ для создания задач на СС с целью проверки падения АР на продукте.

Получив доступ и перейдя по первой ссылке попадаем в это меню. Тут нам подойдет Investigation, так как с вопросами по АР мы будем обращаться к нашему текущему PAMу (Payment Account Manager).

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

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

После создания тикета кидаем его в канал ss-billing в слак-канале External SG. При этом обязательно тегаем текущего PAMa и описываем проблему. Далее нужно ждать ответа от СС и напоминать о проблеме, если по ней долго не находится решение. В данном случае нам отвечают, что банк проблемный и у всех остальных брендов. Как итог нам меняют настройки провайдеров под те, которые помогут исправить ситуацию. Если после этого проблема решается - закрываем тикет, если нет, консультируемся с коллегами и СС с целью поиска решения. В еженедельный отчет стоит добавлять только проблемы которые возникли или были решены на этой неделе.

Краткий пример еще одного тикета

Рассмотрим тикет https://jira.softswiss.net/servicedesk/customer/portal/2/BBCUS-674713. На первом скрине мы видим сложившуюся ситуацию, когда транзакции, которые были инициированы на провайдере ECommPay, ни разу успешно не завершились на этом провайдере. То есть этот АР сам не может обработать транзакцию, что является большой проблемой, уменьшающей АР. Создаем тикет, описываем проблему, прикрепляем примеры транзакций, и скриншот. СС соглашается с существованием проблемы и вносит изменения в своих настройках.