There are 7,713,468,100 people in the world in 2019, around 26.3% of which are under 15 years old. This works out to 2,028,642,110 children (persons under 15 years of age) in the world this year.

Santa doesn’t seem to visit children of every religion, so we’ll generalize and only include Christians and non-religious folks. Collectively that makes up approximately 44.72% of the population. If we assume that all kids take after their parents, then 907,208,751.6 children would appear to be Santa-eligible.

What percentage of those children are good? It’s impossible to know; however, we can work on a few assumptions. One is that Santa Claus functions more on optimism than economics and would likely have prepared for the possibility that every child is a good child in any given year. Thus, he would be prepared to give a toy to every child. Let’s assume it’s been a great year and that all 907,208,751.6 children are getting toys.

That’s a lot of presents, and, as we know, they’re all made by Santa’s elves at his North China Pole workshop. Given that there are 365 days in a year and one of them is Christmas, let’s assume that Santa’s elves collectively have 364 days to create and gift wrap 907,208,752 (rounded up) presents. That works out to 2,492,331.74 presents per day.

Almost two-and-a-half million presents per day is a heavy workload for any workshop. Let’s look at two paradigms that Santa might employ to hit this goal: concurrency, and parallelism.

A sequential process

Suppose that Santa’s workshop is staffed by exactly one, very hard working, very tired elf. The production of one present involves four steps:

1. Cutting wood
2. Assembly and gluing
3. Painting
4. Gift-wrapping

With a single elf, only one step for one present can be happening at any instance in time. If the elf were to produce one present at a time from beginning to end, that process would be executed sequentially. It’s not the most efficient method for producing two-and-a-half million presents per day; for instance, the elf would have to wait around doing nothing while the glue on the present was drying before moving on to the next step.

Concurrency

In order to be more efficient, the elf works on all presents concurrently.

Instead of completing one present at a time, the elf first cuts all the wood for all the toys, one by one. When everything is cut, the elf assembles and glues the toys together, one after the other. This concurrent processing means that the glue from the first toy has time to dry (without needing more attention from the elf) while the remaining toys are glued together. The same goes for painting, one toy at a time, and finally wrapping.

Since one elf can only do one task at a time, a single elf is using the day as efficiently as possible by concurrently producing presents.

Parallelism

Hopefully, Santa’s workshop has more than just one elf. With more elves, more toys can be built simultaneously over the course of a day. This simultaneous work means that the presents are being produced in parallel. Parallel processing carried out by multiple elves means more work happens at the same time.

Elves working in parallel can also employ concurrency. One elf can still tackle only one task at a time, so it’s most efficient to have multiple elves concurrently producing presents.

Of course, if Santa’s workshop has, say, two-and-a-half million elves, each elf would only need to finish a maximum of one present per day. In this case, working sequentially doesn’t detract from the workshop’s efficiency. There would still be 7,668.26 elves left over to fetch coffee and lunch.

Santa Claus, and threading

After all the elves’ hard work is done, it’s up to Santa Claus to deliver the presents – all 907,208,752 of them.

Santa doesn’t need to make a visit to every kid; just to the one household tree. So how many trees does Santa need to visit? Again with broad generalization, we’ll say that the average number of children per household worldwide is 2.45, based on the year’s predicted fertility rates. That makes 370,289,286.4 houses to visit. Let’s round that up to 370,289,287.

How long does Santa have? The lore says one night, which means one earthly rotation, and thus 24 hours. NORAD confirms.

This means Santa must visit 370,289,287 households in 24 hours (86,400 seconds), at a rate of 4,285.75 households per second, never mind the time it takes to put presents under the tree and grab a cookie.

Clearly, Santa doesn’t exist in our dimension. This is especially likely given that, despite being chubby and plump, he fits down a chimney (with a lit fire, while remaining unhurt) carrying a sack of toys containing presents for all the household’s children. We haven’t even considered the fact that his sleigh carries enough toys for every believing boy and girl around the world, and flies.

Does Santa exist outside our rules of physics? How could one entity manage to travel around the world, delivering packages, in under 24 hours at a rate of 4,285.75 households per second, and still have time for milk and cookies and kissing mommy?

One thing is certain: Santa uses the Internet. No other technology has yet enabled packages to travel quite so far and quite so quickly. Even so, attempting to reach upwards of four thousand households per second is no small task, even with the best gigabit internet hookup the North Pole has to offer. How might Santa increase his efficiency?

