Healthcare Marketing Dashboards: When to Ask Instead

A dashboard answers the questions somebody anticipated when they built it, and most of the questions you get asked on a Monday are not those. Keep the dashboard for the handful of numbers you check every day, and use a question interface for anything that starts with "why" or "what changed". That is how we split the job at Curve: the analytics and campaign screens stay, and Curve Analyst sits on top of the same data, so the answer to a question can be a chart the dashboard never had. There is a second reason the split matters in healthcare, and it has nothing to do with convenience. The way most practices and agencies build their dashboards is itself the compliance problem.

TL;DR

• Dashboards are the right tool for a fixed set of KPIs watched on a fixed cadence, and the wrong tool for the question nobody built a widget for.
• Why bookings dropped, which platform is doing better, where in the funnel people leave: these need a query, not a filter.
• The typical healthcare dashboard stack (exports into a BI tool with no BAA, GA4 as a source, spreadsheets emailed around) moves data to places nobody signed for.
• A question interface changes who can use the data. The practice owner, the office manager, and the agency account lead can all ask without learning the tool.
• Curve keeps the dashboard and adds Curve Analyst on the same data. Analyst inherits the filters of the screen you opened it from and renders charts in the answer.
• Analyst is read only, does not see session recordings or heatmaps, and does not look up patients.

What is a healthcare marketing dashboard actually good at?

A dashboard is a set of answers to questions somebody already asked, and that is a feature. If you look at spend against budget, cost per booked appointment, and bookings by location every morning, you want those numbers in the same place, in the same order, with the same date range. A chat box does that badly, because typing the same question every morning is slower than glancing at a tile.

So the case for the dashboard is real. The trouble starts the moment someone asks a question that is one step off the page.

Where do dashboards fail?

Somebody asks why. You open the dashboard. The dashboard shows what.

Every question a dashboard can answer was anticipated by whoever built it. The widgets encode a guess about which questions would matter, made months ago, possibly by someone no longer on the account. The Monday question is "why were new patient calls down last week?" The dashboard has a calls by week chart. It shows the drop. It says nothing about which source lost the calls, whether one location fell off, or whether the tracking broke. So you add a filter, then another, then discover the filter you need does not exist, and you export to a sheet.

Comparing across platforms

Google Ads and Meta each report their own conversions with their own attribution windows, and each will happily claim the same booking. A dashboard fed by platform connectors puts the two numbers next to each other and invites you to add them, which is exactly the wrong thing to do. What you want is one attribution model applied to both platforms from your own event data, plus a view of what each platform credited so you can see the gap. Most dashboards are not built that way, because the connectors that feed them only know what the platform believes.

Diagnosing where the funnel leaks

A booked appointments tile cannot tell you whether the drop is at the landing page, the form start, the form submit, or the scheduler handoff. Funnel questions need the steps defined and the drop-off between them computed. If someone built that funnel widget for the old form and you replaced the form in the spring, the widget is quietly wrong and nobody has noticed because it still renders.

Explaining a change

"What changed?" is the hardest question for a dashboard because it is a comparison across every dimension at once. The honest answer compares this period against the previous one for each source, campaign, device, and landing page, then ranks the movers. Nobody builds a widget for that. It is a different query every time.

The hidden compliance cost of the typical dashboard stack

Healthcare differs from every other vertical here: the tooling most people use to build a marketing dashboard is the exposure. A practice's dashboard is usually assembled from a BI tool, a GA4 property, a spreadsheet or two, and an email thread. Each one is a place your data goes. Under HIPAA, a vendor that handles PHI on your behalf is a business associate and needs a BAA, and the FTC has pursued health data disclosures to ad platforms on unfairness grounds, which does not depend on HIPAA status at all. So the question for each piece of the stack is simple: did anyone sign for it?

Exports into a BI tool with no BAA

The common pattern is to pull web analytics and ad data into Looker Studio, Power BI, or a similar tool, blend it, and share the link. Whether that tool is covered depends on the vendor, the plan, and what you loaded into it. On a healthcare site, page URLs can reveal a condition, and a "top landing pages" chart in a BI tool is a list of the conditions people looked up, now held by the tool. We wrote up the Looker Studio case in is Looker Studio HIPAA compliant; the mechanism is the same for any BI product connected without a BAA.

GA4 as a source

Google does not sign a BAA for Google Analytics 4, and any AI feature inside GA4 inherits that status. If GA4 feeds your dashboard, the dashboard is a view onto data that already left without a BAA. A prettier report does not fix the upstream problem.

Spreadsheets emailed around

The last mile of most reporting is an export. Someone downloads a CSV of conversions and emails it to the practice owner before the Monday call. Now the data lives in inboxes and download folders with no access control, no retention policy, and no audit trail. Every "can you just send me the numbers" request creates another copy.

The fix is to move the questions to where the data already lives under a BAA, rather than moving the data to wherever the questions are. That is the difference between a question interface inside the analytics platform and a chat product you paste a CSV into. The second is another export with a friendlier front end.

Who gets to use the data when asking replaces clicking?

The unspoken rule of dashboards is that only the person who built one can really use it. Everyone else clicks around, gets confused by a filter, and messages the builder.

The practice owner

They want to know whether marketing is working and what to worry about, on a phone, before clinic starts. They will not learn a dashboard. They have tried. They will type "are we getting more new patient bookings than last month, and from where?" and read the answer.

The office manager

