How We Use Javascript APIs to Measure Site Usage
Reverb’s marketplace is built for music makers everywhere and our users rely on us for the perfect instrument for their next song and gear to fuel their passions. To make sure we are serving our customers, we like to measure new features and designs to evaluate the impact of those changes. When we change a component on a page, two of the most important things we measure are clicks and impressions.
“Impressions” here means the number of times the component is rendered on the page — it doesn’t necessarily mean that the user has actually seen the component. For example, a component that renders lower down on the page might register as an impression, but we wouldn’t know if a user has actually scrolled down to view it.
In most cases, clicks and impressions are enough to base decisions on, but sometimes we want more precision to understand how users react to new features on the site, so we wanted to know if seeing the modified component affected user behaviors.
Solution
In the past we might have had to rely on custom javascript solutions for this, but luckily the Intersection Observer API has been available for a few years and has quite good browser coverage.
Intersection Observer Basics
The intersection observer allows the developer to track an element and fire a callback when the element intersects with the user’s viewport or another element on screen. This makes it ideal for use in cases such as the following:
- Tracking if an Ad has been shown on the page
- Lazy loading images, or other elements, as they are scrolled into the viewport
- Creating an infinite scroll effect
Here’s a simple example of how we could use the observer to track view events.
First setup the observer:
The above creates an observer that will fire the callback function when an observed element is 50% in the user’s viewport.
Next we need to target the element to observe.
This will track the element myItem on the page, firing the callback when myItem scrolls 50% into the viewport.
Finally let’s implement the callback that will be fired when the target scrolls into view.
Note that the observer can track multiple entries (although in our case, we typically only care about the first one). The object entry has a number of status options, and we use entry.isIntersecting which is true when the element is intersecting the viewport.
Using the Intersection Observer with React Hooks
At Reverb we use React, leaning towards functional components with React hooks. Because of React’s many rendering lifecycles, it makes it a little tricky to integrate the IntersectionObserver, so let’s walk through that.
Finished Example
First let’s look at the finished working code. We’ll break this down later, but for those of you who want to dive right into the code, here it is. Note that it’s been somewhat simplified from what we use in production.
Below is a reusable hook that takes in a callback and fires it when the element comes into the user’s viewport. Crucially, it only fires the first time the user sees the element — if a user scrolls up and down on a page, we only need to count that as a single view.
And here’s a React functional component where we use our observation hook:
Breaking It Down
Ok, since there’s a lot going on there let’s break it down.
The first thing to do is create a new IntersectionObserver. Because this can be considered a side-effect, and because we only want to run this code one time on the first render, React.useEffect is the ideal function to use.
We also need to keep track of the observer between renders, so we’ll use React.useRef. Objects placed into useRef persist for the lifetime of the component, which is exactly what we want. (Note: React hooks are a lengthy subject, so we won’t go into too much detail on them in this post. For more details, the React docs are a great reference.)
Creating the IntersectionObserver
Defining the Callback Function
The callback function is where our tracking code is actually fired. Remember that entries is an array as we can track multiple objects on a page, but for our purposes we just want the first object.
If the entry isIntersecting fire our tracking function doTracking(). (Note: doTracking doesn’t have to be a tracking function specifically, it can be anything you want!).
What is setViewed(true);? For our use case we’re tracking views and only want to fire our doTracking function a single time. So, we need some sort of guard to prevent firing multiple times as a user scrolls up and down the page, or on re-renders.
We’ll use state to track whether or not we’ve already fired the tracking function:
Observing the Object
Finally, we need to observe and un-observe the component we’d like to track.
In simple javascript-land observing an object is easy. Remember from above:
But because we’re in React and want this to be a reusable hook, we instead need to pass a reference of the element we’d like to track. To get this reference we’ll use Callback Refs, which are worth reading more about in the React docs. Put very simply, this allows us to pass a reference of the component we’d like to track into the Intersection Observer.
We use React.useState to setup our callback ref pattern, and attach it to our component like so:
The setRef is a function that gets called by React when “My Component” is rendered. A reference of “My Component” is stored in state in the ref variable, allowing us to reference the component when we observe it:
To call this in React we can use React.useEffect.
Making Sure To Only Track Once
As it is, our tracking event currently fires every time the component comes into the viewport. This means that if a user scrolls up and down the page multiple times, we’d get multiple tracking events. For our purposes we want to make sure to only log the first time the user views it.
Remember at the top we set up a hasViewed state:
In the callback we set hasViewed to true after tracking the view:
We can then check the hasViewed state to prevent double-tracking. To do this we can unobserve the object which will prevent additional views from getting logged.
That’s it! Now that we have a React effect that anyone on the team can use, any element that needs special behavior based on being in the user’s viewport is ready to be hooked up. As Javascript continues to evolve and introduce new APIs, we’ll continue to make use of them to make a better product for our customers.
Interested in solving challenges like this one and making the world more musical? We’re hiring! Visit Reverb Careers to see open positions and learn more about our team, values, and benefits.
