Use case

Mapping a partner ecosystem from technology co-occurrence

Co-occurrence on company websites shows whose audience overlaps yours. A worked method with the datasets, the lift measure and the checks that separate partners from rivals.

Updated 5 October 20266 min read

Integration and co-marketing partners are usually tools whose customers overlap with yours and whose product does not compete with it. Technographic data shows the overlap directly: which tools appear on the websites that run yours. This guide shows how to count those overlaps, correct them for how common each tool is, add the order in which tools are adopted, and turn the result into a short list of candidates.

What co-occurrence tells you

Two tools co-occur when the same website shows both. That is an overlap of audiences, which is what a co-marketing partner needs, and a prompt to check technical fit, which is what an integration needs. Read it as a map of shared customers, and confirm technical fit in the partner's own documentation. It is not causal: Two tools can sit together because one vendor bundles the other, because both suit the same industry, or because both are on nearly every site.

The counts come from Technology Stack, with one row per website and technology, its technology_name and technology_category, and the first-seen and last-seen dates (first_seen_at, last_seen_at). Technology Changes adds the date of every adoption and removal. A third dataset, Website Profile, gives the markets, languages, apps and key pages of each website. All three belong to the marketing stack dataset, and the data dictionary defines each column. The unit throughout is the company, so a company with two websites counts once.

Step 1: count the overlap and correct for popularity

For every other tool B, take three numbers: the share of your base that runs B, the share of all read companies that runs B, and the ratio of the two, called lift. A lift of 1 means B is as common among your companies as anywhere, so it says nothing about you. A lift well above 1 marks an audience you share. A lift well below 1 means the companies that run yours avoid B, which usually makes it a rival.

ToolCompanies running bothShare of your baseShare of all readLift
A tag manager1,30065 per 10062 per 1001.05
Tool B, a complement42021 per 1006 per 1003.5
Tool C, a rival402 per 1009 per 1000.22

The table is illustrative: Acme Robotics, an invented vendor, has a base of 2,000 companies among 60,000 whose websites were read. The tag manager is on most sites, so its large overlap is no signal. Tool B is rare overall and common among Acme's companies, which is what a partner looks like.

A tool on 62 per 100 websites cannot show a lift above 1.6, however loyal your customers are, because the share of your base cannot exceed 100 per 100. Judge universal tools on their share of your base, and keep lift for the tools that are not universal.

-- :mine is the technology id of your own tool
with current_tech as (
  select distinct company_id, technology, technology_name, technology_category
  from company_technologies
  where missing_since is null
),
mine as (
  select company_id from current_tech where technology = :mine
),
per_tool as (
  select technology, count(*) as n_b
  from current_tech
  group by technology
),
overlap as (
  select c.technology, c.technology_name, c.technology_category, count(*) as n_ab
  from current_tech c
  join mine m on m.company_id = c.company_id
  where c.technology <> :mine
  group by c.technology, c.technology_name, c.technology_category
),
sizes as (
  select
    (select count(*) from mine)                                 as n_a,
    (select count(distinct company_id) from company_site_facts) as n_all
)
select
  o.technology_name,
  o.technology_category,
  o.n_ab,
  o.n_ab * 1.0 / s.n_a                              as share_of_base,
  p.n_b  * 1.0 / s.n_all                            as share_of_all,
  (o.n_ab * 1.0 / s.n_a) / (p.n_b * 1.0 / s.n_all)  as lift
from overlap o
join per_tool p on p.technology = o.technology
cross join sizes s
where o.n_ab >= 30
order by lift desc;

The floor of 30 on n_ab keeps a handful of coincidences from topping the list. Choose your own. If your product is not among the recognised technologies, build mine from your customer list matched to company_id instead. To draw a map and not a ranking, group the same result by technology_category and total the companies: the categories your customers buy around you show where partners cluster.

Step 2: separate partners from rivals, bundles and local effects

Rank by lift, then filter in three passes.

  1. Category. A tool in your own technology_category is a substitute. A substitute with a high lift is usually a company in the middle of a migration, running both for a while, so check the dates before reading it as a partner.
  2. Bundles. A tool added at the same reading as yours may belong to the same package. In company_tech_events, count the companies where the added event of B has the same observed_at as yours. A high share marks a bundle, and a bundle is not a partner you can approach on your own terms.
  3. Segments. Repeat the count within segments of your own list, such as country or size band. A lift that holds in each is more credible than one that exists only in the whole, where two tools may meet only because both are common in one place.

Step 3: add the order of adoption

Overlap says who shares customers. Order says which tool companies reach for next. This query counts, for each other tool, the companies that added it within 90 days after adding yours.

-- adjust the date arithmetic to your engine
select
  b.key                         as technology,
  b.technology_name,
  count(distinct a.company_id)  as companies
