Organizing Marketing Information for Self-Service
Why self-service BI projects quietly fail
Most self-service analytics rollouts don't fail because the tool was wrong — Looker, Tableau, and Power BI are all capable platforms. They fail because the data underneath was never organized for a non-technical audience to interpret correctly. A field called status_cd with values A, P, C means nothing to a marketer, who either guesses, asks someone, or — worst case — builds a campaign segment on a wrong assumption and never finds out. Organizing marketing information is the unglamorous work that determines whether self-service actually works or just moves the confusion downstream.
Naming conventions as infrastructure
A consistent naming convention isn't bureaucracy, it's load-bearing. Tables, fields, and metrics should follow a predictable pattern that lets someone unfamiliar with a specific table guess correctly what a neighboring one contains: dim_customer, dim_product, fact_orders, fact_email_sends tells you immediately which are descriptive dimensions and which are event-level facts. Metric names should encode their grain and time window explicitly — revenue_90d instead of revenue, so a marketer isn't left guessing whether a number is lifetime, trailing-12-months, or year-to-date.
Ambiguous vs. self-service-ready naming
| Ambiguous (breaks self-service) | Self-service-ready | Why it matters |
|---|---|---|
| status_cd | lifecycle_stage | Business term instead of system code |
| amt1 | revenue_trailing_90d | Encodes meaning and time window |
| flag | is_email_subscribed | Boolean intent is explicit |
| cust_tbl | dim_customer | Table type (dimension) is discoverable |
| dt | last_purchase_date | Specific, not generic |
Business glossaries
A business glossary is the single document (or, better, a living tool like a data catalog) that defines what each business term means in plain language, independent of any specific table or field — "active customer: has placed at least one order in the trailing 90 days," "churned: no purchase or login activity in 180 days." Without a glossary, every team ends up with its own private definition, and the first time two reports disagree on "active customer" count, trust in self-service data erodes for everyone, not just the team that got it wrong.
The glossary should outrank the dashboard
Semantic layers: the glossary, enforced in code
A semantic layer (dbt's metrics layer, LookML in Looker, Power BI's dataset model) takes the glossary's definitions and encodes them as reusable, version-controlled logic sitting between the raw warehouse tables and whatever BI tool a marketer opens. Instead of every analyst writing their own CASE WHEN logic to compute "active customer," the semantic layer defines it once, and every report, dashboard, and self-service query inherits the same definition automatically.
This is what actually makes self-service safe: marketers can slice and filter freely, but the underlying business logic — what counts as a conversion, how revenue is attributed, what "active" means — is centrally governed and can't drift per report.
Raw warehouse tables
|
v
Semantic layer (metric + dimension definitions, version-controlled)
- active_customer := orders in trailing 90 days
- revenue_90d := sum(order_amount) where order_date >= today - 90
|
v
BI tool (Looker / Tableau / Power BI) <-- marketer builds filters here
|
v
Every dashboard and self-service query inherits the SAME definitionA semantic layer without an owner decays fast
Documentation as a discoverability problem, not a compliance checkbox
Field-level documentation (what a column means, where it comes from, how often it refreshes) is often treated as something to write once for an audit and never touch again. Reframe it as a discoverability problem instead: can a marketer who has never seen a given table figure out, unaided, whether it's safe to use for their campaign? If the answer requires asking someone, the documentation has failed regardless of whether it technically exists.
What's next
Naming conventions, glossaries, and semantic layers organize data at the schema level. The next module takes this further and shows how to build a complete information map — a practical inventory of where every piece of marketing data actually lives.
Next: Building a Marketing Information Map →
I build these systems professionally.
Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.