аналитика на кубах

Расскажу вам про одну рядовую задачу, которая возникла недавно.

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

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

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

Во-вторых, косяк в инфраструктуре. Платежи с тестовых девайсов попадали в общий поток платежей для AppsFlyer, но уходили на тестовый стенд в наших аналитических системах. Обычно на тестовые платежи можно не обращать внимания, пара десятков долларов погоды не делают, да и на других проектах не было таких проблем. Но на старте закупки они оказались заметными. Тоже, наверное, надо будет решать и встраивать механики маркировки тестовых платежей от AF.

Третий кейс вообще смешной. Пользователь сделал платеж. Сервер начислил ему ресурсы. А вот через шесть часов с клиента ушло еще одно сообщение в AF об этом же платеже. В результате два платежа с одним идентификатором. Наши системы отфильтровали дубль, AF — нет, да и не его это задача. Как это произошло — непонятно и скорее всего мы не будем ничего делать, если таких кейсов будет единицы.

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

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

www.group-telegram.com/jp/diceanalytics.com/167

1.1K viewsedited  May 1 at 06:15

Расскажу вам про одну рядовую задачу, которая возникла недавно.

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

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

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

Во-вторых, косяк в инфраструктуре. Платежи с тестовых девайсов попадали в общий поток платежей для AppsFlyer, но уходили на тестовый стенд в наших аналитических системах. Обычно на тестовые платежи можно не обращать внимания, пара десятков долларов погоды не делают, да и на других проектах не было таких проблем. Но на старте закупки они оказались заметными. Тоже, наверное, надо будет решать и встраивать механики маркировки тестовых платежей от AF.

Третий кейс вообще смешной. Пользователь сделал платеж. Сервер начислил ему ресурсы. А вот через шесть часов с клиента ушло еще одно сообщение в AF об этом же платеже. В результате два платежа с одним идентификатором. Наши системы отфильтровали дубль, AF — нет, да и не его это задача. Как это произошло — непонятно и скорее всего мы не будем ничего делать, если таких кейсов будет единицы.

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

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

BY аналитика на кубах