uBlock / EasyPrivacy has blocked even the custom domain

[KristerV]

hey

I have a tracking script on hnsince.com (code is Elixir and OS). I've set up a custom domain for the script at stats.randomforest.ee. Yet uBlock still blocks the script in Firefox.

So uBlock actually looks at the CNAME and blocks the script anyway.

So what workarounds are there? My ideas:

1. Self-hosting, which I don't really want.
2. Taking the index.js content and putting it on my site manually. Would this work? Would updates break it at one point?
3. Configure my own Nginx to proxy the file?
4. Download the index.js not by domain at all, but directly from plausible IP. Or does that change?

With 2 and 3: would these be enough or are the requests to plausible.io (after the script is running) also blocked by uBlock?

[metmarkosaric]

thanks for reaching out @KristerV! yeah, that's known behaviour. Firefox with uBlock Origin can block the custom domain. This doesn't happen on Chrome and Safari though even when uBlock Origin is enabled so it's a Firefox thing only. so unless Firefox stands for huge amount of your traffic I wouldn't worry too much about it but Uku may share advice on other short term measures you could take yourself.

on a relevant note, we're working on introducing a different setup for custom domains to speed up the loading time across the globe via a CDN which indirectly will also make the custom domain unblockable even on Firefox. cannot promise any timeline on when this will be done but we've already started exploring the different options for this.

[metmarkosaric]

No update at this moment. We know what we want to do and how to do it, it's not a priority right now so the work hasn't started yet. This only affects Brave and Firefox with uBlock Origin so it stands for a small percentage of the audience and we have some other more frequently requested features to deal with first. We're a small team with limited development resources so need to take it one step at a time.

[johanrosenson]

@metmarkosaric Thanks for the update :)

I mostly asked because i thought this also applied to ublock in google chrome, but i see now that it blocks our custom subdomain because i stupidly named our subdomain "analytics", and ublock blocks all subdomains with that name :)
I will update later if ublock actually does block anyway in the future, once i have chosen a better subdomain.

[metmarkosaric]

Yeah, Chrome/Safari works all fine even when ublock origin is installed

[johanrosenson]

on a relevant note, we're working on introducing a different setup for custom domains to speed up the loading time across the globe via a CDN which indirectly will also make the custom domain unblockable even on Firefox. cannot promise any timeline on when this will be done but we've already started exploring the different options for this.

@metmarkosaric
What happened to this idea? I have been eagerly waiting for this solution instead of having to deal with setting up our own proxies, one reason we're paying for this service is so that we don't have to deal with some of the technical details, setting up a proxy for each site is a hassle and extra work that I would rather not have.

Now you are removing custom domains completely and the proxy method seem to be only viable replacement.

Can you also add a proxy guide for Apache?

[metmarkosaric]

hi @johanrosenson!

what i was talking about in that message was the proxy approach which we introduced couple of years ago. more details here https://plausible.io/docs/proxy/introduction. there's this option for Apache that we link to from the proxy doc https://github.com/Neoflow/ReverseProxy-PlausibleAnalytics.

our default script loads from a CDN and is more efficient than the old custom domain approach so we recommend that for those that don't want to deal with the proxy.

[Vigasaurus]

Self-hosting, which I don't really want.

This can work of course, but there are alternatives.

Taking the index.js content and putting it on my site manually. Would this work? Would updates break it at one point?

This would work, you'd of course have to update the file manually for new features etc, but the script is backwards compatible. All you'd need to ensure is that in the file the URL it posts to is the correct one (it's a string in the file) - and if you download from the path you're loading normally, this'd be there correctly.

Configure my own Nginx to proxy the file?

You can do this too. The things to keep in mind would be TLS and CSP - but if you just straight rewrite on the Nginx side that should work perfectly.

Download the index.js not by domain at all, but directly from plausible IP. Or does that change?

From what I've seen the Plausible IP seems static, but this may not be a super permanent solution given the IP could of course change on a whim for a variety of reasons and I'm unsure if the plausible host would actually route correctly if requested via IP as opposed to the URL.

With 2 and 3: would these be enough or are the requests to plausible.io (after the script is running) also blocked by uBlock?

I think it would be. uBlock only bases it's rules on the URI, not on the content itself, but there is the potential for uBlock blocking the events being sent too (I'm unsure if it actually does block POSTs, I haven't looked that closely, but I can take a look if you'd like) - but you could circumvent this too with method 2 by changing the URL that events are sent to to your own (by changing the URL string in the js file), and rewriting them to the correct URL through nginx or basic rewrites.

