Dashboard manual

Overview

Ecometry, Data Collector and IAM are the internal stack that sets up and governs data extraction. The extracted data then runs through a large transformation pipeline (dbt models) that computes every KPI and measure, and the results are presented to clients in the dashboards (the dashboard-frontend product).

Dashboards are not hard-coded: they are assembled from configuration that lives in Ecometry. Two surfaces matter — Settings → Dashboard applications (the structure of each dashboard) and Clients → Data groups → Dashboard sections (which dashboards a given client can open). This manual explains the products that consume that configuration and the rules that govern it.

The Maestro products

Where you configure it

• Dashboards are configured in Ecometry in two places: Settings → Dashboard applications (the structure) and Clients → Data groups → Dashboard sections (who sees what).
• All this configuration flows out of Ecometry, through the dbt transformation pipeline, into the client dashboards (dashboard-frontend).

What builds a dashboard

• A dashboard application contains dashboard groups → sections → tabs → panels.
• Each section is Built-in or Custom; a Custom section needs at least one definition entry (for example a Looker or embeddable id).
• Each tab points to one dashboard by id — either a Looker id or an Embeddable UUID. Looker tabs have no panels; only Embeddable tabs may have panels (and panels are optional).
• A tab can name a filter set (e.g. "Range_Basic") that decides which filters appear on it; leave it empty for no filters.
• Position/order fields set the order of applications, groups and sections; labels can be translated per language.

What a client sees (data groups)

• A client's data group decides which sections and applications open for them — sections are assigned to the data group (with an order), and whole section groups can be assigned at once.
• A data group is typed BRAND or AGENCY: BRAND attaches sections directly; AGENCY attaches sections per retailer, so each retailer can surface different dashboards.
• The data group lists the countries and retailers it can access — that scopes everything the client can open.
• A data group can't be deleted while it is still used (by users, dashboard sections, targets, store-extraction types or categories).

Brand vs Agency dashboards

• A data group is typed Brand or Agency, and the type decides how dashboard sections are attached and how the client is scoped.
• Brand — sections are attached directly to the data group (Clients → Data groups → Dashboard sections), giving one consolidated view across the client's scope, with no forced retailer filter. Used for brand-scoped products (e.g. Market Share, Digital Shelf or CMI for a single brand).
• Agency — sections are attached per retailer (Retailers → Dashboard sections), so each retailer can surface different dashboards and the client picks a retailer to view it. It is "Agency" precisely because retailers differ. Used by Retail Media (RMM / RMMS), where data is syndicated and sold per retailer.
• To set up a Brand dashboard: in the client's data group, assign the dashboard sections (and whole section groups) it should expose, give them an order, and set the countries it covers — those become the dashboards the client can open.
• To set up an Agency dashboard: open each retailer and define its Dashboard sections (which dashboards that retailer surfaces); the agency client then sees, per retailer, the sections configured on that retailer.
• Why an Agency dashboard needs a client-retailer-tag: Agency views force a country + retailer filter, so the client must be linked to the retailers (and their categories) it is entitled to. The client-retailer-tag defines those retailer & category options and feeds the dashboard's retailer and category filters — without it the Agency dashboard has no retailers to scope to.

The data behind it (cubes, rules, scopes)

• Cubes are the analytics datasets (e.g. Sales, Share of Shelf); each is bound to a data group, which decides what data a dashboard can query.
• Rules are Maestro-AI prompt instructions; they apply globally or to a specific client/data group, only verified rules are used, and scopes narrow when each rule applies.

Filters & access at view time

• Agency dashboards force country + retailer filters from the page (plus category, except the CMI3 app); Brand dashboards add no mandatory context filters.
• Filters and data are scoped per client + data group + user and enforced server-side, so a client can never see data outside its data group.

Client enablement

• The Category and Discovery section sets are mutually exclusive — clients get Category by default; Beauty and Toys clients get Discovery instead.

Dashboard sections catalogue

The standard top-level section sets a client's data group can expose:

Where the dashboard gets its data

The client dashboard (dashboard-frontend) is a thin layer — it reads everything from backend services:

The dashboard does not call backoffice-api directly. The client, retailer and dashboard configuration it relies on is set up in Ecometry / backoffice and reaches the dashboard through the Visualization API (and the dbt pipeline).

Creating a dashboard

1. 1Request. A ticket from Customer Success, a client, Product or Sales captures the business context, goal, priority and main KPIs.
2. 2Mockup. An initial mockup is built (in Lovable) following the storytelling, visualization and hierarchy standards.
3. 3First validation. Reviewed with the Product Owner and Product Manager before any build.
4. 4Build. Built in Embeddable, validating large and small screens and coordinating dataset/filter needs with Frontend early.
5. 5Internal release & pilot. Released behind Shalion-only visibility, then piloted with one large and one small client (e.g. Danone ES, Coca-Cola LATAM) to validate filters, data volume, performance and visualization.
6. 6Visualization review. A second Product/Visualization member reviews the visualization.
7. 7Data QA. Data validated via the Cube Playground, Snowflake queries and filter checks.
8. 8Final approval. Signed off by the Project Owner and Product Manager before going live.

Behind the scenes (dbt & Snowflake)

• All dashboard configuration originates in Ecometry and is replicated (via Airbyte) into Snowflake staging models: dashboard application, group and section, plus the data-group, retailer and cube bindings.
• dbt builds the marts (e.g. market share, digital shelf) and tags each row with its data group and dashboard type, so dashboards can slice the data correctly.
• A cube's dashboard type acts as a domain boundary — cubes are only queryable by data groups of the same domain.
• A section's type decides which visualization engine renders it; new dashboard + data-group + cube combinations need no code change, only configuration.