• Рубрики

  • Архивы

  • Продвижение сайта шаг за шагом

     

    Отслеживание событий в Google Analytics c помощью Google Tag Manager

    Я часто наблюдаю ситуацию, что пользователи, даже «продвинутые» SEO и спецы по контекстной рекламе, ограничиваются настройкой целей по просмотру конкретной страницы. Еще бы… это просто. Настроить цель просмотренной страницы как правило, не вызывает никаких проблем. Настройка отслеживания событий описана не так прозрачно, как хотелось бы. Давайте устраним эту досадную неприятность и опишем инструкцию по настройке таким образом, чтобы любой начинающий смог разобраться. Но для начала проясним один вопрос.

    Зачем вообще отслеживать события, происходящие на сайте?

    Вам важно знать, сколько людей кликает по определенной ссылке? Сколько людей жмет на «добавить в корзину»? Или просматривает фото в вашей галерее? Или щелкает по вкладке, на которой вы указали условия доставки?

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

    В общем виде, очень желательно вешать отслеживание следующих событий в интернет магазине:

    • Клик «Обратного звонка»
    • Клик «В корзину» на разных страницах
    • Клики просмотра фотографий в галерее карточки товара
    • Клики перемещения по вкладкам страницы карточки товара

    Если у вас информация распределена по вкладкам, например «Описание», «Характеристики», «Оплата и доставка», «Отзывы» — вы можете отследить, сколько людей переходит по этим вкладкам

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

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

    Сюда же относится отслеживание использования различных блоков, вроде последних просмотренных, похожих товаров, дополнительных сопутствующих товаров.

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

    Как настроить отслеживание события в Google Analytics через Google Tag Manager

    Далее я подразумеваю, что аккаунты GTM и Google Analytics у вас уже есть, и код размещен на сайте. Если же нет, то сначала установите. Как это сделать, я описывал в предыдущих статьях. Предположим, я хочу установить отслеживание по ссылке «Поменять фон» на сайте интернет-магазина.

    http://joxi.ru/8AnzEe0U3aJXAO

    Первое, что я делаю, настраиваю отслеживание события. В Google Tag Manager жмем «Создать новый тег»

    http://joxi.ru/GrqYj4eFLjPDrz

    По скриншоту: 1 – ставите свой идентификатор отслеживания UA-XXXXXX-1. На скриншоте у меня он установлен, как {{GA}}, куда подставляется нужный мне идентификатор, который я задал в переменной. Можете задать ее, чтобы далее не вспоминать свой идентификатор. Добавляете переменную, выбираете тип «Константа» и указываете значение своего ID.

    http://joxi.ru/KAxYB45FNexLr8

    Далее 2 – указываете тип – «Событие», 3 и 4 задаете произвольные имена категории и действия события, которые будут передаваться в Google Analytics. В моем случае я указал Категорию «Поменять фон» и Действие «smenit_fon», название которых мне однозначно говорит, что именно это событие значит.

    Этим действием вы установили, что такое событие бывает в принципе. Теперь нужно дать ему понять, когда именно оно наступает. Кликайте – на создание триггера

    http://joxi.ru/gmvYp4eFOVYzra

    Все поля, кроме того, которое я выделил в рамочку, простые. Надо задать имя триггера и указать, что отслеживаем клики только по некоторым ссылкам. И это самый сложный момент. Надо дать GTM понять, что клик именно по этому элементу запустит наше событие.

    http://joxi.ru/brRezW8uXpKLA1

    Чтобы настроить событие, откройте свой сайт в том месте, где имеется та ссылка, по клику на которую вы хотите настроить событие, кликните на этот элемент правой кнопкой и выберите «Просмотреть код». Это справедливо для Chrome,Opera,FireFox

    http://joxi.ru/vAWlzaYcwnvjrW

    Далее находим этот элемент в коде. Он должен сразу там стоять по умолчанию.

    http://joxi.ru/KAxYB45FNedDr8

    Обратите внимание, у меня ссылка имеет id= btn-picker

    Таким образом, все, что мне нужно сделать, это выбрать «Переменная уровня данных»  Click ID и указать, что она содержит (или равна) btn-picker

    http://joxi.ru/D2Pez5BuOeMXA3

    Если у вас ссылка не имеет id, но имеет уникальный class, то выбираете триггер Click Classes.

    Сама по себе эта запись означает, что при клике на элемент с таким-то id надо запустить событие, связанное с этим триггером.

    Если же у ссылки нет своего id и нет class, то и в этом случае вы можете настроить событие, надо только выбрать – Click Text и указать, что он равен тому, что написано в ссылке.

    Вот, как это реализовано на том же моем сайте

    http://joxi.ru/823LdPjivy6JAO

    У ссылки нет никаких атрибутов, но я указал, что при клике на ссылку с таким текстом, триггер активируется. Вот оригинал кнопки:

    http://joxi.ru/RmzYE4gFBxWLrO

    После создания нового триггера необходимо опубликовать изменения, которые вы проделали. На рабочем столе, странице, куда вы попадаете при входе в аккаунт сайта в Google Tag Manager появится красная кнопка «Опубликовать»

    http://joxi.ru/bmoYE4OFZ0nnAy

    Жмем и проходим процесс с помощью далее. Рекомендую перед каждой публикацией делать комментарий, что именно вы установили.

    Итак, после того, как вы все это проделали, на следующий день в Гугл Аналитикс появятся следующие отчеты (если события все же наступили)

    http://joxi.ru/52ang7QTjwE9A0

    Находится это в разделе «Поведение»-«События» и там начнут отображаться те события, что вы настроили. Уникальные события – это число в рамках одной сессии. По сути, отображает число посетителей, которые это событие активировали.

    Далее. Если вы хотели просто настроить событие на отслеживание, то на этом все – смотрим, наслаждаемся, анализируем.

    Если же вы хотите, чтобы это событие регистрировалось, как цель и было доступно в отчетах по конверсиям, то тогда нужно потратить еще буквально одну минуту при настройке.

    Заходим в настройку целей в Google Analytics, выбираем «Добавить цель»  и гордо устанавливаем тип цели «Событие»

    http://joxi.ru/nAyYv4XFJqjdAZ

    В подробных сведениях о цели указываете именно те же Категорию и Действие, которое вы дали в GTM при настройке отслеживания события. Обратите внимание на скриншот ниже – там те же значения

    http://joxi.ru/nAyYv4XFJqwdAZ

    Именно по ним Google Analytics связывает цель с событием, которое настроено в Google Tag Manager.

    Ну что, не так все сложно? Если сложно понять, пишите комменты или обращайтесь за консультацией – помогу.

     

    Что значит «хороший программист»?

    Я уже неоднократно в своих статьях упоминал о той огромной важности, которой обладает скорость загрузки сайта интернет-магазина. Стоит скорость загрузки страниц уменьшить с 0.5 до 3-4 секунд, то конверсия падает в РАЗЫ. Вы осознаете это? Вдумайтесь очень внимательно! Это значит, что если страницы грузятся более 4 секунд, то ваш доход будет в 3-8 раз ниже. А это разница, которая может поставить крест практически на любом бизнесе.

    Посмотрите на график ниже. Это зависимость уровня конверсии от скорости загрузки страниц в крупном ИМ (Walmart.com). По ней четко видно, что граница 1-2 секунды, это тот предел, при котором вы будете впереди планеты всей, а как только время загрузки зашкалит за 3 секунды, вы превращаетесь в унылую серую массу.


    Согласно онлайн опросам факты такие:

    • 60% пользователей ожидают, что страница загрузится в течение 3с
    • Около 75% пользователей смартфонов покинут мобильную страницу, если она будет загружаться дольше 5с
    • Те, кто ушел с сайта из-за низкой скорости, скорее всего покинут его, если зайдут другим путем.

    Как правило, скорость работы зависит от выбранной системы управления и от «наворотов» сайта», количества товаров и программиста, который реализует функционал.

    Знаете, как обычно в веб студиях рождается пункт в перечне достоинств, что «Сайт полностью оптимизирован для SEO»? Очень просто! Просто берут и добавляют этот пункт в перечень достоинств CMS, на основе которой создается сайт. Еще бы, ведь это утверждают создатели CMS.

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

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

    1) Программист оптимизирует БД

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

    Приведу конкретный пример. Как-то ко мне попал в руки интернет-магазин, у товаров которого было 45 различных свойств: материал, страна производства, оптовые и розничные цены, вес, размеры, количества на разных складах, наличие специальных атрибутов и куча других… Под все эти свойства по умолчанию резервировалась строка в 256 текстовых символов. Время загрузки страницы, которое по куче параметров (по фильтру), выдергивало нужные товары, составляло около 20 секунд. Товаров было более 50тысяч, свойств много, код ужасен. В результате время загрузки было такое, что пользоваться сайтом было нельзя.

    После оптимизации одной ресурсов одной только БД, время загрузки упало до 11-12 секунд. В два раза!
    Этим обычно никто не заморачивается. А надо.

    2) Программист должен ломать голову, чтобы использовать функции и программные решения, которые выполняются быстрее всего и не грузят сервер.

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

    Оптимизация этих процессов в нашем примере сократила время загрузки страницы до 3 секунд

    3) Программист должен ломать голову, что из «якобы» нужных динамически обрабатываемых вещей можно убрать в статику и не трогать.

    В примере с этим несчастным сайтом, фильтр в зависимости от выбранных значений, считал по остальным параметрам количество товаров, которые выведутся, если выбрать тот или иной вариант по свойствам. Когда значений свойств немного – это не страшно. Но что делать, если их несколько сотен? Возможно, иногда стоит пренебречь динамическим расчетом только по этому параметру, если это дает заметный выигрыш в скорости. Когда мы убрали динамический расчет по параметру кучи брендов, то время загрузки страницы сократилось до 1.2-1.3 секунд.

    4) Программист должен кешировать все, что возможно.

    Кэширование – это запись результатов исполнения скриптов в статические файлы, из которых отдается информация без необходимости повторно выполнить скрипт.

    Те страницы, которые грузились за 1.2-1.3 секунды, при повторном обращении к ним, выдавались частично из кэша и скорость формирования страниц составляла 0.3-0.6с.

    А это, при отсутствии на сайте тяжелой графики, уже давало полное время загрузки у клиента в пределах 1 секунды, что являлось очень хорошим результатом.

    Стоит ли говорить, что разница в конверсии, не заставила себя ждать?

    Так вот. Хорошие программисты – это редкость. И если вы найдете таких, которые сами радеют за то, чтобы сайт работал как можно быстрее, держитесь за них. Это будет значить очень хорошую инвестицию в проект.
    То, что разработчиков и программистов, которые борятся за каждые 10мс загрузки не так много, это одновременно проклятье и огромный позитив.

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

    Adblock detector