Looker and Slack: Which Dashboards Get Discussed, and Which Nobody Opens

It is the week before the Looker license review. The analytics engineer has System Activity open, the Dashboard Usage view, sorted by views in the last 90 days. Several hundred rows. The top twenty look healthy. Then there is a long tail sitting at zero, and it is longer than anyone wants to admit in the meeting.

The head of data wants a list of what to archive. Reasonable request. So the engineer exports the zero-view rows and pastes them into #analytics, and within four minutes the RevOps lead replies: "don't archive Pipeline Coverage, we use it every Monday." It has three views in 90 days. It has three views because the RevOps lead screenshots one tile and posts the image into #revenue every Monday morning, and eleven people look at the screenshot instead of the dashboard.

That is the whole problem in one thread. Looker knows exactly who opened what. Slack knows which dashboards people actually argue about, quote, screenshot, and tell each other to ignore. The dashboards worth keeping are the ones that appear in both, and no single screen shows you both.

What Looker knows on its own

Looker's System Activity is genuinely good, and it is better than most teams realise. It ships as a model over Looker's own internal database, with Explores for History, Dashboard, Look, User, Content Usage and Scheduled Plan. From those you can get, per dashboard: total views, distinct viewers, last accessed date, average query runtime, who owns it, which folder it sits in, whether it is a LookML dashboard or a user-defined one, and how many schedules point at it. If your question is "which content has not been opened," Looker answers it precisely, with real event data, not a guess.

The Looker Slack integration is real too, and it works well. You can deliver a dashboard or a Look to a channel or a DM on a schedule, as an image, PDF or CSV. Looker alerts can fire into Slack when a tile crosses a threshold. And with the Looker app installed, pasting a Looker link into Slack unfurls it into a preview.

Here is precisely where it stops. That integration is one directional. Looker writes into Slack. It does not read back. Nothing in System Activity records that a link was pasted, that a thread formed under it, that four people replied, or that one of those replies said the numbers were wrong. Looker's history table has a row for a view event and no column for why.

Two consequences follow. A dashboard delivered on a daily schedule accumulates render activity whether or not a human ever looks at the message, so its usage can read as healthy while nobody engages with it. And a dashboard people discuss constantly, but reach through a screenshot or a saved bookmark on one person's machine, reads as dead. Worth noting as well: detailed history in System Activity is kept for a bounded window and older activity is aggregated, so "never viewed" usually means "not viewed inside the window Looker still keeps."

What Slack knows on its own

Slack holds the other half. Search has:link looker scoped with in:#revenue and during: will surface the messages where someone dropped a dashboard URL. The thread under it is there: replies, reactions, who was in the conversation, what they concluded. Slack's analytics will tell you which channels are busy and how message volume moves.

Where Slack stops is that it has no model of what a dashboard is. A Looker URL in a message is a string of characters. Slack cannot group by it, cannot resolve /dashboards/447 to "Exec Revenue Overview," cannot tell you which folder it lives in or who owns it, and cannot rank content by how often it comes up. The unfurl preview you see is rendered for display, not indexed as structured metadata you can query.

And the bigger limit: most references contain no URL at all. People write "the pipeline dash," "Marc's retention board," "the exec overview," "the one with the broken ARR tile." A URL search misses every one of those, which means the search that looks most rigorous is the one that most reliably under-counts.

Why the gap is structural, not a missing feature

Look at the shape of the two halves of the evidence.

Looker's half is a record. It is machine generated, has a schema, carries IDs and timestamps, and was written by the system as a side effect of someone clicking. It is countable by construction.

Slack's half is a sentence somebody wrote. "Ignore the exec dash for now, Priya's sheet is the real number." That has no ID, no schema, no foreign key, and no consistent vocabulary. It was typed at 4pm on a Thursday by a person who was not thinking about your audit.

Neither product is missing a report here. Looker's data model is complete for its own half and contains no table of sentences, because there is no warehouse anywhere that holds your Slack threads as modelled rows. Slack's data model is complete for its half and contains no concept of a dashboard, because a dashboard is not a Slack object. The join lives in neither product's world, which is why no amount of configuration inside either one produces it.

