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

Видео урок: Обновление 2013 года для управления пользователями

Советы по Google Analytics

Сегодня мы собираемся рассмотреть одно из самых последних обновлений Google Analytics. Это обновление является одним из самых востребованных командой Google, поскольку целью его является совершенствование процесса управления пользователями. Со времен создания Google Analytics в ней использовалась знакомая многим из вас и унаследованная от Urchin модель, продемонстрированная на этом скриншоте. При такой модели было возможно только два варианта. Вы были бы пользователем с правами только на чтение, либо администратором с абсолютно неограниченными правами, и другого варианта было не дано. На сегодняшний день наделять пользователя правами администратора очень опасно. Администратор мог бы корректировать настройки аккаунта и параметры пользователей.

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

Другими словами, управляли фильтрами, настройками, источниками данных и тому подобным. Компания Google прислушалась к этим отзывам. Не должно быть так, чтобы было все или ничего, а два варианта редактирования не должны соответствовать двум разным уровням прав доступа. Давайте посмотрим, как это происходит в новом интерфейсе. Для этого я могу войти в мои аккаунты, перейти к представлению "Стандартные отчеты" (Main Reporting), нажать на вкладку "Администратор" (Admin), в которой находится пункт "Управление пользователями" (User Management). Эти 4 уровня были выделены из подхода "все или ничего". Стоит отметить, что необязательно нужно использовать все 4 варианта сразу, поскольку один из пользователей может управлять другими пользователями, но при этом необязательно должен вносить изменения в аккаунт.

Теперь уже добавлять и удалять других пользователей могут пользователи, наделенные правами управления пользователями. Поэтому считайте, что эти пользователи выступают в роли системных администраторов, при этом они необязательно должны обладать какими-то другими правами. А если у пользователя есть разрешение на внесение изменений, то он может не только считывать, но и редактировать настройки отчетов, веб-ресурсов и представлений. Этот пользователь может управлять целями, применять к представлениям фильтры, а также многое другое. В этом плане вариант "Совместное использование" (Collaborate) похож на вариант "Чтение и анализ" (Read and Analyze), поскольку с такими правами пользователь не может вносить большинство из обсуждаемых ранее изменений. Но если с разрешением "Чтение и анализ" пользователь может только создавать и открывать общий доступ к своим персональным объектам, например, к примечаниям, хранящимся в виде комментариев, то разрешение "Совместное использование" позволяет пользователю редактировать общие объекты,

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

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

Например, если я на уровне аккаунтов предоставлю пользователю права администратора, то эти разрешения распространятся на ресурсы и представления. После этого я уже не смогу сделать так, чтобы кто-то мог вносить изменения по всему аккаунту, но при этом на уровне представлений обладать разрешениями только на чтение и анализ. Это не имело бы никакого смысла. Однако я мог бы предоставить кому-то разрешения на просмотр всего аккаунта. Но даже если конкретному веб-ресурсу или представлению предоставлены права администратора, я все равно могу применить на этих уровнях более строгие разрешения, к примеру, "Изменение" или "Управление пользователями".

Поскольку на словах понять это сложно, давайте посмотрим, как это работает в реальной жизни, добавив на каждый уровень нового пользователя. Вернемся обратно в мой веб-браузер. Добавим моего коллегу Дейва Бута, которого вы, возможно, знаете по другим курсам lynda.com. Сейчас мы находимся на уровне аккаунтов, и я хочу убедиться в том, что Дейв может использовать общие объекты аккаунта. Сейчас я это и проверю. Кроме того, я в курсе, что Дейв может слегка увлечься. Поэтому боюсь, мне придется отстранить его от управления пользователями. На данный момент ему нужно внести некоторые изменения, но только в определенные представления, поэтому пока мы опустим редактирование, перейдем на следующий уровень и будем применять эти разрешения по отдельности.

Я добавляю пользователя. Для начала я аннулирую эти изменения и смогу увидеть то, что мы получили при этом на уровне аккаунтов, ресурсов и представлений. Мне нужно перейти на соответствующий уровень представлений. Для этого давайте перейдем к представлению "Стандартные отчеты" (Main Recording). Выберем пункт "Управление пользователями" (User Management). И увидим, что Дейв уже находится в этом списке, а разрешения унаследованы от уровня аккаунтов. Я могу пойти дальше и добавить все необходимое для того, чтобы Дейв смог редактировать свой профиль. Затем я могу перейти к другому представлению. Например, к Z-Test/Sandbox. И, возможно, мне захочется, чтобы Дейв мог добавлять в это представление разных пользователей.

Но это не принесет мне никаких неудобств. Поэтому к этому представлению я могу применить разрешения "Управление пользователями" и "Изменение". Однако я не хочу, чтобы кто-либо применял к необработанным данным фильтры или делал что-то, что может нарушить их целостность. Я хочу убедиться, что эти данные останутся неизменными, за исключением разрешений "Управление пользователями" и "Изменение". Если вам когда-либо захочется вернуться обратно и проанализировать какие-то настройки, просто применяйте их к разным представлениям. Вы можете перейти к уровню аккаунтов и нажать по имени пользователя. При этом будут продемонстрированы все возможные наборы разрешений для этого пользователя на разных уровнях.

Таким образом, в этом примере для аккаунта установлены разрешения "Совместное использование" и "Чтение и анализ". Но для каждого из продемонстрированных здесь представлений установлены свои собственные индивидуальные разрешения. Несмотря на небольшую сложность, возникшую в результате применения дополнительных опций, думаю, вы поймете, что в плане структуры и разрешений этот пример гораздо точнее соответствует реалиям большинства организаций и бизнес-предприятий.