There’s clearly only one logical conclusion to this mystery: Santa Claus is a multithreaded process.

A single thread

Let’s work outward. Think of a thread as one particular task, or the most granular sequence of instructions that Santa might execute. One thread might execute the task, put present under tree. A thread is a component of a process, in this case, Santa’s process of delivering presents.

If Santa Claus is single-threaded, he, as a process, would only be able to accomplish one task at a time. Since he’s old and a bit forgetful, he probably has a set of instructions for delivering presents, as well as a schedule to abide by. These two things guide Santa’s thread until his process is complete.

Single-threaded Santa Claus might work something like this:

1. Land sleigh at Timmy’s house
2. Get Timmy’s present from sleigh
3. Enter house via chimney
4. Locate Christmas tree
5. Place Timmy’s present under Christmas tree
6. Exit house via chimney
7. Take off in sleigh

Rinse and repeat… another 370,289,286 times.

Multithreading

Multithreaded Santa Claus, by contrast, is the Doctor Manhattan of the North Pole. There’s still only one Santa Claus in the world; however, he has the amazing ability to multiply his consciousness and accomplish multiple instruction sets of tasks simultaneously. These additional task workers, or worker threads, are created and controlled by the main process of Santa delivering presents.

Each worker thread acts independently to complete its instructions. Since they all belong to Santa’s consciousness, they share Santa’s memory and know everything that Santa knows, including what planet they’re running around on, and where to get the presents from.

With this shared knowledge, each thread is able to execute its set of instructions in parallel with the other threads. This multithreaded parallelism makes the one and only Santa Claus as efficient as possible.

If an average present delivery run takes an hour, Santa need only spawn 4,286 worker threads. With each making one delivery trip per hour, Santa will have completed all 370,289,287 trips by the end of the night.

Of course, in theory, Santa could even spawn 370,289,287 worker threads, each flying to one household to deliver presents for all the children in it! That would make Santa’s process extremely efficient, and also explain how he manages to consume all those milk-dunked cookies without getting full. ????

An efficient and merry multithreaded Christmas

Thanks to modern computing, we now finally understand how Santa Claus manages the seemingly-impossible task of delivering toys to good girls and boys the world-over. From my family to yours, I hope you have a wonderful Christmas. Don’t forget to hang up your stockings on the router shelf.

Of course, none of this explains how reindeer manage to fly.

Buddy the Elf waving

To get in the spirit, we’re going to spin up a web app that includes a map that tracks Santa on it!

Edit 12/23: Updated the app to request directly to Santa's route, just in case the original API doesn't work as originally expected.

What are we going to build?

We’re going to work through building a mapping app that tracks Santa’s route and his current location.

To achieve this, we’re going to spin up a premade Gatsby starter that will give us a basic foundation for a map, utilize Google’s unofficial API to grab Santa’s route, and overlay his position and route on top of the map with Leaflet.

Woah, a mapping app?

Ay Caramba

Yup. If you haven’t played with maps before, don’t be discouraged! It's not as bad as you probably think. If you’d rather start with mapping basics, you can read more about how mapping works first.

What do we need before we get started?

For this exercise, I’m going to assume you have node or yarn installed. For each example, I'll use yarn, but use the tool of your choice.

You’ll also want to install Gatsby’s CLI globally which will allow us to use their Starter tools.

To set up Gatsby’s CLI, run the following command:

yarn global add gatsby-cli

After, you should be able to run gatsby -h to see the available commands, which means it’s successfully installed.

Running gatsby -h to verify install

For more info about the Gatsby CLI, you can check out their documentation.

Getting started with our map foundation

Once our command line tools are set up, the first thing we’ll want to do is create a new Gatsby project using a Leaflet starter I put together. It provides us with a basic setup with Leaflet and React Leaflet.

Starting in your project directory, let’s install the project:

gatsby new [directory] https://github.com/colbyfayock/gatsby-starter-leaflet

Make sure to replace [directory] with the location you want to set up your project.

Once you run that command, Gatsby will clone that project without any of the git references and install the packages required to start.

Installing Gatsby Starter Leaflet

To make sure it works, you can now navigate to that directory, spin up your server, and test it in the browser:

cd [directory]
yarn develop

Where you see [directory] above, make sure to use the same path as you did before when setting up the new Gatsby project.

