> For the complete documentation index, see [llms.txt](https://docs.jentis.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.jentis.com/data-activation/connectors/google-ads/transaction-id-vs.-event-id-in-the-google-ads-conversion-tag-template.md). # 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.jentis.com/data-activation/connectors/google-ads/transaction-id-vs.-event-id-in-the-google-ads-conversion-tag-template.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.