Skip to main content

3rd Party Scripts

Core principles​

Third party scripts concern the additional JS that an application will need to download, parse and execute, in order to work with 3rd party services. This might be error logging, managing cookie consent, experimentation platforms, and tools like HotJar which allow you to see how users interact with your site. This might take the shape of a script tag but the same consideration can be taken with NPM packages which will pull in information and scripts from elsewhere.

tip

The general rule of thumb is the fewer 3rd party scripts that you can get away with, the better. The faster every page load will be, the smaller the surface area for bugs and security issues, less is generally more.

Every time you add a 3rd party script it should be scrutinised:

  • Do I need it?
  • Do I trust where it comes from?
  • Can I lazy load this or will it be render blocking?
  • If it's render blocking, do I have evidence to support it's value? Is the impact to rendering less than the value this script will bring? Are the stakeholders aware of the trade-offs?
  • What holes do I need to cut in the content security policy to get this script to work?
  • Is there away to make this script as small as possible?
  • What other scripts do I have running, will this clash?
  • Will the script be executed as if you'd authored it with access to local scope like session storage, or would it have it's own isolated scope?

Cancer Research has a moral and legal obligation to protect the privacy of our supporters. We are the custodians of information given to us by our supporters and we honour supporter preferences for what they allow us to track. We state in our privacy and cookie policy the tracking options selected for cookies also represents the level of consent that we apply to all tracking technologies even ones that aren't cookie based.

Further reading: https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guide-to-pecr/guidance-on-the-use-of-cookies-and-similar-technologies/how-do-we-comply-with-the-cookie-rules/

Strictly Necessary​

This is always enabled because this holds the information about the supporters' settings, without this category being enabled we either could not honour the settings or the cookie banner would appear on every visit

Performance​

Records number of visitors, user behaviour and site performance

Functional​

This allows personalisation and functionality of the our web apps

Targeting​

Used to measure efficacy of marketing

OneTrust​

OneTrust is the current governance tool which we use to record this information. There are two parts to OneTrust. The first is the user facing cookie banner which users interact with to set their privacy settings.

Implementing this is really straight forward. The core sites team maintain a branded cookie banner script. This can be added to your app with a script tag like this:

<script
  async
  src="https://cdn.cookielaw.org/scripttemplates/otSDKStub.js"
  data-domain-script={COOKIE_DOMAIN_ID}
></script>

The core sites team will help you identify what your domain ID should be.

The second part of OneTrust, is the OneTrust web app itself which can run regular scans of all our domains and lists all the cookies used. It allows an administrator to better label them and categorise all the cookies into the categories mentioned above. This then feeds into our cookies policy page which is then periodically updated with an updated list of used cookies.

https://www.cancerresearchuk.org/terms-and-conditions/cookies-policy

warning

If you know of cookies used by your site, that is not listed on this page, please contact the core sites team.

The OneTrust cookie banner will set a cookie against the https://www.cancerresearchuk.org domain, the name of the cookie would be OptanonConsent and in the middle of the cookie text value you will see something that looks like &groups=snc:1,per:1,fun:1,tar:1

If someone has enabled a category it will be a 1 if they have not it will be 0 or simply missing from the cookie value.

If you are about to load a 3rd party script you will have to understand what category of the script you are about to load and and prevent it from loading if the user has not opted in for that category.

If a script is loaded from The GTM container, it will automatically do this for you. If you are initialising a 3rd party script from inside your application then you might need to do something like this:

/* eslint-disable  @typescript-eslint/ban-ts-comment */
export const canTrackPerformance = () => {
  if (typeof window === "undefined") return false;
  // @ts-ignore assuming OnetrustActiveGroups on window object
  if (!window.OnetrustActiveGroups) return false;
  // @ts-ignore assuming OnetrustActiveGroups on window object
  const activeGroups = window.OnetrustActiveGroups as string;
  return activeGroups.split(",").includes("per");
};
/* eslint-enable */

export const onPerformanceCookieEnabled = (callbacks: (() => void)[]) => {
  if (typeof window === "undefined") return;
  if (canTrackPerformance()) {
    callbacks.forEach((callback) => callback());
  } else {
    window.addEventListener("consent.onetrust", () => {
      if (canTrackPerformance()) {
        callbacks.forEach((callback) => callback());
      }
    });
  }
};

Then for example in an entry point of a React app you might do something like this:

let didInit = false;

useEffect(() => {
  if (!didInit) {
    didInit = true;
    onPerformanceCookieEnabled([initHotJar]);
  }
}, []);

Google Tag Manager (GTM) and the GTM Container​

Google Tag Manager is a tool used to track user session information over time, its main purpose to identify user funnels and their efficacy. You can also send custom events with custom data, such as call-to-action (CTA) button/link labelling. It also has the ability to identify if the user in the session and what any experiment variant they have been bucketed into for something like Optimizely.

The GTM container and its contents are largely opaque to developers and all the scripts inside it are controlled by the GTM team. The container and its contents still honour the settings selected in the OneTrust cookie banner.

In the future if we use a server-side solution then we won't need to load the contents of this container down to the users browser, for now however, if you see any errors or negative impact on the users' sessions please speak to the GTM team.

info

The GTM container when loaded handles all privacy consent and cookie categorisation

Google Analytics (GA)​

This is another analytics tool for analysing site performance and anonymous user session behaviour but the information is a bit more generic than the custom events specified in GTM. Both data from GA and GTM can be combined in reports in looker studio. This tool is automatically loaded by the GMT container.

info

The GTM container loads GA handles all privacy consent and cookie categorisation

Optimizely​

Optimizely is an experimentation platform for identifying the best way to modify applications for better outcomes. Your app will need to speak to the the optimizely service multiple times, once to identify the unique user and what variant of the experiment they should be seeing, and subsequently to send events about the user actions. This provides enough information to identify what variant has the best outcome.

See the frontend experimentation section for more information.

info

Optimizely is categorised as Performance

HotJar​

Hotjar is a tool mostly used for collecting user feedback though surveys and and producing heat maps to show how people interact with your site en mass and where rage clicks happen.

Further reading: https://www.hotjar.com/

info

HotJar is categorised as Performance

UserZoom​

UserZoom is a tool exclusively used by the UX team for live user testing. It collects specific session data about live test sessions. It allows the UX team to follow user actions as perform certain tasks on the site to analyse how people interact the application live, and asking them questions about their experience.

Further reading: https://www.userlytics.com/

info

UserZoom is categorised as Performance

Datadog​

When an error happens on an user's browser, the only way to know about it is to have an error boundary that can capture these errors send them somewhere useful. This is where Datadog comes in. Ideally we want to catch all potential errors, then and using the datadog package send them to our datadog service where we can identify and fix the issue. Uncaught errors will also be sent via the datadog package but generally contain less useful contextual information.

See the frontend logging section for more information

info

Datadog is categorised as Strictly Necessary

Content Security Policy (CSP)​

danger

You must have a CSP set up for your app and you ideally want it to be a restrictive as possible.

Each 3rd party tool will fail to communicate to a 3rd party service unless you allow certain permissions for specific domains and they will usually provide instructions about their requirements.

The GTM team can provide CSP requirements for everything inside the GMT container.

tip

If you are concern about security or privacy please speak to the InfoSec team or the Data Governance team respectively.

Further reading: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP