Fix GA4 "(not set)"/Unassigned Traffic on Orders — 2 PrestaShop Stores

JOB TITLE Fix GA4 "(not set)" / Unassigned Traffic on Orders - 2 PrestaShop Stores (Success-Based Pay) JOB DESCRIPTION We run a digital agency managing several PrestaShop e-commerce stores, and we've identified a tracking/attribution issue affecting 2 of our stores that we need a GA4/GTM specialist to diagnose and fix. THE PROBLEM A large share of our completed orders are landing in Google Analytics 4 with Session source/medium = "(not set)" (which rolls up into the "Unassigned" channel), even though the revenue and purchase event itself is recorded correctly. This is distorting our channel-attribution reporting and, in cases where a store's primary Google Ads conversion is imported from GA4, it can also be starving Smart Bidding of real conversion data. Below is a real 7-day sample from one of the two stores, pulled from a GA4 Exploration (Session default channel group, Session source/medium, Transaction ID, Revenue). Order IDs and revenue are real; this is a representative sample of the pattern across dozens of orders: Channel: Referral, Source/medium: (not set), Order: 6877, Revenue: 40.95 EUR Channel: Organic Search, Source/medium: (not set), Order: 6876, Revenue: 69.42 EUR Channel: Organic Search, Source/medium: google / organic, Order: 6875, Revenue: 142.14 EUR Channel: Organic Search, Source/medium: (not set), Order: 6872, Revenue: 51.97 EUR Channel: Organic Social, Source/medium: (not set), Order: 6871, Revenue: 75.49 EUR Channel: Referral, Source/medium: (not set), Order: 6869, Revenue: 65.91 EUR Channel: Organic Search, Source/medium: (not set), Order: 6868, Revenue: 39.85 EUR Channel: Organic Social, Source/medium: (not set), Order: 6867, Revenue: 48.41 EUR Channel: Paid Search, Source/medium: (not set), Order: 6866, Revenue: 77.09 EUR Channel: Paid Search, Source/medium: (not set), Order: 6864, Revenue: 50.50 EUR Channel: Paid Search, Source/medium: (not set), Order: 6861, Revenue: 74.76 EUR Channel: Organic Search, Source/medium: (not set), Order: 6859, Revenue: 148.80 EUR Channel: Referral, Source/medium: (not set), Order: 6858, Revenue: 40.87 EUR Channel: Organic Search, Source/medium: (not set), Order: 6857, Revenue: 142.49 EUR Channel: Direct, Source/medium: (direct) / (none), Order: 6856, Revenue: 130.68 EUR Channel: Referral, Source/medium: (not set), Order: 6855, Revenue: 110.32 EUR Channel: Referral, Source/medium: (not set), Order: 6854, Revenue: 163.77 EUR Channel: Referral, Source/medium: (not set), Order: 6853, Revenue: 100.66 EUR Channel: Organic Search, Source/medium: (not set), Order: 6851, Revenue: 27.29 EUR Channel: Referral, Source/medium: (not set), Order: 6851, Revenue: 194.51 EUR Roughly 60-70 percent of order-rows in this sample show "(not set)" as source/medium, spread across "Referral", "Organic Search", "Organic Social", "Direct" and "Unassigned" default channel groups. Note the same order ID sometimes appears split across multiple channel/source rows, likely due to multiple sessions/products contributing to one order. WHAT WE'VE ALREADY RULED OUT - PLEASE DON'T RE-TEST THESE We spent a full diagnostic session today on one of the two stores (live testing via GA4 DebugView, GTM Preview, and the browser Network tab through a real test purchase via Redsys), and confirmed the following are NOT the cause: - htaccess / Apache redirect rules stripping gclid/UTM params (checked - standard PrestaShop-generated rules, no missing QSA flag issue) - GA4 "unwanted referrals" list - already correctly includes the payment gateway domains (Redsys, PayPal, Stripe, Bizum), and confirmed working (ignore_referrer=true seen on a real purchase event) - GA4 session cookies (_ga and the per-stream session cookie) being lost when returning from the external payment gateway - confirmed they survive intact round-trip - GTM tag firing order - the GA4 Configuration tag fires very early, before third-party tags (Meta Pixel, Quantcast, etc.) - Consent Mode defaulting to "denied" - confirmed analytics_storage and ad_storage are "Granted" by default on page load - Google Ads conversion action for "Purchase" - already correctly set as Primary, sourced from the native website tag (not imported from GA4), so Smart Bidding isn't blinded by this on the Ads side - Campaign parameters (utm_source, utm_medium, gclid) being stripped from the URL before GA4 can read them - confirmed intact in the first page_view's page_location parameter WHAT'S SUSPECTED BUT NOT YET CONFIRMED Session inheritance from a previous, still-open session. GA4's default session timeout is 30 minutes (unchanged on this store). We suspect that returning visitors whose browser still has an active/recent GA4 session (from earlier normal browsing, not necessarily from an ad click) may be inheriting that older session's source/medium instead of starting a fresh, correctly-attributed session tied to their most recent campaign click. This would fit the real-world pattern we see: relatively few sessions land in "(not set)", but they convert to purchase at a disproportionately high rate, consistent with returning/familiar visitors rather than brand-new ones. Consent-denied fallback fragility. For visitors who reject the cookie banner, the site relies on a url_passthrough / linker-parameter mechanism (a documented GA4 Consent Mode fallback) to carry client/session identity instead of a cookie. This mechanism does not survive the round-trip to the external Redsys payment page (Redsys' return URL carries no Google identifiers at all), so any session depending purely on that mechanism would lose its identity on return. We were not able to fully confirm either hypothesis today due to test methodology limitations (repeated tests from the same browser/device made it hard to isolate a truly cold session). SCOPE OF WORK 1. Confirm or rule out the session-inheritance and consent-fallback hypotheses above, using GA4 DebugView, GTM Preview, and live test purchases on both stores. 2. Identify the root cause or causes of "(not set)" / Unassigned attribution on completed orders. 3. Implement the fix (GTM configuration changes, GA4 settings, and/or PrestaShop/module-level code changes as needed). 4. Validate the fix with live test purchases and confirm the "(not set)" rate drops meaningfully over the following days once GA4 has processed the data. 5. Repeat steps 1-4 on the second store (same platform, PrestaShop, likely similar setup; full diagnosis pending). ACCESS WE CAN PROVIDE - Google Analytics 4 (Admin access to the property/data stream) - Google Tag Manager (container access, both stores) - Google Ads (read access to conversion settings) - PrestaShop back office (both stores) - FTP/SSH or hosting panel access as needed (one store runs on LiteSpeed hosting) REQUIREMENTS - Strong hands-on experience debugging GA4 (DebugView, Explorations, session/channel attribution model) and Google Tag Manager (Preview mode, tag sequencing, Consent Mode v2) - Experience with PrestaShop and its payment module / checkout flow - Familiarity with Measurement Protocol / server-side tagging is a plus - Clear, direct communication - we will be validating findings with our own tests in parallel PAYMENT TERMS This is a success-based engagement. Payment is released only once the fix is confirmed working: the root cause is identified, the fix is implemented, and we jointly validate via live test purchases and a measurable drop in "(not set)" / Unassigned attribution over the following days. Please propose your rate/structure with this in mind, for example a milestone tied to root-cause confirmation, and a final milestone tied to verified resolution.