Use PostHog to enrich the signups who show intent

Enrich a signup after the person takes a meaningful product action, then buy only the missing information needed to decide whether the account deserves attention. PostHog supplies the activity signal. A small worker applies your rules, checks fit with Jev when needed, and calls an enrichment service through Vaaya. The output is a daily list with a reason each account appears.

A signup alone gives you little context. Someone who has made several successful calls has used the product. Someone who opened the top-up page has reached a different stage. Those observations deserve different follow-up, and neither proves that the person wants a sales call.

Define the trigger before choosing a provider

For a developer tool, start with three candidate events: the third successful tool call, a visit to the top-up page, or API key creation. Require a company email for this particular account-research workflow. People using personal addresses should retain normal product access; they stay outside this rule.

Emit the third-call milestone from your backend, where you can count completed calls consistently. A webhook receiving one event cannot safely infer an account's lifetime usage from that payload alone. Map your actual event names to these milestones and exclude staff, tests, and known automation.

PostHog's webhook destination can forward event data to your backend and apply event filters. Configure a minimal payload containing an opaque account ID, event ID, trigger, and timestamp. Resolve the company domain inside your worker instead of broadcasting the full signup record. PostHog webhook documentation.

Reserve a unique account-and-rule key before doing paid work. Three qualifying events from one person, or several people at one company, should not accidentally buy the same company record several times. Give the cache an expiry date so a later change in company size can be reconsidered.

Check fit using what you already know

Apply deterministic exclusions first. A missing domain, an existing fresh result, or an exhausted daily budget should stop the job without a model call.

Then give Jev the evidence already available: the observed trigger, an explicitly supplied use case, and any company information your product legitimately holds. Ask it to choose enrich, skip, or review against written criteria. For example, an integration developer with an unclear company match belongs in review; the model should not fill that gap by inventing an employer.

Vaaya's current Jev adapter uses openrouter/decisions for typed decisions. Ask consult for the current schema and quote before wiring the call. Keep budget enforcement in code, and validate the returned choice before it selects a branch. The gated spending workflow shows how to carry that decision through later research and outreach steps. Vaaya documents discovery and execution in its tool reference.

For accepted accounts, request company name, domain match, headcount range, and a source date. Add a role lookup only when that information changes the next action and you have a suitable identifier. Start with the domain; don't buy phone numbers or personal emails to populate unused columns. Select a provider through the current data catalog, because coverage, required inputs, and prices differ.

Store a missing value as missing. A stale headcount estimate or a same-name company can make a tidy row misleading.

Compare the full costs

Consider a fictional planning example with 1,000 signups. Suppose 5% pass the behavior and company-email filter, and an enrichment costs an assumed $0.20. These are invented inputs for arithmetic, not Vaaya results or provider quotes.

Enriching every signup would cost $200. Enriching the 50 qualifying accounts would cost $10 before the gate, hosting, and any other paid work. If the fit check costs an assumed $0.001 for each of those 50 accounts, the combined call cost becomes $10.05.

The general comparison is:

all-signup cost = signups × enrichment price
triggered cost = eligible accounts × gate cost
               + accepted accounts × enrichment price
               + other workflow costs

Use accrued usage for metered model calls. A zero immediately settled charge can coexist with billable usage that settles later. Count each expense once, and reconcile the weekly total against receipts rather than multiplying every call by a remembered catalog price.

Lower spending alone does not establish a better rule. Review a small, permitted sample of excluded accounts for missed opportunities. Track unresolved company matches and useful records, so a cheap workflow that returns poor data is visible.

Make the daily list explain itself

Save a PostHog insight for the qualifying events, with an explicit date range and account definition. Keep an internal run record containing the insight URL, rule version, accepted and skipped counts, and receipt references. PostHog supports saved insights that can be added to dashboards. Creating insights.

The daily Slack or email digest should contain company, observed event, verified enrichment fields, source dates, and a proposed next step. Write “created an API key” when that is the evidence. Avoid replacing it with “ready to buy.” Restrict delivery to the team responsible for the workflow.

Set a retention period for enriched records, restrict access, and provide a way to disable enrichment for an account or the whole pipeline. Delete downstream copies when your retention or deletion process requires it. Run a dry pass first that produces only eligibility decisions, then inspect those decisions before enabling paid lookups.

Questions

Which product events should trigger lead enrichment?

Start with a small set of events that matter to your product, such as a third successful tool call, a top-up page visit, or API key creation. Deduplicate them at account level before buying data.

Does a company email prove purchase intent?

No. It can help identify an account, but activity and an email domain do not establish a buying decision. Keep observed behavior separate from inferred fit.

Does this article report a live enrichment experiment?

No. It describes an implementation and uses explicitly hypothetical cost arithmetic. No production accounts were enriched or contacted for this article.