Найти в Дзене
In Data We Trust

Соглашение Google Tag Manager по именованию и структурированию элементов

Оглавление

С погружением в тему настройки инструментов веб-аналитики средствами Google Tag Manager я все чаще встречаюсь с “наследием” других специалистов.

Зачастую это наследие вызывает чувство растерянность. Зная на сколько дружелюбное и классное коммьюнити в сфере анализа данных, понимаю что никто “на зло” не портит жизнь тем кто придет после. Просто каждый работает в привычной ему и его компании системе нейминга и структурирования элементов в контейнерах.

В этой статье приведен вольный перевод статьи “Google Tag Manager naming convention guide ”.

Google Tag Manager naming convention guide
Google Tag Manager naming convention guide

Когда работаешь с Google Tag Manager, или любым другим решением по управлению тегами, обязательно должно быть хорошо продуманное соглашение по именованию элементов. Именование тегов, триггеров и переменных в структурированном легко читаемом виде важно, и будет полезным для всех кто работает в контейнере. В этой статье мы рассмотрим как необходимо называть элементы (теги, триггеры и переменные), но сначала рассмотрим преимущества соблюдения хорошего соглашения об именовании.

Дисклеймер! Само собой разумеется, но всегда просматривайте и отлаживайте изменения и/или дополнения, которые вы вносите в свое рабочее пространство, перед его публикацией. Хорошее соглашение об именовании укажет вам правильное направление и сэкономит время, но в конце концов вам самим нужно убедиться, что все правильно. Никогда не верьте, что элемент в GTM содержит именно то, как он называется.

Преимущества соглашения об именовании

Экономия времени

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

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

Правильно названные элементы улучшают возможность поиска по GTM. Чтобы найти нужный элемент, не придется терять время. А при работе с пользовательскими JavaScript переменными, которые ссылаются на другие переменные, будет гораздо легче понять код, и какой будет результат в итоге.

Список можно продолжать еще долго!

Уменьшение вероятности ошибиться

Если элементы хорошо названы, люди, работающие в контейнере, будут делать меньше ошибок.

Конечно, перед публикацией рабочей области, ее всегда стоит просматривать и проверить на ошибки!

Но, это уменьшит количество итераций прежде чем все ошибки будут исправлены и область можно будет публиковать.

Улучшение опыта настройки тегов

В отличие от описанного выше (экономия времени и уменьшение ошибок), это трудно измерить, но стоит упомянуть.

Намного приятнее работать в контейнере, с хорошим соглашением об именовании. Это день и ночь!

Мы все хотим получать удовольствие от работы!

Как называть теги, триггеры и переменные

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

Общие рекомендации

Когда вы даете название элементам, убедитесь что они:

  • Последовательны;
  • Информативны;
  • И легко читаемы.

Последовательны

Будьте последовательны в том, как называете различные типы тегов, триггеров и переменных в GTM. Например, если вы начинаете названия тегов для событий Google Analytcs с “UA - Events ”, всегда делайте так. Это гарантирует, что эти теги будут сгруппированы в списке тегов, при сортировке тегов по имени. Когда тегов немного это может казаться не таким важным, но с ростом контейнера, это очень полезно. Кроме того, согласованность гарантирует что люди, работающие в контейнере, будут правильно интерпретировать элементы правильно. Допустим, вы обычно заканчиваете название своих тегов доменом, на котором они запускаются (например “SE”). Тогда это ключ к тому, что вы всегда так делаете, и люди могут быстро понять что к чему.

Информативны

Вы должны стараться включить наиболее релевантную информацию в название элементов GTM, чтобы убедиться что любой, кто работает в контейнере, знает назначение конкретного элемента. Например, включите тип, группировку и действие (“UA - Event - Newsletter signup ”) в название тегов, чтобы каждый мог понять что это за тег и что он делает.

Легко читаемы

Убедитесь что названия элементов легко читаются. Совет: используйте тире (“-”) и регистр в качестве разделителя каждой части имени. Например: “GAds - Remarketing - Add To Cart”. Кроме того, старайтесь делать имена короткими, чтобы они не разбились на новую строку, которая сделает контейнер менее читаемым для глаз (но не упускайте релевантную информацию в угоду короткому имени).

Примеры соблюдения соглашения об именовании

