Most embedded analytics designs assume three things: a tenant is a customer, a metric is a measurement, and an event arrives on the day it happens. A construction platform breaks all three.
Each break surfaces as a support ticket rather than as an architecture decision. A subcontractor sees a number they should not have seen, a project manager asks why last month's revenue changed, or a superintendent reports that today's dashboard is missing half the crew. The three sections below are the causes.
The Tenant Is a Project, and the People In It Work for Different Companies
In most B2B products the access unit is the account: one company, its own users, its own rows. Construction inverts that. A project has an owner, a general contractor and subcontractors who are separate businesses with separate commercial interests, all reading the same job.
Procore states the mechanic in one line: "A user's permissions for a specific tool are granted on a per project basis" (Procore, subcontractor permissions, checked 4 September 2026). So scope is not a single column comparison against an account. It is a grant per project and per role, and the same person carries a different scope onto the next job.
The boundary is contested rather than theoretical. On Procore's own community forum a general contractor describes buying the platform to hold historical project data and then finding that an owner's account restricted access to it (Procore community thread, checked 4 September 2026).
That is one team's account of one dispute, not an industry finding. It is enough to show that an analytics layer has to be able to represent two parties with different rights over one project.
Our multi-tenant analytics architecture piece works through the general contract: identity, routing, authorization, workload, delivery. The construction-specific addition is that the routing key is a pair rather than a value, and membership lives per project instead of per account.
The Headline Number's Denominator Is an Estimate
Long-term contracts recognise revenue as work progresses rather than at handover. Under the cost-to-cost approach, percent complete is costs incurred to date divided by total estimated costs, and revenue to date is that percentage of the contract value (NetSuite, checked 4 September 2026).
Read the formula from the dashboard's side. The numerator is a measurement and the denominator is a forecast, which means recognised revenue moves when somebody revises the estimate and no work has happened at all.
Three consequences follow for the chart:
- A revision date belongs next to the figure. Without it, a jump reads as progress when it may be a re-estimate.
- A period-over-period comparison computed under two different estimates is not like-for-like. Either restate both periods on the current estimate or say which estimate each period used.
- The metric needs one definition, not one per surface. This is the ordinary argument for a semantic layer, with a sharper edge: here the same word can be arithmetically different between two screens rather than merely rounded differently.
The Data Arrives After the Day It Describes
Jobsites lose signal in basements, in steel-framed structures and on rural sites, so field apps capture offline and sync when connectivity returns. Vendors treat this as a baseline rather than a feature: Trimble's B2W mobile apps are documented as working online or offline (Trimble, checked 4 September 2026), and jobsite platforms describe offline access to plans, tasks, punch lists and forms with automatic sync.
The analytics consequence is that occurrence time and arrival time are different columns. A timesheet entered on Tuesday in a basement may land on Thursday, so Tuesday's total is not final on Tuesday, and a chart that recomputes silently will show a number that grew without anyone editing anything.
That makes an as-of stamp part of the metric rather than a nicety, and it makes "today" the least trustworthy bucket on the page. Our real-time dashboard guide separates the architectures behind the word real-time; for a field-capture product the honest default is a stated lag rather than a live claim.
What to Test Before You Ship
Run each of these against a real project rather than a seeded one:
- Add a subcontractor to project A only, then request project B's data by direct URL, by export and by a saved link.
- Move the same person between two projects with different roles and confirm the scope changed rather than accumulated.
- Revise a cost estimate and check whether every surface that shows percent complete moved together, including caches, scheduled reports and exports.
- Enter a field record with the device offline, sync it two days later, and confirm the original day's total updates and is labelled as having updated.
- Ask what a party sees after they leave a project, and whether the answer is the same for the dashboard, the export and the shared link.
The first four have a pass or fail answer in a test environment. The fifth is usually a contract question before it is an engineering one, and it is worth settling before the first renewal rather than after it.
Where to go next
- Multi-tenant analytics architecture: the general tenant contract this page specialises.
- Headless BI guide: where a metric gets one definition instead of one per screen.
- Real-time dashboard guide: what real-time can mean, and which meaning a field-capture product can support.
- Interactive dashboard features: drill paths, freshness contracts and saved views.
- Embedded analytics complete guide: the evaluation path from data audit to pilot.
Test the Project Boundary With Your Own Data
Try a per-project scope, a revised estimate and a late-arriving field record against your own model before you commit to an approach.