Running Gatsby Starter Leaflet

If all goes as planned, your server should start and you should now be able to see your basic mapping app in your browser!

Gatsby Starter Leaflet in the browser

Cleaning things up

This starter comes with a quick example of how we can interact with the map. We're not going to need this at all for our purposes so we can go ahead and clean things up.

To start, we’re going to open up our index.js file, the homepage file, and get rid of everything inside of the mapEffect function, which leaves us with:

// In src/pages/index.js

async function mapEffect({ leafletElement } = {}) {
  // Get rid of everything in here
}

Now, let’s remove the Marker component nested inside of our Map, so we end up with:

<Map {…mapSettings} />

Now that we’re no longer using that functionality, we can get rid of the variables and references at the top of the file, so you can go ahead and remove:

• useRef
• promiseToFlyTo
• getCurrentLocation
• Marker
• gatsby_astronaut
• ZOOM
• timeToZoom
• timeToOpenPopupAfterZoom
• timeToUpdatePopupAfterZoom
• popupContentHello
• popupContentGatsby
• markerRef

Follow along with the commit.

Finding Santa

Now that we’re in a good place, let’s get our hands dirty and find Santa. To do this, we’re going to use Google’s unofficial, undocumented API. This means that it’s possible this API won’t be available the day after this get’s published, but let’s be optimistic.

Additionally, at the time of writing, it’s still showing last year’s destinations, so what we’re really going to be visualizing here is Santa’s previous year’s route, though the hope is this would reset on the 24th and we’ll all be merry!

Before we get Santa, let’s first add a line back to our mapEffect function:

async function mapEffect({ leafletElement } = {}) {
  if ( !leafletElement ) return;
}

What this will do is prevent the rest of our code from running in the event our map isn't ready yet. The mapEffect function itself, as you can see in the Map component, runs inside of an instance of useEffect passing an argument of a ref to the map, allowing us to run some code after our component renders.

So once we have that line, let’s now fetch Santa’s route inside of our mapEffect function:

async function mapEffect({ leafletElement } = {}) {
  if ( !leafletElement ) return;
  let route, routeJson;
  try {
    route = await fetch('https://firebasestorage.googleapis.com/v0/b/santa-tracker-firebase.appspot.com/o/route%2Fsanta_en.json?alt=media&2018b');
    routeJson = await route.json();
  } catch(e) {
    console.log(`Failed to find Santa!: ${e}`);
  }
  console.log(‘routeJson’, routeJson);
}

Let’s break this down:

• We grab Santa’s route via the API endpoint
• Once we have his route, we grab the response in a JSON format to make it easier to work with
• This is all wrapped in a try/catch so we can safely handle any response errors
• Finally, we just log out our response for now

Santa's route object in the web console

Now we have Santa and his route, which means we can see all the destinations in his route. If you dig in the response a little bit, you can see some fun things like how many presents were delivered to each location and the weather at the time!

Follow along with the commit.

Put a pin in his location

We found Santa! ? Now let’s put him on the map.

For our purposes, we’ll need to find the latitude and longitude of Santa. The problem is, we don’t get this exact value defined anywhere, we just get his destinations.

Since we don’t have his location specified anywhere, we can utilize his last known location where presents were delivered. Add the following after our last snippet inside the mapEffect function:

const { destinations = [] } = routeJson || {};
    const destinationsVisited = destinations.filter(({arrival}) => arrival < Date.now());
    const destinationsWithPresents = destinationsVisited.filter(({presentsDelivered}) => presentsDelivered > 0);
const lastKnownDestination = destinationsWithPresents[destinationsWithPresents.length - 1]

Below our request code, we:

• Destructure routeJson to grab destinations into a constant, adding a fallback to an empty object
• Filter the results to only find the destinations that he's visited, using the arrival time from the route object
• Filter the results to find only the locations with presents
• And finally grab the last item from the array, which shows his last known location

At this point in time, 12/23, we don't actually have any destinations, as Santa is still at the North Pole. At any time, we can test this out to simulate a future date by replaceing Date.now() in destinationsVisited with a future date, such as 1577188980000 which would be around 7pm Eastern on 12/24. With that change, we can see what Santa's route actually looks like!

Handle a missing Santa

Now that it's close to Christmas, Santa will still be at the North Pole, so let's handle the case where we don't have a location.

