How this LookML model wires events, sessions, visitors and web orders
At a glance
Does
Six explores on project_connection: events joined to sessions and visitors, sessions joined to visitors, plus visitors, transactions, transaction_items and session_apps.Trust: Source-defined
Why
The web analytics model for the dating site, in the shape of a Snowplow web package: event, session and visitor tables keyed by cookie id and session index.Trust: Inferred
Each lane is one explore: its base view on the left, joins on the right, labelled with the join key. Dashed edges declare no relationship, so Looker assumes many_to_one.
The events explore joins sessions on domain_userid and domain_sessionidx together, and visitors on domain_userid alone. Both are many-to-one from events.
include: '*.view.lookml' and '*.dashboard.lookml' load the product views and dashboards into this model too, so dashboards resolve explores across both models.
All four joins rely on Looker's default many_to_one. That default is right for these keys, but nothing records it, and sessions and visitors have no primary key.
What goes wrong: Sums from sessions or visitors queried through events repeat once per event with no symmetric aggregate protection.