Google Ads Offline Conversion for Shopify: Complete 2026 Guide

Google Ads offline conversion tracking for Shopify closes the gap between orders in Shopify and conversions in Google Ads by sending hashed customer data server side when the browser cannot. When Shopify orders exceed Google reported purchases, the missing rows are usually not a delay but a match failure. The browser tag never reached Google, the click identifier was blocked, or the Pulse lacked an identifier Google could resolve. Attaching hashed email and phone to a server side Pulse and delivering it through the Google Ads Channel gives Google the data it needs to credit the purchase to the ad click. The complete Shopify conversion tracking guide explains why server side delivery is now the foundation for reliable measurement, and this guide covers the Google offline path specifically: what offline conversion means for a Shopify purchase, how it differs from Enhanced Conversions, what data it needs, how consent controls it, and how to set it up and keep it healthy without Google Tag Manager.

The Quick Answer

Google Ads offline conversion for Shopify sends the purchase that happened on your store to Google Ads after checkout, with customer data hashed with SHA-256, so Google can match the order to the Google Account that clicked the ad even when the browser tag was blocked or the click identifier is missing. You enable a Google Ads conversion action that accepts offline or Data Manager uploads, collect email and phone at checkout, hash and format the data per Google schema, and deliver the Pulse server side through the Google Ads Data Manager API. When browser loss is the cause of underreporting, this server side Channel recovers the conversions the browser could not send. Google deduplicates browser and server uploads for the same purchase on hashed identifiers and click identifiers where present. Add phone in E.164 format, confirm consent state with every Pulse, and verify through Google Ads diagnostics and Clarity Score per Channel.

What Google Ads Offline Conversion Is on Shopify

In Google Ads language, offline conversion originally meant a conversion that happens away from the website, such as an in store sale or a phone order, uploaded later with Google click identifier data. For Shopify, the same mechanism now covers online purchases whose conversion Pulse did not reach Google through the browser. The order completes online, Shopify confirms it, and the Pulse is delivered server side after checkout as an offline conversion upload.

The key point is timing and identifier. A standard Google Ads conversion tag fires in the browser at the thank you page and depends on the Google click identifier stored in a cookie. An offline conversion upload sends the same purchase from the server with hashed customer data the store already collected, such as email and phone, plus the click identifiers gclid, wbraid, or gbraid when available. Google hashes its own user data the same way and attempts to match the two sets. If the match succeeds, Google credits the conversion to the ad click that produced it even though the browser tag never arrived.

Hawklists sends this Pulse through its Google Ads Channel, which is a live Channel alongside Meta Conversions API. The Pulse is captured once at order confirmation and transformed per destination, so delivery success is measured per Channel as a Clarity Score. The Stream shows one recovered purchase with confirmed delivery per Channel rather than separate order counts.

For Shopify merchants, offline conversion is not a replacement for the Google tag. It is the server side complement that catches the conversions the tag missed. Stores running only the browser tag see the same browser loss that affects Meta: ad blockers filter third party requests, Safari Intelligent Tracking Prevention caps cookies and blocks third party storage, and iOS App Tracking Transparency shifts browsing into environments where click identifiers are short lived. An offline server side upload is not subject to those browser restrictions because it travels server to server.

Why Shopify Stores Show More Orders Than Google Reports

The gap between Shopify orders and Google Ads purchases has four causes, and most fixes address only the first one.

The first cause is browser blocking. Client side conversion tags fire inside the buyer’s browser, and the browser may refuse to send them. According to Statista’s Global Digital Advertising Report, about forty two percent of desktop users in North America and Western Europe run an ad blocking extension that filters third party tracking requests, and Julian Juenemann of MeasureSchool has documented that client side pixel loss of forty to sixty percent is now typical for Shopify stores without server side coverage. A blocked Google tag means the order completes but Google never counts the conversion.

The second is cookie and identifier lifespan. Safari Intelligent Tracking Prevention limits first party cookie life to seven days and blocks third party cookies, and Chrome’s ongoing third party cookie deprecation shortens the window where a Google click identifier remains available at purchase. A customer who clicks a Google ad, browses for more than a week, then buys in Safari, is not connected to the original click because the identifier that would have linked the two is gone.

The third is the checkout surface. Shopify checkout extensibility in 2024 changed where thank you and order status handlers live, and many customizations defer or move the confirmation script. A store can appear correctly tagged while the Google tag never fires at confirmation for a subset of orders, especially when accelerated checkouts such as Shop Pay skip the standard form.

