Amplitude Signup Enrichment: Turning Product Analytics Into Account Context

Amplitude knows what users do. It doesn't know who they are.

Amplitude is built to answer behavioral questions: which users hit the "aha" event, where a cohort drops off, whether a feature launch moved retention. It does that well. What it doesn't do on its own is tell you whether the user behind user_id: 8842019 runs infrastructure at a 300-person fintech company or is someone's intern testing a free plan on a Tuesday afternoon.

Most teams patch this with user_properties set at signup: plan tier, signup source, maybe a UTM parameter if marketing remembered to pass one through. None of that answers the question a growth manager actually asks when a retention chart looks off: is this drop coming from low-fit users we shouldn't have activated in the first place, or from good-fit users hitting a real product problem? Without company and ICP context sitting in the same tool as the behavioral data, every Amplitude chart mixes both populations together and neither story is visible.

The fix isn't a new Amplitude feature. It's getting enriched identity attached to the user before the first event lands, so every chart, cohort, and retention curve can be sliced by fit, not just by plan or signup date. Groful resolves the company, scores ICP fit, and finds relevant teammates at signup time; this post covers getting that data into Amplitude specifically. For the enrichment fundamentals, start with the PLG signup enrichment guide.

Why blended cohorts hide the real story

Say your D7 retention is 22%. That number is an average across every signup: personal Gmail accounts kicking the tires, enterprise buyers stuck in a security review, and mid-market teams who are your actual ICP. Blend them and 22% tells you almost nothing about what to fix.

Split the same cohort by ICP fit and a different picture usually shows up. High-fit signups might retain at 41%. Low-fit signups might retain at 9%, dragging the blended number down without reflecting a product problem at all. A team optimizing onboarding against the blended 22% is often optimizing for the wrong population, or worse, changing a flow that already works fine for the users who matter.

This is the same reasoning behind activation cohort analysis and PLG activation scoring: behavioral data and fit data have to sit next to each other before either one is useful on its own.

Getting enriched properties into Amplitude

Amplitude accepts arbitrary user_properties, which is really all enrichment needs. The work is making sure those properties are set once, early, and consistently rather than patched in later by five different scripts.

Set properties at identify, not at every event

Call amplitude.identify() (or the equivalent Identify object in the newer SDKs) right after a signup resolves, and set enriched properties there instead of attaching them to every subsequent event. Amplitude persists identify-time properties across the user's history, so a single call covers every event that follows.

const enrichment = await fetch("https://api.groful.co/v1/enrichment/lookup", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    Authorization: `Bearer ${process.env.GROFUL_API_KEY}`,
  },
  body: JSON.stringify({ externalId: userId, email }),
}).then((res) => res.json());

const identify = new amplitude.Identify();
identify.set("company_domain", enrichment.company?.domain ?? "unknown");
identify.set("company_size_band", enrichment.company?.employeeCountBand ?? "unknown");
identify.set("job_title", enrichment.user?.jobTitle ?? "unknown");
identify.set("icp_fit", enrichment.company?.icpFit ?? "unknown");
identify.set("icp_confidence", enrichment.company?.confidence ?? "low");

amplitude.identify(identify, { user_id: userId });

Fail open here too: if the enrichment call errors or times out, still call identify() with whatever you have, or skip it and let the user come through unenriched rather than blocking analytics tracking on a third-party API.

Backfill existing users once, not per session

If you're adding this to an app with an existing user base, run a one-time batch job that enriches your user table and pushes an Identify call per user through Amplitude's HTTP API or a CSV import, rather than waiting for enrichment to trickle in as those users happen to return. Otherwise your historical cohorts stay blank on fit for months.

Keep the property set small and stable

Six to eight properties is plenty: company domain, size band, industry, ICP fit tier, confidence, job title or seniority, and a routing lane if you use one. Amplitude's user property limits and query performance both degrade once you're pushing forty raw enrichment fields per user. Anything more detailed belongs in your warehouse copy of the enrichment result, joined in for deeper analysis when needed, not as a first-class Amplitude property.

Charts worth building once fit is in Amplitude

Retention by ICP fit tier. The same D7/D30 retention chart you already have, split into high/medium/low/unknown fit as separate lines. This alone usually explains more about a retention dip than any UI change under investigation.

Activation funnel by company size band. If your activation event is "created first project" or similar, compare completion rates across size bands. A funnel that works for 10-person teams and breaks for 200-person teams needs a different onboarding path, not a universal fix.

Feature adoption by seniority. ICs and managers often use a product differently. If a feature is meant to drive expansion, check whether the people using it are the ones with budget authority, using job_title or seniority as the segment.

Time-to-activation by confidence tier. Low-confidence enrichment usually correlates with messier signups (shared inboxes, disposable domains, ambiguous emails). If those users also activate slower, that's a data-quality signal worth investigating before you conclude a product problem exists.

None of these require a new tool. They require the enrichment property already existing on the user record Amplitude sees.

Where this breaks if you skip a step

Setting properties after the first few events. Amplitude applies identify-time properties going forward from when they're set, but early session data captured before enrichment finished won't retroactively carry the tag. Enrich as close to signup as your latency budget allows, and accept that the first handful of events from a brand-new user might be unenriched.

Overwriting properties on every login. Company data doesn't change every session. Re-running enrichment and re-calling identify() on every login burns credits for no benefit. Cache the enrichment result and only refresh it on a schedule (weekly or monthly) or when a real signal, like a new employer domain, shows up.

Treating unknown as low fit. A signup that hasn't finished enriching yet, or that enrichment genuinely can't resolve, is not the same as a signup that resolved to a bad-fit company. Keep those as distinct values in your cohort definitions, or your "low fit" segment will be full of cases that are actually just pending or ambiguous.

Forgetting group properties for account-level views. If multiple users from the same company sign up separately, Amplitude's group analytics (when available on your plan) can roll behavior up to the account level using company_domain as the group key. This is where teammate discovery data pays off twice: once for routing, once for account-level product analytics.

A short rollout plan

Days 1–3: Wire the identify call into your signup flow and verify enriched properties are showing up correctly on a handful of test accounts in Amplitude's user lookup tool before touching real cohorts.

Days 4–7: Backfill existing users with a batch enrichment job, then rebuild your core retention and activation charts as segmented-by-fit versions alongside the originals.

Week 2: Replace the blended charts your team currently checks in standups with the fit-segmented ones, and start referencing size band and seniority splits in onboarding and feature-adoption reviews.

The chart is only as good as the identity behind it

Amplitude is precise about behavior and blind about identity. Enrichment fixes the second half, and once it's in place, every chart you already look at gets more honest without any change to the product itself. Growth managers stop debating whether a retention dip is real or a mix-shift problem, because the segmentation is right there in the tool they already use daily.

Groful is built for growth managers who need that identity resolved before the first product event fires, not weeks later in a CSV export. Review the PLG signup enrichment solution, check pricing, or contact Groful to scope an Amplitude identify integration for your product.