Field Notes/bryngtmsignalssite-intentidentity-resolutionfield-guide

The Class You Rent

Anonymous site intent is the class almost everyone rents, including us. Renting is not the sin. Renting badly is: paying for a match rate you never route, treating a resolved visit as a lead, and forgetting that a rented instrument reprices, degrades, and gets rented to your competitor. Part 2 of Signals: A Field Guide.

Brad Webb, Chief Growth Officer

Sep 10, 202614 min read

Hero image: a naturalist's field-guide plate showing four GTM signal classes as specimen etchings. Plate two, anonymous site intent, is highlighted with a visit-path etching of three page nodes and a return arc in teal, stamped with a coral lease tag. Title: The Class You Rent. Part 2 of 4 of Signals: A Field Guide.

tl;dr

Anonymous site intent is the second class in the legend: who is on your site and what they read, resolved from a cookie or an IP address to a company or a person by an identity vendor. Almost everyone rents it, including us. Renting is not the sin. Renting badly is: paying for a match rate you never route, treating a resolved visit as a lead instead of a specimen, and forgetting that a rented instrument reprices, degrades, and gets rented to your competitor on the same afternoon. Part 2: learn to read the rented class, and rent well.

Part 2 of Signals: A Field Guide. Part 1: The Class You Own.

Plate II. The class you rent.

Here is what took me too long to admit. A few years ago I bought a visitor-identification tool. It took an afternoon to install. It fed a Slack channel, and for a month I watched that channel the way you watch a bird feeder: with real interest and no plan. Company names scrolled past. Some of them were good. I routed nothing. Not one visit turned into one action by one person. I paid rent on a feed and lived somewhere else.

I have written before about the year we tried to buy our way out of the signal gap. This was the smaller, dumber version. The instrument worked. I had bought eyes and forgotten to attach hands.

Plate II: the site-intent signal

Part 1 was about the class you own: what users do inside your product, with their hands. Site intent is the class next door. It is what people do on your public surfaces before they have told you who they are, plus a guess at who they are.

The guess is the rented part. A visitor arrives with a cookie and an IP address. An identity vendor matches those against its graph and hands you back a company, sometimes a person. Everything after the match is yours to read. The match itself belongs to somebody else.

I write these specimens the way I wrote the product ones, by their parts. Surface, behavior, window.

pricing → return → 3 pages (48h). Somebody read pricing, left, came back inside two days, and read three more pages. That is a person doing homework.

docs → integration page → pricing (same session). Somebody checked whether you fit their stack, found the answer, and went straight to the cost. That is an engineer with a budget question.

careers → nothing. Somebody read your jobs page and left. That is not a buyer. It is a candidate, or a recruiter, or a competitor's recruiter. It looks like intent on a dashboard because the company name resolved and the company was in your ICP. It is a negative specimen, and every field guide needs a few of those. The difference between a birder and a tourist is knowing what the common ones look like.

The fidelity of this class is good. Not great. A product signal is a user telling you what they want with their hands. A site signal is a stranger telling you what they are curious about. Curiosity is worth something. It is not a decision. Read the class as inference and you will use it well. Read it as hands and you will call people who were just looking.

Figure 1. One specimen, fully identified, on somebody else's lease (illustrative, not a benchmark).

Three rungs of resolution

Every site-intent signal comes in at one of three resolution levels, and the level decides what you are allowed to do with it.

Anonymous. You know a visitor did the pattern. You do not know who. You can still act on the pattern itself: change what the page shows next, put the right proof in front of the right path. Cheap, no consent question worth the name, works in any country.

Company. The vendor matched the IP or the cookie to an organization. Now you can route: the account owner gets a note that somebody at Anweledig Labs read pricing twice this week. You can personalize by account. You cannot email anyone, because you do not know who anyone is. This rung is enough for most Plays. It is where I would spend most of my rent.

Person. The vendor matched the visit to a named human with an email address. Now you can contact somebody. This is also where the posture gets heavy: consent, suppression lists, and the plain fact that person-level resolution is a United States phenomenon. The data that makes it possible mostly does not exist elsewhere, and where it exists it is mostly not usable this way. That is not a fencepost for who should buy what. It is just how the class works.

The resolution ladder.

Pick a rung. The panel says what you can do at that level, what it costs, and what posture it needs before you act.

Rung	What you can do	What it costs	Posture it needs
Anonymous	Act on the pattern itself: adapt the page, surface the right proof for the path.	Low. No vendor match needed.	Ordinary site analytics consent. Works in any region.
Company	Route to the account owner; personalize by account. No direct contact.	Medium. Priced per identified visitor.	Vendor terms; a suppression list for customers and competitors; region check for company-level matching.
Person	Contact a named human. Full outbound.	High. Priced per identified person, and heavier to operate.	Consent basis, suppression lists, United States only in practice, and a Play that actually needs a name.

Costs and postures are qualitative and illustrative, not a benchmark or legal advice.

Figure 2. Three rungs, three postures. Most Plays stop at company.

The rule I wish I had followed with my Slack channel: resolve to company unless the Play needs a person. Most Plays need a route, not a name.

BRYN byCivicLabor Day offer ⬩ through September 17

Save Your Labor (Day)

Bryn watches your site, scores the account, runs the Play, and files the run. A free month of it, on any tier.

Timesheet ⬩ arbor.devPunched ⬩ Tue 2:02 PM

2:02:08 PMWatched a return to pricing, then the comparison page

2:02:09 PMScored the account 86

2:02:10 PMRan the pricing.follow-up Play into Slack and the CRM

2:02:11 PMFiled the run, replayable

Your time 0:00Bryn 0:03on the record

