The two demos to actually watch
Product analytics is the quantitative half — funnels, trends, retention, increasingly with the AI assistant writing the queries. Session replay is the qualitative half — the tape you watch to understand why. Three minutes each.
In this chapter's workbook
Everything you write, answer, and tick below saves to your personal workbook. Sign in free to keep it across visits.
Two products are where a growth team actually lives, so it's worth seeing each one work for three minutes before you move on. Product analytics is the quantitative half — funnels, trends, retention, increasingly with the AI assistant doing the query-writing:
▸Read the transcript(891 words)
Hi, I'm Edwin and I'm part of the content team here at Postto and I'll be showing you how we use product analytics [music] to help us improve and write developer documentation. So recently we overhauled a lot of our installation pages for products like error tracking [music] and that meant building a lot of new components like this steps component that essentially sequences out the content in a very structured way.
And when you compare that with our older documentation, it's a very different look and feel in terms of visual and information layout. So we use product analytics to track the user behavior and engagement with that content so [music] we can know how it's performing. So, we built this really comprehensive dashboard with lots of different insights that track page views over unique users, page views by session or user, breakdowns by URL path, the referral Google for GEO, chat GPT for AEO, as well as probably the most important insight funnels that help us actually track how well these installation pages are converting to real feature usage.
So on the left we have the [music] old installation pages converting at a rate of about 11.3% for a user who reads the page and then tries the feature to our new layout which goes about to 16.04%. So big increase and gives us great positive sign to keep going in the new direction.
Another way we use product analytics in a more low-level manner is to use SQL insights. So SQL insights lets us query the data warehouse that powers product analytics at Posthog under the hood. So I can open up the SQL editor and write queries in our own version of click house SQL across our entire event schema of Postto.
And if I want to write or create new SQL queries, I'm not the best at doing that myself, I'll admit. So I lean a lot on Postgog AI which is a really fantastic way to create, validate and fix SQL right here in Postto. So I might open the chat and ask it [music] to write a SQL query to match how many users have looked at both error tracking and feature flags and finding that intersection.
So I'll kick it off and it should generate a fully workable query for me to run. >> [music] >> And right there we have a SQL query that [music] Postto AI generated and I'll use this as a template to work off of. And I have data coming back from my SQL insight. We also [music] use product analytics to instrument new events when we ship new features or content that have no prior reference.
So for example, we shipped a new feature down here that lets you copy as markdown or view as markdown the contents of a documentation page which is great for LLMs or AI coding agents. So we use actions in post hog which is one of our most powerful features that lets you combine or filter for events under a saved name.
So we would create a new action called copy as markdown and from the auto capture events of all the activity that we're tracking we can actually target the element uh with its text. So it had copy as markdown within the div and we can specify the page URL. In this case it would be under docs.
And when we create this copy as markdown event we can create insights [music] just the same way we would with any event in post hog which allows us to create graphs or pie charts with a full breakdown of our new actions that [music] we created for copy as markdown, view as markdown, whatever we wanted.
So, this is a great way for us to track new activity for brand new behavior on docs pages that didn't exist before. Product analytics also lets us investigate things here at Postto. So, in the same dashboard that I showed you earlier for error tracking docs, we had noticed a couple weeks ago an overall spike in traffic, but a flat line for unique visitors.
So, this odd behavior led me to investigate more. And when I was creating more product analytics, I use an underrated feature at Postto called notebooks. When you create insights, you can use [music] the action side panel to add the insight to a notebook which will create a rich text editor document similar to Google Docs or notion.
So you can write in markdown, you can copy paste and with the slash command you can embed more insights that you can create directly within the notebook itself. So for my investigation, I ended up creating a notebook called investigation [music] docs traffic spike where I could write down the context, paste images from Slack of the first person who discovered the problem and then in kind of more of a narrative way explain what I thought was going on by embedding more insights, [music] my thoughts and commentary which led me to conclusion where I can also tag my teammates.
So notebooks are a really powerful way to create more of a free form report than just a dashboard. So those are a few ways the content team uses product analytics at postto. Thanks for watching. [music]
What to take from it:
- The daily loop is ask a question → get a chart: funnels, trends, and retention are a few clicks, and the AI assistant will write the query when you don't know how.
- You don't need to learn a query language on day one to get real answers — which is exactly the point for a small team without a data analyst.
And session replay is the qualitative half — the tape you watch to understand why the number you just saw is what it is:
▸Read the transcript(549 words)
Hey, I'm Steven. I'm a support engineer at Post Hog and I'm going to take you backstage for a look at how we use session replay to help us do support. So, when someone opens a ticket from within our system, we include some information about the session they were in when they open that ticket.
And one of the things that we include is a link to the session recording. By the way, stick around and I will show you where you can get information about how to set up a link like that in your own system. So this is really helpful in cases where the user doesn't tell you much about why they opened the ticket.
For example, this user didn't tell us which insight that they were working on, uh what it was that looked wrong about the graph, what they were doing just before they noticed the problem, etc. Once upon a time, there was not much you could do but to reply to the user and ask for more information.
But now with session recording, you can have a look at what they were up to just before they opened that ticket. Uh the link takes us to the moment where they started the ticket. And in a shorter session, it's usually just a few hops back to where they encountered the trouble that they wrote in about.
So you can watch, see what they were doing, uh have an idea about their expectations, uh and then you'll notice problems. uh for example, this user just disabled formula mode probably without understanding uh the effects that that would have uh on the output in this insight. So that's a situation where it's pretty easy just from watching to see what went wrong.
Other times it might not be something that the user did, it might be something going on in uh your app. So you can have a look here in inspector. Uh you can uh turn on and off uh the details uh such as uh what we are able to capture from the console. Um the events uh what we're able to capture on the network tab etc.
Um you can get a detailed look at uh the properties, the metadata, the flags that were involved, uh what elements uh were particularly involved in this part of the capture person properties if you are capturing identified events, set once properties, debug properties, etc., etc., etc. I'm not going to drill down into all that in this video because it would be pretty long.
So, to learn how to add links to session recordings to your own support tickets from your own product, uh go to our docs and tutorials and search for how to add session replays to Zenesk. Uh Ian's got a great document he's written here that shows you how to do it. Uh has uh code examples.
It walks you through the whole thing. While this example is particular to Zenesk, you can extrapolate this for pretty much any system or platform that you're using for support. And um it will uh save you a lot of time and it will make your users happy because they will feel like you're psychic.
Enjoy. Thanks for watching. Take care.
What to take from it:
- Replay is the why under the where: when a funnel shows a drop, you jump straight from that data point to the recordings of the people who dropped.
- Console logs and network requests are captured with the session, so "reproduce the bug" becomes "watch it happen" — the same move whether you're chasing a support ticket or a drop-off.
Before you move on
This chapter's workbook items — sign in free and they save as you go:
The whole PostHog suite
The full product list — analytics, replay, flags, experiments, surveys, error tracking, LLM analytics, warehouse, CDP, and Max — with what each one does for a growth team specifically. You won't use all of it; here's what's there.
Events, persons, and why it isn't GA4
Everything in PostHog hangs off events (a thing that happened) attached to a person (who it happened to). Get those two right and every chart works — and it's the exact place product analytics parts ways with GA4.