How to Calculate the Right Number Pool Size for Dynamic Call Tracking

This guide explains how to calculate the number of phone numbers required for a dynamic call-tracking pool using Google Analytics 4 data. It compares daily-traffic estimates, peak-hour rules, session-duration formulas, realtime checks, and minute-level concurrency analysis, then shows how to balance monthly number costs against the risk of incorrect call attribution.

Practical default: size the pool from peak eligible session arrivals and the call-tracking platform’s effective number-hold time, then choose a capacity near the historical p99 or p99.5 of concurrent assignments. Treat daily visitors and simple peak-hour divisors as initial estimates, not as accuracy guarantees.

Executive summary

A dynamic number pool does not need one phone number for every visitor received during a day. It needs enough numbers for the visitors whose tracking assignments overlap at the same time. The correct capacity variable is therefore peak concurrent number assignments, not daily users, daily sessions, or calls per day.

This distinction explains why common calculators can return very different answers. CallTrackingMetrics can recommend a pool from an estimated daily visitor count and a target likelihood score, while CallRail recommends dividing peak hourly visitors by four. Nimbata uses peak hourly visitors, average session duration, and a 1.3 buffer. Delacon describes concurrency as the underlying requirement: for the highest attribution accuracy, each concurrent visitor needs a different number. These methods are not necessarily contradictory. They encode different assumptions about traffic concentration, session length, number recycling, and acceptable overflow risk.

The strongest GA4-based method is:

1. Limit the analysis to traffic that will actually receive dynamic numbers.
2. Measure session starts at the smallest practical time interval, ideally one minute.
3. Determine how long the call-tracking provider keeps a number assigned after a visitor arrives or becomes inactive.
4. Reconstruct the number of overlapping assignments for every minute.
5. Select a percentile that matches the business risk, normally p99, p99.5, or a higher level for expensive lead-generation campaigns.
6. Validate the result after launch using the provider’s pool-assignment, reuse, or overflow reports.

When only standard GA4 reports are available, peak hourly sessions multiplied by average session duration is a defensible starting point. However, a fixed percentage buffer does not guarantee a fixed accuracy level. Bursty campaigns, long sessions, delayed calls, provider-specific assignment windows, consent gaps, and sampling can all create additional error.

What a dynamic number pool must cover

Visitor-level dynamic number insertion assigns a temporary tracking number to a website visitor and links that number to the visitor’s source, campaign, landing page, and browsing session. When the assignment expires, the number is recycled for another visitor. WhatConverts describes this sequence directly: a number is assigned to a visitor session and returned to the pool after the session expires. CallRail and Nimbata also warn that when two visitors see the same number at the same time, their histories can be combined or a call can be attributed to the wrong source.

The pool is exhausted when all numbers are already assigned and another eligible visitor arrives. What happens next depends on the platform. It may reuse a number, show a fallback business number, reduce visitor-level detail, or mark the assignment as lower confidence. Calls can still route correctly while attribution becomes ambiguous, so pool exhaustion is mainly a measurement-quality problem, not necessarily a telephony failure.

The practical capacity relationship is a form of Little’s Law: the average number of occupied resources equals the arrival rate multiplied by the average time each resource remains occupied. Applied to call tracking:

Expected occupied numbers = eligible session arrival rate × effective number-hold time

This gives an average, not a safe maximum. Real traffic varies from minute to minute, so the final pool also needs a margin for random variation and campaign spikes.

Why daily visitors are not enough

A daily total contains no information about when visitors arrived. Two websites can each receive 1,200 eligible sessions per day but require very different pools:

• A service website receiving traffic steadily across 12 business hours may have about 120 sessions in its busiest hour.
• A campaign landing page receiving a large email, television, social, or paid-search spike may have 360 sessions in its busiest hour.

If numbers remain occupied for 15 minutes, the expected peak occupancy is approximately 30 numbers in the first case and 90 in the second. Under a simple Poisson-arrival model, a pool designed for roughly 99% instantaneous coverage would be about 43 numbers for the smoother site and about 113 for the spiky site. The same daily traffic therefore produces a pool requirement more than 2.5 times larger.

A daily-visitor calculator can still be useful when it has been calibrated from many similar accounts and asks for an accuracy target. CallTrackingMetrics, for example, calculates a recommended pool from estimated daily visitors and offers an automatic configuration intended to achieve 99% likelihood. However, the public documentation does not expose the complete statistical model. A daily estimate should therefore be treated as a vendor recommendation to validate, not as a transparent universal formula.

Comparison of pool-sizing methods

