WooCommerce stores running PR-driven acquisition have richer attribution potential than paid-acquisition stores. They just can’t see it. GA4 buckets press mentions into “direct” or “referral” with no link to the article that drove the visit. The customer reads the BBC piece on Tuesday, browses on their phone, and checks out on their laptop on Saturday. GA4 sees a direct conversion. The journalist who drove the order disappears from the report.
The architectural fix is server-side identity stitching: a persistent first-party ID across visits, email at checkout as the anchor, and a time-window match between the press hit and the eventual order. Once it’s running, you can name the journalists who drive real money.
Why GA4 Can’t See Press Attribution
The default attribution model in GA4 has three structural problems for press-driven stores.
Referrer integrity. Major news sites strip outgoing referrers for privacy and ad-revenue reasons. A user clicking from a BBC article to your store often lands with a blank or scrubbed referrer — GA4 has no way to know they came from BBC. The session bucket goes to “direct.”
Cross-device fragmentation. Press traffic is disproportionately mobile. The user reads the article on their phone during the morning commute, returns later on a laptop, and converts. GA4’s default Default Channel Group assigns the original mobile session and the eventual desktop conversion to two unrelated user IDs. The press touchpoint and the conversion never appear in the same session journey.
Time decay. The default attribution windows in GA4 (typically 30 days for Google channels) work for ad-driven journeys where the click is the touchpoint. Press touchpoints are often not click-driven — the user sees the brand mention, doesn’t click, googles you a week later, and converts. The press hit isn’t in the click stream at all.
Pew Research found that 26% of users end their session entirely after reading an AI summary (Pew Research, 2025). That same fragmentation behaviour applies to press touchpoints — users see the mention, leave, and re-arrive much later via a different surface entirely.
The Cross-Device, Cross-Time Pattern
A typical press-driven WooCommerce conversion looks like this:
- Tuesday 8:42am — User reads a BBC News article that mentions your product. Phone, mobile data, no click.
- Tuesday 11:15am — Same user types your brand name into Google on the same phone. Lands on your homepage. Bounces. GA4 records: Mobile / google / organic / Brand Search.
- Wednesday 2:30pm — User searches the same brand name on their work laptop. Different device, different IP. Lands on the homepage. Browses three product pages. Doesn’t convert. GA4 records: Desktop / google / organic / Brand Search. New user ID. No connection to Tuesday.
- Saturday 7:55pm — User on their personal laptop (third device) goes directly to your store and converts. Enters their email at checkout. GA4 records: Desktop / direct / none. Third user ID.
The journey GA4 records is three unrelated sessions across three users. The journalist who started the chain isn’t visible to any of them. The actual journey is one human, three devices, four touchpoints, five days.
This is the same identity-stitching problem that affects AI Overview citations, ChatGPT referral traffic, and any cross-device path. We covered the AI traffic side in Gemini Just Overtook Perplexity in AI Referrals — same architectural gap, different surface.
The Three Pieces of the Fix
Server-side press attribution needs three things most WooCommerce stores don’t currently run.
1. Persistent First-Party ID
A first-party cookie set on your own subdomain (not shopify.com or klaviyo.com) that survives Safari ITP’s 7-day cap (Apple WebKit) and ad blockers — 31.5% of global users run blockers that drop client-side tracking (Statista, 2024). The ID is generated server-side, stored in a cookie scoped to your subdomain, and refreshed on every visit. When the cookie expires or gets cleared, a new one is issued — but the old one’s history is still queryable in your warehouse.
2. Email-at-Checkout as the Identity Anchor
The first-party ID gives you per-device identity. Email at checkout gives you per-human identity. Most users will check out with the same email regardless of which device they used to browse — so when you stamp the conversion event with the hashed email and the current device’s first-party ID, you’ve created a join key that links every previous device’s first-party ID to the same human.
The pattern is: at checkout, generate a SHA256 hash of the lowercased email. Stamp it on the order event. In your warehouse, build a dimension table that maps email_hash → all first-party IDs that have ever used this email. Every previous browsing session from any device now joins to this human.
3. Time-Window Matching for Press Signal
Press visits often arrive without a referrer. But they’re not invisible — they have signatures. A burst of new first-party IDs landing on a specific product page within a few hours, with no Google referrer, no Meta click ID, and no email match to existing customers, is press traffic. The Tuesday 8:42 BBC mention doesn’t show as a referral, but it shows as a 200-visit spike on /products/the-thing-you-make within the hour the article went live.
The time-window match is: for each known press hit (from a press-monitoring service like Mention or Meltwater, or just a manual log of major coverage), join all sessions that landed within ±2 hours of the publication time, on a landing page that matches the product or brand mentioned, with no organic or paid referrer. Those sessions are press-attributable.
The Query That Names the Journalist
Once the three pieces are running, the BigQuery query is straightforward:
SELECT
press_hit.publication,
press_hit.journalist,
press_hit.url,
COUNT(DISTINCT order_event.email_hash) AS attributed_buyers,
SUM(order_event.order_total) AS attributed_revenue
FROM press_hits AS press_hit
JOIN page_view_events AS pv
ON pv.timestamp BETWEEN press_hit.published_at
AND TIMESTAMP_ADD(press_hit.published_at, INTERVAL 2 HOUR)
AND pv.landing_page LIKE CONCAT('%', press_hit.landing_page_match, '%')
AND pv.referrer NOT LIKE '%google.com%'
AND pv.referrer NOT LIKE '%facebook.com%'
JOIN order_events AS order_event
ON order_event.first_party_id_history @> ARRAY[pv.first_party_id]
AND order_event.created_at <= TIMESTAMP_ADD(pv.timestamp, INTERVAL 30 DAY)
GROUP BY publication, journalist, url
ORDER BY attributed_revenue DESCThe output is a ranked list: which journalist, at which publication, drove which dollar amount in the 30-day window after their article ran. That list is your PR budget. The names at the top are the people you pitch first next quarter.
Why This Doesn’t Work Inside GA4
Even with GA4’s cross-device User-ID feature enabled, the press attribution still fails for the same structural reasons. GA4’s User-ID requires the user to be logged in at every touchpoint — but press readers aren’t logged in until they convert. GA4’s default channel-group rules cannot be extended with a “press hit at this URL within this time window” rule. And BigQuery export of GA4 data still inherits GA4’s session boundaries, so a join that crosses sessions has to fight GA4’s data model rather than work with it.
The architecture that works is the one that captures every page view independently of session, with a stable per-device ID, and ties them all to the email at checkout. That architecture lives in a server-side first-party pipeline, not in GA4. The same pattern handles AI Overview citation revenue, ChatGPT referrals, and any other channel where the customer journey crosses devices, time, or referrer boundaries — see The Eight Hops a WooCommerce Conversion Has to Survive for the broader fragility map.
How Seresa Captures Press Attribution
Transmute Engine™ is a first-party Node.js server that runs on your own subdomain (for example, data.yourstore.com). The inPIPE WordPress plugin captures every WooCommerce page view with a persistent first-party ID and stamps every order event with the hashed email at checkout, then sends them via API to Transmute Engine, which streams them into BigQuery alongside GA4, Meta CAPI, and Google Ads. The press-hit time-window join lives in your warehouse, on your data, and runs against every press hit you log — independent of whether the article linked to your store.
Key Takeaways
- GA4 cannot see press attribution. Referrer-stripping by major news sites, cross-device fragmentation, and the lack of click-stream events on press touchpoints all conspire to bucket press traffic into “direct” or “referral” with no article link.
- The fix is three pieces. Persistent first-party ID per device, hashed email at checkout as the human-identity anchor, and time-window matching against a press-hit log to attribute referrer-less visits.
- The output is a ranked journalist list. A BigQuery query that joins press hits to page views to orders by first-party ID, returning publication, journalist, URL, attributed buyers, and attributed revenue.
- The journey is real. A typical press-driven conversion is one human, three devices, four touchpoints, five days. GA4 records three unrelated sessions across three users; the journalist who started the chain is invisible.
- The architecture is the same one that handles AI Overview citation revenue, ChatGPT referrals, and any other channel where the customer journey crosses devices, time, or referrer boundaries.
FAQ
Two reasons. First, major news sites strip outgoing referrers for privacy and ad-revenue protection — so the visit lands at your store with no source URL, defaulting to direct. Second, even when the referrer survives, the GA4 default Default Channel Group has no rule for this referrer is a press mention — it just buckets the publication’s domain as referral / [publication.com] with no journalist or article-level breakdown. The result is the same either way: GA4 cannot tell you which press mention drove which conversion.
Two hours for the initial visit-attribution match — most press-driven traffic spikes within 60-120 minutes of publication, and a 2-hour window captures the bulk without picking up unrelated organic traffic. Then 30 days for the conversion-window match — most press-driven conversions complete within 14 days, with a long tail running to 30. Adjust the conversion window based on your product’s typical decision cycle: longer for high-consideration items, shorter for impulse purchases.
This is the more common case, and it’s the reason the time-window match exists in the first place. When an article mentions your brand without linking, readers Google your name and arrive via brand-search organic traffic — bucketed by GA4 as google / organic / Brand Search with no connection to the article. The time-window match catches these by joining press-hit publication times to brand-search session spikes within the same window, attributing the brand-search traffic to the press hit that triggered it.
Technically yes, in any analytical database — Snowflake, Postgres, Redshift, ClickHouse, DuckDB. The pattern is database-agnostic; what matters is the data architecture: per-device first-party ID per page view, hashed email per order, and a press-hits log. The reason most WooCommerce stores end up in BigQuery is the GA4 free tier export — having GA4 data and your own server-side data side-by-side in the same warehouse is what makes the join cheap. If you’re not on GA4, any warehouse works.
If your PR budget is more than one journalist’s coffee, you should be able to name which one. See how Transmute Engine stitches per-device first-party IDs to email-at-checkout in your own BigQuery warehouse.
