DONT FORGET TO REPLACE ME LATER

整体逻辑已经不错,但如果目标是 30–45 分钟、听众熟悉 Tableau 但不了解 Looker,而且希望他们听完愿意 adoption,我会做一个比较重要的调整:

现在这版有点像“完整介绍 Looker”。我会把它改成“从我们真实的问题出发,解释为什么这个场景需要 Looker,然后教大家最少够用的 Looker”。

也就是始终围绕一个主线:

We don’t need another dashboard tool. We need a better way to deliver governed analytics to external dealers.

这样整场 presentation 会更像一个 story,而不是 product training。

Slide 1:开场不要马上塞太多信息

你现在第一段把 trustworthy dashboards / external dealers / embedding / access control / agenda 全说了,有点重。

我会这样开:

Thanks everyone for joining. Today we’re going to talk about Looker.

But I don’t want this to be just another “here’s a new BI tool and here are all its features” presentation.

Instead, I want to start with a problem we actually have: how do we securely share dashboards with external dealers without creating a lot of manual access-management work?

That’s the problem where I think Looker becomes really interesting.

So today I’ll show you why, how it compares with Tableau, how you actually build something in Looker, and then we’ll look at a real example.

这个开场更自然,而且给大家一个问题,让他们想知道答案。

Slide 2:Agenda 可以非常快

不需要把 agenda 每项解释一次。

Here’s the plan for today.

We’ll start with the problem and why Looker makes sense for this use case. Then I’ll compare it with Tableau, walk through how you build a dashboard, spend some time on access control, and finish with a live demo.

Since most of you already know Tableau, I’ll use Tableau as a reference point throughout the presentation.

最后一句很好,因为直接降低听众心理门槛:

“我不用重新学一个完全陌生的东西。”

Slide 3:这是整场最重要的一页

你现在这页的核心非常好,但第一句:

We just build a dashboard, we don’t just report internally.

不太自然。

我会改成:

Let’s start with the problem.

Building the dashboard itself usually isn’t the hardest part.

The harder part starts when we want to put that dashboard in front of external dealers.

Now we have to answer a completely different set of questions:

Who can access it?
How do they authenticate?
How do we make sure Dealer A can’t see Dealer B’s data?
And when a new dealer comes onboard, who manages that access?

Suddenly, what looked like a dashboard project becomes an identity and governance problem.

So the real question isn’t:

“Can we build the dashboard?”

It’s:

“Can we deliver the right dashboard to the right dealer, with the right data, without manually managing every user?”

That’s the problem Looker helps us solve.

我认为这个版本比原稿更强。

尤其最后这个 framing:

right dashboard → right dealer → right data → minimal manual management

后面每一页都可以回来 pay off 这四件事。

Slide 4:Why Looker,不要说成三个 feature

现在是:

Governed metrics / Embedding / Access control

我会让它继续回答上一页的问题:

So what does Looker give us that makes this easier? Three things.

First, trusted metrics.

Looker gives us a centralized modeling layer called LookML. Instead of defining the same business metric differently in multiple dashboards, we define it once and reuse it.

Second, embedding.

We can put the dashboard directly inside paccar.net, so dealers consume the analytics in a platform they already use.

And third — probably the most important for this use case — access control.

We can reuse the identity and entitlement information we already have through PASS rather than manually managing every dealer inside the BI tool.

So if I had to summarize the value proposition in one sentence:

Looker gives us a governed way to deliver trusted analytics to external dealers at scale.

我会把你原来的:

there’s only one number

稍微弱化。

Central semantic layer 能显著减少 metric inconsistency,但并不意味着组织里技术上“只能存在一个数字”。说:

one governed definition

更准确。

Slide 5:Tableau vs Looker 我会特别小心

这页是我觉得目前最需要修改的地方。

现在:

Looker = external/governed
Tableau = internal/exploratory

作为你们团队的 use-case guideline 可以,但不要讲成两个产品本身能力上的绝对区别。Tableau 本身也有 embedding、row-level security 和 governance 能力。

所以建议说:

Now, this doesn’t mean Looker is better than Tableau.

And it definitely doesn’t mean we’re replacing Tableau.

The way I think about it is: which tool fits our use case better?

For the dealer-facing use case we’re talking about today, Looker fits very naturally because the governed model, embedding, and our existing PASS integration work together.

For a lot of our internal analytics, Tableau is still a very good fit — especially when we want flexible visualization and fast exploratory analysis.

So this isn’t really Looker versus Tableau.

It’s about choosing the right tool for the use case.

然后你可以给团队自己的 rule of thumb:

For our current environment, I would start with Looker for governed dealer-facing reporting, and Tableau for many of our internal analytical use cases.

注意这里加了:

for our current environment

这就非常专业。

不是说 Tableau “做不到”,而是说你们当前 architecture/integration 下,Looker 对这个 use case 更合适。

Slide 6:Concept Map 可以做得很轻松

这一页非常适合互动:

Now, if you’re thinking, “Okay, but I know Tableau — how much do I have to relearn?” The good news is, not that much.

Here’s my mental translation.

An Explore is roughly where you explore your data.

A Look is a saved query or visualization.

And a dashboard is still a dashboard.

The biggest conceptual difference is LookML.

In Tableau, we’re used to putting quite a bit of logic into the data source or workbook. In Looker, much more of that reusable business logic can live centrally in the model.

Once you understand that difference, the rest starts feeling pretty familiar.

我不建议说:

Tableau data source = Looker Explore
Tableau worksheet = Looker Look

然后让大家认为是一对一 equivalent。