They care about calls, form submissions, and bookings by location, and whether the front desk got slammed because a campaign went live. They do not care about ROAS. They need an answer about last week they can paste to the owner without editing. The rules in reports a compliance officer will sign off on apply to a chat answer as much as to a PDF: aggregates only, no patient identifiers, and a clear statement of what the number is.

The agency account lead

Fourteen clients and a Monday. They need each client's numbers with that client's filters, which conversions moved, and an explanation they can put in an email without opening four tabs. Building a dashboard per client and rebuilding it each time the client asks something new is where agency reporting time goes. If your client reports follow the structure in agency client reporting without PHI, the questions you get between reports are exactly the ones a question interface handles: what changed, which source, since when.

What should you keep on a dashboard anyway?

Keep the dashboard. Trim it.

• The KPIs you check every day, in a fixed order. A handful of tiles, not a wall of them.
• Anything you glance at rather than ask about. Realtime visitors. Today's form submissions. Whether the scheduler is still firing.
• Anything with a definition the owner and the agency both signed off on. The dashboard is the contract, and the tile is where the agreement lives.
• Anything you screenshot into a weekly report.

Remove the widgets that exist because a question came up once in March. Remove the "other" charts nobody scrolls to. Remove any chart whose attribution model the builder cannot explain from memory. If a widget is only there in case someone asks, that is a question, and it belongs in the question box.

How does Curve Analyst work next to the dashboard?

Analyst is a chat inside the Curve dashboard. Open it from the analytics, goals, or campaign screen and it keeps that screen's date range and filters. If you are looking at the last thirty days, one location, paid traffic only, that is what Analyst is looking at too. You do not restate the scope.

It queries the account's own data and answers with text plus rendered charts: trends as line charts, ranked lists as tables, totals as stat cards, funnels as step charts. So "which sources drove the most booked appointments this period" comes back as a ranked table, whether or not any dashboard page has that chart.

It covers three areas. Website analytics: visitors, sessions, pageviews, bounce rate, top pages, sources and channels (including referrals from AI assistants such as ChatGPT and Perplexity, which show up as their own rows in the sources report), UTMs, devices, locations, custom events, and realtime visitors. Goals and funnels: how many times each goal fired, period comparisons, and step by step funnel leakage. Campaign reporting: spend, conversions, cost per acquisition, ROAS, revenue, clicks, impressions, and CTR by platform, campaign, or ad group, plus a reconciliation view showing what Curve sent to Google or Meta next to what the platform credited.

On the numbers: Curve reports its own attributed conversions, credited by Curve's attribution engine using the model you chose. Spend, clicks, and impressions come from the platforms directly. The two conversion figures will not match, and Analyst tells you which one it is quoting. A gap in the reconciliation view is usually the platform's attribution window still being open rather than underreporting. If tracking and attribution are not sorted yet, asking questions of the data is premature; track, then attribute, then ask is the order that works.

Every number is the result of a query against the account. Analyst never estimates. If a metric is empty it says so. If the data is stale, partial, sampled, or still syncing, it says so before the number. It treats "unknown" and "zero" as different things, which is more than most dashboards manage.

It runs on Claude through Amazon Bedrock, inside infrastructure covered by Curve's BAA with AWS. Your data is not exported to a separate AI product and is not used to train models.

What Analyst will not do

We built it read only. It cannot change tracking, edit destinations, or take actions. It does not access session recordings or heatmaps; watching the session where the form failed is still a click. It does not look up individuals or answer person-level questions. Ask who filled in the form on Tuesday and you get a refusal, on purpose. It does not write SQL. And it does not yet answer about tracking configuration or connector health, which is planned.

What to ask Curve Analyst

Open Analyst from the screen you are already on so it inherits that view, then ask the questions you would otherwise export a sheet to answer. The launch post at introducing Curve Analyst has more examples, and Analyst suggests questions itself once it is open. These three cover most Monday mornings:

• "Summarize the analytics view I came from and tell me what changed compared with the previous period."
• "Which conversions moved the most this period, and in which direction?"
• "What were the best and worst sources over this period, by conversions and cost per acquisition?"

Frequently asked questions

Is Looker Studio a HIPAA compliant healthcare marketing dashboard?

Whether any BI tool is covered depends on the vendor, your plan, and a signed BAA, which you confirm with the vendor rather than assume. The larger issue is usually what feeds it. If the source is GA4, Google does not sign a BAA for GA4, so the dashboard is a view onto data that already left uncovered.

Can I keep my existing dashboard and add Curve Analyst?

Curve's own analytics, goals, and campaign reporting screens are the dashboard, and Analyst opens from them. If your current dashboard is an external BI tool fed by exports, ask whether you still need the export once its questions can be asked directly. Often the external dashboard shrinks to a few agreed KPIs and everything else moves to a question.

Why do Analyst's conversion numbers differ from Google Ads?

Because they are different numbers. Curve reports conversions credited by its own attribution engine under the model you chose, while Google reports what Google credited under its own window. Analyst says which one it is quoting, and the reconciliation view puts the two next to each other. A gap is usually the platform's window still being open, not lost data.

Can the practice owner use Analyst without training?

That is who it is for. They open it from the screen they were on, type a question the way they would ask it in a meeting, and get text plus a chart. It suggests questions if they are not sure where to start. It will refuse to look up a patient and cannot change anything, so there is nothing to break.

If your dashboard has grown a widget for every question anyone ever asked and still cannot answer the one you got this morning, book a demo and bring that question. We will ask Analyst in front of you.