Transaction-ID vs. Event-ID in the Google Ads Conversion Tag Template

Overview

The Transaction-ID field in the Google Ads Conversion Tag Template is often misunderstood. Many users assume it should always be filled with an order-related identifier, such as an Order-ID. In reality, its purpose is different: Google uses this field for deduplication, allowing multiple hits from different sources to be recognized as a single conversion.

This article explains what the Transaction-ID field is actually for, how JENTIS uses it by default, and when you might want to override the default behavior with your own Order-ID.

What Is the Transaction-ID Field For?

Google Ads uses the Transaction-ID to deduplicate identical conversions that are sent from multiple sources for the same transaction. In a hybrid tracking setup, the same conversion event is often sent both:

• Client-side (from the browser), and

• Server-side (from your server or tag management backend)

Without a shared identifier, Google Ads could count these as two separate conversions instead of one. The Transaction-ID field solves this: as long as both hits share the same value, Google Ads links them together and counts them as a single conversion — regardless of which source they came from.

In short: the Transaction-ID field is not primarily an order identifier. It's a deduplication key.

How JENTIS Uses the Event-ID by Default

In the JENTIS standard configuration, the Transaction-ID field is populated with a variable called Event-ID.

The Event-ID is a randomly generated identifier created per state-and-trigger combination, ensuring that the client-side and server-side hits for the same event are stitched together correctly. This is a core part of how JENTIS enables hybrid tracking — combining client-side and server-side data — across different vendors.

Using the Event-ID by default means that every conversion event tracked on your website (not just purchases) is ready for deduplicated, hybrid reporting in Google Ads — without any extra configuration required.

Why Not Just Use the Order-ID?

Ultimately, this is your decision — both approaches are valid, depending on your goals.

The JENTIS default uses the Event-ID because it works for all conversion events, not only purchases. If you only need deduplication for purchase events, using the Order-ID as the Transaction-ID is also a valid setup — particularly if the Order-ID already functions as your primary identifier for that transaction.

Benefits of using the Order-ID for purchase conversions

• It ties the conversion directly to a specific order, which can be useful for order-level analysis.

• It provides protection against duplicate purchase conversions if the same order confirmation page is reloaded — since the reload would send the same Order-ID again, allowing Google Ads to recognize and dedupe it.

Note: Preventing duplicate purchase events from firing on page reload should primarily be handled at the datalayer level. Your datalayer should ensure that a purchase event only fires once per completed order, regardless of Transaction-ID logic. The Order-ID as Transaction-ID acts as an additional safeguard, not a replacement for correct datalayer implementation.

Summary

	Event-ID (JENTIS default)	Order-ID
Scope	Works for all conversion types	Best suited for purchase/order conversions
Purpose	Deduplicates client-side and server-side hits for any tracked event	Deduplicates hits tied to a specific order
Extra reload protection	Not order-specific	Adds a safeguard if the confirmation page reloads
Recommended when	You want deduplicated hybrid tracking across all events	You track orders with a primary Order-ID and want conversions tied to it

If you want to switch from the Event-ID to the Order-ID for your purchase conversion tag, you can simply update the transaction_id value in your Google Ads Conversion Tag Template configuration in JENTIS.