Lead Ingestions

This page describes lead ingestions, which is used to describe any bulk import of leads or suppression lists into campaigns, whether via CSV or CRM integrations.

Definition(s)

• Lead Ingestions refer to any bulk import of leads or suppression lists into Campaigns, whether via CSV Uploads, CRM Integrations, Suppressions, and by Caller (aka Fractional Rep)s and Customers both.

Why Lead Ingestions is Useful as a Concept

It's nice to be able to 'tag', or trace a lead added to a campaign, back to the CSV file or source from which a lead was added.

The below view of lead ingestions for a campaign, which can be accessed by Customers at customer.glencoco.com/campaign/leads, shows various Lead Ingestionsinto the campaign over time.

This view is only accessible to a Customer. Customers must create a business workspace at https://customer.glencoco.com or be invited into their company's existing workspace using a non-personal email domain.

How to Read & Analyze Ingestions

Clicking on each lead ingestion row allows Customers to view stats about leads on a per-ingestion basis, which in theory makes it easy to A/B test leads from different data sources, leads of different ICPs, etc.

How we handle multiple lead ingestions with overlapping set of leads

We deduplicate leads based on the lead's email address.

Learn about Deduplication

Our Current "First Ingestion" Attribution

If a lead was ingested for the first time into a campaign via an original ingestion file named 'Original_ingestion.csv', we split out contact and account and tag both the Contacts and Accounts from this ingestion with this original ingestion ID.

If a week later, a customer uploads that same lead (same email address) in a second list upload (let's call this 'Second_Ingestion.csv'), we correctly update all the columns for the contact and account with the latest data (except for email address, since that wouldn't change since that's how we even find the original lead to update the data for.

This is intended and aligns well with Customer needs. If your previous data source sucked and you need to refresh the same person with better phone numbers and you found a better data source, it makes sense that we would update the original lead with newer, better phone number data.

However, we do not change update the contact and account's original ingestion id.

For example, if the original ingestion had:

• First Name: Bob

• Last Name: Dylan

• Email: [email protected]

• Company Name: Songwriter

• Phone: [phone]

• Mobile: Missing

• Ingestion Name: 'Original_Ingestion.csv'

And the second ingestion has better data and has a lead with '[email protected]' as the email, the same lead in our system might now look like:

• First Name: Robert <- changed

• Last Name: Dylan <- changed

• Email: [email protected] (unchanged as it's the matching key)

• Company Name: Songwriter Inc. <- changed

• Phone: [phone] <- changed

• Mobile: [phone] <- changed

• Ingestion Name: 'Original_Ingestion.csv'

Put another way, we do not store Object Relationships of all lead ingestions that had a given contact - we only store information about first lead ingestion is stored on contacts and accounts.

So, uploaded Leadsare able to have their data enriched/updated, but they are mapped to the original ingestion.

Why we decided to take a first ingestion approach, as opposed to a latest ingestion approach, or an 'all ingestion' approach

We're actually not sure. Unfortunately, the original technical PRDs and documentation for our lead ingestion view are sparse.

A big motivation for the documentation you're reading now today is in reaction to this. Our commitment on a go-forward basis is to provide helpful context and transparency to allow you to easily navigate different parts of our product surface area.

Known Issue: How our first ingestion approach of tagging leads to ingestions currently impacts auditability and analysis of lead ingestions

Suppose, over a course of 12 months, leads are consistently imported into the platform for a campaign, one each month.

The first month, there are 2,000 total leads added, and, since this is the first ingestion, 2,000 net new leads are added.

The second month, 2,000 total leads are added, of which 1,000 already existed from the first ingestion (so 1,000 net new leads)

The third month, 2,000 total leads are added, of which 1,000 already existed from either the first or second ingestion

.... and so on and so forth, until month 12:

The final month, 2,000 total leads are added, of which 2,000 already existed from any of the 11 previous ingestions.

Since we're only tracking leads to ingestions on a first ingestion basis, clicking through different ingestions to see performance will not be useful, because the most recent ingestion will show leads 0 available to call, 0/0 for connection rate, 0/0 for qualified meeting rate, and 0/0 for total leads.

Why? Because those stats will "accrue" only appear by clicking on the ingestion row that corresponds to the first ingestion of the lead.

This mean that, to track the performance of the latest batch of leads imported, Customers would need to manually remember, for the 2,000 leads uploaded, all of these leads' first ingestion, and click through each of those ingestions.

How we plan to fix this issue:

We plan to shift towards either an all ingestions <> leads mapping table, which maps all ingestions to leads that were part of the ingestion OR to a latest ingestions <> leads model, which we believe is more useful for analyzing ingestion performance across thousands of leads and multiple ingestions than our current first ingestion model.

For now, we recommend contacting [email protected] where our team can build the appropriate reports to analyze lead performance over time.