Above the line where we set lastKnownDestination, let's add:

if ( destinationsWithPresents.length === 0 ) {
  // Create a Leaflet Market instance using Santa's LatLng location
  const center = new L.LatLng( 0, 0 );
  const noSanta = L.marker( center, {
    icon: L.divIcon({
      className: 'icon',
      html: `<div class="icon-santa">?</div>`,
      iconSize: 50
    })
  });
  noSanta.addTo( leafletElement );
  noSanta.bindPopup( `Santa's still at the North Pole!` );
  noSanta.openPopup();
  return;
}

Okay so what are we doing here?

• First, we’re checking if we have any destinations with presents, which here we don't
• We first create a LatLng of the center of the map
• We create a Leaflet marker, using that center, with a custom Icon of Santa
• Next we add that Santa marker to the leafletElement, which is our map
• To show a message, we first bind a popup with a custom message and open it
• Finally we return so the rest of the code doesn’t run, as we don’t have Santa at this point

This was a section added after published to handle the API resetting, but you can still follow along with the code I added in context of the rest of the rest of the code.

Follow along in the code.

Pinning Santa

Edit 12/23: This section was originally written with the previous year's API, but this is still a good example of what you'll expect on the response, so you can follow right along.

And as we can see, since we’re looking at last year’s data, Santa is back home at the North Pole.

Santa's last known location in the web console

With his location, we can pull that apart, set up a Leaflet marker instance, and add our old friend to the map. Add the following after our last snippet inside the mapEffect function:

const santaLocation = new L.LatLng( lastKnownDestination.location.lat, lastKnownDestination.location.lng );

const santaMarker = L.marker( santaLocation, {
  icon: L.divIcon({
    className: ‘icon’,
    html: `<div class=“icon-santa”>?</div>`,
    iconSize: 50
  })
});

santaMarker.addTo(leafletElement);

Here we:

• Create a Leaflet LatLng instance with his location
• Create a Marker instance with our newly created LatLng instance
• Add our new Marker to the map

If we refresh our page, you’ll have to zoom out and pan up a little bit, but we'll see Santa on the map!

Santa on the map

Before we move on, let’s give Santa a little holiday cheer to make him easier to find. Find your application.scss file and toss these styles in:

// In src/assets/stylesheets/application.scss

.icon {

  & > div {

    display: flex;
    justify-content: center;
    align-items: center;
    overflow: hidden;
    border-radius: 100%;
    box-shadow: 0 3px 4px rgba(0,0,0,.4);
    border: none;
    transition: all .2s;

    &:hover {
      box-shadow: 0 4px 8px rgba(0,0,0,.6);
    }

  }

}

.icon-santa {
  width: 50px;
  height: 50px;
  font-size: 3em;
  background: white;
}

This just adds a white circle around him, a little drop shadow, and increases the size a bit to make him a little easier to find on the map.

Santa styled on the map

Follow along with the commit.

Drawing his route

The last thing we’re going to do here is draw a path on the map showing his route so we can follow along.

To get started, let’s update our code and add this last bit after our last snippet in the mapEffect function:

// Create a set of LatLng coordinates that make up Santa's route

const santasRouteLatLngs = destinationsWithPresents.map(destination => {
  const { location } = destination;
  const { lat, lng } = location;
  return new L.LatLng( lat, lng );
});

// Utilize Leaflet's Polyline to add the route to the map

const santasRoute = new L.Polyline( santasRouteLatLngs, {
  weight: 2,
  color: 'green',
  opacity: 1,
  fillColor: 'green',
  fillOpacity: 0.5
});

// Add Santa to the map!

santasRoute.addTo(leafletElement);

What we’re doing:

• Creating an array of Leaflet LatLng instances that make up Santa’s route
• Creating a Leaflet Polyline (a multi-point line) using that routes array
• Make that Polyline green
• Add our Polyline to the map

What we get… is a bunch of squiggly lines!

Santa's route on the map

This is expected. This gets technical really fast, but Leaflet by default can only understand 1 “portion” of the map as it wraps around in our browser. What this realistically means, is instead of drawing a line around a globe, the coordinates think it goes from one side of the world to the other as it hits the International Dateline. This is a bit out of scope for this tutorial, but you can check out Leaflet.Antimeridian to learn more and see if you can implement the solution to it.

Follow along with the commit.

A few quick style tweaks

