Spotting churn risk when a customer removes your technology

If your product leaves a footprint on a customer's website, its disappearance is a dated, public event. This guide shows how to watch your own technology across your customer list, tell a confirmed removal from a technology that is only missing, notice a competitor arriving beside you, and turn the result into a churn alert whose accuracy you can measure against your own cancellations.

What a removal is in the data

Two datasets hold the record, both in the marketing stack dataset. The Technology Stack (company_technologies) has a row for each technology detected on a company website, from page content, scripts, network requests, response headers and DNS records, with first_seen_at and last_seen_at (the first and latest observation that saw it), missing_since and seen_via. Technology Changes (company_tech_events) records a dated event for every adoption, removal and platform migration, with observed_at, category, key (a technology id, for a technology event), change (added, removed or changed) and technology_name.

A removal is confirmed in two steps. A technology absent from an observation is marked missing and missing_since is set. It is recorded as removed once a later observation confirms that it is still absent, so a tag that comes and goes with a consent banner or a test does not raise a removal. The state before confirmation is your early warning.

Refresh is daily to weekly depending on the company, so a removal is recorded within days to a couple of weeks of the tag going. A company's first observation sets a baseline and writes no event. The methodology sets out the rules in full.

How much of your customer base shows your tag?

Before you build alerts, measure what share of your active customers show your tag. In the queries below, customer_accounts is your own table with a company_id and a status, and your technology id replaces your_technology_id.

select
  count(*)                                                      as customers,
  count(t.company_id)                                           as seen_now,
  round(count(t.company_id)::numeric / nullif(count(*), 0), 2)  as share_seen
from customer_accounts a
left join (
  select distinct company_id
  from company_technologies
  where technology = 'your_technology_id'
    and missing_since is null
) t on t.company_id = a.company_id
where a.status = 'active';

If the share comes back at 62%, every alert speaks for those 62% of your customers, and you report that share beside every alert rate. For the rest, the tag may sit only inside your product, so add the usage signals you hold to the programme.

Three alerts, from weakest evidence to strongest

A customer that is leaving can leave three kinds of trace in the data, and they differ in how much each proves.

• A competitor appears. A row in Technology Changes with change of added and key set to a competitor's technology id, while your tag is still seen. It is the earliest trace and the least certain: it can be a test, a second tool or a parallel run.
• Your tag goes missing. missing_since is set on your row in the Technology Stack, and last_seen_at shows when the tag was last seen, so the gap is now() - last_seen_at. A later observation confirms or clears it.
• Your tag is removed. An event with change of removed and key set to your technology id. A removal that falls within a window you choose of a competitor's addition is the pattern to treat as a replacement.

The first query lists your customers in the missing state. The second lists confirmed removals and flags those with a competitor added from 60 days before to 30 days after.

select
  a.account_id,
  t.domain,
  t.last_seen_at,
  t.missing_since,
  now() - t.last_seen_at as unseen_for
from customer_accounts a
join company_technologies t on t.company_id = a.company_id
where t.technology = 'your_technology_id'
  and t.missing_since is not null
order by t.missing_since;

select
  r.company_id,
  r.observed_at             as removed_at,
  c.technology_name         as competitor,
  c.observed_at             as competitor_added_at,
  c.observed_at is not null as replaced
from company_tech_events r
left join company_tech_events c
  on  c.company_id = r.company_id
  and c.category   = 'technology'
  and c.change     = 'added'
  and c.key in ('competitor_one', 'competitor_two')
  and c.observed_at between r.observed_at - interval '60 days'
                        and r.observed_at + interval '30 days'
where r.category = 'technology'
  and r.change   = 'removed'
  and r.key      = 'your_technology_id'
  and r.company_id in (select company_id from customer_accounts)
order by r.observed_at desc;

A removal with no competitor beside it still calls for a conversation. The customer may have stopped, consolidated into another tool or lost the tag in a rebuild, and each of those needs a different one.

Reading a removal: causes and the check for each

A removal is a prompt to look, not a verdict. A tag absent once and back at the next observation never becomes a removal, and the table lists what else can produce one.

Context from Market Series

One customer removing your tag is an account problem. Removals across a whole segment are technology churn, a product or market problem that calls for a different response. Market Series (market_series) carries tech_removed and tech_added for each recognised technology, written as family:subject, as a rate per 100 companies or websites, by industry, country or company size band, over 7, 30 and 180 days.

select as_of, dimension as size_band, count as removals, cohort as sites, rate, growth
from market_series
where metric = 'tech_removed:your_technology_id'
  and dimension_kind = 'size'
  and window_days = 30
order by as_of desc, rate desc;

Rows are same-store: the rate is over the websites read since before the window began and still read at its end, so the growth of the index does not inflate it, and a row over fewer than 20 companies is not written. If your removal rate in one size band stands well above the others while one of its customers drops your tag, look at the band before the account. The guide to measuring an installed base goes further into adds, removals and net change, and running competitor displacement plays reads the same events from the side of the vendor that gains.

Measure the alert before you trust it

Define three numbers on your own cancellation history.

• Recall. Of the customers who cancelled, the share with a removal event before the cancellation date.
• Precision. Of the customers with a removal event, the share who cancelled within your renewal window.
• Lead time. The median number of days between the removal and the cancellation date.

With few cancellations the figures will be rough, so keep the table and extend it each month. Then tune the alert. If precision is low, require a competitor's addition before an alert reaches the account team. If recall is low, alert on the missing state as well and send it to a lower-priority queue.

How to read a detection

• Presence, not use. A detection shows that a technology is present on the website. A customer can cut seats or move its work elsewhere while your snippet stays on the page, so pair removals with the usage and billing data in your own systems.
• A second signal. A leadership change is recorded by role in Company News and can serve as a second signal beside a removal. The post on how we detect technologies describes what detection reads.
• Dated evidence. Every event carries its observation date, so you can place a removal against a cancellation date or a renewal window.

Frequently asked questions

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