A Practical Guide to Connecting Website Visits With Phone Calls

A phone call creates a harder break: once a visitor leaves the browser and dials, the connection between the website session and the conversation can disappear.

Dynamic number insertion, or DNI, is designed to preserve more of that connection. It changes the phone number shown on a website according to available source, campaign, context, or session data. When the visitor calls the inserted tracking number, a call-tracking platform can associate the call with that assignment and forward it to the business’s normal phone line.

Useful attribution requires more than installing a script. Teams must choose an appropriate tracking model, allocate sufficient phone numbers, replace every relevant number and phone link, verify routing, connect downstream systems, and account for missing or ambiguous attribution.

This guide explains how dynamic number insertion works, how source-level and session-level configurations differ, how to implement and test DNI, and what to evaluate before selecting a provider. The implementation frameworks are practical recommendations rather than universal standards. Product documentation is useful for understanding mechanics, but vendor claims should not be treated as independent proof of performance, compliance, or financial results.

What dynamic number insertion is—and what it is not

Dynamic number insertion is website code that replaces a default business phone number with a tracking number. The selected number can depend on information available when the page loads, such as the visitor’s traffic source, campaign parameters, referring site, landing page, or session.

The displayed number changes for attribution purposes, but the place where the call is answered does not necessarily change. Calls to tracking numbers can be forwarded to an existing office, contact center, branch, or other destination line while the call-tracking system logs the assignment and available acquisition data, as described in Twilio’s overview of dynamic number insertion.

Consider a company with one office number:

• A visitor arriving from paid search sees tracking number A.
• A visitor arriving from organic search sees tracking number B.
• Both visitors view the same service page.
• Calls to both tracking numbers are forwarded to the same office line.
• The platform associates the first call with paid search and the second with organic search.

DNI belongs to the broader category of call tracking, but the terms are not interchangeable. Call tracking can also use manually assigned or static numbers. A billboard might display one permanent tracking number while a direct-mail campaign displays another. No website script is required for those placements. Twilio uses DNI more broadly for unique phone numbers tied to advertisements, including billboards and television spots What is Dynamic Number Insertion (DNI)? | Twilio.

Number insertion does not inherently include:

• Call recording
• Conversation transcription
• AI scoring or summarization
• Lead qualification
• Skills-based or sales-rule routing
• Agent evaluation
• CRM opportunity matching
• Revenue attribution

A provider may package these capabilities with DNI, but they are separate product functions. The number swap determines which number appears. Forwarding determines where the call goes. Recording, analysis, routing, and CRM matching add other technical and governance layers.

DNI also creates an attribution association rather than proof of causation. It establishes that a tracking number was shown in connection with observed acquisition data and that a call later reached that number. It does not prove that one channel alone caused the call. The caller may have encountered several campaigns, changed devices, returned later, saved the number, or learned about the business elsewhere.

Nor does DNI guarantee coverage of every call. The script may not run, campaign parameters may be missing, the number pool may be exhausted, or the visitor may dial a number found outside the tracked website. Sound reporting therefore treats DNI as a way to increase the visibility of phone calls—not as an infallible record of why every caller acted.

How DNI works from page visit to attributed call

A typical DNI journey has several connected stages:

1. A visitor reaches the website. The visit may come from an advertisement, search result, email, social post, referring website, bookmark, or direct navigation.
2. The script reads available signals. These may include referrer data, UTM parameters, advertising click identifiers, URL tokens, landing-page information, or an existing session identifier.
3. The platform applies an attribution rule. It may select a number dedicated to a source or assign an available number from a rotating pool.
4. The page replaces the default number. Every configured display of that business number should change.
5. The phone link changes too. The tel: destination should match the number visible to the visitor.
6. The visitor calls the tracking number.
7. The tracking service forwards the call. The business answers at its configured destination.
8. A call record is created. The platform connects the call with the number assignment and the marketing information retained for it.
9. Selected events may be sent downstream. Depending on the setup, the call may create analytics, advertising, CRM, or reporting records.

CallRail documents a JavaScript-based process that detects source data, changes the displayed number, and may use a browser cookie to preserve the visitor’s assigned number across pages or visits in its explanation of DNI scripts and visitor tracking.

Attribution inputs