Claim your first month free

The math of renting

A match rate is a rent payment. That sentence took me embarrassingly long to arrive at.

Vendors sell match rate as the headline, and it is a fair headline, because the difference between matching a third of your traffic and two thirds is real. But match rate is an input to a multiplication, not an output you can bank. Monthly visitors, times the fraction the vendor can resolve, times the fraction of those that fit the accounts you actually sell to. Every one of those is a fraction below one. Multiply three fractions and you get a small number.

Then the small number goes stale. A resolved visit is worth the most in the hour after it happens and worth almost nothing a week later, which is the whole argument of the edge is the minute after. So the real yield of this class is not "how many accounts did we identify this month." It is "how many accounts did we identify this month that somebody acted on while the visit was still warm." That number is smaller still, and it is the only one that matters.

The math of renting.

Set your own numbers. Nothing here is a benchmark; the point is the shape of the multiplication and how fast the result goes stale.

One worked example (illustrative, not a benchmark): 8,000 monthly visitors, a 35 percent match rate, and 20 percent ICP fit among the identified gives roughly 2,800 identified visitors and 560 fit accounts a month. That is roughly 130 accounts a week, each worth acting on inside 4 hours. Past that window the rent on each one is spent.

Every output is illustrative, not a benchmark. No vendor numbers are used or implied.

Figure 3. Three fractions and a clock. The small number is the one you already paid for.

Move the sliders and you will notice the thing I noticed too late. The monthly invoice is the cheap part. The expensive part is the identified, fit, warm account that nobody touched, because that is the one you already paid for.

The lease

The rented class has three clauses in its lease that the owned class does not. I would read them before signing anything.

Reprice. The vendor sets the price, and the price is set to the vendor's needs, not yours. A Play built only on this class has a cost floor you do not control.

Degrade. Match rates drift. Browsers change what cookies can do, graphs go stale, a data source dries up. A Play built only on this class fires less often over time, quietly, with no error message.

Rent-to-competitor. The same vendor, the same graph, the same match, is for sale to the two companies you keep losing deals to. If they buy it, they see the same Anweledig Labs visit you do, at the same minute. A Play built only on this class is a race you did not know you had entered.

The lease, clause by clause.

Toggle a clause on. The panel restates what happens to a Play built on the rented class alone, and to the same Play paired with an owned product signal like invite → stall → second-seat (48h).

Play on the rented class alone

Vendor reprices: your Play's cost floor moves and you did not get a vote.
Match rate drops: the Play fires less often, quietly, with no error.
Competitor rents the same feed: they see the same visit at the same minute; the Play is a race.

Play paired with an owned product signal

Vendor reprices: the owned signal still carries the Play; you renegotiate or swap the vendor without stopping.
Match rate drops: fewer visits resolve, but the product pattern still fires, and the score tells you what changed.
Competitor rents the same feed: they can see the visit; they cannot see the invite stall inside your product. The Play is still yours.

Qualitative and illustrative, not a benchmark.

Figure 4. Three clauses, two Plays. Pairing is the difference.

Here is the honest paragraph. We rent too. Bryn resolves identity through a single identity vendor, on purpose, because one vendor is one lease you can read, price, and audit, rather than four leases you cannot. And we build the Plays so the rented input is one signal among the owned ones, never the whole Play. A site visit raises a score. It does not, by itself, fire the action. The owned classes carry the weight. The rented class adds resolution.

That is not a hedge. It is the design. Chris wrote on Wednesday about controls being the thing that moves agents into production. A lease you have actually read is a control, and a small one, and it is the one most growth teams skip.

Renting well

Three rules, and they are the whole of part 2.

Route in the hour. If a resolved visit is going to be acted on at all, decide who acts and by when, before the vendor's Slack channel starts filling up. A feed nobody routes is rent on an empty apartment.

Resolve to company unless the Play needs a person. Company-level gets you the account owner and a personalized page. Person-level gets you an email address and a posture problem. Most Plays are fine with the first.

Never let a rented signal fire a Play alone. Pair it with something you own. pricing → return → 3 pages (48h) on a resolved account is interesting. The same pattern on an account that also did invite → stall → second-seat (48h) inside your product is a Play. Everyone has signals, and everyone can rent this one. The owned signal, the class you own, is what turns a rented curiosity into an action worth taking.

The gift

Do this Monday. It costs half an hour.

Write one site-intent specimen by its parts. Steal pricing → return → 3 pages (48h) if you like. Decide the resolution it needs, and for this one the answer is company. Pre-approve the one action: "If it fires on a fit account, the account owner gets a note with the three pages, and nothing else happens until they answer."

Then open your identity vendor's terms and find the three lease clauses. Price per identified visitor. Match-rate SLA, which is usually not there. Exclusivity, which is never there. You are not looking for a reason to cancel. You are looking to know what you rent.

How Bryn runs the class

Bryn is not another dashboard to watch. It is the governed execution layer that runs Plays through your stack. It watches site, product, and CRM together, so the site signal is one input to the score rather than the whole story. When the pattern you named crosses the threshold you set on an account that fits, it runs the Play you approved. And it logs the resolution level it used and the vendor the match came from, on every run. Your CFO can see exactly what the rent bought. So can you.

Follow-up has no owner was Monday's argument. This is the same argument at the top of the funnel. A resolved visit with no owner is not a signal. It is an invoice.

Next in this series: the class you already have and never read. CRM lifecycle, the history sitting in your own pipeline, and why the class you own on paper is the one most teams treat as a filing cabinet.

Part 2 of Signals: A Field Guide. Part 1: The Class You Own. Part 3 next week.

Stop watching signals. Start running them.