Method	Data required	Hidden assumption	Likely error	Best use
Daily visitors or sessions	Eligible daily traffic	Traffic follows a typical hourly distribution and the platform assumes a typical assignment duration.	Can materially under-size bursty sites or over-size sites with long operating hours and smooth traffic. The error cannot be calculated from the daily total alone.	Early budgeting when no hourly data or existing pool telemetry is available.
Peak hourly sessions divided by four	Maximum sessions in one hour	The effective assignment window is approximately 15 minutes and the hourly peak is internally smooth.	Overestimates short assignments and severely underestimates long assignments or sharp within-hour bursts.	Fast CallRail-style estimate for ordinary sites with a similar assignment pattern.
Peak hourly sessions × average duration × buffer	Peak-hour sessions and average session duration	The average duration represents the platform’s actual number-hold time and a fixed buffer covers variance.	Better than a fixed divisor, but averages hide long tails and a 1.3 multiplier does not equal 99% coverage in every traffic range.	Best standard-GA4 method when minute-level or provider data is unavailable.
GA4 Realtime active users	Active users in the last 30 minutes	A rolling 30-minute unique-user count approximates simultaneous assignments.	Not a true historical concurrency metric; can overstate short visits and cannot reveal previous seasonal peaks without continuous collection.	Live sanity checks during campaign launches or sudden traffic events.
Minute-level reconstructed concurrency	Session starts and assignment duration, preferably from GA4 BigQuery export	The reconstructed hold window matches the call-tracking platform’s real assignment logic.	Lowest planning error, but still affected by consent, ad blockers, missing events, multiple tabs, and provider-specific behavior.	Production sizing for paid media, high-value leads, and larger pools.
Provider assignment or overflow telemetry	Actual number assignments, reuse, fallback, or pool-exhaustion logs	The provider exposes reliable operational data.	Lowest post-launch error because it measures the resource that is actually being sized.	Final calibration after the first two to four representative weeks.

Method 1: peak hourly sessions divided by four

CallRail’s published rule is straightforward:

Pool size = peak hourly visitors ÷ 4

The rule is convenient because it needs only one GA4 metric. It is also easy to interpret: dividing one hour by four implicitly assumes that a tracking number is occupied for approximately 15 minutes.

That assumption can be reasonable for many lead-generation sites, but it is not universal. Consider a peak of 120 eligible sessions per hour:

Effective hold time	Expected occupied numbers	Approximate p99 capacity	Peak-hour ÷ 4 result	Direction of error
5 minutes	10	18	30	About 67% above the modeled p99 requirement.
15 minutes	30	43	30	About 30% below the modeled p99 requirement.
30 minutes	60	79	30	About 62% below the modeled p99 requirement.

The modeled values assume independent arrivals distributed approximately as a Poisson process. Real advertising traffic can be more concentrated, so the table is an illustration rather than a guarantee. Its purpose is to show that the divisor is really a hidden duration assumption.

Method 2: duration-adjusted GA4 formula

Nimbata publishes a more explicit formula using peak hourly visitors, average session duration, and a 30% buffer:

Pool size = [peak hourly sessions ÷ (60 ÷ average session duration in minutes)] × 1.3

The same formula can be written more simply:

Pool size = peak hourly sessions × average session duration ÷ 60 × 1.3

This is usually a better starting point than a fixed hourly divisor because it adapts to the site’s measured duration. For 200 peak-hour sessions and a three-minute average session, the formula returns 13 numbers.

However, the average GA4 session duration may not equal the platform’s effective number-hold time. A provider may keep the assignment after the last observed interaction, use its own session timeout, persist the visitor-number relationship across a return visit, or use a separate match period. Telmetrics, for example, distinguishes a match period that controls how long a call can be associated with the displayed number. The implementation should therefore use the provider’s assignment behavior whenever it is available.

A fixed 1.3 safety factor also does not produce a fixed 99% confidence level. If expected occupancy is 30, multiplying by 1.3 gives 39 numbers; under the simple Poisson model, the probability of demand exceeding 39 is still about 4.6%. When expected occupancy is 60, the same multiplier gives 78 numbers and the modeled exceedance probability is approximately 1.1%. The same percentage buffer behaves differently at different traffic volumes.

Method 3: percentile-based concurrency

The most defensible method is to calculate how many assignments would overlap in every minute and then select a percentile. Instead of asking how many visitors arrived in an hour, it asks the capacity question directly:

Recommended pool = selected percentile of concurrent eligible assignments + operational reserve

The percentile should reflect the cost of measurement failure:

