Which field should the Ads and GA4 comparison be matched on?

On a shared identifier present on both sides. For purchase conversions that is the transaction ID; if the action measured in Ads is begin checkout or add to cart, a checkout session ID or cart ID comes into play. What decides it is not the name of the key but whether it is unique per row, because a join on a non-unique key turns into one-to-many and the match rate loses its meaning. In the purchase scenario there is one more precondition: the Ads Webpages report only reports the path portion of the URL, not query parameters. At /thank-you?order=12345 the order ID never enters the report; the method only works when the number is part of the path, as in /order/12345. Matching on campaign name is not reliable, because with auto-tagging the campaign information reaches GA4 through the Ads link while the utm_campaign written to the cookie is usually empty.

Can this comparison be done with the Ads Report Editor?

Partly. Report Editor has no webpage dimension, so an order-level join cannot be produced there. Outside the dashboard, Ads API conversion upload records and the store's own order records can also serve as a bridge. Report Editor is required for the campaign-level normalisation: the (by conv. time) columns, the All conv. gap, cross-device conversions and the conversion action inventory all come from there. Staying inside the dashboard, the only row-level bridge is the Webpages report under Conversions.

Does GA4 have a click ID dimension, and should it be filtered in an Exploration?

GA4 does not ship a click ID dimension. The dimension in the report is a custom one you register yourself after capturing the click ID on the landing page and sending it with the event; if it is not set up, there is no such field to choose in an Exploration. Even once it exists, do not filter to populated rows. A filter excludes orders that arrive with gbraid or wbraid instead of gclid on iOS, and orders where the cookie could not be written because consent was denied. Once those rows leave the report, a real gap starts looking like cross-device loss. Pull without the filter and classify afterwards.

Is there a measurable ceiling to storing the click ID in a first-party cookie?

Yes. In practice it settles at a capture rate around ninety percent and drops a few points as the comparison window widens. The cause of the drop is an asymmetry between cookie lifetime and the ad conversion window, but that asymmetry is not present in every account: the click conversion window in Ads is set separately for each conversion action, defaults to thirty days and can be raised to ninety. If it has been raised, the cookie expires earlier, and much earlier on Safari because of ITP. Most of the remaining gap is users switching devices and consent denial.

If the match rate comes out low, where should I look first?

At the denominator. Ads volume that can never be attached to a row (conversions where the page URL was not recorded, modeled conversions, view-through conversions and cross-device) has to be removed before computing the rate, otherwise the method reports what it cannot measure as loss. The second place is the GA4 only bucket: if organic and other-platform orders have leaked into it, you are no longer comparing two dashboards but two different universes. The third is the precondition, whether GA4's own count agrees with the store's order records.

Can sGTM extend cookie lifetime and raise the capture ceiling?

Partly, but not unconditionally. A cookie written server-side through the Set-Cookie header is not subject to ITP's seven-day cap on JavaScript cookies. The exemption depends on where the subdomain resolves: WebKit's documentation states that when third-party CNAME cloaking or third-party IP address cloaking is detected, the expiry of cookies set in the HTTP response is also capped at seven days. This route only closes the loss caused by cookie lifetime; consent denial, cross-device, and gbraid or wbraid arriving instead of gclid on iOS are unaffected by it.

Joining Google Ads and GA4 at Row Level: A Shared Key and a Two-Layer Reading

Instead of putting two dashboard totals side by side, join at row level on an identifier present in both. How the join key is chosen, the precondition in the Ads Webpages report, the three-bucket reading, and the measured ceiling of first-party cookie capture.

TL;DR

Taking the difference between two dashboard totals is not a method. What works is joining at row level on an identifier present on both sides, then reading the result in two layers rather than as one match rate. The key changes with the conversion action; what decides it is not its name but whether it is unique per row. Verify the GA4 side's own count first, because the difference may belong to the measurement layer rather than to Ads.

Create Free Account Sign In