The short answer
Buying signals for developer tools should be ranked as an evidence ladder, not counted as a feed. Repository activity can show that a person interacted with a project. It does not establish their employer, role, problem, budget, authority, or buying timeline. A useful sales signal is an observable event that resolves to the correct entity, remains fresh, is permitted for the intended use, and changes a predefined sales decision.
For most developer-tool motions, a star or watch belongs at the bottom of the ladder. Sustained relevant activity from resolved people at one organization may justify research. First-party product activity combined with a commercial event may justify a rep-reviewed action. The team must define and validate those thresholds locally; no public source provides a universal conversion rate.
This page narrows the broader B2B buying-signals taxonomy to developer tools. It focuses on evidence quality and queue design. The signal-based outreach guide owns the separate question of how an accepted event can become a defensible message.
Build an evidence ladder
Rank signals by the decision they can safely support. “Weak,” “medium,” and “strong” are not properties of the event alone. They describe the evidence available for a named sales play after identity, freshness, relevance, and permission checks.
| Level | Example evidence | Permitted default action | What remains unknown |
|---|---|---|---|
| Weak | One public star, watch, issue, or isolated repository event | Aggregate trend analysis or no action | Employer, role, use case, commercial interest, permission |
| Medium | Sustained relevant activity with a verified person/account match, or multiple resolved participants from one eligible account | Account research or rep review | Active project, budget, authority, purchase timing |
| Strong | Relevant technical activity plus permitted first-party product or commercial evidence | Specific rep-reviewed task or draft | Buyer preference and outcome still remain uncertain |
The “multiple participants” pattern is a hypothesis, not proof. Common Room's vendor-authored article on overlooked buying signals illustrates how community and forum activity can be treated as commercial context. Use such guidance to form a test, not to assign intent automatically.
Write an acceptance contract for every rung:
- Observable event: the exact event and source, without a sales label added.
- Entity rule: how the source user, person, company, and target account resolve.
- Freshness: how long the event can affect a decision.
- Relevance: why the repository, issue, package, or product area maps to the sales play.
- Permission: which uses, roles, exports, and channels are allowed.
- Corroboration: which additional evidence is required to move up a rung.
- Action: no action, research, review, draft, account update, or suppression.
Map public events carefully
GitHub exposes event types and activity endpoints; it does not label them as sales intent. The official webhook event reference documents issue, pull-request, release, star, watch, and many other events. The pages also state the repository or GitHub App permissions required to subscribe to particular events.
The official REST activity reference lists endpoints for public events, repository and organization events, notifications, stargazers, and watchers. Endpoint availability is not a commercial-use conclusion. The team must confirm authentication, permissions, platform terms, privacy obligations, retention, and its own contact policy for the intended workflow.
Preserve the source object before enrichment. At minimum, store the event type, source URL or stable identifier, repository, source actor ID, event time, collection time, visibility, authentication context, and raw-to-normalized transformation. Never replace a GitHub identity with a guessed CRM contact without keeping the original evidence and match confidence.
| Public event | What it establishes | What it does not establish |
|---|---|---|
| Star | A GitHub user starred a repository at an observed time | Evaluation, adoption, employer, budget, or permission to contact |
| Watch | A user started watching or subscribing to a repository | A deployment or commercial project |
| Issue or comment | A user participated in a specific technical thread | Account authority, purchase intent, or fit |
| Pull request | A user contributed to a repository workflow | Production use by the user’s employer |
| Release | A release-related event occurred for a repository | Which external organization needs a paid product |
The largest failure is often identity, not the event. A consultant, student, former employee, bot, hobbyist, customer, and target-account engineer can all produce similar public activity. Keep “unknown” as a valid outcome. The intent-data quality test provides precision, recall, freshness, and identity controls for evaluating a provider or internal pipeline.
Combine product and commercial evidence
Move an account up the ladder only when independent evidence changes the sales interpretation. Useful corroboration can come from permitted first-party product activity, a verified inbound request, an eligible CRM relationship, an open opportunity, an approved trial milestone, a commercial question, or a procurement/security step. Each company must define which events it collects lawfully and which actions they permit.
Do not add weak events until the sum looks strong. Ten stars do not necessarily equal one buying project. Combine evidence only when the items refer to the same resolved entity, fall within compatible freshness windows, and support a shared hypothesis.
A practical record can separate facts from inference:
| Field | Example | Label |
|---|---|---|
| Observed fact | Two resolved engineers opened relevant issues during the last 21 days | Source-backed event |
| First-party fact | The eligible organization has an active trial with accepted usage in the same product area | Permissioned internal evidence |
| Inference | The account may be evaluating a production workflow | Hypothesis, not fact |
| Permitted action | Owner reviews context and decides whether to create a specific draft | Governed next step |
Negative evidence matters too. Suppress or downgrade current customers routed to support, contributors with no resolvable commercial relationship, known students, bots, stale activity, irrelevant repositories, people who changed employers, and records blocked by contact policy. A good detector should be allowed to produce fewer alerts.
Create a governed rep queue
Every queue item should explain why it exists and what the rep may do. A score without evidence forces sellers to reverse-engineer the system. Give them the source events, identity path, freshness, confidence, corroborating evidence, uncertainty, owner, permitted action, and suppression reason.
- Ingest: preserve the source event and collection authority.
- Resolve: match person and account; quarantine ambiguous identities.
- Classify: apply the versioned evidence-ladder rule.
- Suppress: remove policy-ineligible, duplicate, customer-support, and stale cases.
- Route: assign research, review, draft, or no action to a named owner.
- Review: record accept, edit, reject, correction, and reason.
- Reconcile: preserve the final action and CRM state without unsafe overwrite.
Gangly's current repository documentation does not list a native GitHub integration. Do not claim that Gangly collects GitHub events. For its documented supported sources, Gangly can connect signal context to rep-reviewed outreach and later workflow steps; the product signal-detection page describes that narrower boundary. Use the provider-evaluation guide when GitHub or other developer-source collection is a requirement.
Measure the motion
Measure evidence and decisions before pipeline outcomes. Start with a labeled, permissioned set of account-event cases. Include accepted events, negatives, ambiguous identities, customers, bots, consultants, stale events, subsidiaries, job changes, and suppressions. Blind reviewers to the rule or provider where practical.
- Person resolution accuracy = correctly resolved people ÷ people reviewed.
- Account resolution accuracy = correctly resolved accounts ÷ accounts reviewed.
- Signal precision = accepted eligible signals ÷ signals delivered.
- Signal recall = accepted eligible signals found ÷ all labeled eligible signals.
- Freshness pass rate = signals inside their contracted window ÷ signals reviewed.
- Action acceptance = rep-accepted proposed actions ÷ proposed actions.
- Correction burden = review and correction minutes ÷ accepted actions.
- Suppression escapes = ineligible cases reaching an actionable queue; set a hard gate appropriate to policy.
Only after the evidence layer passes should the team compare downstream outcomes against a matched holdout. Preserve account selection, rep, segment, period, action policy, and opportunity definitions. Report counts and uncertainty; do not turn a descriptive difference into a causal claim.
The operating goal is not to detect the most developer activity. It is to make fewer, better-grounded sales decisions while respecting the people and platforms that produced the evidence.