If you have more questions feel free to ask :D

Edit: From a quick look here, it seems Easy privacy does not block the XHR requests to actually send events once the script is loaded, but there's nothing stopping them from adding it in the future, so they could start getting blocked at any time. (uBlock does support this sort of blocking)

[KristerV]

wow great answer! thorough. I guess the Nginx proxy would be best, I'll post a solution here if we figure it out.

[ukutaht]

Only thing I would add is that configuring your own nginx/caddy/apache proxy is by far the most effective and future-proof solution. If API calls are an issue, you can proxy them as well no problem. Since your proxy server won't be a known IP or domain like plausible.io, it will not be blocked by anyone anywhere. And since you're not actually hosting anything, just proxying, it is safe in terms of future updates to the script etc.

Not to discourage contributions but the custom domain infrastructure is probably the most difficult area of Plausible to work on. And like I said in the other issue, we will rebuild it from scratch this year. If you're open to working on other parts of the app it would definitely make things a lot easier.

We have a list of tasks that I feel would be a good first contribution here: https://github.com/plausible/analytics/projects/1. What do you think of those?

[KristerV]

configuring your own nginx/caddy/apache proxy is by far the most effective and future-proof solution

I'll get around to this and post the solution for future people.

a list of tasks that I feel would be a good first contribution

I was hoping I could contribute with something I have experience in or something I need. Just making a feature that I'm not connected to is basically just work that I'd feel better about if it's compensated. I still want to dive in so I'll use Plausible some more. Perhaps I'll find a better connection with the tasks then.

[ukutaht]

Totally. I just posted the list as a reference in case you're looking for something to pick up. Obviously feel free to suggest your own improvements via issues/PRs :)

[metmarkosaric]

Another email arrived about this topic today this time with a similar problem on Brave which now blocks Plausible custom domain out of the box with the default settings:

"we’re customers at Plausible. Since some time Brave browser blocks the Plausible script. We serve it via custom DNS. Changing the CNAME has no effect, it still gets blocked. So it does not seem related to the domain name. Do you have any workarounds you can recommend"

[KristerV]

just for info, it is related to the domain name. Just that Brave (like uBlock) probably checks what is behind the CNAME and finds plausible.io. Anyway I think we've found a solution for now and will post the solution below shortly, so guide that person here.

[Vigasaurus]

Hmm if this is actually becoming more widespread (especially with no user-configuration) maybe there's a potential to improve the solution before of the CDN swap too.

@ukutaht is there a reason you elected to use CNAME redirection for the custom domains solution? I wonder if doing them directly though setting A records and using Nginx's default_server directive on the custom host could help mitigate basically all of these blocking issues - as most any browser-level feature won't be able to step in between DNS/hostname resolution, and thus requests would almost always hit the custom.plausible.io box directly from userdomain->IP. Of course DNS based services would be problematic, but assuming the custom domain is first-party, odds are it wouldn't be blocked by most - or at least not be widespread. The only downside to doing it this way would be that you'd probably need a bit more overhead to issue the certs - it should still be pretty straightforward though (but I'm unsure what your current cert generation looks like).

[KristerV]

So we added this to our Nginx and the script loads just fine now:

location = /pls.js {
  proxy_pass https://plausible.io/js/plausible.js;     
  proxy_http_version 1.1;
}

However.. the requests are still blocked:

So we have 2 options going forward:

1. Rewriting the script target URL with Nginx is possible, but annoying.
2. Hosting the script ourselves..

edit: turns out that Nginx module was already installed so going that route.

[KristerV]

Working solution:

We made a new subdomain plaus.mydomain.com and this is the Nginx config behind it:

 location = /pls.js {
    proxy_pass https://plausible.io/js/plausible.js;
    proxy_http_version 1.1;
    proxy_set_header Accept-Encoding "";
    sub_filter_types "application/javascript";
    sub_filter plausible.io 'plaus.mydomain.com';
  }

  location / {
    proxy_pass https://plausible.io;
    proxy_http_version 1.1;
    proxy_set_header X-Forwarded-For   $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Host  $host;
  }

You need this Nginx module for the sub_filter command to work.

What it does is:

1. Make the plausible.js script available at our own domain: https://plaus.mydomain.com/pls.js
2. Rewriting the contents of the plausible.js script so the POST requests from the script would be directed again to our own URL.
3. Proxy the POST requests back to plausible.io while forwarding headers.

@ukutaht can you please check that the header setup makes sense? What headers does Plausible need?

[Vigasaurus]

The second option can be even more aesthetic, but I guess it depends on the support for IE you want to maintain. https://caniuse.com/?search=currentscript

[ukutaht]

@Vigasaurus Nice I wasn't aware of the currentscript api. We haven't defined our level of browser support at the moment which we need to do.

[KristerV]

My vote is on the second option. I can't really imagine why I would need to manually override the value if I'm already proxying the file.

The /api/event hard coded path seems a little dirty, but since having a separate subdomain for this is a good idea anyway, I guess it doesn't make a difference (and perhaps it'll prove useful later).

