Veyo Technology: Using Angular Environments to Configure Multiple Segment Sources

March 1, 2018

Using Angular Environments to Configure Multiple Segment Sources

NOTE: This is part 2 of a series on tracking analytic events in Angular projects using Segment. You can find the first part on the Veyo Tech Blog. The code will be referenced in this article

Although code snippets are included in this article, you can find the full example application on GitHub.

Segment’s default setup provides you with a stupid-simple flow to get user events into your analysis tools. This is great for a simple production app where you have a single stream of data, such as a static sign up form which shows you how users interact with the fields you’ve deemed as important for your business. Unfortunately, the real world requires a higher level of interactions than a single stream of data can provide.

This is where Segment’s multiple sources feature comes to the rescue. A complex application will generate different types of analytic data – think UX events, error logging, query status logs, A/B tests, etc. You may use different services to generate data, which Segment views as a new source.

You also want to make sure that your development and test environments aren’t polluting your production data. Maybe it’s important to separate your data between internal and external users, or regions; again, individual sources give you the power to easily organize these use cases.

AngularCLI Environment Config

Luckily, AngularCLI is perfectly setup to configure multiple Segment sources through through its environment configuration.

An AngularCLI project has a directory for setting  environment specific variables. You tell it which environment to use by passing the `env` property, such as `ng serve –env=test` or `ng build –env=test`. However, before you can pass in the specific variable, you need to tell AngularCLI that they exist:

  1. Create a new environment file. For this example, let’s create an analytics environment:
touch src/app/environments/

We’re going to leave this file blank for now.

  1. Add the environment to our cli config

In `/.angular-cli.json`, add a new line to the `environments` list:

"environments": {
"analytics": "environments/",
"dev": "environments/environment.ts",
"prod": "environments/"
  1. Now that we have multiple environments, it’s important that our environment variables are strongly typed. If you don’t have one already, you’llneed to make an environment interface:
touch src/app/environments/environment.model.ts

This file will export our interface. We don’t have much right now, but we do have the `production` variable, so we can model that:

export interface Environment {
production: boolean;
  1. The other environment configurations need to use the interface:

import { Environment } from './environment.model'

export const environment: Environment = {
production: false

import { Environment } from './environment.model'

export const environment: Environment = {
production: true

  1. Now we can use the environment in any file by importing the interface and environment object:
import { Environment } from '../environments/environment.model.ts'
import { environment } from '../environments/environment'


// Simply grab the 'production' property
if (!environment.production) {
console.log('This is a development build')

By importing the interface, the properties of the environment object will be highlighted for us in certain IDEs and text editors. We’ll also be able to see if we’re trying to access properties that don’t exist.

Loading the Unique Source

Now that our project is configured to use environments, let’s manipulate the bootstrap process to load our Segment source.

In the previous article, I advised you to include the Segment snippet and load the service in your `index.html` file. I need to be honest: I mislead you. By keeping this code in your index, it’ll be hard-coded to a single source. We need to pull the analytics.load() and .page() methods out of the hardcoded template file, and into a class that only runs after Angular has been bootstrapped.

I prefer to do this in main.ts:

// Create a new window interface so analytics can be set
interface MyWindow extends Window {
 analytics: any;


// Bootstrap analytics
const mywindow = window

// If the Segment library has been successfully included, start tracking things
if ( {

 // Now we can trigger events, such as:

The Segment script adds an “analytics” method to the global `window` object that exposes its functionality. Similar to what we did for the AngularCLI environment config, we have to tell typescript about this. Unfortunately, Segment hasn’t provided the JS community with a TypeScript definition of their API, so here we’re using the dreaded `any`.

Also notice how we’re passing our Segment source key to the `load()` method. Now that it’s configured, let’s actually add our key by updating the environment interface and analytics environment:

export interface Environment {
production: boolean;
SegmentSourceKey?: string;

import { Environment } from './environment.model'

export const environment: Environment = {
production: false;
SegmentSourceKey: '...your analytics key goes here...';

Now, when you run the project with the analytics environment, you will see that the Segment library is requested after the app loads. You can use your true Segment source key in the production environment.  If you don’t want to track analytics (such as in the dev environment), just leave out the property. A non-fatal 404 will be triggered when Segment tries to load an invalid source key and other segment events won’t be triggered.

– AJ Zane, Front End Engineer at Veyo

Part 3 in our series can be found here: Connecting Segment to Google Analytics