Pull to refresh
0

Разрабатываем систему аналитики

Reading time 9 min
Views 15K
Данный пост открывает цикл статей о разработке аналитической системы мониторинга действий пользователей. В первой статье мы расскажем о том как собирать необходимые данные с мобильных приложений под андроид и айос.

package Birdy::Stat::Stalin;
#
# Это Сталин, он всё про всех знает
# Кто и что делает, кто и с кем спит
#
# ########################################################
# ########################################################
#
#                 !#########       #
#               !########!          ##!
#            !########!               ###
#         !##########                  ####
#       ######### #####                ######
#        !###!      !####!              ######
#          !           #####            ######!
#                        !####!         #######
#                           #####       #######
#                             !####!   #######!
#                                ####!########
#             ##                   ##########
#           ,######!          !#############
#         ,#### ########################!####!
#       ,####'     ##################!'    #####
#     ,####'            #######              !####!
#    ####'                                      #####
#    ~##                                          ##~
#
# ########################################################
# ########################################################


Мы — рекомендательный сервис Surfingbird. Чем больше мы понимаем пользователя — тем более релевантные рекомендации мы генерируем.

Google analytics, Flurry, Appsflyer — можно с головы до ног обмазаться существующими аналитическими системами. Можно построить великолепный dashboard на который вывести DAU, MAU, DNU, ARPU, K-Factor и еще с десяток показателей — но все это будут лишь тени на стенах пещеры. Ни одна система аналитики не ответит вам на вопрос ПОЧЕМУ пользователь ушел из приложения, что именно спровицировало его уход, она лишь зафиксирует факт ухода пользователя. Вы даже не сможете написать ему прощальный email) Поэтому мы решили, что для того чтобы ответить на этот и подобные вопросы — мы должны знать о пользователях все. В какой последовательности и с каким интервалом, на каких экранах и какие кнопки он нажимал. Сколько секунд и какую статью он читал, прежде чем развернуться, плюнуть и уйти. Какова гистограмма чтения статьи. Сколько времени было потрачено на каждый пиксель и в каком варианте А/Б теста. В определенный момент мы поняли что нам нужен Сталин.

Прежде всего мы согласовали структуру данных в которой хотим передавать трекаемые события. Данная структура едина для веб, мобайл и, забегая вперед — баз данных на бэкенде (да, их много).

События состоят из следующих базовых составляющих
  1. Action — действие пользователя, отвечает на вопрос что он сделал
  2. Screen — экран, отвечает на вопрос на каком экране
  3. ContentType — тип контента, отвечает на вопрос с каким типом контента было взаимодействие

А так же:

  • userToken — кто
  • time — когда
  • clientVersion — в какой версии
  • contentID — идентификатор контента
  • deviceID — уникальный идентификатор устройства
  • deviceType — тип устройства
  • прочие измерения — абтесты, описания (для ошибок) и так далее


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

Это базовый набор от которого мы отталкиваемся.

В свою очередь измерения могут быть представлены например неким набором значений, например:

    //Действия
    public enum Action {
        none,
        //хиты установки клики
        install,//в момент запуска приложения незарегом
        hit,//в момент открытия приложения
        clickon_surfbutton,//клик по кнопке серф
        clickon_volumebutton,//клик по кнопке громкости

        //открытие лент
        open_surf,//открытие ленты рекомендаций
        open_feed,//открытие ленты подписок
        open_popular,//открытие ленты популярного
        open_dayDigest,//открытие ленты картина дня
        open_profile,//открытие профилю
        open_settings,//открытие настроек
        open_comment,//открытие комментарияв

        //блок регистрации/авторизации пользователя (начало/конец)
        registrationBegin_vk,//done
        registrationSignIn_vk,//done
        registrationSignUp_vk,//done
        registrationBegin_fb,//done
        registrationSignIn_fb,//done
        registrationSignUp_fb,//done
        registrationBegin_email,//done
        registrationComplete_email,//done

        //страница
        page_seen,//в андроиде пока не используется
        page_click,//клик из какой нибудь ленты (8 штук)
        page_open,//открытие страницы (откуда угодно)
        page_read,//чтение страницы в секундах
        //шаринги
        share_fb,//done
        share_vk,//done
        share_sms,//done
        share_email,//done
        share_pocket,//done
        share_copyLink,//done
        share_saveImage,//done
        share_twitter,//done
        share_other,//done

        //действия со страницей
        like,//done
        dislike,//done
        favorite,//done
        addToCollection,//done

        //действия с пушами
        openPush,//done
        deliveredPush,//done
       //and so on
    }


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

