# How to turn your data into content with PostHog ### Contents - Why we finally decided to write a data study - How I actually wrote it - 1. Brainstormed the angle with our MCP - 2. Pull the data with PostHog AI, straight into a notebook - 3. Interrogate the product with the PostHog Slack bot - 4. Write the first draft - 5. Mock up the graphs with Claude + the PostHog MCP - 6. Send it to review and ship it Here's something we know (mostly) to be true about LLMs: they love novel, first-party data. They're hungry for it. I would be too if I was forced to rehash the same 100,000 public datasets over and over again. And it's not just the robots. People love it too. I always appreciate a company that takes the time to share real stats and benchmarks, and try to read as many as I can. I personally believe we're all a little better off for it. So: robots love data. People love data. And PostHog just so happens to sit on a mountain of it. Which is why I pitched us doing a study in my first quarter at PostHog. The reason why it never got picked up is because of how daunting of a task that used to seem. Somebody has to pull the data, sift through it, validate it, slice and dice it into something interesting, and then write an actual story around it. ## Why we finally decided to write a data study So what changed? Two things. First, we got realistic. Instead of writing The Definitive PostHog Data Study Of All Things™, we scoped it down to [a scrappier MVP](/content/nobody-watches-session-replay/index.html). In all seriousness, we chose to focus on a proof of concept that would be interesting to our audience, and that we could actually ship in a reasonable amount of time. Second, and this is probably where the biggest unlock is, **the tools got good**. Like, really good. [PostHog AI](/content/ai/index.html) started out questionable, but it really grew into itself in the last few months. It's a beast now. On top of that we shipped [a great MCP](/content/mcp/index.html), [a Slack bot](/content/slack/index.html), improved our [Notebooks](/content/docs/notebooks/index.html), and generally made it easier to get at the data we already have. In another life I used to spend days exporting datasets into spreadsheets and wrestling through assorted BI tools. All that manual grunt work that used to make writing something like this a massive pain, is now a few clicks and a couple of queries away. Which means I get to spend most of my time doing the fun part: making creative and editorial calls. ## How I actually wrote it Here's roughly what we did, in order. ### 1. Brainstormed the angle with [our MCP](/content/mcp/index.html) I gave my agent a few guardrails to help me brainstorm: no PII, has to be data we already collect, and has to be something PostHog AI can pull relatively easily. > **Prompt I used:** You're helping me pick the angle for a data study (a short, very data-heavy blog post built entirely on PostHog's own first-party data). You have the PostHog MCP connected, so check event definitions and property definitions before you pitch me anything. > > Hard guardrails: > > - No PII, and nothing that identifies a specific customer, company, or user. Aggregates only. > - It has to be data we ALREADY collect. No "we should start tracking X." > - It has to be pullable in a handful of SQL queries. > - It has to be something PostHog would be comfortable publishing. ### 2. Pull the data with PostHog AI, straight into a notebook Once I decided to focus on session replay and [Replay Vision](/content/replay-vision/index.html), I asked PostHog AI to pull the data I needed, and to create a Notebook to hold all my SQL queries and charts in one place I could go back and reference. > **Prompt I used:** Make me a notebook called "Replay data study" with every query and its SQL, so I can re-run them later. Cross-tenant, last 90 days. > 1. Every time someone opened the player and watched – how long? Median and full distribution. > 2. Median and mean length of the recordings. > 3. Recordings captured vs. recordings opened at least once. > 4. Recordings captured per company. Median and mean separately. > 5. Distinct people who watched anything, and replays per watcher. > 6. Playback speed when people change it. ### 3. Interrogate the product with the PostHog Slack bot Since I'm not the person who built Replay Vision, I asked the Slack bot to gather all the context I needed to better understand it. ### 4. Write the first draft The fun part. Self explanatory. ### 5. Mock up the graphs with Claude + the PostHog MCP By now I had the raw numbers, but a table of medians doesn't exactly make a story. I wanted to see them and to play around with what different visualizations could look like, and had Claude sketch a few versions of each. > **Prompt I used:** Here are the SQL queries behind my study. Re-run each one through the PostHog MCP and check the numbers still hold – tell me about anything that doesn't match what I've got in the draft. > > Then, for each query, show me three different ways to visualize the result. ### 6. Send it to review and ship it [You can read it here](/content/blog/nobody-watches-session-replays/index.html). Is it perfect? No, it's an MVP, and I can already see about 10 things I can do better next time. But it exists, it shipped, and it's a glimpse of how much more of this we can do now. That's kind of the point: this is the worst this process will ever be, and it was already good enough.