Methodology & Advanced Topics

This document provides a technical overview of the advanced features and mathematical concepts underlying GeoSC, focusing on how SparseSC is implemented and operationalised.

For a more rigorous econometric exposition intended for Data Scientists and Statisticians, see the Mathematical Formalism of Synthetic Controls.

SparseSC Mathematical Foundation

The standard Synthetic Control Method minimises pre-treatment prediction error by constructing a convex combination of donor units.

GeoSC uses the vendored SparseSC implementation, which extends traditional synthetic control by learning a regularized match space and donor weights from the pre-treatment data.

Two objects are useful for interpretation:

  1. Feature weights / match space (V): Which pre-treatment features or time periods matter most for matching.
  2. Unit weights (W): How control units combine to form the synthetic counterfactual.

SparseSC exposes penalties for unit-weight shrinkage (w_pen) and feature weighting (v_pen). GeoSC’s default inference configuration uses SparseSC’s fast path, which constructs the match space through RidgeCV-backed machinery in the vendored implementation. The non-fast path uses SparseSC’s coordinate descent and cross-validation over feature-weight penalties.

Regularization can reduce overfitting to pre-treatment noise and often produces more interpretable donor structure, but it does not make a weak donor pool valid. The result still depends on comparable controls, adequate pre-treatment support, and uncontaminated treatment timing.

Statistical Inference in GeoSC

Because regional marketing experiments typically involve a very small number of treated units (often just one), asymptotic statistical inference is usually not appropriate. GeoSC uses SparseSC placebo inference to compute empirical p-values and, when SparseSC returns finite bounds, placebo confidence intervals.

Placebo Inference (Permutation Tests)

The primary method for significance testing is in-space placebo permutations.

  1. The algorithm iteratively reassigns the “treatment” status to every untreated unit in the donor pool.
  2. It fits a completely new SparseSC model for each of these placebo units.
  3. It calculates the pseudo-treatment effect (the prediction error in the post-treatment period) for each placebo.
  4. The empirical p-value is calculated as the proportion of placebo effects that are at least as extreme as the actual estimated treatment effect.

This is a finite-sample comparison against the observed donor pool, not an unconditional production-safety guarantee. With few donors the p-value grid is coarse, and non-comparable geographies, spillovers, or poor pre-period fit can make the placebo reference set uninformative.

Advanced Configuration & Tuning

Regularisation Selection (Cross-Validation)

SparseSC selects penalty settings using cross-validation over pre-treatment information. The exact machinery depends on whether the configured run uses the fast path.

If the default automatic search does not yield a good fit, the configuration allows for direct intervention:

# Inference configuration options
sparse_sc_model_type: "retrospective"
sparse_sc_fast_estimation: true
sparse_sc_level: 0.95
  • sparse_sc_fast_estimation: When set to true, GeoSC calls SparseSC’s fast estimator. This uses a RidgeCV-backed match-space path and is generally faster than the full coordinate-descent estimator. Treat any speed/accuracy tradeoff as data-dependent.
  • sparse_sc_model_type: Setting this to retrospective ensures the model adheres strictly to the pre/post treatment boundary defined in the configuration.

Donor Pool Constraints

By default, GeoSC includes all non-treated units in the donor pool. However, if business logic dictates that certain regions should not be used (e.g., they experienced a supply chain shock), they should be excluded from the input CSV entirely prior to analysis.

The recipes/donor_evaluator.py tool helps systematically identify the highest quality donors prior to running inference.

Performance Considerations

GeoSC relies heavily on matrix operations during the cross-validation and optimisation phases. The following options are supported to improve execution speed:

  • Power Analysis Parallelism: Set jobs: -1 (or pass --jobs -1 via CLI) to use all available CPU cores when simulating hundreds of treatment effects.
  • GPU Acceleration: The maintained GPU path is optional CuPy-backed acceleration for the power calculator only. Pass --use-gpu to request it for performance-oriented power runs. This requires cupy to be installed and matched to your system’s CUDA version (e.g., pip install cupy-cuda12x). Seeded power runs disable GPU DGP/generation paths so CPU simulation draws are reproducible.
  • Inference Computation: The main SparseSC inference step runs on CPU. The legacy geolift.gpu_accelerator module is experimental compatibility code and is not wired into the maintained inference pipeline. To avoid thread oversubscription when running on multi-core servers, set environment variables such as OMP_NUM_THREADS or MKL_NUM_THREADS to a sensible value relative to your total core count.

Need More Help?