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.
-
|
I would look for a way to avoid this but if it's not possible, I guess we'll have to go with What issue do you get when it's kept as Lax? |
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.
-
|
Thanks @bradkane. This makes sense to me. Only thing I would look into is whether we could introduce a new |
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.
-
No, there's no such mechanism so you should be good to go |
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.
-
|
Not really. At the moment the |
Beta Was this translation helpful? Give feedback.
-
|
Thank you! This is exactly the guidance we needed. We will adjust our approach accordingly. |
Beta Was this translation helpful? Give feedback.
-
|
@ukutaht We attempted to set the cookie parameter {Lax, None; Secure} dynamically by checking the incoming URL, but that turned out not to be possible. Plug inside Phoenix has some quirks about processing order in endpoint.ex and we also found that this code was being cached, making a dynamic approach impossible. That being said, we might be missing something. A better approach seems to be to use the ENV file and add a new (optional) config variable to set the cookie parameter for the entire server. If the config variable is missing (current situation), the configuration will default to {Lax}. If the config variable is present, we will set the cookie parameter according to the value entered. {e.g. None; Secure}. The result is that a self-hosting server will either allow embedding or not. The choice of whether this will be supported is up to the server administrator. Once a server has been configured with the proper cookie setting, individual sites can control whether embedding is permitted or not. This is up to the site account owner. Once enabled, a shared link URL such as https://domain.com/share/embed/123abc would be used as the iFrame source in the third party website. One final area we are exploring is how shared link password may (or may not) be permitted with an embedded URL. Once this is determined, we should have a working version ready to go. Finally, it might be useful to allow you (and others) to try the embedding feature using our self-hosted server. Once our code is ready, we will migrate from a local instance to a cloud-based instance we have provisioned already. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, looking forward to it! |
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.
-
|
No worries, @ukutaht on not having the time to check out embeddable. API is very big and very exciting! Your comment about the lack of semantic classes in the HTML elements is starting to make sense. This explains why I did not see any meaningful HTML inside the iFrame with an embedded dashboard, but do see them in my Plausible dashboard when logged in. To allow users to modify the styling, we would need to have semantic classes (I think) so that we can target them with styles. I am not familiar with TailwindCSS, but I will explore it. Something new to learn. I will also look at hCaptcha. I have seen this (or similar) approach with another company - WuFoo (sister company of Survey Monkey). They use a similar JS approach with the form key as the div id. The JS file targets the content of the div and creates an iFrame dynamically. What WuFoo does in their dashboard is allow the user to specify a CSS file (served over SSL). When the JS script on the client website runs, it dynamically builds an iFrame wrapper inside the div, and loads the content via an AJAX call. Part of that HTML content is a reference to the CSS file specified in the dashboard. I was thinking about the same approach for Plausible embeddable. This approach seems to be more secure in that the person controlling the dashboard defines the location of the CSS file in the portal (WuFoo or Plausible). iFrames are more difficult to work with. Their benefit is security and isolation. If you don't want someone messing with the content (a good idea for a captcha box and a web form), then iFrame is a good approach. With respect to Plausible, that's an interesting question. Personally, I like the idea of isolation, as the analytics data should be from a trusted source (Plausible) and not easily manipulated (which would be the case in a div). By allowing only CSS injection, just the styling of the data could be changed, not the data itself. Also, but asking the user to define a trusted CSS file - trusted because it is served over SSL and at a location that the analytics administrator specified, the risk of manipulation is low. And as I am thinking, perhaps there are two answers here: embed a Plausible dashboard inside an iFrame and expose any and all data through the API. Inside the iFrame, the source is Plausible, clear and distinct. In fact, perhaps there should be a note at the bottom of the dashboard "Powered by Plausible". For two reasons: one, you owe me a beer for the brand plug:) More importantly, it tells the viewer the source of the data... Plausible. The second approach is the API, where the user is responsible for using the data. They are including it as they see fit, manipulating it as they see fit, styling it as they see fit. The responsibility is on the user, not Plausible. I would suggest accommodating both use cases. @aymanterra and I will look at the hCaptcha reference and Wufoo as well and see how both of these approaches can benefit Plausible. More to come... |
Beta Was this translation helpful? Give feedback.
-
|
@bradkane Thanks for this. I took another look and it looks like hCaptcha works exactly as you described: the script is just included to generate the I have 0 experience with iframe CSS injection. Until I do my own research I'm happy to trust your knowledge on this :) I'm flexible on how self-hosters choose to manage this for their own installations but when our official cloud dashboard is embedded, I definitely want to include our branding. Doesn't have to be huge but just a 'powered by' message so people know where the stats are coming from. |
Beta Was this translation helpful? Give feedback.
-
|
I have more time to look at this now. @bradkane Could you share your repository or open a draft PR on this repo so I could set up my own testing instance for this? We have a bunch of data on our own servers already, I'd rather test embedding with these than register a trial account on your dev box. I'd also like to play around with the code and make some changes. I read up on iframes a bit this morning. Couple things I'd like to play with:
|
Beta Was this translation helpful? Give feedback.
-
|
With regard to nr 1, here's a PR I'm working on that should make the cookie stuff simpler: #752 |
Beta Was this translation helpful? Give feedback.
-
|
@ukutaht Just invited you to our repo. @aymanterra has been working on making two specific changes: a solution for light/dark and the ability to inject an external CSS file and control the look of the embedded Plausible view. He is hoping to have this done in the next few days (he has been busy on other things), so you might want to wait a bit for him to finish, but that is up to you. Understood on the iFrame loading and the JS solutions designed to achieve an async page rendering. We will look at the PR you suggested on simpler cookies. |
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.
-
|
@p4block @ukutaht Embedding individual graphs is very interesting. I have an idea on how we might be able to accommodate this in our current approach to embeddable. I think we need to include the time dropdown to make the graph more dynamic. As a first pass, we might be able to deliver these options in embeddable: all panels, panel 1 (main graph), panel 2 (top sources, top pages), panel 3 (Countries, Devices). Let me consult with @aymanterra. What do you think about the panel idea (if we can do this)? |
Beta Was this translation helpful? Give feedback.
-
|
I've been a customer of Plausible for a while and I have been eagerly awaiting this feature because it would change the game for my org. I'd highly appreciate the entire dashboard iframe embedding option as soon as the team is able. I think plausible would also gain a huge marketing boost from having their analytics embedded in many websites. And of course, thank you for the wonderful open-source work you do. |
Beta Was this translation helpful? Give feedback.
-
|
@bradkane I think it's an interesting idea but it's not worth increasing the scope of the work you're doing. Let's prove the entire dashboard first, individual graphs can be worked on separately once the basics are there. |
Beta Was this translation helpful? Give feedback.
-
|
@ArsalaBangash Mind sharing what the use-case for your org is? Feel free to email me at [email protected] |
Beta Was this translation helpful? Give feedback.
-
|
We have made some progress in allowing customized styling of dashboards by including external CSS stylesheets. The only requirement is that they be served over SSL. So it is possible to use a common location (e.g. https://domain1.com/plausible/css) to serve stylesheets for multiple domains (e.g. domain1.css, domain2.css). The stylesheets would affect both shared links and embedded shared links (the primary reason for this feature). In the screenshot, you can see the impact of changing the background color by applying overriding styles for both the light and dark themes. The use of the !important CSS directive is not required, but will force the desired result. Nice work @aymanterra :) |
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.
-
|
@marko @ukutaht Really well done!!! @aymanterra and I had our first chance to discuss as we reviewed the release notes last Friday (after your mad dash to release everything). The changes were solid and true to the spirit of Plausible Analytics. It was an honor to be part of this and we hope to contribute more in the future. |
Beta Was this translation helpful? Give feedback.
-
|
thank you for all the help @bradkane and @aymanterra! and for the kind words! |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for everything @bradkane and @aymanterra ! |
Beta Was this translation helpful? Give feedback.
-
|
@bradkane @ukutaht and @metmarkosaric Thank you for the support and your nice words. |
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.
-
|
Sorry Brad I don't fully understand your setup and suggestion. Could you explain in more detail what you mean by 'allowing multiple domains'? I tested with @metmarkosaric's setup and yes I can access the embedded stats on https://markosaric.com/stats/ with Firefox but not Brave. This is what I get in brave:
I guess adblockers are being indiscriminant about blocking the whole plausible.io domain. When I disable the Brave Shield, it loads fine. How can we fix this? I guess we could move our script to a |
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 created an issue to track this problem: #919 |
Beta Was this translation helpful? Give feedback.
-
|
I think this issue is become more widespread. For example, I was looking at one of my websites just now that uses a Vimeo embed. In Microsoft Edge (Privacy=Balanced, which is the default), I see this message in the Console: Tracking Prevention blocked access to storage for . Here is Microsoft's explanation: https://docs.microsoft.com/en-us/microsoft-edge/web-platform/tracking-prevention . I suspect that the 3rd party service Microsoft is using has determined that Vimeo's domain is one that should be blocked for tracking purposes. My concern is that in the future, Plausible domains could be added to those lists as well (as its popularity grows). Perhaps in the new world, everyone will have to give permission for everything. If so, we will have a terrible user experience, with intrusions all the time. I am thinking about whether we should move to a first-party tracking website/tracking server relationship, which in theory, would bypass all of these concerns or wait for the problem to reach critical mass to solve it. Unfortunately I think that it will be sooner than later. |
Beta Was this translation helpful? Give feedback.
-
@bradkane what did you mean by this? |
Beta Was this translation helpful? Give feedback.
-
|
@ally9335 We have decided to move to a first-party tracking implementation of self-hosted Plausible. So we will host Plausible at srvr.domainA.com and use it to track host1.domainA.com, host2.domainA.com, etc. In our testing this has kept us from being blocked by most privacy-focused browsers. Since we have made that decision, I have not kept current on whether the Plausible script and /or domain (plausible.io) are on blacklists to prevent tracking website traffic. In addition, there are proxy strategies and some actual code posted on GitHub to implement that. @metmarkosaric, can you add any recent information about whether blocking of Plausible is a current issue or not? |
Beta Was this translation helpful? Give feedback.
-
|
there's more info about this and instructions for different hosting providers/tech stacks here https://plausible.io/docs/proxy/introduction |
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