The integration is connected but the dashboard is empty: what onboarding should explain
A blank first dashboard can mean missing events, delayed reporting, a filter mismatch or a valid zero. Design a diagnosis that keeps those states distinct.
In this article
When an integration is connected but the dashboard is empty, onboarding should help the user locate the missing step. A successful connection may establish access to an account. It does not establish that the selected report contains data for the current workspace, date range and filters.
The empty state needs to distinguish what the product knows from what it has yet to observe. “No events received” requires a different next action from “Events received; this report is still processing.” A valid zero in a narrow report is different again.
Treat the first dashboard as a short diagnostic journey. The user should be able to answer where the data is expected to come from, whether any has arrived and why this particular view is blank.
Start with the report’s scope
Before recommending a reinstall or reconnection, show the account, workspace or property the dashboard is reading. Include the active date range and any filter that can remove the expected activity.
A new user may have several similar workspaces. A connection confirmation that displays only the integration’s brand name leaves them without a useful way to check the destination. The first dashboard should retain the identity of the selected source after the connection dialog closes.
Consider an illustrative analytics product connected to a Demo Store workspace. A test event was sent today, but the dashboard is showing the previous calendar month. “No data” is technically plausible and practically unhelpful. The relevant repair is to choose a date range containing the event, not to reinstall the integration.
A focused explanation could say: “This report covers the selected month. Your most recent received event is outside that range.” Only show that statement when the product has the corresponding event information. Otherwise, make the date-range check an explicit suggestion rather than a diagnosis presented as fact.
Show whether anything has arrived
A connection indicator should sit alongside a separate reception indicator if the product can provide one. The first says the connection is configured; the second says an identifiable event or record reached the system.
In our fictional product, the reception panel could display the last received event name, its timestamp and its source workspace. That gives the user an object to investigate. It is more useful than telling them to generate “some traffic” and wait for an unspecified period.
The event need not appear in every report immediately. Google Analytics’ Realtime documentation describes a view of recent activity and notes that an empty Realtime report can simply mean there are no active users. It also documents limitations and possible delays. A blank panel therefore does not, on its own, isolate a broken connection.
Keep the reception check narrow. Finding one test event demonstrates that one event arrived in that context. It does not establish complete instrumentation, correct attribution or the accuracy of every downstream metric.
Separate reporting delay from missing input
Google Analytics’ data-freshness guide distinguishes realtime, intraday and daily processing. It explains that reports can change while processing continues. Those are Google Analytics behaviors, not a universal timetable for analytics products.
The design lesson is to report the actual stage your own system knows. If data has arrived and is awaiting a documented reporting process, keep that fact visible. If the system has not observed input, do not use “processing” as a comforting substitute for an unknown state.
A useful first-dashboard panel can say which dataset is current, when it was last refreshed and whether a later update is expected. Where the product has a reliable job status, link to it. Where it has only a documented normal interval, explain that interval as guidance rather than a guaranteed completion time.
The user should be able to leave and return without losing the diagnosis. Preserve the selected source and the latest known state. An empty chart that resets to a welcome illustration on every visit makes progress difficult to recognize.
Give each empty state a different repair
This proposed matrix belongs to the fictional Demo Store product. It is an editorial design aid, not a report of observed behavior in Google Analytics.
| State the product can establish | What the user should understand | Useful next action |
|---|---|---|
| No input observed for this source | The connection exists, but the product has not received the expected data | Follow the documented event or record check |
| Input observed; report pending | The data reached the system and has not appeared in this report yet | Inspect processing status or the stated refresh guidance |
| Input falls outside the date range | The selected period excludes the known activity | Change the period while preserving the other settings |
| A filter removes the known activity | The report’s selection is narrower than the received data | Review the named filter or clear it temporarily |
| The report correctly contains zero | The selected metric has no qualifying activity | Explain the metric and identify a relevant next task |
Avoid a single button that clears every filter, changes the account and restarts setup. It may produce a populated chart while hiding which assumption was wrong. A targeted action gives the user a reusable understanding of the product.
If the product cannot distinguish two states automatically, say what is uncertain and offer the smallest next check. That is more helpful than choosing a confident explanation without supporting information.
Use a known event to make the journey inspectable
For an internal review, propose one controlled sample event with a recognizable name and timestamp. Confirm the intended test workspace before generating it, then follow that same event through the reception view and the relevant report. This is a suggested acceptance exercise; no event was sent for this article.
Change one condition at a time: select the wrong workspace, choose a date range that excludes the event or apply a filter that removes it. Observe whether the empty-state explanation changes accordingly. Restore the original setting and verify that the person can find their way back.
Include a legitimate zero. For example, the fictional workspace may contain page-view activity while a report counts a different action that has not occurred. A successful integration should be able to show that zero without implying an error or prompting the user to generate artificial business activity merely to finish onboarding.
The result of this review is a clearer explanation of the data path. It is not a performance benchmark or proof that all instrumentation is correct.
End with a result the user can interpret
A populated chart is useful only if the user knows what it contains. Once the first result appears, keep the source, period and active filters visible. Explain the metric in the context of the task they came to perform.
If they need help, carry the current scope and last observed event into the support request. That gives support a starting point beyond “the dashboard is blank” while avoiding a request for account credentials.
The first dashboard has done its job when the user can tell the difference between no qualifying activity and an unresolved setup problem. That understanding lets them continue with a meaningful question instead of repeatedly reconnecting a system that may already be working.