The fourth is identity completeness. The standard tag waits for a click identifier, but offline conversion adds a second chance to match using customer data the store collected at checkout. Without hashed email or phone, a conversion that arrives without a usable click identifier has nothing to match against. The Shopify signal recovery guide places this identity gap alongside browser gaps as one of the remaining places where recovered purchases are lost after server side delivery is live, and the Shopify signal loss audit documents identity gaps as one of the twelve leaks that keep Clarity Score and match coverage separate metrics.

Offline Conversion vs Enhanced Conversions on Google

Merchants often ask whether offline conversion and Enhanced Conversions are two names for the same thing. They overlap on hashing and matching but differ on when and why they send customer data.

Enhanced Conversions supplements the browser tag with hashed customer data sent alongside the conversion. The tag reads email and phone at checkout, hashes them with SHA-256, and sends the hashes with the purchase event so Google can match even when the click identifier is degraded. It is primarily a tag side improvement.

Offline conversion upload sends the conversion entirely server side after the order is confirmed, through the Google Ads Data Manager API or the Google Ads API offline conversion endpoint. The Pulse carries the same hashed customer data and the click identifiers gclid, wbraid, gbraid when the store captured them, but the transmission is server to server and does not depend on the browser at all. Google attributes the uploaded conversion to the click or to the hashed user when the click identifier is absent.

A third variant, Enhanced Conversions for Leads, imports leads rather than purchases and is used when the conversion is a lead form submission rather than a completed order. A Shopify purchase is a purchase conversion, not a lead, so the correct action is the purchase conversion with offline or Data Manager upload enabled, not the lead type.

In practice, most Shopify stores use Enhanced Conversions and offline upload together. The browser tag with Enhanced Conversions handles purchases where the browser cooperates, and the offline server side Channel handles the purchases where the browser does not. The Google Enhanced Conversions guide for Shopify covers the tag side in detail, including field formatting and the browser path. This guide focuses on the server side upload path and how to make the two sources work without double counting.

For Hawklists, both paths share the same purchase Pulse. The Pulse is captured once at order confirmation and formatted per Google requirement. The Overview shows Clarity Score per Channel, so a store can see that the Google Ads Channel confirms ninety percent of Pulses while the browser tag confirms fewer, and that difference points to a browser coverage gap rather than a capture problem.

What Data Google Matches On

Google matches an offline uploaded purchase on the hashed customer data the store provides and, when present, the click identifiers the store captured from the ad click.

The primary customer fields are email address and phone number. Email is the most important single field because it is the most likely to be tied to a Google Account. Phone is second because users change phone numbers less often than email addresses and phone is more likely to be present on the Google side as a verified contact. Where the store collects them, first name, last name, street address, city, region, postal code, and country add incremental matching value. Each field has its own parameter in the Google schema.

Normalization determines whether a correct Pulse actually matches. Email must be lowercased and trimmed of surrounding whitespace before hashing. Phone must be in E.164 format, which includes the country code with a leading plus sign and only digits after the plus, for example plus one for the United States. Names must be sent as separate first and last values, not a combined full name. Addresses must be split into street, city, region, and postal code rather than sent as a single line. Google expects each field hashed separately with SHA-256, and a Pulse that bundles name or address into one field has a lower probability of matching even when the underlying data is correct.

The click identifiers matter when the browser captured them. Google sets gclid for Search, Shopping, and other click types, wbraid for web to app, and gbraid for app to web. When any of these is present in the session at purchase time and the store forwards it with the upload, Google can attribute directly to the click. When none is present because the browser blocked storage, the hashed customer data is the fallback identifier.

Hawklists handles the per fact normalization and hashing: email is lowercased and trimmed, phone is normalized to E.164, both are hashed with SHA-256 before delivery, and credentials are encrypted per tenant with AES-256-GCM. The Pulse never carries plain text email or phone to the Channel after the hash step, and PII handling stays at the benefit level in this article without revealing key material or algorithm internals.

A store that sends only email will still see improvement over no customer data, but adding phone in E.164 raises the share of matchable conversions the most. The CAPI event quality checklist guide documents similar field discipline for Meta, and the same attention to per field schema applies to Google offline uploads.

How Consent Mode v2 Controls Whether Google Can Count the Pulse

Consent Mode v2 is the gate before Google is allowed to use the hashed data for advertising measurement, and it is the one Google enforces most strictly for European Economic Area and United Kingdom traffic.