The inputs available to a DNI system depend on the provider, website, campaign configuration, browser environment, and connected advertising platforms. Common possibilities include:

• Referring domain or referrer category
• Source and medium
• UTM source, medium, campaign, term, and content
• Advertising click identifiers
• Landing page and entry path
• Campaign or ad-group fields
• Custom URL parameters or tokens
• Session identifiers
• Pages viewed during the visit
• Search keyword, when exposed by the relevant platform and configuration

Keyword attribution is conditional. A system may receive a paid-search keyword or related campaign field in some journeys but have no keyword information for an organic search, privacy-restricted visit, unsupported channel, or untagged campaign. “Supports keyword data” does not mean every call will contain a keyword.

Call and journey outputs

The resulting call record also varies by provider and integration. Representative fields may include:

• Traffic source and medium
• Campaign or ad group
• Landing page
• Referring domain
• Tracking number displayed
• Call date and time
• Call duration
• Caller ID, where available and enabled
• Pages visited
• Routing destination
• Answered, missed, or other call status

Some systems use cookies to maintain an assignment as a visitor moves between pages or returns within a defined period. Others use different session or identity methods. These choices affect continuity and resilience when browsers block or delete identifiers, so buyers should verify the provider’s actual method rather than assume all platforms behave alike.

Three layers should be tested separately:

1. Number insertion: Did the correct visible number and tel: link appear?
2. Call handling: Did the call route to the correct destination and produce a complete call record?
3. Downstream integration: Did the intended advertising, analytics, or CRM event arrive with the correct fields?

Successful forwarding does not guarantee that the CRM or advertising platform received a valid conversion event.

Source-level, session-level, and static tracking compared

The appropriate model depends on the reporting question. A team comparing broad channels does not necessarily need the same infrastructure as one analyzing individual paid-search sessions.

Model	Number assignment	Attribution granularity	Number demand	Typical use	Key limitation
Source-level DNI	One number for each configured source or channel	Channel or source level	Relatively low	Comparing paid search, organic search, email, referrals, or social	Cannot reliably identify individual concurrent visitors from the same source
Session-level DNI	A rotating-pool number is temporarily assigned to a visitor session	Session, visitor, campaign, ad, or keyword level when metadata is available	Higher	Granular digital campaign and visitor-journey analysis	Requires pool management and remains vulnerable to missing data, recycling, and cross-device gaps
Static tracking	A dedicated number remains fixed for a placement or campaign	Placement or campaign level	Fixed numbers for each tracked placement	Billboards, radio, television, print, direct mail, directories, and third-party profiles	Cannot dynamically distinguish website sessions without another tracking method

Source-level DNI

Source-level DNI generally assigns one number to each configured source or channel. Paid-search visitors might see one number, organic-search visitors another, and email visitors a third.

This model suits questions such as:

• How many tracked calls were associated with paid search?
• How did organic-search call activity compare with referrals?
• Which broad digital channels generated calls?

Because visitors from the same source share a number, the model requires fewer numbers than session-level tracking. Its weakness is granularity. If several paid-search visitors are active simultaneously and all see the same number, a later call can be associated with paid search but not necessarily with the correct visitor, ad, or landing-page journey.

Source-level tracking should therefore be reported as channel attribution, not individual-session attribution.

Session-level DNI

Session-level DNI temporarily assigns an available number to an eligible visitor session. While the assignment remains active, a call to that number can be associated with the session and its retained acquisition details.

This model can support reporting by visitor session, campaign, ad, landing page, and sometimes keyword. It is more number-intensive because simultaneous eligible sessions need distinct assignments for the platform to distinguish them. Nimbata’s comparison of source-based and session-based DNI similarly describes session tracking as more granular and more demanding of number inventory.

The business must also decide—or understand the provider’s rules for—how long each assignment remains reserved. Pool utilization, overflow, delayed callbacks, and number recycling become part of attribution quality.

Static tracking numbers

A static tracking number does not change according to website context. It stays attached to a defined placement or campaign.

Static numbers are useful for:

• Billboards and outdoor advertising
• Television and radio spots
• Print advertisements
• Direct mail
• Event materials
• Third-party directories or profiles
• Fixed campaign assets
• Environments where website JavaScript cannot run

