No Looker Studio connector for your source? The alternative path
The search that brings most people here is oddly specific: "eBay to Looker Studio". "Fitbit to Looker Studio". "Stackby to Looker Studio". "Similarweb Looker Studio". Different tools, same moment — you opened the data source picker, typed the name of the platform your numbers actually live in, and got nothing back. This piece is about what to do next, including the option nobody in the connector marketplace has any reason to tell you about.
Why your source isn't in the list
Looker Studio's connector catalogue is really three catalogues wearing one coat, and knowing which is which explains everything about the price you're about to be quoted.
- Google connectors. Search Console, Google Analytics, Google Ads, Sheets, BigQuery, YouTube, Campaign Manager. Built by Google, free, and the reason Looker Studio feels effortless right up until it doesn't.
- Partner connectors. Built and sold by third-party vendors. This is where Facebook Ads, TikTok, Shopify, Stripe, LinkedIn, Amazon and most of the long tail live. They are commercial products, typically billed per data source per month, per account.
- Community connectors. Someone wrote one and published it. Some are excellent. Some were last touched three API versions ago and now fail silently at 4am.
So the honest answer to "why isn't eBay in here?" is: because eBay is not a Google product, and no first-party connector for it is ever coming. The catalogue looks like a feature list, but for anything outside Google's own estate it's closer to a marketplace listing — and your integration is a line item on someone else's price page.
The tell: the moment a source needs a partner connector, its cost stops scaling with how much data you have and starts scaling with how many sources you have. That's the connector tax, and it's why a five-channel report costs five times more than a one-channel report to keep alive.
The four real paths
Once you accept there's no free native connector coming, the options narrow to four. They're worth laying out plainly, because each one fails in a different place.
1. Pay for the partner connector
Fastest to working. You authorize, pick your account, and the data shows up in the picker like it was always there. The cost is a recurring subscription per source, and it compounds: each new channel is another vendor relationship, another OAuth grant to re-approve when a token expires, another status page to check when the chart goes blank. It's the right call when you have exactly one awkward source and it matters daily.
2. Land it in BigQuery and point Looker Studio at that
The "do it properly" answer, and genuinely the correct one at real warehouse scale. But it moves the problem rather than removing it: something still has to write into BigQuery. That something is either an ELT vendor — billed per connector, so you've re-bought the connector tax one layer down — or pipeline code you now own, schedule and debug. Add a warehouse bill and a schema to keep in sync with an API you don't control. For a marketing dataset measured in millions of rows rather than billions, this stack is usually several sizes too big; we argued that case in full in the smallest marketing data warehouse that actually works.
3. Export to Sheets, connect the Sheet
Free, works today, and quietly the most common thing people actually do. It's also the one that rots. Every refresh is a human remembering to re-export; every schema change from the source platform breaks a formula three tabs deep; and the dashboard gives no signal that the numbers behind it are eleven days old. It survives right up to the week someone makes a budget decision on a stale tab.
4. Skip the canvas
The option that doesn't appear in the picker, because it isn't in the picker: don't build the report in Looker Studio at all. Take the same export, hand it to a backend that normalizes it into shared cross-channel definitions, and publish the dashboard from there. You give up the drag-and-drop canvas. You get back the connector tax, the refresh ritual, and the per-source pricing model all at once.
What the fourth path looks like
This is what TableBI is built to do. Sources that support OAuth connect live; everything else arrives as a file and is normalized into the same tables. There is no picker to be absent from, because a CSV is a first-class source rather than a fallback.
# install once npm i -g @tablebi/cli tablebi login tablebi install # the sources that connect live, connect live tablebi connect gsc --site sc-domain:example.com tablebi connect ga4 tablebi connect google_ads tablebi connect meta_ads # the one with no connector anywhere: export it, label it, done tablebi connect csv --file ebay-orders-aug.csv --platform ebay
The --platform label is the part that matters. It isn't cosmetic metadata — it's what lets those rows sit in the same facts table as your ad platforms, so spend is spend and clicks are clicks no matter which of the four paths a row arrived by. That's the thing a per-source connector structurally cannot give you: connectors deliver each platform in its own dialect and leave the reconciliation to you and a blend configuration that lies.
Before querying anything, check what actually landed and how it was interpreted:
tablebi sources # every connected source + how fresh each one is tablebi schema # dimensions, measures, definition macros tablebi sample # actual rows, so you can see how the CSV was normalized
Asking across the seam
Once the awkward source is in, the question you couldn't previously ask becomes a single query — the unsupported platform sitting in the same result set as the supported ones:
tablebi ask "SELECT platform,
SUM(cost) AS spend,
SUM(clicks) AS clicks,
ctr(SUM(clicks), SUM(impressions)) AS ctr
FROM facts
WHERE date >= (SELECT MAX(date) FROM facts) - 28
GROUP BY platform ORDER BY spend DESC"
And when you need the source exactly as it reported itself — no normalization, nothing averaged away — the raw per-platform table is still there underneath:
tablebi ask "SELECT query, SUM(impressions) AS imp, AVG(position) AS pos
FROM search_console_raw
WHERE date >= (SELECT MAX(date) FROM search_console_raw) - 14
GROUP BY query ORDER BY imp DESC LIMIT 20"
Every answer comes back with a freshness block naming how old each source is, plus caveats about the ones that mislead — that Search Console lags a few days and anonymizes rare queries, that GSC clicks and GA4 sessions are different populations and shouldn't be expected to match. A CSV that hasn't been re-exported in three weeks shows up as three weeks old rather than as a confident number. That's the specific failure mode of path 3, fixed.
Publishing it
The last thing the canvas was doing for you was producing a URL someone else can open. That's one command:
tablebi pin --title "Cross-channel overview" \ --widget "Daily clicks (28d)::line=SELECT date, SUM(clicks) AS clicks FROM facts …" \ --widget "Spend by platform=SELECT platform, SUM(cost) AS spend FROM facts …" ✓ published → https://dk.tablebi.com/d/dsh_… (public, read-only, self-refreshing)
Here's a real one, pinned exactly that way — live Search Console data across a portfolio of sites. It's not a mockup; it refreshes as the sources sync: