В чем разница двух методов сбора сессий?

В OWOX BI есть два способа сбора данных о сессиях: на основе API Google Analytics и на основе сырых данных о хитах с помощью алгоритма OWOX BI.

Для чего нужен алгоритм OWOX BI

Новый алгоритм позволяет собирать полные и точные данные о поведении пользователей на сайте. Вот его главные преимущества:

1. Алгоритм OWOX BI не зависит от Google Analytics Core Reporting API и собирает данные о сессиях на основе сырых несемплированных данных о хитах.
2. Сбор сессионной таблицы никогда не прервется из-за превышения лимитов GA Core Reporting API или отсутствием доступа к Google Analytics. Не будет задержек из-за долгого импорта сессионных полей из Google Analytics.
3. У алгоритма OWOX BI нет ограничений на объемы собираемых данных. Нет лимитов на 500 тыс. сессий в сутки, 10 млн. хитов в сутки и 500 хитов на сессию — все ваши данные попадут в таблицы Google BigQuery.

С помощью нового алгоритма вы также можете:

• Отследить, был ли прямой переход действительно прямым, а не протянутым с прошлого платного перехода — с алгоритмом OWOX BI это можно сделать с помощью поля trafficSource.isTrueDirect. Таким образом, вы сможете атрибутировать источники сессий одновременно по двум моделям: Last Non-Direct Click и Last Click.
• Объединить аудитории разных сайтов с помощью единого идентификатора OWOX User ID и анализировать их пересечение.

Когда стоит переходить на алгоритм сбора сессий от OWOX BI

• Количество сессий на вашем сайте — больше 200 тыс. в сутки или приближается к этому числу;
• Вы часто сталкиваетесь с семплированием данных в Google Analytics;
• Вы часто сталкиваетесь с лимитами в 500 хитов на сессию;
• Вам важно отслеживать истинный прямой источник сессии с помощью поля trafficSource.isTrueDirect, которое в Google Analytics доступно только при использовании функции BigQuery Export для GA360;
• Вы хотите объединить аудитории разных сайтов с помощью единого идентификатора OWOX User ID и анализировать их пересечение.

Отличия в структуре таблиц

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

1. В полях totals.* ранее находилось количество хитов, собранное в Google Analytics. Теперь в полях totals.* дублируются значения полей totalsStreaming.* — количество хитов, собранное в OWOX BI.
2. Отсутствуют значения для полей visitNumber и newVisits. Данные поля есть в таблицах, однако они пока пустые. Расчет этих значений будет добавлен в следующих обновлениях.
3. Добавлены поля customDimensions, customMetrics, customGroups, однако пока не распределены по области действия — сейчас у всех область действия на уровне хитов. Разные области действия пользовательских переменных будут добавлены в следующих обновлениях.
4. Добавлено поле isTrueDirect, благодаря которому вы можете определить, был ли переход прямым (значение true) или его source/medium протянут с прошлого платного перехода.
5. Присутствует поле userOwoxId (как в таблицах с данными о хитах).

Изменение настроек для включения нового алгоритма

• Если до этого был настроен сбор сессий на основе алгоритма Google Analytics, не нужно менять настройки кода отслеживания. 
  Если не был настроен ни один метод сбора сессий, необходимо модифицировать код отслеживания для сбора SessionID в custom dimension уровня сессии. Сделайте это сразу после настройки сбора данных о сессиях.
• В случае использования авторазметки в Google Ads: с помощью нативной интеграции Google Data Transfer необходимо включить выгрузку сырых отчетов Google Ads в BigQuery для получения данных по авторазметке (с gclid) и указать путь к набору данных BigQuery с этими отчётами в настройках сессионного стриминга. Если используется только ручная разметка (utm-метки), то пропустите этот пункт.
• Поле user.id формируется непосредственно на основании параметра userId (&uid), при этом custom dimension не используется. Потому, если на сайте не настроено отслеживание и сбор &uid, настройте его стандартным способом.

Отличия в сборе данных