Skip to Content
Analytics and Reporting

Analytics and Reporting

“Does Foir do analytics?” is really three questions wearing one coat. Foir answers each of them, but not by being an analytics product. Foir does not build analytics, and this page is the honest map of where each need is actually met.

The three needs usually hiding inside the word:

  • Behavioural analytics are pageviews, sessions, funnels, and where a visitor dropped off.
  • Reporting and BI are questions over the data Foir already holds for you: revenue by month, records per model, customers per segment.
  • Event forwarding is pushing “this just happened” into another system, such as a CRM, a warehouse, or a Slack channel.

They look similar and they are not. Here is where each one lives.

Behavioural and traffic analytics

Pageviews, sessions, funnels, heatmaps, and where a visitor dropped off are not something Foir captures, and it will not. Foir is the backend your app talks to; it never sees the page a visitor loaded or the button they didn’t click. Bring your own tool for this and put it in your storefront or app, where the traffic actually is. PostHog, Plausible, and Google Analytics all drop in with a snippet.

A common hope is that lifecycle hooks can stand in for this. They cannot. Hooks fire when something in Foir changes: a record is created, updated, published, or deleted. There is no read event and no pageview or impression. A visitor reading a published page is invisible to Foir by design, so no hook can tell you it happened. If you need to know what visitors did, measure it where they are, in the browser.

Reporting and BI over your data

For questions over the data Foir holds, such as totals, trends, breakdowns, and joins across your models, the answer is to query a database you own rather than to ask Foir for a reporting UI it deliberately doesn’t have.

foir export postgres ships today and gives you exactly that: an ordinary Postgres database with a typed table per model, your content in real columns, and references as real foreign keys.

foir export postgres --target "postgresql://localhost/reporting"

Point Metabase, Looker, or any SQL tool at that database and build whatever dashboards you like, on infrastructure you control. Re-run the export whenever you want fresher numbers; reporting usually tolerates a little lag. If you need the data continuously up to date, replicate that database at the infrastructure layer, the same way you would keep any read replica current. That is a database concern, not a separate Foir feature.

See Your Data Is Portable for what the export contains and Export to Postgres for the full walkthrough.

Event forwarding to other systems

If the goal is to react to changes, such as syncing a new record into your CRM, dropping a message in Slack when a page publishes, or pushing an update into a warehouse, that is what lifecycle hooks and operations are for. A hook fires on a content event and calls an endpoint you control.

This is genuinely useful, and it comes with edges worth stating plainly:

  • It tells you what changed, not a running total. Each delivery describes the record that changed and carries its data and identifiers. If you want to aggregate, you aggregate on your side. See Lifecycle Hooks and Webhooks for the exact payload.
  • Delivery is at-least-once. A retry after a network blip means your endpoint can receive the same event more than once. Make your handler idempotent by keying on the executionId present on every payload and treating repeats as no-ops.
  • There is no backfill or replay. A hook only fires for events that happen after you create it. It does not walk your existing records, and there is no button to re-send history. To seed a downstream system with what already exists, do that once with an export or a batch job, then let hooks keep it current from there.

Hooks are a forwarding mechanism, not a metrics pipe. They are the right tool for “when this happens, go do that,” and the wrong tool for “how many happened this week.”

Personalization has no built-in feedback loop

If you serve variants to different segments or contexts, it is worth being clear about what Foir records: nothing today records which variant a given visitor was served. Resolution happens per request and Foir keeps no history of it. So Foir cannot tell you which variant performed better. There is no built-in experiment framework, no traffic-splitting with goal measurement, and no conversion tracking. Measuring which variant won is a job for the behavioural analytics tool in your storefront, the same one from the first section.

See also

Last updated on
Your Data Is PortableGetting Started