Google introduced Consent Mode v2 in 2023 and began enforcing the two new signals, ad user data and ad personalization, for EEA and UK traffic in March 2024. The four signals are ad storage, analytics storage, ad user data, and ad personalization. A complete implementation sends all four as granted for consenting visitors and all four as denied for non consenting visitors. Without the version two signals, Google treats the setup as version one and may not use hashed customer data for advertising measurement for EEA and UK visitors even when the Pulse reaches Google with correct hashes.

This is why a Shopify store can see healthy Clarity Score per Channel and still show fewer Google reported conversions than Shopify orders. The Stream confirms delivery and the Overview shows the Pulse sent, but Google holds the conversion on its side because the consent state says the data may not be used for ads. The Google Consent Mode v2 guide for Shopify covers the four signals, the difference between basic and advanced, and the two working Shopify implementations that map the Shopify Customer Privacy API to the Google signals.

Offline uploads must carry the current consent state with every Pulse, not a cached default. A stale consent state from an earlier session reads as a mismatch between what the store sent and what the visitor allowed. Google treats the stored consent on the upload as authoritative for that conversion, so a Pulse sent with denied when the visitor actually granted, or the reverse, appears as reduced conversions or modeling rather than as a delivery error.

When consent is denied and the store uses advanced Consent Mode, Google receives cookieless pings that feed its conversion modeling. Google estimates how many denied visitors converted based on the behavior of consented visitors. Google reports that modeling recovers more than half of the ad click to conversion journeys lost to consent on average, with advanced settings recovering about twice as much as basic settings that block tags until consent. The practical rule for offline conversion is to use advanced mode and to verify that both granted and denied paths are exercised, because an offline upload for a denied visitor without the supporting pings has less calibration data for the model.

Sending the Purchase Through the Google Ads Data Manager API

The reliable server side path for Shopify offline purchases is the Google Ads Data Manager API, which is the successor to the earlier offline conversion import for this use case. Google opened Data Manager as the unified ingestion point for first party customer data including Enhanced Conversions and offline uploads, and a connected Google Ads account can accept purchase conversions through it with hashed customer data and optional click identifiers.

Capture happens at order confirmation. When Shopify confirms the order, the server captures the purchase details, order value, currency, and the customer identity data collected at checkout, and formats the upload per Google schema. Because the transmission is server to server, ad blockers, Safari Intelligent Tracking Prevention, and iOS App Tracking Transparency cannot intercept it. This is the same capture point that feeds Meta Conversions API through a separate Channel, which is why one purchase Pulse produces per Channel delivery confirmation in the Stream rather than separate order records.

Authentication uses Google OAuth to the Google Ads account and Data Manager endpoint. The Channel must remain connected, and like any OAuth backed Channel it can expire. A credential check belongs in monthly maintenance because a token that expired yesterday looks connected today and silently stops confirming Pulses.

Deduplication across browser and server matters once both paths are live. When the same purchase is sent through the browser tag and through the offline upload, Google deduplicates on the combination of hashed customer identifiers and click identifier where present. The conversion action in Google Ads should be configured to accept both the browser source and the offline or Data Manager source under the same action name rather than as two separate conversion actions. Separate actions split reporting and force the merchant to reconcile what is actually one purchase counted twice.

A common mistake is uploading purchases as leads. The Google Ads conversion action type must be purchase with value for a Shopify order. A lead conversion expects a different attribution path and reporting, and an upload to the wrong type produces diagnostics that read as formatting errors even when the hashes are correct.

Step by Step Setup on Shopify Without Google Tag Manager

Follow these steps in order. Each one removes a specific failure point, and skipping ahead makes later verification harder.

Step 1: Confirm checkout collects email and phone. Open your Shopify checkout in an incognito window and place a test order with a real email and phone. In Shopify admin, open the order and verify both fields are present on the order, not only in a shipping note or a metafield. Many stores collect phone for fulfillment but do not forward it to the checkout customer object that conversion events read, leaving the second most valuable matching field unused. If you use Shop Pay or an accelerated checkout that skips the customer form, verify that the order still contains email and phone at confirmation, or plan to send that Pulse through the server Channel where the full order object is available.

