Quick answer: When a prospect calls instead of filling in the form, most analytics stacks lose the thread — the ad platform claims the click, the CRM owns the call, and neither can name the other. Call tracking closes that gap with Dynamic Number Insertion (DNI): a pool of tracking numbers, a snippet that swaps the number a visitor sees based on where they came from, and attribution that ties the inbound call back to its source. Devotel Orbit ships this as Numbers > Call Tracking (/numbers/tracking-pools), and the results land in Insights > Attribution > Call attribution. Because the tracking numbers are your own DIDs terminating on Orbit, there is no second vendor holding your call data — tracking, telephony, and attribution live in one tenant.
Why "just use a static number" breaks attribution
A single number on every page tells you calls happened, not what made them happen. The standard workaround — one fixed number per source — is a fixed pool: "Google Ads" DNI, "Microsoft Ads" DNI, one DID each. It survives cookie loss and ad blockers, but it burns numbers and still cannot tell one campaign from the next, only one channel from the next.
The classic third-party answer is a DNI provider (the CallRail / Invoca category): their numbers, their snippet, their attribution reports. That solves the mechanics but splits your call record across two systems and routes your customers' voice through someone else's network.
Orbit's version is a fixed pool done properly, plus dynamic pools when you need per-campaign granularity — with telephony, snippet, and attribution inside the platform that already owns your numbers.
What Orbit ships: Numbers > Call Tracking
The surface is Numbers > Call Tracking (/numbers/tracking-pools). Each pool binds a set of tracking DIDs from your inventory to a marketing source:
- Fixed pool — one number per source. The snippet always shows the same number when the UTM or referrer matches. Simple, no per-visitor logic.
- Dynamic pool — the pool rotates through its tracking numbers for matching visitors, which is what lets you separate campaigns or keywords within a single source.
A pool carries a label, a source (such as google, microsoft, or a partner name), and match rules — UTM parameters and/or referrer. You enable it, and the numbers in the pool start attributing.
The DNI snippet
The page builds a self-contained snippet from your enabled pools. Paste it on the marketing page; it reads the visitor's UTM parameters and referrer, finds the first pool whose match rules fit, and swaps the displayed phone number in-place. Because the pool configuration travels inside the snippet, it works without a server call — the same behavior you can preview in the dashboard before pasting.
Attribution: Insights > Attribution > Call attribution
Inbound calls to tracking DIDs are attributed back to their pool's source. The Insights > Attribution (/insights/attribution) surface carries a Call attribution tab, backed by GET /insights/call-attribution, so the paid-ad manager's question — "which source sent us calling customers?" — is answered without exporting call logs to a spreadsheet.
This complements the touch-level attribution models on the same surface and the budget-level view in Insights > Media mix model (/insights/media-mix-model), which answers the allocation question across SMS, email, ads, and — now — tracked inbound calls. See the media-mix modeling walkthrough for where each model fits.
Example: separating two search campaigns
A home-services company runs two Google Ads campaigns — "emergency repair" and "install estimate" — landing on the same site:
- Create two dynamic pools — each bound to source
google, one matchingutm_campaign=emergency, the otherutm_campaign=estimate. - Paste the snippet on the landing pages once; it renders the right pool's number per visitor.
- Read the split in the Call attribution tab — emergency repairs dominate call volume, estimates dominate call value. The ad platform's click report never shows this; the phone was the conversion.
- Reallocate budget with the media-mix model once enough call-attributed revenue accumulates.
Numbers inventory notes
Tracking DIDs come from your existing Numbers inventory, and are inbound-termination only, consistent with how Orbit handles inbound voice generally. Buy extras in Numbers > Buy if a dynamic pool needs more rotation depth; port existing tracking numbers via Numbers > Porting if you are leaving a third-party DNI vendor and want to keep the printed numbers. The carrier-of-record explainer covers how buying and porting DIDs works on Orbit.
Frequently asked questions
Do I need cookies for the snippet to work?
No. The snippet reads UTM parameters and the referrer from the page URL — both survive cookie consent declines and browser storage partitioning. A fixed pool works even when the visitor's browser strips everything, because the match already happened server-of-page.
What if a visitor calls a tracking number days later?
That is the offline-attribution gap every DNI approach shares: a saved number decouples the call from the session. Fixed pools handle this best, since the static mapping still names the source. Keep pools narrow enough that the source channel alone answers your budget question.
Can I use call tracking numbers for outbound?
Tracking pools are inbound-only — that is where attribution applies. Outbound provenance is a separate discipline (campaign goals, STIR/SHAKEN attestation), covered in the outbound goals and attribution walkthrough.
Is this compliant with call-recording and consent rules?
Call tracking changes which number rings, not how the call is handled — your existing recording, disclosure, and routing configuration applies unchanged. Consent obligations follow your jurisdiction's recording rules as they already do on Orbit.