[ItalyPaleAle]

I don't know if this has been implemented, but my vote is on the first option which offers more control and flexibility. This way we could do things like:

• Proxy the analytics from the same domain as the site (so users connect to a single domain, and this helps with performance thanks to HTTP/2 multiplexing, and it makes it harder for blockers to block the entire domain)
• If proxying the APIs isn't an option, would at least allow keeping the JS script on a separate domain.

However I think it would be important for the script to still contain a default domain. Not just so the absence of data-api would still work, but also because then each domain's script is unique and ad-blockers have a harder time blocking scripts base on their hash.

Also, two questions/suggestions:

• Would be great if data-api wasn't just a hostname but in general a URL prefix (if not possible already). So I could set it to https://plaus.mydomain.com/foo and then have the Plausible APIs at https://plaus.mydomain.com/foo/api/message.
  Reason for this is so I could even proxy Plausible from the same domain as my site, making it even harder for ad-blockers to do domain-based blocking (they'd have to block the entire site)
• Because the next step for ad-blockers is blocking scripts named plausible.js no matter what domain they're on (they've started doing that), maybe the Plausible server could respond with the script no matter what the the requested file is. So we could request a random JS file (as long as non-existing, so like pizza.js or 3hndsf723.js) and the server would respond with the Plausible JS script

[ukutaht]

This hasn't been implemented yet, but I'm planning to do it sometime in the coming months. Your suggestions are great, thanks for thinking along with this.

I suppose we could combine the 2 options. Use data-api if present. If not, use document.currentScript to figure out which hostname the script is being loaded from and send it to /api/event on the same domain. It could even be smart enough to account for subdirectory installations.

I like both your suggestions. Makes a lot of sense.

[TheNomad11]

The thing is that even www.plausible.io is included in most anti-tracking lists, so when using a vpn with adblock enabled or with pi-hole even plausible.io is not reachable

[metmarkosaric]

By the way I wish blocklist maintainers would come together and create some kind of best practice list. Kind of "If you don't track personal data, don't do any connection to adtech, don't do any behavioral profiles across websites/devices, be open source etc etc, then we will not block you". Google will never do anything to get on this list and this would encourage a larger percentage of websites to remove GA and replace it with one of these better "approved" tools.

And we would be the first to remove our custom domain feature and would take no step whatsoever to try and avoid adblockers if that was implemented. But unfortunately by the principle they're taking in that all trackers are bad they give no incentive for people to remove GA and then they also give incentive for site owners to look for ways to count stats without being blocked by adblockers.

[KristerV]

As long as you use Plausible with a custom domain enabled, I wouldn't worry too much about adblockers.

Just custom domain doesn't actually help all that much. uBlock still knows you're redirecting.

Now one has to deal with lots of dependencies and reverse proxies that cause lots of issues)

The solution I've posted above (mark, can you mark it as the solution to this thread?) does take just a little bit of work, but does not cause issues after that. Just works. Script stays updated. All good.

[metmarkosaric]

Just custom domain doesn't actually help all that much. uBlock still knows you're redirecting.

uBlock can only do this on Firefox but not on Chrome or Safari

GitHub doesn't allow me to mark as solution on this forum only on the q&a forum for self-hosting, I do link people to your comment when they ask about how to manually try to avoid this.

[KristerV]

GitHub doesn't allow me to mark as solution

okay. then upvoting should be encouraged.

uBlock can only do this on Firefox but not on Chrome or Safari

Oh yeah i forgot.

[metmarkosaric]

just upvoted it myself :)

[divinerites]

Hello,

Did you tried to reach Brave.com asking for them to remove the blocking because you do not track user personal informations ?
And by by doing this they will help remove the "bad usages of tracking" instead of removing "the privacy friendly" ones ??

