Expansion signals for GTM engineers

Most signals a GTM engineer wires up arrive as a field: a funding amount, a technology detected, a headcount bracket. Expansion doesn’t. There’s no clean “this account is entering a new market” attribute to enrich against — the signal only exists once you build it. That makes it one of the more satisfying things to engineer, and one of the easiest to get wrong.

Expansion is a fusion problem

The raw material is scattered. A new office shows up in local news. Localized pages appear on the account’s site in a language it didn’t support before. Job posts cluster in a city the company had no presence in. A new legal entity gets filed — the kind of formation activity the U.S. Census Bureau tracks in its Business Formation Statistics at national scale. Each of these, alone, is a shrug. Fused on the same account inside the same window, they’re a confident statement that the company is moving somewhere new.

So the build is a composition layer: ingest the weak signals, resolve them to one canonical account, apply a threshold for what counts as expansion, and emit a single event with a confidence score attached. The LinkedIn Economic Graph is a good reminder that hiring patterns — scaling companies adding headcount and new skills faster than larger peers — are a strong input here, but they’re an input. In a clean pipeline, a cluster of new-city reqs feeds the expansion event; it doesn’t fire on its own.

Dedup and freshness are the parts that break

Two failure modes dominate. The first is double-counting: because expansion is many weak signals, and because the same move gets reported across multiple feeds on different days, naive logic scores the account several times and double-fires the sequence. Entity resolution and event-level dedup are non-negotiable — collapse everything onto one account and one underlying move before anything downstream runs.

The second is staleness. Expansion decays quickly; an account that opened a region six months ago has already chosen its stack. McKinsey’s finding that half of corporate growth in the decade to 2019 came from foreign markets means there’s plenty of expansion to catch — but only if the pipeline fires on new evidence rather than re-deriving the same event on every full refresh. Build it as a change-detection stream, not a nightly recompute.

Worth designing in from the start: a confidence score, not a boolean. Because expansion is composed from evidence of varying strength, downstream consumers need to know how sure the signal is, so scoring and routing can branch — auto-fire on high confidence, queue for review on the edge cases. A binary “expanding: true” throws away the exact information the rest of the stack needs to act proportionally, and it’s the first thing you’ll wish you had once the pipeline is live.

Consume the trigger instead of rebuilding it

If you’d rather not stand up the whole fusion layer, that composition is exactly what Trayo does — detecting the move across sources, resolving it to one account and the relevant buyer, and drafting the outreach. Run accounts through the signal generator to see the composed expansion signal directly, and the GTM engineer use case shows where it slots into your workflows. Expansion also composes cleanly with money signals — pairing it with a funding round raises the confidence of both and gives your scoring a corroborated trigger.

The engineers who make expansion useful aren’t the ones with the most sources plugged in. They’re the ones who turn scattered weak evidence into one deduplicated, fresh, confidence-scored event — the kind of trigger the rest of the stack can act on without second-guessing it.