PostHog is an all-in-one platform for product analytics, session recording, and feature flagging. It’s a great tool for understanding user behavior.
Our new PostHog integration lets you add PostHog to your Glide apps and send custom events via Actions. Learn more about it in our Glide docs.
Have questions about the PostHog integration? Suggestions?
Drop your thoughts below.
Thanks you! 
Related links:
A MA ZING ! 
I implemented PostHog on my app this morning, and after just a few user session recordings, I was able to identify the issues my users were facing — all in less than half a day — and make some quick fixes.
Huge thanks for this implementation! It’s really going to help me make my app even more powerful by truly stepping into my users’ shoes.
Can you share more on what the issue was?
I’m interested, but not sure what issues can be identified by PostHog and not by other Glide functions, say a log of a workflow (since my issues usually tie to workflows only).
Hello, super cool announcement! I can’t see however, Glide listed in the integrations for session replays on PostHog. How do you install it?
And session replay is not listed in the features in the integrations screen on Glide. Is it doable? Thanks!
I would be interested in knowing how to clean up the URLs. It is a challenge working with these long URLs.
The first one after the dl is straightforward, it’s your tab’s slug.
Then /r/ implies opening a screen with the part right after that being its rowID.
Anything after /s/ likely is a component ID. I thought it would be included when you copy a component and try to read that through the clipboard, but it isn’t there.
What do you mean?
I don’t really understand this either. The path analysis in PostHog shows visitor paths I believe. I am assuming, perhaps wrongly, that each one of these URLs is that of a screen. In fact it’s very easy to check.
I believe we are seeing these unreadable URLs because slugs can only be defined at the tab level. It would be nice to be able to define slugs on all screens.
The screen recordings help understand the quality of the design, its inefficiencies, bugs etc. Very powerful.
The best Glide integration for me personally is Google Tag Manager, as it allows to handle many others (Facebook pixel, Google analytics, postHog and many others that don’t have integrations), but it requires some understanding of tag manager.
Absolutely amazing service!
I mean the part right after /r/ is the rowID of the row you’re interacting with.
That’s correct, and I’m just dissecting what it means.
It would be nice, but I think it would be costly to do something like that.
Let’s take this URL for example:
/dl/a-decouvrir/s/586405/r/tp7ScvwWReeDL52jJBg5vA/s/cOa8e8/r/10R6zyx2S2yek3ud6cm3kg
It means:
So the path of the visitor is in the URL, that could be useful.
I had never paid attention to how URLs in Glide are built, and this is quite insightful. Rather than a simple destination or page/screen URL, the URL is defined as a path from a top-level tab.
I’m not too sure what that brings us builders, but it’s very interesting regardless, thanks for the explanation 
Personally, I’m thinking about how we could tap into the PostHog API and parse those paths to understand common user navigation funnels within an app. 
The path can tell you where the user has been too. If you navigate to a child record and then back to the parent and then back to the child, all of that is appended to the URL. It shows the user’s path (as long as they are clicking to go to a page and not clicking back), not just the page location relative to the top page.
I absolutely agree, the information is potentially useful for path analysis or navigation funnels as suggested by Andy.
My only small gripe is that as is, the information is difficult to decipher. Tabs and components are already labeled, and further screens could be. It would allow us to not have to parse the URLs and rework the data.
But I agree, the information at our disposal in the URLs in PostHog is already useful.
This is also the problem that one of our clients had when she integrated Google Analytics. She had to manually parse those URLs out like I said to investigate user behavior.
Parsing on our side is doable. Creating a reference table with component IDs, row IDs and readable screen names would help, but even that would be a lot of work. A row ID is associated to a table ID. Hm, but a table ID isn’t necessarily associated to a screen ID.
It’s true that even as I’m writing this, I realize that there is no real notion of screens in Glide. Navigating in the front end (the layout editor or production) is nothing but navigating across tables and rows in the data editor. So screens don’t actually exist, these are only collections of individual rows and tables (if needed filtered).
Let’s put it this way: it would still be nice if Glide had screen IDs and perhaps added that screen ID at the end of the URL which is currently generated: /sc/a1b2c3d4e5f6g7h8i9 . This would help with the parsing exercize.