Static numbers also provide consistency when every viewer should see the same number. Their attribution is tied to the placement rather than an individual viewer or web session.

The three models can be combined. A business might use session-level DNI for paid digital traffic, source-level DNI for broad website-channel reporting, and dedicated static numbers for direct mail, radio, or directory profiles. The best design is the least complex one that answers the organization’s actual reporting questions.

Number pools, recycling, and attribution risk

A number pool is an inventory of tracking numbers available for temporary assignment to visitors or sessions. Session-level DNI draws from this pool as eligible visitors arrive.

Pool demand depends primarily on:

• Peak concurrent eligible visitors
• The length of each reservation
• Inactivity rules
• Expected delay between viewing and calling
• Return-visit behavior
• Traffic spikes and campaign volatility
• The pages, sources, domains, or locations eligible for DNI

Total monthly traffic is not enough to size a pool. Pool pressure occurs when eligible sessions overlap, so peak concurrency is more useful than a monthly average.

How recycling works

After an assignment or inactivity window expires, the number can return to the pool and later be shown to another visitor. RingSquared, for example, documents a process in which a number returns to its DNI pool after a configured period, often connected to average visit length. Other providers may use different release rules.

The evidence does not establish a universal pool-size formula or universally safe recycling interval. Provider ratios and default settings may be reasonable starting points for a specific product, but they should not be treated as industry standards.

A practical planning framework is:

1. Define eligible traffic. Specify the websites, pages, locations, and sources that require session-level numbers.
2. Measure peak concurrency. Use traffic data at suitably short intervals rather than monthly totals.
3. Document reservation rules. Determine when assignments begin, extend, expire, and return to the pool.
4. Review callback patterns. Estimate how often visitors call immediately, after browsing, or much later.
5. Set a safety margin. Account for campaign launches, traffic spikes, and measurement uncertainty.
6. Monitor actual utilization. Adjust the pool using observed demand and attribution gaps.

Pool exhaustion and collisions

Pool exhaustion occurs when no unassigned number is available for a new eligible session. The result depends on the provider. Some products can add numbers automatically, but that behavior is platform-specific rather than universal.

A collision occurs when active visitors share a tracking number. If either visitor calls, the platform may be unable to determine which session produced the call. CallSource identifies insufficient pool capacity as a cause of ambiguous DNI attribution.

Delayed callbacks

Recycling creates another attribution risk. A visitor may:

• Save the number in a phone
• Write it down
• Copy it into a message
• Share it with someone else
• Leave a browser tab open
• Call after the original assignment has expired

If the number has already been assigned to another session, a delayed call may be linked to the later visitor. Shorter windows reduce inventory demand but can increase ambiguity.

Before choosing a provider, ask:

• Can the pool expand automatically?
• What happens when every number is assigned?
• How are reservation and inactivity windows configured?
• What is the fallback number?
• How are delayed calls represented?
• Are utilization and exhaustion alerts available?
• Can administrators inspect historical assignments?
• Who controls the tracking numbers?
• Can numbers be ported or retained after offboarding?

Define pool metrics before launch

Avoid reporting vaguely named metrics without a documented calculation. Useful definitions include:

• Peak pool utilization: Highest number of simultaneously assigned pool numbers divided by total available pool numbers during the reporting period.
• Exhaustion duration: Total time during which no unassigned number was available for an otherwise eligible session.
• Fallback rate: Eligible sessions shown a default or overflow number divided by all eligible sessions.
• Collision count: Confirmed instances in which one number was assigned to multiple active sessions, where the platform exposes that information.
• Delayed-callback count: Calls received after the original assignment window, if historical assignment data allows them to be identified.
• Ambiguous-call rate: Calls that cannot be connected to one interpretable assignment divided by all calls received through pooled numbers.

Record the underlying data source for every metric. A pool dashboard, browser test log, call-platform record, and destination-line log measure different parts of the system.

How to implement and test dynamic number insertion

A controlled rollout is safer than deploying a script across the entire site and waiting for calls.

1. Document the current phone setup

Create an inventory of:

• Every public business number
• The destination associated with each number
• Departments, branches, franchises, and locations
• Operating hours and after-hours routing
• Existing static tracking numbers
• Numbers that must never be replaced
• Pages requiring a specific local or departmental number

