Connecting Olo to GA4

Architecture

How Olo and GA4 actually connect

Two systems that know nothing about each other. Everything below exists to give them one shared reference.

1. Step 1

   Olo holds the truth

   Rails pulls DoorDash, Uber Eats and Grubhub orders into the same order stream as your own website. They land in one feed and they are not the same thing: one carries a click you paid for, the other carries a marketplace commission and no identifier at all.

2. Step 2

   GA4 needs a click to match

   GA4 needs the client_id to attach a server event to the user and session that produced the click. Without it there is no attribution to inherit and the event is orphaned.

3. Step 3

   The identifier is the bridge

   The GA4 client_id, captured at the visit and carried into the Olo order. Without it there is nothing to join on and no tool fixes that.

4. Step 4

   The event source decides reliability

   Send per-location. A brand with two hundred restaurants running one national campaign learns nothing from a single national conversion number.

5. Step 5

   Deduplication at the destination

   GA4 has no built-in deduplication for Measurement Protocol. If the browser also sends the event, it counts twice. The only reliable approach is to decide per event which side sends it, and enforce that decision — GA4 will not protect you from your own duplicates.

Diagnose it honestly

Working vs. broken, side by side

Both states look identical from the GA4 dashboard, which is why this runs for months before anyone notices.

Diagnostic sequence

Diagnostic order

Each step rules out a class of cause. Run them in order and the last one usually has a single explanation standing.

1. 1

   Count orders carrying the GA4 client_id

   The ceiling on everything else. Do this before debugging anything downstream.

2. 2

   Follow one real conversion end to end

   From the ad click through Olo and into GA4.

3. 3

   Separate direct from Rails at the source

   Do this before any tracking work. The split is the measurement; everything after it is plumbing.

4. 4

   Check whether server events carry a session and a source

   In GA4 Realtime or DebugView, find the event and look at its session and traffic source. A brand-new user with no source on every server event is the missing-client_id signature.

5. 5

   Read the match rate, not the success message

   GA4 DebugView shows events arriving with their parameters, and Realtime confirms the user and session they attached to. Neither tells you whether you are double-counting — for that, compare GA4's conversion count against the source system's record for the same window.

Source-of-truth validation

How it gets proven

Against Olo's own records, not against either platform's dashboard.

• The GA4 client_id confirmed present on a live order.
• A real conversion followed from click through Olo to GA4.
• Server events confirmed in DebugView attaching to an existing session with the original traffic source intact.
• Direct-channel orders per location reconciled against imported conversions, with Rails volume reported as a named exclusion.
• Reconciled over a fully closed window, matched per record rather than on totals.
• Re-checked 30 days later.

Straight talk

When you don't need this

Worth reading before paying anyone, including us.

• If GA4 already reports conversions that reconcile against Olo's records within a few percent, this join is working and there is nothing to buy.
• Measure identifier coverage yourself first — pull your last hundred orders and count how many carry the GA4 client_id. Ten minutes, free, and it tells you whether any of this is worth doing.
• If your Olo volume is overwhelmingly Rails, the campaign question is about marketplace placement and commission, and no amount of conversion tracking will answer it.
• GA4 is reporting, not bidding. If your problem is ad platform optimization, fix the ad platform destination first — GA4 will not change what any campaign does.