Why BigQuery ML Predictions Fail With ETL-Only WooCommerce Data

What ETL Actually Delivers to BigQuery

ETL tools sync database records reliably — but the WooCommerce REST API limits what they can extract to just 6 entity types.

Connect Coupler.io or Skyvia to your WooCommerce store and here’s exactly what flows into BigQuery: orders, products, customers, coupons, refunds, and shipping records. That’s the complete list. Six database entity types. Zero behavioral events. These tools aren’t broken — they’re doing precisely what they were designed to do.

The WooCommerce REST API exposes only structured database records. It doesn’t track which pages a visitor viewed, which products they browsed, whether they added something to their cart and then abandoned it, or how far through checkout they progressed before leaving. Those are browser-side activities that the REST API was never built to capture.

For reporting, this is fine. You can answer “what happened” — which customers bought, what they spent, when the orders came in. ETL gives you a receipt. It doesn’t give you a behavioral profile.

You may be interested in: Your WooCommerce BigQuery Integration Is Missing 90% of Your Data

The Behavioral Data Gap That Breaks ML Models

Machine learning models are only as smart as their input features — and order records alone don’t predict future behavior.

GA4’s recommended ecommerce implementation requires 12+ behavioral events — from view_item through purchase. ETL tools can access exactly none of them through the WooCommerce REST API. That’s not a marginal gap. When the average ecommerce conversion rate sits at 1–3%, ETL-only integrations miss 97–99% of visitor behavior.

Consider what happens between a first visit and a purchase. A visitor lands on your site, browses three product pages, adds one item to their cart, removes it, comes back two days later, browses five more pages, adds two items, starts checkout, enters their email, then abandons at the shipping step. They return a week later and complete the purchase.

ETL captures one row: the final order. Everything else — the browsing pattern, the cart hesitation, the checkout abandonment, the return visit — is invisible. The model never learns that this customer needed three sessions and a cart abandonment before converting.

With average ecommerce conversion rates at 1–3%, ETL-only BigQuery integrations miss 97–99% of visitor behavior because page views, cart actions, and checkout steps never reach the warehouse.

Cart abandonment averages 70.19% across ecommerce according to Baymard Institute research. That’s an entire funnel stage — arguably the most diagnostic one for predicting future purchases — that remains completely invisible in ETL-synced BigQuery tables. You can’t predict which customers will buy if you can’t see which customers almost bought.

What BigQuery ML Actually Needs for Predictions

BigQuery ML runs on SQL and is free for built-in models — but the quality of features determines whether predictions are useful or noise.

BigQuery ML lets you create and train machine learning models directly inside BigQuery using standard SQL. No separate ML platform. No Python notebooks. BigQuery ML CREATE MODEL runs at standard BigQuery query pricing — no additional ML service fees for built-in model types. That means the same store owner querying sales data can build a churn prediction model.

The barrier isn’t cost or complexity. It’s data. A churn prediction model needs features that represent recent behavior — login frequency, page views, session duration, feature usage, support interactions. A CLV model needs behavioral sequences — browsing depth, cart activity, purchase cadence alongside monetary values. A purchase propensity model needs real-time session signals — which pages this visitor has viewed today, whether they’ve interacted with product detail pages, and how their current session compares to their historical pattern.

Transaction-only features give you recency, frequency, and monetary value — the RFM triad. That’s a starting point, not a prediction engine. Research consistently shows that models built on RFM alone perform significantly worse than those incorporating behavioral signals.

Customer lifetime value predictions improve 2–3× in accuracy when behavioral event data supplements transaction history. That gap isn’t subtle. It’s the difference between a model that correctly identifies your top 20% of customers and one that misclassifies half of them.

Customer lifetime value predictions improve 2–3× in accuracy when behavioral event data supplements transaction-only records in BigQuery ML models.

ETL vs Event Streaming: Feature Comparison

A side-by-side look at what each data pipeline approach actually delivers to your BigQuery ML training tables.

ML Feature Category	ETL (Coupler.io / Skyvia)	Event Streaming
Order history (recency, frequency, monetary)	Yes — synced from WooCommerce orders table	Yes — captured at purchase event
Product catalog data	Yes — synced from products endpoint	Yes — enriched with view and cart context
Customer profile data	Yes — synced from customers endpoint	Yes — enriched with behavioral segments
Page views per session	No — REST API doesn’t expose this	Yes — page_view events with URL and timestamp
Product detail page views	No	Yes — view_item events with product ID
Add-to-cart actions	No	Yes — add_to_cart events with product and quantity
Cart abandonment	No	Yes — cart sessions without purchase completion
Checkout step progression	No	Yes — begin_checkout, add_shipping, add_payment
Session duration and depth	No	Yes — calculated from event timestamps
Time between sessions	No — only order timestamps available	Yes — session-level timestamps with user stitching
Scroll depth and engagement	No	Yes — scroll and engagement events
Data freshness	15-minute to daily sync schedules	Real-time streaming insert

ETL covers 3 of 12 ML feature categories. That’s 25% feature coverage. The remaining 75% — the behavioral features that actually differentiate high-value customers from one-time buyers — never reaches your BigQuery tables through an ETL pipeline.

