The operations director of a Singapore logistics company asks for a single view of delivery performance. She gets three answers from three tools: the dispatch system, the customer service platform, and a finance spreadsheet. She hires a freelance data person, who builds a set of dashboards in two months. They work. Six months later the freelancer moves on, and the company discovers that the dashboards depend on a set of manual exports, one hard-coded API key, and a spreadsheet only he understood. When a source system changes its export format, everything stops, and nobody in the company can say what needs fixing.

The problem was not the freelancer’s skill. It was that the company needed data engineering — a reliable foundation of pipelines, models, and monitoring — and bought dashboards. This article explains what a data engineering consultant in Singapore actually does, how the role differs from an analyst or a data scientist, the signs that you need one, the cases where you do not, and how to choose between a consultant, a full-time hire, and a fractional arrangement. It draws on the approach used by Engine Analytics, a data analytics company in Singapore that builds data infrastructure for growing businesses.

What Data Engineers Build, and How They Differ From Analysts

The three data roles are often confused. A data analyst answers business questions using data that already exists in usable form, producing reports, dashboards, and analysis. A data scientist builds predictive models, such as churn prediction or demand forecasting. A data engineer builds the infrastructure that makes both possible: the pipelines that move data from source systems into a central warehouse, the models that turn raw records into clean, consistent tables, and the monitoring that catches problems before they reach a report.

The relationship is one of dependency. Analysts and data scientists are only as good as the data they are given, and when that data is unreliable, they spend most of their time cleaning it. A business that hires analysts before it has a data foundation tends to find them doing engineering work badly, and leaving when the frustration builds. The order matters: foundation first, analysis on top.

What a Data Engineering Consultant Does

A consultant’s work usually follows a sequence. It begins with an assessment of the current state: which data sources exist, how data moves between them today, where the manual steps and single points of failure are, and which reports the business actually relies on. From that, the consultant designs a target architecture — typically a cloud warehouse such as BigQuery, ingestion for each source, a transformation layer, and a reporting layer — sized for the business rather than for a hypothetical enterprise.

The build phase covers pipelines for each source, modelling of core business entities and metrics with agreed definitions, automated testing and monitoring, and access controls that fit the organisation’s data protection obligations. A good engagement also covers what surrounds the code: cost management on the cloud platform, documentation, and a structured handover so the client’s team can operate what has been built. A modern transformation layer built with a tool such as dbt, described in our article on how dbt is changing pipeline development, is a common part of this.

What an Engagement Looks Like in Practice

A typical engagement runs in four phases. The first one to two weeks are an assessment: mapping sources, reviewing existing reports, and agreeing which decisions the business most needs data for. The next phase sets the architecture and priorities, including which sources and reports to tackle first. The build follows in order of business value rather than in order of technical convenience — the handful of reports leadership actually uses come before the long tail of nice-to-have sources. The final phase is handover and stabilisation, where the client’s team takes over operation, supported by documentation and working sessions. Throughout, the business should see working output early, such as one reconciled metric in a live dashboard within the first few weeks, not a single reveal at the end.

Signs You Need a Data Engineering Consultant

Certain symptoms reliably point to a foundation problem. Different teams report different numbers for the same metric. Reports depend on manual exports and spreadsheets that one person maintains. Pipelines break when a source system changes and nobody knows until a stakeholder notices. Each new data source takes weeks to integrate because there is no standard pattern. Cloud costs are rising without a clear explanation. Or the business is about to start an AI or machine learning project and has no reliable dataset to feed it. Expanding into new markets is another trigger, because the cost of an unstructured setup multiplies with each additional country and currency.

The common thread is that the business has outgrown ad hoc reporting and now depends on data for decisions, but the underlying structure was never designed. A consultant can assess this quickly and tell you whether it is a small repair or a substantial rebuild — an assessment that is worth having before committing to a full-time hire or a large platform purchase.

When You Do Not Need One

Honest consulting includes saying when the answer is no. A business with one or two data sources, modest volumes, and reports that already agree may be well served by the built-in tools of those systems. If the actual problem is poor tracking on the website, or a lack of analytical skill in the team, a data engineering project will not fix it. And if nobody makes decisions from the data yet, the first need is usually a clear question, not infrastructure. A good consultant will point to these situations rather than sell a project the business does not need.

Consultant, Full-Time Hire, or Fractional: How to Choose

A full-time data engineer makes sense when there is continuous, substantial engineering work — many sources, ongoing model development, and a team relying on the platform daily. A consultant is a better fit for a defined outcome: designing and building the foundation, fixing a broken setup, or migrating to a new platform, after which the workload drops to maintenance. A retainer or fractional arrangement suits the middle ground, where the business needs regular engineering capacity but not a full salary. Many companies use a combination: a consultant to build the foundation and train the team, then a fractional or junior in-house hire to maintain it.

The main risk with consultants is dependency. It is managed by insisting on a few basics: the code lives in your repository, the cloud accounts belong to you, everything is documented, and the handover includes working sessions with your team rather than a folder of files. If a consultant resists any of these, that is a warning sign.

What to Ask Before You Hire

Five questions separate experienced engineering consultants from dashboard builders. Ask how they will document metric definitions, and who owns them. Ask how they test and monitor pipelines, and how you will find out when something fails. Ask what will belong to you at the end — code, cloud accounts, documentation. Ask how they handle data protection, including where data will be stored and who can access it, which matters under Singapore’s Personal Data Protection Act and, for regional businesses, the rules in each market. And ask for examples of similar work, including one where the plan changed and how they handled it. The broader principles a business leader should know are covered in data engineering for business leaders.

Ready to Assess Your Data Foundation?

If your reports disagree, your pipelines depend on manual steps, or you are planning to scale into new markets or AI projects on top of an unstructured setup, the path forward starts with an honest assessment of the foundation. View our data and AI services, explore our engagement plans, see what we have built in our project portfolio, or get in touch and we can review your current data setup and tell you whether you need an engineering project at all.

Engine Analytics is a data analytics company in Singapore that builds the data foundations — pipelines, warehouse models, and audience-specific reporting — that businesses need to make decisions from data they trust.

A marketing manager at a Singapore B2B software company checks Google Ads on a Tuesday morning. The account shows 214 conversions last month at S$62 each. The same afternoon, the CRM shows 71 sales-qualified leads from the same campaigns, because the two systems define a conversion differently. The cost-per-lead figure that reaches the leadership team is built from a spreadsheet where ad spend is copied in by hand each week, so it is always a week old and occasionally wrong. When the CEO asks what a qualified lead costs, three people give three answers, and each of them can defend their arithmetic.

The fix is not a better spreadsheet. It is getting Google Ads data into the same warehouse as the CRM and website data, so that cost, clicks, and conversions can be joined to leads and revenue automatically. This article is a step-by-step guide to Google Ads BigQuery integration — from setting up the transfer to modelling the data so that reports are cleaner and consistent. It draws on the approach used by Engine Analytics, a data analytics company in Singapore that builds marketing data infrastructure for growing businesses.

What You Are Building and Why