One last thing! And this is completely optional. Let’s make the map a little bit bigger, set the background color to match our oceans, and zoom out a little bit. So let’s make a few changes:

// In src/pages/index.js

const DEFAULT_ZOOM = 1;

We’re setting our default zoom to 1 instead of 2 to allow the map to be zoomed out a bit.

// In src/assets/stylesheets/pages/_home.scss

.page-home {

  .map,
  .map-base {
    height: 80vh;
  }

}

We’re setting our map to a height of 80vh instead of 50vh to make it take up a little more of our screen.

// In src/assets/stylesheets/components/_map.scss
.map {

  &,
  .map-base {
    background: #acd3de;
  }

}

We’re setting the background color of our map to #acd3de instead of $blue-grey-50 which allows us to match the color of the oceans on our map.

What this achieves is being able to see Santa’s full route and Santa on the first view. Additionally, since the map only covers part of the screen, setting the background color of the map allows us to not have a little bit of a weird cutoff.

Santa's route zoomed out

Follow along with the commit.

Want a challenge?

To take this 1 step further, follow along with both how we added the routes and Santa to the map and try to see if you can add a marker to each destination location to show where all of the stops are. Bonus, add a popup to each one that says how many presents were delivered to that location!

To see the answer with some code organization and how I added the gift markers, check out the final version of the Santa Tracker demo.

Final Santa Tracker demo

While you’re there, you can also see how I utilized Leaflet.Antimeridian to fix our map's route.

What did we learn?

Building basic apps with a map isn’t nearly as bad as we thought! We learned how to fetch some data from an API, grab the data we need, and draw representations of that data on a map.

Next time you want to add a map widget to your landing page, try Leaflet. Share what you create on Twitter! Would love to see what you come up with.

I hope you and your family have a fantastic holiday season!

Happy Holidays from Dunder Mifflin

Want to learn more about maps?

You can check out a few of my other resources to get started:

• Anyone Can Map! Inspiration and an introduction to the world of mapping
• How to create a Coronavirus (COVID-19) Dashboard & Map App in React with Gatsby and Leaflet
• How to set up a custom Mapbox basemap style with React Leaflet and Leaflet Gatsby Starter
• How to Create a Summer Road Trip Mapping App with Gatsby and Leaflet
• How to build a mapping app in React the easy way with Leaflet

Want to read some of my other articles? Check out my blog: https://www.colbyfayock.com/2019/12/create-your-own-santa-tracker-with-gatsby-and-react-leaflet/

Twas the night before Christmas, in a Developer’s place
I had just finished writing, a brand new code base
With VSCode humming I then pulled up Git,
Then I hit up Github with my final commit;

With eyes that were heavy and circles so deep,
I thought to myself, I must have some sleep
With Hactoberfest stickers all over the back,
I closed my laptop, and grabbed a quick snack;

With my head on my pillow, hoping for sleep,
Envisioning my code and rewards I would reap
But my eyes would not shut, I had a slight jitter,
Too much caffeine so I thought I’d check Twitter;

When what to my wondering eyes should appear,
but tweet after tweet, saying my code was inferior,
The recursion is wrong and the code base is sloppy,
No one will use it, it’s not worth a copy;

I thought to myself, I have to debug,
So I jumped out of bed, but slipped on the rug,
Out cold on my floor, but not for too long,
A few moments later, I woke to a song;

As my eyes regained focus, but what did I see,
Good ol’ St. Nick, coming down my chimney,
With a rip on his coat, it was in a slight tatter,
He looked down at me and asked what was the matter

My code was all wrong, I just don’t have the knack
He just laughed a deep laugh as he put down his sack,
Don’t be confused, I may look like a Gramps,
But over the years, I attended code camps;

He opened my laptop, and first installed Node
Who knew that old Santa had learned how to code,
His fingers were flying, his typing was quick,
How will I ever, repay ol’ St. Nick

When he was finished, my code was brand new,
He said I should practice, mistakes were not few,
As he left, I was thinking, I know that he’s right,
So I pulled up a browser and freeCodeCamp’s site

Though I was tired, and incredibly weary
I was soon certified in Front End Libraries,
I looked out the window, and saw a faint light
Merry Christmas to all, I just coded all night!

by Brad Harr | Twitter: @bradsharr

The holidays are here! It’s time to grab some egg nog, kick back by a fire place, and toast to all the coding you crammed into 2016.