It is worth being clear about the neighbouring tools, because they are good and the distinction matters. Zapier and Make will connect Looker and Slack cleanly, and if you want a link posted when a schedule fires, use them. But they are trigger based: they run when something happens and move a record forward. They cannot look backward across six months of history that already happened and reach a conclusion about it. That is a different shape of question, not a harder version of the same one. And BI tools, including Looker's own conversational layer and Power BI Copilot, connect to databases and modelled sources. They answer questions about data that has been modelled. An unstructured thread is not outside their skill, it is outside their input set. You could build the whole thing in Retool, and some teams should, as long as you are prepared to write the URL matching, the name matching and the reading step yourself.

What a real dashboard usage audit has to join

There is a hard key and a soft one.

The hard key is the dashboard ID in the URL. Looker URLs look like /dashboards/447 for user-defined dashboards and /dashboards/model_name::dashboard_slug for LookML ones, and that same ID appears in System Activity's Dashboard Explore. Extract IDs from Slack message text, match on exact ID, done. This half is a join, and a computer does it perfectly.

The soft key is everything else, and it is the majority. Name references with no link. Nicknames. Dashboards that were renamed six months ago and are still called by the old name. Three near duplicates where one is called "Copy of Exec Overview." Matching those to real Looker titles requires holding the title list in mind and reading the sentence, which is fuzzy work with a real error rate.

Then comes the judgement call, which is not matching at all. A mention is not automatically engagement, and engagement is not automatically value:

Note the trap in row three. A dashboard everyone is complaining about generates the most conversation in the workspace. Rank by mention count and the single most broken dashboard you own comes out on top. Distinguishing "we rely on this" from "this is wrong, do not use it" means reading the thread and understanding it. That is the part that cannot be a join condition.

How you would answer this with Skopx

Skopx connects Looker and Slack, along with nearly 1,000 other tools and your databases, to the same chat. So the question gets asked once, in one sentence:

"Pull every Looker dashboard with fewer than five views in the last 90 days, with owner and folder. Then search the last six months of Slack for anyone linking or naming those dashboards, including nicknames. Tell me which ones look genuinely dead and which ones are quietly load bearing, and quote the Slack message that changed your mind."

It reads System Activity through Looker's API, searches Slack with the permissions your account already has, matches the exact IDs, reads the fuzzy references, and comes back with a shortlist where every verdict cites the specific message and the specific usage row behind it. Then you keep going in the same thread: "show me the ones where the discussion sounds like people distrust the numbers."

Once the answer is useful more than once, you describe it as a standing console and Skopx builds one from that description, which is what Internal Apps does. One table: dashboard, owner, folder, views in 90 days, distinct human viewers, last opened, Slack references with the most recent quote and channel, and a verdict column. Filter by folder or owner. Open it, and it reads live from both sides.

It reads and it acts, and the only write is a button a person clicks. Here that button is "ask the owner," which sends one Slack message to the dashboard's owner asking whether it can be archived, with a confirmation before it sends. The console stores nothing. There is no form, no record created, no scheduled run, no alert, no public link.

What this does not do

It sees what your Slack account sees. Discussion that happened in a private channel or a DM you are not in is invisible, so a dashboard argued about entirely inside a closed exec channel will look dead. Screenshots are a real blind spot: an image with no link and no name carries no text to match on, and the Pipeline Coverage case that started this article is exactly the case a text search can miss unless someone also typed the name.

It does not measure value. A dashboard the CFO opens once a quarter before a board meeting outranks one that gets opened daily by people who do nothing with it, and no usage metric will tell you that. It does not see discussion that happened in email, in Notion, or out loud in a meeting.

And the verdict column is a judgement, produced by reading, with the reasoning shown so you can disagree with it. Treat the output as a shortlist to take to the owners, not a delete list to execute. The point is not that the audit runs itself. It is that the half of the evidence that was previously unreachable, the part somebody typed in a thread, finally sits next to the part Looker already counted.