What PostHog is built to answer
PostHog is product analytics you explore: funnels and insights you build, session replays of the people who dropped, feature flags, and experiments that split your users so a change can be tested. If you want to ask your data anything, it is a deep tool.
It answers the questions you think to ask. A chart nobody opened does not say that sign-up completion fell last Tuesday, or that the release on Thursday brought it back.
What Forge reads from the same events
Your app sends its events, errors and logs with a small SDK or plain HTTP. Forge counts them every day and comes to you when a number moves, instead of waiting to be asked.
- Journeys proposed from your rows. Forge counts which pairs of events your users send in order most often — signup_started, then signup_completed — and proposes them as journeys. A person confirms them; nothing is defined for you.
- An issue with its rule. A journey opens an issue when its completion over the last 7 days falls at least 5 points against the 7 days before, from at least 50 entries in each. Below that, Forge says it is too few to judge.
- The week against the week before. Events, errors and sessions, each in the colour of its side — more sessions green, more errors red — with a 14-day line under each.
- The release, read from the rows. Your tracker sends the release with every event, so Forge knows when a version reached production without anyone marking it, and measures the journey before and after it under a plan written before it shipped.
- Counts, never people. Person ids are hashed per product and never shown. Forge has no profile of anyone and ranks no one.
npm install @ambera/forge-tracking
import { createForgeTracker } from '@ambera/forge-tracking'
const forge = createForgeTracker({
token: 'ftk_…', // your product's tracking key, safe in page source
environment: 'production',
release: COMMIT_SHA, // how Forge knows which version sent each row
})
forge.track('signup_completed')
forge.captureException(error)Where Forge stops
These are the things PostHog does that Forge does not:
- No session replays and no person profiles — by design, Forge never shows a person.
- No feature flags and no experiments. A before-and-after read is an observation, not a controlled test; when you need to know a change caused something, run an experiment.
- No dashboard or query builder. The stored rows are a table you can filter; every other number is one Forge states for you.
Questions
- Do I have to define my funnels first?
- No. Forge proposes journeys from the order your events already arrive in, states the share of people who completed each, and marks a pair with too few people to judge. You confirm the ones that matter; until then nothing is measured against them.
- Can I keep PostHog?
- Yes. Forge’s own team uses PostHog for its website. The Forge tracker is its own small package, so the two send side by side and neither reads the other.
- Is a before-and-after as good as an A/B test?
- No, and Forge says so on every outcome: “a before-and-after comparison is an observation, not proof the change caused it”. What Forge adds is that the plan — the metric, the windows, the change that counts — is written before the release, so the threshold is never chosen after seeing the numbers.
- What does it cost?
- Free for 1 product, no card: the tracking, the issues, the releases and their outcomes, up to 20,000 rows a day. Solo is $29 a month, flat, for 3 products and 100,000 rows a day each. Nothing is metered and there are no credits; the one paid addition to oversight is the model’s draft of a work spec.
- What happens to my users’ data?
- Person and session ids are hashed together with your product’s id before they are stored, the IP address is never read, and e-mail addresses, IP addresses, query strings and anything shaped like a secret are removed from the texts. Rows are kept 30 days on Free, 90 on Solo, 180 on Team and 365 on Premium. No screen in Forge shows a person, lists the people behind a count, or ranks them.