Part 2: Collecting and modeling first-party intent data for B2B

In our four-part series, 'Under the Hood: Koala's Data Platform,' we're sharing our insights on the key ingredients necessary for a world-class first-party intent solution and strategies to help sales and marketing teams get the most out of their first-party website traffic.

Part 1: Website deanonymization: the definitive technical guide
Part 2: Collecting and modeling first-party intent data for B2B
Part 3: Finding Signal(s) from the noise
Part 4: Incorporating intent into your Rev Ops architecture

In this post, we'll walk you through the technical details of collecting first-party intent data (including a few advanced techniques you may want to consider), the right data model for B2B, and how to join data across your GTM stack.

Collecting data

If you want to track the entire lifecycle of your prospect from the moment they first find out about the product through conversion, you'll need a first-party cookie identifier to identify each logical visitor. In order to do this, you'll need a pixel (or "Javascript SDK") installed on all of the places you want to track first-party intent.

You'll want to ensure that this code is very small – the bigger the code, the more it will impact performance of your website. We've worked hard over the years to slim this code down as much as possible so that we meet the bar for the most performance-obsessed websites in the world. At the time of writing this, Koala's pixel size is ~30kb.

Here is some data you'll likely want to collect:

Auto-capture all page views. It's tedious to go through all of your pages, so you'll likely want to auto-capture all of these. This is fairly straightforward for a traditional website, but note that this requires a little extra work to do if you're using a single-page app architecture.
Auto-capture all form submissions. You'll likely want to capture identity data from form submissions (eg., demo requests). If you do this, be sure to automatically omit any sensitive data (eg., password, secret API keys, and credit cards).
Auto-capture active session time. This one is a bit more advanced, but one of the most important signals for intent scoring is how much active session time has been spent by your prospect. A session that lasted 2 minutes is very different from one that lasted twenty minutes, even if they had the same number of pageviews. Capturing active session time is challenging – you only want to accrue session time when the user is engaged with the page, and importantly you can't have it accrue when the site is open in a background tab. We've fixed countless bugs around time-zone changes, looping videos causing session time to stay "active" when it shouldn't, and the other kinds of weirdness you find when you're accruing session time across millions of pageviews a day. Here's one example of a homepage that was challenging to get session time right for, since the looping video was causing us to think the tab was always active:

Product analytics data

Koala allows optional collection of product analytics data. At a minimum, this should be leveraged for resolving identity of anyone signing up / logging into the platform (see Part 1), but can also be incredibly useful data for sellers to have at their fingertips to understand which end-users are already using the app. This is especially useful in a PLG context so you can get an understanding of who your champions might be, or a POC context where you can see how the POC is trending in terms of usage.

You'll want to consider if any in-product activity is helpful for your business, and if so consider adding it into your intent dataset. Reps will appreciate having all of this engagement and product usage data available on a single pane of glass.

B2B data model

In the first days of Koala, the most critical question we had to answer was: how should we model our data? We were fairly familiar with a standard "product analytics" data model from our time at Segment, which has best-in-class data collection and identity resolution capabilities. As we prototyped in the first few months of Koala, we realized that there was one key thing missing from the classic product analytics data model – a first-class "Account" object.

In our initial prototype a month into the company, we realized we didn't have proper support for Accounts, so we paused and took another month to fix that. At the time (pre-product and pre-PMF!), this felt like an eternity, but because data models are often one-way doors, it felt necessary. We landed with the following data model:

Accounts - accounts are uniquely identified by their domain. This makes sense because every company in the world has a unique domain (their website), and is also similar to how most people reason about their CRMs. As your Rev Ops team will be the first to tell you, there is still further complexity to handle here, since many companies have different domains (we are only two years old and already have koala.live and getkoala.com). Koala handles this by checking a list of domain aliases when joining different data sources together.
Visitors - visitors are uniquely identified by their email. We chose email rather than some kind of user ID because email is used across all tools. If we haven't yet seen an email for a visitor, we give them a unique random identifier that is stored in a first-party cookie. We'll continue to accrue activity on their profile with that identifier until we see an email associated with it. More on how identity resolution works below.

Joining data across tools

Once we had a solid data model, we wanted to ensure that we could join the data across all of your tools. For this, we chose to store our data in Elasticearch, so that we could slice and dice this data. Here's an example of how you can slice-and dice data across multiple data sources (intent data, firmographic enrichment, CRM, and product billing).

Show me all companies who match the following criteria:

with Surging or Heating intent [intent];
with an ICP Fit score of 'A' [firmographic enrichment];
who don't have an active Opportunity [CRM];
who are on our free plan [product billing].

Unlocking reps

One of our larger customers joked that prior to Koala, they had spent an insane amount of data science resources building propensity-to-buy models and then promptly… locking it up in a data warehouses where no sales rep could actually benefit from it. And in fact: the strategy of many Sales tech tools has been to deliver the simplest/narrowest possible sliver of data "X passed a threshold and became an MQL." In talking to hundreds of sales teams, we've seen that having only a thin window into the data leaves them frustrated, unable to act, and generally distrusting the tool.

While it is true that you probably only want to interrupt their daily workflow with a high-intent alert, once you surface something to them, they are going to want to do deep research and need a full analytics tool to support that. As such, we've landed on a companion research app that shows you the complete picture of a prospect:

And the complete picture of an account:

We've found that reps love understanding (1) a complete picture of everyone involved, (2) having as much identity to work with as possible, (3) any relevant UTM data about the initial source of the traffic, and (4) a summary of the most important recent things.

Conclusion

Once you have this down, you'll be able to create dynamic audiences of both accounts and visitors. These audiences are an important primitive in your rev ops stack, as they can be used for marketing use cases (ad retargeting, marketing automation, marketing analytics, etc.) and sales use cases (seeing who is active on your target account list, territory carving, a daily or weekly lead list to work out of, etc.). We'll dive more into what you can do in Part 4.

In this 4-part series, we’re exploring the key ingredients necessary for a world-class first-party intent solution and strategies to help sales and marketing teams get the most out of their first-party website traffic. Go further and explore the next articles in our series here: