HG Insights

Skill: HG Technographic

Tech-stack claims your AE can repeat in the room: the right product, ranked within the account, dated by its last verification.

Overview

Teach Claude to read HG install data the way a careful analyst would. It names the product rather than the category, ranks install strength within each company instead of using fixed intensity bands, checks the last verified date before calling an install current, treats 2000-01-01 as 'before tracking began' rather than an adoption date, and keeps payloads small with ID filters and selected fields.

Use cases

  • Briefs that say 'runs' only when the install is current

    Claude reads the last verified date on every install. Within 90 days it writes 'runs X'; older installs are dated ('used X as of March') and anything over 24 months is corroborated or dropped. Your AE doesn't open a meeting with a stack reference the customer retired last year.

  • Core products ranked within the account, not against a fixed scale

    Intensity counts detection days and grows with company size, so Claude ranks each company's installs against its own top readings. The brief calls out the products that are core at that account, without comparing a startup's numbers to a global enterprise's.

  • No phantom adoption dates or double-counted products

    A 2000-01-01 first-verified date is treated as 'before tracking began', not a new add, and country rows are deduped by product. Tenure and stack counts in the brief hold up when someone checks them.

View full skill

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:

FieldMeaning
product_id, product_nameCanonical product. Name the product, not the category
vendor_id, vendor_name, vendor_domainVendor
product_category_level1_name to product_category_level5_nameCategory path (levels 4 and 5 may be null)
product_category_idA taxonomy code (e.g. "SW012"), not the 32-hex category_ids filter value
intensityAll-time count of distinct days HG detected the product. Unbounded
product_first_verified_date, product_last_verified_dateFirst and last detection (YYYY-MM-DD)
location_countNumber of locations with the install
country_codeInstall 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_dateReadingHow To Write It
Within 90 daysCurrent"runs X"
3 to 12 months agoRecent, not confirmed current"used X as of "
12 to 24 months agoHistorical"has used X (last seen )"; don't lead with it
Over 24 months agoStaleDon'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