Quick answer: Dynamic Number Insertion (DNI) is a pool of tracking numbers plus a page snippet: the snippet reads where a visitor came from, picks a number from the right pool, and swaps the displayed phone number so the inbound call can be attributed back to the source that drove it. Devotel Orbit ships this as Numbers > Call Tracking (/numbers/tracking-pools) — pools bind tracking DIDs from your own inventory to a source, campaign, and match rules, and the resulting calls roll up in Insights > Attribution > Call attribution. This explainer covers what a DNI pool is (and is not — DNI vs DNC vs DNO vs TRACED), how per-session number binding works, where the attribution is read, and how consent rules, quiet hours, and IVR or AI-agent routing interact with it. The product walkthrough lives in the call tracking and attribution guide; this post is the vocabulary-and-workflow companion.
What a DNI pool actually is — and what it is not
The voice-compliance alphabet soup puts four similar-sounding acronyms in one buyer's head. DNI is the odd one out: the other three live on the compliance plane, DNI lives on the attribution plane.
| Term | Full name | Plane | What it does |
|---|---|---|---|
| DNI | Dynamic Number Insertion | Attribution | Swaps the number a visitor sees so calls attribute to a source |
| DNC | Do-Not-Call | Compliance (recipient) | Filters destinations by recipient opt-out status |
| DNO | Do-Not-Originate | Compliance (origin) | Blocks caller IDs that must never originate a call |
| TRACED | Telephone Robocall Abuse Criminal Enforcement and Deterrence Act | Legal backdrop | US statute that mandates caller-ID authentication (STIR/SHAKEN) and empowers traceback |
The confusions that matter in practice: DNI has nothing to do with DNC suppression — a tracking pool does not exempt you from opt-out lists, and an opt-out list does not change which number your site renders. DNI is also not a DNO-style guard — it no more blocks spoofed caller IDs than a billboard does. And TRACED is the statute, not a feature name — the DNO explainer covers the TRACED-era origin-side controls if that is the thread you actually need. Everything below is strictly about the attribution plane.
A DNI pool is the unit the swap draws from: a named set of tracking DIDs bound to a marketing source, an optional campaign and medium, and match rules (UTM parameters, referrer substring, presence of a click id) that decide which visitors qualify. One pool per source is the classic fixed setup; pools that distinguish campaigns or keywords within a source are where the granularity comes from.
How Orbit binds a number to a session
The surface is Numbers > Call Tracking (/numbers/tracking-pools), and the per-pool choice that defines the binding is the swap strategy:
- Sticky — one number per visitor session. The resolver hashes a stable session key (an existing session or visitor id) deterministically onto one of the pool's DIDs, so the same visitor sees the same number across pageviews and return visits, and two visitors distribute across the pool. This is the strategy that separates campaigns or keywords within one source — the session-level binding survives the visit that converts.
- Fixed — one number per source. Every matching visitor sees the same DID. Cheaper on inventory, survives cookie loss entirely, and still answers "which channel" — just not "which campaign."
Match rules compose: the resolver requires every defined condition to hold (undefined means "don't care"), and when several pools match, the most specific one wins. A pool with no match rules at all is the catch-all; a requireGclid pool claims only click-carrying paid traffic.
The dashboard page builds a self-contained snippet from your enabled pools — the configuration travels inside the snippet, so the swap happens on the page with no API round trip, and any element carrying data-orbit-dni gets its text and tel: href swapped. You preview the resolution for a given UTM set in the dashboard before pasting. The endpoint-level contract (for teams that resolve server-side instead) is in the call tracking guide.
Tracking DIDs come from your own numbers inventory and are inbound-termination only — they receive calls; the pool never originates one. That is what keeps the pool's attribution ledger clean: every call on a tracking DID is, by construction, inbound demand.
Where the attribution is read — and how it extends to post-call analytics
Two surfaces carry the numbers:
- Inbound attribution — Insights > Attribution > Call attribution (
/insights/attribution) rolls inbound calls on tracking DIDs up by source and campaign. This is the paid-media manager's answer to "which spend made the phone ring." - Outcome attribution — a call that ends in a booked appointment, a quote, or a sale is a conversion, and conversions read through Outbound > Goals & attribution (
/outbound/goals: last touch, first touch, linear, or time decay per goal — the goals and route-preview walkthrough covers the model choice). Attach a value to the goal and call-tracking stops being a call count and becomes revenue attribution per source.
For the budget question — move spend from the source that rings and never converts to the one that does — the media-mix model consumes the attributed call data alongside SMS, email, and ads. The evaluation post for third-party DNI vendors is the call tracking alternatives guide; the short version is that Orbit's pools keep telephony, snippet, and attribution in one tenant, so no second vendor holds a partial copy of your call record.
Consent and quiet hours — what changes, and what does not
A tracking pool changes which number rings. It does not change how the call is treated, and the tenant-owned compliance controls you already configured keep their semantics:
- Recording and disclosure. Your existing recording announcements, disclosure prompts, and one-party/two-party handling apply to calls on tracking DIDs exactly as they do on your main line. Consent obligations follow your jurisdiction's recording rules, unchanged by which DID terminated the call.
- DNC and opt-outs. Any outbound follow-up the inbound call triggers — a scheduled callback, a follow-up SMS — still filters recipients against your DNC suppression lists. The inbound attribution layer and the outbound suppression layer stay separate by design.
- Quiet hours. Return calls and follow-up messages evaluate the same recipient-local send windows your organization configured — tenant-controlled, opt-in per channel, deferral rather than dropping. The send-time optimization explainer covers the recipient-local rule; the federal-vs-state window post covers how the overlays intersect for US traffic.
The principle to carry: DNI is an attribution mechanism. Every control you own on the compliance plane runs on the tracking-pool calls identically, because a tracking DID is a normal inbound number that happens to carry a source label.
When IVR or an AI voice agent routes the callback
Attribution binds to the called tracking DID and its pool — not to whichever flow answered. That is what makes the join survive routing: an inbound call to a tracking DID attributes to its source whether the resolver sent it to an IVR menu, an AI voice agent, a queue, or a human.
The two directions worth separating:
- Inbound resolved by an agent or IVR. The source attribution is already settled at the pool on the inbound leg. An AI agent resolving the call, or an IVR branching it to a queue, neither clears nor reassigns that attribution — the Call attribution report reads the pool's source regardless of the downstream path the call took.
- An outbound callback placed later. When an agent or AI voice agent calls the visitor back, that is an outbound leg and it attributes through goals, not through the pool. Pair the two and the loop closes: the pool tells you which source rang, the goal tells you which callback converted. The AI voice agent archetypes post covers where agent-led resolution fits next to IVR in the routing mix.
So the answer to "does my AI receptionist clear the attribution?" is no — attribution is a property of the number called, resolved once, and routing choices downstream operate on a call that already knows its source.
Frequently asked questions
What is dynamic number insertion (DNI)?
Dynamic Number Insertion is the attribution technique of showing different website visitors a different inbound phone number, chosen from a pool bound to a marketing source, so that inbound calls can be attributed back to that source. It is unrelated to Do-Not-Call (recipient opt-outs), Do-Not-Originate (caller-ID block lists), and the TRACED Act (the US anti-robocall statute).
Sticky or fixed — which swap strategy should I pick?
Sticky when you need to distinguish campaigns or keywords within one source — the per-session binding is where the granularity lives, and it scales with pool depth. Fixed when the channel-level answer is enough and you want the smallest number footprint. Pools with no match rules act as the catch-all for untagged traffic.
How big should a sticky pool be?
Big enough that simultaneous sessions rarely collide — a session whose number got reused between visits attributes correctly either way, but a deeper pool reduces the odds of a returning visitor drawing a different DID. Buy the extra DIDs in Numbers > Buy, or port your existing tracking numbers in Numbers > Porting if you are consolidating from a third-party DNI vendor.
Does an IVR or AI voice agent answering the call clear attribution?
No. Attribution binds to the called tracking DID and its pool at the moment of the inbound call. IVR branches, AI-agent resolution, queues, and human agents all operate downstream of that binding, so the source attribution survives routing. What an outbound callback adds later attributes separately, through goals.
The takeaway
DNI is a pool of your own numbers, a swap on the page, and an attribution read — everything else is the compliance plane running exactly as it already does. Name the acronyms correctly, pick sticky when you need campaign granularity, read inbound attribution in Insights and outcomes in Goals, and let IVR or AI agents route freely: the source label was settled at the pool before any of them answered.