Does it worth trying to reach them ?

[metmarkosaric]

thanks @divinerites! would be nice for sure! there were couple of threads on twitter on this including this one yesterday https://twitter.com/JeremiahLee/status/1370805886017495047

[fabsau]

Also when when selfhosting I ran into multiple issues. First it was triggered by the name of the script (plausible.js), then by the url it was connecting to (plausible.[domain.tld]). After renaming the script to "stats.js" and changing the plausible URL to data.domain.tld I successfully bypassed the uBlock Origin Easylist. Let's hope the triggerwords won't change in the future too often.

I know the main problem is about the cloud version, but I found this issue googling and it helped me troubleshooting my issue. Then maybe could this comment help somebody else as well.

[metmarkosaric]

If you're concerned about adblockers, we now have instructions on how to proxy our script. See https://plausible.io/docs/proxy/introduction

[ItalyPaleAle]

Wow looks like the new version supports the data-api attribute too! This will help proxying (caching) the JS script separately from the API endpoint :) (ideally you'd still want them both on your main domain to prevent DNS-based adblockers, but it's great news regardless) Thanks!!

[nicbou]

This unannounced broke tracking for me. I had to find this on my own after noticing page views went to 0 and reading the minified code.

[metmarkosaric]

this didn't change anything in the current setup. if you're using a custom domain, it is still working all fine.

[nicbou]

