Что такое User ID?

Технически - это дополнительный идентификатор, который позволяет объединить в одну цепочку взаимодействия одного пользователя, сделанные им на разных устройствах. Иначе говоря, User ID объединяет несколько Client ID.

Разберемся с определениями:

Client ID - это анонимный и временный идентификатор экземпляра браузера, который представляет собой случайное число, записанное в куки.

User ID - персональный и постоянный идентификатор, под которым в вашей внутренней системе хранится как персональная информация о конкретном пользователе (ФИО, телефон, email, номер карты), так и вся история взаимодействий пользователя с вашим бизнесом. (Когда и какие товары покупал, когда он звонил, какие письма ему отсылались, и т.д.)

В подавляющем большинстве случаев бизнес интересуют именно пользователи (Users), а не сессии от анонимных устройств, статистику по которым вы получаете, установив Google Analytic "из коробки". При создании экосистемы GA предполагалось, что User ID нужно начинать использовать при первой же возможности. Так почему же качественно проработанная система присвоения User ID на сайтах встречается еще реже чем электронная торговля?

Очевидная причина - трудозатраты. Внедрить базовый код отслеживания на порядок сложнее, чем реализовать User ID.

Вторая причина - сама реализация User ID в GA выглядит сделанной "на коленке", в стороне от основного процесса базового внедрения. По умолчанию функция выключена. При включении функции User ID, GA создаёт урезанное представление, в котором только пользователи с User ID. Вы не можете сконвертировать в User ID ранее созданное представление. Иными словами сконвертировать в User ID ранее собранные данные вы не сможете. Также вы не сможете получить отчеты, в которых бы присутствовала "смесь" из "реальных пользователей" и "браузеров". То есть, улучшить отчеты путем добавления в них функции User ID не получится.

Ниже приведен характерный пример того, как путь одного и того же пользователя по-разному распознается в "обычном" и "User ID" представлении.

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

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

Куда податься аналитику? Решение - получить доступ к сырым данным и строить отчеты по ним.

Третья причина - это сложившиеся среди аналитиков стереотипы и мифы.

Миф первый - для отправки хита в Google Analytics обязательно нужно передать Client ID. Это не так. Для отправки хита нужно передать или Client ID или User ID.

Например, этот хит (без Сlient ID) валиден:https://ga-dev-tools.appspot.com/hit-builder/?v=1&t=pageview&tid=UA-137178440-1&cid=&dl=http%3A%2F%2Fholoway.io%2Ftest%2F&uid=123&dt=TEST

Незнание аналитиками этого факта часто приводит к излишне усложненным схемам передачи транзакций из CRM при помощи Measurement Protocol.

Коллеги, использование User ID на порядок упрощает схему передачи данных из CRM в GA. Об этом - в отдельной статье.

Миф второй - User ID внедряется только для сайтов с авторизацией. И это не так. Как только вы узнаете любую минимальную информацию о пользователе - он перестает быть просто анонимной кукой Client ID и обязан получить User ID. Это значит, что как только вы узнаете email, или телефон, или номер карты лояльности, вы уже можете, нет, просто обязаны сформировать User ID. И не важно, что мы не уверены на 100%, в корректности этих данных (Все врут. (с) Доктор Хаус). Слышали когда-нибудь про exit-polls? Штука в том, что даже если опросить, поверив на слово, людей на выходе из избирательного участка - получаются статистически достоверные результаты. А мы тут статистикой как раз и занимаемся.

Миф третий - нам это не нужно.

Если ваш бизнес сложнее чем эвакуация автомобилей, если вы хоть раз задумывались или уже реализовали передачу статуса сделки из CRM в GA - значит путь вашего пользователя выходит далеко за рамки одной сессии с одного устройства. Скорее всего, у значительной доли ваших пользователей несколько устройств и они с каждого из них совершают несколько сессий, прежде чем в CRM появится выручка или подтвержденный лид. По нашему опыту, ошибка в оценке эффективности каналов с User ID и без в случае чисто он-лайн воронки - это десятки процентов, а в случае, когда у вас есть офф-лайн точки - это разы.

В следующей статье я опишу известные мне кейсы, в которых User ID позволяет существенно увеличить точность оценки эффективности рекламы.

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

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

Итак, бесплатная версия GA (как и GA360) не предлагает "из коробки" адекватных решений по оценке длинного жизненного цикла пользователей, состоящего из длинной цепочки устройств и сессий, среди которых неоднократно встречаются управляемые рекламные каналы.

Какое я предлагаю решение - собирать сырые данные и реализовывать метчинг User ID и атрибуцию самостоятельно. Тем более, что есть решения (например OWOX BI), которые сделают за вас всю грязную работу. Об этом поговорим в следующих выпусках.

Подписывайтесь на мой телеграмм канал: https://t.me/analytics_refined

#holoway #analytics #holowayanalytics #продуктоваяаналитика #аналитика #когортныйанализ