Альтернативы Google Analytics: как продолжать использовать технический стек Google и соблюдать GDPR

За последние пару лет в сфере маркетинговой аналитики произошли значимые события, которые повлияли на качество данных и подготовку маркетинговых отчетов. Из-за GDPR, режима согласия и ограничений на использование файлов cookie многие компании сейчас ищут альтернативы Google Analytics. Они обеспокоены тем, что их обычный технический стек Google не гарантирует, что собранные данные будут храниться только в странах ЕС.

Однако изменение стеков технологий болезненно и дорого:

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

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

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

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

Что мы знаем о тех добрых временах?

Сбор данных

• 99,5% специалистов использовали Диспетчер тегов Google для отправки данных куда угодно.
• 85,7% специалистов использовали Google Analytics для сбора данных о сайтах.

Обработка данных

• Почти все использовали ETL и DWH для обработки данных.
• Было действительно легко определить ключи и использовать их для объединения данных и создания любых отчетов, которые вы хотите.

Отчетность по данным

Различные инструменты визуализации данных, включая Google Data Studio и Google Sheets, легко подключаются к хранилищам данных.

Короче говоря, работать с данными было намного проще без всех сегодняшних внешних требований.

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

Браузеры ограничивают использование сторонних файлов cookie

Браузеры и платформы ограничивают время жизни сторонних файлов cookie, установленных сторонним доменом. Это влияет на отображение важных идентификаторов для систем аналитики, таких как Client ID в Google Analytics. Из-за этого значительное количество информации об эффективности рекламных каналов уже в будущем будет недоступно:

• Доля конверсий для новых посетителей будет расти. Однако на самом деле это будут не «новые» посетители, а скорее бывшие «вернувшиеся» посетители, которым был назначен новый файл cookie.
• Доля прямых/отсутствующих конверсий будет расти.
• ROI платной рекламы в отчетах будет иметь погрешность от 10% до 20%. Чаще всего она будет на нижней стороне.

Google Analytics не соответствует GDPR

После вступления в силу Общего регламента ЕС по защите данных (GDPR) пользователи Google Analytics в Европе столкнулись с проблемой. Google Analytics стал незаконным для использования операторами веб-сайтов в нескольких странах из-за решений европейских органов по защите данных, поскольку он не соответствует GDPR.

Теперь компании должны удалить Google Analytics со своих веб-сайтов, иначе им грозят штрафы за нарушение GDPR. Пользователи Google Analytics, работающие в Европейском союзе или обслуживающие клиентов в странах ЕС, должны принять незамедлительные меры, чтобы гарантировать, что никакие личные данные не будут переданы на серверы в Соединенных Штатах, или найти альтернативную аналитическую платформу, соответствующую GDPR.

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

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

Рекламодатели продолжат собирать данные о действиях пользователей, но не смогут определить, какие взаимодействия с рекламой приводят к конверсиям. Средняя доля пользователей, которые отказываются от файлов cookie на веб-сайтах с включенным режимом согласия, составляет 30%. В зависимости от типа сайта эта доля может достигать 40%.

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

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

Сбор данных

• Что мне делать с отсутствием данных из-за GDPR, режима согласия и ограничений на использование файлов cookie?
• Что мне делать с пользователями, давшими согласие, и пользователями, не давшими согласия? Как мне их отличить и получить в отчетах данные, которым можно доверять?
• Какое согласие я должен запрашивать для отслеживания параметров UTM? (Важно отслеживать параметры UTM, чтобы сопоставлять сеансы/конверсии веб-сайта с вашими кампаниями.)
• На какие конечные точки я могу отправлять данные пользователей? (Перепроверьте, какими сервисами вы пользуетесь, прежде чем отправлять туда данные.)
• Какие данные я могу отслеживать для несогласных пользователей?

Обработка данных

• Как я могу убедиться, что данные европейских клиентов обрабатываются и хранятся в странах ЕС?
• Как данные PII проходят через все мои конвейеры данных и преобразования?

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

Отчетность по данным

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

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

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

1. Ознакомьтесь с геоотчетами в Google Analytics.

Вы должны понимать, из каких регионов приходят посетители сайта. Сколько из США против ЕС? Вам обязательно нужно начать работать со странами, откуда чаще всего приезжают посетители. Мы верим, что все знают, где найти свои геоотчеты. Проверьте их и определите список стран, из которых прибывает большинство ваших посетителей.

2. Узнайте о законах о защите данных в регионах посетителей

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

3. Дедуплицируйте требования и расставляйте приоритеты

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

В конце этого этапа вы разберетесь со всеми ограничениями конфиденциальности независимо от того, на какую платформу вы собираетесь отправлять данные. Дело не только в Гугле.

4. Правильно реализовать режим согласия.

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

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

Всем известно, что мы больше не можем просто отправлять данные PII в GA, как делали раньше, даже если данные из GA затем экспортируются в GBQ, а местоположение GBQ установлено в ЕС. Это связано с тем, что законы ЕС гласят, что вы не можете отправлять PII напрямую в GA без надлежащей настройки.