The goal is a scheduled, automatic copy of Google Ads reporting data in BigQuery, landed raw and then cleaned into tables that analysts and dashboards can use. There are two broad routes. Third-party ELT tools support many advertising platforms through one interface. Google’s own BigQuery Data Transfer Service, a managed service that copies Google Ads data into BigQuery on a schedule without custom code, is the simplest route for Google Ads specifically. For a business whose main paid channel is Google, starting with the Data Transfer Service is usually the right call: it is built by the platform that owns the data, and it keeps the setup light. Other channels such as Meta may need a different connector or a third-party tool depending on what the Data Transfer Service currently supports, so check its connector list — but the modelling principles in this guide apply equally.

Step One: Prepare Access and Structure

Before creating anything, confirm three things. First, who has the right access: setting up the transfer needs permission on the Google Ads account — or on the manager account if several client or market accounts sit under one — and the right permissions on the Google Cloud project that holds BigQuery. Second, that billing is enabled on the project and the BigQuery Data Transfer API is turned on. Third, where the data will live. BigQuery datasets are created in a specific location, and datasets in different locations cannot be joined in a single query. Choose the location once, in line with where your other marketing and CRM data will sit, and keep it consistent. For Singapore businesses, the Singapore region is a common choice.

It also pays to plan the dataset structure now. A sensible pattern is one dataset for raw Google Ads data exactly as it arrives, a separate dataset for the cleaned staging models, and another for the final reporting tables. Keeping raw data untouched means any later error in the cleaning logic can be corrected without going back to Google.

Step Two: Create the Transfer With the BigQuery Data Transfer Service

In the BigQuery console, the Data Transfers section lets you create a new transfer with Google Ads as the source. You provide the Google Ads customer ID — the manager account ID if you want every child account pulled through — choose the destination dataset, and set a schedule, which is daily for most reporting needs. The service then creates the reporting tables for entities such as campaigns, ad groups, ads, and keywords, along with performance-statistics tables broken down by day. The data lands in date-partitioned tables, with views built on top of them, and the table names include the account ID.

Two settings deserve attention. The refresh window determines how many recent days are re-pulled on each run; this matters because Google Ads figures for recent days can change as late conversions and adjustments arrive, and a window that is too short will leave those days permanently understated. And the transfer runs under the credentials of the person who authorised it, so it is wise to authorise it from an account that will still be there next year, rather than a personal login that will be disabled when someone leaves the company.

Step Three: Backfill History and Understand What Lands

A new transfer starts collecting from the day it is created, so the next step is a backfill of historical data. The service allows scheduled backfill runs for past dates, within the limits Google sets on how far back it can go, and it is worth running this immediately, since year-on-year comparisons depend on having last year’s data in the same structure as this year’s. If history beyond those limits matters, exporting it separately and loading it once is often a practical fallback.

Then spend time understanding the tables before building anything on them. Google Ads data has quirks that catch teams out. Cost is stored in micros — millionths of the account currency — so it must be divided by one million to give a normal figure. Conversion numbers depend on the conversion actions configured in the account, and the same conversion can be counted differently depending on whether it is reported by the date of the click or the date of the conversion. Getting comfortable with these details early prevents the most common reporting arguments later.

Step Four: Clean and Model the Data

Raw Google Ads tables are not reporting-ready. A staging layer should convert cost from micros, set consistent data types, convert to a single reporting currency where there are several accounts, and align the account time zone with the rest of the warehouse. It should also map campaign names to a channel taxonomy — brand search, non-brand search, performance max, display, and so on — using a documented rule rather than eyeballing campaign titles. A well-modelled table has one row per campaign per day with cost, clicks, impressions, and conversions clearly defined, and a separate view of conversions by conversion action.

The real payoff comes from joining. Ad cost can be matched to website sessions in the GA4 export through campaign identifiers, and to leads and revenue in the CRM through campaign parameters or click identifiers stored on the lead record. That is what turns “cost per conversion” into cost per qualified lead and cost per closed customer, and it is the foundation for the touchpoint analysis described in our article on attribution modelling for marketing teams. For ecommerce brands, the same model joins to order data as described in our guide to building a Shopify and BigQuery analytics stack.

Step Five: Monitor and Reconcile

A pipeline that runs silently will eventually fail silently. Set up checks that alert when a transfer fails, when the latest date in the data is older than expected, or when daily row counts or cost drop sharply. Then reconcile: compare monthly cost and conversions in BigQuery against the Google Ads interface. Small differences for the most recent days are normal because of late-arriving data, but closed months should match closely, and any persistent gap points to a modelling error worth finding. Reconciliation also builds trust — once the marketing manager and the finance lead have seen the warehouse figures match the platform, they stop arguing about which number is right. The wider approach to keeping pipelines reliable is covered in our article on data engineering for business leaders.

Ready to Build a Reliable Google Ads BigQuery Integration?

If your Google Ads spend is still copied into spreadsheets, cost-per-lead figures differ between teams, or paid media cannot be tied to revenue, the path forward is a proper Google Ads pipeline into your warehouse. View our data and AI services, explore our engagement plans, see what we have built in our project portfolio, or get in touch and we can review your current reporting and outline what a reliable integration requires.

Engine Analytics is a data analytics company in Singapore that builds the data foundations — marketing data pipelines, consistent metric definitions, and audience-specific reporting — that businesses need to connect ad spend to real outcomes.

A data engineer at a Singapore logistics software company inherits a reporting pipeline built over three years by four different people. It consists of around a hundred and forty scheduled queries in BigQuery, transformation logic embedded in two BI dashboards, and a Python script that runs on a colleague’s laptop on Sunday nights. Nothing documents which query depends on which. When the finance team reports that a revenue figure looks wrong, it takes two days to find the query responsible, because changing it might break something downstream and nobody can say what.

The engineer’s job, in practice, is not building anything new. It is stopping the existing system from falling over. This is the situation dbt was designed for, and it is why the tool has become a standard part of how data teams work. This article explains how dbt data pipelines differ from ad hoc SQL, how dbt works day to day, what it does not do, and how a team can adopt it without rewriting everything at once. It draws on the approach used by Engine Analytics, a data analytics company in Singapore that builds data infrastructure for growing businesses.

The Problem dbt Was Built to Solve

In most organisations, the logic that turns raw data into reporting tables is scattered. Some lives in scheduled queries, some in BI tool calculations, some in scripts, and some in the head of whoever built it. None of it typically has the disciplines software teams take for granted: dependency tracking, automated tests, version control, and review before changes go live. The consequences are predictable — silent errors, slow debugging, fear of change, and reports that drift apart over time.

Two shifts made a better approach possible. Cloud warehouses such as BigQuery made it practical to load raw data first and transform it inside the warehouse using SQL, a pattern known as ELT. And a large population of analysts already write SQL fluently. dbt — short for data build tool — brings engineering practice to that SQL, so that the transformation layer can be built, tested, and maintained like software.

How dbt Works in Practice