所以口头用:

roughly / mental translation / closest equivalent

更准确。

Slide 7:Build Dashboard,这页应该让大家觉得“原来不难”

So what does building something actually look like?

At a high level, it’s five steps.

Connect → Model → Explore → Save → Build.

First, we connect Looker to the warehouse.

Second, the reusable business logic is defined in LookML.

Then for most dashboard development, this is where you’ll spend your time — inside Explore.

You select the dimensions and measures you need, build the visualization, save something you want to reuse, and then assemble those pieces into a dashboard.

So if you’re already comfortable building dashboards in Tableau, the dashboard-building part isn’t the big learning curve.

The new concept is really the governed modeling layer underneath it.

这个比解释每一步更适合 knowledge share。

然后 live demo 再 show detail。

Slide 8–9:我会把它们变成整场的高潮

因为前面已经一直在铺:

governance problem

现在终于回答它。

Slide 8

Now let’s come back to the problem we started with: how does a dealer actually get access?

There are really two questions we have to answer:

Number one: what content are you allowed to open?

Number two: once you’re inside, what data are you allowed to see?

Those are two different authorization problems.

When a dealer comes through paccar.net, PASS handles their identity. Their group information then becomes part of the authorization flow.

At the content level, that determines which dashboard they’re allowed to access.

Then separately, row-level security determines which dealer’s data they can see.

So two dealers can access the same dashboard but see different data.

That’s the distinction I want you to remember: content access versus data access.

这比一开始就解释 SSO → PASS → group → Looker 更容易听懂。

先 conceptual model,再 architecture。

Slide 9:这里一定要避免 overclaim

我会把:

no dedicated access team
zero-touch
self-sustaining

这些词稍微收一点。

因为别人很容易 challenge:

谁管理 PASS group?
谁管理 entitlement?
谁管理 row-level mapping?
谁处理 exception?

你真正有证据支持的应该是:

we don’t need to manually provision each dealer in Looker

这已经很强了。

所以:

Here’s where the operational benefit comes in.

We’re not manually creating and managing each dealer inside Looker.

We reuse the identity and entitlement information that already exists in PASS.

For existing dashboards, that means onboarding can flow through the existing identity process rather than becoming a separate BI access-management process.

And when we introduce a new dashboard, we add the appropriate group-to-dashboard mapping in the application configuration.

So we’re reusing an existing access-control system instead of building and maintaining a separate one specifically for analytics.

这句话比:

access runs itself

技术上 defensible 很多,同时 business value 没有下降。

Slide 10:Live demo 不要只是 demo features

这里我建议你一定采用一个 scenario:

Let’s pretend I’m building a dealer scorecard.

然后一路走:

Here’s the Explore → here’s the metric → here’s the filter → here’s the Look → here’s the dashboard → here’s what dealer sees.

开场:

Rather than showing you random Looker features, let me walk through one real workflow.

Let’s say I want to build a dealer scorecard.

I’ll show you where the data comes from, how I explore it, how I turn that into a dashboard, and then how that dashboard fits into the dealer access model we just talked about.

这样 demo 和前面 story 是一个整体。

不是:

presentation 讲完 → 现在随便看看 software。

Slide 11:Takeaways 我建议只留三个

你现在四个其实稍多。

我会变成:

If you remember only three things from today, remember these.

First: Looker isn’t just another visualization tool. For our dealer-facing use case, the real value is the combination of governed metrics, embedding, and access control.

Second: this isn’t about replacing Tableau. We’re choosing the tool that best fits the use case.

And third: if you already know Tableau, the learning curve for building basic content in Looker is pretty manageable. The biggest new concept is the modeling layer underneath it.

And that brings us back to the question we started with:

How do we deliver the right dashboard to the right dealer with the right data?

That’s the problem Looker helps us solve.

然后:

That’s everything I wanted to cover. What questions do you have?

非常干净。

我还会改你 Q&A 里面的一个重要答案

你现在:

Why not just embed Tableau for dealers?
You can embed Tableau, but you’d rebuild the governance and per-dealer access story yourself.

这个说得太绝对,容易被懂 Tableau Server / Embedded Analytics 的人 challenge。

建议:

Tableau can absolutely support embedded analytics and row-level security. The question for us is less about whether Tableau can do it and more about which option fits our existing architecture better.

In this use case, Looker’s governed modeling layer and the integration we’ve already built around paccar.net and PASS make it a natural fit. So it’s more about reducing integration and operational overhead than saying Tableau can’t support the use case.

这个回答层次高很多。

你整场 presentation 的“主线句”

如果让我只给你一张小抄,我会让你记这 6 句话:

Building the dashboard isn’t the hard part.

The hard part is getting the right dashboard, to the right dealer, with the right data.

That’s where Looker becomes interesting.

This isn’t Looker versus Tableau — it’s about choosing the right tool for the use case.

There are two authorization questions: what can you open, and what data can you see?

We’re reusing an existing access-control system instead of creating a separate one for analytics.

只要这六句话贯穿始终,你即使现场某些 wording 跟 transcript 完全不一样,整个 presentation 依然会显得非常有逻辑。

而且这其实和你前面 Grill Me 的例子形成了一个很有意思的呼应:你原来可能会让 AI 给你做一个 “Introduction to Looker”,但问清楚 strong why 以后,它应该变成:

不是教大家 Looker 有哪些功能,而是回答——为什么我们有一个 Tableau 已经很好用的情况下,仍然需要 Looker 来解决特定的 dealer-facing analytics 问题。

这个才是这场 knowledge share 最值得讲的东西。