Firebase Authentication Signup Enrichment: A Playbook for PLG Teams

Firebase gives you a user. It doesn't tell you who they are

Firebase Authentication is the default choice for a huge share of indie products, mobile apps, and early-stage SaaS tools, and for good reason. Email/password, Google sign-in, Apple sign-in, phone auth, anonymous sessions: it's all handled, it's cheap, and it ships fast. A team can go from nothing to a working login flow in an afternoon.

What Firebase does not give you is business context. A new row in the Authentication console tells you a uid exists, an email came from Google or a password form, and a session started. It says nothing about what company this person works at, whether they're a fit for your product, or what should happen next in your onboarding or sales process.

That gap matters more for Firebase apps than for most, because Firebase's easiest signup path ("Continue with Google") pulls a personal Gmail address by default unless someone deliberately builds domain restrictions into an enterprise flow. A solo developer testing your API, a product manager evaluating tools for her team, and a student poking around on a Saturday can all show up in your users collection looking identical: a name, a Gmail address, and a timestamp.

Where enrichment fits into a Firebase auth flow

Firebase gives you a few real trigger points, and the one you pick changes what's practical to build.

The onCreate Auth trigger (a Cloud Function bound to user creation) fires once when the account is first created, which maps cleanly to "a new user exists." This is the right place to kick off enrichment. Don't attach enrichment logic to sign-in events. Those fire on every session, and repeated enrichment calls for the same person will burn through your credits for no new information.

Blocking Functions (beforeCreate and beforeSignIn) run synchronously before the account is finalized or before a token is issued. They're built for validation, not enrichment: rejecting a disposable email domain, or requiring email verification before allowing sign-in. Resist the temptation to run full company resolution inside a blocking function. These have tight execution limits, and a slow third-party lookup will delay every signup, not just the ones worth investigating.

A queued background job is where the actual enrichment work should happen. Have the onCreate trigger publish a lightweight event (uid, email, provider, creation timestamp) to Cloud Tasks or Pub/Sub, then let a worker call your enrichment service, write the result to Firestore, and update custom claims or a user profile document. This keeps the auth trigger fast and gives enrichment room to do real work: resolving a personal email, searching for teammates, scoring ICP fit.

What to capture from the Firebase user object

Firebase's UserRecord carries more than most teams use. Before reaching for a third-party enrichment tool, pull what's already there:

• uid and email, plus emailVerified. A Google or Apple sign-in email is verified by definition; a password signup may not be.
• providerData, an array showing every linked provider (password, google.com, apple.com, facebook.com). A google.com entry with a company-owned Workspace domain is a much stronger signal than a bare Gmail address.
• metadata.creationTime and metadata.lastSignInTime, useful for spotting accounts created long ago that just became active, a common pattern for invited teammates.
• displayName and photoURL, when populated by an OAuth provider, give a name to work with before any enrichment call runs.

None of this replaces enrichment. It narrows the problem. A Google Workspace domain that matches a real company is close to free to resolve. A personal Gmail or a password-based signup with no other signal is the case that needs real personal email enrichment, matching the address to a professional identity with actual evidence rather than a guess.

A signup enrichment playbook for Firebase apps

1. Split signups by provider before doing anything else

Route Google Workspace and Apple Business Manager domains to a fast, low-cost firmographic lookup by domain. Route personal-provider and password signups, the majority of Firebase apps, to the harder resolution path. Treating every signup the same wastes budget on the easy cases and under-resolves the ones that actually need work.

2. Keep the Cloud Function thin

The onCreate trigger should do one thing: capture the event and hand it off. Cloud Functions triggered from Auth events have execution limits, and cold starts add latency you don't want stacking on top of a slow enrichment call. Publish the event, return, and let a worker do the resolution asynchronously.

3. Write enrichment results to Firestore, not just custom claims

Custom claims are useful for gating client-side behavior, unlocking a feature once a user is confirmed to be on a paid team, for instance, but they're capped in size and require a token refresh to take effect on the client. Keep the full enrichment payload (resolved company, role, confidence, ICP score, teammate signals) in a Firestore document keyed by uid, and only mirror the one or two fields your app actually reads at runtime into custom claims.

4. Score fit and confidence as separate numbers

A resolved company and a good-fit company are different questions. Confidence describes how sure you are about the match. Fit describes how close that company is to your ICP. A high-confidence match to a five-person agency and a high-confidence match to a 300-person logistics company should not trigger the same routing rule just because both were "resolved."

5. Check for teammates once a company clears your bar

If a Firebase signup resolves to an account above your fit threshold, look for other users in your users collection already tied to that domain. Firebase apps often see a single early adopter sign up months before the rest of their team follows, and teammate discovery is how you catch the second and third signup as an expansion signal instead of three unrelated free-tier accounts.

6. Route on at least three lanes

High-confidence, high-fit signups go to sales-assist or a direct founder note. Medium-confidence matches sit in a review queue rather than triggering automated outreach. A rep emailing the wrong "Head of Product" costs more trust than a delayed follow-up. Low-confidence or low-fit signups stay in self-serve, with enrichment status logged so the record can be revisited if the person invites a teammate or upgrades later.

A concrete example

A B2B analytics tool built on Firebase sees a signup from jamie@gmail.com via Google sign-in, no company domain, no other signal at creation time. Two weeks later, the same uid connects a data source, invites a second user, and hits a usage limit that triggers an upgrade prompt. None of those events change the original enrichment record on their own, but together they're exactly the kind of behavioral signal that should upgrade a "low confidence, monitor" record to "high urgency, notify sales," even though the identity resolution itself never got more certain. Confidence and urgency move on different clocks, and a routing system that only checks confidence will miss this account for weeks.

Firebase enrichment checklist

• Enrichment triggers on onCreate, not on every sign-in.
• The Auth-triggered Cloud Function stays fast; heavier resolution runs in a queued worker.
• Google Workspace and Apple Business signups get a cheap domain lookup; personal-provider and password signups go through full resolution.
• Enrichment results live in Firestore, with only necessary fields mirrored to custom claims.
• Confidence and ICP fit are stored and reviewed as separate values.
• Teammate discovery runs automatically once an account clears your fit threshold.
• Routing has at least three lanes: sales-assist, review queue, self-serve.
• Behavioral events (invites, usage limits, upgrades) can raise urgency without waiting for a re-resolved identity.

Metrics to track

Resolution rate on personal-provider and password signups specifically. Blending them with Workspace signups, which were never hard to resolve, hides whether the real problem is actually solved. Time from onCreate to a usable enrichment result in Firestore. Conversion rate from high-confidence, high-fit signups to a sales conversation or paid upgrade. And the metric most teams skip: how often a "resolved" match turns out wrong once someone checks it manually. If that number climbs, tighten the confidence threshold before adding another data source.

Where this leaves Firebase teams

Firebase will keep doing what it does well: fast, reliable authentication with almost no setup cost. Enrichment is a layer you build alongside it, not instead of it, turning a bare uid and an email into a company, a role, and a fit score your team can act on before the signup goes cold.

Groful runs this as a background workflow built for exactly this handoff: resolve the Firebase signup, including the personal Gmail accounts most tools ignore, discover teammates already inside the account, score everything against your ICP, and push results to your stack through API and webhook integrations. See pricing, read how the approach compares on Groful vs. Clearbit, or get in touch to run a batch of your own Firebase users through it before wiring anything into production.