Naming as Strategy Failure · The Google Marketing Stack • Hoshank Ailani

A Google Cloud sales team is in a procurement meeting some time in 2023, asking a large enterprise to sign a Looker contract worth six or seven figures a year. Somewhere in the second half of the meeting, a finance stakeholder who has not spoken yet asks the obvious question. Isn’t Looker Studio the free thing the marketing intern uses to build dashboards? The answer is yes, that product exists, it is free, and it shares no code, no data model, and no engineering team with the one on the table. It shares a name because Google decided in October 2022 that it should. In April 2026 Google undid that decision. The round trip took three and a half years, and it is the cleanest available evidence for a claim this whole book has been making: the Google marketing stack is an assemblage of separately acquired and separately built products, presented as a suite, and the naming keeps giving that away.

March 2016: A Free Visualization Tool Arrives Inside an Enterprise Suite

Data Studio was announced on March 15, 2016, as one of six products in the Google Analytics 360 Suite, alongside Analytics 360, Tag Manager 360, Optimize 360, Attribution 360, and Audience Center 360 (Google, 2016). It was called Data Studio 360, it shipped in limited beta, and its pitch was that it turned data from across the suite and from outside it into interactive reports with real-time collaboration built on Google Docs infrastructure (TechCrunch, 2016).

A free tier followed within months, and the free tier is what actually mattered. Data Studio became the default reporting layer for hundreds of thousands of agencies and in-house marketing teams, not because it was powerful but because it was free, browser-based, shareable by link, and connected to the Google products those teams already used. It grew into an ecosystem: over six hundred partner connectors and thirty-six chart types today (PPC Land, 2026). It was never an enterprise business intelligence product, and Google never charged for the thing most people used.

June 2019: Google Buys a Different Product Entirely

On June 6, 2019, Google announced it would acquire Looker in a $2.6 billion all-cash transaction, closing the deal in February 2020 (Alphabet investor relations, 2019). Looker was a Santa Cruz company selling enterprise BI built around LookML, a version-controlled modelling language in which analysts define dimensions, measures, and joins once, and everyone downstream queries those governed definitions rather than writing their own SQL (TechCrunch, 2019).

The distinction between the two products is not cosmetic. It is the difference between a charting tool and a semantic layer.

	Data Studio	Looker
What it is	free report and dashboard builder	enterprise BI platform
Metric definitions	per-report, per-author, unversioned	LookML models, defined once, governed centrally
Source of truth for “revenue”	whatever each report author wrote	one model definition every report inherits
Version control	none	LookML lives in git
Embedding and delivery	share a link	embedded analytics, APIs, row-level permissions
Price	free, plus a paid Pro tier	six to seven figures annually
Team that built it	Google, internal, 2016	Looker Data Sciences, acquired 2019

There is no shared lineage. LookML is not a Data Studio feature and never became one.

October 2022: One Name for Two Unrelated Things

At Cloud Next in October 2022, Google announced that Data Studio was joining the Google Cloud product family and being renamed Looker Studio, on the stated logic that Looker would become the brand for all Google Cloud business intelligence products. A paid tier, Looker Studio Pro, launched alongside it with enterprise collaboration and management features (Looker Studio, product history).

Read as a brand exercise, the reasoning is legible. Google had spent $2.6 billion on a BI brand and had a much larger free user base sitting under a different name. Consolidating them promised to move Data Studio’s users toward Cloud and lend the free product some enterprise credibility.

Read as a positioning exercise, it inverted the value flow. Brand consolidation transfers association in both directions, and the direction that dominates is determined by volume. Data Studio had vastly more users than Looker had customers. So the shared name did not make Data Studio look enterprise-grade. It made Looker look like the paid version of a free tool, which is the single most expensive misconception a six-figure BI contract can carry into a procurement review. Every Looker seller spent the next three years explaining that their product was not the other product. Every Data Studio user spent the same three years landing on Looker documentation about LookML models they did not have.

