CallRail to Google Ads: Attribute Calls Without Double-Count

To attribute phone calls to Google Ads, pull each tracked call and its gclid (Google's click id) out of CallRail, match it to a real booking, and upload it as an offline conversion. To avoid double-counting, set just one conversion action as primary for calls: CallRail's native import or your own upload.

Without this loop, phone leads can stay invisible to Google: someone clicks an ad, calls, books days later, and the platform never learns the click worked.

I built patient conversion tracking for a multi-location US medical practice that ran Google Ads for calls and online bookings.

Why phone leads break Google Ads attribution

Standard Google Ads conversion tracking sees a form submit because the gclid is in the browser when the form fires. A phone call breaks that chain: the click id is nowhere near the conversation. Unless something carries the gclid across that gap, Google credits the click with nothing, and smart bidding favors the leads it can see (forms) over the channel it cannot (calls).

CallRail closes the gap. It swaps in a dynamic number per visitor, ties it to the session, and captures the gclid from the landing page URL, so each call knows its click. Your job is to decide which calls count, attach a value, and hand them back to Google.

How do I match a call to a booking?

A ringing phone is not a conversion. The caller may be an existing patient, a wrong number, or someone who never books. Credit the ad only when a call becomes a real appointment, so join the call log to the booking record.

Two rows trip people up.

First, the time window. Allowing a week to catch slow bookers matches calls to bookings that would have happened anyway, so Google Ads gets credit for organic demand. Keep it to a day or two. You will miss a few late bookings; that beats crediting the ad with bookings it did not drive.

Second, the phone number. You do not need the raw number to match, and in healthcare you do not want it in your pipeline. Hash it with SHA-256 on both sides, normalizing first (strip formatting, force E.164) so one number always gives one hash.

// normalize to E.164, then hash. The raw number never leaves this function.
const digits = phone.replace(/\D/g, "");
const e164   = digits.startsWith("1") ? `+${digits}` : `+1${digits}`;
const phoneHash = crypto.createHash("sha256").update(e164).digest("hex");

Now the two records join on phoneHash with no raw phone number crossing systems.

Build the pipeline, step by step

The loop, from click to uploaded conversion:

1. Capture the gclid on click. CallRail attaches it to the visitor's call session. Confirm it with a test call first.
2. Pull calls daily. Fetch the previous day's calls from the CallRail API, keeping the gclid, the timestamp and the number you will hash.
3. Hash both sides with the same normalize-then-hash step.
4. Match inside the window. Join on phoneHash. Keep bookings made within 1 to 2 days after the call, and only those that reached a real appointment status.
5. Assign a value. Take it from your own booking data, for example the service booked multiplied by its list price, computed on your side and in aggregate. Google gets a number, not a patient record.
6. Upload through the Data Manager API. Send each matched call to a dedicated UPLOAD_CLICKS conversion action, with the gclid, value and conversion time.
7. Reconcile. Log what you uploaded and compare it with Google Ads a day later, so a silent failure surfaces fast.

The upload payload is deliberately thin:

{
  "destinations": [{
    "operatingAccount": { "accountType": "GOOGLE_ADS", "accountId": "CUSTOMER_ID" },
    "productDestinationId": "ACTION_ID"
  }],
  "events": [{
    "adIdentifiers": { "gclid": "<gclid-captured-by-callrail>" },
    "eventTimestamp": "2026-07-28T14:11:02+00:00",
    "conversionValue": 180,
    "currency": "USD"
  }]
}

The pipeline is the same offline conversion tracking setup I use for web bookings; the phone loop feeds a second event type into it.

The double-counting trap

CallRail's native Google Ads integration posts calls from your Google ads to its own "Phone Call" conversion action, and CallRail recommends making it primary. Separately, you build the pipeline above and upload your own matched-to-booking calls into a "qualified call" action. Now the same call can hit Google twice.

Google Ads de-duplicates inside one action (by order id, if you set one), but two separate actions are two different events to Google. Your conversion count climbs, your cost-per-conversion drops, and smart bidding chases a number that is partly fictional.

The fix is a decision, not more code. Pick one source of truth for phone conversions:

• Keep your own upload as primary, because it is matched to an actual booking, not just a call that rang long enough. Set CallRail's native action to secondary, or turn it off after a couple of weeks of proof.
• Or, if you do not yet trust the custom pipeline, leave the native import as primary and set your own action to secondary and observation-only while you validate it.

Never run two primary actions for the same call: one counts the ring, the other the booking, and they overlap on every lead that did both.

Send calls and web bookings down one pipe

A caller can also be a web booker: someone phones Monday, then books online Wednesday from the same ad click. If your call loop and web-booking loop never talk, you upload two conversions for one gclid and count one person twice.

Route both through the same Data Manager API path, keyed by gclid, even though they land in separate conversion actions. The call goes to your UPLOAD_CLICKS action and the web booking to its own, but both pass through code that can see "this gclid already produced a booking today, do not fire again." Two conversion actions for reporting, one pipeline for truth.

What actually leaves your system

Run this way, only an anonymous click id (the gclid), a conversion value, and a timestamp reach Google. The phone number is hashed before use and never uploaded. No name, no appointment detail, and no patient record is persisted into the attribution files or shipped to the ad platform. That is the posture a HIPAA-conscious practice needs.

When the phone actually rings

Once calls carry a source, patterns show up, such as a lunchtime peak, a dead Sunday, or a pool of calls with no source.

Source quality matters as much as volume: the largest source can be the noisiest.

Synthetic figures, not client data. Note the no-source row: 203 calls a month with nothing to attribute them to, and the highest short-call share.

When is this worth building?

If phone is a rounding error in your lead mix, skip it and track forms well. Once calls are a meaningful share of qualified leads, bidding works from only part of the picture.

You can build this yourself: CallRail's API, a scheduled job, a hash function, and the Data Manager API are all documented.

Sources checked on 2026-10-25.