In dbt, each transformation is a model: a SQL SELECT statement saved in a file. Models reference each other using a simple reference function rather than hard-coded table names, and dbt uses those references to build a dependency graph, so it always runs models in the right order and knows exactly what depends on what. Each model can be materialised as a view, a table, or an incremental table that processes only new data, which matters for cost on large event datasets. Reusable logic can be written once as a macro using Jinja templating, and raw source tables are declared explicitly so their freshness can be monitored.

A typical project is layered. A staging layer cleans and standardises each source. An intermediate layer applies shared business logic. A marts layer produces the final tables that dashboards and analysts read from. dbt compiles this into SQL and runs it inside the warehouse. It does not extract data from source systems or load it into the warehouse — that remains the job of ingestion tools — and it does not move data out of the warehouse. Its scope is deliberately narrow, and that focus is much of why it works.

Testing and Documentation Built Into the Workflow

The change most engineers notice first is testing. dbt ships with generic tests that check a column is unique, is never null, contains only accepted values, or matches a valid record in another table, and teams can write custom tests as SQL queries. Source freshness checks flag when upstream data has stopped arriving. Tests run every time the project is built, so a duplicated order ID or an unexpected drop in row count is caught before it reaches a dashboard rather than after someone quotes the wrong number in a meeting.

Documentation follows the same principle. Descriptions of models and columns are written alongside the code, and dbt generates a browsable site with a lineage graph showing how every table is derived. A new team member can trace a revenue figure back to its source without asking anyone. That single change addresses much of the knowledge concentration that makes inherited pipelines so fragile, and it supports the wider goal described in our article on data engineering for business leaders: reporting that can be trusted because it can be traced.

Version Control, Review, and Deployment

dbt projects live in Git, which means every change is recorded, reviewed through a pull request, and reversible. Developers work in their own development schemas rather than on production tables, so experimenting cannot break live reports. Continuous integration can build and test only the models a change affects, catching problems before merge. Production runs are scheduled through dbt’s managed platform, an orchestrator such as Airflow, a scheduled container job, or a CI workflow, depending on what the team already uses. dbt Core, the open-source version, covers the modelling and testing itself; the managed platform adds scheduling, a hosted development environment, and collaboration features.

What dbt Does Not Do

It is worth being clear about the limits. dbt does not replace ingestion, so data still needs a pipeline into the warehouse — for example the connector-based approach in our article on building a Shopify and BigQuery analytics stack. It is not a general-purpose orchestrator for tasks outside the warehouse, such as calling an external API. It does not fix poor modelling; a badly designed model tested and documented is still badly designed. And without naming conventions and a defined structure, a dbt project can become as tangled as the queries it replaced. Poorly chosen materialisations can also raise warehouse costs. The tool provides the framework, but the discipline still has to come from the team.

What This Looks Like in a Real Business

Return to the logistics company in the opening example. After adopting dbt, its revenue logic lives in a small number of models with clear dependencies, and the Sunday-night script has been replaced by a scheduled job. When finance next flags a figure that looks wrong, the engineer opens the lineage graph, sees the three models feeding it, and finds that a test on the billing source has been failing since a currency field changed format. The fix is a one-line change, reviewed through a pull request, and the test that caught the problem now guards against a repeat. Debugging that once took two days takes a fraction of the time, and the analyst can add new metrics in a development schema without worrying about what else might break. The gain is not speed alone; it is the confidence to change the system.

How a Team Adopts dbt Without a Rewrite

The teams that succeed with dbt rarely attempt a full migration. They pick one domain where the pain is highest — usually revenue or customer metrics — and rebuild those models first, alongside the existing pipeline, checking that the results match. They agree conventions early: how models are named, how layers are organised, which tests are mandatory. Then they migrate domain by domain, retiring old queries as the dbt versions prove reliable. Within a few months the highest-risk logic is under version control, tested, and documented, and the rest follows at whatever pace the team can sustain.

Ready to Bring Structure to Your dbt Data Pipelines?

If your transformation logic is scattered across scheduled queries and dashboards, changes feel risky, or nobody can say where a number comes from, the path forward starts with a structured transformation layer. View our data and AI services, explore our engagement plans, see what we have built in our project portfolio, or get in touch and we can review your current pipeline and outline how to introduce dbt in a way that fits your team.

Engine Analytics is a data analytics company in Singapore that builds the data foundations — warehouse models, tested transformation layers, and audience-specific reporting — that businesses need to maintain their pipelines with confidence.

A Singapore pet supplies brand reports a customer lifetime value of S$310 in its investor update. The figure came from a founder’s spreadsheet: average order value, multiplied by an estimated number of orders per year, multiplied by an assumed five-year customer life. Three months later, a new head of growth pulls the actual order data and finds that fewer than a third of customers place a second order, that most repeat purchasing comes from a small group who reorder every six weeks, and that the average customer’s realised value after twelve months is closer to S$95. The S$310 was not dishonest — it was an assumption that had never been checked against behaviour.

In the meantime, acquisition targets had been set against that number and advertising budgets had been scaled on it. The business had been willing to pay up to S$90 to acquire a customer on the belief that each one would return S$310, when the evidence supported a far tighter limit. This is what happens when customer lifetime value is treated as a number to quote rather than a measurement to maintain. This article covers how to track customer lifetime value for ecommerce properly, from your own order data, and what to do with it once you have it. It draws on the approach used by Engine Analytics, a data analytics company in Singapore that builds analytics infrastructure for ecommerce businesses.

What Customer Lifetime Value Actually Measures

Customer lifetime value is the total value a customer generates for the business over the course of the relationship. It exists in two forms that are often confused. Historic CLV is what customers have actually spent to date, and it is a fact drawn from order records. Predictive CLV is an estimate of what customers are likely to spend in future, and it is a model. The familiar formula — average order value, multiplied by purchase frequency, multiplied by expected customer lifespan — is a rough sanity check at best. It assumes every customer behaves like the average, which is rarely true when a small group of loyal buyers drives most of the repeat revenue.

The definition of value matters as much as the formula. CLV calculated on revenue overstates what the customer is worth, because it ignores product cost, shipping, payment fees, and returns. For decision-making, value should be measured after refunds and, where product costs are maintained, as contribution margin. A frequently cited rule of thumb is that lifetime value should be around three times the cost of acquiring the customer, but the ratio hides the question that matters to cash flow — how long it takes to earn the acquisition cost back — so payback period should be tracked alongside it.

Why Most CLV Numbers Cannot Be Trusted

Most unreliable CLV figures share the same handful of causes. Customer identity is fragmented, because guest checkouts and changed email addresses turn one person into several, which understates repeat purchasing and overstates the number of new customers. Refunds and returns are ignored, so value is counted that was later handed back. Cohorts are averaged together, blending customers acquired years ago with those acquired last month, so a lifetime figure describes nobody in particular. There is often no time horizon at all, so two people quote “CLV” and mean twelve months and five years. And wholesale or B2B orders sit in the same data as retail, quietly inflating the average.

Each of these is a data problem rather than an analysis problem, which is why CLV cannot be fixed inside a dashboard. It needs a defined customer identity, defined value, and a clean order history underneath it — the same foundation described in our article on building a Shopify and BigQuery analytics stack.

