Я не могу точно знать, как они это реализуют.
Но поскольку я создал продукт, который извлекает не сэмплированные, не агрегированные данные из Google Analytics, я кое-что узнал о структуре.
Я считаю, что данные заполняются через BigTable.
BT предлагает осведомленность о локализации данных и отображение / сокращение запросов по n-узлам.
Отличный счет
(Независимо от того, может ли служба данных обеспечить различное количество или нет, это простая мера гибкости модели данных, но обычно это также мера стоимости и производительности)
Google Analytics не рассчитана на четкие подсчеты, даже если GA может рассчитывать пользователей практически по любому измерению, но не может подсчитывать, например, Сеансов за га: pagePath?
Как так...
Ну, они только регистрируют сеанс с первым pageView в сеансе.
Это означает, что мы можем только посчитать, сколько посадочных страниц было сессией.
Мы не учитываем все остальные 99% страниц вашего сайта. : /
Причина этого в том, что Google сделал выбор НЕ рассчитывать количество скидок вообще. Это просто плохо масштабируется при обслуживании миллионов сайтов бесплатно.
Они нуждались в подходе, где они могли бы избежать подсчета отличных. Отличительный счетчик - все о сортировке, группировании списков идентификаторов для каждой ячейки в пересечении данных.
Но ...
Разве не просто подсчитать различное количество сеансов по значению ga: pagePath?
Я отвечу на это немного
Пользователь и разделение данных
Выбор, который они сделали, состоял в том, чтобы разделить данные на пользователей (clientIds или userIds)
Потому что, когда они знают, что clientId / userId X присутствует только в определенной таблице в BT, они могут запускать функцию сопоставления / уменьшения, которая подсчитывает пользователей, и им не нужно беспокоиться о том, что тот же пользователь присутствует в другом наборе данных, и вынуждает хранить все clientIds / userIds в списке - группировать их, а затем считать их - отдельно.
Поскольку текущий скрипт отслеживания GA называется Universal Analytics, они должны иметь возможность правильно рассчитывать количество пользователей. Особенно при фокусировке на отслеживании между устройствами.
ОК, но как это влияет на количество сеансов?
У вас есть набор пользователей, каждый из которых имеет несколько наборов сеансов, каждый из которых имеет список посещений страницы.
При подсчете в определенном сеансе в поисках pagePaths вы найдете одну и ту же страницу несколько раз, но не будете считать страницу более одного раза.
Вам нужно записать, что вы уже видели эту страницу раньше.
Когда вы прошли все страницы в этом сеансе, вам нужно только посчитать сеанс на страницу. Эта процедура требует состояния / памяти. И поскольку процесс подсчета, вероятно, выполняется параллельно на одном и том же сервере. Вы не можете быть уверены, что конкретный сеанс обрабатывается тем же процессом. Что делает подсчет еще более трудоемким.
Google решил больше не гоняться за этим кроликом и просто проигнорировал, что счетчик сеансов неверен для pagePath и других измерений области попадания.
"Куб" хранилище
Причина, по которой я пишу «куб», заключается в том, что я точно не знаю, используют ли они традиционную структуру куба OLAP, но я знаю, что для ответа на различные комбинации измерений / метрик заполнено до 100 кубов.
Из-за изоляции / группировки измерений в меньшие кубы данные не будут взорваться экспоненциально, как если бы они помещали все данные в один куб.
Недостатком является то, что не все комбинации данных допускаются. Что мы знаем, это правда.
Например. ga: TransactionsId и ga: eventCategory не могут быть запрошены вместе.
При выборе этой структуры набор данных может масштабироваться очень экономично и с точки зрения производительности