Building a Sponsored Products campaign from scratch is one of those tasks where the work doesn't match the value. The decisions are usually straightforward — what SKUs to advertise, what budget, what bid to start at — but the execution involves filling out an Amazon bulk sheet with anywhere from 8 to 40+ rows per campaign, each one with the correct Entity, Operation, ID, and field values, and getting any of it wrong means the upload fails or creates the wrong thing.
The manual approach: open Amazon's UI, click Create Campaign, walk through the wizard for each SKU one at a time. For 20 SKUs that's maybe two hours of clicking.
BulkSheet Pro has three builders for the three Sponsored Products campaign types — Auto, Keyword, and Product Target. Each one takes the list of SKUs you want to advertise plus a small set of global parameters and outputs an Amazon-ready bulk sheet that creates all the campaigns at once. Twenty SKUs becomes a five-minute job.
The shared pattern
All three builders follow the same shape:
- Paste your list of SKUs (one per line) into the input area
- Set the global parameters that apply across all the campaigns being built — budget, default bid, placements, bidding strategy, start date, status
- For the keyword and product-target builders, also set the keywords or ASINs to target
- Review the preview of what's about to be built
- Export — a properly-formatted Amazon bulk sheet downloads
The "one builder, many campaigns" approach works because Sponsored Products campaign structures are mostly identical across SKUs. The same naming convention, the same budget, the same bid, the same placement settings. What changes per SKU is which product the campaign is targeting. The builder handles the boilerplate; you handle the strategy.
The SP Auto builder
Auto campaigns let Amazon decide what to bid on. They're discovery campaigns — you give Amazon a SKU and a budget, and it surfaces search terms it thinks are relevant. The Auto builder is the most common entry point for new SKUs because it gives Amazon the most flexibility and produces the richest signal for downstream harvest work.
The fields the builder asks for:
- Default bid — the bid Amazon uses unless you've set per-targeting-group overrides
- Targeting group bids (optional) — separate bids for the four auto targeting groups: close match, loose match, substitutes, complements. Most users start with all four enabled and the same bid; later cycles refine them based on which groups convert.
- Daily budget — applies to every campaign in the batch
- Bidding strategy — "dynamic bids - down only," "dynamic bids - up and down," or "fixed bid"
- Placement multipliers — Top of Search, Product Pages, Rest of Search percentages, plus any audience placements
- Status — usually Enabled, but you can build them as Paused if you want to review before launching
- Start date — defaults to immediate
You paste a list of SKUs, fill in the fields, and the builder generates one auto campaign per SKU. Each campaign is named with whatever convention you've set up (most users use a pattern like "SP - Auto - [SKU]"). The resulting bulk sheet has all the rows correctly populated — campaign rows, ad group rows, product ad rows, placement rows.
Preflight check: Before exporting, the builder checks your current bulk sheet for existing Auto campaigns. If any of the SKUs already have an enabled SP Auto campaign, you'll see a warning. Amazon will reject duplicate campaign names on upload, so you typically want to either remove those SKUs from the list or rename them before exporting.
The SP Keyword builder
Keyword campaigns target specific search terms directly. They're precision tools — you choose the keyword, the match type, and the bid. The Keyword builder is what you reach for when you've identified terms you want to compete on at a specific bid.
The fields differ from the Auto builder mostly in the targeting section:
- Keyword list — one keyword per line
- Match types — Exact, Phrase, Broad, Modified Broad (chip selector; you can select multiple, and the builder generates one ad group per match type per SKU)
- Per-match-type bids — optional, lets you bid different amounts for exact vs phrase vs broad
The rest of the global parameters — budget, default bid, placements, bidding strategy — work the same as the Auto builder.
The output is more complex than the Auto builder because each SKU generates one campaign with potentially multiple ad groups (one per match type) and one keyword row per (SKU × match type × keyword). For 5 SKUs with 10 keywords selected and 3 match types active, you're looking at 150 keyword rows plus 15 ad group rows plus 5 campaign rows. The bulk sheet handles all of that.
Preflight check: The builder validates that your SKU list doesn't contain SKUs longer than 40 characters (Amazon's limit). It also flags any SKU that already has an enabled keyword campaign so you can decide whether to keep it in the batch.
The SP Product Target builder
Product Target campaigns place ads on specific competitor ASINs or category pages. They're conquesting tools — your ad shows up on a competitor's detail page when a shopper is browsing.
The fields:
- SKUs to advertise — same input as the other builders
- Target ASINs — one ASIN per line, or comma-separated lists. These are the competitor products you want to appear on.
- Bid per ASIN target — applied to every (SKU × target ASIN) pair
- Global parameters — budget, placements, bidding strategy, status, start date
The output: one campaign per SKU, with one ad group containing all the target ASINs you specified. Each target ASIN is encoded as a product-targeting expression (Amazon's specific format), and the bulk sheet rows include the Product Targeting ID and Product Targeting Expression columns that Amazon's parser expects.
Preflight check: SKU length validation, existing-campaign detection, and a sanity check that target ASINs look like valid ASIN format (B0... or older formats).
The preview before export
Each builder shows a preview of what's about to be built. The preview is read-only — it's there to confirm that the SKU list parsed correctly, that the global parameters look right, and that the resulting campaign counts match what you expected. If something is off, fix it in the builder fields and the preview updates automatically.
Most users skim the preview, confirm the counts, and click export. If you're building 20 campaigns at once, the preview lets you confirm in two seconds that you've got 20 campaigns coming, not 1 or 200.
The export
Clicking export downloads a bulk sheet sized to the build — usually a single Sponsored Products Campaigns sheet with all the rows for all the campaigns. You upload it to Amazon's Bulk Operations page. Amazon processes the rows in order — campaigns first, ad groups next, then keywords or product targets, then placement adjustments — and your new campaigns are live within an hour.
The file is a separate export from the main "UPLOAD_TO_AMAZON" bulk sheet that comes out of the Recommendations workflow. Builder exports are their own files because they represent new entities being created, not changes to existing ones. Mixing them with rec-engine changes in one sheet would slow the upload and risk confusion if Amazon rejected one row.
What BulkSheet Pro won't do
It won't build Sponsored Brands, Sponsored Brands Video, or Sponsored Display campaigns. These ad types require your brand assets — headline copy, image creative, video creative, brand store URL — that BulkSheet Pro can't infer from a SKU list alone. You build SB, SBV, and SD campaigns in Amazon's UI directly. The Coverage page surfaces the gaps so you know which ASINs need those builds; the building itself happens elsewhere.
It won't pick bids for you. The builders ask for a default bid and (optionally) per-targeting-group or per-match-type bids, and they apply those values uniformly across the batch. There's no auto-bid suggestion based on category benchmarks. The bid is a decision you bring to the builder, not something the builder produces.
It won't generate keyword lists from a SKU. The Keyword builder requires you to paste in the keywords you want to target. There's no built-in suggestion engine; you bring the keywords (either from your own research, from previous harvest workflows, or from Amazon's own suggestion tools). The builder handles formatting them into the right bulk-sheet rows.
It won't validate ASIN format on product targets beyond surface-level checks. If you paste in B07XXXXXXX strings and one is actually a misspelled or discontinued ASIN, Amazon will reject that specific target row on upload. The builder doesn't verify each ASIN against Amazon's catalog.
It won't update existing campaigns. The builders are for creating new campaigns. If you want to modify an existing campaign (add new keywords to its ad group, change its budget, etc.), that work happens on the Campaigns page or through the Toolmaker, not in the builders.
When to use a builder vs. the manual UI
One campaign for one SKU as a quick test: Amazon's UI is faster. Walk through the wizard, click create, done.
One campaign per SKU for 5+ SKUs at once: the builder is much faster. Especially if you're applying the same parameters to all of them.
Anything that involves keyword campaigns across multiple SKUs and multiple match types: the builder is the only realistic option. Amazon's UI doesn't let you batch this work; you'd be clicking through the same wizard 5-15 times per SKU.
Most accounts using BulkSheet Pro reach for the builders any time they're scaling up beyond a single new campaign. The time saved compounds across cycles — every month you're not spending an hour or two clicking through Amazon's UI is an hour or two spent on the work that actually moves the account forward.