Read a rule's estimated reach¶
Estimated reach is an estimate of how much of an agent's recent traffic a draft rule would match, shown in the rule editor before you save. It is the most direct check that a rule does what you meant: a rule meant for a small group that matches every request, or one that matches no one, usually has a condition that was read differently from what you intended. This page describes how the estimate is made, how to read it, and what it leaves out.
How the estimate is made¶
Offer Manager keeps a random sample of up to 5,000 recent requests for each moment, from the last seven days, refreshed daily. When you edit a rule, the draft is evaluated over the samples of its moments with the same code that serves offers, so the estimate and serving can't disagree about what a condition means. Each request is evaluated with the attributes it carried at the time.
The estimate applies the rule's moments, Where, Who sees it, and Not shown to. It updates as you edit, including changes you haven't saved and changes made by translating an instruction.
Read the estimate¶
The panel at the top of the rule editor shows the following:
| Part | Example | Meaning |
|---|---|---|
| Headline | About 12% of requests at After a billing question in the last 7 days would have matched. | The share of sampled requests at the rule's moments that the draft matched. With a small sample, it reads "Roughly". |
| Customers | About 3,400 customers, estimated from the sample. | The estimated number of distinct customers matched, from requests that carry a customer identifier. A customer seen at several of the rule's moments counts once. |
| Notes | The draft has history conditions, which read today's history. | Why the estimate is approximate or deserves a second look. See the next section. |
Click How this is estimated to see how many sampled requests matched, when each moment was sampled, and the result for each moment.
A draft that matches far fewer requests than you expect usually has one condition removing most of them. To find it, remove conditions one at a time and watch the estimate, without saving.
Notes on the estimate¶
| Note about | What to do |
|---|---|
| No requests at the moments | The moments had no traffic in the last seven days. There is nothing to estimate until the agent reports them. |
| A small sample | Fewer than 200 requests were sampled. Treat the share as rough. |
| No request matched | Check that the conditions mean what you intended, and that the agent sends the attributes they use, on the Attributes page. |
| Every request matched | Check that Who sees it and Not shown to are set as intended. |
| History conditions | Conditions on past responses, such as declines in the last 30 days, are evaluated against each customer's history as it is today, which is close to but not the same as it was at each request. |
| Schedule and frequency | The schedule and the How often cap aren't part of the share. |
| A sample being taken | A busy moment that had no sample yet is being sampled and is left out of this estimate. Check again in about a minute. |
| No channel named | The rule is limited to channels, and most sampled requests named no channel, so they can't match. Ask the agent's team to send the channel. See Name the channel. |
| No offers | The rule has no offers yet, so conditions on this offer's history match no one. |
What the estimate leaves out¶
The estimate describes the past week's requests. It doesn't predict how often the rule will win: another rule with a higher Priority at the same moment, the moment's frequency cap, and the offers' frequency caps can all keep a matching request from showing this rule's offer. To see why a specific request got the offer it did, ask the copilot to explain the decision, or read its decision trace.
What's next¶
- Write a rule in plain language, with the estimate beside each change.
- Read the full response, including every flag, in Impact preview.