Planning level	Interpretation	Suitable context
p99	The pool covers 99% of observed minute-level concurrency values in the analysis period.	Cost-sensitive reporting where occasional lower-confidence attribution is acceptable.
p99.5	The pool covers 99.5% of observed minute-level concurrency values.	A practical default for paid-search and multi-channel optimization.
p99.9 or observed maximum plus reserve	Very little historical overflow is accepted.	High-value calls, small data volumes, automated bidding, legal, healthcare, finance, or other cases where a few wrong conversions can distort decisions.

These are planning policies, not universal industry standards. A site with predictable organic traffic may accept a lower reserve than a site where television spots, newsletters, influencer posts, or automated campaign budget changes create sudden bursts.

How to calculate a pool in GA4

Step 1: define eligible traffic

Do not size an all-traffic pool from all website sessions if the DNI rule only swaps numbers for paid search, selected countries, specific locations, or a subset of landing pages. The analysis segment must match the tracking rule.

Typical filters include:

• Session default channel group or Session source / medium;
• landing page or page path;
• hostname or web data stream;
• country, region, or location-specific site section;
• device category if the implementation swaps only click-to-call experiences;
• campaign parameters such as gclid, wbraid, gbraid, msclkid, or selected utm_* values.

Also remove internal traffic and obvious implementation-test sessions. Consent-denied visitors and users who block analytics may still receive a number depending on how the call-tracking script is deployed, so GA4 can undercount the population that consumes pool capacity. Compare GA4 sessions with server, CDN, landing-page, or call-tracking script-load data where consent loss is material.

Step 2: find the peak hour in GA4 Explorations

For a standard-report estimate:

1. Open Explore and create a blank exploration.
2. Add Date + hour as a dimension.
3. Add Sessions and Average session duration as metrics.
4. Apply the same segment or filters used by the DNI pool.
5. Use a table or hourly line chart and sort by Sessions descending.
6. Review at least 28 to 90 representative days and include known seasonal peaks, promotions, campaign launches, and high-spend days.

Google defines Sessions as sessions that began on the site or app and Average session duration as the average duration of users’ sessions. These metrics are suitable for the duration-adjusted estimate. Do not substitute Average engagement time per session; engagement time measures foreground or focused interaction and is not the same as the time a number may remain reserved.

Step 3: identify the effective number-hold time

Ask the call-tracking provider what releases a number back into the pool:

• the visitor closing or leaving the site;
• a fixed inactivity timeout;
• the end of a provider-defined session;
• the last page interaction plus a grace period;
• a cookie-based return-visitor window;
• a separate post-visit call-match period.

The capacity calculation should use the interval during which the number is unavailable to another visitor, not merely the visible time on page. If that information is not documented, use a conservative estimate and validate it with assignment telemetry after launch.

Step 4: calculate the initial pool

For an accessible GA4-only estimate:

Mean peak occupancy = peak hourly eligible sessions × effective hold minutes ÷ 60

Then add a statistical and operational reserve. A simple percentage buffer is acceptable for a first deployment, but a percentile model is more consistent:

Initial pool = Poisson or empirical concurrency quantile for the chosen coverage target + 1–2 operational reserve numbers

The reserve protects against reporting delay, a campaign that exceeds the historical range, or a number temporarily removed from service. Larger pools may use a percentage reserve instead of one or two fixed numbers.

Step 5: do not use GA4 Realtime as the final answer

GA4’s Realtime report shows active users in the last 30 minutes and a per-minute view over that rolling period. It is useful for watching a launch, but it is not the same as the number of visitors simultaneously holding tracking numbers. A user active at the beginning of the 30-minute window and another active near the end can both appear in the count even though their sessions never overlapped.

Realtime also has no built-in historical peak distribution. To use it for planning, the data would need to be collected continuously through the Realtime Data API and aligned with the provider’s assignment duration. For most implementations, historical session starts plus a modeled hold window are easier to audit.

Advanced method: reconstruct concurrency from GA4 BigQuery export

Google allows GA4 properties to export raw events to BigQuery. This makes it possible to reconstruct approximate session intervals from user_pseudo_id, ga_session_id, and event_timestamp. The following query estimates the number of overlapping web sessions for every minute. Replace the project, dataset, dates, and post-event hold period.

DECLARE post_last_event_hold_minutes INT64 DEFAULT 5;