I opened a ticket for it (#1061) that contains more information. If you already proxied the script, this change broke tracking completely. Instead of sending events to the request host (stats.allaboutberlin.com), it sends them to the script's domain (allaboutberlin.com).

[divinerites]

Thanks a lot @metmarkosaric !!

Happy to let you know that my gohugo-plausible module is now able to manage this proxying (plus warning about deprecated CNAME).

[metmarkosaric]

nice! thank you @divinerites!

[divinerites]

Just to confirm @metmarkosaric

If we want outbound-link, the redirect file should read

/misc/js/script.js https://plausible.io/js/plausible.outbound-links.js 200
/misc/api/event https://plausible.io/api/event 200

and the script will remains <script defer data-domain="yourdomain.com" src="/js/script.js"></script>.

Right ??

[divinerites]

Hello @ukutaht it works (I mean the standard /misc/js/script.js).

But I now have quite a reasonable amount of error 500 for the script.
Did you noticed this ?
And this seems confirm by my average stats being lower since 2 days.

Any idea ? I change nothing and it switch from 200 OK to error 500 without any pattern.
I'm on Netlify

[divinerites]

Hello @ukutaht,

I can confirm this still happens. This time the event fails (see screenshot).
Any idea ? (PS: I opened a post on Netlify

This is my _redirects

/misc/js/script.js https://plausible.io/js/plausible.outbound-links.js 200
/misc/api/event https://plausible.io/api/event 200

[divinerites]

Not sure if related but there is a post on Netlify about the cause being "no valid HTTP response".
I'm not technically able to have an opinion on this. @ukutaht ?

https://answers.netlify.com/t/redirect-returns-500-internal-server-error-for-only-put-and-delete-requests/12280/9

$ curl -I https://www.camping-arolla.com/misc/api/event
HTTP/2 500 
server: Netlify
age: 0
x-nf-request-id: 3016a1f8-d520-4f57-874b-ceadfac73d00
date: Wed, 26 May 2021 12:23:14 GMT

$ curl -I https://www.camping-arolla.com/misc/js/script.js
HTTP/2 200 
age: 0
cache-control: max-age=3600,public
content-length: 1830
content-type: application/javascript
cross-origin-resource-policy: cross-origin
date: Wed, 26 May 2021 12:23:42 GMT
server: Netlify
x-nf-request-id: 396518f1-e04a-41e9-b78f-be514dafd0cb

[divinerites]

This is the response from Netlify engineer. Any statement/comment about that ?

Hey! I’m cURLing the URL now and seeing a 404 which makes sense, 
as raw requests to the path also return a 404.
The 500 error is/was likely returned by the proxied path itself!

[divinerites]

To avoid this point beiong too deeply nested with other things, I opened a proper issue : #1085

[ukutaht]

Warning for people that are using a proxy setup like what @KristerV posted in #610 (comment): please double-check that it's working and it may need some adjustment.

We made a change so that the hostname where to post analytics data isn't baked into the script anymore. Instead, it's pulled from the document.currentScript.src value. This means that if you're proxying the script from yourdomain.com/pls.js then it will attempt to post data to yourdomain.com/api/event which will not work.

You can fix it by supplying data-api="https://plausible.io/api/event" to the script tag to override the API endpoint.

Alternatively, you can set up a proxy using our new proxy guides section in the docs: https://plausible.io/docs/proxy/introduction.

[nicbou]

This is now working fine for me. However, I see a few "HTTP 499" messages in the reverse proxy's logs when calling /api/event. Is this expected?

[ukutaht]

No, this is not expected. A tiny amount of timeouts can be acceptable I guess, depends what percentage of requests are failing.

[ItalyPaleAle]

The only problem now is that with no domain included in the JS file, the content of plausible.Js are the same for everyone. So ad-blockers could switch to hashing the file and blocking those that contain the hash.

How about adding a few bytes of gibberish (like a string with a random number that has no use) at the beginning of the file?

[thomasjsn]

I'm testing the proxy solution on CloudFront, using a custom origin and behavior.

I'm concerned that the visitor IP and User-Agent gets lost when the request hitting you is from a CloudFront edge server, and not the actual visitor. Seems that you need IP and User-Agent for "uniqueness" and country.

This is next to impossible for me to verify.

I've set up a test, which does seem to work, but I am unable to verify that country and unique users are based on the actual user and not the CloudFront edge server.

Suggestions?

[ukutaht]

Oh I see. That only exists for our live demo, it should not be depended upon by anyone because we don't guarantee keeping it around.

Can a path mapping be added to the Cloudfront config?

[ukutaht]

Sorry I didn't read your reply correctly. Clearly the mapping cannot be added.

So the only way to make it work in Cloudfront seems to be to support all the script variants with the name /js/script.js on our origin.

[thomasjsn]

@ukutaht The request URL can be rewritten using lambda@edge, but like I wrote; it does make the setup more complicated — it's no longer a pure Cloudfront solution. The easiest would be that no name rewrite is required.

Just an idea; instead of manually having to administer aliases, maybe some wildcards could be used? Like /js/whatever-variant.js returns the script. This would also make it easier for webadmins to use random script names, to further prevent blocking.

[ukutaht]

Yeah that's a pretty good idea. The reason I haven't gone that route yet is because the actual app assets are also kept in /js/*.js. If someone used /js/app.js for their tracking script for example, it would shadow the actual /js/app.js which is necessary for the dashboard to work.

Maybe I could move the dashboard assets to some deeper subdirectory like /js/app/*.js and any filename in the base /js/ directory would then return the tracking script.

I actually really like this option. Super flexible, not making any decisions for you and no manual configuration required. Do you see any issues with this approach?

[thomasjsn]

Make sense to separate the app assets and the proxy targets. You could put the tracking scripts on a dedicated subdomain, maybe easier to manage the configuration for it, without breaking something in the app.

But as long as they don't get mixed up, I think it should be good :)

I think this solution is easy to manage, and to users :) /js/tanktop-dance-queen.outbound-links.js would just magically work :)

[marban]

Here's a quick & dirty way to get it running on App Engine Flex / Flask. Didn't have the time to make it prettier but things seems to work.

def stats_target(url, method, headers={}, data=None):
    hd={}
    headers_lower = {k.lower():v for k,v in headers.items()}
    hd["User-Agent"] = headers_lower.get("user-agent","")
    hd["Accept-Language"] = headers_lower.get("accept-language","")
    hd["Accept-Encoding"] = ""

    try:
        ip = request.access_route[0]
        hd["X-Real-IP"] = ip
        hd["X-Forwarded-For"] = ip
        hd["X-Forwarded-Host"] = ip
        hd["Referer"] = request.referrer
    except:
        pass

    if method.upper() == "GET":
        r = httpx.get(url, headers=hd, allow_redirects=False)
        headers_fwd = {"Content-Type": "application/javascript"}
        status = 200
    else:
        r = httpx.post(url, headers=hd, allow_redirects=False, json=json.loads(data))
        headers_fwd = {"Content-Type": "application/json; charset=utf-8"}
        status = 202
    out = Response(r.text, headers=headers_fwd)
    out.status_code = status
    return out

@app.route('/tks/js/script.js', methods = ["GET", "POST"])
def stats_js():
    try:
        return stats_target("https://plausible.io/js/plausible.js", request.method, dict(request.headers), None)
    except:
        out = Response("", headers={"Content-Type": "application/javascript"})
        return out, 200

@app.route('/tks/api/event', methods = ["GET", "POST"])
def stats_event():
    try:
        return stats_target("https://plausible.io/api/event", request.method, dict(request.headers), request.get_data(as_text=True))
    except:
        out = Response("", headers={"Content-Type": "application/json; charset=utf-8"})
        return out, 202

[ndom91]

data-api does not seem to work anymore. I'm using the plausible.outbound-links.js script and couldn't find any mention of grabbing and using the data-api attribute. In fact, its got /api/events hardcoded in.

Is this a regression? Or do I need to use a special script to support rewriting the api path?

[ukutaht]

It should work fine and I just checked, the code is as I would expect:

This is minified from https://plausible.io/js/plausible.outbound-links.js but as you can see it checks for data-api first and then falls back to the script origin plus /api/event. Is this not working for you as you'd expect?

[ndom91]

Strange, I"m using the self-hosted version of plausible, but mine doesn't have the getAttribute('data-api') anywhere.

Here's the pretty-printed version I get served of plausible.outbound-links.js:

!function(n, i) {
    "use strict";
    var e, o = n.location, s = n.document, t = s.querySelector('[src*="' + i + '"]'), l = t && t.getAttribute("data-domain"), c = n.localStorage.plausible_ignore;
    function p(e) {
        console.warn("Ignoring Event: " + e)
    }
    function a(e, t) {
        if (/^localhost$|^127(?:\.[0-9]+){0,2}\.[0-9]+$|^(?:0*\:)*?:?0*1$/.test(o.hostname) || "file:" === o.protocol)
            return p("localhost");
        if (!(n.phantom || n._phantom || n.__nightmare || n.navigator.webdriver || n.Cypress)) {
            if ("true" == c)
                return p("localStorage flag");
            var a = {};
            a.n = e,
            a.u = o.href,
            a.d = l,
            a.r = s.referrer || null,
            a.w = n.innerWidth,
            t && t.meta && (a.m = JSON.stringify(t.meta)),
            t && t.props && (a.p = JSON.stringify(t.props));
            var r = new XMLHttpRequest;
            r.open("POST", i + "/api/event", !0),
            r.setRequestHeader("Content-Type", "text/plain"),
            r.send(JSON.stringify(a)),
            r.onreadystatechange = function() {
                4 == r.readyState && t && t.callback && t.callback()
            }
        }
    }
    function r() {
        e !== o.pathname && (e = o.pathname,
        a("pageview"))
    }
    function u(e) {
        for (var t = e.target, a = "auxclick" == e.type && 2 == e.which, r = "click" == e.type; t && (void 0 === t.tagName || "a" != t.tagName.toLowerCase() || !t.href); )
            t = t.parentNode;
        t && t.href && t.host && t.host !== o.host && ((a || r) && plausible("Outbound Link: Click", {
            props: {
                url: t.href
            }
        }),
        t.target && !t.target.match(/^_(self|parent|top)$/i) || e.ctrlKey || e.metaKey || e.shiftKey || !r || (setTimeout(function() {
            o.href = t.href
        }, 150),
        e.preventDefault()))
    }
    try {
        var h, f = n.history;
        f.pushState && (h = f.pushState,
        f.pushState = function() {
            h.apply(this, arguments),
            r()
        }
        ,
        n.addEventListener("popstate", r)),
        s.addEventListener("click", u),
        s.addEventListener("auxclick", u);
        var d = n.plausible && n.plausible.q || [];
        n.plausible = a;
        for (var g = 0; g < d.length; g++)
            a.apply(this, d[g]);
        "prerender" === s.visibilityState ? s.addEventListener("visibilitychange", function() {
            e || "visible" !== s.visibilityState || r()
        }) : r()
    } catch (e) {
        console.error(e),
        (new Image).src = i + "/api/error?message=" + encodeURIComponent(e.message)
    }
}(window, 'https://domain.tld')

[ndom91]

I'm using the docker container plausible/analytics:latest with the sha256:ea787e180e9833342f4e17af9a310412af717e215e235765f3c76776c518905f

[ukutaht]

This feature is brand new and hasn't made it into a self-hosted release yet. From the README of this repo:

Bug fixes and new features are released to the cloud version several times per week. Features are battle-tested in the cloud which allows us to fix any bugs before the general self-hosted release. Every six months we combine all the changes into a new self-hosted release.

[ndom91]

Ah gotcha, wasn't aware this was new. Thanks!