A practical guide to planning dashboard data sources before building custom reporting tools.
A business dashboard becomes unreliable when its data sources disagree about basic concepts. Sales may mean orders placed, payments collected, invoices issued, or recognized revenue. A chart can display any of those accurately while still answering the wrong business question.
Before commissioning dashboard development, define the decisions, records, and ownership behind the metrics. Website Planning Consultation can help turn reporting requirements into a development brief. This is a planning starting point; custom dashboard integrations require their own agreed scope.
List the questions the dashboard should help someone answer. Which leads need attention today? Which products may run out? Which campaigns acquire suitable customers? Which invoices are overdue?
Identify the person making each decision and the action they can take. A metric without an owner or response can become decorative reporting. Different users may need different views even when they share the same underlying data.
For an illustrative service-and-retail business, the owner may review cash collections, sales staff need overdue follow-ups, and fulfillment needs paid unshipped orders. Combining those into one unlabeled sales total would obscure important distinctions.
Define each metric in plain language and specify its calculation. Record the source, included statuses, exclusions, date basis, timezone, currency treatment, and responsible business owner.
For paid orders, decide whether partially paid orders count and how refunds are reflected. For qualified leads, define the actual qualification criteria. For average response time, identify the starting and ending events and how non-working hours are treated.
Keep definitions visible to dashboard users through appropriate documentation or contextual labels. A number should not require a private conversation with the original developer to understand.
Version meaningful definition changes. If revenue logic changes midyear, historical comparisons need explanation. Quietly replacing the calculation can make a trend appear to change for reasons unrelated to the business.
List the commerce platform, payment provider, CRM, advertising accounts, analytics, support system, inventory records, and finance tools. Record who owns each account and whether an approved API or export is available.
Check the fields you actually need, not just whether an integration exists. A connector may provide order totals but omit refunds, item-level data, or historical stage changes. Those omissions can make a planned metric impossible or misleading.
Google's Analytics Data API reporting guide describes reports built from dimensions and metrics. API access does not mean every business question can be answered from analytics; choose sources according to the record being measured.
Use the order system for order state, the payment provider for payment transactions, and the appropriate finance system for accounting records according to the business's processes. These systems may need reconciliation rather than replacement by one universal source.
Analytics is useful for observed website behavior, but may not capture every order because of consent and browser conditions. The GA4 revenue-validation guide explains why behavioral reporting and operational records can differ.
Document which source wins when records conflict and who investigates. A dashboard should not silently choose whichever value arrived most recently if that choice has no business justification.
Grain means what one row represents. An order table may contain one row per order, while an item table contains several rows per order and a payment table may contain multiple attempts or refunds.
Joining those tables carelessly can multiply totals. In a simple illustrative example, an order with three items and two payment-related records can produce six joined rows. Summing the original order total across those rows would overstate sales.
Define how data is aggregated before combining it. Keep transaction identifiers and relationship keys explicit. Ask the developer to demonstrate totals on a small known sample before building broader reports.
Google's BigQuery export schema illustrates the importance of understanding event-level data and nested fields. Raw exports need interpretation; they are not ready-made business metrics.
Decide how customers, companies, products, and opportunities are matched across systems. Prefer stable identifiers and documented mappings. Email addresses can change, and two records with similar names are not automatically the same person or business.
Avoid collecting personal information that the dashboard does not need. Aggregate or pseudonymous reporting may answer many questions without exposing customer contact details to every viewer.
Consider history. A CRM showing the current deal stage may not reveal when the deal entered previous stages. If the dashboard needs stage duration or historical pipeline snapshots, verify that the source provides those records or plan suitable collection going forward.
Choose refresh timing based on the decision. Inventory alerts may need timely updates, while a monthly financial review can use a reconciled batch. Real-time architecture adds complexity and should have a clear purpose.
Display when the data was last updated and distinguish stale data from zero activity. If a connector fails, an empty chart should not imply that the business made no sales.
Plan retries, rate-limit handling, duplicate prevention, and backfills. A temporary outage should be recoverable without manually reconstructing every missing record. Record how late-arriving refunds or corrections update earlier reporting periods.
Give users access to the information required for their role. A marketing dashboard may not need customer addresses, salary details, or full financial records. Developers should use appropriately scoped access and secure credential storage.
Separate view permissions from configuration permissions. Changing a metric definition, connector credential, or source mapping can affect every user. Those actions need identifiable ownership and an audit trail appropriate to the system.
The dashboard governance guide provides a broader framework for connecting KPIs, sources, and access decisions.
Select a sample containing normal orders, partial refunds, cancellations, multiple currencies, duplicate contacts, and late updates where those cases exist. Compare dashboard values with the original records.
Check date boundaries and daylight-saving behavior where relevant. A business operating across regions can see the same event fall on different calendar dates in different systems.
Create reconciliation thresholds and investigation steps. Some differences may be expected because the systems measure different concepts. The validation should explain them rather than hide them with an arbitrary adjustment.
Include a reconciliation example in the handover. Show how one known order, its partial refund and its eventual payout appear in the relevant views. This gives future maintainers a concrete reference when a provider changes its export format or a new integration starts producing unexpected totals.
Include the decision list, metric dictionary, source inventory, field availability, identity rules, refresh expectations, access roles, and validation examples. Identify unknowns that require a technical discovery phase.
Specify what happens when data is unavailable and who receives an alert. Include ownership for ongoing connector changes and provider API updates. A dashboard is a maintained data product, not only a one-time collection of charts.
No. Match freshness to the decision and the source's capabilities. A dependable scheduled refresh with a visible timestamp can be more appropriate than a fragile real-time integration.
Only when everyone agrees on its meaning. Orders, collected payments, and accounting revenue often need separate measures with clear labels.
Show the last successful update, identify the affected data, alert the responsible person, and support recovery. Do not silently replace missing records with zeros.
A practical portfolio website guide for freelancers, consultants and creative experts who need better client trust.
Read article →
A practical guide for companies planning a more structured corporate website with room for growth.
Read article →
A practical CRM pipeline setup guide for service teams that want cleaner lead management.
Read article →
Author
Anushka Dahanayake builds SEO-focused websites, e-commerce platforms, dashboards, and automation systems for businesses worldwide.
