--- name: set-up-scoring-model-segmentation description: >- Upgrades Shopping segmentation from single-metric ROAS tiers to a weighted composite score that blends performance with business inputs like margin, stock level, and price competitiveness, then maps score bands to priority campaign buckets via a second custom label. Use it when ROAS-only tiering misprices the catalog, high-margin or well-stocked products deserve visibility their ad history alone would deny them, and reliable data exists for each extra variable. Requires a feed tool that can compute fields and a catalog of roughly 100+ SKUs. Do not use it as a first segmentation (set-up-performance-based-shopping-segmentation is the simpler prerequisite), for building the feed itself (set-up-and-optimize-product-feed), or for launching the bucket campaigns from scratch without a scoring layer (launch-standard-shopping-campaign, launch-pmax-feed-only-campaign). --- # Segment Shopping Campaigns with a Weighted Product Score ## Purpose Build a composite priority score per product, a weighted blend of ad performance and business signals such as unit margin, inventory depth, and price position, and use score bands, synced into a custom label, to drive Shopping campaign buckets. This aligns spend with what the business actually wants pushed, instead of only what happened to convert historically. The score is computed in the feed management layer; this skill covers model design, output verification, and the Google Ads bucket build. ## When to run - ROAS-only tiers keep burying products the business knows are valuable (fat margins, deep stock, sharp pricing) because their ad history is thin. - Clean, regularly-refreshed data exists for at least two non-ROAS variables. - A feed management tool capable of calculated fields (Channable, DataFeedWatch, Feedonomics, or equivalent) is already in place. - Performance-based segmentation has been run and its limits are understood. ## When NOT to run - No segmentation exists yet -> set-up-performance-based-shopping-segmentation first; scoring is the second step, not the first. - Margin/stock/price data is patchy or stale, one rotten variable corrupts every score. - Catalog under ~100 SKUs: bands would hold too few products to matter. - Nobody will own quarterly weight recalibration; an unmaintained model silently drifts wrong. - The feed itself needs work -> set-up-and-optimize-product-feed. ## Prerequisites - Merchant Center linked, feed approved, and a feed tool that supports computed fields. - 90+ days of Shopping conversion data with values (for the ROAS variable and for scale breakpoints). - Data pipelines into the feed tool for every chosen variable, refreshed at least weekly (daily for stock). - A free custom label slot, conventionally `custom_label_1` when `custom_label_0` already carries performance tiers. ## Procedure 1. **Session guardrail.** Before the first Google Ads write of this session, call `gads_policy_guardrail` and honor its output. 2. **Pull the performance variable.** Call `gads_get_shopping_performance` and `gads_run_gaql_query` (trailing 90 days, product level) for ROAS, conversions, and spend per item. This is both the ROAS input and the source for percentile breakpoints in step 4. 3. **Select variables with the user.** Start from ROAS + margin; add stock level and/or price position only if the data source is trustworthy. Cap the model at 2-3 variables on the first build (see Decision rules). 4. **Design scales and weights (analysis only).** Normalize every variable onto a common 0-10 scale, use the catalog's own 20th/50th/80th percentile values from step 2 as breakpoints rather than guessing. Assign weights summing to 100% with no variable above ~35%. Define score bands and budget shares per Decision rules. Present the full model spec (variables, scales, weights, bands, handling of missing data) for user sign-off, and store it in the run notes, the model must be reconstructible later. 5. **HUMAN STEP (outside VigilDog).** Implement the model in the feed tool: one computed field per normalized variable, one weighted-sum field, one band-mapping field written to `custom_label_1`, then sync to Merchant Center. VigilDog has no tool for feed-tool configuration or Merchant Center data sources. 6. **Verify the scored output.** Call `gads_run_gaql_query` segmented by the product custom attribute to count products per band. Check against the expected distribution in Decision rules, and spot-check ~10 products per band with the user: do the top-band products genuinely deserve priority, and are new/out-of-stock/missing-data products landing where the model spec says they should? Fix the model (step 5) before building campaigns. 7. **Plan the buckets.** Call `gads_plan_shopping_campaign` per band to assemble naming, budget split, bidding, and filter plans; present the whole structure to the user. 8. **Create budgets and campaigns (write).** For each band: `gads_create_budget` then `gads_create_shopping_campaign`. Preview first (validate_only=true default), show each campaign's budget share, apply only after explicit user approval. 9. **Filter buckets by score band (write).** Use `gads_create_product_group` to subdivide each campaign's listing tree by `custom_label_1`, including only that band's value, and `gads_exclude_product_group` for all other values. Preview first, apply after approval. 10. **Seal overlapping campaigns (write).** Apply `gads_exclude_product_group` for the scored label values on every legacy Shopping/PMax campaign that could still serve these products. Preview first, apply after approval. 11. **Set bidding (write).** `gads_set_campaign_bidding_strategy` with the SAME tROAS on every band, priority is expressed through budget share, never through easier targets. Preview first, apply after approval. 12. **Week-1 validation.** Via `gads_run_gaql_query`: each band serving, top band drawing the majority of spend, no product in two campaigns, pacing near the planned split. 13. **Ongoing calibration.** Monthly: re-run step 6's distribution and spot checks; confirm every variable's source is still refreshing. Quarterly: full weight review with the user, business priorities move, and the model must move with them. Log every change against the model spec. ## Decision rules - **Variable count:** launch with 2-3, never more than 5. Each added variable adds a data pipeline that can silently rot. - **Weight caps:** weights total 100%; no single variable above ~35%. Past that, the model is a disguised single-variable sort and the complexity buys nothing. - **Normalization:** all variables mapped to 0-10 before weighting; derive breakpoints from the catalog's own 20th/50th/80th percentiles. - **Band thresholds (3-band default):** high >= 7.0 (expect ~15-25% of catalog, give 50-60% of budget), medium 5.0-6.9 (~30-40% of catalog, 25-35% of budget), low < 5.0 (~35-50% of catalog, 10-20% of budget). Simpler 2-band alternative: priority >= 6.0 at 70-80% budget, remainder at 20-30%. - **Missing data policy:** pick ONE, neutral score (5), category average, or exclusion from scoring, and write it into the model spec. New products with no ROAS history should default toward neutral, not zero, or launches get buried. - **One tROAS across bands:** identical target everywhere; budget share is the only lever that differs. A softer target on the low band traps products there. - **Volume gate:** any band campaign bidding to tROAS still needs ~30 conversions/month; merge bands that cannot clear it. ## Common failure modes - **Garbage variable, confident score.** A stale stock export or wrong margin column corrupts every product's score while looking precise. Verify each pipeline's freshness monthly (step 13). - **Over-weighted pet metric.** Weighting margin at 60% because "profit matters" reduces the model to a margin sort. Hold the 35% cap. - **Comparing raw units.** Mixing ROAS percentages with stock counts without normalization makes the biggest-numbered variable win by accident. Normalize first, always. - **Set-and-forget weights.** A model tuned for a stock-clearance quarter keeps clearing stock in peak season. Quarterly recalibration is part of the procedure, not optional hygiene. - **Undocumented model.** Six months later nobody can say why a product scores 6.2, so nobody trusts or fixes the model. The step 4 spec is the contract. - **Skipping the spot check.** Distribution can look right while individual products are absurdly misplaced. Ten products per band, human-reviewed, before any campaign is built. ## Related skills - Before: set-up-performance-based-shopping-segmentation (run and outgrow it first), set-up-and-optimize-product-feed (feed and label plumbing), set-up-cart-data-and-profit-tracking (trustworthy margin/profit inputs). - During: launch-standard-shopping-campaign or launch-pmax-feed-only-campaign (per-bucket build details). - After: run-shopping-campaign-optimization-cycle (recurring tuning of the bucket campaigns), allocate-budget-across-campaigns (rebalancing band budgets as results come in).