What is website analytics, and how do you build it in Metabase?
Website analytics treats your site as an operation: the content it publishes, the traffic that content earns, the orders and leads the site captures, and the members it keeps. In Metabase, build it by connecting directly to self-hosted CMS databases (WordPress, Strapi, Ghost) or syncing hosted-platform APIs (WordPress.com, Wix, Webflow) into a SQL database — then joining content to search, analytics, and revenue data on the one key every source shares: the URL.
TL;DR — Self-hosted CMS databases are already Metabase data sources: connect read-only and skip ETL. Hosted platforms need scheduled API syncs — start before retention windows (Wix: 62 days) eat your history. Normalize URLs once; every cross-source join depends on it.
What does website analytics measure?
- Is the publishing engine producing — by author, type, and cadence?
- Which content earns traffic, engagement, and conversions?
- What has gone stale, and what is it still worth in search?
- What does the site sell, and is conversion improving?
- What do forms capture, and where do those leads go?
- Are members and subscribers growing — free and paid?
- Does site history survive the platform's retention window?
Which tools feed website analytics?
| Tool | Best for | Getting data into Metabase |
|---|---|---|
| WordPress | Publishing velocity by author and category; Content inventory and freshness audit | Direct MySQL connection, WordPress REST API, or MCP |
| WordPress.com | Views and visitors trend by day; Top posts and pages by views | WordPress.com REST & Stats APIs, pipeline, or WordPress.com MCP server for exploration |
| Wix | Sessions and unique visitors trend; Store revenue, orders, and AOV | Wix Analytics Data & eCommerce APIs, pipeline, or Wix MCP server for exploration |
| Webflow | Content inventory by collection and status; Form submissions by form and week | Webflow Data & Analyze APIs, pipeline, or Webflow MCP server for exploration |
| Ghost | Member growth: free vs. paid by week; MRR trend and paid-conversion rate | Direct MySQL 8 connection, Ghost Admin API, or MCP |
| Strapi | Entries created and published by content type; Draft backlog and time-to-publish | Direct PostgreSQL or MySQL connection, Strapi REST API, or MCP |
| Google Search Console | Search clicks per page | BigQuery bulk export, connector, or API |
| Google Analytics 4 | Sessions and conversions per page | Native BigQuery export or connector |
What shared data models should you build?
Build clean models on top of raw CMS tables and synced stats so each dashboard uses the same definitions.
content_items— one row per real published item (revisions and autosaves filtered out), with type, author, status, and datessite_traffic_daily— one row per site per day, with views, visitors, and sessions from whichever stats source you trustpage_performance_daily— one row per URL per day, joining content metadata to search clicks and analytics sessionsordersandorder_lines— commerce data from WooCommerce, Wix, or Webflow, modeled like any storeform_submissions— one row per submission, with form, page URL, and UTM fields for attributionmembersandmrr_daily— subscriber records and daily revenue snapshots for membership sitesurl_map— the normalization table (lowercase, no protocol, no trailing slash) every cross-source join runs through
Which website metrics matter most?
- Publishing throughput — real items published per week, by author and type.
- Organic clicks & impressions — what search sends each piece of content.
- Conversion rate — form fills or orders over sessions, per page.
- Average order value — for site commerce, alongside order volume.
- Repeat purchase rate — whether the store keeps its customers.
- MRR and churn rate — the membership pair, snapshotted daily.
- Click-through rate — newsletter engagement for publications.
How do you connect website platforms to Metabase?
- Direct database — for self-hosted CMSs: a read-only connection to MySQL or Postgres, models on top, zero ETL.
- MCP + CLI — pull a scoped export through the platform's MCP server and load it with
mb upload csvfor quick analysis. - Scheduled API sync — for hosted platforms: land daily stats, orders, and content metadata in your own database before retention windows drop them.
Which dashboards should you build first?
- Content performance — publishing cadence joined to traffic and engagement per post.
- E-commerce sales — orders, revenue, and AOV from site commerce data.
- Organic search performance — what search sends the content, from GSC.
- MRR — subscription revenue for membership sites.
- Lead funnel — form submissions through to qualified leads.
Common mistakes
Counting revisions and autosaves as content.→ A WordPress site with 800 posts has thousands of wp_posts rows. Filter to real, published types once in the model — or every count is fiction.
Letting hosted-platform history expire.→ Wix keeps 62 days of analytics; other platforms have their own windows. The sync you schedule today is the only source of next year's trend.
Joining sources without URL normalization.→ The CMS says /Blog/Post/, analytics says blog/post?utm=x, GSC says https://www.site.com/blog/post. Normalize once in a shared step or joins silently drop rows.
Comparing content by lifetime totals.→ Old posts always win lifetime comparisons. Compare traffic per post by time-since-publish windows (first 30/90 days) to judge recent work fairly.
Querying the production CMS database for analytics.→ Use a read replica and a read-only user. An analytics query scanning wp_posts during a traffic spike is a self-inflicted outage.
Related
Integrations
Analytics
Terms
FAQ
What is website analytics?
Website analytics, as built here, is reporting on the site itself as an operation: what content exists and how fast it ships, what traffic it earns, what the site sells, what its forms capture, and who subscribes. It starts from the website platform's own data — the WordPress database, Wix stats and orders, Ghost members — landed in a SQL database and analyzed in Metabase next to search and analytics data.
How is this different from Google Analytics?
GA4 measures visitor behavior; it knows nothing about your content operation. Website analytics joins both sides: the CMS knows what was published, by whom, when, and in what state; GA4, Plausible, and Search Console know who arrived and what they did. Joined on URL in a warehouse, they answer questions neither side can alone — output per author versus traffic earned, stale content still winning search, forms that convert.
How is website analytics different from marketing analytics?
By starting point and audience. Marketing analytics starts from acquisition spend and attribution — a demand-gen view. Website analytics starts from the site: content operations, site commerce, membership. They share a warehouse and meet at traffic, but a content team asks "is our publishing engine working?", not "what did this campaign return?"
What is the fastest way to analyze a self-hosted CMS?
Connect Metabase to the CMS database directly — no ETL. Self-hosted WordPress (MySQL), Strapi (Postgres or MySQL), and Ghost (MySQL 8) all expose content, users, members, and commerce tables Metabase queries natively. Use a read-only user on a replica, wrap the raw tables in Metabase models, and content dashboards exist by the end of the afternoon.
What about hosted platforms like Wix or WordPress.com?
They don't expose databases, so sync through APIs on a schedule. WordPress.com serves real daily traffic time-series through its Stats API; Wix serves analytics (62-day retention — sync early) and eCommerce orders; Webflow serves CMS items, forms, orders, and traffic through its Analyze API beta. Land daily rows in your own database and the retention windows stop mattering.
Can I measure content ROI with this?
You can get close. Chain the joins: content metadata (CMS) → search clicks per URL (Search Console) → sessions and conversions per URL (analytics) → revenue (orders or CRM). The honest caveats: attribution beyond last-touch is a modeling choice, and content compounds — measure traffic per post by time-since-publish, not calendar totals that favor old posts.
Which dashboards should you build first from website data?
Start with content performance — publishing cadence joined to traffic per post. If the site sells, add e-commerce sales from order data. Membership sites add MRR and member growth. Then organic search performance connects the content to what search sends it.