How tracking numbers are assigned across multiple swap groups on the same site
If your website uses more than one swap group, you may wonder what happens to those numbers as a single visitor moves between pages.
Are old numbers released? Replaced? Held onto? E.g. a default number on most pages and location-specific numbers on regional landing pages.
This article walks through the exact behavior.
Tracking number behavior
All numbers assigned to a visitor stay locked to their session until that session expires.
Numbers are not released or replaced when the visitor navigates to a new page.
Each new swap group the visitor encounters adds another number to their session.
A typical multi-location setup
Many businesses with multiple physical locations configure their site like this:
- Default swap group (
nimbata_number_1) - used on the homepage and other non-location pages - Amsterdam swap group (
nimbata_number_2) - used on the Amsterdam landing page - Rotterdam swap group (
nimbata_number_3) - used on the Rotterdam landing page - ...and so on, one swap group per location
Each location page uses its own swap group class for DNI so that visitors see a number local to the region they are browsing.
What happens as a visitor browses
Imagine a single visitor moving through three pages in one session.
Step 1. Visitor lands on the homepage
Nimbata assigns a tracking number from your Default pool (nimbata_number_1) and ties it to the visitor's session cookie.
Step 2. Visitor navigates to the Amsterdam page
Nimbata detects a new swap group (nimbata_number_2) on this page.
It assigns a number from the Amsterdam pool and ties it to the same session.
The Default number is not released; it stays attached to the session in case the visitor returns to a non-location page.
Step 3. Visitor navigates to the Rotterdam page
Nimbata detects another swap group (nimbata_number_3), assigns a number from the Rotterdam pool, and adds it to the session.
Again, the previously assigned numbers stay attached.
Step 4. Visitor goes back to the Amsterdam page
The Amsterdam pool number that was already assigned in Step 2 is displayed again.
Nimbata does not re-assign a new Amsterdam number; it reuses the one already tied to this session.
By the end of this browsing journey, the visitor has three tracking numbers concurrently assigned to their session: one from Default, one from Amsterdam, and one from Rotterdam.
Why numbers aren't released when a user navigates to different pages
Releasing a number the moment a visitor leaves a page would break attribution.
A common visitor pattern looks like this:
- Visitor lands on the Amsterdam page
- Browses the homepage to learn more about the company
- Returns to the Amsterdam page
- Calls the number shown
If Nimbata released the Amsterdam number in Step 2, the visitor might be shown a different number in Step 3, and the eventual call would not be attributed to the original Amsterdam visit. Holding the number until the session expires guarantees that attribution stays consistent for the entire visit.
What this means for pool sizing
Because a single visitor can occupy multiple numbers concurrently, you need to size your pools to account for this when you have many swap groups.
If you expect a meaningful share of visitors to view several location pages in one session, factor that into your pool calculation.
If you are unsure how many numbers each pool needs, you can use the pool calculator inside Nimbata, or get in touch with the team and we will help you size it correctly.
Detailed Guide: DNI script 101: how to install and configure it
Detailed Guide: DNI: swap target formatting rules and common mistakes
Detailed Guide: How to structure tracking numbers for multiple traffic sources
Updated on: 21/05/2026
Thank you!