Open annikaschmid opened 1 year ago
Link to internal RFC: https://github.com/PostHog/product-internal/issues/434
Do you know if you're planning on supporting embeddings (non-public)?
In its simplest form, it's just a matter of allowing embedding of PostHog into other websites (using iframes). In a more complex form, it'd be allowing embedding of the Insight chart only.
Additionally, I believe it would be valuable to allow embedding of both Insights (individually) and whole Dashboards. This is particularly useful when we're building a backoffice and we want to embed analytics insights right there, without having to go into another app (PostHog).
Another feature that would be beneficial is "Dynamic Filters", i.e: the ability to load an insight with filters provided in the URL.
Use cases would be:
Hi @DNA-PC! You can already embed insights and dashboards, simply click "Share" on a dashboard and "Share on embed" on an insight:
As for filters in the URL on a shared insight, that'd be interesting, but it'd have complex security implications: if editing the URL is all it takes to change to any other filters, then access to any shared insight would allow access to all your data, which would seldom be intended. That's why we're not currently planning this.
The issue I have with "Share or embed" is that it only works with public links, and I'd like to have people signed in in PostHog, but visualize the Insights/Dashboard from another tool.
As for filters in the URL on a shared insight, that'd be interesting, but it'd have complex security implications: if editing the URL is all it takes to change to any other filters, then access to any shared insight would allow access to all your data, which would seldom be intended. That's why we're not currently planning this.
True, I had a "template" system in mind, basically a Dashboard/Insight where we could allow specific dynamic properties, such as the value to filter by (not the key), this kind of things.
Usually, the way people want to use this is:
At this time, this requires to create 2 separate Insights, but using a "Template" with a dynamic value would be better, and much simpler to maintain.
We tried using the function of groups and set up a group type called customers and report back what B2B customer the user is using our products from. We thought that groups would support this but as I see it, the the functionality is limited.
The way we have to do it right now is that we set up the exact same insights filtered for each customer groups.
My thought when you would add a B2B2C functionality natively would be to add a filter for whole dashboards where you could pick between different groups without having to edit the insight.
@Twixes regarding
As for filters in the URL on a shared insight, that'd be interesting, but it'd have complex security implications: if editing the URL is all it takes to change to any other filters, then access to any shared insight would allow access to all your data, which would seldom be intended. That's why we're not currently planning this.
You can always put the filters inside a JWT token and sign/validate it through a backend call. I use a BI solution that does exactly that.
This would be a very useful feature for my use case.
Use case: Tenent-based services, like profile builders. Tenant-based services usually use single source code to handle multiple websites/pages. Our service lets users select a subdomain and we host their profile page and other pages on that subdomain for them. We have a dashboard where they can build and enter data for their profile and pages. At the end of the day, each customer wants to get some analytics about their profile/page, like how many visits, referring domains, and typical things. The tenant setup is a self-service and fully automated, the number of tenants can grow to a million potentially!
Now, to provide each tenant with a simple analytics dashboard driven by Posthog, I don't have a solution with Posthog yet.
I think the basic requirement is a solution to be able to run a query against posthog API in an authorized fashion. Each tenant should only have access to the results of a query that pulls only their data (correct filtering).
The query and filtering can be done on a server-side request that handles authorization on our side, the problem with that is if 10k users request at the same time, our server will be sending too many requests from the same IP to PostHog API and will get rate-limited.
Just found out about this while trying to find out how to work around what was currently built-in :) My use-case is the classic one of a franchisor: I'd like to embed dashboards in our internal app where our franchises -- more or less independent entities that we support -- could follow up on their data.
On top of this B2B aspect, we have a B2B2B aspect as well, where our "end-user" are themselves entities that would benefit from filtered in dashboards.
I'd love to get updates on this, as it's quite high on your roadmap
About this:
Potential implementations:
- Create a separate project for each end user, and send their users' data there, then invite them to only that org (requires Enterprise plan)
- Create dashboards of enduser metrics and share them (or embed in iframe for slightly more white-labeled experience)
- Build your own UI for this and just hit PostHog query endpoints for data
I'm definitely interested in the 2. or even the 3.. Whitelabel experience is 100% part of my use-case.
Thanks!
I'm also interested in white label. We're building out a "reporting" feature in an a CRM app right now where users can build reports based on their data (hubspot/salesforce-esque) and it's a very heavy lift.
Would be great if you could sync you application database (e.g. MongoDB) with the posthog data warehouse and then embed a reporting feature into your app where customers could build their own reports with a UI.
For us, this would be an obvious buy in the build vs buy analysis. It's kind of a commodity feature.
In some contexts, PostHog users need to productize the data they've collected with PostHog and show it back to their customers/end users. This could be from the customers' end users (b2b2c), or people within the customer's org (b2b). A common b2b2c example is: building products for ecommerce (checkout optimization, cart functionality, etc)
Potential implementations:
We'd love to hear user feedback, as well as ideas for stretch goals or implementation.
If you like this idea, please leave a 👍 or ❤️ reaction on this post to vote for it -- your votes and feedback help us prioritise what to work on next!