1. Настройте Google Analytics и Диспетчер тегов Google.

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

Сделав вышеизложенное, вы можете обеспечить соответствие GA с точки зрения конфиденциальности и всех правил, предотвратив сбор PII без согласия.

Однако, как только вы настроите все эти настройки в GA, вы обнаружите, что действительно важных данных нет нигде в GA и, соответственно, в Google BigQuery Export.

Мы говорим о детализированных данных о местоположении, некоторых данных PII, которые вам нужны для определенных отчетов, и некоторых пользовательских параметрах, которые используются в качестве ключа для их объединения, например, с данными CRM.

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

2. Настройте отслеживание без файлов cookie на стороне сервера

Вы можете использовать решение OWOX или создать собственное.

Подпишитесь на демонстрацию, чтобы узнать больше о OWOX BI Server-Side Tracking

В любом случае, самое главное в сервере то, что он должен находиться в ЕС. Таким образом вы можете быть уверены, что все данные PII отфильтрованы, прежде чем отправлять их в любую другую службу.

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

3. Настройте диспетчер тегов на стороне сервера

Третья часть — настройка менеджера тегов на стороне сервера. Почему это важно? Потому что вы хотите контролировать все данные, которые вы отправляете не только в свою аналитическую службу, но и во все сторонние рекламные службы (Facebook, Bing).

На этом этапе вы можете разместить диспетчер тегов на стороне сервера в регионе ЕС и отфильтровать все поля PII, такие как IP-адрес. Вы можете отправить только данные, необходимые для каждого рекламного сервиса.

Вот как вы можете экспортировать данные в соответствии с требованиями GDPR.

Если вы по-прежнему сталкиваетесь с возражениями со стороны юристов, скажите: Эй, как мы можем гарантировать, что никто не сможет получить доступ к персональным данным наших посетителей в Google BigQuery?

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

Честно говоря, мы не встречали ни одной организации, которая все еще сомневалась бы в использовании GCP после того, как они следовали всем этим рекомендациям.

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

Как только вы начнете отправлять данные с согласия (например, с помощью OWOX BI), вы получите специальный параметр, который содержит этот режим согласия.

Вот таблица сеансов. Как видите, у него есть специальное поле ConsentMode, которое содержит значение согласия, предоставленного на веб-сайте.

Чтобы собирать данные для целей аналитики, вы должны получить согласие, и вы можете определить варианты согласия со значением этого параметра ConsentMode. Значения Google Analytics, соответствующие аналитическим потребностям, — G101 и G111. Если параметр gsc имеет одно из этих значений, вы можете собирать свои данные в аналитических целях.

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

Давайте посмотрим, как это работает.

Представьте, что вы не получили согласия. Теперь у каждого обращения будет новый идентификатор клиента и идентификатор пользователя OWOX.

Кроме того, детализированные данные о местоположении будут недоступны. Идея, стоящая за этим, заключается в следующем:

Вы не можете собирать какие-либо данные, которые могут прямо или косвенно идентифицировать человека. Что это за данные? Город, широта, долгота, браузер (имеется в виду дополнительный номер версии и пользовательский агент), все, что можно использовать для снятия отпечатков пальцев, включая марку/модель устройства и т. д.

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

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

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

Было бы здорово иметь специальный инструмент, который показывает все эти преобразования и то, как вы пришли к окончательному отчету, самым четким и поддающимся проверке способом — инструмент, который поможет вам понять, правильно ли обрабатывается ваша PII.

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

Для решения этой проблемы, с которой часто сталкивались наши клиенты, мы создали в OWOX BI наглядный график трансформации, наглядно показывающий, как, куда и почему перемещаются ваши данные. С его помощью можно легко увидеть логику расчета и повлиять на нее:

• Отслеживайте, как данные перемещаются и изменяются от соединителей к информационным панелям.
• Настраивайте и контролируйте преобразования данных и логику расчета метрик в каждом отчете.
• Управляйте преобразованиями SQL в несколько кликов.
• Запланируйте обновление данных, чтобы данные оставались свежими.
• Немедленно увидеть любую ошибку или задержку в обновлении данных.

1. Создайте каталог данных

Во-первых, каталог данных — это способ организации инвентаризации активов данных, особенно тех, которые содержат данные PII. У вас должно быть четкое представление о том, к какому типу данных относится PII. Например, вы можете зашифровать свои данные, хешировать их или расшифровать. Это зависит от того, как вы собираетесь его использовать.

2. Назначьте владельца для каждого актива данных

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

3. Определите безопасность PII на основе столбцов

И последнее, но не менее важное: вы даже можете определить безопасность данных PII на основе столбцов, чтобы определить, хотите ли вы шифровать данные или хешировать их.

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

Следуя рекомендациям из этой статьи, вы сможете:

• Получите все свои данные в Google BigQuery
• Отфильтровать все данные PII для пользователей, не давших согласие
• Избегайте потери данных PII без согласия, чтобы получить итоговые данные и создать сводные отчеты.
• Сообщите своему юридическому отделу, как ваши данные проходят через все конвейеры