Exciting news!Announcing our $4.6M Series Seed. Learn more
Log in


Package Overview
File Explorer

Advanced tools


Package containing tracking logic reused between multiple Schibsted niche sites


Version published
Yearly downloads
increased by175.3%

Weekly downloads



Niche Tracking


This repository contains code we use for tracking. The goal of niche-tracking is to be used in all of our products. Currently it's used by tek-web, godt-web and pent-web.

Local development

Nothing fancy here. First install dependencies clone repository, open terminal and run.

npm i

Next start transpiling the source code:

npm run transpile:watch


Note: order of command execution is important.

In order to make your project available as package locally:

npm link

And in project you need:

npm link @schibsted/niche-tracking

And now you are all good. Your project will now use the local version of niche-tracking instead of the one in node_modules.


After you end working on the package you need to unlink it.

First, in the project where the package was used:

npm unlink --no-save @schibsted/niche-tracking

Second, in the niche-tracking package:

npm unlink

Supported trackers

Currently pulse, google analytics and mbl trackers are implemented.

How to use it and how it works

Package exports Tracker class and all implemented tracker objects. You can import it like this:

import { Tracker, pulse, googleAnalytics, mbl } from '@schibsted/niche-tracking';

Next you need to create tracker instance with proper parameters

const tracker = new Tracker({ pageviewTrackerMappers, eventTrackerMappers, logger, enabled, mutateScript, trackers: [pulse, googleAnalytics, mbl], });

When you have the tracker instance you will have to initialize it with proper config. Calling this method will download all tracking scripts and actually make them work. Don't worry, you can call tracker.pageView and tracker.event methods before calling tracker.initialize as all build in trackers have event queue that will be unloaded after initialization.

tracker.initialize methods takes config with tracker specific options. You can see them here:

Let's discuss Tracker constructor parameters


Optional object containing 4 methods:

  • log
  • info
  • warn
  • error


Array with trackers you want to use. You can import those from package or provide your own. They must be objects with three methods:

  • pageview
  • event
  • initialize

pageViewTrackerMappers, eventTrackerMappers

These are objects with following format:

{ [TYPE]: { [TRACKERNAME]: optionTransormFunction } }


This flag lets you disable the tracking. Please keep in mind that even if you set enabled: false mappers will still be called to keep the behaviour as close to production as it can be.

Where TYPE is unique name of event type you want to track (defined by you), TRACKERNAME is (who would have guessed?) tracker name and optionTransformFunction is function that transforms data from option object to data that specific tracker needs for that event.

For example it could look like this:

const pageViewTrackerMappers = { [SCREENS.SECTION]: { pulse: options => ({ object: { name: window.document.title, id: options.category, type: 'Listing', category: options.category, filters: { query: options.location.search, }, }, }), googleAnalytics: options => ({ page_path: options.location.pathname, }), mbl: options => ({ url: window.location.toString(), title: window.document.title, image: options.image.url, referrer: document.referrer }) } }

Remember out tracker instance? Just to remind you:

const tracker = new Tracker({ pageviewTrackerMappers, eventTrackerMappers, logger, enabled, mutateScript, trackers: [pulse, googleAnalytics, mbl], });

Now each time you call tracker.pageView(SCREENS.SECTION, options) the tracker will create:

  • pulseSpecificOptions,
  • googleAnalyticsSpecificOptions
  • mblSpecificOptions

according to transform functions you provided in pageViewTrackerMappers.

Next it will call pulse.pagewiew(pulseSpecificOptions), googleAnalytics.pageView(googleAnalyticsSpecificOptions), mbl.pagewiew(mblSpecificOptions).

As you can see it enables you to implement most of the tracking in declarative way. All you need is choose which trackers you need and provide proper options mapping.

As a recommendation I suggest providing redux state as options and using selectors in option transorm function.


This function allows for mutating scripts that will be injected in dom. You can for example add css class to them.

mutateScript: script => { script.classList.add('no-prerender'); }


Experiments is a field used for A/B tests tracking. It should be passed during tracker initalization and contain list of all A/B tests that user is part of. For example it could look like this:

const tracker = new Tracker({ pageviewTrackerMappers, eventTrackerMappers, logger, enabled, mutateScript, trackers: [pulse], }); const experiments = [ { id: 'experimentId', // unique identifier of A/B test name: 'Readable explanation of A/B test', variant: 'variant-b' // identifier of a variant which will be served to user }, { id: 'anotherExperimentId', name: 'Readable explanation of another A/B test', variant: 'another-variant-a' }, ]; tracker.initalize({ ...trackersConfig, clientId, experiments, })

In the case of the pulse tracker, this list will be added to every page view and engagement event.


Deployment is done using Travis CI

The new version of the package is deployed by Travis after you push a semver tag (e.g. v1.0.1 to Github). The make the process as smooth as possible we're using release-it package.

To make the release work you need to do the following:

  1. Generate a Github personal token with repo credentials.
  2. Set the token as GITHUB_TOKEN environment variable.
  3. Run npm run release and follow the wizard there (mostly pick the patch/minor/major release type and confirm everything else).

Release-it does the following:

  • makes sure you have your workspace clean and GITHUB_TOKEN set
  • bumps the version in package.json and package-lock.json
  • commits the changes
  • tags the commit with the version number
  • pushes the changes and tag
  • creates a Github Release with the changelog since the last release


This package requires only one polyfill: Promise.

To get more general idea of how tracking works check our team docs



What is @schibsted/niche-tracking?

Package containing tracking logic reused between multiple Schibsted niche sites

Is @schibsted/niche-tracking popular?

The npm package @schibsted/niche-tracking receives a total of 238 weekly downloads. As such, @schibsted/niche-tracking popularity was classified as not popular.

Is @schibsted/niche-tracking well maintained?

We found that @schibsted/niche-tracking demonstrated a healthy version release cadence and project activity. It has 5 open source maintainers collaborating on the project.

Last updated on 04 May 2022


Subscribe to our newsletter

Get open source security insights delivered straight into your inbox. Be the first to learn about new features and product updates.

  • Terms
  • Privacy
  • Security

Made with ⚡️ by Socket Inc