Блог

Всем привет! на связи Таня, основатель аналитического агентства Atlant Analytics. Принесла вам полезную историю из рабочей практики — как мы пообещали клиенту запилить отчет за 2 недели, а ушло…1,5 месяца. 

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

Как мы попали в ловушку «простой задачи»

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

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

Сайт на SPA. Яндекс.Метрика не увидела города

Команда стартовала проект и детально изучала запрос клиента. Казалось, всё просто, выделяешь из URL город, локацию и вперед. Но тут мы поняли, что в урле не передаются город и локация. 

Почему так? Дело в том, что сайт работает на SPA. Из-за этого формата он загружается один раз, а далее контент обновляется без перезагрузки браузера. И Яндекс.Метрика не понимает, какой город выбран у пользователя. А нам эти данные нужны для анализа.

Решили передавать город и локацию в пользовательских параметрах визита. Сработало отлично, данные поступали в Яндекс.Метрику, было видно разделение по городам. Мы подумали, что красиво упакуем отчет с графиками и табличками. 

Попытка №1. Ничего не работает

Выбрали очевидный способ — прямой коннектор Яндекс.Метрика и Datalens. Казалось бы, что может пойти не так? Два продукта из одной экосистемы,  коннектор есть. Но нет!

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

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

Попытка №2. Технический ад

У Яндекс.Метрики есть встроенные визуализации. Может, попробовать их? Ох, они не дают отобразить больше 10 строк, а это критично! Городов и локаций по задаче много. Не подходит.

Попытка №3. Яндекс режет данные

Посмотрели API отчётов. Нужные срезы по дням были доступны не полностью: строки, где визитов было меньше 10 в выгрузку не попадали. Мы сначала списали проблему на Яндекс — у них есть правила агрегации, что казалось логичным.

Примечание:

Через пару месяцев выяснилось, дело было в нас. В операторе выгрузки стоял лимит в 150 000 строк — раньше мы в него не упирались, а когда данных стало больше, он молча срезал часть выгрузки. Пока мы собирали отчёт, эта ошибка ещё не была обнаружена.

Работа в итоге заняла три недели вместо двух. Объяснили клиенту, что первый подход не даёт нужной точности, и предложили искать другое решение. Он отнёсся с пониманием. Задача перестала казаться простой — это, наверное, и было главным результатом этапа.

Попытка №4 

Вспоминается песня группы ВиаГра, но до пятой попытки не дошло.
​​

Работать стандартными методами нельзя. Пора подключить тяжелую артиллерию. Стали выгружать logs API. Это детальное API фиксирует каждый визит пользователя отдельной строкой. Далее API отчетов выводит данные сгруппированно, например, по визитам.

Нашли решение для обхода ограничений

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

Для хранения и обработки данных выбрали ClickHouse. Это быстрая СУБД, но она требует прикладной инженерной логики. Взяли ее как источник, который стабильно поддерживается в DataLens, позволяющий оперативно строить графики и таблицы. 

Выбор ClickHouse заведомо создал технические ограничения, поскольку это специфичная СУБД. Многие функции и подходы, привычные в Greenplum или BigQuery, отсутствуют или реализованы иначе. Даже базовые операции типа “разделить строку на массив и сопоставить ключи со значениями” могут требовать нетривиальных решений.

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

Как мы искали выход из технического тупика

Ниже покажу, что делает наша view, и как она стала “многослойной”. Город и локация (arena), напомню, передавались через пользовательские параметры визита. В Logs API они приходили как два поля:

ParsedParamsKey1 — список ключей,

ParsedParamsKey2 — список значений.

Эти строки считываются как массив данных. Чтобы не было искажений,  приходилось:

• очищать служебные символы [ и ],
• приводить экранирование кавычек к удобному виду,
• разбивать строки по запятым,
• приводить к массиву.

Конечно, Greenplum/BigQuery подобные вещи решаются куда проще (JSON/ структуры/ функции работы с массивами). В ClickHouse заняло заметное время из-за особенностей формата и ограничений, но зато у этой СУБД есть другие преимущества. В частности, высокая производительность, возможность оптимизировать базы данных и аналитика в реальном времени;