How to Track CLV From Your Own Order Data

The most reliable approach is cohort-based. Customers are grouped by the month of their first purchase, and the cumulative value per customer is tracked at fixed intervals — thirty, ninety, one hundred and eighty, and three hundred and sixty-five days. Plotted together, the cohort curves show how quickly customers return, how much they spend, and whether newer cohorts behave better or worse than older ones. A single blended average cannot show this. A curve that flattens after ninety days tells a very different story from one that keeps climbing, and the difference should change how the business spends on acquisition and retention.

Doing this well takes five steps. Customer identity is unified using a documented rule. Value is defined after refunds, and after product costs where they are available. The full order history is modelled in the warehouse so that every customer’s orders can be joined to their acquisition source. Cohort curves are produced from that model, then segmented by acquisition channel, first product purchased, discount use, and market. Finally, the definitions are fixed and versioned, so that a CLV quoted in March means the same thing in September. The segmentation is where the insight lives: the customers acquired through one channel can be worth twice as much as those from another, and no blended average will reveal it.

From Historic to Predictive CLV

Once enough history exists, predictive models can estimate the future value of each customer. Probabilistic models such as BG/NBD, paired with a spend model, estimate how many more purchases a customer is likely to make and how much they will spend, based on their recency, frequency, and monetary patterns. The same approach can be built with machine learning inside BigQuery. These models need a meaningful amount of repeat-purchase data — typically a year or more of history and a reasonable number of repeat buyers — to be reliable, and they should always be validated by predicting an earlier period and comparing the result with what actually happened.

Predictive CLV is best used to prioritise, not to promise. It can rank customers for retention campaigns and help judge which acquisition channels attract higher-value buyers early. For businesses selling products people buy once or twice in their lifetime, such as furniture or appliances, most of the value sits in the first order, and effort is better spent on average order value and margin than on modelling repeat behaviour that does not exist.

What to Do With CLV Once You Have It

A trusted CLV changes decisions in four places. It sets the ceiling on what the business can pay to acquire a customer, by channel, with a payback window the finance team can support — and it works best alongside the channel view in our framework for attribution modelling. It shapes retention: the median time between first and second orders shows when a follow-up email or offer should land, and the customers most likely to lapse can be reached before they do. It informs product and pricing, because first products that lead to repeat purchases deserve more prominence than those that do not. And it improves forecasting, since revenue from existing customers can be projected from cohort behaviour rather than guessed.

These uses depend on each team seeing the same figure. Marketing needs CLV by channel, retention teams need it by segment, and finance needs it as margin and payback, all built from one modelled dataset. The principles behind structuring reporting this way are covered in the article on data-driven decision-making with business intelligence.

Ready to Track Customer Lifetime Value for Ecommerce You Can Rely On?

If your CLV figure comes from a spreadsheet assumption, differs between marketing and finance, or has never been checked against actual order data, the path forward starts with the data layer beneath it. View our data and AI services, explore our engagement plans, see what we have built in our project portfolio, or get in touch and we can assess your current order data and outline what reliable CLV tracking requires.

Engine Analytics is a data analytics company in Singapore that builds the data foundations — customer identity, cohort models, and audience-specific reporting — that ecommerce businesses need to measure customer value accurately and act on it.

A Singapore skincare brand on Shopify is processing around nine thousand orders a month across Singapore, Malaysia, and Australia. The founder’s Monday routine is to export orders from the Shopify admin, paste them into a Google Sheet, and combine them with separate exports from Meta Ads and Google Ads. It takes most of a morning. The sheet has grown to fourteen tabs, two of which nobody remembers building, and it breaks whenever a column name changes. When the marketing manager asks which products bring customers back for a second purchase, the answer is that someone will need to check — because Shopify’s reports show orders and sales, but joining them to customer history, ad spend, and returns needs more than the admin can offer.

The business does what many growing Shopify brands do next: it connects Looker Studio directly to a Shopify connector. The dashboards load, though slowly, and the numbers differ from the Shopify admin by a few percent. Nobody can explain by how much or why, because refunds, discounts, and currency conversion are each handled differently in each place. The team has moved from a spreadsheet problem to a dashboard problem without solving the underlying issue, which is that there is no analytical foundation between Shopify and the reports.

This article covers how to build a Shopify BigQuery analytics stack that scales — how data leaves Shopify, how it should be modelled, how it joins with marketing data, and how to keep it affordable as volumes grow. It draws on the approach used by Engine Analytics, a data analytics company in Singapore that builds analytics infrastructure for ecommerce and SaaS businesses.

Where Shopify’s Built-In Reporting Runs Out of Road

Shopify’s analytics are designed for running a store, and they do that job well: orders, sales, traffic, and conversion are all a click away. The limits appear when the questions get broader. The depth of built-in reporting depends on the Shopify plan, and even at the top tier the reports are shaped around Shopify’s own definitions. They cannot easily combine store data with ad spend from other platforms, product costs, email performance, or a customer’s full history across years and markets. Each connected app also reports its own version of the truth — Klaviyo, Meta, and Google each claim revenue on their own terms.

A data warehouse is where those separate views are joined into one. It does not replace Shopify’s reporting; it sits beside it and answers the questions Shopify cannot, such as which first-purchase products lead to repeat orders, what a customer acquired through a particular channel is worth after twelve months, or what contribution margin looks like after discounts, returns, and shipping. BigQuery is a common choice for Shopify businesses because it is serverless, sits comfortably alongside Google Analytics 4 and Google Ads data, and has a Singapore region for teams that want data held close to their customers.

Getting Data Out of Shopify Reliably

There are four ways to move Shopify data into BigQuery, and they are not equally good. Manual CSV exports are not a pipeline; they are a habit, and they fail the moment the person doing them is away. A managed connector from an ELT tool is the fastest route for most stores — it handles authentication, schema changes, and incremental syncing without custom code, though its cost grows with data volume. A custom extraction using Shopify’s GraphQL Admin API, including its bulk operations for large historical pulls, offers more control at the price of more maintenance. Webhooks can push events in near real time when a specific use case, such as stock alerts, needs speed that a daily sync cannot give.

For most businesses the right answer is a managed connector for the core objects and custom extraction only for gaps the connector does not cover. Whichever route is chosen, one design point matters more than the tool: Shopify orders change after they are created. Refunds, cancellations, fulfilment updates, and edits all modify an order days or weeks later, so a pipeline that only picks up new orders will slowly drift away from the truth. The sync should track updates, not just creation dates, and the raw data should land untouched so that any later modelling error can be traced and corrected without re-extracting from Shopify.

Model the Data Around Orders, Customers, and Products

Raw Shopify tables are not ready for reporting. A well-structured setup transforms them in layers: a staging layer that renames fields, sets data types, and standardises currency and time zones, followed by business-logic tables — orders, order lines, customers, products, and refunds — that every report reads from. The most common cause of wrong revenue figures is joining at the wrong grain. An order has one shipping charge but several line items; join the two carelessly and the shipping is counted once per line. Deciding, and documenting, what one row in each table represents removes an entire category of error.