Теги

Правильные названия тегов для Google Analytics
Правильные названия тегов для Google Analytics

Хороший способ структурирования имени тега — это “Тип - Группировка - Действие ”. Это гарантирует что самая важная информация о тегах будет включена в их название. Несколько примеров:

  • GAds - Remarketing - Checkout
  • UA - Event - EEC - Purchase
  • Custom HTML - Hotjar

Давайте разберем первый тег, чтобы понять, как строятся имена тегов. GAds (Google Ads) — это тип тега. Затем у нас идет Remarketing, который является группировкой (может быть Remarketing или Conversion for Google Ads). И, наконец, у нас есть действие Checkout. Все это говорит о том, что тег предназначен для отправки данных в Google Ads, данные будут использоваться для ремаркетинга, а отслеживаться событие Checkout.

Если мы посмотрим на второй тег (который имеет тип тега Universal Analytics), то он также включает в себя группу EEC (Enhanced Ecommerce). Это дает нам дополнительную информацию о теге и говорит что он используется для отправки данных электронной коммерции в Google Analytics. Обязательно включайте подгруппу каждый раз, когда это имеет смысл.

Наконец, у нас есть тег “Custom HTML - Hotjar ”. Тут отсутствует метка о действии, так как обычно в каждом контейнере есть только один тег Hotjar, и тогда нет необходимости дифференцироваться с меткой действия.

Триггеры

Пользовательские триггеры событий с простыми для понимания именами
Пользовательские триггеры событий с простыми для понимания именами

Обязательно включайте тип триггера и действие пользователя в имена триггеров. Кроме того, включите область действия триггера, когда это имеет смысл. Областью действия может быть тем доменом (доменами), в которых срабатывает триггер. Например, он может активироваться на домене www.mywebsite.se, но не в других доменах конкретной страны, к которым может быть добавлен ваш контейнер GTM. Давайте рассмотрим несколько примеров имен триггеров, чтобы получить более полную картину:

  • Page View - Order Confirmation
  • Event - Purchase
  • Scroll - 75 % - SE

Мы видим что первый триггер имеет тип Page View, а действие пользователя — Order Confirmation. Другими словами, тег, к которому привязан этот триггер срабатывает, когда пользователь попадает на страницу подтверждения заказа.

Второй триггер имеет тип Custom Event, а пользовательское действие — Purchase. Этот триггер срабатывает когда пользовательское событие покупки передается на уровень данных.

Последний триггер имеет суффикс “SE ”, который говорит нам, что этот триггер, вероятно, срабатывает только тогда, когда пользователь прокручивает 75% страницы на Шведском домене (.se).

Переменные

Название пользовательских переменных
Название пользовательских переменных

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

  • GA Settings — Standard
  • URL — Query — Gclid
  • DLV — ecommerce.purchase.actionField.revenue

Первая переменная имеет тип переменной GA Settings и описание Standart. Эта переменная предназначена для добавления в теги Google Analytics, которые не должны отправлять данные электронной коммерции в GA (часто такие переменные называются как “GA Settings-EEC ”).

Вторая переменная состоит из трех частей: тип, подтип и описание. Тип (URL) говорит что переменная является переменной URL. Подтип (Query) говорит что мы имеем дело с параметром в URL. И, наконец, описание (Gclid) говорит нам, что переменная должна содержать значение параметра запроса, называемого “gclid ”. Пример: httsp://site.ru/?gclid=xxx.

Наконец, у нас есть переменная с типом Data Layer и описанием: ecommerce.purchase.actionField.revenue. Это означает, что эта переменная должна содержать общий доход (который находится на уровне данных) транзакций, происходящих на сайте(сайтах). Описание не соответствует правилам по использованию регистра, который был рекомендован ранее в этой статье, но это обычная практика называть переменные dataLayer таким образом. Но вы также можете назвать переменную чем — то типа “DLV - Ecommerce - Purchas - Revenue”, что тоже довольно информативно.

Резюме

К этому моменту вы достаточно хорошо знакомы с тем, как называть теги, триггеры и переменные в GTM, чтобы гарантировать, что ваш контейнер эффективен и прост в работе, а также что ошибки, отнимающие много времени, сведены к минимуму.

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

Используйте это руководство в качестве отправной точки!