from company_tech_events a
join company_tech_events b
  on  b.company_id  = a.company_id
  and b.category    = 'technology'
  and b.change      = 'added'
  and b.key        <> a.key
  and b.observed_at >  a.observed_at
  and b.observed_at <= a.observed_at + interval '90 days'
where a.category = 'technology'
  and a.change   = 'added'
  and a.key      = :mine
group by b.key, b.technology_name
order by companies desc;

Divide each count by the companies that added yours, then compare it with the same figure for the bundle case, which you get by changing the join to b.observed_at = a.observed_at. The rows below are illustrative, for 400 companies that added the tool.

ToolAdded within 90 days afterAdded at the same reading
Tool B96, or 24 per 10016, or 4 per 100
Tool D31, or 8 per 1000
Tool E58, or 15 per 10048, or 12 per 100

Tool B is added after yours by a quarter of the adopters and with it by few, so companies choose it separately: a candidate. Tool E is added at the same reading by one adopter in eight, which points to a package. A tool often added after yours is the best case for an integration, because those companies are already adopting it as part of the same stack. Swap the sides of the join to find the tools added before yours, which are the ones you can build on.

Each event is dated by the observation that recorded it, and a first observation sets a baseline, so a sequence begins with the first change after it.

Step 4: turn the list into a shortlist

Each candidate should answer five questions, and each answer has a source.

QuestionMeasureWhere
Do the audiences overlap?Share of your base running B, and liftTechnology Stack
Is B a complement?A different category from yours, added after yours and not with itTechnology Stack, Technology Changes
Is B growing?tech_added against tech_removed per 100 websitesMarket Series
How many companies does B bring?Websites running B and not yoursTechnology Stack
Is there a door?Whether B's vendor site links to a partners pageKey pages in Website Profile

For the fourth question, count the companies that run B and not your tool.

select count(distinct company_id) as reachable
from company_technologies
where technology = :partner
  and missing_since is null
  and company_id not in (
    select company_id from company_technologies
    where technology = :mine and missing_since is null
  );

That is the audience of a joint campaign, as companies with names and websites. For the last question, if the vendor of B is itself a company in the index, its key pages in Website Profile show whether its site links to a partners page. A link suggests a programme to apply to, and no link proves nothing. To follow how large B's footprint is and how it moves, see measuring an installed base.

Integration or co-marketing

The same shortlist serves two decisions, and they weight the columns differently. For an integration, category fit and adoption order matter most, because you want a tool that your customers adopt as part of the same stack and that your product can sensibly connect to. For co-marketing, the reachable audience and its fit matter most: the partner's companies that are not yet yours, in the countries and sizes you sell to. A candidate can pass one test and fail the other, and it is cheaper to know which before the first call.

Rerun the counts monthly with the same floor and the same segments, and keep each run's output. Watch the lift of each shortlisted tool and its adds and removals per 100 websites. A tool whose lift is falling or whose removals are rising is losing the audience you wanted.

How to read the result

  • A detection shows presence on the website. A tool that appears on a company's website is in use there. A tool that works only in the background of a business, with no trace on the site, is outside what co-occurrence measures, so read the result as the overlap among visible tools. The blog explains how detection works.
  • A website is not a relationship. Two tools on one site show shared customers and the order of adoption. Who bought them, how they connect and what they cost come from the vendors' own pages.
  • The result is a list of companies. Each row is a company with its identifiers and website, ready to join to your own CRM, where your relationships open the introduction to a partner.

Rivals show up in the same data. The guides to finding accounts by the technology they run and to competitor displacement use the same tables from the selling side.

Frequently asked questions

What is technology co-occurrence?

Two technologies co-occur when the same website shows both. Counting how often each other tool appears on the websites that run yours, against how often it appears everywhere, shows whose customers overlap with yours. It describes an overlap of audiences, not a technical integration between the two tools.

How do you choose integration partners for a software product?

Start with tools in other categories that appear on many of your customers' websites, and rank them by lift so that universal tools do not dominate. Check that they are adopted after yours and not alongside it, and that their audience is large enough to matter. Then confirm technical fit in the partner's documentation.

What is lift and why use it instead of a raw count?

Lift is the share of your base that runs a tool divided by the share of all websites that runs it. A raw count ranks the most common tools first, whatever your audience. Lift removes that effect. A value of 1 means no association, well above 1 means the tool is over-represented among your websites, and below 1 means it is under-represented.

What does technographic data show about two tools that appear together?

It shows which tools are present on the same websites and when each was added, so you can see how large the shared audience is and which tool companies adopt next. Vendors' own documentation describes how their products connect, and co-occurrence tells you where an integration would reach the most of your customers.

How many websites do you need before a pair of tools means anything?

There is no universal number. Set a floor on the number of companies running both tools, so that a handful of coincidences cannot top the list, and repeat the count within segments such as country and size band. A pair whose lift holds across segments and across weeks is more credible than one with a high lift on a few dozen websites.

The queries and code on this page are examples to adapt. Test them in your own environment before you rely on them.