Step 2: Add the Google tag to the storefront. Add the Google tag, often referred to as gtag, to your Shopify theme so it fires on every page. The current methods are the Google tag placed in theme.liquid or the Shopify Google and YouTube app that Google maintains with Shopify. Verify the tag fires on page load before you configure offline or Enhanced Conversions, because the server upload cannot supplement a tag that never loads. The server-side tracking guide for Shopify explains why the browser tag and the server Channel share capture but diverge on delivery, which is the diagnostic value of this step.

Step 3: Create or confirm the Google Ads purchase conversion action. In Google Ads, open Tools and Settings, then Conversions, and select or create the purchase conversion action for your store. Configure it to accept Data Manager or offline upload as a source in addition to the website tag. Set currency and value handling so the Shopify order value flows through rather than a fixed value. Do not create a separate purchase action for the server source; use one action that accepts both browser and server uploads so reporting stays unified and deduplication works.

Step 4: Map and hash the customer fields. Ensure each customer field is sent in its own parameter and hashed with SHA-256. Lowercase and trim email, convert phone to E.164 with the country code, and split name and address into separate fields. If you send through a signal layer, the transformation and hashing step is handled before delivery. If you send only through an import, confirm that plain text email or phone never leaves the store after the hash step. The CAPI event quality checklist guide covers the same formatting discipline for Meta and the principle applies directly to Google offline uploads.

Step 5: Connect consent state. If you serve EEA or UK traffic, implement Consent Mode v2 before you expect accurate Google reporting. Either install a consent app that maps Shopify Customer Privacy API to the four Google signals or add a short script in theme.liquid that sets defaults to denied and updates them on consent. Test in an incognito window that consent granted shows ad storage, analytics storage, ad user data, and ad personalization as granted, and that consent denied still sends cookieless pings. A Pulse sent with the wrong consent state reads as a held conversion even when delivery is healthy.

Step 6: Connect the Google Ads Channel server side. Connect the Google Ads Channel in your signal layer, authorize the Google Ads account through OAuth, and confirm the Channel shows as connected and Data Manager is selected as the ingestion point. Captured purchase Pulses will now be sent through the Data Manager API in addition to the browser tag, with the same hashed customer data and order value. This Channel is included at the Growth tier at twenty nine dollars per month with unlimited Pulses; the Starter free tier covers roughly five hundred Pulses per month with Meta, and the server side Google Channel is part of paid tiers that carry unlimited volume.

Step 7: Configure deduplication and click identifier forwarding. Forward gclid, wbraid, and gbraid from the session to the server upload when they are present, and ensure the upload and the browser tag share the identifiers Google uses to deduplicate. When both sources send the same purchase, Google should count one conversion, not two. The Stream helps here: each purchase Pulse should show confirmed delivery per Channel rather than duplicate order counts.

Step 8: Measure recovery. Compare Shopify orders to Google Ads reported conversions for the same week and time zone before launch, then again one week after launch. The gap shrinking confirms recovery. Read Clarity Score per Channel on the Overview to distinguish a delivery issue from a matching issue. A low Clarity Score on Google with a healthy Meta score points to a Google specific configuration, such as an invalid field format or an expired OAuth token. A low score on all Channels points upstream to the Shopify capture point.

How to Verify the Pulse Reaches Google

Verification is where most broken offline setups are caught, because a misconfigured field format or a stale consent state looks correct in Shopify admin but fails silently on the Google side.

Start with Google Ads diagnostics. In Google Ads, open Tools and Settings, then Conversions, and select the purchase conversion action. The diagnostics tab reports whether hashed customer data was received, what share of conversions carried user provided data, and whether formatting errors such as a phone number not in E.164 or an email not normalized before hashing are present. A diagnostics panel that shows zero user provided data for a purchase action that should be receiving offline uploads points to a mapping issue rather than a capture issue.

Check the Google tag side separately. Open Google Tag Assistant in a Chrome incognito window, load the store, complete a test purchase with a real email and phone, and confirm that the purchase tag fires on the thank you page and that Enhanced Conversions data is present with hashes rather than plain text where the tag handles hashing. Then confirm that a second server side Pulse for the same order appears in the Stream with confirmed delivery on the Google Ads Channel. Finding the tag firing but the server Pulse missing points to capture or Channel connection rather than to Google schema.

Check per Channel delivery. The Overview in Hawklists shows Clarity Score per Channel as the percentage of captured purchase Pulses confirmed received by each destination. A healthy Clarity Score on Meta with a low score on Google points to a Google specific issue such as an expired token or a schema change on the Data Manager side. A low score on all Channels points to the capture point itself, such as a theme update that moved the confirmation hook. Per Google documentation, Google Ads diagnostics and the Overview measure different things, so a healthy Clarity Score does not guarantee that match coverage is high; it guarantees that delivery reached Google, and match coverage measures whether the data that reached Google was sufficient to credit the conversion.

