Connecting Uber Eats to GA4

Architecture

How Uber Eats and GA4 actually connect

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

1. Step 1

   Uber Eats holds the truth

   In-app sponsored placement performance lives in Uber's own reporting and never touches your website. Your external advertising and your in-app advertising are measuring different customers and should never be summed.

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 Uber Eats order. Without it there is nothing to join on and no tool fixes that.

4. Step 4

   The event source decides reliability

   If you send anything at all, send net payout per order, and label the channel so it can be excluded from any return-on-spend calculation for external campaigns.

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 Uber Eats and into GA4.

3. 3

   Confirm the channel is excluded, not included

   For most restaurants the correct integration here is a deliberate exclusion, documented so nobody re-adds it in six months.

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 Uber Eats'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 Uber Eats to GA4.
• Server events confirmed in DebugView attaching to an existing session with the original traffic source intact.
• Uber Eats revenue reported as its own line, demonstrably absent from imported conversions.
• 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 Uber Eats'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.
• This is the common case, not the exception. If Uber Eats is purely a marketplace channel for you, skip the integration and spend the effort on your direct ordering path.
• 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.