Если посмотреть на модель данных, например в андроид, то любое событие может быть представлено в виде следующего класса:

    public ClassEvent (Action action, Screen screen, ContentType contentType, String contentID, String abTest1, String abTest2, String description, int count) {
        this.abTest1 = abTest1;
        this.abTest2 = abTest2;
        //and so on
        this.contentType = contentType;
        this.contentID = contentID;
        this.time = System.currentTimeMillis()/1000;
        this.deviceID = SurfingbirdApplication.getInstance().getDeviceId();
        this.deviceType = "ANDROID";
        String loginToken = SurfingbirdApplication.getInstance().getSettings().getLoginToken();
        this.userToken = loginToken==null?"":loginToken;
        this.clientVersion = SurfingbirdApplication.getInstance().getAppVersion();
    }

    @Override
    public String toString() {
        JSONObject jsonObject= new JSONObject();
        try {
            jsonObject.put("clientVersion", clientVersion);
            jsonObject.put("action", action.toString());
            jsonObject.put("screen", screen);
            jsonObject.put("contentType", contentType);
            jsonObject.put("contentID", contentID);
            jsonObject.put("time", time);
            jsonObject.put("deviceID", deviceID);
            jsonObject.put("deviceType", deviceType);
            jsonObject.put("userToken", userToken);
            jsonObject.put("abTest1_id", abTest1);
            jsonObject.put("abTest1_value", abTest2);
            jsonObject.put("description", description);
            jsonObject.put("count", count);
        } catch (JSONException e) {
            AQUtility.debug("EVENTERROR",e.toString());
        }
        return jsonObject.toString();
    }



Как это выглядит в самом приложении?

Любое действие, на любом экране регистрируется в виде события.
Проще всего рассмотреть фрагмент моей сессии в табличном виде


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

Примерно так будут выглядеть те же данные, но уже после процессинга в OLAP:
image

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

На андроиде мы упаковываем в пакеты по 50 штук и, в момент генерации добавляем в гугл аналитику, для перекрестной сверки:

    public void newEvent(ClassEvent.Action action,ClassEvent.Screen screen,ClassEvent.ContentType contentType,String contentId) {
        registerEvent(new ClassEvent(action,screen,contentType,contentId));
    }


    public void newEvent(ClassEvent.Action action,ClassEvent.Screen screen,ClassEvent.ContentType contentType,String contentId,String abTest1,String abTest2,String description,  int count) {
        registerEvent(new ClassEvent(action,screen,contentType,contentId,abTest1,abTest2,description,count));
    }

    public void registerEvent(ClassEvent event) {
        Tracker t = getTracker(
                SurfingbirdApplication.TrackerName.GLOBAL_TRACKER);

        t.setScreenName(event.screen.toString());
        Map<String, String> hits = new HitBuilders.EventBuilder()
                .setCategory("event")
                .setAction(event.action.toString())
                .setLabel(event.action.toString())
                .build();
        t.send(hits);
        if (TextUtils.equals("",event.userToken) || TextUtils.equals("null",event.userToken)) {
            String eventsString = "[";
            eventsString+=event.toString();
            eventsString+="]";
            events.clear();
            aq.ajax(UtilsApi.eventsCallBackBasic(this, "some_method", eventsString));
        }
        else {
            events.add(event);
            if (events.size()>50) {
                sendEvents();
            }
        }
    }

    public void sendEvents() {

        if (events.size()>0) {
            String eventsString = "[";
            for (ClassEvent event: events) {
                if (!eventsString.equals("[")) eventsString+=",";
                eventsString+=event.toString();
            }
            eventsString+="]";
            events.clear();
            aq.ajax(UtilsApi.eventsCallBack(this, "nop", eventsString));
        }
    }


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

Так выглядит собственно «набрасывание событий на андроид»
       SurfingbirdApplication.getInstance().newEvent(ClassEvent.Action.install, ClassEvent.Screen.none, ClassEvent.ContentType.none, "");
       SurfingbirdApplication.getInstance().newEvent(ClassEvent.Action.openPush, ClassEvent.Screen.page_parsed, ClassEvent.ContentType.siteShort,shortUrl);
       SurfingbirdApplication.getInstance().newEvent(ClassEvent.Action.registrationBegin_email, ClassEvent.Screen.start, ClassEvent.ContentType.none, "");


На айос мы опробовали немного иную логику:

События так же накапливаются в стек и при любом последующем запросе – к нему паровозом прицепляется массив накопленных сообщений. Если событий накапливается больше чем 50, мы принудительно делаем запрос с системным методом nop. Также, если отслеживаемое событие нужно отправить как можно скорее, можно форсировать nop-запрос.

// переопределяем метод у наследника AFHTTPRequestOperationManager
- (void)    POST:(NSString *)path
      parameters:(NSMutableDictionary *)parameters
         success:(void (^__strong)(AFHTTPRequestOperation *__strong, __strong id))success
         failure:(void (^__strong)(AFHTTPRequestOperation *__strong, NSError *__strong))failure {

    SBEvents *events = [SBEventTracker sharedTracker].events;

    if (events.count > 0) {

        parameters[@"_events"] = [events jsonString];
        [[SBEventTracker sharedTracker] clearEvents];
    }

    [super POST:path parameters:parameters success:^(AFHTTPRequestOperation *operation, id json) {
        //
    } failure:^(AFHTTPRequestOperation *operation, NSError *error) {
        //
    }];
}


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

