--- title: CallRail & GoHighLevel Integration type: article created: '2026-04-05' updated: '2026-04-05' source_docs: - raw/2025-11-11-call-railattribution-explainer-adava-care-100774928.md tags: - callrail - go-high-level - call-tracking - attribution - dynamic-number-insertion - crm-automation layer: 2 client_source: null industry_context: null transferable: true --- # CallRail & GoHighLevel Integration ## Overview CallRail and GoHighLevel (GHL) serve overlapping but distinct roles in call tracking and CRM workflows. Understanding how they interact — and where each falls short — is essential before designing a phone strategy for any client. The core tension: GHL's native call tracking uses **static number assignment** (one number per source), while CallRail's strength is **Dynamic Number Insertion (DNI)**, which connects calls to a user's full digital journey. Clients often arrive with a GHL-based setup that works at a surface level but lacks the attribution depth that DNI provides. --- ## How GHL Static Tracking Works GHL's approach assigns a unique phone number to each traffic source or location. When a call comes in on that number, GHL logs it as originating from that source. **Example (Adava Care):** Karosh set up 10 location-specific numbers, each forwarding to the corresponding facility. A call to the "Fardale" number was logged as a Fardale inquiry. A number tied to a Google Ads call extension was logged as a Google Ads call. **What you get:** - Source-level attribution (billboard, Google Ads extension, specific location) - Call logs within GHL - Basic forwarding and routing **What you don't get:** - Keyword-level attribution (what did the user search?) - Session-level attribution (which ad, which landing page?) - The digital thread connecting a click to a call This is "A-level" call tracking — useful, but not granular. It's analogous to putting a unique number on a billboard: you know the billboard drove the call, but nothing else. --- ## Where CallRail Adds Value CallRail's DNI closes the attribution gap by connecting each call to the visitor's full session data via the Google Click ID (GCLID). **How DNI works:** 1. User clicks a Google Ad → Google assigns a GCLID to that click 2. CallRail's JavaScript on the landing page detects the GCLID 3. The script swaps the visible phone number with a temporary number from a pool (typically 4–6 numbers) 4. User calls the temporary number → CallRail links the call to the GCLID 5. CallRail dashboard shows: source → keyword → landing page → call **What you gain over GHL static tracking:** - Keyword-level attribution - Landing page attribution - Full session context passed to downstream CRMs (HubSpot, Salesforce, etc.) or via Zapier/webhook --- ## The Multi-Number Problem GHL static setups with many location-specific numbers create a structural barrier to DNI adoption. **The issue:** DNI works by swapping a single target number on the website. If a site has 10 different numbers (one per location), there is no single swap target — DNI cannot cleanly operate across all of them simultaneously without creating a separate pool per page, which becomes expensive and complex. **The recommended path:** 1. Consolidate all marketing-facing numbers to a single number (or toll-free number) 2. Route that number through a CallRail call flow to the appropriate sales contact 3. Apply DNI to swap that single number across the site 4. Use CallRail's **whisper message** feature to inform the agent which location or campaign the caller came from, compensating for the loss of location-specific numbers > **Note:** Location-specific numbers can still exist for operational purposes (e.g., families contacting a specific facility directly), but they should be removed from marketing-facing pages and landing pages. --- ## CallRail Features Relevant to GHL Clients | Feature | Description | GHL Equivalent | |---|---|---| | **DNI / Keyword Pool** | Swaps website number per visitor session; links call to GCLID | Not available | | **Static Tracking Numbers** | One number per source; basic attribution | GHL tracking numbers | | **Call Flow / Call Tree** | Ring groups, IVR menus, sequential routing | GHL workflows | | **Whisper Message** | Private audio to agent before caller connects, identifying source | Limited in GHL | | **Call Recording** | Inbound recording with consent message | Available in GHL | | **Outbound Recording** | Requires agent to dial from CallRail mobile app | Available natively in GHL | | **CRM Integration** | HubSpot, Salesforce, Zapier, webhooks, Google Analytics | GHL-native | --- ## When to Use CallRail vs. GHL Native Calling **Use CallRail when:** - The client runs paid search and needs keyword/session-level attribution - You need DNI across a website or landing page set - Multiple unique tracking numbers are required (e.g., one per state, one per campaign) - Call data needs to flow into a non-GHL CRM (HubSpot, Salesforce, Pipedrive via Zapier) **Stick with GHL native calling when:** - The primary need is outbound call recording for a sales team - The client is already fully in GHL and doesn't run significant paid search - Simplicity and cost are priorities over attribution depth > Mark's framing: "The time that CallRail is really super valuable is if you need a bunch of phone numbers for unique purposes or if you want to run dynamic number insertion. If they just want to record outbound calls, they'd be better off with HubSpot phone numbers." --- ## Implementation Checklist (GHL → CallRail Migration) Before setting up CallRail for a client currently using GHL static tracking: - [ ] Audit all phone numbers currently on the website and their forwarding destinations - [ ] Confirm who receives marketing calls (sales contact vs. facility/location staff) - [ ] Determine whether to consolidate to a single number or maintain location-specific pools - [ ] Identify the "swap target" number for DNI - [ ] Build the CallRail call flow (primary contact → fallback chain) - [ ] Configure whisper message if location context is needed at answer - [ ] Install CallRail JavaScript on the website - [ ] Verify pool numbers are all active and forwarding correctly (test via incognito) - [ ] Brief the client on DNI — explain why the website number will appear to change - [ ] Set up CRM integration (HubSpot plugin, Zapier, or webhook) - [ ] Confirm recording consent compliance for relevant states (two-party vs. one-party consent) --- ## Known Pitfalls - **Clients panic when numbers change.** DNI causes the visible website number to rotate. Clients who check their own site will see unfamiliar numbers. Brief them in advance. - **Pool numbers can go dead.** Individual numbers in a CallRail pool can stop forwarding without obvious alerts. Verify all pool numbers are live after setup. - **Outbound recording requires the CallRail app.** Agents must initiate calls from the CallRail mobile app for outbound calls to be recorded. This is a workflow change that needs buy-in. - **Multi-location DNI gets expensive.** If each location page needs its own pool (to support location-specific whisper messages), costs scale quickly. Evaluate whether a single pool + whisper message is sufficient. - **GHL and CallRail can conflict.** If GHL is already managing forwarding for tracking numbers, adding CallRail on top requires careful coordination to avoid double-forwarding or broken call chains. --- ## Related - [[clients/adava-care/_index]] - [[clients/bluepoint/_index]] - [[knowledge/crm-automation/dynamic-number-insertion]] - [[knowledge/crm-automation/hubspot-phone-integration]] - [[knowledge/paid-search/gclid-attribution]]