April 2026: The Round Trip Completes

On April 10, 2026, Google announced that Looker Studio would be renamed Data Studio, with Looker Studio Pro becoming Data Studio Pro, and the change shipped on April 16 alongside a refreshed home page (Google Cloud blog, 2026). The official framing is a clean split of purpose: Data Studio is the home for personal data exploration and ad hoc reporting, and Looker remains the enterprise platform built on governed semantic models. Coverage was blunter about the reason, describing a three-and-a-half-year experiment reversed because enterprise buyers would not pay enterprise prices for something sharing a name with a free product (PPC Land, 2026).

Nothing broke for users. Reports, data sources, and permissions carried over. The rebrand shipped with real functional additions, including BigQuery conversational agents and Colab data apps under the same roof, and the free-plus-Pro tiering stayed.

A designed product family does not need to test a brand name for years, on two unrelated products, and then revert it. PNG ↓

What the round trip demonstrates is that the suite was never designed as a suite. A designed product family does not need to test a name for three and a half years and then revert it, because the boundaries between its products would have been decided when they were built. Google’s marketing and analytics stack has boundaries that were decided by acquisition dates and by which internal team happened to own a surface. Urchin became Analytics. DoubleClick became Campaign Manager and Ad Manager. Adometry became Attribution 360. Looker became Looker and briefly also became Data Studio. The 2018 rebrand that produced the Google Marketing Platform and Google Ads names was an org-chart document as much as a branding one, and the Looker Studio round trip is the same phenomenon, running in reverse, in public, seven years later.

The connector ecosystem is the same evidence in a different form. Data Studio’s six hundred-plus partner connectors, plus a community connector framework anyone can build against, exist because the products a marketer needs in one report do not share a query layer. Google Ads, Search Console, GA4, Merchant Center, YouTube, and Campaign Manager each expose a different API with different dimensions, different date semantics, different attribution definitions, and different quota rules. A designed suite would have solved that once, underneath. Instead the join happens at the top, in a feature called blended data that performs a left outer join between connector results inside a chart definition. It works. It is also the clearest possible statement that no shared semantic layer exists beneath it, and it is why the same “conversions” number can differ between two reports in the same file depending on which connector supplied it.

The renaming, then, is not a communications failure sitting on top of a well-built system. It is what a well-built system’s absence looks like from the outside. Boundaries between products in this stack were drawn by acquisition dates, by which team owned a surface, and by which business unit needed a story for a keynote. When those boundaries are wrong, the visible symptom is a name, because names are the cheapest thing to change and the last thing anyone gets around to.

There is a practical reading of this beyond the anecdote. Naming is the cheapest signal you get about whether two products in this stack actually integrate. When Google gives two things the same name and they do not share a data model, the shared name is a claim about strategy rather than a description of architecture, and it will eventually be corrected by whichever side of the business is losing revenue to the confusion.

Three Glue Roles and One Lossless Path

Part VI covered three products that look unrelated and are not. Each governs a different contract in the stack, and each is a place where a mistake propagates silently rather than failing loudly.

Google Tag Manager governs collection. It decides what fires, in what order, carrying what payload, under what consent state. A dataLayer field renamed in a redesign changes what every downstream system believes happened. Chapter 18 covered the mechanics; Consent as an API covers the legal layer bolted onto it.

Merchant Center governs the product-data contract. It decides what Google Ads is allowed to bid on and at what stated price. A stale availability value removes inventory from the auction, and a price mismatch severe enough to look deliberate removes the account. The dependency from the Ads side runs one way: Performance Max cannot bid on products the feed has not successfully declared.

Data Studio governs presentation. It decides what the organization believes about the first two, which in practice means it decides what gets funded next quarter.

