The enterprise LookML model: six explores, 14 joins and no declared relationships
At a glance
Does
Declares six explores on project_connection: churn, transactions, messages, propositions, date_ideas and tests. Together they wire 14 joins across revenue, messaging, proposal and experiment views.Trust: Source-defined
Why
The main analysis model for the dating product. It puts revenue, messaging, date proposals and A/B test metrics in one place, with guard filters on the messaging and proposition explores.Trust: Inferred
Each explore takes the grain of its base view. Two base views, user_transactions and user_metrics, are not in the repo, so those explores have no known grain.Trust: Missing
Source
dating_platform/enterprise.model.lookml78 lines
Explore graph: enterprise
Trust: Source-defined
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.
Explores and joins in enterprise
No relationship declared
Not in the repo
Text version
churn ("Churn Report"): churn
transactions: transactions (not in repo), users (not in repo), subscriptions, user_score
messages (always_filter): messages, sender (users) (not in repo), recipient (users) (not in repo)
propositions (conditionally_filter): propositions, users (not in repo), messages
date_ideas: date_ideas, propositions
tests ("Test Metrics"): user_metrics (not in repo), user_experiment_buckets, tests (experiments), user_tenure_metrics, users (not in repo), user_score, messages
transactions (not in repo) joins (fk transactions.user_id) users (not in repo) (no relationship declared)
transactions (not in repo) joins (fk transactions.subscription_id) subscriptions (no relationship declared)
transactions (not in repo) joins (fk users.id) user_score (no relationship declared)
messages joins (fk sender_id) sender (users) (not in repo) (no relationship declared)
messages joins (fk recipient_id) recipient (users) (not in repo) (no relationship declared)
propositions joins (fk propositions.user_id) users (not in repo) (no relationship declared)
propositions joins (on messages.proposition_id = propo...) messages (no relationship declared)
date_ideas joins (on propositions.proposition_templa...) propositions (no relationship declared)
user_metrics (not in repo) joins (on user_metrics.id = user_experime...) user_experiment_buckets (no relationship declared)
user_metrics (not in repo) joins (fk user_experiment_buckets.experiment_id) tests (experiments) (no relationship declared)
user_metrics (not in repo) joins (fk user_metrics.id) user_tenure_metrics (no relationship declared)
user_metrics (not in repo) joins (fk user_metrics.id) users (not in repo) (no relationship declared)
user_metrics (not in repo) joins (fk user_metrics.id) user_score (no relationship declared)
user_metrics (not in repo) joins (on messages.sender_id = user_metri...) messages (no relationship declared)
Explores in enterprise 6
Trust: Source-defined
Connection project_connection. Includes *.view.lookml*.dashboard.lookml
users (not in repo)fk transactions.user_id, no relationshipsubscriptionsfk transactions.subscription_id, no relationshipuser_scorefk users.id, no relationship
propositionson propositions.proposition_templa..., no relationship
none
L49-54
testsTest Metrics
user_metrics (not in repo)
user_experiment_bucketson user_metrics.id = user_experime..., no relationshiptestsfk user_experiment_buckets.experiment_id, no relationshipuser_tenure_metricsfk user_metrics.id, no relationshipusers (not in repo)fk user_metrics.id, no relationshipuser_scorefk user_metrics.id, no relationshipmessageson messages.sender_id = user_metri..., no relationship
none
L55-78
Filters and exclusions that change meaning
The messages explore always hides welcome messages, spammers and older weeks
Trust: Source-defined
always_filter excludes Messages::Welcome, drops spammer senders and recipients, and sets created_date to last week. Readers can change the values but cannot remove the filters.
conditionally_filter applies status = published unless the query filters on status itself. A count with no status filter covers published propositions only.
Several joins set fields: [] so only keys travel. The sender and recipient joins expose sender.messages and recipient.messages, sets that would live in a users view that is not in the repo.
All 14 joins use sql_foreign_key or sql_on with no relationship, so Looker assumes many_to_one everywhere. The messages join on propositions is really one proposition to many messages.
What goes wrong: Proposition measures can repeat once per message when the messages join is pulled in.
Caution: user_tenure_metrics is joined on a key that is not unique
Trust: Inferred
The tests explore joins it with sql_foreign_key: user_metrics.id, but user_tenure_metrics.id repeats three times per user, once per tenure. fields: [] hides it today.
What goes wrong: If anyone exposes its fields, every user_metrics measure in the tests explore can triple.
Note: The user_score join chains through a missing view
Trust: Source-defined
In the transactions explore, user_score joins on sql_foreign_key: users.id, which depends on the users join. With users missing, the score join cannot be verified.
