We use LogRocket to monitor the frontend of about.gitlab.com, excluding pages under
/handbook. We also use it to collect analytics about the marketing site.
We followed the LogRocket Quickstart for most of these steps. We installed LogRocket as a node module with
yarn add logrocket, so it's managed in our
In the www-gitlab-com repository, you'll find the entrypoint for our LogRocket installation at
LogRocket, and runs the initialization.
The review apps generated via merge requests in that repository build the site in a "production" environment, so in
source/includes/layout/head.html.haml. That file explicitly tells Middleman to skip calling LogRocket on handbook pages.
In addition to calling the script in the
head, we had to update our Content Security Policy according to the LogRocket troubleshooting around session recording. Safari and Mobile Safari don't yet support the
worker-src directive provided by LogRocket, so we modified the CSP changes according to this StackOverflow post, session recordings work across Safari and Mobile Safari.
We have not yet integrated with the Core Marketing Site, since that project is not yet in production, but the integration will be slightly different there.
We have the ability to integrate with many of our existing tools. Currently, our LogRocket has no additional integrations. Some DRI for marketing operations or another relevant area should determine what tools we want to integrate. We have a variety of options built in to the tooling.
To protect users privacy, we sanitize all user input fields by default, as per the LogRocket configuration for
Marketing Operations or some other DRI should determine how they want to identify users across LogRocket sessions. We can use any data available to us on the client-side through our other integrations, but as a static site, we don't have any backend to integrate with, so there may be gaps in coverage or reliability with identification.