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.
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!
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.
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.
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
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.