Check consent handling separately. In a fresh incognito window, accept the banner and confirm in Tag Assistant that the consent tab shows ad storage, analytics storage, ad user data, and ad personalization as granted and that the purchase carries hashed data. Close the window, open a new one, reject the banner, and confirm that defaults are denied and cookieless pings fire. This confirms that granted conversions will be counted and denied conversions will feed modeling rather than disappear.

How to Raise Match Coverage and Keep Clarity Score Healthy

Match coverage is the share of conversions that reach Google with sufficient hashed data to be matchable. Clarity Score is the share of captured Pulses confirmed received per Channel. A store needs both high to recover the full gap.

Improve match coverage by completing the identity set. Sending only email produces some matches, but adding phone in E.164 and, where the store collects them, address fields raises the share of matchable Pulses. Many Shopify stores already collect phone for fulfillment but do not include it in the checkout data passed to conversion events. Forwarding that field is a single configuration change that lifts the match share more than any other adjustment on Google. The shop post that introduced offline uploads through Data Manager emphasizes hashed email and phone as the minimum reliable set for purchase uploads, which is the same principle that drives Match strength on the Meta side.

Keep normalization strict. A phone number sent as 415 555 1234 without the country code or an email sent as JOHN@EXAMPLE.COM without lowercasing will not match even though the underlying customer is a known Google user. The CAPI event quality checklist guide details similar formatting rules, and a weekly review of match diagnostics catches drift the week it starts rather than the quarter it finishes.

Treat Clarity Score as the delivery health check and match coverage as the identity completeness check. When both are visible per Channel, diagnosis is straightforward. A low Clarity Score means delivery is failing before Google can attempt a match; check credentials, connection state, or capture. A healthy Clarity Score with low match coverage means delivery is working but the Pulse carries too little hashable data; complete the customer field set and correct formatting. The Hawk assistant in Hawklists audits the Stream and flags Missed windows where a Pulse lacked the identifiers needed for a match, which is the entry point for finding the checkout or data flow that is suppressing coverage. The Overview also shows anomaly detection for revenue and campaign sync that can surface drift earlier than a manual comparison.

Guard against data drift. Checkout redesigns, new accelerated checkout buttons, or a move to a headless or composable surface can change how customer data flows to the confirmation page. A weekly review of match coverage per Channel catches that drift quickly. The shopify signal loss audit frames this as one of the ongoing checks that keeps Clarity Score and match coverage healthy after launch, and the iOS privacy playbook for Shopify places drift alongside browser privacy changes as the two forces that require regular verification.

Common Failure Points

Offline conversion for Shopify fails quietly. The typical patterns are a Clarity Score drop on the Google Channel, a low match coverage percentage in Google Ads diagnostics, or a persistent order to conversion gap after every other leak reads clean.

The first pattern is credential expiry. Google Ads OAuth tokens and Google Ads Data Manager API access tokens expire, and when they do the Channel stops confirming Pulses while the configuration screen still appears connected. Reauthorizing the Channel and confirming that Clarity Score returns to its baseline is the fix, and it should be part of any monthly maintenance check.

The second pattern is the Google tag or confirmation hook not present at the thank you step. Shopify checkout extensibility in 2024 changed where order status and thank you handlers live, and a customization that defers the Google tag means the browser tag never fires even though the server Channel continues to deliver. This shows up as a reduction in browser attributed conversions that the server upload partially recovers, which masks the underlying break until the store audits why the browser share dropped.

The third pattern is stale or missing consent state. A Pulse sent with a default denied consent state for a visitor who actually granted consent is held on the Google side and appears as reduced conversions even though the Stream shows confirmed delivery. The consent app or custom script must call the update command when the visitor changes their choice, and every Pulse must carry the current state rather than a cached value.

The fourth pattern is identity drift. A theme redesign that stops collecting phone, a shortened checkout that collects only email, or a subscription or app checkout that skips the standard customer form can reduce match coverage even though Clarity Score stays healthy. This is the distinction the Stream makes visible: number of Pulses delivered versus number of Pulses with sufficient hashed identifiers. Track both separately.