WITH sessions AS (
  SELECT
    CONCAT(
      user_pseudo_id,
      '-',
      CAST(
        (SELECT value.int_value
         FROM UNNEST(event_params)
         WHERE key = 'ga_session_id') AS STRING
      )
    ) AS session_key,
    TIMESTAMP_MICROS(MIN(event_timestamp)) AS session_start,
    TIMESTAMP_MICROS(MAX(event_timestamp)) AS last_event
  FROM `project_id.analytics_property_id.events_*`
  WHERE _TABLE_SUFFIX BETWEEN '20260601' AND '20260630'
    AND platform = 'WEB'
    AND (SELECT value.int_value
         FROM UNNEST(event_params)
         WHERE key = 'ga_session_id') IS NOT NULL
  GROUP BY session_key
),

session_minutes AS (
  SELECT
    session_key,
    minute
  FROM sessions,
  UNNEST(
    GENERATE_TIMESTAMP_ARRAY(
      TIMESTAMP_TRUNC(session_start, MINUTE),
      TIMESTAMP_TRUNC(
        TIMESTAMP_ADD(
          last_event,
          INTERVAL post_last_event_hold_minutes MINUTE
        ),
        MINUTE
      ),
      INTERVAL 1 MINUTE
    )
  ) AS minute
)

SELECT
  minute,
  COUNT(DISTINCT session_key) AS estimated_concurrent_sessions
FROM session_minutes
GROUP BY minute
ORDER BY minute;

The query uses the last collected event plus a configurable grace period. It does not automatically reproduce a vendor’s cookie, return-visit, delayed-call, or number-release rules. It can also miss users excluded by consent settings or blocked analytics collection. Treat its output as a better traffic model, then reconcile it with provider data.

After storing the minute-level result in a table, calculate the relevant percentiles:

SELECT
  APPROX_QUANTILES(estimated_concurrent_sessions, 1000)[OFFSET(990)] AS p99,
  APPROX_QUANTILES(estimated_concurrent_sessions, 1000)[OFFSET(995)] AS p995,
  APPROX_QUANTILES(estimated_concurrent_sessions, 1000)[OFFSET(999)] AS p999,
  MAX(estimated_concurrent_sessions) AS observed_maximum
FROM `project_id.dataset.minute_concurrency`;

For source-specific pools, apply traffic-source, landing-page, hostname, country, or campaign filters in the session CTE. Remember that BigQuery exports device-based raw event data, while GA4 reporting surfaces can use different reporting identities and modeled data, so small differences from the GA4 interface are normal.

How to estimate the error of each method

There are two separate errors to measure:

1. Capacity-model error: the difference between predicted and actual concurrent number demand.
2. Attribution error: the share of calls linked to the wrong visitor, linked with lower confidence, or left without visitor-level attribution.

A pool can be large enough and still have attribution gaps caused by consent denial, script blocking, cross-domain breaks, multiple devices, copied phone numbers, delayed calls, or calls made after the match window. Conversely, a brief pool overflow may affect no call if none of the overlapping visitors calls. This is why “99% pool coverage” and “99% call-attribution accuracy” are related but not identical metrics.

For a transparent pre-launch estimate, calculate the error against a minute-level baseline:

Capacity error = (method estimate − reference percentile) ÷ reference percentile

After launch, use operational measures:

Pool exhaustion rate = minutes with demand above pool size ÷ observed minutes

Affected-session rate = sessions arriving during exhaustion ÷ eligible sessions

Affected-call rate = calls from reused, fallback, or ambiguous assignments ÷ tracked calls

The affected-call rate is the most useful business metric, but not every provider exposes it directly. CallRail’s Number Assignment Table can show whether numbers are swapping too quickly and whether multiple visitors viewed the same number. WhatConverts advises monitoring pool usage and adding numbers when available numbers are frequently exhausted. Use the closest equivalent in the chosen platform.

Balancing cost and measurement accuracy

The cheapest pool is not necessarily the lowest-cost measurement setup. An under-sized pool can send incorrect source, campaign, or keyword data into GA4, Google Ads, CRM reports, and automated bidding. The value of one extra number depends on how many ambiguous sessions and calls it prevents and how costly those errors are.

Use a marginal decision rule:

Add another number while:

expected value of attribution errors avoided > monthly cost of the additional number

The expected value is not only the revenue of calls that might be misattributed. It can include wasted ad spend, incorrect keyword exclusions, poor budget allocation, distorted agency reporting, and weakened Smart Bidding signals.

A practical deployment policy is:

• Start from p99.5 concurrency plus a small reserve when paid media and call conversions influence bidding.
• Use separate pools only when their traffic and reporting purpose are genuinely different. Splitting one large pool into many small source pools can increase the total reserve required and create exhaustion in one pool while numbers sit unused in another.
• Recalculate before predictable peaks. Seasonal businesses should use peak-season data, not an average two-week period from a quiet month.
• Review pool utilization after two to four representative weeks. Include weekdays, weekends, promotions, and at least one high-spend period.
• Increase quickly when exhaustion affects calls. Do not wait for a monthly reporting cycle if assignments are being reused during active campaigns.
• Reduce gradually. Remove one or two numbers at a time only when the chosen percentile remains comfortably below capacity and no overflow or attribution-confidence warnings appear.

