Python (pandas, scipy, scikit-learn)

Python's analytics ecosystem is unmatched in breadth. But breadth without discipline creates complexity. The production-grade Python analytics workflow requires: dependency management (poetry or uv, not pip install into global), reproducible environments (pyproject.toml with pinned versions), structured project layouts (src/ layout with separate notebooks/ and tests/ directories), and CI-tested transformation code. Jupyter notebooks are for exploration, not production. Extract validated logic into importable modules, test them, version them, deploy them.

pandas 3.0's Arrow-native backend changes the performance calculus for analytics workloads. PyArrow-backed DataFrames use columnar memory layout, which means analytical operations (groupby, merge, window functions) on million-row event datasets run 2-5x faster with 50% less memory. The API is backward-compatible — you get the speedup by setting pd.options.mode.dtype_backend = 'pyarrow'. For analytics datasets exceeding 100M rows, consider Polars (which is Arrow-native by design) or DuckDB's Python API for even better performance.

scikit-learn for behavioural modelling follows a specific pattern refined over dozens of implementations. Feature engineering: compute session-level features (page_count, duration, scroll_depth_mean, bounce_flag, conversion_flag), user-level features (session_count, recency_days, frequency, monetary_value, channel_diversity), and temporal features (hour_of_day, day_of_week, days_since_first_visit). Pipeline: StandardScaler → feature selection (mutual_info_classif) → GradientBoostingClassifier. Evaluation: stratified k-fold cross-validation, ROC-AUC and precision-recall curves, calibration plot for probability reliability. Feature importance: SHAP values, not built-in feature_importances_ (which are biased toward high-cardinality features).

Statistical testing in web analytics requires methodology awareness. For conversion rate A/B tests: proportions_ztest from statsmodels (frequentist) or scipy.stats.beta for Bayesian posteriors. For revenue per user: Mann-Whitney U (mannwhitneyu from scipy) because revenue is never normally distributed. For time-series comparisons: CausalImpact for pre/post interventions, or BSTS (Bayesian Structural Time Series) from tfp (TensorFlow Probability). Never use t-tests on conversion rates or revenue data — the distributional assumptions are violated, and your p-values will be wrong.

The BigQuery integration workflow: google-cloud-bigquery client → DataFrame. But for large extractions (10M+ rows), use the BigQuery Storage API (read_gbq with use_bqstorage_api=True), which streams data in Arrow format and is 10-100x faster than the standard REST API. For write-back: load_table_from_dataframe with Parquet serialisation and WRITE_TRUNCATE disposition. Automate this with a thin wrapper that handles credentials, project selection, and cost logging.

Robin Signals' integrated Python environment eliminates the most friction-heavy step in the analytics workflow: getting the data. Instead of querying BigQuery → downloading → loading into pandas → discovering the data is stale → re-querying, you write Python directly against the live event stream. The iteration cycle drops from hours to minutes. For exploratory analysis — hypothesis generation, anomaly investigation, segment discovery — this co-location of compute and data is transformative.

Environment reproducibility is the difference between analysis and science. Use poetry.lock or uv.lock. Pin numpy, pandas, scikit-learn, and scipy versions explicitly. Test your analysis code in CI. When someone asks 'can you reproduce the analysis you did in March?', the answer should be 'git checkout march-report && poetry install && python run_analysis.py', not 'let me try to remember which library versions I had installed'.