Query String Support

[sarthaktexas]

Google Analytics has custom query strings that allow it to detect where specific traffic came from. Umami does not appear to support this but it would be very helpful and not that difficult to implement.

[mikecao]

You can click on the More button below the urls and filter by Raw, that will show you the query strings.

If you're wondering why you don't get query strings in urls sometimes, it's because Chrome has it disabled by default, https://developers.google.com/web/updates/2020/07/referrer-policy-new-chrome-default

[sarthaktexas]

What I'm asking is if I can provide custom query strings at the end of my links in newsletters and such. If so, what would be the template for this?

[mikecao]

There is no reporting based on query string parameters if that's what you mean.

[jnaklaas]

This is something that I think should really be added. Knowing where visitors come from is quite essential to measure which source, campaign or medium generates the most traffic / leads. Which is essential to know where to invest your money for future campaigns.

The referrer is not always known by the browser. For example in newsletters, or when the referrer uses http and the website uses https (or vice versa), or when the referrer data is blocked by the referrer (our main advertising platform blocks it and they refuse to change it for some reason - I suspect laziness). From what I can tell, these visitors are just not shown in umami under "Referrers". In Google analytics the referrer source would then be shown as "direct", as if the visitor entered the url directly in the address bar.

Google analytics solves this by using the utm_source query parameter as referrer (when available). Ackee analytics does the same using the source query parameter.

Meanwhile I discovered that there should be a way to do this in umami, by turning off data-auto-track and using the umami.trackView function to send the pageviews to umami. Downside is that in this case, events too can only be sent to umami by writing custom functions. So it would be nice if this feature would be built in to be able to use the auto-tracking while having decent referrer data.

I noticed that by default (when using auto-track) umami always sends the page's referrer. Which is your own website except for the first page you visit. How does umami link pageviews and events to the same user? It doesn't use cookies or session storage?

Also, it would be useful to be able to see events per referrer. For example it would be useful to know which source, campaign or medium generates the most contact form requests.

[mikecao]

All urls are already being collected. If you pass in utm_source it will be recorded. The only thing missing is there's no way to report on the parameters. It's something we can look into.

[artfulrobot]

Did this ever get looked into? Being able to filter by utm_campaign etc. is super useful as you can see what pages folx visit etc. I'm trying to decide Umami vs Plausible at the mo, and Plausible seems to have the edge because of this filtering/reporting availability.

[jnaklaas]

What I'm primarily suggesting is that there could be a query parameter that overwrites the referrer value that is sent to umami. Reporting wouldn't have to change that way. This would fix so many situations where the referrer is not collected by the browser.

Also, thanks and congratulations for the good work with Umami! Can I buy you a coffee?

EDIT: I've tried to do the above myself by changing line 42 of public/tracker/index.js:

  const getQueryStringParams = query => {
    return query
      ? (/^[?#]/.test(query) ? query.slice(1) : query).split('&').reduce((params, param) => {
          let [key, value] = param.split('=');
          params[key] = value ? decodeURIComponent(value.replace(/\+/g, ' ')) : '';
          return params;
        }, {})
      : {};
  };

  let currentRef = getQueryStringParams(location.search).utm_source || document.referrer;

Umami expects the referrer values to be URL's. If they're not, they're still not displayed in the reports despite being saved in the database.

To show these in the dashboard, I had to change the refFilter in lib/filters - perhaps not the most elegant solution but i just return the url on line 87: return url; instead of return null;.

To show in the realtime dashboard, I tried to change components/metrics/RealtimeViews.js. I didn't manage to get it working though. See my attempt at jnaklaas@8e387af.

[joe-pritchard]

I'm more than happy to set the referer myself when I record the pageview, that way I can use whichever query parameter (or other logic) I want to decide what should go in there.

As you say, the big thing would be actually displaying referers in the dashboard when they're not necessarily always URLs, that would be really useful

[addlistener]

Basically the referrer URL is not useful at all in real-world cases. Social platforms disallowing links to be posted, or adding "noreferrer" to the link.

Take a look at my real stats

A simple filter for query strings is what actually works in 2024. That's how organic traffic & paid traffic works like @jnaklaas mentioned

We love umami as an opensource Google Analytics alternative. But now it cannot serve as 100% alternative.