A fifth pattern is type mismatch. A store creates a lead conversion action and uploads Shopify purchase orders to it, which produces persistent formatting and category errors in diagnostics. Keep the conversion action as purchase with value and use one action per purchase type so deduplication and value reporting remain correct.

Checklist to Launch and Keep It Healthy

1. Measure the current gap by comparing Shopify orders to Google Ads conversions for the same week and time zone.
2. Confirm checkout captures email and phone and that both fields reach the purchase Pulse at confirmation.
3. Add the Google tag to theme.liquid or through the Shopify Google and YouTube app and confirm it fires on every page.
4. Create or confirm a Google Ads purchase conversion action that accepts Data Manager or offline upload as a source and shares the name with the browser tag action.
5. Map each customer field to the expected Google schema and hash with SHA-256, with phone in E.164 and email lowercased and trimmed.
6. Implement Consent Mode v2 so the current consent state reaches Google with every Pulse for EEA and UK traffic.
7. Connect the Google Ads Channel server side through the Data Manager API and authorize the Google Ads account.
8. Forward gclid, wbraid, and gbraid where present and deduplicate browser and server sources for the same action rather than splitting them into separate actions.
9. Verify through Google Ads diagnostics that hashed data was received and through the Overview that Clarity Score per Channel is healthy.
10. Review Clarity Score and match coverage weekly and re verify on every theme or checkout change.

FAQ

Is Google Ads offline conversion the same as Enhanced Conversions? No. Enhanced Conversions supplements the browser tag with hashed customer data sent alongside the tag. Offline conversion uploads the purchase server side through the Data Manager API after checkout when the browser cannot reliably deliver it. Stores use both so the browser tag handles cooperating browsers and the server upload catches the rest. Hawklists delivers one purchase Pulse to each Channel and measures confirmed delivery per Channel as a Clarity Score.

Do I need Google Tag Manager for offline conversion on Shopify? No. You can run the Google tag plus a server side upload on Shopify without Google Tag Manager. Add the Google tag to your theme or through the Shopify Google and YouTube app, and deliver the same purchase Pulse server side through the Google Ads Data Manager API Channel. A server side tag container is useful when you need to centralize tags across non Shopify surfaces, but it is not required for a standard Shopify purchase flow.

Why does Shopify show more orders than Google Ads reports purchases? Browser restrictions such as ad blockers and Safari Intelligent Tracking Prevention block the tag or expire the click identifier before it reaches Google. Offline upload recovers those conversions by attaching hashed email and phone to the server side Pulse so Google can match the order to the signed in user even without the original cookie or click identifier.

What customer data must I send for offline purchase upload? At minimum send email. For best matching include phone normalized to E.164 plus, where collected, name and address fields split into their expected parameters, and the click identifiers gclid, wbraid, gbraid when the session captured them. Each field is hashed with SHA-256 before transmission. Only send fields the customer provided at checkout and respect current consent state.

How does consent affect offline conversions? Google requires the four Consent Mode v2 signals for EEA and UK traffic: ad storage, analytics storage, ad user data, and ad personalization. When consent is granted, Google matches the hashed data. When consent is denied in advanced mode, Google uses cookieless pings for modeling rather than individual matching. Sending a stale consent state causes Google to hold conversions even when delivery is healthy, which reads as a persistent reporting gap rather than as a delivery failure.

Does Hawklists send purchase data to GA4 or TikTok? No. Hawklists live Channels are Meta Conversions API and Google Ads through Data Manager API. GA4 Measurement Protocol and TikTok, Snapchat, Pinterest, and X are on the roadmap, not shipped Channels. For a comparison table, those cells read as not available for Hawklists in 2026. GA4 sending, Merchant Center, Klaviyo destinations, CSV upload, and digital fingerprinting are also roadmap only.

Related Resources

• The complete Shopify conversion tracking guide explains the full tracking stack that offline conversion sits inside.
• The server-side tracking guide for Shopify covers the no GTM server side implementation that both Meta and Google share.
• The Google Enhanced Conversions guide for Shopify details the tag side path that pairs with offline upload.
• The Google Consent Mode v2 guide for Shopify sets up the consent signals that offline upload depends on for EEA and UK traffic.
• The CAPI event quality checklist guide covers field formatting and quality checks that improve match coverage for both Meta and Google.
• The Shopify signal recovery guide places offline conversion among the other recovery levers for lost purchases.
• What Meta CAPI is for Shopify explains the Meta side of hashed matching for comparison with Google offline uploads.