Embeddable mode #213
Replies: 18 comments 35 replies
-
Hi! I'd love this feature as well to display on my org's website org.grey.software/stats I'm in favor of the first implementation as a minimally viable solution at this point. |
Beta Was this translation helpful? Give feedback.
-
Hi @cassidyjames, I've emailed Plausible Analytics about this issue and CC'ed you. This would be a very useful feature for @grey-software because I'd like to display weekly analytics on https://grey.software/this-week How did you manage to get the screenshot working? I get the following error:
|
Beta Was this translation helpful? Give feedback.
-
@ArsalaBangash my screenshot is of a native app, so the Plausible site is actually loaded in the top-level of a webkit frame—not embedded into some other page. |
Beta Was this translation helpful? Give feedback.
-
Having my team take a run at developing this. Currently thinking of allowing embed mode on a per website basis and adding the necessary header (either Content Security Policy or X-Frame) to allow analytics page to be embedded only in the domain tracked. For example, if abc.domain.com is the tracked website, then analytics page can only be embedded in domain abc.domain.com. Analytics page header and footer will be suppressed. We are also planning on allowing a user to link an external stylesheet over https to change the styling of the analytics page. IFrame src should be set to a shared link to allow analytics page to display without username/password authentication. Feel free to suggest any additions/modifications. |
Beta Was this translation helpful? Give feedback.
-
@bradkane that sounds interesting and probably a good approach. Just to clarify my use case, though: I would be embedding the Plausible dashboard into a native app, not a website. So as long as this solution works for both, it sounds reasonable to me. Of course for my uses, I can also control the “browser” itself and decide how it injects CSS, handles headers, etc. so some of that is not directly needed for me. I think the biggest thing for me is hiding the footer and any other “website” sort of UI from the Plausible side; while this can be achieved with external CSS, it is more prone to breaking than if the Plausible codebase was aware of an “embedded” flag that could also alter its own UI to make it more friendly to being embedded. |
Beta Was this translation helpful? Give feedback.
-
@cassidyjames The external CSS is a nice to have, rather than a need to have and technically doesn't really relate to "embeddable" featureset. External CSS is optional and not required for "embeddable" solution. When the "embeddable" flag is detected, we are planning on suppressing the header/footer and adding the necessary addition to the headers. In your native app, will a SAME ORIGIN restriction work? We were going to implement it that way to reduce potential for configuration errors and security issues. |
Beta Was this translation helpful? Give feedback.
-
@bradkane I believe that should be fine, yes. |
Beta Was this translation helpful? Give feedback.
-
@bradkane This sounds interesting for us, as we would like to include a shared dashboard inside our TYPO3 CMS's backend so editors can have a convenient way to access statistics. |
Beta Was this translation helpful? Give feedback.
-
We have this working in dev. For each domain tracked, you will be able to turn on "Embedding". When turned on, by using a shared link as the iFrame source, you can bypass authentication and have the content displayed automatically. In addition, by adding a querystring parameter, you will be able to disable the header and footer. @metmarkosaric @ukutaht . One of the requirements to making "embeddable" work is to change the default SameSite cookies attribute in Plausible from Lax to None; Secure. This will affect the entire Plausible installation. Is this acceptable? Please let me know as we are nearing completion of this feature. |
Beta Was this translation helpful? Give feedback.
-
@ukutaht iFrame will not work unless samesite cookies are set to None; Secure. Apparently, Lax allows cookies, but only at the "top level", i.e. address bar in browser. Since the Plausible URL we want to use (shared link) resides inside an iFrame, cookies can only be passed if Secure. I believe it is the _plausible_key cookie we need. Here are two helpful references on this subject: https://stackoverflow.com/questions/59990864/what-is-difference-between-samesite-lax-and-samesite-strict and https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite. We may be able to be more restrictive as to when we move from SameSite=Lax to SameSite=None;Secure. Let me discuss and test this concept with Ayman, my developer who is working on this project for us. I will provide an update on this shortly. |
Beta Was this translation helpful? Give feedback.
-
Interesting suggestion. One concern we had was storing a flag value in the database and using it in a more local scope - either per site or even better, per share link (as that might require a trip to the database for each request). Since Phoenix (and Plausible) are new to us, is this a valid concern or is there some caching mechanism where the details of a site or share link are loaded at first request and can be used without a trip to the database? |
Beta Was this translation helpful? Give feedback.
-
Do you see any performance issues with storing the site/share link settings in the database and more importantly, retrieving them each time we need them (which might be with every request)? |
Beta Was this translation helpful? Give feedback.
-
We now have a working self-hosted server that allows embedding of Plausible Analytics in another website. To test this out in your environment, please feel free to sign up for a trial account here: https://plausible.crazygooddigital.com A couple of notes: (1) This is only for testing. Once the test is complete, we will delete all the accounts and any data stored on our server will not be retained. Please post any questions, comments, and suggestions. Finally, I would like to acknowledge the awesome job done by one of my key programmers, @aymanterra. Without his hard work and dedication, this would not have been possible! |
Beta Was this translation helpful? Give feedback.
-
Wonderful to see the progress on this! I look forward to embedding plausible analytics into my website and various org dashboards. |
Beta Was this translation helpful? Give feedback.
-
Interesting use-case came up in #696: embedding individual graphs. I think the first pass should be embedding the whole dashboard but would be good to also support individual graphs. |
Beta Was this translation helpful? Give feedback.
-
Embed mode is now ready. See the docs: https://plausible.io/docs/embed-dashboard |
Beta Was this translation helpful? Give feedback.
-
We have been experimenting with adding another domain to our self-hosted instance (e.g. plausible.domain2.com). The results so far have been interesting. Using Brave browser for testing, with 3rd party cookies disabled, we can embed a Plausible dashboard at mywebsite.domain2.com using a shared link like this: https://plausible.domain2.com/share/mywebsite.domain2com?auth=blahblahblah. Trying to embed using a shared link at domain1.com results in the iFrame being rejected due to the restrictive browser settings. The benefit of allowing multiple domains appears to be creating a 1st party relationship between the Plausible server and the website where the embedding is taking place. Since Caddy/Let's Encrypt supports adding multiple domains to the same SSL certificate, this may be worth exploring and thinking through how a custom domain could be entered in the dashboard and shared links and potentially the tracking script(s) could be served from that custom domain - again making this a 1st party relationship. @ukutaht are there negative implications of this idea in the core Plausible code? If seems (with our limited testing) that if the server responds to the URL containing the second domain, all the routes inside the application seem to work. |
Beta Was this translation helpful? Give feedback.
-
Looks like my response from 2 days ago never made it here. So I am reposting: Uku, so my Brave test environment has the Shield enabled. Without an exception in the "firewall", it will reject an embedded Plausible website (same as you are experiencing). But here are the details of our configuration: (1) Main self-hosted Plausible server URL: plausible.domain1.com (2) Alternate domain bound to self-hosted server: plausible.domain2.com (we accomplish this by editing this file: /hosting/reverse-proxy/docker-compose.caddy-gen.yml, and then stopping/restarting the reverse proxy). Both plausible.domain2.com and plausible.domain1.com work as Plausible servers. (3) Website where Plausible needs to be embedded: www.domain2.com And our test environment: (1) Brave browser. Shields enabled. Third-party cookies are blocked. No exceptions (sites that can always use cookies) for domain1.com or domain2.com. This is intentionally a high-security browser environment. Test results: (1) When I embed a shared link (https://plausible.domain1.com/share/mywebsite.domain2com?auth=blahblahblah) in an iframe at www.domain2.com, the Plausible dashboard is blocked (Brave's 3rd party cookies blocked with no exceptions). (2) If I enable the 3rd party cookies setting in Brave and repeat Test 1, the dashboard is visible. (3) If I add *.domain1.com to "sites that can always use cookies", the dashboard is visible. (4) Other browsers (less restrictive security) are not a problem. Approach to Getting Around Brave Restrictions: (1) When I embed the same shared link using the alternate domain (in order to make this link, we need to manually edit the domain, replacing the first domain with the second one we wish to use for this purpose, e.g. https://plausible.domain2.com/share/mywebsite.domain2com?auth=blahblahblah) in an iframe at www.domain2.com, the Plausible dashboard is visible! No 3rd party cookies or cookie exceptions required. (2) I believe that by using the alternate domain, Brave treats the embedded Plausible dashboard as a first party. This configuration may extend to the JS files if served from the alternate domain. Why Consider This: (1) Blocking of cookies is becoming more common. This makes embedding (and possibly tracking) more difficult. If we can move tracking script and embedding to a 1st party domain, this might result in better tracking and less customer service issues ("can't see my embedded dashboard"). I hope this explains things a little more clearly. If not, happy to hop on a Zoom meeting with you to talk about it. |
Beta Was this translation helpful? Give feedback.
-
👍
I am making a native/web hybrid Plausible app (think: similar to Electron, but more native) for my own use on elementary OS and probably distribution on Flathub or AppCenter. I would like to have more of the app native than just having one big web view, so I can follow the native design patterns of elementary OS.
I have thought of three potential solutions:
An “embedded” flag, i.e. via URL query parameter, that tells Plausible to hide the header, footer, and other bits of navigation. The embedding app would be expected to implement that navigation in its own (native) way.
Individually embeddable widgets, so a native app could have smaller web frames that just show the specific graphs/widgets as needed. These could also be useful if a site wanted to share some social proof—similar to Live visitors widget #119.
A full REST/JSON API of some sort. That would be a lot more work for everyone, but ultimately the most flexible.
For my uses, I prefer solutions 1 or 2 the most.
Here's what I'm doing with my app:
I hide the top and bottom navigation manually by injecting CSS, and then show certain buttons in the native HeaderBar depending on the current page.
Update: Embed mode is now live!
Beta Was this translation helpful? Give feedback.
All reactions