But wait! Before you sink into a carbohydrate-induced hibernation, let me tell you about a project that’s taking the North Pole by storm.

Rumor has it that Santa spent his summer break reading up on data and analytics. You didn’t think his global distribution empire ran purely on magic, did you?

Some tech savvy elves are indulging Santa by setting up Google Analytics in time for the big night.

You see, Santa, his elves, and children everywhere have a secret shared website that they all use to register and review wishes. I’m sworn not to reveal the actual URL, so we’ll just call it www.wish.io.

On this site, children can:

1. See the benefits of wish.io
2. Have an opportunity to register as a good kid
3. Choose a present they wish to receive
4. Review their choice
5. Submit their wish

As you can imagine, Santa and the elves can learn a lot from Google Analytics as to how they can further improve wish.io. Here’s how they’re putting it to work.

Setting Up Google Analytics for Santa

To get Santa’s secret page ready for tracking, the elves need a Google Analytics tracking code. This is a Javascript code snippet (also often referred to as ‘pixel’ or ‘tracking snippet’) that you get after signing up for Google Analytics.

You can set up as many as 100 accounts, which can all contain multiple properties. These properties in turn can contain multiple views. This can seem confusing at first (especially if you’re an elf) but it’s not so bad if tackled one step at a time.

The elves will accomplish this in the admin area of Google Analytics. Let’s take a look.

A screenshot of the Admin area of Google Analytics

Account properties describe websites, mobile apps, or other systems, each represented by a tracking code and unique ID — called a UA code. Here you can set up the property “Santa’s wish.io”. If Santa later decides to build subdomains or separate-but-related pages — like Santa’s naughtylist.io — he can set up an additional property here to avoid mixing data about good and naughty children.

You can define your user management for each level, but permissions are inherited per detail (account > property > views).

The elves have to think carefully about who should be able to see and modify what. It only takes one little green user who doesn’t know what they’re doing to mess up the settings and data.

So Santa makes sure that all the elves read the Google Analytics permission guide before they can add users.

Google Analytics offers several views that the elves can use for a variety of purposes.

First, they can apply filters. This is useful because the elves generate a lot of internal traffic that needs removed, so that Santa can instead focus on the session data from children who are visiting the site.

Second, the elves can define goals and segments at the view level, so that each team can access the data that’s most interesting for them. After all, the logistics elves want a different sort of information than the front-end elves.

You can configure much more here, such as automatic reports and custom calculated metrics. But that’s a job for next summer.

Elf Best Practices in Setting Up Views

Next, the elves have to set up three standard views: www wish.io (Master), www wish.io (Test), and www wish.io (Raw).

These three views are essential due to the way Google Analytics operates: it applies filters between the steps of data collection and data processing.

This means that if the elves have a faulty filter, their data will vanish. For this reason, they need to set up a Raw view and never touch it so they have a fallback for emergencies. Every elf knows that the test view is for testing, and the master one is there to work with from day to day.

A screenshot of adding new view with Google Analytics

How the Elves Track Kids

With the backend of Google Analytics in place, the elves add a tracking snippet e of wish.io.

Yes, this is a gross violation of COPPA. But Santa doesn’t care about our laws. Heck, he doesn’t even care about the laws of physics.

They find the tracking code in the property section of the admin panel, then paste it into their website’s layout code.

The elves also take the vital step of ensuring that the script is located just before the </head> closing tag. Usually, developers don’t want any render-blocking scripts here, but this is a special exception. The Google Analytics script is asynchronous, and ultimately the elves want to catch all traffic. They can’t risk missing the information of children who might leave a page before all scripts are loaded.

The bounce rate — which tracks the proportion of visitors who drop out of a page without engaging with any of the content — is an important metric. It might show the QA and front-end elves that something is wrong with the page. It also helps the marketing elves check whether a certain activity was poorly targeted.

A screenshot of the Google Analytics tracking code section

Navigating Google Analytics

With tracking integrated, the elves were set to look at the initial data. Even though Google Analytics starts collecting real time data immediately, the elves decide to give it at least 24 hours so it can gather a meaningful amount of data.

Now the elves have to get familiar with Google Analytics, its various menus and data it displays.

Screenshot: Google Analytics Reporting Overview (Wish.io renamed Demo Account)

