Switched from Tableau to Looker, here's the pricing difference

You're hitting on the real business model shift here. It's the difference between buying a fleet of cars (seats) and paying for a toll road (consumption).

That financial governance change is huge. Our finance team initially loved the flat invoice, but they struggled with the concept of "what if we're too successful?" More user adoption and better data literacy, which are goals, directly increase the cost. It inverts the incentive.

We had to start treating it like a cloud bill, with showback reports per department. It created friction, but also accountability.

Yeah, that's the exact mental shift that's required. >Now the finance team needs to understand query patterns< is the key. It forces you to build a whole new attribution layer.

We ended up tagging our explores and dashboards with department codes in LookML (like `finance_`, `sales_`). It's a manual pain, but then we could pipe usage logs to our data warehouse and build a crude showback report. Without something like that, you're right, it's just a black box of cost.

The weird side effect? It made teams more cost-aware. A marketing analyst suddenly thinks twice about that 20-column export because they see it hits their "budget." It's good governance, but it's definitely a new operational tax.

That manual tagging approach is exactly the right path, though the operational tax you mention can become unsustainable. I've seen teams try to scale that and drown in LookML merge conflicts and forgotten tags.

We automated it by having our CI/CD pipeline enforce tagging based on the Git repo path a model lived in, e.g., everything in `models/marketing/` got an auto-generated `department: marketing` tag. It required restructuring our LookML project, but it removed the human error and constant manual upkeep. The cost showback became reliable enough that we could actually charge back, not just report.

The side effect you noted is real, but it also creates friction for legitimate exploration. We had to carve out a "sandbox" tier with a capped LU budget for experimental work, otherwise innovation got stifled by analysts afraid to run a query.

Automating tags in CI/CD is a smart move to avoid the merge conflict mess. It shows the real cost isn't just the license, it's the internal devops work to make this billing model functional.

I'm worried about the sandbox tier, though. Who funds that central pool? And how do you stop teams from just doing their "experimental" work there permanently to avoid their own showback?

Yeah, the power user vs casual viewer split is real, and it's exactly why per-user pricing felt "fair" even when it was expensive.

>Have you found a good way to attribute usage
We had to. Our early dashboard just showed aggregate LU burn, which led to finger-pointing. The real unlock was using the Looker API to pull the `history` and join it on our user directory (we pipe it to BigQuery nightly). That tags every query to a person, and then we map people to cost centers. It's a bit of a plumbing job, but now I can tell you the finance team's fancy custom explores cost 3x what the whole sales org spends on viewing dashboards.

Turns out, showing individuals their own usage is the best behavior modifier. One analyst was running a massive query on a schedule for a personal spreadsheet. That stopped fast.

The consolidation benefit you're seeing is valid, but that >all-in annual commitment< is a forward estimate, not a fixed cost like your Tableau contract. You're now on the hook for accurately predicting aggregate user behavior for the year.

A key piece is benchmarking your initial Looker Unit allocation. Did you back into it from a sample month of Tableau query logs, or was it based on a vendor-provided model? The variance between those two methods can be significant.

Forecasting licenses is easy, it's headcount. Forecasting compute is predicting human behavior. One is administrative, the other is psychological.

You're spot on about the true-up being the vendor's goal. The initial deal is just the hook. The real price is discovered later, when your own team's activity becomes the meter.

Exactly. That's why forecasting turns into a bureaucratic game of setting internal budgets before you even sign the contract. You're forced to pre-allocate Looker Units across teams based on a guess, which creates instant internal tension.

We had to create a whole internal rate card and forecasting spreadsheet, arguing with VPs about whether their team was a "heavy explorer" or "dashboard viewer only." It's all psychological estimation disguised as financial planning.

The true-up is absolutely the goal. Our first year, we came in 40% over our committed LUs. The discount we got for the annual commitment was completely wiped out by the overage fees. The next year, we padded our forecast by 30% just to be safe, which meant we were prepaying for capacity we were scared to use.

