# Spend enrichment credits only where they pay back

**The job:** stop paying to enrich visitors you will never contact, without
losing the ones you would have called.

**Who this is for:** anyone on a paid plan watching credits disappear by the
middle of the month.

**What it costs you:** one configuration change, and a habit of checking what
you bought.

---

## Before you start

- You need an **API key with the `copilot` scope** — the enrichment gate is
  configured through the assistant or the dashboard, not the four public
  `GET`s.
- You need the **pixel live**, or there is nothing to enrich and nothing to
  tune.
- Enrichment is a **paid-plan feature**. The free tier spends nothing by
  design: it runs on data that costs nothing at the margin. Your plan's credit
  allowance is published at `GET /capabilities` under `plans`.

---

## What you are actually buying

Identification is one thing; enrichment is another. Identification tells you
*who* a visitor is from the identity graph. Enrichment spends a credit with a
vendor to fill in the rest — title, company detail, the fields that make a
first email worth sending.

Credits are finite and monthly. So the only question that matters is: **which
visitors are worth a credit?** Enriching everyone is the default failure — the
month's budget goes on people who bounced off your homepage once.

## See where it goes today

```bash
curl -X POST https://app.signal.geysera.com/agent-api/signal/copilot/ask \
  -H "Authorization: Bearer $SIGNAL_COPILOT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"question": "What is my enrichment configuration and how many credits have I spent this month?"}'
```

That returns the gate and the budget together, which is the pair you need —
a generous gate with a small cap does not fail loudly, it just stops enriching
partway through the month and leaves the rest of your visitors bare.

## The four dials

The gate decides who is eligible. Caps decide how much you will spend before
stopping.

| Dial | What it does |
|---|---|
| `min_intent_score` | Only enrich at or above this intent score. The single most effective filter. |
| `account_kind` | `business`, `personal`, or `all`. |
| `page_patterns` + `match_mode` | Only enrich visitors who saw particular pages — `all` of them, or `any`. |
| `daily_cap` / `total_cap` | Spend ceilings per day and per month. |

Ask for a change in English:

```json
{"question": "Only enrich business visitors with an intent score of 60 or higher, and cap it at 40 credits a day."}
```

It will describe the change and wait for your approval before applying it.

## Two traps that cost real money

**An empty `page_patterns` list matches NOBODY, not everybody.** This reads
backwards from every other filter in the product, where empty means "no
restriction". Here, setting it to `[]` switches enrichment off in practice — and
it does so silently, because a gate that matches nothing produces no errors,
just an enrichment budget that never gets spent and visitors who are never
filled in. If credits stopped moving and nothing looks broken, check this first.

**On a DTC site, `personal` is most of your traffic.** Consumer mailboxes roll
up under one sentinel, so `account_kind: "all"` on a consumer site means you are
mostly buying enrichment for individuals. That is right if you sell to people
and wrong if you sell to companies, and the default does not know which you are.
Setting `business` on a DTC store can take your spend to near zero — which is a
saving or a mistake depending entirely on your model.

## Check what you got, not just what you spent

A credit spent is not a field filled. Ask about a specific person:

```json
{"question": "What did enrichment find for dana@acme.com?"}
```

Two answers are worth acting on. **"Never enriched"** means the identity fields
you are seeing came from identification, not from a paid lookup — so the gate
never let this person through, and if you would have called them, your threshold
is too high. **"Expired"** means what you are looking at is what we last saw,
not what is true now; re-running refreshes it and spends again.

Sampling ten people you actually contacted last month tells you more about
whether the gate is set right than any aggregate.

## A starting point worth tuning

There is no universally correct configuration, but there is a sensible order to
find yours:

1. **Start with the intent threshold alone**, set where your reps would
   genuinely pick up the phone. Leave the page filter empty of restrictions.
2. **Add a daily cap** at roughly your monthly allowance divided by 25, so a
   single busy day cannot eat the month.
3. **Only then add page patterns**, and only for pages that genuinely indicate
   intent — pricing, a specific product, a booking page. Remember `any` versus
   `all`: requiring `all` of three pages is a much narrower gate than it looks.
4. **Re-check after two weeks** by sampling people you contacted.

Raise the threshold if you are running out mid-month. Lower it if you keep
finding people you wanted who were never enriched.

## Let an agent watch it

This is a good standing job for the loop in [Give Signal to any LLM as
tools](./give-signal-to-any-llm-as-tools.md): once a week, ask for the
configuration and the spend, compare against the allowance in `/capabilities`,
and say something only when the run rate will miss or overshoot the month. A
budget that quietly stops working is the failure mode, and it is exactly the
kind of thing nobody notices until a rep asks why a record is empty.

---

## Next

- [Build a daily call list](./build-a-daily-call-list.md) — who the credits
  were spent on, ranked.
- [Write a first-touch email from what they read](./write-a-first-touch-email-from-what-they-read.md)
  — the thing enrichment is funding.
- [Watch your own data quality](./watch-your-own-data-quality.md) — whether
  the inputs deserve the budget at all.