Three definitions need to be settled before the first dashboard is built. The first is customer identity: Shopify assigns customer IDs, but guest checkouts and changed email addresses fragment the picture, so most stores adopt a clear rule such as a normalised email address. The second is revenue: gross sales, discounts, returns, shipping, taxes, and net sales are different numbers, and finance and marketing usually mean different ones. The third is currency: Shopify records both the customer-facing currency and the shop currency, and a multi-market brand needs one consistent reporting currency. The principles behind documenting these decisions are covered in the article on data engineering for business leaders.

Joining Shopify With GA4, Ad Platforms, and Email

The real value of the warehouse appears when Shopify orders are joined with the rest of the marketing picture. GA4’s BigQuery export provides event-level data, which can be matched to Shopify orders through the transaction identifier. Ad spend and click data from Google Ads, Meta, and other platforms lands through scheduled connectors, and email performance from tools such as Klaviyo can follow the same route. Together they support the blended measures leadership actually needs — marketing efficiency ratio, blended customer acquisition cost, and channel contribution — calculated from actual orders rather than platform claims.

This is also the foundation for proper channel attribution, which needs touchpoint data from every source in one place. The framework in our article on attribution modelling for marketing teams builds directly on the joined Shopify, GA4, and ad data described here. One practical note: the GA4 export and the rest of the warehouse need to sit in the same BigQuery location, because BigQuery cannot join datasets held in different locations. Choosing the location once, at the start, avoids a painful migration later.

Designing for Cost and Scale in BigQuery

BigQuery charges for storage and for the data scanned by queries, and at the time of writing it includes a monthly free tier that covers small workloads. Costs stay predictable when a few habits are built in from the start. Large tables should be partitioned by date and clustered on the columns most often filtered, so queries scan only what they need. Dashboards should read from the modelled business-logic tables, not from raw data. Heavy transformations should be materialised as tables and, for large event data, built incrementally so that each run processes only new records. Budgets and alerts should be configured so that a badly written query is noticed on the day rather than on the invoice.

Scale is also an ownership question. As the number of models and dashboards grows, someone has to know what depends on what, which tables are tested, and when data last refreshed. Monitoring that alerts on failed loads, unexpected drops in order volume, or stale tables is what keeps a growing stack trustworthy. For most Shopify businesses a daily refresh is entirely adequate; the piece on real-time analytics covers the few cases where faster data movement is worth the added cost.

What the Stack Looks Like End to End

A scalable Shopify analytics stack has five parts, each with a clear job. Shopify and connected apps are the sources. An ingestion layer moves their data into BigQuery on a schedule, landing it raw. A transformation layer, usually SQL managed with a tool such as dbt, cleans and models it into orders, customers, products, and marketing tables with documented definitions. Audience-specific dashboards — one for marketing, one for finance, one for operations — read from those tables. And monitoring watches the whole chain. The result is that every number can be traced back to a Shopify order, and every team quotes the same figure for the same metric.

Ready to Build a Shopify BigQuery Analytics Stack That Scales?

If your Shopify reporting depends on spreadsheets, dashboards that disagree with the admin, or exports that only one person knows how to run, the path forward starts with the data layer rather than another dashboard. View our data and AI services, explore our engagement plans, see what we have built in our project portfolio, or get in touch and we can review your current setup and outline what a scalable Shopify and BigQuery foundation requires for your store.

Engine Analytics is a data analytics company in Singapore that builds the data foundations — warehouse, models, and audience-specific reporting — that growing ecommerce businesses need to move from spreadsheet exports to numbers they can trust.

A Singapore ecommerce brand spending  $45,000 a month across Google Ads, Meta, and email opens its monthly marketing review with three sets of numbers on the table. Google Ads reports 620 orders for the month. Meta Ads Manager reports 540. Between them, the two platforms are claiming 1,160 orders — against 780 orders actually recorded in the store across every channel, including organic search, direct visits, and returning customers. Nobody in the room can explain how the platforms sold more than the business did, and the meeting moves on to next month’s budget using whichever numbers the person speaking happens to trust.

The marketing lead settles on GA4’s last-click view as the tiebreaker. It shows Meta prospecting campaigns generating very few last-click orders, so the budget is cut by forty percent. Six weeks later, branded search volume has fallen, new-customer orders are down, and the Google Ads numbers that looked healthy the previous month are softening. Meta had been introducing new customers to the brand, many of whom later searched for it by name and converted through a branded Google click. The last-click model credited the branded search and saw nothing else. The cut looked like an efficiency saving; it removed the top of the funnel that the other channels were harvesting.

This is one of the most common situations in marketing analytics, and it does not come from bad tools or careless people. It comes from treating attribution as a report setting rather than as a modelling decision that needs a defined question, clean data, and validation. This article sets out a practical attribution modelling framework for marketing teams — six steps that take a business from conflicting platform reports to a view of channel performance it can defend in a budget meeting. It draws on the approach used by Engine Analytics, a data analytics company in Singapore that builds marketing analytics and data infrastructure for growing businesses.

Why Every Platform Reports a Different Answer

Each advertising platform attributes conversions using its own rules. It applies its own attribution window, counts the conversions it can see in its own data, and — in many cases — credits itself for people who saw an ad but did not click it, or who clicked and then converted days later on another device. None of the platforms can see what the others did along the same customer journey. When a customer clicks a Meta ad on Monday, opens an email on Wednesday, and buys through a Google search on Friday, all three systems may legitimately report the sale as theirs, each according to its own logic. The disagreement is not an error in any one report; it is what happens when several systems each measure a shared journey from their own side.

Measurement limits make this worse. Browser and device-level privacy controls restrict how much of a journey any tool can follow, and Singapore’s Personal Data Protection Act sets expectations around consent and purpose that marketing tracking needs to respect — so every platform reports a mix of observed and modelled conversions. Platform reporting is useful for optimising inside a channel, such as comparing one ad set with another. It is not a sound basis for deciding how much to spend across channels, because none of the platforms can measure the channels it does not run.

What Attribution Models Actually Do

An attribution model is a rule, or a statistical method, for dividing credit for a conversion across the marketing touchpoints that preceded it. The common rule-based models are simple to describe. First-touch gives all the credit to the first interaction and last-touch gives all of it to the final one. Linear splits credit evenly across every touchpoint. Time-decay gives more weight to touches closer to the conversion. Position-based — often called U-shaped — commonly gives around forty percent to the first touch, forty percent to the last, and splits the remaining twenty percent across the middle. Data-driven models use statistical methods to estimate each touchpoint’s contribution from patterns in converting and non-converting journeys.

The important point is that no model is neutral. Each one answers a different question. Last-touch answers “what closed the sale?”, which favours branded search, email, and retargeting. First-touch answers “what started the journey?”, which favours prospecting and awareness channels. Position-based tries to balance the two. Choosing a model is therefore choosing which question the business wants answered — and a team that has not decided that in advance is effectively letting a default setting decide it. Google Analytics 4 illustrates the practical constraint: at the time of writing, it centres its reporting on data-driven and last-click attribution and has removed several of the older rule-based models, which means teams that want to compare models side by side generally need to build that comparison from raw event data rather than from the standard interface.

