Running competitor displacement plays from technology changes

When a rival's technology disappears from a company's website, a change has happened that you can see and date. This guide shows how to find technology churn in Technology Changes, how to tell a swap from an abandonment and from a flicker, which play fits each pattern, and which measures show whether the plays are worth running.

The output is accounts and dates: which company, which tool, which day. The owner and the contact come from your CRM. Each event says what changed on a website and when, which is the timing a displacement play is built on, and a removal is a reason to ask the account a question.

What Technology Changes records

Technology Changes (company_tech_events) has one row for every change observed on a company website: every adoption, removal and platform migration, and every new market, language, currency or app. Five columns do the work, and the data dictionary defines them all.

Technology and DNS events also carry technology_name and technology_category. Two rules from the methodology shape how you read them. A company's first observation sets a baseline and is never counted as a change, so every event is a real difference between two observations. A commerce or content platform that is removed while another appears is recorded as one platform change.

Technologies detected from DNS records, such as a workspace, a mail provider or a domain verification, change under category set to dns. If your rival is one of those, query both categories.

Four patterns and a play for each

The window of 14 days in the table is a starting value, and it runs both ways because a new tool is sometimes added before the old one goes.

Each play is a hypothesis, and the measures below say which ones to keep. The third is the easiest to test, because the events show whether tools change around a platform change: count the removed and added technology events for the same company in the 30 days either side of each platform event. If platform changes bring tool churn with them in your data, the play earns its place, and if not, drop it.

A new account id under a rival's technology, an event with category set to technology_id, belongs with the fourth pattern. It suggests that the account is widening its use of the rival, which makes it a poor target for the moment.

A worked query: a rival removed with no replacement

with removed as (
  select company_id, key as technology, technology_category, observed_at
  from company_tech_events
  where category = 'technology'
    and change = 'removed'
    and key = any(:rivals)
    and observed_at >= current_date - 30
)
select r.company_id, r.technology, r.observed_at
from removed r
where not exists (
  select 1
  from company_tech_events a
  where a.company_id = r.company_id
    and a.category = 'technology'
    and a.change = 'added'
    and a.key <> r.key
    and a.technology_category = r.technology_category
    and a.observed_at between r.observed_at - interval '14 days'
                          and r.observed_at + interval '14 days'
);

Only a different tool in the same category counts as a replacement. The same tool coming back is a flicker, handled below. Change not exists to exists and the query returns the swaps. Join either result to your CRM on company_id or on the domain, and drop the accounts you already own. The :rivals parameter is a list of technology ids, and the guide to finding accounts by technology shows how to build that list and the CRM match.

Here is the query read on an illustrative account. Acme Robotics, an invented company, removes a rival analytics tool on 30 September and adds a different analytics tool on 2 October. A replacement arrived within two days, so the query as written leaves the account out, and the version with exists returns it as a swap. Whether anyone calls depends on who owns the new tool. An account that moved to your product is a customer to look after, one that moved to a complement needs a different message, and one that moved to another rival is lost for now.

Reading the dates

observed_at is the time the change was observed, and the change happened some time before it. Datasets are refreshed daily to weekly, depending on the company, so the gap between a change and its observation is between a day and a week. Treat observed_at as the latest date a change can have happened, and work in weeks.

Set windows in weeks, count them from observed_at, and never tell a rep that a change happened today. A tight window is a promise a weekly refresh cannot keep, and a window in weeks is one the data keeps.

Filtering out a flicker

A technology that is removed and added back within a few weeks is a flicker, a tag that came and went, and not a decision. You should know how often it happens in your list before a rep acts on a removal.

select r.company_id, r.key, r.observed_at as removed_at,
       min(a.observed_at) as re_added_at
from company_tech_events r
join company_tech_events a
  on a.company_id = r.company_id
 and a.category = r.category
 and a.key = r.key
 and a.change = 'added'
 and a.observed_at > r.observed_at
 and a.observed_at <= r.observed_at + interval '30 days'
where r.category = 'technology'
  and r.change = 'removed'
group by r.company_id, r.key, r.observed_at;

The share of removals that appear in this result is your reversal rate. Hold each removal for a short period before it reaches a rep, and set that period from your own rate.

The measures that tell you whether it works

• Capture. The share of rival removals that reached a rep within your window.
• Speed. The median days from observed_at to the first touch.
• Conversion. Opportunities opened within 60 days per removal worked, against removals you held back, if you hold some back.
• Reversal. The share of removals followed by the same tool being added back.
• Platform test. The count described above, of tool changes around each platform event.

Every event is dated and written once, never revised, so each measure can be recomputed for any past period and gives the same answer. Report each measure with the number of accounts behind it, and read nothing from a handful.

How to read a removal

• A detection shows presence on the website. A tool that moves to a server-side set-up can disappear from the website while it is still in use, so a removed tag is a reason to ask the account, and the question is the play.
• An event carries timing. Behind each event is the date it was observed, so any timing window is built on behaviour, and the contract dates sit in your own CRM beside it.
• A company's first observation is a baseline. A newly indexed company shows its stack at once, and its events begin with the next observed difference.

How Fokals delivers it

The marketing stack dataset is refreshed daily to weekly, depending on the company, and reaches you by REST API or as bulk files. Its events are the same rows a vendor reads from the other side in spotting churn risk when a customer removes your technology, and the weekly counts of added and removed tools across a market are the subject of measuring an installed base. To rank the accounts a displacement query returns, see prioritising accounts with intent scores.

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.