TL;DR
Google's user-provided data collection lets GA4 match hashed customer details with Google's own data, which Google uses for measurement accuracy, Customer Match audiences, enhanced conversions for GA4 conversions and demographics. On a Shopify store running the app, the purchase GA4 receives from the order already includes those details whenever the order has them, on every plan. The GA4 property setting decides whether Google processes them. It reaches purchases only: browser events carry no customer data, and a Google tag can't read Shopify's checkout. Expect up to a month before anything shows in reports.
Key Takeaways
- Turn it on at
Admin → Data collection and modification → Data collection, under User-provided data collection; you need Editor or above at the property level [1]. - Acknowledging the policy is permanent; the setting isn't. Unchecking it means Google won't "process user-provided data in the Google Analytics property" [1].
- Skip Allow user-provided data capabilities on the data stream unless you also want the Google tag to look for emails on theme pages. The app's purchase doesn't need it [2].
- Properties in the Health industry category can't use the feature at all [1].
- Google's validation check looks for an
emparameter in browser requests to/g/collect[3]. The app's purchase never passes through the browser, so that check shows nothing on Shopify, and that's expected. - Write down the date you switch it on. Model and attribution changes "may take up to one month to appear" [1].
What the app already sends with each purchase
The purchase event the app sends GA4 for an order carries a user_data block alongside the usual order details. It's sent server-side through the Measurement Protocol (the route is explained in our Measurement Protocol primer), and it holds what the order knows about the buyer:
| Field | How it's sent | Preparation |
|---|---|---|
| SHA-256 hash | Lowercased and trimmed, Gmail dots removed, following Google's email rules [4] | |
| Phone | SHA-256 hash | Formatted to the international format (E.164) using the order's country where it can be parsed, cleaned to digits otherwise |
| First name, last name, street | SHA-256 hash | Lowercased, symbols removed, trimmed |
| City, region, postal code, country | Plain text | Lightly cleaned |
Google's help page says that on the Measurement Protocol route "you must use SHA256 to hash the data before sending it to Google" [1], and the four hashed rows above follow that. A field the order doesn't have is simply left out, so a checkout with no phone number sends the email and address only. The details come from the order's customer and address fields.
This runs on every plan, including the free one, since GA4 is the free plan's integration. There's no app setting for it to switch on. Click identifiers travel separately from this block, and whether they reach your orders at all is a different check.
Nothing on the store changes when you flip the GA4 switch. With the app installed, the data is already in the request, and the switch decides whether Google uses it.
How do you turn on user-provided data collection?
The setting lives on the GA4 property, and it applies to every route that sends data to it: the Google tag, Tag Manager and the Measurement Protocol [1].
- In GA4, click Admin (the gear icon, bottom left).
- Under Data collection and modification, click Data collection.
- In User-provided data collection, click Turn on.
- Review Google's User-provided data policy and acknowledge it. Google describes the feature as being for "your consented, first-party data from your website" [1], and the policy is yours to meet.
- Confirm the toggle now shows as on.
You must be "an Editor or above on the Google Analytics account at the property level" to do this [1]. If your property's industry category is Health, the option isn't offered [1].
There's a second setting elsewhere, on the web stream: Admin → Data streams → (your stream) → Configure tag settings, Allow user-provided data capabilities. That one is part of the gtag.js setup [2]. It lets the tag pick up details through automatic detection, CSS selectors, JavaScript variables or a code snippet [2]. The property switch covers every data stream in the property [1], and the app's purchase brings its own user_data [4].
Should you turn the stream setting on anyway? Only if you want the tag to collect emails people type into theme pages. Either choice is fine, and the next section explains how little it reaches on Shopify.
Why can't automatic detection read your checkout?
Automatic detection works by having Google Analytics inspect "your web pages for strings that match the pattern for email addresses, phone numbers, names, and addresses" [2]. It can only inspect pages the Google tag runs on.
On Shopify, the page where a buyer types an email, phone and address is checkout. Checkout and the thank-you page aren't theme pages, so the Google tag in your theme isn't there (the changes are covered in our checkout extensibility piece). A tag placed in a custom pixel doesn't fix it either: Shopify runs custom pixels in a sandbox that "cannot access the top frame" [6], so a script there can't scan the checkout's form fields. This is our reading of Shopify's documented sandbox; we haven't measured it.
What's left for automatic detection is a theme page with an email field on it, like a newsletter form, the login page or the contact form.
The app's own browser events don't fill the gap. Page views, product views, add to cart and the checkout steps go to GA4 with no customer data on them, partly because Shopify withholds most of it from pixels in the first place (what a web pixel can and can't see, and why the email is usually missing).
So on a Shopify store, user-provided data is a purchase-time signal. GA4 gets it once per order, at the end of the funnel.
What GA4 does with the data
Google lists the uses on its help page [1]:
- matching against other Google data "to improve the accuracy of your measurement data"
- Customer Match support for GA4 audiences exported to linked Google advertising products
- enhanced conversions support for Google Analytics conversions
- demographic and interest reporting based on first-party data and consented, signed-in Google user data
None of this is Google Ads enhanced conversions, which is set up in your Google Ads account and has its own settings in the app. That product is covered in our Google Ads enhanced conversions guide. Google signals, which also feeds demographics, has its own story after the June 2026 change, told in our June 2026 consent change audit.
The data is kept for as long as your property's user data retention allows, "2 or 14 months" [1]. Google publishes no match rate or uplift figure for GA4's user-provided data, and none of the pages we read describe a report that shows how many purchases matched.
One gap to know about: the app sends no User-ID on any GA4 event. Google's Measurement Protocol guide says "We recommend that you also include the user_id parameter whenever user_data is provided" [4]. It's a recommendation, not a requirement, and the difference between the two IDs is in our client ID vs User-ID explainer.
There's a quirk on the other side of that pairing. In May 2024, on the Magento side, we found in our own testing that once the policy had been acknowledged, Measurement Protocol events carrying a user_id without a user_data block were discarded (the Magento write-up). Google doesn't document it; it's what we saw. It doesn't apply here, since the app's purchase sends user_data and no event sends a user_id.
Where does consent come in?
The app's server-side purchase doesn't include a consent field. For requests like that, Google's Measurement Protocol reference says "Google Analytics uses the consent settings from corresponding online interactions for the client or app instance" [5].
The app has one optional setting on this path, in Advanced Settings for GA4: Skip purchase events for visitors who declined analytics. It's available on every plan and off by default. It does nothing unless Respect Customer Privacy Settings is on, and when it applies it drops that visitor's whole purchase. There's no separate switch for the customer details.
Browser events respect Shopify's Customer Privacy API signals. If your banner and Consent Mode defaults still need setting up, our Consent Mode v2 guide walks through it.
Check it without Google's validation steps
Google's page for validating user-provided data describes one method: open Chrome's developer tools, find the request to www.google-analytics.com/g/collect, and look for an em parameter starting with tv.1~em [3]. The method checks the browser tag. The app's purchase goes from the server, so that request never carries it, and Google documents no equivalent screen for the Measurement Protocol.
Use this instead:
- In GA4, go back to Admin → Data collection and modification → Data collection and confirm User-provided data collection is on. Note the date.
- Confirm purchases are reaching GA4 at all. The Realtime report shows them as they arrive, and DebugView shows each event's parameters once you turn on GA4 debug mode in the app (our DebugView walkthrough). Turn debug mode off afterwards.
- In the app, open the home page's Conversion tracking card. It shows GA4's sent, attempted and skipped counts for the last 7 days. If GA4 purchases aren't going out, the user data isn't either.
- If you turned on Skip purchase events for visitors who declined analytics, expect fewer purchases in GA4 than orders in Shopify. Part of that gap is the setting working.
- Wait. Give it a month from the date in step 1 before reading anything into GA4 or Google Ads reports [1].
There isn't a sixth step that confirms the hashed fields landed. Google doesn't offer one for this route.
FAQ
Do I need "Allow user-provided data capabilities" turned on for the app's purchases?
No. That stream setting belongs to the gtag.js setup [2]. The property-level switch covers all the property's data streams [1], and the app's purchase carries its own user_data block [4].
Is GA4 user-provided data the same as Google Ads enhanced conversions?
No. They're separate products with separate settings. GA4's version supports enhanced conversions for Google Analytics conversions [1], while Google Ads enhanced conversions is turned on in your Google Ads account.
Can I turn user-provided data collection off later?
Yes. The policy acknowledgement stays, but unchecking the setting means Google won't process user-provided data in that property [1].
Does the free plan send customer data with the GA4 purchase?
Yes. GA4 is the free plan's integration, and the purchase carries the same hashed details on every plan whenever the order has them.
Send GA4 the purchase it can match
WeltPixel Conversion Tracking sends GA4 a server-side purchase for your orders, with the buyer's email, phone, name and street hashed in the request, so turning on user-provided data collection in GA4 is the only step left on your side. GA4 is on the free plan; Google Ads, Meta, TikTok, Reddit, Pinterest, Snapchat, OpenAI Ads and Klaviyo come with Plus at $39/month [7].
Sources
- Google Analytics Help, "User-provided data collection", support.google.com/analytics/answer/14077171, accessed October 6, 2026
- Google Analytics Help, "Collect user-provided data (gtag.js)", support.google.com/analytics/answer/14078702, accessed October 6, 2026
- Google Analytics Help, "Validate your user-provided data implementation", support.google.com/analytics/answer/14171683, accessed October 6, 2026
- Google for Developers, Measurement Protocol, "Send user-provided data", developers.google.com/analytics/devguides/collection/ga4/uid-data, last updated August 19, 2026, accessed October 6, 2026
- Google for Developers, Measurement Protocol reference, developers.google.com/analytics/devguides/collection/protocol/ga4/reference, last updated September 30, 2026, accessed October 6, 2026
- Shopify developer documentation, "Pixels", shopify.dev/docs/apps/build/marketing-analytics/pixels, accessed October 6, 2026
- WeltPixel Conversion Tracking, Shopify App Store listing, apps.shopify.com/weltpixel-conversion-tracking, accessed October 6, 2026