Article · Updated July 2026
Analytics With Your Own Keys, on Your Own Machine
“Connect your data” usually means “give another company long-lived access to your accounts.” Metricsjar uses a narrower model: your coding agent runs source queries on your machine with credentials you already control, then publishes the dashboard-ready result.
The boundary is simple enough to audit.
What stays on your machine
Source credentials remain local, including:
- Google Cloud and BigQuery authentication.
- DataForSEO credentials.
- App Store Connect key files and identifiers.
- RevenueCat secret keys.
The local configuration also holds the source-specific details needed to run queries: project names, dataset names, property identifiers, store countries, and environment filters.
What Metricsjar receives
Metricsjar receives the computed payload needed for your dashboard. Depending on the sources you connect, that can include keyword rows, page performance, traffic totals, backlink summaries, app downloads, revenue, retention, and product events.
This is still business data. Treat dashboard access as you would access to any analytics report. The own-keys model reduces credential exposure; it does not turn the published metrics into public information.
Why the distinction matters
Long-lived integration credentials create three kinds of work:
- Trust. You must accept the scopes and security posture of another platform.
- Rotation. When a key changes, every hosted integration using it must be updated.
- Cost. The platform either absorbs source-query costs or passes them back through a subscription.
Running locally keeps those decisions with you. DataForSEO usage hits your balance. BigQuery jobs run in your project. The agent can show you exactly what it is about to query before it does so.
The trade-offs
Local execution is not magic. The machine must be available for scheduled refreshes. Credentials that exist only in an interactive shell will not be visible to a background job. A laptop on battery may sleep. Source APIs can change.
That is why Metricsjar installs a doctor alongside the refresh:
- It tests the account that the schedule will actually use.
- It distinguishes a missing configuration from an upstream publishing delay.
- It checks that the current machine can still reach every configured source.
- It reports stale data rather than quietly presenting it as current.
A readable local client
The served CLI is a single readable file. Your agent can inspect it before running it, and you can compare the installed copy with the served copy. The goal is not “trust this binary.” It is to make the local side small enough to understand.
For setup, start with the getting-started guide. If Search Console is one of your sources, enable its BigQuery export first because it does not backfill.