Spot on about the true-up being the vendor's goal. The "initial discount" is just a loss leader to get you hooked on the consumption model.

But I'll push back slightly on the finance team being the weak link. The real failure is usually in procurement and IT leadership signing a deal without the instrumentation to meter it from day one. You can't manage what you can't measure, and committing to a year of LUs without a tagging/attribution pipeline is just writing a blank check.

Finance gets the Friday calls because they're holding the bag for a technical debt that was signed off months earlier.

Your point about tracking "burdened engineering minutes per dashboard" is critical, and it's a metric more teams should formalize. The hidden labor cost often exceeds the platform's sticker price, especially when you factor in the opportunity cost.

One nuance I'd add: this internalization also changes the skill profile you need on staff. A Tableau consultant often specializes in visual storytelling and stakeholder management. When that work shifts to a data engineer, you're asking someone optimized for pipeline reliability and data modeling to also become a UI/UX expert and a business translator. That mismatch can inflate those "burdened minutes" significantly, as the engineer spends cycles on tasks outside their core competency.

The worst-case scenario isn't just paying for both systems concurrently, but the knowledge debt incurred when the original consultant's context isn't fully transferred. You end up with a senior engineer reverse-engineering business logic from a pile of legacy workbooks, which is the least productive form of "knowledge transfer."

You're absolutely right about the skill profile mismatch. That's often quantified as the "context switching tax," and it's brutal. I've seen data engineers spend weeks building a Looker explore only for the business to reject it because the filter logic "doesn't feel right," a purely UX concern.

The "burdened minutes" metric should include the rework cycles caused by this mismatch. It's not just the initial build time. A Tableau specialist might iterate with a stakeholder in real-time during a 2-hour workshop. An engineer often works in tickets, leading to days of asynchronous back-and-forth to clarify the same requirements.

The knowledge debt point is the real kicker. We documented the business logic transfer in our migration, but we failed to capture the *discarded alternatives* - why certain visual approaches were rejected. An engineer rebuilding a dashboard often resurrects those discarded ideas, triggering the same debates the consultant already settled years ago. That's pure waste.

Great breakdown, and congrats on the initial cost savings! The consolidation benefit you mentioned is real, but I'd watch that "all-in annual commitment" closely.

Ours started lower too, but the true-up at the end of the year caught us off guard. We didn't have a good way to track usage per team at first, so we blew past our Looker Unit forecast. The annual fee ended up being more of a minimum than a fixed cost.

How are you planning to attribute LU consumption back to different departments? That was the key for us to actually keep costs in check.

Your "predictable" Tableau cost was just predictable overspending. The spreadsheet had names, but were those people actually using it? Probably half were dormant seats.

The real shift isn't from predictable to variable. It's from paying for shelfware to paying for actual usage. That's a better problem to have, even if it's noisy.

Chargeback is key, but it's step two. Step one is just showing the raw query logs. No internal billing needed. When a department lead sees their team authored 40% of all queries last month, behavior changes fast.

Agreed that showing raw logs is the first step, but I'd push back on the "better problem" part.

Turning that visibility into cost control requires tagging from day one, not just reviewing logs later. You need to map every query to a team or project at runtime, which means your auth layer or proxy needs to inject labels. If you're just looking at raw logs, you're stuck with pattern-matching usernames or dashboard titles, which breaks down fast.

The noise you mention isn't just administrative. It can lead to teams self-limiting exploration because they're afraid of the bill, which defeats the point of moving to a more flexible platform.

Exactly. The fear-based self-limitation is the killer. You spend all this money on a "modern" platform, then scare your team into using it like it's a scarce mainframe resource.

Tagging from day one is a nice theory, but it assumes your org has the maturity to define and enforce cost centers before anyone's even run a query. In reality, you're retrofitting governance onto a tool sold as "self-service."

So you get the worst of both: variable costs you can't predict, and users too nervous to explore.