Now the part worth ending on. Of every path data can take across this stack, exactly one is lossless: GA4’s BigQuery export. It writes event-level rows into a dataset you own, with nested event_params, items, traffic_source, collected_traffic_source, and privacy_info records preserved, and it ships in the free tier rather than requiring 360 (GA4 BigQuery Export schema). Every other route is lossy in a specific, documented way:

GA4’s own UI applies cardinality limits and data thresholding, so high-cardinality dimensions collapse into an “(other)” row and small segments are withheld entirely. The Death of the Session covers why the event model makes this unavoidable in the interface.
Data Studio’s BigQuery connector defaults to twelve-hour cache freshness, so a dashboard can show yesterday’s warehouse state without saying so (Manage data freshness).
The Extract Data connector, the standard fix for slow reports, caps an extract at 100 MB and refreshes on a schedule, which quietly turns a live report into a snapshot (Extract data for faster performance).
The Google Ads, Search Console, and GA connectors are subject to API quotas, so a heavily viewed dashboard can fail on request volume rather than on query correctness.
The new BigQuery conversational agents inside Data Studio cap results at 5,000 rows per query (PPC Land, 2026).
And Data Studio still has no LookML equivalent, meaning no governed metric definitions and no version control, which is precisely the gap the paid Looker product exists to fill and precisely why the shared name was untenable.

None of these limits is a defect. Each is a reasonable engineering tradeoff for a free tool serving a very large number of reports. The mistake is treating a number in a dashboard as the number, when the number has passed through a sampled interface, an aggregated connector, a cached query, and a 100 MB extract on its way to the screen. Land the raw events in a warehouse you control, define your metrics somewhere version-controlled, and treat the reporting layer as a rendering surface rather than as a source of truth. That advice survives every rename Google has coming.

Key Sources

Source	Author/Org	Year	Link	Why it matters
Introducing the Google Analytics 360 Suite	Google	2016	blog	Dates Data Studio’s launch to March 15, 2016, inside an enterprise suite
Google announces Analytics 360 Suite for enterprise marketers	TechCrunch	2016	article	Contemporaneous description of Data Studio 360’s original positioning
Google to Acquire Looker	Alphabet investor relations	2019	press release	The $2.6 billion all-cash figure and the June 6, 2019 announcement date
Google to acquire analytics startup Looker for $2.6 billion	TechCrunch	2019	article	Describes LookML and the governed semantic layer that Data Studio never had
Looker Studio (product history)	Wikipedia	2022	entry	The October 2022 rebrand and the launch of Looker Studio Pro
Looker Studio is Data Studio	Google Cloud blog	2026	blog	The April 2026 reversal and Google’s stated split of purpose
Data Studio is back: Google kills Looker Studio name for good	PPC Land	2026	article	The enterprise-pricing reason for the reversal, plus connector, chart, and row-cap figures
GA4 BigQuery Export schema	Google Analytics Help	current	help doc	The event-level schema that makes the BigQuery export the only lossless path
Manage data freshness	Data Studio Help	current	help doc	Twelve-hour default cache on BigQuery sources
Extract data for faster performance	Data Studio Help	current	help doc	The 100 MB extract cap that turns live reports into snapshots

PM Lens

I have watched more than one review meeting stall on the question of whose number is right, and the answer is almost always that both numbers are right and nobody wrote down what either one means. That is a semantic-layer problem, and a free charting tool cannot solve it, which is the real content of the Looker Studio round trip rather than a branding anecdote. My working rule on the DSP and exchange side is that any metric appearing in a recurring executive report needs a definition living in version control, next to the query that produces it, with a named owner. The corollary is architectural: get event-level data into a warehouse you control, because every reporting surface above it is sampled, thresholded, cached, or quota-limited, and none of those will announce themselves in the chart. The other habit I would recommend is treating Google’s product names as loose descriptions rather than statements of integration, and asking instead which team owns the surface and whether the two systems share a data model. Naming is the last thing a company fixes and the first thing that reveals how the org chart is actually shaped.