The left navigation menu shows the main sections the elves can use to look at a website’s data. The most important elements are Audience, Acquisition, Behavior, and Conversions.

This menu is also home to the Realtime and Intelligence Events view. Intelligence Events will cease to exist in Google Analytics soon, so Santa and the elves decided not to bother with it. The Realtime view is nice to show on flat-screens in Wish Operations HQ and boost moral among the elves. But meaningful decisions demand a longer-term view.

So the elves head back to Google Analytics main sections to check out what other tools it offers.

Audience Overview

When the elves open a new property’s view, they see the Audience Overview by default. Fortunately, the overview pages are all similar, making the learning process a little smoother for elf and human alike.

In the area marked “1” (above), the elves get the most important information about their audience. How many users came to their page, how long they spent on it, and pages they saw per session etc. All this is nicely presented in graphs, so the elves can spot peaks, lows, and overall trends.

Looking at annotation (2), you’ll see that it’s possible to segment these overviews. This is true for all the main sections in Analytics. Now Santa can see whether kids browsing wish.io on the mobile phones they received last year behave differently to other users. The creation of segments is an advanced topic, but can be very rewarding. Segments can unearth context from the data which is otherwise only presented in rough averages. Note: You can use Google’s in-depth guide on segments or check the Gallery to import popular community-made segments.

Below the summary values (3), the elves have quick access to more detailed information each category offers. For example, they can see more demographics by country, or the technical context of users.

Even more detailed insights are available in the sub-categories of the left navigation bar (4).

One aspect of the detailed audience data added fuel to an already hot debate the elves were having over summer: the big question of which version of Internet Explorer wish.io should be backwards compatible with.

You can no doubt imagine how heated that became. Thankfully, Google Analytics has replaced the bickering with data driven decisions. Just use the left navigation and check out: Audience > Technology > Browser/OS and click on “Internet Explorer” for version details.

Screenshot: Internet Explorer Sessions and Visitors per Browser Version

Luckily, Google Analytics records details of a browser’s specific version. Santa and the elves are pleased that 95% of Internet Explorer visitors use version 11. They also assuming that the good kids (who are the main audience for wish.io, of course) are diligent enough to either update Internet Explorer regularly, or to just use a better browser. Of course, the browser share for visitors to the upcoming naughtylist.io site will need to be evaluated separately.

There are lots of more great things the elves can learn here. For example, Google can show the kids’ Gender and Interest data (activated in the property settings under the admin panel — make sure you comply with your local laws, unlike Santa). It also allows them to delve much deeper into acquisition data and benchmark audience behavior based on the different channels visitors arrived from.

Acquisition

To learn more about where visitors came from to access wish.io, Santa can look at the Acquisition Overview.

Screenshot: Acquisition View showing visitors by traffic source

This view focuses on sources of traffic.

Google defines nine main channels in which it aggregates these sources:

Direct: Usually people typing the URL or using a bookmark.

Organic Search: People using Google or Bing, and clicking an organic search result link.

Referral: Someone following a link on another website or blog.

Social: Visitors originating from sites listed as social (click the ‘Social’ link to see the list).

Email: All visits coming straight from emails.

Paid Search: People accessing pages via paid links on Google and partner sites.

Display: People that clicked paid advertising banners.

Affiliates: Traffic received from affiliate partners that promote wish.io

Others: A summary of advertising traffic classed as “special.” For example, traffic bought on a cost per action rate.

It’s important to understand that these groupings are the result of a set of default rules stating which medium counts for which traffic group.

The elves can fabricate links for social or advertising purposes — so-called UTM links — which are also summed up in these groups. This way they can judge how successful an ad or blog post was.

For convenience, they use Google’s Link Builder tool. To prevent false counting, they need to be aware of the grouping rules and set ‘utm_medium’ correctly.

Once everything is up and running, the elves can discover lots of interesting details about their channels. They can see which social channels contributed most to wish.io, or which campaigns were most successful. They can even optimize their AdWords’ investments and see which landing pages kids usually arrive on from various sources.

The next logical step for Santa is to gain — and act upon — a deeper understanding of exactly how visitors to his sites behave.

Tracking kids’ behavior on wish.io

For Santa and his elves, it’s always been hard to keep up with the many millions of different wishes kids might come up with. So it’s important for them to understand trends, popular choices, evergreens, and also potential errors across their millions of pages.

Screenshot: Behavior View showing visitors by page