После парсинга данных я с коллегами поискала индексы ключей и забрала значения из массива значений. Если ключа не было, мы фиксировали not_set. Это действительно важно для отчёта: лучше показать отсутствие данных, чем получить NULL-значения, которые теряются в визуализациях.

Собрали массив страниц Pages: значения ParsedParamsKey2 для элементов, где ключ равен page. Поможет выбрать корректную страницу визита и не переврать данные.

Для отчёта нужно понимать, какая конкретно страница относится к визиту как основная. Из-за особенностей single page application и маршрутизации сайта просто взять первую или последнюю страницу нельзя.

Так что мы заложили прикладную бизнес-логику:

— если в массиве страниц встречаются только /buy и /booking-success, брали первую;

— если есть /booking-success — брали первую страницу после неё, которая не равна /buy;

— иначе брали первую страницу, которая не /buy.

В Logs API цели (GoalsID) приходят списком внутри строки. 

Как мы работали в этом случае:

— “распаковывали” GoalsID в отдельные строки через split + arrayJoin,

— считали количество срабатываний цели внутри визита,

— собирали в итоговую структуру нужные цели (в нашем случае — три ID).

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

Поработав, команда получила два типа показателей:

1. goalXXXX — количество срабатываний цели,
2. visitsXXXX — флаг, был ли визит с этой целью (0/1).

Это важно: конверсию чаще считают по визитам, а “объём действий” — по количеству срабатываний.

Реализовали модель атрибуции «последний значимый переход»  

Пришлось реализовывать модель атрибуции, близкой к атрибуции «последний значимый переход» Яндекс.Метрики. Это сделает отчет более качественным. 

В логах часть визитов разметили как direct/internal/saved. Учли, что в аналитике может не слишком детально отображаться вклад отдельных каналов. Например, ситуация, когда пользователь пришел из рекламы или органики, вернулся прямым заходом и выполнил целевое действие.

С этим учетом в витрине мы исключили direct/internal/saved визиты из “значимых” источников. С помощью оконной функции по ClientID подтягивали последний ненулевой источник и его детализацию в окне ретроспективы. 

Для прямых и внутренних визитов источник заменяли на найденный “последний значимый”. Так аналитика будет более точной и подробной. 

Расчёты приблизились к логике Яндекс.Метрики. Можно избежать ситуации, когда конверсии массово “переезжают” в прямой трафик, и данные противоречат Яндекс.Метрике.

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

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

Запомнили с коллегами этот кейс на будущее. Подключили витрину к DataLens и построили финальные визуализации отчёта.

С какими результатами мы закончили работу

— Со слезами. Шутка!

— Собрали отчет не 2 недели, а 1,5 месяца. 

— Держали клиента в курсе всех изменений срока и сохранили хорошие отношения.

— Получили решение, которое закрывает все задачи клиента.

— Собрали визиты и цели в одну таблицу.

— Добились сходимости с данными Яндекс.Метрики.

— Сделали отчет с простой визуализацией.

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

Было неприятно, что темпы выполнения работы замедлились, но потом мы сфокусировались на глубине и качестве решения для клиента. Написала себе и вам шпаргалку, как не наступить на наши грабли:

1. При оценке сроков задачи проверяйте, не изменились ли технические ограничения, косвенно влияющие на срок работы. Особенно, на срочных проектах.
2. Не верьте SPA-сайтам на слово.
3. Помните про ограничения API Яндекса.
4. Не бойтесь говорить клиенту: «Мы переделываем задачу, чтобы добиться лучшего результата». Клиенту чаще всего это важнее, чем формальный дедлайн любой ценой.
5. Никаких быстрых дешевых решений, если вы любите подробные аналитические отчеты.

С вами была на связи Таня, основатель аналитического агентства Atlant Analytics.. Сохраняйте эту статью — она станет вашим инструментом для работы с отчетностью в Яндекс.Метрики. Она наглядно и структурно дает понять, как собрать качественный отчет с прозрачной аналитикой.