Google OAuth Signup Enrichment: Turning "Sign in with Google" Into Company Context

The button that generates most of your signups gives you more than you're using

Check your signup logs and there's a good chance "Sign in with Google" accounts for the largest single chunk of new users. It's the default OAuth option on most signup screens, it skips password creation entirely, and for anyone already logged into a work Google account, it's a one-click signup. Teams obsess over enriching form-based signups and personal email addresses, then let the biggest OAuth source run through with almost no attention, because it looks like it's already "enough."

It isn't. Google OAuth hands your app a verified email, a name, a profile photo, and a hd (hosted domain) claim when the account belongs to a Google Workspace organization. That's a real signal, not a guess, and most apps throw it away after using it to create a session.

What Google actually gives you at signup

When someone signs up through Google's OAuth flow, the ID token and userinfo response typically include:

• email: the address itself, already verified by Google
• email_verified: a boolean, almost always true for OAuth signups
• name, given_name, family_name
• picture: a profile photo URL
• hd: the Workspace domain, present only when the account is a Google Workspace user, absent for consumer Gmail accounts

That hd field is the one growth teams miss most often. If hd is present and equals acmecorp.com, you know with certainty that the person authenticated through a Workspace account tied to that domain. No inference, no fuzzy matching. If hd is absent, you're looking at a consumer Gmail signup, which is the same personal-email resolution problem you'd face from any other free provider.

That single field splits every Google OAuth signup into two very different enrichment paths before you've made a single API call.

Two paths, two different jobs

Workspace signups: verify and expand, don't guess

A signup with hd: "acmecorp.com" already tells you the company domain. The enrichment job here isn't identity resolution, it's expansion:

1. Resolve the domain to a company profile: size, industry, tech stack, funding stage.
2. Check whether other users from acmecorp.com already exist in your product.
3. Run teammate discovery to see who else at that company might be a fit, especially if this is the first signup from that domain.
4. Score the account against your ICP using firmographic data, not just "email domain matched."

Skip straight to company-level enrichment for these. Running a personal-email resolution waterfall against a Workspace address wastes API calls chasing something the OAuth token already handed you for free.

Consumer Gmail signups: this is where the real work is

No hd claim means you're back to a bare firstname.lastname@gmail.com. This is the exact case personal email enrichment exists for: matching a personal address to a professional identity using search, public profile data, and pattern matching, then confirming the match with enough confidence to act on it.

The mistake here is treating a consumer Gmail signup as a dead end because Google didn't do the identity work for you. It's not dead data. It's a harder resolution problem, and roughly a third to half of B2B SaaS signups fall into exactly this bucket depending on your market. Ignoring it means ignoring a meaningful share of your funnel.

Building the enrichment trigger

The implementation pattern is close to what you'd build for any OAuth provider, with one branch added for the domain check.

1. Capture the right fields at the OAuth callback

Pull email, email_verified, hd, and name from the ID token during your callback handler. Don't wait for a background job to re-fetch this from Google's userinfo endpoint if you already have it in the token; that's an extra round trip for data you're already holding.

2. Branch on hd before doing anything else

if (profile.hd) {
  // Workspace signup: go straight to company + teammate enrichment
} else {
  // Consumer Gmail: needs personal email resolution
}

This branch alone cuts wasted enrichment spend. Teams that skip it often run the same generic enrichment pipeline against every signup regardless of what they already know, which means paying for firmographic lookups on domains they could have confirmed for free and paying for slow resolution attempts they could have fast-pathed.

3. Watch for free and disposable "Workspace-like" domains

Not every domain in the hd field is a real company. Some small teams run Workspace on domains that are really just a side project or a placeholder registered for a single signup. Cross-check the domain against basic firmographic signals (does it resolve to an actual company site, does it have any employee footprint) before treating a Workspace match as automatic high-fit. hd tells you the domain is real and authenticated. It doesn't tell you the company behind it is worth chasing.

4. Don't double-count re-authentication

Google OAuth fires the same flow on login as on signup. Gate enrichment on your own "new user created" event, not on every successful OAuth callback, or you'll re-trigger enrichment (and burn credits) every time an existing user logs back in.

5. Feed both paths into the same scoring model

Whether a user arrived with a confirmed Workspace domain or a resolved Gmail match, they should land in the same ICP scoring pipeline at the end. Keep a confidence field alongside the score so a rep can tell the difference between "we know this for certain" and "we're fairly sure," even though both cases might land in the same routing lane.

Google OAuth enrichment checklist

• hd claim captured and checked on every new signup, not just email.
• Workspace signups (hd present) route to company + teammate enrichment, skipping personal email resolution.
• Consumer Gmail signups (hd absent) route through personal email matching with a confidence score.
• Enrichment triggers on account creation, not on every login.
• Workspace domains get a basic real-company check before being treated as automatic high fit.
• Both paths write into one ICP scoring model with a confidence field attached.
• Teammate discovery runs automatically the first time a new Workspace domain appears.

Why this matters more than it looks like it should

Sign in with Google is often the path of least resistance for a signup form, which means it's also the path most likely to get the least product attention afterward. Teams spend weeks building enrichment logic for form-based signups with company-name fields, then leave the largest OAuth source running on autopilot because the token already "worked." The token doing its job (verifying identity) is a different thing from your product understanding who that identity belongs to.

Splitting on hd costs almost nothing to implement and immediately tells you which of your two hardest signup enrichment problems, company resolution or personal email matching, you're actually looking at. From there it's the same playbook as any other signup source: resolve, score, discover teammates, route by confidence.

Groful handles both branches of this out of the box: confirmed Workspace domains go straight into company enrichment and ICP scoring, consumer Gmail signups run through personal email resolution with confidence scoring attached, and any account that clears your fit bar gets automatic teammate discovery. See how the product-led sales workflow plugs into your existing OAuth callback, compare it against Clearbit if you're weighing options, or get in touch to run a batch of your own Google OAuth signups through it.