Доброго времени суток, дорогие жители !
За несколько лет в вебе наши маркетологи привыкли к системам аналитики, они их понимают, хорошо знакомы с большинством инструментов, знают, как их использовать. Они научились с этим работать за 5-10 лет. А мобильная аналитика пока для них темный лес. Соответственно и функционал немного отстает в развитии от веба, потому что отрасль молодая.
Об этих проблемах мы поговорим со старшим аналитиком Google Analytics, Станиславом Видяевым. Полная аудиоверсия интервью — iTunes, TuneIn.
Я захожу в систему, какой функционал мне нужно освоить в первую очередь, чтобы начать реально работать с вашим продуктом? Может быть, есть какая-то литература, семинары, ваши книги на английском языке?
Google Analytics изначально веб-продукт и в нем хорошо развиты все соответствующие метрики.
Развитие идет таким образом, что изначально веб-продукт начинает приспосабливаться к появлению этого мобильного мира.
Если сказать честно, то компания Google немного опоздала: первые мобильные профили у нас появились 2 года назад (июнь 2012 года), с этого времени мобильное направление развивается, и система пытается освоить мобильный язык. Но все-таки подходит к мобильному миру с точки рения веб-маркетолога.
Маркетолог, который занимался веб-аналитикой, сайтами, он уже более-менее подготовлен, и, приходя к нам за анализом мобильного приложения, он выбирает привычные метрики.
Для мобильного приложения они не сильно применимы, но тем не менее их можно использовать, оценивая эффективность мобильного приложения.
Все метрики, какие там есть и какие видны стразу после установки Analytics. Это количество активных пользователей, новые, возвращающиеся, география использования приложения, популярность отдельных разделов, как люди их смотрят (те же самые конверсии, покупки) — весь тот набор, который изначально нужен для понимания, что в мобильном приложении происходит. Еще какие то вещи можно настраивать — Custom Dimensions.
Что такое Custom Dimensions?
Это дополнительные параметры, которых нет по умолчанию, но мы можем создать и задать их. Например, юзер в приложении кликает на кнопку и становится платным пользователем, мы можем повесить ему ярлык платного пользователя, с которым он будет оставаться всю жизнь, пока у него установлено это приложение.
То есть все его дальнейшие посещения мы можем отсегментировать как группу платных пользователей нашего приложения. Это настраивается дополнительно, и изначально этих метрик в Analytics нет. То есть об этом надо заранее подумать, придумать эту метрику, понять в какой момент ее создавать и запускать.
Такой конструктор есть и в вебе. Мы переносим веб на мобильные рельсы. Архитекторы считают, что те концепты и принципы аналитики, которые существуют для вебсайтов, применимы и для мобильных приложений
Где мне почерпнуть первичный набор знаний?
Книга — самый неудачный способ описания проблемы, как только она опубликована, она тут же устаревает. Я бы отправил всех на наш ресурс. Единственный недостаток в том, что он только на английском, на русский пока не переведен.
На этом ресурсе самая последняя информация, там делаются все анонсы.
Естественно, интернет необъятный, есть много умных людей, которые пишут от себя что-то стоящее. В основном я бы читал у различных авторов обзоры разных систем и их сравнения. Они не всегда корректные, что-то они упускают, но общая идея хорошая.
Какие реальные проблемы ты сейчас видишь в мобильной аналитике?
Это сложность системы в целом. То есть техническая аналитика в мобильных приложениях. Я не беру сайты, потому что может быть дальше у нас не будет разделения на мобильный и обычный сайт, и такое понятие, как мобильный сайт исчезнет.
Если брать приложение, то это сложность технической имплементации, интеграции пакетов и большие требования по установке к технической подготовке того, кто это делает.
Если на сайт установил код и поехали (есть какие-то данные), то в приложении надо подумать заранее что мы хотим отслеживать, как и в какие моменты, мы хотим запускать те или иные события. То есть это все нужно заранее обдумать и технический специалист должен это дело имплементировать. Опять-таки, если касаться собственно Google Analytics то, как я упомянул, система только привыкает к мобильным определениям.
Есть еще одна тема, которая сегодня развивается (это с одной стороны слабость Google Analytics, но из этой слабости хотят сделать очень сильную сторону) — это объединение двух миров — веба и мобайл.
Вот как раз под «зонтиком» Universal Analytics мы будем в этом направлении двигаться. Universal Analytics — это новая реинкарнация Google Analytics, у которой другой код и архитектура, там используются другие cookies — это новая система. Она называется Google Analytics только потому, что ее видно в интерфейсе.
Когда я подготавливался к интервью, я снова посмотрел документацию на еще один хороший источник — developers.google.com — там техническая информация. В том числе посмотрел SDK, и там уже есть раздел User ID, который можно использовать для отслеживания переходов с разных устройств на сайт (пока только на сайт) одного и того же пользователя.
Какой там принцип?
Пользователь приходит на сайт, ему в браузер загружается client ID — это идентификатор Google Analytics, и он уникален для этого браузера, то есть, сколько браузеров у пользователя, столько и идентификаторов и, соответственно, уникальных посетителей в отчетах Analytics. Если на одном устройстве у него три браузера, то это будет три разных пользователя.
Есть User ID — это параметр владельца бизнеса, владельца сайта. То есть, когда пользователь зарегистрировался, заполнил заявку (как-то идентифицировал себя), то владелец сайта может подгрузить этот User ID.
Так вот в документации для мобильных приложений уже появился User ID. То есть мы можем объединять не только его историю посещений сайта, но и приложений. В данный момент у нас пока четкое разграничение между миром веб и мобайлом. Но потом Universal Analytics будет двигаться в сторону объединения этих двух миров.
Вы активно пропагандируете Google Tag Manager. Что это за штука, как она работает?
Google Tag Manager — это способ работы с трекинговыми кодами. Если брать вебсайты, это код, скрипт — кусочек кода, который мы устанавливаем на сайт, и уже потом в интерфейсе Tag Manager работаем с непосредственными трекинговыми кодами аналитических систем.
И этот код Tag Manager, он выполняет функции других кодов, то есть, он отправляет вызовы, притворяется ими и в данный момент, он может работать как Google Analytics, потом как Яндекс.Метрика, потом как Conversion Tracking — он выполняет функции этих кодов.
Какую проблему он решает?
Проблему установки кодов в исходный код сайта. То есть, у нас нет необходимости каждый раз бежать к техническому специалисту, к веб-программисту и говорить: «Установи вот эту маленькую строчку». А он это ставит в Pipeline, и это дело длится три месяца, это правится, потом выполняется — чем больше компания, тем больше заморочек в этом плане.
С Tag Manager мы имеем один сниппет на сайте, возможно, к нему какие-то дополнительные функции, которые мы продумали заранее, допустим, транзакция. Дополнительные параметры в синтаксисе Tag Manager-а передаются в Data Layer — это способ передачи событий, переменных и транзакций для Google Tag Manager. То есть все параметры прописали, и потом мы можем отслеживать, например, транзакции и в Google Analytics, и в Яндекс.Метрике — везде где нам нужно.
В мобильной аналитике та же история?
История следующая. Создатели и разработчики Tag Manager сделали его следующим образом: для Tag Manager и для Google Analytics единый SDK. То есть, интегрируя в SDK последний Google Analytics с приложением, вы интегрируете и Tag Manager. И наоборот — интегрируя Tag Manager, вы получаете Google Analytics.
То есть управление этим кодом достаточно более простое и эффективное. Дело не только в таких маркетинговых ходах. Допустим, нужно отслеживать какое-то событие в Tag Manager, для этого не надо бежать в разработку и заставлять их делать новую версию приложения, публиковать ее, чтобы этот вызов или событие было включено.
То есть я могу настроить отслеживание любого события без помощи разработчиков?
Да. При условии, что это событие заведено в Tag Manager. То есть если оно там есть, то внутри Tag Manager можно на это событие заводить любые коды, которые надо. Это намного проще.
Есть еще один момент. При интеграции с Analytics появляются возможности, например, по проведению экспериментов.
Что за эксперименты?
Это эксперименты на реальных пользователях. То есть мы не где-то в песочнице тестируем различные цвета, размеры кнопок, картинок, текстов, оформление логотипов и т.д. Все эти элементы дизайна можно динамически менять и проводить эксперименты в Google Analytics.
Это будет выглядеть так. Эксперимент создается и конфигурируется в Tag Manager, а визуализация этого эксперимента и все графики, какой вариант конфигурации приложения победил, они все видны в Analytics. И после завершения этого эксперимента можно будет в Tag Manager сконфигурировать приложение таким образом, чтобы выигравший вариант стал базовым.
Это, например, эксперимент с формой: какая регистрация лучше — только Facebook или Facebook + Email?
Да, в том числе. Элементы, с которыми мы хотим провести эксперимент, мы их оформляем переменными Tag Manager, то есть вызов контейнера.
Я вижу проблему: есть простой рядовой маркетолог — ему невозможно внедрить аналитическую мобильную систему (вообще ни одну) без похода к разработчику. На самом деле вариантов-то особо нет, это реалии рынка.
Но есть другой вариант — у вас есть такой инструмент, как Google Developer Console. Почему бы там не выводить больше количество информации по retention, churn rate и т.д.?
Мы движемся в этом направлении, но идеальной ситуации нет, к ней можно только стремиться. Появляются отчеты. Недавно был июньский апдейт — появился ряд отчетов для игровых приложений. То есть там видно количество игроков, retention и т.д. Но опять-таки это достаточно общая информация.
Если ты хочешь увидеть что-то эдакое, например, посмотреть с помощью Google Analytics, как пользователи отваливаются при прохождении различных уровней игры. Например, у тебя 10 уровней, и с помощью аналитики ты выявляешь, что уровень 5 и 6 слишком трудные, пользователи их не проходят и отваливаются. После этого ты делаешь их чуть полегче, и они у тебя доходят до уровня 7-8. То есть длительность взаимодействия с пользователем в одной игрушке увеличивается.
Эти уникальные вещи для всех на такой платформе не заточишь, поэтому в игру вступает Google Analytics, который можно видоизменить под эти цели, настроить и там эти цели отслеживать.
Какие базовые возможности Google Developer Console?
Это место, где мы публикуем приложения. То есть заводиться аккаунт разработчика, мы публикуем приложения, оплачиваем $25 и начинаем продвигать его в Google Play (у вас может быть несколько приложений), и там по умолчанию доступна часть статистики. Но опять-таки для серьезной аналитики это не подойдет — это базовый уровень.
Есть ли у вас удобный способ для трекинга источника инсталов, что-то типа аналога того же MAT. То есть для Android он вроде как точно есть, но как это сделать для iOS?
Это вопрос интеграции Google Play с приложением. Если мы это делаем, то у нас видны источники, которые приходят в Google Play (на нашу страничку) и потом превращаются в инсталлы, потом мы можем увязать эту историю с конверсиями.
Говоря на веб-жаргоне — Google Play протягивает referrer. То есть тот referrer, который принес нам трафик (это может быть платный источник, партнерки, социальные сети — что угодно), все эти вещи мы можем видеть внутри аналитики приложения.
Более того, там же дальше тема развивается — трекинг конверсии, чтобы обратно в тот же AdWords отдать конверсию — это тоже все возможно, вплоть до последнего клика показа конкретного объявления в конкретном приложении. Мы видим конверсию.
На основе это аналитики мы видим источник 1, источник 2, инсталы, конверсии. Мы видим, что источник 1 надо отключать, потому что он не конвертируется, а все деньги нести в источник 2, например. Аналитика об этом. Этот как раз объединение маркетинговых действий с поведением пользователя внутри Android-приложения.
iOS не передает, не протягивает referer. Для того чтобы это сделать на developers.google.com/, есть описание процесса, как этот referrer протащить. То есть там уже серверная интеграция, нужна серьезная техническая настройка.
Как правильно считать время жизни пользователя в приложении?
Наука не знает, что происходит после последнего отслеживаемого события. Пользователь кликнул, открыл страницу — сколько он на ней был? Он ее читал 5 минут или изучал ее 40 минут по диагонали, вверх-вниз и поперек — мы этого не знаем.
У нас есть время нахождения пользователя на сайте или в мобильном приложении — это первое и последнее событие, и мы измеряем период, который прошел между ними. То есть Google Analytics отслеживает какое-то событие, и от этой точки начинается отсчет времени.
Что можно сделать, чтобы это дело сделать более точным?
Был такой прием, для вебсайтов он прокатывал. Например, просмотр страницы: допустим, у нас большой контентный сайт, у нас огромные статьи, люди читают аналитику. Открыл страницу — читаю, больше никаких событий не происходит. То есть, сколько я на этой станице нахожусь, Analytics не знает и не может знать.
Для того чтобы измерить время на этой странице мы запускаем событие. Допустим, каждые 15 секунд, пока пользователь находится на странице, мы отправляем событие или отслеживаем Scroll как событие — получается, мы даем Analytics понять, что пользователь все еще находится на сайте.
Для приложения можно запустить какую-то аналогичную вещь. Не только отслеживать клики по кнопкам, но и такие вещи, как Swipe, Zoom In, Zoom Out — на все эти действия, сугубо применимые для приложения, мы тоже можем отправлять события. То есть на таком экране произошел Zoom In, на другом экране произошел Zoom Out. Все это можно отслеживать, и это увеличит время взаимодействия пользователя с приложением. А если оно открыто и экран темный, то, я думаю, не надо ничего отслеживать.
Такие моменты как виральность, органика и прочее — есть ли возможность отслеживать как минимум виральность приложения или хотя бы оценивать примерное значение?
Скорее, оценивать примерное значение. В Google Analytics отчет виральности отсутствует. Надо подумать заранее и пытаться представить себе каким образом наше приложение может расходиться и как наши действия могут влиять на это.
Запустили рекламу, после нее есть какой-то длинный хвост, который всегда доходит — нужно смотреть сегмент. То есть мы выделяем в сегмент рекламный трафик, мы знаем, в какие даты у нас происходят какие-то оффлайновые события, проходят другие контентные проекты.
Допустим, у нас с тобой автомобильное приложение, и мы проводим автопробег Москва-Петушки, где мы продвигаем это приложение — и реклама приложения есть на всех бортах автомобилей. Мы смотрим даты этого автопробега (в Google Analytics есть аннотация, это все можно прописывать по времени) и динамику инсталлов и т.д.
Или, например, сегодня на TV была новость. Соовтетственно, мы смотрим на органический трафик, на цитируемость бренда в поиске — все эти вещи должны быть в комплексе. Можно разбить это дело по сегментам и смотреть, как рекламный трафик влияет на рост органики.
Органический трафик уже виден в отчетах?
Да. В Analytics это видно, там будет два сегмента — две кривые — идут они друг за другом или не идут. Соответственно, также можно оценивать качество трафика, например, каково время взаимодействия с пользователем, падает оно или увеличивается. То есть ту аудиторию мы приводим или нет. То же самое с конверсиями.
Все эти вещи можно оценивать по ряду косвенных признаков. Естественно, прямого отчета нет.
Есть еще одна проблема — это фрод в мобильном сегменте: наливают некачественный трафик. Если ли возможность этот фрод определять? Я знаю, как это делать в вебе. То есть я вижу источники, даже смотрю ту же сеть Google, то, что он не поймал, я сам долавливаю и смотрю мошенников с промахами кликов, что угодно — вариантов как меня перехитрить много. Я детально отсекаю каждую площадку.
Если ты какие-то механики отсева этого фрода в мобайле при помощи того же Google Analytics?
Analytics не предназначен для ловли воров. Опять-таки, это ряд косвенных признаков.
У меня пока не было кейсов, чтобы я кого-то отловил именно для мобильной аналитики, а вот с вебсайтами были. Обращались клиенты и спрашивали, что это за трафик такой.
Фрод можно увидеть по некоторым специфическим показателям взаимодействия.
Бывает, делают такие баннеры, что при нажатии на крестик я все равно попадаю по рекламному объявлению. Как я пойму, что что-то там не то, по какому событию?
Первый признак — это высокий показатель отказа (bounce rate). Если у нас цель инсталлы и этот трафик дает инсталлы, то тут немного сложнее. Если мы видим большое количество посещения страницы Google Play/App Store и мало установок, а для нас этот трафик платный, то мы можем задуматься, каким образом это происходит.
В данный момент, если идет рекламная компания, можно пойти посмотреть на это объявление, попросить, чтобы родственники сходили, коллеги коллег, чтобы они с разных устройств это дело посмотрели (желательно в разных регионах) и покликали. Соответственно, если есть фрод, то таким образом его можно хотя бы отловить.
Как вести себя с партнерами — это следующий вопрос, но факт фрода сам Analytics не увидит, а просто подскажет, что здесь видно, что приходят и не инсталлируют.
Вопрос об ограничениях на продукт по объемам, по количествам событий и т.д. — они применимы к мобайлу?
Да. Ограничение общее, как для всего Analytics, так для любого ресурса. И есть несколько ограничений непосредственно для мобильных приложений. Это все описано в документации.
Для стандартного Google Analytics — это 10 миллионов хитов в месяц.
Для одного ресурса это ограничение достаточно растяжимое. То есть если у нас 30-40-50-100, мы работаем нормально. Единственное, что в негатив, который происходит, у нас включается выборка — точность данных страдает. Мы видим те же самые графики, тенденции, но, условно говоря, в отдельных отчетах система берет за основу расчета данного отчета 10% этого трафика, а потом домножает в уме. Это семплирование — выборка.
С появлением в России реселллеров, и с появлением возможности приобрести Google Analytics Premium для тех сайтов, в том числе и приложений, это правило становится более жестким. То есть мы оповещаем: «Дорогой клиент, Вы превзошли лимит во столько-то раз».
Если у вас 10-20-50 миллионов хитов, такого извещения не будет. Если много — 500 миллионов в месяцу, то велика вероятность, что такое оповещение будет получено.
Можно ли хоть забирать сырые данные по мобильному приложению для построения своей аналитики?
Да. Для API мобильных приложений такой возможности сейчас нет, но я полагаю, что под «зонтиком» Universal Analytics она будет. В частности то, что User ID начинают прикручивать к мобильным устройствам, а это ведь тема, приближенная к API. Сервер — это уже работа с Big Data и прочие интеграции.
Я полагаю, что эта тема будет развиваться в ближайшее время и API для мобильных приложений будет либо отдельный, либо в рамках Core Reporting API, который сейчас есть в Analytics. Я не знаю, как это будет архитектурно, но само собой напрашивается, что будет.
Наверняка есть какой-то Road Map, о котором ты слышал и про который вам коллеги разрешают рассказывать. Что будет? Когда появятся такие метрики, как Return Rade, LTV, еще что-то? Когда Google Analytics начнет со мной разговаривать на мобильном языке?
Он как трехлетний ребенок пытается осваивать язык мамы и папы, уже что-то говорит. В данном случае Return Rade в вебе есть отчет по лояльности — новые и вернувшиеся. Аналогичные отчеты есть в мобайл, только они немного по-другому называются, но их там можно смотреть и работать с ними.
Что касается LTV — то этого отчета нет, но с помощью кастомных метрик и параметров его можно собрать. То есть условно мы знаем, что этот пользователь вчера купил у нас что-то на 5 рублей, и мы в переменную ему записываем, что он оставил у нас 5 рублей. Если он завтра еще что-то на 5 рублей купит, мы можем взять те предыдущие 5 рублей и к ним прибавить еще 5 и получится 10 рублей.
Опять-таки, всех случаев не предусмотришь. Мы не всегда можем предусмотреть и предсказать, что данная функция действительно будет пользоваться успехом. А дать возможность конфигурировать самим то, что нужно, с помощью тех же кастомных переменных (пользовательских определений на языке Universal Analytics) можно.
Там есть переменные на уровне хита, сессии и пользователя. И как раз для LTV лучше подходит сессия на уровне пользователя, когда мы присваиваем пользователю какой-то параметр.
Об этом все говорят, но не все это используют, потому что это довольно специфическая функция. А потом сегментировать пользователя, который оставил 10 рублей, против пользователя, который оставил 5 рублей, и сравнивать данные по ним.
В общем, вам не хватает образовательных вещей на простом языке.
На самом деле западный рынок более подготовленный и образованный в этом плане. Они без проблем общаются на более техническом языке. То есть там люди подкованные, и им можно просто сказать: «Вот кастомные переменные». А в ответ: «Окей, пойду делать, все понял».
Может быть, есть еще какие-то, фичи, сюрпризы, обратная связь, push-уведомления?
Внутренняя коммуникация с product-менеджерами строится таким образом, что вещь, которая подходит — нам о ней рассказывают. То, что я рассказывал про объединенный функционал Tag Manager и Google Analytics, о возможностях в этой системе, это как раз вот такой функционал, который прямо сейчас становится доступным.
Про эксперименты в мобильных приложениях рассказали совершенно недавно, сейчас тестируют, скоро будет выкатываться. Мы уже можем полушепотом рассказывать, что это есть или скоро будет.Что касается отдельных вещей, которые будет потом мне тяжело говорить.
Есть какая-то обратная связь с рынком?
Да. У нас есть разработчики, специалисты, которые общаются внутри Google с продавцами — с нами, мы продаем AdWords и помимо этого у нас есть потребность клиентов в аналитике.
Мы собираемся, и эта коммуникация идет вот таким образом. У нас есть человек по Восточной Европе, мы ему коммуницируем, что у нас есть такие-то сложности, такие-то возможности и замечательные конкуренты — давай вместе посмотрим интерфейс, может, возникнут какие-то идеи.
Мы смотрим вместе, у него появляются идеи и он может коммуницировать их разработчику. Разработчик говорит — «Окей, интересная тема, давай посмотрим». Такая коммуникация есть.
Всем спасибо, всем продуктивного дня!
—————————————————————————————————————————————————————————————————
Мы сделали рассылку полезных материалов для мобильных разработчиков и маркетологов. Скажу честно, работали над ней очень долго ;)
Подписывайтесь, первый выпуск уже сделали :)
Автор: Apps4All_post
