Adava Care operates 10 assisted living locations, each with its own phone number on the website. This setup creates two compounding problems: calls route directly to facility staff rather than the sales contact, and attribution data is limited to source-level tracking with no keyword or session data. This article documents the diagnosis of the current setup and the recommended consolidation strategy discussed in the [1].
See also: [2] and [3].
Static number tracking provides source-level attribution only. For example: a number tied to a Google Ads call extension tells you the caller saw that extension — nothing more.
"What this tells you is that if somebody dialed this phone number right here, this 920 phone number, they saw that phone number on this Google Ads extension. That's as far as you're going. You don't know the keyword that they searched." — Mark Hope
This is analogous to putting a unique number on a billboard: you know the channel, but you lose keyword, session, and landing page data entirely.
| Problem | Detail |
|---|---|
| Weak attribution | No keyword, ad, or landing page data attached to calls |
| Wrong call destination | Calls route to facility staff, not the sales contact (Keri) |
| DNI incompatible | Multiple swap targets make dynamic number insertion impractical without a pool per page |
| No call tree | Unknown whether a fallback chain (Keri → Tanya → Karosh) exists |
Remove all 10 location-specific numbers from the website and replace them with one number — either a local Milwaukee number or a toll-free number (recommended if callers from Madison or other markets may hesitate to dial a 414 number).
"If it's me, there's one phone number on the website. One phone number." — Mark Hope
Location-specific numbers should be removed from public-facing pages. If direct facility contact is ever needed (e.g., for family members of current residents), those numbers can be placed in a non-marketing context — not on landing pages.
With a single swap target in place, install the CallRail JavaScript snippet on the Adava Care website. Configure a keyword pool of 4–6 numbers set to track all visitors.
How DNI works in this context:
1. A user searches "assisted living Milwaukee" and clicks an Adava Care Google Ad.
2. Google assigns a GCLID (Google Click ID) to the click.
3. The CallRail script on the landing page detects the GCLID and swaps the displayed number with a unique pool number.
4. If the user calls, CallRail links the call to the GCLID — capturing keyword, ad, and landing page.
Expected dashboard output: Source: Google Ads | Keyword: Assisted Living Milwaukee | Landing Page: Fardale
See [4] for full technical detail.
Configure a CallRail call flow so all inbound marketing calls route to Keri (the designated sales contact). The call tree should include a fallback chain in case Keri doesn't answer (e.g., Keri → Tanya → Karosh voicemail). This needs to be confirmed with Karosh — it's possible a partial call tree already exists in Go High Level.
Enable a whisper message on the CallRail number so Keri hears a brief recording before the caller connects — e.g., "Call from the Adava Care Fardale landing page." This gives Keri location context without requiring the caller to navigate an IVR.
"There does need to be a little bit of that — so they're not talking about Nina, which is up in Oshkosh, when they're wanting to be talking about Fardale, which is in Milwaukee." — Melissa Cusumano
Note: Whisper messages can initially confuse agents who haven't encountered them before. Brief the team before enabling.
Adava Care (specifically Karosh) must be briefed on how DNI works before the pool goes live. When the JavaScript is active, the phone number displayed on the website will change with each visitor session. Clients who check their own site will see unfamiliar numbers and may raise concerns.
"You've got to be able to explain this to your clients so they don't lose their mind when the numbers change." — Mark Hope