Technology & integration

The technology behind intent signals is less mysterious than the vendor brochures suggest. It consists of three parts: collection on your own website, mapping of the recorded accesses to companies, and a connection to the systems people later work in. This page describes all three and names where they become unreliable.

How an IP address becomes a company

Every access to a website brings with it the IP address it comes from – without it the server could not send a reply. Mapping that address to an organisation draws on several publicly accessible sources.

Registration data from the address registries. Address ranges are allocated by regional registries such as RIPE NCC for Europe and recorded with the name of the organisation holding them. These entries can be queried via RDAP or Whois. A company with its own address range is directly identifiable this way; by far the most are not, because they draw addresses from their provider.

Reverse resolution of the name. Many addresses have a name on record, maintained by the provider or the line holder. If that name contains a company designation or a domain, it is a strong hint. If it only contains the address in encoded form, it is worthless.

Mapping via the autonomous system. Every address belongs to a network group with a unique number. From that you can at least derive whether it is a corporate network, a consumer line, a mobile network or a data centre.

From these sources a mapping table emerges that has to be maintained continuously. Address ranges change owner, companies move, providers restructure. A mapping that is a year old reliably contains errors.

Why coverage has gaps

These limits belong in every honest conversation about the topic:

  • Home offices. An access from a private line leads to the provider, not to the employer. Since working from home became normal, a considerable share falls away with it.
  • Mobile networks. Addresses from mobile networks cannot be mapped to any company.
  • VPN and cloud access. The access appears at the location of the data centre.
  • Shared address ranges. Many lines share one address. That produces mappings that are formally correct and say practically nothing.
  • Group structures. An address range belongs to the parent company, the access comes from a subsidiary in another country.

What follows from this: a share of accesses remains unmapped, and a share of the mappings is wrong. That is enough for prioritisation, not for billing. Vendors who make no statement about their hit rate should be asked about it.

Collection on your own website

On the website itself, a script runs that records page views, time on page, referrer and triggered events. Technically this is no different from ordinary web analytics, and it is worth thinking about both together instead of running two collections side by side.

Two designs are common. In the client-side setup the browser talks directly to the evaluating service. That is quick to set up and vulnerable to ad blockers and browser restrictions. In the server-side setup, an endpoint of your own runs under a subdomain of the website; the browser only talks to that, and the endpoint decides what gets passed on. That is more robust, allows data minimisation before passing on, and costs operational effort.

Which events get recorded at all is a substantive decision, not a technical one. The useful ones are the pages and actions that indicate seriousness in your particular business: prices, technical documents, references, configurators, downloads. That definition is best derived from past closed deals.

Access to information on the end device – cookies, local storage – requires consent under § 25 of the German TDDDG, unless it is strictly necessary for the service the user explicitly requested. Transmission of the IP address, by contrast, happens through the protocol itself; it cannot be switched off without switching off the connection.

From that distinction the conclusion is occasionally drawn that a purely IP-based analysis is generally exempt from consent. It is not that simple: the processing itself remains subject to the GDPR, and whether a legitimate interest holds depends on the individual case. For an assessment of your specific setup you need legal guidance. What you can prepare technically is the clean separation: which components write to device storage, which do not, and can the consent-requiring part be released on its own?

Removing noise

Without filters, a good part of every signal list consists of activity nobody is interested in:

  • Accesses from your own company, your own agency and your service providers
  • Search engine crawlers and automated retrievals posing as browsers
  • Availability checks from monitoring services
  • Competitors, job applicants and students
  • Existing customers looking for support

Exclusion lists by IP range, company name and domain are the single most effective step during setup. They belong maintained, not set once.

What belongs in the data model

A workable model has three levels. At the bottom sit the events with timestamp, page and referrer. Above that lies the session, which bundles related events. Above that the company, to which sessions are attributed, with master data and a history carried forward over time.

The score sits at the top level and is calculated, not stored like a property. What matters is that the raw events are retained: as soon as it turns out the weighting does not fit, it has to be recomputable retroactively. Anyone keeping only the score cannot do that.

Retention periods belong with this. Signals lose value within weeks; a data store reaching back three years has hardly any use and increases the risk in the event of a breach.

Connecting to CRM and automation

This is where it is decided whether the method arrives in daily work.

Reconciliation with existing accounts. A recognised company has to meet the existing CRM record, otherwise duplicates arise. The match generally runs on the domain, not on the company name – spellings differ too much.

Direction of transfer. In most cases one direction is enough: signals into the CRM. Two-way synchronisation is more work and only pays off once CRM information is meant to influence the scoring, customer status for instance.

Field mapping. Less is better. One field for the last signal timestamp, one for the recognised topic, one for the score. Create twenty fields and you will fill them and never read them.

Triggers and notifications. An alert that comes too often gets ignored. The threshold is deliberately set high at the start and only lowered once the processing works.

If custom interfaces between systems have to be built along the way, that is a development project with the usual requirements around error handling and logging.

Rollout in steps

  1. Define target accounts and the ideal customer profile before technology comes into play.
  2. Check the collection on the website and define the events that indicate seriousness.
  3. Clarify and document consent handling.
  4. Set up the mapping, populate exclusion lists, let it run for two weeks and spot-check the results by hand.
  5. Only then transfer into the CRM and set up notifications.
  6. After the first closed deals, recompute the weighting.

The fourth step is skipped most often and is the most important: anyone who never checked whether the identified companies are correct is building on an assumption.

How the field is developing is under trends and strategies; the B2B intent signals page gives an overview of the whole series. For an assessment of a specific setup, drop us a line – you can also book a slot directly there.