In Bright Analytics, metrics can be built from metrics, which can be built from metrics – to arbitrary depth. The system resolves cross-platform queries, dimension dependencies, and recursive substitutions automatically at runtime.
Example. You can define Cost per Sale (CPS) as Cost / Sales.
Everything underneath – handling the data from multiple source platforms with their own schemas and granularity-dependent metric definitions – is handled for you.
A typical metric – say cost from a single platform – is based on a SQL snippet: SUM(your_data_table.cost).
In Bright Analytics we use an internally designed DSL (Domain Specific Language) which features dynamic tokens so that changes in characteristics of the underlying data model do not break reports.
The above metric might look like this: SUM({F1}). At runtime your_data_table.cost is substituted for {F1}.
Most reporting platforms support calculated metrics. Alongside your catalogue of base metrics, you can design metrics such as CTR or CPA where the metric is made up of a calculation based on two other metrics: SUM({F1}) / SUM({F2}) etc.
In Bright Analytics you can take the substitution a level deeper: {M1} / {M2} where M1 is cost and M2 is conversions.
This means Metric 1 (Cost) = SUM({F1}), Metric 2 (Conversions) = SUM({F2}), and Metric 3 (CPS) = {M1} / {M2}.
Now you can change the definition of M1 or M2 without having to update M3. And you can keep building deeper, creating complex composite metric trees with many levels of hierarchy.
Where Bright Analytics goes further is in providing facilities for mixing and matching of metrics and fields and the configuration of deep trees of submetrics to create complex cross-datasource metrics with minimal configuration effort. You can nest metric references arbitrarily deep, and the system resolves the full dependency tree at runtime based on the report context, taking into account dimension splits and filtering.
This exists alongside multiple metric definition capabilities for dynamic handling of different datasource granularity levels. Crucially, all metric types – base, calculated, or composite – are treated equally. If a metric is compatible with your report structure, you can use it, regardless of the underlying complexity.
The illustration below shows how an example composite metric – Cost per Sale – resolves at runtime.
The Materialised Formula box shows what the formula actually looks like when Cost Per Sale is expanded. The simple Cost / Sales definition becomes a complex cross-platform aggregation, resolved automatically based on the report context.
The Materialised Formula is then expanded further into a number of SQL queries that run on the underlying platform data to fetch the data for the Base metrics that make up the Materialised Formula. Note that SQL queries will be determined by the metric definitions that are selected to satisfy the report, where metric definition selection will be determined by the granularity of the report, specifically the compatibility that the chosen dimensions have with the data sources that are referenced by the metric definitions.
The key point is that Cost Per Sale can be defined simply as Cost / Conversions in our Semantic Layer. From then on our system handles all the complexity – cross-datasource queries, dimension-dependent formula selection, and recursive substitution transparently, with amendments to details of submetric formulation or datasource configuration causing no breakage in downstream metric configurations.
Book a Bright Analytics Demo
No hard sell. We want to hear about your current reporting & analytics, any pain points and what is on your wish list. We’ll show what’s possible with Bright Analytics and answer any questions you have.
Book a Demo