This prevents broad replacement rules from swapping the wrong number or sending callers to an inappropriate destination.

2. Choose the tracking model

Start with the reporting questions:

• Is channel-level attribution sufficient?
• Is session-, campaign-, or ad-level detail required?
• Which traffic qualifies for pooled numbers?
• Which offline placements need fixed numbers?
• Are multiple domains or locations involved?

Do not select session-level DNI solely because it produces more fields. Greater granularity adds pool-management, testing, and maintenance requirements.

3. Define attribution rules

Document how the system should classify paid search, organic search, email, referral, social, direct, affiliate, and custom campaigns. Establish UTM conventions and decide what happens when signals conflict or disappear during redirects.

Define the reporting model as well. Will reports use first touch, last touch, the current session, or another rule? DNI cannot resolve attribution disagreements if the organization has not established how credit should be assigned.

4. Provision numbers and configure forwarding

Obtain the required tracking numbers, map them to their destinations, and verify inbound routing. Include location-specific, department-specific, after-hours, failover, and overflow scenarios.

Providers may require separate configurations for different websites, domains, companies, or locations. ServiceTitan’s product documentation, for example, describes a configuration for each website and supports multiple location configurations on one page. Other platforms should be assessed against their own documentation.

5. Identify every swap target

A swap target is the default number or markup pattern that the script is configured to replace. Audit every place the business number appears:

• Desktop and mobile navigation
• Headers and footers
• Contact pages
• Landing-page templates
• Sticky mobile call controls
• Pop-ups and banners
• Location finders
• Dynamically rendered components
• Embedded widgets
• Buttons with hidden phone links
• Structured click-to-call elements
• Numbers repeated inside body copy

Incomplete coverage creates inconsistent numbers and missing attribution. Record approved exclusions so testers can distinguish an intentional static number from a failed swap.

6. Install the script

Common installation methods include:

• Adding JavaScript to the global website template
• Deploying it through a tag manager
• Using a provider-supported CMS plugin

Choose the method that fits the website’s release and testing processes. A tag manager introduces trigger, container, environment, and publishing dependencies. A plugin may simplify installation but still requires testing across templates, themes, and updates.

7. Replace visible numbers and phone links

The number displayed in text and the destination of the clickable link must agree. A button that displays one number but dials another creates a poor user experience and can undermine attribution.

Test:

• Raw and formatted phone numbers
• Country codes
• Extensions
• Numbers contained in icons or buttons
• Mobile menus
• Sticky call controls
• Components loaded after the initial page
• Single-page application route changes
• Cached page fragments

8. Connect downstream systems

Configure only the integrations required for the reporting chain, such as:

• Advertising platforms
• Web analytics
• CRM systems
• Marketing automation
• Business-intelligence tools
• Data warehouses
• Booking or lead-management systems

Map fields explicitly. Decide how call records will be matched to existing contacts, leads, opportunities, bookings, or customers. Define deduplication rules before sending the same call to several systems.

9. Run a prelaunch test matrix

Create tagged URLs for every intended source and campaign scenario. Use cleared cookies or private browsing for clean-session tests, while recognizing that private mode does not perfectly reproduce ordinary returning-user behavior.

Cover:

• Paid, organic, referral, email, social, and direct visits
• Tagged and untagged URLs
• Desktop and mobile layouts
• Supported browsers
• Multiple locations
• Returning visits
• Simultaneous sessions
• Delayed callbacks
• Dynamically rendered content
• Each configured consent state, if the site uses consent controls

For every scenario, verify:

1. Visible phone number
2. tel: destination
3. Call-routing destination
4. Source, medium, and campaign fields
5. Call-platform record
6. Advertising conversion event, if configured
7. Analytics event
8. CRM record
9. Deduplication behavior
10. Timestamps and time zones

10. Monitor after launch

Postlaunch monitoring should cover script execution, swap coverage, phone-link consistency, routing failures, pool capacity, unmatched calls, duplicate events, integration delays, and differences among systems.

Define the principal measurements precisely:

• Swap success rate: Eligible test page views in which both the visible number and tel: link changed correctly, divided by all eligible tested page views.
• Routing success rate: Completed test calls reaching the intended destination, divided by all completed test calls to active tracking numbers.
• Tracked-call coverage: Destination-line calls expected to originate through tracked website numbers that have a matching call-platform record, divided by all such eligible destination-line calls. Document how eligibility is determined.
• Campaign-data completeness: Tracked website calls containing the required source or campaign fields, divided by all tracked website calls.
• CRM match rate: Tracked calls matched to the intended CRM entity, divided by all tracked calls eligible for CRM matching.
• Reconciliation gap: The numeric and percentage difference between records in two named systems for the same time range, time zone, and eligibility rules.

Create a fallback plan for pages where the script cannot run. That may mean displaying the default business number, using a static tracking number, or excluding the page from session-level reporting. Test the provider’s actual behavior rather than assuming a fallback exists.

Using DNI data in advertising, analytics, and CRM reporting

A call record becomes more useful when it can be connected to the rest of the customer journey:

Source or campaign → website session → phone call → qualified lead → booking or opportunity → revenue

Each arrow represents a separate data and identity problem. DNI primarily helps connect the website session with the call. It does not automatically create the later relationships.

Practical uses of attributed-call data include:

• Comparing tracked call volume by channel or campaign
• Comparing qualified call outcomes rather than all calls
• Identifying landing pages frequently associated with calls
• Finding campaigns that produce calls but few qualified outcomes
• Reviewing missed-call rates by source or location
• Reconciling advertising conversion events with CRM leads
• Comparing bookings or opportunities associated with call-generating campaigns
• Investigating differences between form and phone lead patterns

The distinction between activity metrics and business outcomes is essential. Call count and duration indicate activity, not lead quality. A long call might be a sales conversation, support request, complaint, or wrong number. An answered call is not automatically a booking, opportunity, or sale.

Recording, transcription, conversation intelligence, outcome scoring, and revenue matching can help classify calls, but they require additional product capabilities and governance decisions. Keep them separate from the core question of whether the right number was displayed, routed, and logged.

Do not assume connected dashboards will match. Reconcile call-platform records against:

• Carrier or destination-line logs
• Advertising conversion events
• Analytics events
• CRM contacts and leads
• Bookings or appointments
• Opportunities and closed revenue

Differences may arise from time-zone settings, processing delays, duplicate suppression, attribution windows, call-duration thresholds, blocked scripts, field mapping, or CRM matching rules.

A useful reporting view combines coverage and outcomes:

• What proportion of eligible destination-line calls has a tracking record?
• What proportion of tracked website calls contains the required campaign data?
• What proportion becomes a qualified lead?
• What proportion can be matched to a CRM outcome?
• At which connection point is the largest reconciliation gap?

DNI data can inform campaign and budget discussions, but the available evidence does not establish that installing DNI inherently improves conversion rates, lead quality, revenue, or return on investment. Better attribution may reveal that previous reporting was incomplete or misallocated without changing the campaign’s underlying performance.

Attribution limitations, privacy, and troubleshooting

DNI attribution depends on a chain of conditions:

1. The script runs.
2. It reads usable attribution signals.
3. The correct rule is applied.
4. An appropriate number is available.
5. Relevant numbers and phone links are replaced.
6. The visitor calls the inserted number.
7. The assignment remains interpretable when the call arrives.
8. The call routes and logs correctly.
9. Required fields survive downstream integrations.

A failure at any stage can reduce coverage or create misleading associations.

Common attribution gaps

Potential failure scenarios include:

• Blocked, delayed, or failed JavaScript
• Incorrect tag-manager triggers
• Unpublished or outdated containers
• Consent settings that prevent execution
• Ad blockers or browser restrictions
• Missing or malformed UTM parameters
• Advertising click identifiers removed during redirects
• Cookie expiration, deletion, or rejection
• Browser or device changes
• VPN use
• Cross-device journeys
• Numbers rendered after the DNI script runs
• Unsupported embedded frames or widgets
• Insufficient pool capacity
• Numbers recycled before a delayed callback
• Incorrect forwarding
• Analytics or CRM integration failures

CallSource’s discussion of cookie-based DNI notes that browser changes, device changes, cookie blocking, and VPN use can interfere with continuity. Claims of proprietary cross-device or cookieless identification should be assessed as product-specific capabilities rather than assumed across the market.

The limitations are easier to understand through examples:

• A buyer discovers the business through an ad on a work laptop but later finds and calls the number on a personal phone. The original session and call may not connect.
• A visitor arrives through a campaign, returns directly several days later, and calls. The result depends on identifier persistence and the organization’s attribution rules.
• A visitor saves a tracking number and calls after it has been reassigned. The call may be associated with a later session.
• An organic-search visitor provides no usable keyword data. The call may still be associated with organic search without a keyword.

Troubleshooting matrix

Symptom	What to check
Number never changes	Script loading, consent state, tag-manager trigger, domain configuration, swap-target format, dynamic rendering
Number changes on some pages only	Template coverage, single-page application events, page-specific scripts, embedded components
Visible and dialed numbers differ	tel: replacement, button markup, mobile navigation, cached components
Wrong campaign appears	UTM values, click identifiers, redirects, attribution priority, persistence rules
Call reaches the wrong destination	Number-to-destination mapping, location rules, forwarding, after-hours routing
Call exists but analytics event is missing	Integration credentials, event rules, thresholds, account mapping, processing delay
CRM record is absent or duplicated	Field mapping, identity matching, deduplication, webhook or API errors
Calls are ambiguous	Pool capacity, concurrent assignments, recycling window, delayed callbacks
Call-platform and advertising reports differ	Attribution windows, time zones, filters, duplicate rules, eligible-call definitions
Direct traffic appears unusually high	Lost parameters, redirects, identifier loss, return visits, classification rules

Privacy and governance review

Depending on the configuration, a DNI system may process cookies or similar identifiers, session and click identifiers, IP addresses, referrer information, browsing activity, caller metadata, recordings, transcripts, lead classifications, or CRM identities.

Treat privacy and governance as a documented review rather than assuming that a platform’s default configuration answers every organizational requirement. Ask:

• Which data elements are collected?
• Which are necessary for the intended attribution model?
• Which identifiers are stored in the browser?
• Which vendors and subprocessors receive data?
• Where is information stored?
• How long is each data category retained?
• Which roles can access call and journey data?
• Can recordings and transcripts be disabled?
• Can records be exported, corrected, or deleted?
• Are access logs and administrative audit trails available?
• What happens to data and tracking numbers during offboarding?
• What disclosures or consent controls should the organization use?

This guide does not determine which legal rules apply to a specific implementation. Obtain advice from qualified legal, privacy, security, procurement, and accessibility professionals before collecting sensitive information, recording calls, or deploying tracking across jurisdictions.

How to choose a DNI provider

Provider selection should begin with operational requirements, not a generic feature count.

Core DNI scorecard

Area	Questions to ask
Tracking models	Does the provider offer source-level, session-level, and static tracking where required?
Attribution inputs	Which referrers, UTMs, click IDs, URL tokens, campaign fields, and session signals are supported?
Number pools	How are pools provisioned, monitored, expanded, and reduced?
Recycling	When is a number released, and how are delayed callbacks represented?
Overflow	What happens when every number is assigned?
Forwarding	Which routing, failover, after-hours, and diagnostic controls are available?
Number availability	Are the required local, national, toll-free, or other number types available?
Multiple properties	Can the platform support the required domains, companies, brands, and locations?
Number control	Who controls the numbers, and what happens to them during offboarding?

Technical implementation

Ask how the platform handles:

• The organization’s actual CMS and tag manager
• Single-page applications
• Dynamically rendered content
• Multiple business numbers on one page
• Location-specific swaps
• Visible-text and tel: replacement
• Consent-management tools
• Script diagnostics
• Staging environments
• Testing utilities
• Script failure and fallback behavior
• Caching and content-delivery systems
• Implementation documentation and support

Request a demonstration using a page structure similar to the real website. A clean demonstration page does not establish compatibility with sticky controls, third-party widgets, location finders, or custom front-end components.

Relevant integrations

Evaluate integrations with the systems the business actually uses. A large directory of logos matters less than reliable support for the required advertising accounts, analytics properties, CRM objects, booking systems, and reporting tools.

Confirm:

• Which fields are sent
• Whether data moves in one or both directions
• Expected event latency
• Retry behavior
• Error visibility
• Deduplication controls
• API and webhook access
• Export formats
• Historical backfill options

Data governance