Each elf department has its own information that is of interest.

The front-end and QA elves should always keep a close eye on bounce rates, average time on page, and the speed score of their most important pages.

Every front-end elf hates the lengthy SEO meetings triggered by wish.io’s loading times getting out of hand. So it’s helpful for them to explore the Site Speed subcategory. Google delivers great insights by browser, country, and page — as well as suggestions on how to improve.

UX elves can get an insight into priority pages in the Behavior section. They can also look at the flow of where people enter Santa’s page, their journey, and where they exit.

But the most exciting topic for them is building content experiments. Basically, they can ask the front-end elves to build alternative versions of the same page, then automatically test these versions against measurable objectives.

For example, it might be of interest to find a page variant where kids stay longer or submit wishes at a better rate. They can set up initial experiments with the analytics tool, which has a simple guide. For advanced use cases, elves can carry out content experiments via the well-documented analytics.js API.

Finally, the Behavior tab also offers event tracking, which the marketing elves love. Events can be sent back to Google Analytics whenever kids initiate an important action that doesn’t trigger a new pageview.

For example, when kids click download buttons, submit their “I have been a good kid” forms, amend a wish, and more. Events are straightforward function calls to the analytics API. Elves add them to their Javascript event listeners and callbacks that control the interactivity of their page. All of this is described over at Google’s event tracking guide.

Marketing elves love event tracking because it puts them in a better position to configure the all-important Conversions element of Google Analytics.

Conversions

Setting up the Conversion section in the admin panel took some effort from Santa and his team, but it was worth it. Conversions will help the elves to understand the “business” effects of all formerly looked at insights. This closes the loop between having a lot of data and understanding how it leads to the ultimate goal: happy kids.

Screenshot: Conversions showing goal completion by location

Goals are not set by default in Google Analytics. Users need to define them in the admin panel. Goals are defined by the underlying type of interaction. This could be either the viewing of a certain page (e.g. thankyou.html), a behavior (minimum duration on site, amount of pages per session), or when an event is recorded. You can even define a series of destinations to show as a single goal.

This is important when you want to track how many children have gone through a whole conversion “funnel.” For example, they enter the registered kids’ area, browse through the wish options, and successfully submit a wish.

With this funnel goal tracked, the visualization shows how children go through every step. It also reveals to what extent (and when) they drop out, and where they go from there.

It’s important to note that goals should be defined in a way that they don’t overlap each other. If one event generates the counting of two goals, your conversion rates can be too high.

In addition to using Goals, it’s possible to wire the entire Santa ecommerce system into Google Analytics. But that’s a job for the new year. Once that deep integration is up and running though, Santa & Co. will gain insights down to a per-wish “order” level, and will even be able to track wish returns.

Another useful Google Analytics view was the Multi Channel Funnels sub-category. Before Google Analytics, the marketing elves often argued over budget allocation, and who contributed the most overall wishes submitted.

The brand advertising elves complained that their work not only impacted direct traffic, but search and social as well. They figured some children initially came via their social media posts, but returned later to submit wishes by typing the wish.io URL.

So why should the last elf involved take all the credit? They shouldn’t. Which is why every marketing meeting in the North Pole now includes a look at the Assisted Conversions and Top Conversion Paths. Here the elves can see not only their direct conversion value, but also the value of conversions they helped to close.

Screenshot: Assisted Conversions per traffic source

A job well done

Thanks to his Google Analytics project, Santa has dubbed 2016 as “the year of data driven decisions.” He’s happy his elves have turned once-heated discussions into data competitions and experiments.

From now on, he’ll be using the power of data to encourage his team’s scientific spirit — and to find ever-optimized processes for boosting happiness.

Now all that remains is for me to wish you and your loved ones’ happy holidays. I hope that this little tale from the North Pole has inspired you to make your 2017 even more successful, and data driven.

Now, let’s all slip into our ugly holiday sweaters and embrace the holiday spirit.

Special Thanks to Craig Rennie of Draft Punk and Quincy at Free Code Camp for all their editing efforts. May your holidays be extra happy!

Disclaimer: This story is written in a holiday theme for entertainment purposes only. Despite the above report about Santa, elves, and children it is important to note that Google Analytics doesn’t track or share audience information of anyone under 18.

All data and images are courtesy of Google. The data shown here is available for every analytics account via accessing the Google Analytics Demo Account