Предыдущий ролик Следующий ролик  

Видео урок: Как структурированы аккаунты, ресурсы и представления в Google Analytics

Советы по Google Analytics

Одной из самых сильных сторон Google Analytics является интуитивно понятный интерфейс, позволяющий пользователям без труда создать аккаунт и приступить к отслеживанию цифровых ресурсов, не имея при этом особых знаний в этой области. Тем не менее, это палка о двух концах, поскольку первоначально принятое решение о структуре аккаунта впоследствии будет очень трудно, если даже невозможно, отменить. Или же это решение может значительно повлиять на получение полноценной оценки аккаунта. Для блогов или сайтов, посвященных хобби, это может быть и несущественно, но пользователи корпоративных сайтов захотят получать более подробный анализ, поэтому, прежде всего, стоит начать с рассмотрения структуры данных, пользователей и отчетов на серверах платформы Google Analytics.

Основообразующим элементом этой иерархии является логин пользователя. Это аккаунт Google или, возможно, логин, который вы используете для Gmail, Google Plus или любого другого сервиса Google. Это всего лишь имя и пароль пользователя, которые вы используете для аутентификации в Google. Это не аккаунт Google Analytics, который является следующей ступенью иерархии. Обратите внимание на то, что можно создать несколько аккаунтов Google Analytics. Следующими уровнями иерархии являются веб-ресурсы, представления и сами отчеты. Лучше всего это будет понятно на реальном примере, поэтому давайте рассмотрим универсальную конфигурацию.

Первый уровень иерархии - логин пользователя. Заметьте, это необязательно должен быть аккаунт Gmail. Это должен быть аккаунт Google, но мы не рекомендуем использовать Gmail при создании аккаунтов для бизнеса. Все управление ведется на уровне аккаунта: в нем можно наделять пользователей правами доступа, задавать часовые пояса, открывать доступ к настройкам и тому подобное. Но, фактически, самое интересное начинается не на этом уровне, поскольку аккаунт не собирает и не содержит никаких данных. Все самое интересное происходит на уровне веб-ресурсов. Исторически, это самая противоречивая составляющая системы Google Analytics. У каждого из этих ресурсов есть уникальный номер, который мы называем UA-номером.

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

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

Что касается представлений, то раньше они назывались "профилями" (profiles), и я иногда так их и называю, но некоторые считают название "представления" более интуитивно понятным, поскольку, в действительности, это всего лишь вид отображения тех данных, которые содержатся в ресурсах. В основном этими представлениями управляют фильтры, которые вносят небольшие, а иногда и значительные изменения в данные, например, фильтр верхнего регистра или добавление в URL суб-домена. Следующим уровнем иерархии, конечно, являются сами отчеты. В основе отчетов лежат настройки, выполненные на уровне представлений, которые определяют вид отображения данных, содержащихся в ресурсах.

Давайте рассмотрим это на реальном примере. При входе в систему Google Analytics вы увидите экран, подобный этому. Это домашний экран. В первую очередь, я хочу обратить ваше внимание на расположенный в верхней части логин. Еще раз напоминаю, что это либо аккаунт Gmail, либо какой-то другой аккаунт Google, который будет определять доступ к аккаунтам Google Analytics. В этом примере с помощью введенного мной логина я получаю доступ к двум разным аккаунтам. Обратиться к этим аккаунтам можно одним из двух способов: либо посредством папок, либо с помощью расположенного вверху выпадающего меню, которое можно скрывать и раскрывать.

На следующем уровне располагаются веб-ресурсы, увидеть которые можно, раскрыв аккаунты. Под каждым из этих ресурсов находятся представления, в которых расположены действующие отчеты. А теперь вам стоит запомнить некоторые оптимальные приемы. Во-первых, всегда создавайте необработанное, неотфильтрованное представление, которое никогда не будете использовать в работе. Сводные отчеты лучше всего создавать в виде отдельного веб-ресурса. А для тех, кто не знает, что это такое, "сводные отчеты" - это то, что вы получаете, когда пытаетесь собрать статистику с нескольких разных сайтов. Например, если вы - коммерческий директор компании Procter & Gamble, и вам захотелось просмотреть сразу все торговые марки, чтобы сравнить, например, количество пользователей мобильных приложений и веб-сайтов, то вы могли бы создать ряд отчетов, в которые автоматически сводилась бы информация веб-сайтов всех отдельных торговых марок.

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

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

Раньше компания Google позволяла пользователям создавать такое количество представлений, которое значительно превышало установленный первоначально лимит в 15 штук, но недавно они стали строже относиться к этому вопросу. Даже в отношении пользователей с премиум-аккаунтом. Поэтому если ваша стратегия предусматривает создание более 50 представлений, например, для каждой из 75 имеющихся торговых марок, то вам следует пересмотреть свою стратегию. Я надеюсь, что после знакомства с внутренней структурой Google Analytics, вы сможете эффективнее конструировать свой аккаунт, что позволит воспользоваться всеми преимуществами Google Analytics и избежать некоторых проблем. Приведенная здесь иерархия будет иметь особую важность при изучении прав доступа пользователей, а также при определении того, на каком уровне иерархии необходимо назначать права доступа.