HG Technographic

When to use

• A workflow needs to know which products a company actually runs.
• A prompt is about to make a claim that depends on the strength or recency of an install.
• An author is about to inline intensity cutoffs: stop, and use the within-company rule below.

Tools you'll touch

• company_technographic: installed products for up to 25 known companies (hg_ids[] or domains[]). Cost: 2 per company, billed proportionally to the batch. Cached 30 days.
• get_vendor_information, get_product_category, get_product_attribute: free lookups for vendor_ids, product_ids, category_ids and product_attribute_ids.
• company_cloud_spend: which cloud, CDN, hosting, DNS and SaaS vendors a company uses and when each was first seen. Domain only. No dollar figures, despite the name. Cost: 2 per call.

To find which companies use a product, use search_companies (hg-search-companies). For usage over time use company_install_time_series (hg-momentum-signals).

What HG returns

Each row is one product install at one company:

Field	Meaning
product_id, product_name	Canonical product. Name the product, not the category
vendor_id, vendor_name, vendor_domain	Vendor
product_category_level1_name to product_category_level5_name	Category path (levels 4 and 5 may be null)
product_category_id	A taxonomy code (e.g. "SW012"), not the 32-hex category_ids filter value
intensity	All-time count of distinct days HG detected the product. Unbounded
product_first_verified_date, product_last_verified_date	First and last detection (YYYY-MM-DD)
location_count	Number of locations with the install
country_code	Install country; null for global or unattributed rows

Per company: company_id, company_domain, installs_count (rows in this response), total_installs_count (all matching rows), has_more.

How to read it

Strength: within the company only. intensity scales with company size and with how long HG has tracked the domain, so the same value means "core" at a small company and "minor" at a large one.

• Rank the company's installs: the top quartile of that company's intensities = core; or compare each install with that company's highest intensity.
• Never use fixed intensity bands. Never compare intensity across companies.
• Low intensity across the whole stack can mean a recently changed domain, not light usage. Check product_first_verified_date and any alternative domain before calling a company a light user.
• Intensity is a breadth-of-detection signal, not a quality or satisfaction score.

Recency.

product_last_verified_date	Reading	How To Write It
Within 90 days	Current	"runs X"
3 to 12 months ago	Recent, not confirmed current	"used X as of "
12 to 24 months ago	Historical	"has used X (last seen )"; don't lead with it
Over 24 months ago	Stale	Don't use alone; corroborate or drop

Tenure and renewal. Tenure is a weak heuristic for renewal timing, never a renewal date. Say so whenever the user asks about renewal.

Placeholder dates. A first-verified date of 2000-01-01 means "before tracking began", not a real adoption date: don't compute tenure or call it a new add. Treat 1970-01-01 and -1 the same way: no value.

Calling it well

Filter by ID. Prefer vendor_ids and product_ids (integers from get_vendor_information or a prior result) and category_ids (32-hex from get_product_category). vendor_names / product_names are case-insensitive substrings, OR within the list, max 10 (more is a 422). A bad ID matches nothing.

Read company_id before concluding. Unfiltered, an empty company_id means the company isn't in the catalog. With a filter it may only mean zero matching installs. A non-empty company_id with no installs = found, no match.

Control the payload.

• max_results defaults to 50 (max 100). On large companies, unfiltered calls above 50 can fail: add filters or keep it at 50 or below.
• install_fields returns only the fields you name (e.g. ["product_id","product_name","vendor_name","intensity","product_last_verified_date"]).
• include_description is false by default; leave it.
• sort: "intensity" (default) or "last_seen".
• last_verified_date{from,to} keeps only recent (or only stale) installs.

Geography. Unset granularity includes global and unattributed installs, which often carry the highest intensity. country_codes switches to one row per product per country, so the same product repeats: dedupe on product_id for a product list. granularity:"global" with country_codes keeps deduplicated rows.

Paging. Page with offset (max 10,000) and stop when offset + installs_count >= total_installs_count. Large companies can have 1,000+ installs, so filter rather than page through everything.

Common pitfalls

1. Applying fixed intensity bands or comparing intensity across companies. Rank within the company.
2. Leading with a stale high-intensity install. It sounds confident and reads out of date in a meeting. Check product_last_verified_date first.
3. Reading 2000-01-01 as an adoption date. It means "before tracking began".
4. Passing product_category_id from a row into category_ids. Different identifiers; resolve with get_product_category.
5. Counting a product twice when country rows are on. Dedupe on product_id.
6. Citing company_cloud_spend as spend. It lists vendors and first-seen dates, no dollars. Dollar estimates are in company_spend (hg-spend).
7. Quoting a category as if it were a product. "Runs CRM" reads wrong; name the product.

Citation rules

Cite company_technographic once per table at the source boundary, with the verification month for anything not current. When mixing installs with intent, label each source: "uses X" and "is researching X" are different claims.

Reference

• V2 tool docs: https://phoenix.hginsights.com/docs/mcp-tools/v2/company-technographic
• V2 tool docs: https://phoenix.hginsights.com/docs/mcp-tools/v2/company-cloud-spend
• Full docs for LLMs: https://phoenix.hginsights.com/docs/llms-full.txt
• Related skills: hg-mcp-calling-rules, hg-recent-signals, hg-momentum-signals, hg-search-companies, hg-company-profile, hg-spend