Ory Signup Enrichment: Reading Identity Events From an Open-Source Stack

An Ory connection usually means a team that builds its own identity layer

Most signup enrichment advice assumes the customer bought an identity product off the shelf: Auth0, Okta, WorkOS. Ory is different. Teams that adopt Ory Kratos (self-hosted) or the Ory Network (managed) are, by definition, choosing to own their identity schema instead of renting someone else's login screen. That's a self-selecting group, and it skews toward engineering teams who care enough about auth to build around it rather than bolt it on.

When one of those accounts connects your product to their Ory setup, you're not looking at a generic OAuth signup. You're looking at a company that already modeled its own identity traits, already decided what a "user" looks like in their system, and is now extending that model to include your product. The decision happened earlier than the signup did.

That earlier decision is exactly where the useful signal lives, and it's the part most enrichment pipelines skip because they only watch for the login event itself.

What Ory's identity model actually exposes

Ory's architecture splits identity into a few pieces, and each one carries a different kind of account context.

Identity schemas define what fields a user record holds beyond email and password: job title, department, company domain, team ID, whatever the account's engineers decided mattered. If a signup arrives with a populated traits.company or traits.department field, someone on the customer's side already built structured company context before you ever touched the data. That's a gift most identity providers don't hand you for free.

Verifiable addresses and verification state tell you whether the user completed email or phone verification, and when. A batch of unverified identities created in a short window usually means a provisioning script or a migration, not organic signup. A steady trickle of verified identities over weeks looks like real usage.

Sessions and session devices, available through Kratos's session API, show concurrent logins and device fingerprints per identity. Multiple devices tied to one identity within the first day is a normal power user. The same pattern spread across five different identities sharing a company domain, all appearing within an hour of each other, is a team rollout, not five separate trials.

Courier and webhook events fire on identity lifecycle changes: registration, verification, recovery, settings updates. These are the closest thing Ory gives you to a native activity stream, and they're underused because most integrations only wire up the registration webhook and ignore the rest.

Reading the sequence, not just the signup

Treat Ory activity as a short story with a few predictable chapters:

1. Identity schema includes a company or team field, but only one identity exists. Early and quiet. Someone configured the schema to capture company context before inviting anyone else, which usually means they're planning a rollout, not just trying the product solo.
2. A cluster of new identities shares the same domain in traits.company or email domain within a tight window. The rollout started. This is your cue to run teammate discovery immediately rather than waiting for each person to show up as a separate, unconnected signup.
3. Verification completion rate for that cluster crosses roughly 70-80%. The team is actually using the product, not just provisioning accounts to check a box. Below that threshold after a week, something stalled.
4. Recovery or settings-update events spike outside normal patterns. Could be an offboarding wave, could be a password policy change pushed from their side. Either way, it's a cheaper churn signal than waiting for usage to drop.

Most teams only build logic for step 2. Step 1 gives you the longest lead time of any signal in this list, and step 4 catches problems before they show up in your product analytics.

Turning identity traits into teammate discovery

The core enrichment problem with any self-hosted identity stack is confidence: is this new signup from the same company as that other signup, or just a coincidence of similar names. Ory's schema system solves part of this for you, because the company explicitly decided what traits to collect.

A practical approach:

• Pull traits.company, traits.department, or any custom field the schema defines, and use it as a primary match key before falling back to email domain parsing.
• When the schema doesn't include a company field (a lot of early-stage Ory setups don't), fall back to personal email enrichment and domain resolution the same way you would for any unstructured signup.
• Cross-reference session device data against existing identities at the same company to flag people who already have internal tooling access but haven't created a separate account yet. That gap is usually your highest-value teammate discovery target, because they're already inside the account's infrastructure.
• Weight schema-declared company data higher than inferred data in your ICP scoring model. A field the customer's own engineers chose to collect is more reliable than a guess based on a free-mail domain.

A short checklist before you wire this up

• Confirm whether the account runs self-hosted Kratos or the managed Ory Network. The webhook and API surface differs slightly, and self-hosted deployments sometimes run older API versions.
• Check the identity schema definition first. If it has no company or team field, don't build logic that assumes one exists.
• Set a verification-rate threshold per rollout cluster instead of per individual identity. Individual verification is noisy; cohort verification is a usable signal.
• Rate-limit your reaction to recovery events. A single password reset means nothing. A cluster of them inside a day is worth a look.
• Keep this scoring path separate from your default signup flow. An identity record this well-structured deserves different handling than a bare email-and-password signup with no traits at all.

Where this fits with everything else

Most of your signups will never touch an Ory instance at all, and for those you're still doing the baseline work: resolving personal emails, scoring individual fit, running your standard PLG signup enrichment process. The Ory-specific signals above matter for the subset of accounts that have already invested in their own identity layer, and that subset tends to correlate with technical buyers who make rollout decisions as a team rather than one person expensing a trial.

Don't fold Ory's structured signals into the same pipeline you use for loosely-typed OAuth signups. A Kratos identity with a populated traits.company field has already done work your enrichment pipeline usually has to do from scratch, so treat it as a higher-confidence input rather than running it through the same inference steps as a bare Gmail signup.

Groful can plug this into your existing onboarding personalization and product-led sales workflows, so a new identity schema field or a verification spike turns into a specific routing decision instead of sitting unread in a webhook log. If you're also handling lighter managed providers on the same self-serve tier, see how we approach Clerk and Supabase Auth signups, browse the rest of our identity playbooks on the blog, check pricing, or get in touch if you want help mapping Ory's identity events into your scoring and routing.