For businesses looking for a self-service implementation, metricfixer’s Nimbata overview explains the platform’s dynamic number insertion, GA4 connection, and automatic pool estimator. Regardless of provider, the final configuration should be verified against the actual assignment logic rather than accepted solely from a calculator.

Recommended calculation workflow

For most small and medium-sized sites, the following hierarchy is sufficient:

1. Best available: actual provider occupancy or overflow data.
2. Best pre-launch: GA4 BigQuery minute-level concurrency using the provider’s hold rule.
3. Good practical estimate: peak hourly eligible sessions × effective duration ÷ 60, followed by a percentile or conservative reserve.
4. Fast estimate: peak hourly sessions ÷ 4, only when a roughly 15-minute effective assignment window is reasonable.
5. Budget-only estimate: daily visitors, with explicit acknowledgment that the error cannot be determined without traffic-shape assumptions.

Implementation checklist

• [ ] The GA4 segment matches the traffic sources and pages where DNI will run.
• [ ] Internal, staging, and test traffic is excluded.
• [ ] The analysis covers representative high-traffic and seasonal periods.
• [ ] The provider’s number-release, session-expiry, and match-period logic is documented.
• [ ] GA4 consent and blocker-related undercounting has been considered.
• [ ] The calculation uses peak arrivals and duration, not calls per day.
• [ ] A target percentile or explicit overflow tolerance has been chosen.
• [ ] One or more reserve numbers are included for operational failures and unexpected spikes.
• [ ] Pool exhaustion, number reuse, fallback, and assignment confidence will be monitored after launch.
• [ ] The pool will be recalculated before major promotions or seasonal peaks.

Limitations

There is no provider-independent formula that converts daily visitors into a guaranteed call-attribution accuracy percentage. Each call-tracking platform can use different assignment, cookie, match-window, return-visit, fallback, and number-recycling logic. Public calculators may also use proprietary models that cannot be audited from their documentation.

GA4 is not a perfect representation of all number-consuming visitors. Consent settings, ad blockers, missing tags, browser restrictions, and reporting identity can create differences between GA4, BigQuery, server logs, and the call-tracking platform. GA4 Explorations may also be sampled when a query exceeds property limits, and session counts are estimated with Google’s reporting methods. For high-volume properties, check the data-quality indicator and validate with BigQuery or provider telemetry.

The Poisson examples in this article are simplified capacity models. They assume relatively independent arrivals and do not fully represent coordinated campaign bursts, television spots, email sends, outages, bot traffic, or sudden budget changes. Empirical minute-level percentiles are preferable whenever sufficient historical data exists.

Methodology and sources

This article combines official Google Analytics documentation with published pool-sizing and assignment guidance from call-tracking providers. The comparison separates transparent formulas from proprietary calculators and uses queue-capacity principles to show which assumptions are hidden inside each method. Modeled examples use Little’s Law for expected occupancy and a Poisson distribution for illustrative instantaneous-demand percentiles; they are presented as planning examples, not vendor accuracy guarantees.

• Google Analytics: About Analytics sessions
• Google Analytics Data API dimensions and metrics
• Google Analytics Realtime report
• Google Analytics: Active users in the last 30 minutes
• Google Analytics BigQuery Export
• Google Analytics BigQuery Export schema
• Google Analytics data sampling
• Google Analytics reporting surfaces comparison
• CallRail: How to calculate website pool size
• CallRail Number Assignment Table
• Nimbata: How to calculate tracking number pool size
• WhatConverts: Understanding dynamic number pools
• CallTrackingMetrics Number Pools
• Delacon Rolling Numbers Calculator
• Telmetrics number pool and match-period documentation
• Columbia University notes on Little’s Law

This article is for analytics and operational planning only. It does not guarantee a particular attribution rate, advertising outcome, or call-tracking platform behavior. metricfixer is not affiliated with Google, CallRail, Nimbata, WhatConverts, CallTrackingMetrics, Delacon, Telmetrics, or other third-party platforms mentioned in the article. Product interfaces, pricing, session rules, privacy requirements, data availability, and number-assignment logic may change after publication. Validate the calculation in the selected platform and ensure that call tracking, recording, cookies, consent, and personal-data processing comply with the laws and policies applicable to your implementation.