Skip to content

First party script delivery

How to serve the tracking script from your own domain, and what that does and does not change.

Why you would do this

A script served from the domain of your own site is a first party request. Some teams prefer that, because a list of allowed domains is a list they control and a request their own server makes.

The script itself is small and loads asynchronously. Serving it from your own domain does not make the events arrive faster, and it does not change what the script collects.

The script

The script is served from a fixed address. The snippet looks like this:

index.htmlhtml
<script async src="https://abackanalytics.com/track.js"
  data-website-id="abk_xxxxxxxxxxxxxxxx"></script>

The script reads the tracking id from the attribute of the script tag, so the snippet is the only thing that has to change when you add a site.

Serving it from your own domain

Fetch the script once and store it. The same file works for every site, because the tracking id is read from the attribute of the script tag, not from the file.

terminalbash
curl https://abackanalytics.com/track.js -o track.js

Serve the file from your own domain and point the snippet at it. The script still posts the events to Aback Analytics, so the data lands in the same place.

index.htmlhtml
<script async src="https://analytics.example.com/track.js"
  data-website-id="abk_xxxxxxxxxxxxxxxx"></script>

What this does not change

This is worth being exact about, because the word proxy is often read as a promise it does not keep.

  • It does not bypass a consent banner. The script still collects what it collects, and you still have to ask the visitor before you load it.
  • It does not change the origin the browser reports when it posts the events. The events are posted to Aback Analytics, so the origin is the origin of your page.
  • It does not change what the script stores in the browser. The pseudonymous identifier still lives in the local storage of the site the script runs on.
  • It does not remove the request to Aback Analytics. The script still has to reach the ingestion endpoint, so a blocker that blocks that domain blocks the events.

A first party delivery is a hosting choice. The privacy behaviour of the product is described on the privacy page, and it does not change because of where the file is served from.

Keeping the copy fresh

Fetch the file again when you deploy, or on a schedule. The script has to stay in step with the server, because the server is what validates the payload and what the ingestion endpoint expects.

A file that is too old still sends events, but a field the server has added will not be understood. Refreshing it is the whole of the maintenance.