Skip to content
English
Contact us
  • There are no suggestions because the search field is empty.

Analytics Dashboard in CXT (e-Courier model) that connects to CXT data set

💁‍♂️ Problem / Context

CXT currently has no analytics dashboards, while e-Courier already operates mature Metabase dashboards backed by Snowflake views.
Leadership has decided to pursue a fast-time-to-value approach for CXT by reusing e-Courier’s dashboards rather than building a new analytics platform immediately.

To achieve this, CXT must supply a Snowflake view whose schema, column names, data types, semantics match the e-Courier analytics view powering the existing dashboards.
Metabase will then clone e-Courier’s dashboards and simply point the copies to the CXT Snowflake data source—allowing dashboards to work out of the box with no redesign.

This requires:

  1. Reviewing the list of fields used in e-Courier’s dashboards.

  2. Assessing whether CXT has equivalent data available in its OLTP databases.

  3. Identifying data gaps and determining how to derive or engineer missing fields.

  4. Building data pipelines from CXT Azure SQL → Snowflake → transformed analytics view.

  5. Ensuring the final Snowflake view for CXT is schema-identical to e-Courier’s.

This approach delivers dashboards quickly while minimizing engineering and product effort.

 

Resources:

📖 User Story

As a CXT Client Portal user,
I want access to operational analytics dashboards,
so that I can monitor performance and make data-driven decisions without exporting data manually.

🎨 Design

  • No new dashboard design required—Metabase dashboards will be cloned from e-Courier.

  • The required schema is defined by the e-Courier Snowflake analytics view provided in the data-field export.

  • Transformation logic must produce a final Snowflake view for CXT matching that schema exactly.

🉑 Acceptance Criteria

  • Complete mapping between e-Courier required fields and CXT source fields.

  • All data is injected into Snowflake and data is there

  • Snowflake views are being produced with CXT data exactly like ecourier data.

  • Metabase connects to Snowflake and uses CXT data to power the dashboards successfully.

 

🉑 Scope & Phasing - DATA

Phase 1 — Demo Readiness (Current Scope)

Data Flow

  • One-way, read-only data flow: CXT → Snowflake → Metabase

  • No write-back or mutation of CXT data

Order Coverage

  • On-demand orders only

Data Model & Contract

  • Snowflake views schema-identical to e-Courier analytics contracts

  • Field-by-field mapping validated between:

    • CXT operational data

    • e-Courier analytics schema

  • Required transformations and resolved data gaps included

  • Supporting datasets:

    • Customers

    • Drivers

    • Services

    • Sites

Dashboards

  • Clone and reuse existing e-Courier Metabase dashboards

  • Preserve:

    • Charts

    • Metrics

    • Filters

    • Naming and semantic meaning

  • Minimal or no dashboard redesign

Tenancy & Access

  • Tenant-aware dashboards (per courier company)

  • Access via redirect from CXT Operations to Metabase

Validation & Demo Enablement

  • End-to-end validation using:

    • Sample data

    • Controlled production data (read-only, privacy-compliant)

  • Demo-ready visual fidelity and correctness

Phase 2 — Future Considerations (Non-Blocking)

Potential Inclusions

  • Routed orders

  • CXT-specific dashboards and KPIs

  • Deeper in-app analytics embedding

  • Performance tuning and refresh optimisations

🉑 Risks & Mitigations

  • Data usage variability

  • Customer-specific workflows and data entry patterns may differ from assumptions embedded in existing e-Courier dashboards. When CXT data is visualised in Metabase, discrepancies such as unexpected nulls, unexpected value types, skewed metrics, or filter/join inconsistencies may appear.

  • Impact

  • These discrepancies may require targeted adjustments to Metabase queries, filters, or calculated fields to ensure accurate and consistent dashboard behavior, potentially introducing iteration during validation.

  • Semantic differences

  • Even with schema parity, semantic differences in how fields are populated or interpreted across tenants may surface, leading to metric inconsistencies between customers.

  • Mitigation approach

  • Validate early using both sample and controlled production data, review dashboards with live data connected, and apply minimal, scoped Metabase adjustments while preserving overall structure and semantics.

  • Demo readiness

  • Final demo tenants will be selected only after data behaviour is understood; fallback to known-good sample data remains available to reduce demo risk.

🙅‍♂️ Out of Scope

  • Fabric/Lakehouse, Azure ML, long-term data platform selection.

  • Redesigning dashboards or changing KPI definitions.

  • Unifying or merging CXT and e-Courier operational schemas.

🉑 UX, Enrollment & Commercialization

This Epic delivers a phased analytics experience, balancing short-term delivery with a clear long-term product vision.

🎨 1. User Experience (UX)

Phase 1 – Initial Experience

  • A new “Premium Analytics” button is added top left to the multiple dashboards top menu in the Dashboard section in the navigation, both in Classic app and the web Operations app.

  • Clicking Premium Analytics opens the Metabase instance in a new view/tab. (if enabled)

  • The user logs in using a separate Metabase account (email + password).

  • Once authenticated, the user sees:

  • prebuilt analytics dashboards,

  • data filtered and scoped only to their CXT account (tenant).

  • Dashboards are read-only.

This phase prioritizes speed and functional validation over seamless UX.

 

Phase 2 – Seamless Experience (Future)

  • Analytics is integrated via Metabase Embedded Analytics SDK.

  • Seamless login using SSO (no separate Metabase credentials).

  • Dashboards render directly inside CXT Operations.

  • Authentication, tenant scoping, and permissions handled automatically.

🉑 2. Enrollment & Activation

Phase 1 – Manual Enrollment

  1. Customer submits an Analytics request via Account Management (AM).

  1. Customer signs the required contract addendum.

  1. AM requests activation from SysOps / SaaSOps.

  1. SysOps performs manual provisioning:

  • Create / configure the Snowflake DB connection.

  • Provision or configure the Metabase instance.

  • Create a Metabase user (email + invitation).

  • Associate the user with the correct tenant-specific data scope.

  • Enable the Analytics button for the customer in CXT Operations.

This process ensures controlled rollout and minimizes operational risk.

Phase 2 – Self-Service Enrollment (Future)

  • Analytics is offered via CXT Marketplace.

  • Customer can:

  • activate Analytics themselves,

  • accept terms digitally,

  • gain immediate access.

  • System automatically provisions:

  • Metabase access,

  • data source connections,

  • permissions and tenant scoping.

  • No manual SysOps intervention required.

📖 3. Billing & Commercial Model

Phase 1 – Manual Billing

  • Analytics is treated as a sellable feature.

  • Billing and entitlement tracking handled manually by Account Management.

  • No automated billing enforcement in the product.

  • Usage tracked operationally (outside the platform).

Phase 2 – Automated Billing (Future)

  • Analytics becomes a formal paid add-on.

  • Billing automated via HubSpot billing integration.

  • Entitlements enforced by the platform.

  • Account Management oversight remains, but manual tracking is removed.

📖 Summary

  • Phase 1 delivers a functional, sellable analytics experience quickly using manual enrollment and billing for FMM event mid Feb 2026.

  • Phase 2 evolves the experience to a fully integrated, self-service, and automated model.

Additional notes:

Linked epic: https://cxtsoftware.atlassian.net/browse/DPE-46