All of these models share a limit worth stating plainly. They can only distribute credit to interactions that were tracked, and they cannot tell whether a sale would have happened anyway — a customer who was already going to buy and clicked a retargeting ad on the way still gives the model a conversion to assign. What the marketing actually caused is answered by incrementality testing, not by attribution rules, which is why the framework below ends with validation rather than with a model choice.

Step One: Decide Which Decision the Model Needs to Support

The most useful first step is not technical. It is agreeing on the decisions the attribution output will be used for, and on what counts as a conversion. Typical decisions include which channels to fund next quarter, whether branded search is being over-credited, how much value content and email are adding to the journey, and what the business can afford to pay to acquire a customer. Each decision points to a different model and a different level of detail, so the list should be written down before any modelling starts.

The conversion definition deserves the same care. For ecommerce, a purchase is the obvious event, though revenue and margin often matter more than order count. For B2B and lead generation, a form submission says nothing about lead quality, so attribution should ideally run against qualified leads or closed-won revenue from the CRM. The rule of thumb is to attribute against the deepest conversion stage that still has enough volume to be meaningful; measuring form fills because they are easy to track is how a business ends up optimising for cheap leads that never close.

Step Two: Fix the Tracking Foundation

Attribution models amplify whatever quality the tracking data has. If campaigns are tagged inconsistently — “facebook”, “Facebook”, and “fb” appearing as three separate sources — channel performance is split across labels and no model can reassemble it. A documented UTM naming convention, a single channel taxonomy that maps every source and medium to a channel group, and consistent conversion event definitions across GA4, the ad platforms, and the CRM are the unglamorous prerequisites. They take days to set up and are the difference between a model that can be trusted and one that produces precise-looking nonsense.

For lead-generation businesses, the second half of the foundation is capturing click and campaign identifiers on the lead record itself, so that when a lead becomes a customer weeks later the CRM can still say where it came from. Offline conversions, such as a sale closed by phone, can then be matched back to the campaign that produced them. Consent handling belongs here too: it determines which journeys are observable, so it should be documented as part of the measurement design rather than treated as a legal afterthought.

Step Three: Bring Marketing Data Into One Place

A defensible attribution model needs touchpoint data from every channel in one analytical environment. In practice that means landing event-level GA4 data through its BigQuery export, ad spend and click data from each platform through scheduled connectors, and order or CRM data from the systems that record the actual sales — then joining them on shared identifiers into a single table of customer touchpoints. This is the same principle covered in the article on data engineering for business leaders: reporting is only as trustworthy as the layer underneath it. Once the touchpoint table exists, each attribution model becomes a SQL transformation on top of it, which is what makes side-by-side comparison possible and what lets the same definitions feed every dashboard.

For most marketing teams, a daily refresh is enough. Attribution informs budget decisions made weekly or monthly, and streaming pipelines rarely pay back here — the piece on real-time analytics covers the cases where faster data movement is genuinely justified.

Step Four: Choose the Model to Fit the Decision

With touchpoint data in one place, the practical recommendation is to run more than one model in parallel rather than search for the single correct one. Last-click is worth keeping as a baseline because it is easy to explain and most teams already know its numbers. A position-based or linear model adds the journey view that last-click lacks. Where conversion volume is high enough for stable results, a data-driven model adds a statistical estimate of each channel’s contribution; lower-volume businesses are generally better served by simple rule-based models, because data-driven methods need substantial volume to separate signal from noise.

The most valuable output is the difference between the models, not any one of them. A channel that looks weak under last-click but strong under position-based is doing top-of-funnel work — introducing customers rather than closing them — and cutting it on last-click evidence is exactly the mistake described at the start of this article. A channel that looks strong under every model is a safer place to add budget. That comparison turns attribution from a debate about which number is right into a structured read of where each channel sits in the customer journey.

Step Five: Validate Against Reality

Every attribution output should pass two checks before it informs a budget decision. The first is reconciliation: the conversions and revenue attributed across all channels should sum to what the business actually recorded, with nothing counted twice. This one check would have exposed the 1,160-versus-780 discrepancy in the opening example immediately, and it is the reason attribution should be built from the business’s own order data rather than from platform reports.

The second check is incrementality. Attribution shows where credit falls; it does not prove that the spend caused the sale. Controlled tests — pausing a channel in a set of regions while keeping it on elsewhere, or running a platform conversion-lift study — measure what the marketing added over and above what would have happened anyway. For businesses with substantial spend across several channels and a long history of results, marketing mix modelling offers a complementary, aggregate-level view that does not depend on user-level tracking at all. None of these methods is complete on its own, so the credible approach is to triangulate: attribution for day-to-day channel comparison, and incrementality tests and, where appropriate, mix modelling to calibrate how far to trust it.

Step Six: Report by Audience and Review on a Schedule

The final step is making the output usable. A performance marketer needs campaign and ad-set detail within the channel they manage. A head of marketing needs the cross-channel view — how the models compare, where budget is working, and where it is not. A CEO or finance lead needs blended measures such as marketing efficiency ratio, blended customer acquisition cost, and payback period, calculated from the business’s own revenue and spend rather than from platform claims. Each audience gets its own view, all reading from the same modelled data so that a conversion means the same thing in every report. The principles behind this structure are covered in the article on data-driven decision-making with business intelligence.

The framework also needs a review rhythm. Channel taxonomies drift as campaigns are launched and platforms change what they report, so a quarterly review of the definitions, model assumptions, and reconciliation checks is what keeps an attribution model that was accurate at launch from quietly degrading.

Ready to Build an Attribution Setup You Can Trust?

If your platform reports add up to more than you actually sell, budget decisions rest on whichever number is quoted loudest, or channels are being cut on evidence that only measures the last click, the path forward starts with the data foundation and the question the model must answer — not with another dashboard. View our data and AI services, explore our engagement plans, see what we have built in our project portfolio, or get in touch and we can review your current tracking and reporting and outline what a reliable attribution setup requires for your business.

Engine Analytics is a data analytics company in Singapore that builds the data foundations — unified marketing data layers, consistent metric definitions, and audience-specific reporting — that marketing teams need to move from conflicting platform reports to attribution they can act on.

A Singapore polyclinic group commissions a BI vendor to build a reporting dashboard. The brief is straightforward: the group wants to see appointment volumes, average wait times, patient satisfaction scores, and revenue per consultation — all in one place, updated daily. The vendor delivers. The dashboard is live within eight weeks. It looks exactly as requested.

Six months later, the medical director raises the dashboard in a leadership meeting and points out that the patient satisfaction score has been showing the same number for three months. An investigation reveals that the data feed from the patient survey system stopped updating when the survey platform changed its export format. No one noticed because no one had set up monitoring. The appointment volume figures are also being double-counted — patients who book, cancel, and rebook within the same week appear as three separate appointments. The revenue per consultation figure excludes Medisave claims because those come from a different system that was never connected. Three of the four metrics the dashboard was built to show are either wrong or incomplete. The fourth, average wait time, is accurate.

This is not a story about a bad dashboard vendor. It is a story about a common misconception: that a dashboard is the solution to a clinical data reporting problem, rather than the visible surface of a much deeper set of challenges that need to be solved underneath it first. This article covers what clinical data reporting in Singapore actually requires — the data infrastructure, the governance, and the structural decisions that make a dashboard trustworthy — and why teams that skip those layers consistently end up with reports that no one believes. It draws on the approach used by Engine Analytics, a data analytics company in Singapore that builds reporting infrastructure for healthcare organisations.

Why “Just Give Us a Dashboard” Is the Wrong Starting Point

The instinct to start with a dashboard is understandable. Dashboards are visible. They produce something tangible that stakeholders can evaluate, approve, and refer to. They feel like progress. The problem is that a dashboard is only as good as the data feeding it — and for most Singapore healthcare organisations, the data feeding a freshly built dashboard has not been cleaned, reconciled, or validated against the clinical realities it is supposed to represent.

A dashboard built on unvalidated data does not produce reliable insight. It produces confident-looking numbers that may or may not reflect what is actually happening in the organisation. Clinical and operational leaders who discover — usually in a meeting, usually at the worst possible time — that a number they have been citing is wrong do not just lose confidence in that specific metric. They lose confidence in the entire reporting system. The organisation then faces a choice between investing in fixing the foundation it should have built first, or continuing to operate with a reporting system that everyone knows is unreliable but no one has the mandate to replace.

The right starting point for clinical data reporting is a clear definition of the questions the organisation needs to answer, followed by an honest assessment of the data quality and completeness required to answer them reliably. The dashboard comes at the end of that process, not the beginning. It is the interface through which well-governed, well-structured data is presented to the people who need to use it. It is not the place where data problems are solved.

The Data Problems That Dashboards Surface But Cannot Fix

Disconnected source systems are the most fundamental problem in clinical data reporting. A Singapore clinic group with an EMR system, a patient management platform, a billing system, and a satisfaction survey tool has four separate data sources that need to be reconciled before any reporting across them can be trusted. Appointment data in the EMR may not match appointment data in the patient management system if the two are not synchronised in real time. Billing records may use different patient identifiers than clinical records, making it impossible to reliably join a consultation event to its associated revenue. Survey responses may be timestamped differently from the appointment they relate to.

Duplicate and incomplete records compound the disconnection problem. Clinical systems are built for documentation speed, not data hygiene. Duplicate patient records — created when a patient registers at a different clinic in the group, or when a name is entered differently — are common in multi-site environments. Incomplete records are equally common: fields left blank because they were optional in the system but are required for meaningful reporting. A dashboard that aggregates across duplicate and incomplete records produces counts and averages that no amount of dashboard design can make accurate.

Data freshness is a problem that clinical reporting surfaces with particular acuity. A dashboard showing yesterday’s appointment volume is useful for operational planning. A dashboard showing last week’s average wait time, because the pipeline runs weekly, is not useful for making staffing decisions today. The gap between when data is recorded in source systems and when it is available in the reporting layer needs to be understood and managed explicitly — and for time-sensitive clinical metrics, the infrastructure requirements of real-time or near-real-time data movement are substantially more demanding than a batch pipeline. The piece on real-time analytics covers what that infrastructure looks like and when it is worth the investment.

What Clinical Reporting Actually Requires Underneath the Dashboard

A governed data layer between source systems and the reporting interface is the foundational requirement. This is not a new database or a parallel EMR — it is an analytical environment where data from all clinical and operational sources is landed, reconciled, and standardised before any report reads from it. Patient records matched across systems using a consistent identifier. Appointment events deduplicated and linked to the correct episode of care. Billing records joined to clinical records using a reliable bridge. Revenue figures reconciled between the billing system and the finance ledger. This layer is what the article on data engineering for business leaders describes as the foundation that reporting depends on — and in a clinical context, it is non-negotiable.

Metric definitions agreed and documented before any dashboard is built. In clinical environments, this step is more consequential than in most business contexts because the same word can mean fundamentally different things to different stakeholders. “Wait time” might mean time from appointment booking to appointment date, time from patient arrival to clinical assessment, or time from assessment to treatment initiation — three different metrics with three different values and three different implications for operational decisions. A dashboard that shows “wait time” without specifying which definition is being used is not just ambiguous; it actively misleads the stakeholders reading it.

Monitoring that catches data quality problems before they reach the report. Pipeline failures, schema changes in source systems, unexpected drops in record volume, and anomalous values in key fields need to be detected automatically and flagged immediately. Healthcare organisations that discover a reporting error because a leader noticed an implausible number in a dashboard meeting are experiencing the most expensive possible form of data quality monitoring. Automated monitoring at the pipeline layer catches the same problems days or weeks earlier, before they affect decisions.

The Reporting Structure That Makes Clinical Data Actionable

Clinical reporting that is genuinely useful is not a single dashboard showing all available metrics. It is a set of audience-specific views — each built around the questions a specific role needs to answer, using metric definitions appropriate to that role’s responsibilities — connected to a single, trusted data layer underneath.

A medical director needs visibility into clinical outcomes, patient flow across the care pathway, and quality indicators that reflect the standards the organisation is accountable to. An operations manager needs resource utilisation, scheduling efficiency, staff capacity, and the operational metrics that drive daily decisions about room allocation and appointment availability. A finance director needs revenue by service line, collections performance, cost per encounter, and the financial metrics that feed into budget planning and board reporting. Building a single dashboard that tries to present all of these simultaneously produces a view that is too complex for any one audience to use effectively and too aggregated to surface the detail any of them actually needs.

Separating reporting by audience, building each view around the specific questions that audience asks, and connecting all views to a common data layer where metric definitions are consistently applied — this is the structure that distinguishes clinical reporting that gets used from clinical reporting that gets questioned. The broader principles behind audience-specific BI structure are covered in the article on data-driven decision-making with business intelligence, which applies across sectors including healthcare.

Ready to Build Clinical Reporting That Works Beyond the Dashboard?

If your current clinical reporting is producing numbers that stakeholders question, dashboards that nobody opens, or metrics that mean different things in different meetings, the path forward starts with the data layer — not with a better dashboard design. View our data and AI services, explore our project portfolio, or get in touch and we can assess your current reporting infrastructure and map out what reliable clinical data reporting requires in your specific environment.

Engine Analytics is a data analytics company in Singapore that builds the data infrastructure and reporting environments that Singapore healthcare organisations need to make clinical and operational reporting trustworthy, current, and genuinely useful.

A Singapore SaaS business with sixty employees has three BI dashboards. One is owned by the head of sales, built in Salesforce reports, updated when someone remembers to update it. One is owned by the product team, built in Amplitude, showing feature usage metrics that no one outside the product team fully understands. And one is a BigQuery-connected Looker Studio report that the CFO built six months ago to track MRR, which currently shows a number that is twelve percent lower than the Salesforce dashboard shows for the same month.

