In this guide· 5 chapters
A key you make, with reading permission only
PostHog holds the numbers. You are about to make them answerable in a sentence.
The connection runs on a key you create in your own PostHog and can revoke there at any moment. You choose its permissions, and the ones this needs are all reads — so the key itself is the reason nothing here can change your analytics.
- 1
Create a personal API key in PostHog
In PostHog, go to Settings and create a personal API key. Give it the read permissions the connect panel lists — project, query, insight, cohort, dashboard, the event and property definitions, and web analytics. Grant nothing else: a key with no write permission cannot write, whatever it is asked to do.
- 2
Pick your region and paste it
Open Connectors in 1Presence, choose PostHog, and pick where your account lives — US Cloud, EU Cloud, or your own address if you host PostHog yourself. Paste the key and it is checked against your account there and then, so you know immediately whether it worked.
- 3
Leave people-level data off
There is a checkbox for it, and off is the right answer for almost everyone. Left off you still get counts, trends, funnels, retention, breakdowns and your saved insights — everything below works. What you do not get is the identities of the individual people behind the numbers, which is your customers' data rather than yours.
Pasted a key starting phc_? That is the public project key your website sends events with, and it cannot read anything. The one you want starts with phx_ and comes from the personal API keys page — the panel will tell you if you paste the wrong one.
Four shapes of question
You do not have to know which chart type you want. Ask the question you actually have and 1Presence picks the shape — but it is worth knowing the four, because they are what a product question usually reduces to.
Start with these and vary them:
How many people signed up each week for the last three months?
A trend. Any event you record, over any period, counted as totals or as unique people. Add "split by campaign" and you get it broken down.
Where do people drop out between landing and sending a first message?
A funnel. Name the steps in order and get back how many reached each one, and the conversion from the step before and from the top.
Of the people who signed up in August, how many were still active in week four?
Retention. Cohort by cohort, by week or by month — the question a signup count cannot answer.
What are our saved insights called?
Lists what your team has already built and named, so you can run the agreed definition instead of a fresh derivation that is nearly the same.
If you are not sure an event exists, ask what events there are. A mistyped event name returns an empty chart rather than an error, which is the one way a wrong answer can look like a real one — so 1Presence checks the names when it is not certain, and you can too.
Make Monday arrive on its own
The point of asking is usually to notice something changed. That works better on a schedule than on a whim, so the natural next step is a routine: a standing instruction that runs on a morning you choose, asks the questions you care about, and tells you what moved.
- 1
Describe the review you want
Ask for a routine in your own words — "every Monday at eight, pull last week's signups, the activation funnel and week-four retention, and tell me what changed". The questions are yours to name; the shape is the same one you have been asking by hand.
- 2
Have it file the numbers
Ask for the figures to land in a dataset and the routine's weekly reads become rows you can chart. A dashboard drawn from that dataset is then the thing you glance at, and it is made of your own numbers rather than a copy of PostHog's.
- 3
Read it as a story, not a table
The useful part of a weekly review is the sentence, not the figure. Ask the routine to say what moved and what did not, and to flag anything that broke its trend — that is the bit you would otherwise have to work out yourself.
One connection for a whole team
A PostHog project belongs to the company. So in a team space it is connected once, by an admin, in Organisation settings — and from then on everyone can ask about the product numbers without setting anything up. Nobody connects it twice, and it does not stop working when the person who set it up moves on.
The people-level setting is the organisation's in the same way: made once by an admin rather than person by person, because the credential everyone is reading through is a single one. Your own personal PostHog, if you have one, stays entirely separate — asking in the team space reads the team's project, asking in your own reads yours.
What it will not do
- It cannot change anything. Not a flag, not an insight, not a person, not a cohort. The key has no write permission and there is no tool here that could use one. If you ask it to change something in PostHog, it will tell you plainly that it cannot.
- It will not hand you a list of people. Unless you turned people-level data on — which needs the checkbox here and the matching permission on the key — a question that would return individual people is declined with an explanation. That includes reaching them sideways through a hand-written query.
- It does not read in the background. A query runs because you asked, or because a routine you set up asked on a schedule. Queries are bounded to a date range and use PostHog's cached results where they are fresh.
- It reads results as information. An event name or property value that reads like an instruction is a row in a table, not a command it will follow.
The shift
The weekly review, without opening anything.
Connect once, ask in a sentence, and let a routine bring it to you on Monday. Read-only throughout, aggregate by default, and shared across your team from a single connection.