GraphJSON vs Google Analytics 4
Google Analytics 4 excels at web and acquisition reporting; GraphJSON handles arbitrary server-side JSON events, SQL, alerts, and embedded analytics.
Google Analytics 4 and GraphJSON both use events, but they begin from different places. GA4 is a web and app analytics product with built-in acquisition, engagement, monetization, and advertising workflows. GraphJSON is a general JSON event analytics product for developers who want server-side collection, direct ClickHouse SQL, dashboards, alerts, and embeds.
The products can complement each other. The choice depends on whether your center of gravity is marketing traffic or application behavior.
The short version#
| Need | Better starting point |
|---|---|
| Traffic sources and campaign attribution | Google Analytics |
| Google Ads integration | Google Analytics |
| Standard website engagement reports | Google Analytics |
| Server-side product and business events | GraphJSON |
| Arbitrary SQL over raw JSON payloads | GraphJSON |
| Customer-facing embedded dashboards | GraphJSON |
| API, job, webhook, or device analytics | GraphJSON |
GA4 officially models interactions as events and event parameters. That makes it more flexible than older pageview-centric analytics, but its reporting model is still optimized for websites, apps, audiences, and marketing outcomes.
Where Google Analytics is strongest#
GA4 provides a large set of automatically collected and recommended events, standard reports, realtime views, explorations, audiences, and connections to the Google marketing ecosystem.
It is a strong default when you need to know:
- how visitors arrived
- which campaigns and channels convert
- which pages or screens drive engagement
- how ecommerce behavior connects to acquisition
- which audiences should flow into advertising tools
The built-in vocabulary and reports reduce setup for common marketing questions. A team does not need to design a query for sessions by channel because the product already understands that concept.
That opinionated model is the value. It can also be a constraint when the event did not happen in a browser, the payload is domain-specific, or the analysis needs direct control over the underlying query.
Where GraphJSON is strongest#
GraphJSON accepts an event from any server or system that can send HTTP:
{
"event": "report_generated",
"account_id": "acct_42",
"plan": "pro",
"format": "pdf",
"duration_ms": 1840
}
There is no requirement that the fact represent a page, screen, session, or human interaction. It can be:
- a background job completion
- an API request
- a payment lifecycle event
- a webhook attempt
- a device reading
- a customer action inside a SaaS product
The payload lands in ClickHouse-backed storage. You can explore fields through the visualizer or query the same data with SQL, then reuse the answer as a dashboard, alert, CSV, or embed.
Collection and data control#
Most GA4 implementations collect in the browser or mobile app through Google’s libraries and tagging ecosystem. Server-side collection is possible, but the product remains organized around GA properties, users, sessions, events, parameters, and reporting dimensions.
GraphJSON recommends server-side logging. The API key stays private, ad blockers do not discard business-critical events, and the application can decide exactly which fields leave its boundary. A browser-originated action can pass through a server endpoint you control.
Neither setup removes privacy responsibility. Minimize personal data, avoid credentials, define retention, and obtain any consent your jurisdiction and use case require.
Reporting model versus query access#
GA4 provides predefined reports and explorations. Those are excellent for standard questions and let non-technical teammates work within a familiar model. Large or complex explorations may be subject to product limits and sampling behavior; Google provides a BigQuery export path when teams need warehouse-level access.
GraphJSON exposes ClickHouse SQL directly in the product. A query can extract JSON fields, join collections, use window functions, or compute a custom cohort without exporting first:
SELECT
JSONExtractString(json, 'plan') AS plan,
countIf(JSONExtractString(json, 'event') = 'report_generated') AS reports
FROM product_events
WHERE toDateTime(timestamp) >= subtractDays(now(), 30)
GROUP BY plan
ORDER BY reports DESC
Direct SQL is more expressive and asks more of the person writing it. The visualizer covers common exploration so SQL remains an escape hatch rather than a prerequisite.
Embedding changes the decision#
A report for your marketing team and an analytics feature for your customer are not the same deliverable.
GraphJSON can generate secure embed URLs on your server and apply dynamic filters so each signed-in account sees only its own events. That is useful for usage, billing, delivery, performance, and outcome dashboards inside a SaaS product.
GA4 is designed to help your organization understand users, not to become the tenant-isolated reporting UI inside your application.
A sensible two-tool setup#
Many products should not choose:
- Use GA4 for acquisition, web engagement, and advertising attribution.
- Use GraphJSON for authenticated product actions, backend events, operations, and customer-facing analytics.
- Align a small set of stable identifiers where privacy rules allow.
- Avoid sending every event to both systems without a clear consumer.
This keeps marketing workflows in the tool built for them and product events in a system that can answer arbitrary domain questions.
How to choose#
Choose GA4 when the default reports and Google marketing ecosystem solve the majority of your questions. Choose GraphJSON when your events are broader than web analytics, you need direct SQL, or the result must become an alert or embedded product feature.
If you are instrumenting a server-rendered application, How to Add Analytics to Next.js is a practical starting point. For a vendor-neutral event model, use our event tracking guide.

Written by JR
Founder and builder of GraphJSON.