General

Tracking

  • Navigate to the domain-profile once logged in via insights.rumvision.com

    When going to the dashboard, you'll immediately get prompted with a notification that there is no data yet. The notification will also show a link to a new page, containing your domain's snippet.

    These notification can be disabled for the current session. If you aren't being prompted anymore, then collapse the "Settings" option and go to "Snippet".

    Once seeing your snippet, you can copy it in two ways:

    1. automatically by clicking "Copy" at the top right;
    2. or manually by selecting the contents and then copying it.

  • Paste this code snippet in the HTML source code (or JavaScript) of your website if your not using a Tag Manager solution.

    When using Google Tag Manager, you should use the "Custom HTML" type and "All pages" trigger.

    How to install the snippet

  • Yes. Or in other words: there is no need to allow or exclude certain URL's from within your website or Google Tag Manager. Your domain's snippet will know which URL's should be tracked.

    From there, it will regulate itself based on allowed pages, which means you can safely implement it on all pages.

  • Our snippet isn't that different than other (maybe third party) snippets: it is only able to collect data from visitors that were patient enough to wait for the page to load.

    Just like Google Analytics: if the performance of your website or shop is bad for whatever reason, Google Analytics might actually not even be able to track them. As a result, your bouncerate might look better than it actually is. This already is an incentive to get started with improving your site or shop's performance.

    When it comes to our tracking snippet, it's constructed to not be parse or render blocking. As a result, it is save to add it in your head section as well as at the end of the body. When using (Google) Tag Manager, you can use the "All pages" (Page View) trigger, or any of the other triggers (DOM Ready or Window Loaded).

    The sooner it is being executed, the more data it will collect.

  • As we're not receiving personal identifiable information (PII), there is no need to put our snippet behind a privacy notice. See our Privacy compliance page for more information.

  • Yes, as with any third-party integration, we strongly urge you to make sure your webshop or website works as you expect.

    So, try ordering a product through checkout, to see if the process still works. Test forms and other important pages.

    After the snippet is added, we don't expect there will be any problems, but it's better to be safe than sorry.

  • There are two options in conjunction with a cookie banner:

    • Our script is not loaded at all without consent (the easiest to implment for one when you want to be 1000% safe as a marketer, but then INP, CLS and LCP can be missed when one closes the screen immediately after the cookie notice)
    • Load our script directly (then very little is missed and all metrics are measured directly), but people have to let us know via a callback that there was consent, and then we start tracking additional things as well (like browser version, device memory, pixel ratio).

    Then the metrics come in directly, and this data is only combined with the datasets once there is consent, but there is also nothing to worry about when that data is not there (then you simply have less filtering capabilities in those dimensions).

    Device memory, pixel ratio and browser will be tracked because they are privacy compliant, but there may be privacy officers who disagree, and so we've built in at the freedom to let people regulate that themselves.

Data

  • Lab data means metrics from the lab. So, how is a webpage performing when testing under simulated conditions. This is also known as synthetic testing. For example, when running Lighthouse, you will get lab data.

  • Field data means collecting data from the field. In case of pagespeed and performance testing, this means getting data from real users. Unlike lab data from synthetic testing, users won't be visiting webpages under the same conditions. This is why it's important to also monitor user experience of real users, maybe in addition to synthetic testing.

    For example, Google's Core Web Vitals is based on field data. Which is good as lab data and field data can be very different, but in the end it's about your very own users/audience. The downside of Core Web Vitals is that data is very generic instead of fine graine-.

  • RUM is the abbreviation or Real User Monitoring. This means you're monitoring real users, which then leads to field data.

    RUM solutions such as our very own solution will provide stakeholders with in-depth data about those real user experiences.

Dashboard

  • Once implemented, you should see first results within 10 minutes after visitors visited one of the added URL's since implementation.

  • If you don't see any data yet, then the following could be happening:

    • The snippet was not added yet. If you are using Google Tag Manager, then you can use Google Tag Assistent to verify this. For example: maybe a trigger hasn't been set yet or your new tag wasn't published yet;
    • The implementation could be malformed. For example, be sure to include the opening and closing script-elements as well;
    • You might have implemented it behind a cookie notice. Being privacy compliant, this actually isn't necessary;
    • The tracked URL's aren't visited by real users yet;
    • Your website might be using a plugin that is delaying JavaScript, for example until users start to interact. In general, this often is bad for overall UX instead of just tracking purposes;
    • You, your platform, your hosting or your developers might have configured a Content Security Policy to prevent random scripts from being executed. Be sure to add the cloudfront domain that is being used, to your security policy and script-src in particular.

    In case of any issues, just reach out to us.

  • Data is based on real users, so it doesn't get any more accurate than that. There could be discrepancies though. For example in the following cases:

    • your website or webshop's performance is very bad. As a result, not all users might be tracked. You might then see better data then it really is (as those with really poor UX could not be tracked);
    • users could have JavaScript disabled;
    • Not all metrics are supported by all browsers, which could skew gaps between FCP (good browser support) and LCP (not supported by all modern browsers) for example;
    • Even when it comes to a single metric, there could be differences amongst browsers. Such as the FCP metric;
    • When having a lot of (headless) bots, they are actually executing the page. Lighthouse is doing this as well, for example. When regularly doing synthetic tests, you could choose to exclude this data, or test with pages which aren't being tracked;
    • When currently using performance hacks, data won't be as trustworthy. We encourage you to not use any hacks to get a better understanding of real UX. In the end, these metrics were introduced not to annoy us, but to get insights or real UX of our very own audiences.

Notifications

  • Would you like to receive more or fewer emails from RUMvision? You can change the following via your profile settings:

    • Alerts;
    • Domain notifications;
    • Subscription notifications;
    • Features;
    • The frequency of emails: never, each hour, each day, each 3 days, or each week.

  • Are you a member of a conversation in RUMvision, but don't want to receive an email every time a new message is received? Then you can unsubscribe from mails of that conversation through the conversations in RUMvision.