Document the provider’s handling of:

• Browser and session identifiers
• Caller metadata
• Recording and transcription controls
• Consent-support features
• Retention settings
• Role-based permissions
• Deletion and export processes
• Data-storage locations
• Subprocessors
• Security and incident processes
• Offboarding procedures

Treat broad labels such as “privacy friendly” or “compliant” as prompts for further review, not substitutes for configuration details and contractual documentation.

Core requirements versus optional intelligence

Keep number insertion and forwarding distinct from optional functions such as:

• Call recording
• Transcription
• AI summaries
• Sentiment or outcome scoring
• Lead qualification
• Advanced routing
• Agent evaluation
• CRM revenue matching

This separation prevents buyers from assuming that a basic DNI product includes every call-intelligence function—or selecting an extensive suite when dependable number attribution is the immediate requirement.

Total-cost checklist

Rather than assuming a typical price pattern, request current documentation for every cost component that may apply:

• Platform access
• Tracking-number rental
• Inbound call usage
• Pool expansion
• Premium number types
• Recording or transcription usage
• Integration tiers
• Implementation work
• QA and ongoing maintenance
• Support levels
• Data exports
• Number porting and offboarding

Ask vendors to model cost under ordinary traffic, peak concurrency, campaign spikes, longer reservation windows, and multi-location growth.

Request operational evidence as well:

• Routing-availability commitments
• Event-latency expectations
• Support response targets
• Pool-utilization reporting
• Error and escalation processes
• Export formats
• Number ownership terms
• A documented acceptance-test plan

Vendor-reported ROI, conversion, or customer-acquisition results should not be treated as proof that another implementation will produce the same outcome.

Conclusion

The practical decision framework is straightforward:

• Use static tracking numbers for fixed or offline placements.
• Use source-level DNI when channel-level attribution is sufficient.
• Use session-level DNI when greater granularity justifies higher number demand and additional operational complexity.

Whichever model you choose, success depends on verified number swapping and routing, sufficient pool capacity, reconciled analytics and CRM records, clearly defined metrics, and appropriate governance controls.

DNI can make inbound calls more visible within marketing reporting. It should be evaluated by attribution coverage, data completeness, and operational reliability—not promises of perfect tracking or guaranteed financial results.

Frequently asked questions

Does dynamic number insertion change where calls are answered?

Not necessarily. The number shown on the website changes, but calls to that tracking number can be forwarded to an existing office, branch, contact center, or other destination.

Test routing for every tracking number, location, department, failover path, and after-hours scenario before launch.

How many phone numbers does a DNI pool need?

There is no universal number. Size the pool according to peak concurrent eligible visitors, assignment duration, expected callback delay, traffic volatility, and a documented safety margin. Monitor utilization, exhaustion, fallback behavior, and ambiguous calls after launch.

Source-level DNI generally needs fewer numbers because visitors from a configured source can share one number. Session-level DNI needs more because simultaneous sessions require distinct assignments for granular attribution.

What is the difference between DNI and a static tracking number?

A static tracking number remains fixed for a placement or campaign. It is suitable for direct mail, billboards, radio, television, directories, and other environments where website code cannot run.

DNI uses website code to select and insert a number according to source, campaign, context, or session data. It can provide more detailed website-call attribution, but it requires script coverage, testing, and—in session-level configurations—number-pool management.

Can dynamic number insertion track keywords and Google Ads calls?

It can associate some calls with Google Ads campaign information and keywords when the required click data, integration, and configuration are available. Patient Prism’s Google Ads call-tracking documentation, for example, makes conversion reporting conditional on the call coming from a Google Ad and being known to Google.

Keyword-level attribution is not universal. Missing click identifiers, redirects, unsupported channels, privacy restrictions, integration errors, or absent keyword data may leave a call with only campaign- or source-level attribution.

Does dynamic number insertion provide perfectly accurate attribution?

No. DNI associates a call with the number assignment and acquisition data observed by the system. Failed scripts, missing parameters, identifier restrictions, cross-device behavior, return visits, insufficient pools, delayed callbacks, number sharing, and integration failures can all reduce or distort attribution.

Report coverage and reconciliation gaps alongside call totals. Treat a matched call as an informed association, not unquestionable proof that one channel caused it.