When the CEO asks for a single view of revenue performance in the Monday leadership meeting, one person quotes the Looker number, another quotes the Salesforce number, and the next fifteen minutes are spent trying to understand why they are different. Nobody can explain it clearly. The meeting moves on. Both numbers continue to be used by different people for different purposes, producing decisions that are made from different starting points.

This is not an unusual situation. It is, in fact, the most common state of BI reporting in SaaS businesses that have grown past thirty or forty people without making a deliberate decision about how their analytics layer should be structured. The dashboards exist. They are just set up in ways that guarantee the outcome described above: multiple sources of truth, undefined metrics, and reports that nobody fully trusts. This article covers the specific mistakes that produce this state and what a setup that actually works looks like. It draws on the approach used by Engine Analytics, a data and AI consultancy in Singapore that builds BI infrastructure for SaaS businesses across growth and enterprise stages.

Mistake One: Building Dashboards Before Defining Metrics

The single most common BI setup mistake is building a dashboard before agreeing on what the metrics it shows actually mean. Revenue is the clearest example. In a SaaS business, “revenue” could mean bookings, billed revenue, recognised revenue, or cash collected — four different numbers that move differently and matter to different stakeholders for different reasons. MRR could include or exclude free trials, one-time charges, setup fees, or discounts. Churn could be calculated on a logo basis, a revenue basis, or a seat basis, and the window for measuring it — are customers who cancel mid-month counted in that month or the next? — produces different numbers depending on what was decided.

Dashboards built before these definitions are agreed produce numbers that are technically computed but conceptually undefined. Different people read them differently, and the metric means whatever the reader assumes it means. When two people quote the same metric name but arrive at different numbers, it is almost always because they are using different definitions that neither of them has stated explicitly. The dashboard did not cause the disagreement — the undefined metric did.

The fix is a metrics document that exists independently of any dashboard and defines, precisely and without ambiguity, every metric the business tracks: what it includes, what it excludes, how it is calculated, and who owns the definition. This document should be agreed across revenue, finance, and product before any dashboard is built or rebuilt. The principles of data-driven decision-making and why this alignment matters are covered in more depth in the article on data-driven decision-making with business intelligence.

Mistake Two: Connecting Dashboards Directly to Source Systems

The second most common mistake is connecting BI dashboards directly to production databases, CRM exports, or billing system APIs and reading from those sources directly. This approach is fast to set up — there is no intermediate layer to build, and the data is current at the point of the last sync — but it creates several structural problems that become increasingly damaging as the business grows.

Direct source connections produce inconsistent results when the same metric is queried at different times. A revenue query run at 9am may produce a different result than the same query run at 11am because a billing event was processed in between. Without a layer that snapshots data at a consistent point, the dashboard’s numbers are a function of when the query ran, not of what actually happened in the period being measured. This is the most common cause of the “why is this number different from yesterday?” conversation that happens in analytics meetings across SaaS businesses.

Direct connections also mean that the transformation logic — the SQL or calculation that turns raw billing records into MRR, or raw product events into active user rates — lives inside the BI tool, repeated in every dashboard that uses those metrics. When the calculation changes, every dashboard that contains it needs to be updated individually. When a new dashboard is built by someone who was not involved in writing the original calculation, it is written slightly differently, producing a metric that is similar but not identical to the others. This is how you end up with three different MRR numbers for the same month.

Mistake Three: One Dashboard for Every Audience

The instinct to build a single “company dashboard” that shows everything to everyone is understandable. Leadership wants visibility. The dashboard should provide it. But a single dashboard built for multiple audiences inevitably makes a trade-off that serves none of them well: either it is too high-level to be useful for operational decisions, or it contains so much detail that the signal the leadership team needs is buried in metrics that are irrelevant to them.

The head of sales needs a dashboard focused on pipeline, conversion rates by stage, deal velocity, and attainment against target. The product manager needs feature adoption rates, activation cohorts, and engagement depth by user segment. The CFO needs MRR waterfall, recognised revenue, CAC, and unit economics by cohort. Building a single dashboard that tries to present all of these simultaneously produces something that is used by no one because it is designed for everyone.

The right structure is multiple audience-specific dashboards, each built around the questions a specific role actually needs to answer, all reading from the same underlying data layer where metric definitions are consistent. This way, the head of sales and the CFO can both see MRR — defined identically — in the context of the other metrics relevant to their role, without either of them wading through information that is not relevant to their decisions.

Mistake Four: No Single Source of Truth Underneath the Dashboards

All three mistakes above have a common cause: there is no single, governed analytical layer underneath the dashboards where data is cleaned, standardised, and modelled before any dashboard reads from it. Without this layer, every dashboard is effectively its own data environment — with its own connections, its own transformation logic, and its own implicit metric definitions. The piece on data engineering for business leaders covers what this layer looks like and why it is the foundation that makes everything above it trustworthy. For a SaaS business specifically, this layer typically includes a central data warehouse — BigQuery is the most common choice — where data from the CRM, billing system, product database, and any other relevant source is landed on a consistent schedule, cleaned, and modelled into the business-logic tables that dashboards read from.

With this layer in place, metric definitions live in the data model rather than in dashboard calculations. MRR is defined once, in a table that every dashboard queries. When the definition changes, it changes in one place and propagates to every dashboard automatically. New dashboards are built against the same tables, so a new team member building a product dashboard for the first time uses the same MRR definition as the CFO’s finance view. The multiple-source-of-truth problem is structurally impossible when there is only one source.

What the Right Setup Looks Like

The setup that works begins with metric alignment: a documented, agreed definition for every metric the business tracks, owned by the relevant function and reviewed when business logic changes. This document is a prerequisite for any dashboard work, not a deliverable produced after the dashboards are built.

A central data layer is built and maintained separately from the dashboards that read from it. Source data lands in a cloud warehouse on a defined schedule. Transformation models run against that raw data and produce clean, labelled, business-logic tables. Monitoring alerts when pipeline failures occur or when data freshness falls outside expected windows. The data layer is owned and maintained as infrastructure — not as a byproduct of dashboard work.

Audience-specific dashboards are built on top of the data layer, each focused on the questions a specific role needs to answer. They are connected to the warehouse, not to source systems directly, so they read from data that is consistent, snapshotted at the right time, and defined identically across every view. For teams with time-sensitive operational metrics, the architecture may extend to near-real-time data movement — the piece on real-time analytics covers when that investment is justified and what it requires.

Ready to Fix Your SaaS BI Setup?

If your current BI environment produces numbers that different people quote differently, dashboards that nobody fully trusts, or reports that raise more questions than they answer, the path forward starts with the data layer and the metric definitions — not with a new dashboard design. View our data and AI services, explore our engagement plans, see what we have built in our project portfolio, or get in touch and we can assess your current setup and identify exactly where the BI environment needs to be rebuilt to produce reporting your team can trust.

Engine Analytics is a data analytics company in Singapore that builds the analytical foundations — data layers, metric definitions, and audience-specific dashboards — that SaaS teams need to move from conflicting reports to a single version of the truth.