HG Technographic

When to use

• A workflow needs to know which technologies a company actually runs (vs. which they bought).
• A prompt is about to make a claim that depends on the strength of an install (band, intensity, recency).
• An author is about to inline another copy of the intensity-band cutoffs — stop, reference this skill.

Tools you'll touch

• company_technographic — installed-product signals across the verified HG taxonomy
• company_cloud_spend — cloud-specific install + spend modeling (AWS, Azure, GCP)

What HG actually returns

Each row in company_technographic describes one product install at one company, not a company-product pair count. Fields you'll lean on:

• product — the canonical product name in HG's taxonomy. Match against the catalog before fuzzy-matching from prose; HG's product graph is denser than Wikipedia (e.g., "Salesforce Service Cloud" and "Salesforce Sales Cloud" are separate products).
• intensity — a modeled signal that combines verified install density × number of locations running the product × recency of the last verification. It is not a quality score, an NPS, or a sentiment. A high intensity means HG sees this product running widely + recently across the company; a low intensity means either a sparse install or a stale signal.
• first_verified / last_verified — ISO timestamps. Recency is signal: a last_verified more than 24 months in the past should be flagged as stale even if intensity is high.
• locations — number of distinct geo/business-unit installations.
• category — the HG product category (e.g., "Customer Relationship Management"). Do NOT use NAICS codes here; they're a different taxonomy.

How to read it

Intensity bands (canonical, do not re-derive — see hg-insights-api.md#technographic-intensity):

Band	Range	Reading
High	> 70	Verified install at scale; safe to claim "the company runs X".
Medium	30–70	Real but limited — hedge with "uses" or "deploys in part of the org".
Low	< 30	Sparse install. May be a pilot, a single-team deployment, or stale.

Recency cutoffs:

• last_verified within 12 months → fresh, claim without caveat.
• 12–24 months → recent, mention "as of [verification month]".

• 24 months → stale, do not lead with this signal; pair with a corroborating recent source or downgrade the claim.

max_results semantics: the parameter caps total returned rows, not rows per product. If a query asks for 500 results and HG has 1,200 matching installs, you get the top 500 by intensity. For peer-cohort sweeps, paginate; for "what's the headline stack at one company", max_results=20 ordered by intensity is plenty.

Common pitfalls

1. Treating intensity as quality. It's a strength signal, not a recommendation score. A high-intensity install of an aging tool is still an aging tool.
2. Ignoring last_verified when intensity is high. A stale high-intensity install is the most dangerous one to lead with — it sounds confident in prose and reads as out of date in a customer meeting.
3. Pulling 500 results to "be thorough". Pagination + intensity ordering returns the same actionable signal in a fraction of the credits.
4. Quoting category as if it's a product. "The company runs Customer Relationship Management" reads wrong; surface the named product (Salesforce Sales Cloud, HubSpot CRM, etc.).

Citation rules

Cite company_technographic at the source boundary, not per claim. One citation per table; per-bullet only when bullets reference different products from different verifications.

When mixing technographic with another tool (for example, the intent tool), call out the source for each — readers conflate "uses Snowflake" with "is researching Snowflake" without it.

Reference

• hg-insights-api.md#technographic
• hg-insights-api-v2.md#technographic