Four things: whether an account got connected, whether a scheduled post went out on its own, whether a second person showed up, and whether the workspace is still working thirty days later. None of the four rises with an ad campaign. The rest, sign-ups, sessions and followers, sit in front of us and decide nothing.
A metric has to be able to come out badly
Before a number earns a place on a dashboard we ask it an awkward question: what would this look like if the product were bad? If the answer is that it would go up anyway, the number is not measuring the product. It is measuring something else, usually that month's ad budget.
Sign-ups fail that test outright. They rise when an article starts ranking, they rise when a campaign launches and they rise when somebody rewrites a headline. None of that says whether the tool is any use for the work of the person who signed up. Pricing page sessions have the same defect, and follower counts on our own account are a figure about us rather than about the product.
There is a second test, and it is harsher. If that number came out badly three months running, would we do anything differently? A number that cannot change a decision is expensive decoration: it costs work to instrument, work to review, and it ends up taking the meeting time some other number deserved. Very few figures survive both tests, and the scarcity is the point.
The four questions that matter here
What is left is four questions, and all four are answered by looking at a whole workspace, never at a single person.
- Did an account get connected? Connecting a social profile is the first step that genuinely costs something: you sign into the network, authorise, and pick the right account out of the ones that come back. Nobody does that out of curiosity, so it sorts people better than any form.
- Did something scheduled actually go out? A piece publishing itself at its hour is the first moment the product does work instead of promising it. Until then a workspace is a tidy folder.
- Is there a second person inside? A workspace with one user can quietly stop being used and nobody notices. With two people a shared habit appears, and a habit has inertia: somebody asks about a piece, somebody answers, and the calendar becomes the place where the work gets argued about.
- Is it still working thirty days later? The only one of the four that cannot be accelerated. You wait, you look, and you take the result.
None of the four is a percentage we are going to print here, and not out of coyness: a percentage taken from a base this size says more about the base than about the product. What we can describe is how they are measured.
What measures what
Five instruments, each answering one thing. The right-hand column is what prevents most misreadings.
| Instrument | What it answers | What it cannot answer |
|---|---|---|
| Tag Manager and Google Analytics | Where a visit came from and what it did on the site | Anything happening inside the product |
| PostHog, EU cloud | Which features get used and where sign-up is abandoned | Why somebody left |
| Sentry | What broke, in which release, and for whom | Whether something works badly without failing |
| Semrush | What people search for and where we rank | Whether those visits are worth anything |
| The subscription screen | Accounts, storage and Auto DM contacts per workspace | Whether the workspace is happy |
Above those five sits a text file at the root of the repository. Every change that touches something measurable gets a note there saying what it means for the events that already exist, and anything that has to be done in a console stays on it as a dated pending item. It is not bureaucracy: a year later, "why is this event called that" is a real question and that file is the only place it is answered.
One door, and a closed vocabulary
The oddest decision in all of this is also the cheapest. On the marketing site there is exactly one file allowed to send an event, and inside it the list of names that may go out is closed. Not a team convention, not a note in a document: a type, so a name invented anywhere else does not compile.
The reason is that the tagging layer fires on names. A container can only trigger on a name somebody genuinely pushed, so an event improvised at a call site is not extra data, it is a trigger nobody wrote and therefore a thing that appears in no report at all. The failure is silent. There are simply no rows.
The same applies to the places on a page where a click can happen. Instead of a free string there is a list of placements, and every link declares its own in an attribute that is type checked at the sixty-seven points where it is used. A typo there would be a placement no report groups; with the list closed, it is a build error instead.
The side effect turned out to be the most useful part. In an environment with no container at all, a laptop or a preview deployment, the function still writes into an array nothing reads. That makes the whole taxonomy inspectable from a browser console before a single tag exists, and it is how this layer really gets verified.
Why nearly everything is measured server side
Product events are not sent from the browser. They are sent from the server, right beside the write that makes the thing happen. There is one for every operation that passes through a feature gated call, carrying the feature key and the route, captured once the write has succeeded.
The practical consequence is that an ad blocker cannot hide the fact that a feature is being used. Measure from the browser and everyone running a blocker drops out of the report entirely, and that is the profile of a lot of technical people, the ones most worth listening to.
There is one exception and it is deliberate: a screen view during sign-up is captured from the browser, because the server cannot know that somebody read a screen, only that they wrote the next step. And a funnel built from writes alone cannot see what a drop-off is: the screen somebody looked at and left.
Everything in this article happens in one place in GoFeed.
Try it freeWhat we deliberately do not look at
We do not read the content of what you publish or the messages arriving in your inbox. Product metrics are computed over counts and states, and that is a technical limit before it is a promise: the event holds a feature key, a route and an identifier, and there is nowhere in it for any text of yours.
The calculators on this site take the same rule further. What somebody types into one never leaves their browser; the event says which calculator finished computing and nothing else. An event carrying somebody's numbers would be the first thing here to break that rule, which is why the field does not exist.
The product analytics service is hosted in the European Union and browsers reach it through a path on our own domain. Worth saying plainly: blockers filter by hostname, so that path does mean fewer lost events, and it is one of the reasons it is there.
What you see about your own workspace are the same figures we see, on the subscription screen, and your network metrics live somewhere else entirely, in the analytics module, which has nothing to do with any of this. How those turn into a monthly document is covered in social media reporting.
When a number stops meaning what it meant
In September the trial started asking for a card. The conversion marking the start of a trial stopped firing at the end of the wizard and started firing when the card lands, so the count dropped on the day of the deploy. No sign-ups were lost: the population being counted changed, and that distinction is what separates an analysis from a scare. The date is on the record, and the reasoning behind the change is in how we decided the price.
There is a worse trap, because it is quiet. A new analytics dimension is not backfilled: the days between an event going live and somebody registering it in the console can be counted in total but never broken down again. So the correct order is register first and deploy second, and console work is both the part most often forgotten and the only part that cannot be recovered.
And we hold our own numbers to the two rules we ask everybody else to keep. Reach is never summed across days, because somebody who saw you on Monday and on Tuesday is one person and not two, which is the whole of reach against impressions. And a rate is recalculated from the period totals, never averaged from the daily rates, which gives a different and always kinder number, as in the engagement rate guide. A team that skips those two rules on itself has no standing to ask them of anyone.
