Metric Hive treats the semantic layer as the product contract. Source data is mapped into canonical marketing and commerce entities with explicit grain, date semantics, currency behavior, aggregation rules, and query guardrails before it reaches dashboards or exports.
The semantic layer makes business meaning explicit before data is queried. That reduces dashboard drift and keeps exports aligned with the same canonical definitions.
Metric Hive maps source-specific records into stable business entities such as campaign, ad, product, order, order line, customer, source account, and reporting date.
Metrics are modeled at the level where they are true, such as campaign-day, ad-day, order, order line, customer-day, or cohort.
Marketing, commerce, and finance data can use different date bases, including impression date, click date, order date, refund date, and generated date.
Spend, revenue, fees, COGS, and profit need an explicit currency policy before they can be safely aggregated.
Frontend surfaces request approved dimensions, metrics, filters, views, and export modes. Backend query services keep table names, joins, tenant scope, and metric relationships behind governed contracts.
Datasets expose fields that have semantic metadata, including the entity, grain, metric behavior, and source capability needed to use them.
Metrics such as ROAS, margin rate, CPA, CAC, reach, users, and LTV need denominator and grain rules before they are compared or rolled up.
Account and subscription identity should come from backend authorization and scoped services, not from browser-provided table names or identity fields.
The same semantic contracts support product dashboards and external destinations. Exported data is intended to be modeled and named clearly enough for BI tools, spreadsheets, and warehouse workflows.
Expose governed dimensions and metrics for reporting instead of forcing BI users to rebuild metric definitions from raw connector tables.
Looker Studio, CSV, spreadsheet, and warehouse destinations should receive the same approved field names, grains, and caveats.
Modeled outputs retain source and account context so teams can inspect provenance when a metric needs explanation.
The goal is not only cleaner naming. It is safer analysis across connectors, datasets, dashboards, and exports.
A marketing semantic layer defines canonical entities, dimensions, metrics, grains, and guardrails so reports and exports use the same business definitions.
Metric grain states the level where a row is true, such as campaign-day, order, order line, customer, or cohort. Unsafe joins and aggregations usually start with mixed grains.
Metric Hive exposes governed datasets for dashboards, BI, and exports so downstream tools can use modeled fields instead of raw source fragments.
Open the public library to browse registered connector reports by base entity, grain, time key, canonical mapping, aggregation, and field visibility.