The CLV and Churn Prediction Impact

The practical consequences of the data gap show up in every ML use case a WooCommerce store would actually run.

Take the three most common BigQuery ML use cases for ecommerce: customer lifetime value prediction, churn prediction, and purchase propensity scoring. Each one degrades differently when behavioral data is missing, but all three fail for the same fundamental reason — the model can’t distinguish between customers who behave differently but look identical in the orders table.

CLV prediction without behavioral data treats every $100 customer the same. But a customer who browsed 47 pages across 6 sessions before purchasing is fundamentally different from one who clicked a paid ad and bought immediately. The first customer is exploring your catalog, building familiarity, and likely to return. The second may never come back. Without session and browsing data, the model assigns them identical predicted lifetime values.

AI-driven CLV models show approximately 15% increases in predictive accuracy when incorporating deep behavioral features beyond transaction records. And Bain research demonstrates that a 5% improvement in customer retention can increase CLV by 25–95% depending on margins. Small improvements in prediction accuracy compound into significant revenue impact when they inform retention spending.

Churn prediction suffers even more acutely. A customer who hasn’t purchased in 90 days looks identical in ETL data whether they’ve visited your site 12 times in the last month (still engaged, comparing options) or haven’t visited once (actually gone). Without session data, your churn model can’t tell the difference between a customer deliberating and a customer who’s disappeared.

Purchase propensity scoring requires the freshest behavioral data — what is this visitor doing right now, in this session? ETL data running on 15-minute to daily sync schedules can’t inform real-time scoring. The visitor has already left by the time the data arrives.

You may be interested in: BigQuery ML Predicts Which Customers Buy Again — If You Feed It the Right Data

Fixing the Data Foundation

The path from ETL-only reporting to ML-ready behavioral data requires a shift in pipeline architecture, not a bigger ETL budget.

The fix isn’t a better ETL tool. The architectural boundary is the WooCommerce REST API itself — it doesn’t expose behavioral events, and no amount of ETL sophistication changes what the API makes available. The solution is event streaming: capturing browser-side behavioral events at the server level and routing them directly to BigQuery’s Streaming Insert API.

GA4 BigQuery Export partially addresses this. It streams event-level data including page views and ecommerce events. But GA4 data comes with consent-mode gaps, thresholding in reports, sampling at high volumes, and session-stitching limitations. When a visitor denies consent, the behavioral events either don’t fire or arrive in heavily modeled form. For ML training data, you need observed signals — not statistical estimates.

A first-party event streaming pipeline captures the same behavioral events without depending on a third-party tag that the browser or consent banner can block. Running as a server-side process on your own domain, it captures page views, product views, cart actions, checkout steps, and purchases — then writes them directly to BigQuery tables structured for ML feature engineering.

The practical architecture looks like this: keep your ETL tool for what it does well — syncing order records, product catalogs, and customer profiles on schedule. Layer event streaming on top to capture the behavioral signals that ETL structurally cannot access. Your BigQuery tables then contain both the transaction history and the behavioral features that BigQuery ML needs to produce predictions worth acting on.

Transmute Engine™ takes this approach. As a first-party Node.js server running on your subdomain, it captures the complete behavioral event set and routes events to BigQuery alongside other destinations like GA4 and Meta CAPI. The result: BigQuery tables with both transaction records and the behavioral columns that turn a reporting database into a prediction engine.

Key Takeaways

• ETL syncs receipts, not behavior: WooCommerce REST API exposes 6 entity types — orders, products, customers, coupons, refunds, shipping. Zero behavioral events. ETL tools can only extract what the API provides.
• 97–99% of visitor behavior is invisible: At 1–3% ecommerce conversion rates, only the visitors who complete a purchase generate ETL-accessible data. Everyone else — browsers, cart abandoners, checkout dropoffs — is missing from your BigQuery tables.
• CLV predictions degrade 2–3× without behavioral features: Transaction-only RFM features produce significantly less accurate predictions than models incorporating page views, session patterns, and cart activity.
• The fix is architectural, not incremental: No ETL tool upgrade solves this. Event streaming captures browser-side behavioral events at the server level — the data type that the WooCommerce REST API was never designed to expose.
• Both pipelines together create the ML-ready foundation: ETL for structured records plus event streaming for behavioral signals gives BigQuery ML the complete feature set for accurate, actionable predictions.

References

• WooCommerce REST API Documentation (2025)
• Google Analytics Developer Docs — GA4 Ecommerce Events (2025)
• Google BigQuery Pricing — ML Model Training (2025)
• Google Cloud Marketing Analytics — CLV Prediction Benchmarks (2025)
• Baymard Institute — Cart Abandonment Rate Statistics (2025)
• Madgicx — Deep Learning Models for Customer Lifetime Value (2025)
• Bain & Company — The Loyalty Effect: Retention and CLV (2025)
• OWOX — BigQuery ML.PREDICT Inference Guide (2025)
• Google Cloud Blog — BigQuery AI and ML Tools (2025)

Your WooCommerce data is already in BigQuery — or it could be. The question is whether it contains receipts or behavior. Talk to Seresa about closing the gap →