Platform

How Geonimo produces its data: engines, collection pipeline, data model, and the security model behind it.

This section is for readers who want to know how the numbers are made before they trust them — technical evaluators, security reviewers, and anyone who has been burned by a black-box analytics vendor.

PageCovers
AI enginesWhich surfaces are measured, why they are captured from the real UI.
Analysis pipelineHow collection runs, how often, and what happens when it fails.
MCP serverConnect Claude, Cursor or any MCP client to your workspace data and build reports from it.
Data modelThe tables behind the product and how they relate.
Security and privacyTenant isolation, authentication, and what data is retained.

The shape of the system

Prompts × Engines × repeats per day
        │
        ▼
  scrape jobs (queued → submitted → ingested | failed)
        │
        ▼
  answers ── text, citations, fan-out queries, placements, grounded flag, parse status
    │  │  │
    │  │  └──► placements → share of slots
    │  └─────► citations → sources → domains (quoted vs listed)
    └────────► mentions (deterministic) → daily metrics, rolled up on ingest

Four design decisions shape everything downstream:

Capture the real interface. Engines are measured through their consumer UI, not their API. What you see is what a buyer saw, including the ads and shopping units an API never renders.

Sample, don't sample once. Each prompt runs several times per engine per day, so every rate carries a confidence interval and every change can be tested against a noise floor. A single reading of a non-deterministic system is an anecdote.

Pre-aggregate. Dashboards read a daily metrics table, never raw answers. Changing a date range recomputes from stored aggregates, which is why filters feel instant and why cost does not scale with how often you look.

Keep everything traceable. Aggregates never replace their inputs. Any number resolves back to the answers that produced it, stored verbatim with their citations and placements.

Built on Supabase

The platform runs on Postgres with row-level security, scheduled jobs and edge functions — no bespoke servers to babysit. Authentication, multi-tenancy and billing sit on the same stack.

For a security reviewer, the relevant part is that tenant isolation is enforced by database policies rather than by application code remembering to filter, and that the migration suite carries tenant-isolation tests. See Security and privacy.