The CallRail GA4 integration sends each tracked phone call and form submission into Google Analytics 4 as an event, using the GA4 client ID that CallRail's dynamic number insertion script read from the visitor's browser, so the call lands in the same session as the click that produced it and inherits the correct source, medium, campaign and landing page. You then mark that event as a key event in GA4 Admin so it appears in conversion reporting and can be imported into Google Ads. This piece covers what the integration sends, why the client ID matters, the setup path, a naming scheme that keeps reports clean, the Exploration we build to see which sources and pages produce calls, where Local Services Ads and Business Profile calls live, when to use the Measurement Protocol instead, and the mistakes that produce double counts and phantom Direct traffic.
A key event is a GA4 event you have flagged in Admin as an outcome that matters. It is the term GA4 adopted in place of conversions, and it is what the Google Ads link reads when you import analytics events as conversions.
What the CallRail GA4 integration actually sends.
When you connect CallRail to a GA4 property, CallRail sends an event for each call, and optionally for each form submission and text conversation. You choose the event names in the integration settings. Each event carries parameters such as the CallRail source, the tracking number, the duration, whether the call was answered, whether it was a first-time caller, and any qualification you applied. Those parameters can be registered as custom dimensions in GA4 if you want to report on them.
What the integration does not do is create a session. GA4 sessions come from the page tag on your site. The CallRail event is stitched into an existing session by client ID, which is why the DNI script has to be running. If the visitor never received a swapped number, or the DNI cookie was blocked, CallRail has no client ID to attach and the event arrives with no session context. GA4 then files it as Direct, which is the single most misread number in call reporting.
Why the GA4 client ID is the whole trick.
Every GA4 tag sets a first-party cookie, _ga, containing a client ID that identifies the browser. When the DNI script loads, it reads that cookie and stores the client ID alongside the swapped number. When the visitor calls, CallRail knows which client ID was looking at that number and sends the call event tagged with it. GA4 sees an event from a client it already knows, in a session it already opened, and attributes the call to that session's source.
This has three practical consequences. The GA4 tag must load before the DNI script, or the DNI script must wait for it, so the cookie exists when CallRail reads it. Cross-domain setups (a booking tool on a separate domain, a quote calculator hosted elsewhere) need GA4 cross-domain measurement configured and DNI on both domains, or the session breaks at the handoff. And any consent tool that blocks the GA4 tag until acceptance also breaks call attribution for everyone who ignores the banner. We have set this up for HVAC and plumbing companies where most paid traffic is mobile, and consent configuration was the difference between calls attributed and calls lost. See how we approach HVAC and plumbing lead systems.
“If GA4 says your phone calls come from Direct, it is not telling you about your customers. It is telling you the cookie was gone.”
Set up the CallRail GA4 integration.
Naming events so reports stay clean.
GA4 will accept any event name, which is how properties end up with call, Call, phone_call, CallRail_Call and callrail_phone_call all reporting the same thing. Pick a scheme before connecting anything and write it down. The one we use across accounts is: phone_call for every tracked call, qualified_call for calls that a person or the CRM has marked as a real prospect, form_submit for web forms, and text_conversation for SMS. Lowercase, underscores, no vendor names, and the same names in Google Tag Manager, CallRail and any CRM sync.
Keep vendor names out because you will change vendors before you change the report. Keep qualified_call separate from phone_call because they answer different questions: which sources generate phone activity, and which sources generate customers. Only the second should be imported to Google Ads as a bidding signal.
Build the source-to-landing-page Exploration.
The standard GA4 reports show key events by channel, but not calls by source and medium crossed with landing page, which is the view that tells you what to do next. Build it once in Explore and share it with whoever runs the ads.
Where LSA and Google Business Profile calls live.
Two large call sources never reach GA4 in an attributed form. Local Services Ads calls are routed through Google's own number; there is no site visit, no client ID and nothing to stitch. Google Business Profile calls from the call button on the listing are the same: the tap dials a number, it does not open your site. Both can be routed to CallRail tracking numbers for recordings and tags, and both will appear in GA4 as events if you send them, but with no session and therefore no source.
Our practice is to send them with a source parameter set explicitly (lsa, gbp) so they are countable in GA4 but excluded from the source-to-landing-page Exploration, and to treat the LSA dashboard and the Business Profile performance report as the systems of record for those channels.
Native integration, Measurement Protocol or a manual gtag event.
There are three ways to get a call into GA4 and they should not be combined for the same event name.
| Method | How it works | Best for | Watch out for |
|---|---|---|---|
| Native CallRail GA4 integration | CallRail sends events server-side with the client ID captured by DNI | Most businesses; fastest to set up and maintain | Requires DNI live on every page; event names set once |
| Measurement Protocol from your own system | Your CRM or a middleware tool posts events to GA4 with a stored client ID | Sending CRM outcomes such as booked or sold back to GA4 | You must store the client ID on the lead yourself |
| Manual gtag or Tag Manager click event | A tag fires when a visitor taps a tel: link | Sites without CallRail; measures intent to call, not a call | Double counts every call if CallRail is also sending |
| Google Ads call asset reporting | Google forwards the number shown in the ad itself | Calls from the ad, not the site | Never reaches GA4; lives in Google Ads |
The Measurement Protocol route is worth the effort when you want GA4 to know that a call became a booked job. Store the GA4 client ID on the lead when it is created, and when the CRM stage changes, post a job_booked event with that client ID and a value. It is the same discipline as offline conversions for Google Ads; the conversion tracking audit checklist lists the fields to capture.
What usually goes wrong.
- Double counting: a Tag Manager click-to-call event named phone_call fires on the tap, then the CallRail integration sends phone_call for the connected call, and every call reports twice. Pick one sender per event name.
- Internal numbers not excluded, so staff calls through the website number appear as calls from Direct or from whatever session the staff member happened to be in.
- Reading Direct as a channel. A large Direct share on call events almost always means DNI cookie loss: consent blocking, script order, a landing page without the script, or a cross-domain jump.
- Event created but never marked as a key event, so it is absent from the conversion reports and the Google Ads import list, and someone concludes the integration is not working.
- Custom dimensions created weeks after the events started, so historical calls have no callrail_source and the Exploration looks broken for the first month.
- Sending the all-calls event to Google Ads for bidding instead of the qualified event, which trains bidding on spam and vendor calls exactly as it would with a direct CallRail to Google Ads all-calls action.
When an owner asks whether their reports can be trusted, the calls-by-source Exploration is the first thing we open, because it exposes all six problems at once. For a broader check, this piece on reading your marketing covers the reconciliation between ad platform, analytics and CRM.
Does CallRail integrate directly with GA4?
Yes. CallRail has a native Google Analytics 4 integration under Settings, Integrations. You paste the GA4 Measurement ID and an API secret, choose which activity to send (calls, forms, texts) and name the events. CallRail then sends each event with the visitor's GA4 client ID so it attaches to the right session. You mark the event as a key event in GA4 Admin afterward.
Why do my CallRail calls show as Direct in GA4?
Direct means the event arrived without a session to attach to, which usually means the dynamic number insertion cookie was missing. Common causes are a consent banner blocking the script, the DNI script loading before the GA4 tag, a landing page without the script, or a cross-domain jump. Calls from Local Services Ads and the Business Profile call button are also Direct by nature.
How do I make a phone call a conversion in GA4?
Send the call as an event first, either through the CallRail integration or the Measurement Protocol, then go to GA4 Admin, Data display, Events, find the event name and toggle Mark as key event. Once it is a key event it appears in conversion reporting and can be imported into Google Ads through the Google Ads link for bidding.
Should I track phone calls with Google Tag Manager or CallRail?
Use one, not both, per event name. A Tag Manager click-to-call tag measures the tap on a phone link, which is intent. CallRail measures the connected call, its duration and its outcome. If you have CallRail, let it send phone_call and keep any Tag Manager tel: click event under a different name such as phone_click, or remove it, so nothing is counted twice.