Внимание, код на перле. У неподготовленных людей вызывает кровоточение из глаз и преждевременную беременность
package Birdy::Stat::Stalin;

use constant {
    SUCCESS     => 'success',
    FAILURE     => 'failure',
    UNKNOWN     => 'unknown',

    CONTENT_TYPE_NONE => 'none',
};

sub track_events {
    my $params = shift;

    return unless ref $params eq 'ARRAY';
    return unless @$params;

    my ($s_events, $f_events, $u_events) = ([],[],[]);

    foreach (@$params) {

        my $event = __PACKAGE__->new($_);
        $event->parse;

        # раскидываем события по разным спискам
        given ($event->status) {
            when (SUCCESS) {
                push @$s_events, $event;
            }
            when (FAILURE) {
                push @$f_events, $event;
            }
            when (UNKNOWN) {
                push @$u_events, $event;
            }
        }
    }

    __PACKAGE__->_track_success_events($s_events);
    __PACKAGE__->_track_failure_events('failure', $f_events);
    __PACKAGE__->_track_failure_events('unknown', $u_events);
}

state $enums = {
    'action' => [qw/
                    install hit
                    open_surf open_feed open_popular open_dayDigest open_profile open_settings open_comment
                    registrationBegin_email registrationComplete_email
                    page_seen page_click page_open
                    share_fb share_vk share_sms share_email share_pocket share_copyLink share_saveImage share_twitter share_other
                    like dislike favorite addToCollection
                    openPush deliveredPush openDayDigestFromLocalPush
                    error page_read none
    /],
    'screen' => [qw/
                    none start similar
                    surf feed popular dayDigest profile settings
                    page_parsed page_image siteTag actionBar
                    actionBar_profile actionBar_page actionBar_channel
                    profile_channel profile_add profile_like profile_favorite profile_collection
    /],
    'deviceType'  => ['IPAD', 'IPHONE', 'ANDROID'],
    'contentType' => [CONTENT_TYPE_NONE, 'siteShort', 'userShort', 'siteTag'],
};
state $fields = [ sort (keys %$enums, qw/time deviceID clientVersion userId userLogin contentID shortUrl count description/) ];

sub parse {
    my ($self) = @_;
    my $event_param = {};

    {
        my $required = [keys %$enums];
        my $optional = [];

        # проверим что есть нужные параметры
        # если какого-то нет, такое событие трекать нельзя
        unless ( $self->_check_params($required) ) {
            $self->status(FAILURE);
            return;
        }

        # Эти параметры енумы, поэтому они могут иметь лишь определённые значения
        # Если значение хоть одного параметра нам не известно,
        # Запишем параметры события в другую таблицу, чтобы обработать потом, когда научимся
        unless ( $self->_check_enum_params($required) ) {
            $self->status(UNKNOWN);
            return;
        }

        my $params = $self->_parse_params([@$required, @$optional]);

        $event_param = {
            %$params,
            %$event_param
        };
    }

    {
        my $required = ['time', 'deviceID', 'clientVersion'];
        my $optional = ['userToken', 'count', 'description'];

        # contentID опционален, если contentType eq 'none'
        push @{
            $event_param->{'contentType'} eq CONTENT_TYPE_NONE ? $optional : $required
        }, 'contentID';

        # проверим что есть нужные параметры
        # если какого-то нет, такое событие трекать нельзя
        unless ( $self->_check_params($required) ) {
            $self->status(FAILURE);
            return;
        }

        my $params = $self->_parse_params([@$required, @$optional]);

        $event_param = {
            # если опциональных параметров нет, всё равно нужно их добавить
            (map { $_ => undef } @$optional),
            %$params,
            %$event_param,
        };
    }

    $event_param->{'time'} = Birdy::TimeUtils::unix2date(
        $event_param->{'time'}
    );

    $self->status(SUCCESS);
    $self->params($event_param);

    return;
}

# вернёт hashref с запрошенными параметрами
sub _parse_params {
    my ($self, $params) = @_;

    $params = [] if ref $params ne 'ARRAY';

    my $result = {};

    foreach my $key (@$params) {

        my $value = $self->params->{$key};
        next unless $value;

        $result->{$key} = $value;
    }

    return $result;
}


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

В следующих статьях мы планируем подробнее остановиться на методике анализа усвоения контента, как построить DWH/OLAP систему из говна и палок, а также подробнее расскажем о прощальных письмах и к каким смешным результатам это приводит.
Tags:
Hubs:
+4
Comments 8
Comments Comments 8

Articles

Information

Website
surfingbird.ru
Registered
Employees
11–30 employees
Location
Россия