Short pages, written in the same words the product uses.
A job affects exactly what your admin filter returns at the moment you open the panel — never a hidden selection, never "all products" by default. The panel shows the filter it is working from, and the preview that follows gives you the exact counts before anything is applied. If you change the filter, reopen the panel.
Variant-level fields (price, compare-at price, SKU, barcode, weight, stock) are counted in variants. Product-level fields (title, description, tags, product metafields) are counted in products. Both counts are shown when a rule stack touches both.
A rule is a field, an operation and a value. Rules run in the order you add them, so reduce price by 15% followed by round to end in .99 produces a different result from the reverse — and the preview shows the final value either way, not the intermediate one.
Rounding modes end a price in .99, .95, .00 or a whole unit. Rounding always moves the price to the nearest matching value; it never systematically rounds up.
Operates on titles, descriptions, SKUs and text metafields. Matching is literal and case-sensitive by default. The preview highlights the matched span in each affected row, so a rule that would match more than you meant is visible before it runs.
Nothing is written until you press the apply button, and that button always carries the count: Apply to 892 variants. It is styled as a destructive action because it overwrites data.
Jobs over 1,000 variants add one step: type the count to confirm. This is the only modal dialog in the product.
If some writes are rejected, the job stops in a partly applied state. You get the number written, the number not written, the reason, and a Retry the 42 variants action. The writes that succeeded remain undoable on their own.
Before a job writes anything it snapshots the current value of every field it is about to change. Undo restores those snapshots verbatim; it does not recompute an inverse rule. If a value changed after the job ran — by you, by another app, or by Shopify — undo will overwrite that newer value, and the panel warns you when it detects one.
The window is 7 days on Free, 30 on Core, 90 on Growth, and 12 months on Scale and Compliance. After the window the snapshot is deleted and the job can no longer be undone.
Schedule appears next to Apply on the preview. A schedule is either a one-shot (run once at a time) or a window (run at the start, restore the snapshot at the end). Recurring schedules repeat a one-shot on a weekly or monthly cadence.
All times are your store's timezone, read from your Shopify locale settings. If you change the store timezone, existing schedules keep the wall-clock time you chose.
Windows on overlapping product sets are detected at save time and both jobs are named in the warning. You can save anyway; the later-starting job wins on conflicting fields.
Two views: a per-product price history, and a store-wide log covering every field BulkGauge can observe. The store-wide log is filterable by date range, resource type and job, and exports to CSV on Growth and above.
Pick a definition; its type decides the control. Single-line text gets a text box, a date gets a date field, a product reference gets a picker, and a list type gets a repeatable control. Types BulkGauge cannot safely bulk-write — rich text and file references — are read-only in previews and marked as such.
Shopify rejects a metafield value over 16 KB. BulkGauge measures each resulting value before the job runs and lists the ones that would fail, with three fixes: shorten the value, split it across two fields, or move it to a metaobject reference.
A chain is a job with ordered steps. A single rule is a chain with one step, so nothing about the model changes — what changes is that four related edits become one preview, one job record and one undo.
Steps run in order by default: step 2 reads what step 1 produced. Turning that off computes every step against the state before the job started and writes them together. Sequential is what merchants mean by “then”, which is why it is the default.
If a step fails, the chain halts and the steps already applied are rolled back, newest first. Nothing is left half-changed. Keep going if a step fails is available per job and off unless you turn it on.
Undo reverses the whole job in reverse step order. Chains are capped at 10 steps. Saved chains store the rules, not the products, so a saved chain runs against whatever your filter holds on the day you run it.
A template is text with variables: {{product.title}} | {{product.vendor}} | Free UK Delivery. Variables resolve per product at preview time, so one rule writes a different value for every product. Available variables cover product fields, the lowest variant price, the first collection, variant-derived values and any metafield.
Modifiers follow a pipe: | truncate: 40, | upcase, | round, and | default: "our range". The fallback matters — without it, a product with no vendor produces a title with a hole in it.
Products that already have a value are skipped unless you choose to overwrite them; the preview counts both groups. Length is shown per row against 60 characters for titles and 160 for descriptions, and rows resolving to identical text are flagged.
URL handle templates are disabled until enabled in settings. Changing a handle changes a product’s address; BulkGauge creates a redirect from the old one for every change, which reduces the damage without removing it.
The coverage audit is read-only and runs on every plan, including Free. It reports how many product images have no alt text, by product and by collection, and exports to CSV.
Writing it is either a template — the same resolver as SEO templates, with {{image.position}} and {{image.count}} added — or an AI description generated from the image. The template path has no per-image cost. The AI path is 1¢ for each description generated.
There is no included allowance and no free tier of images: the first description costs a penny and so does the ten-thousandth. What is free is what you have already paid for — an image described once is reused wherever it appears again at no charge — and anything you turn down. You set a monthly limit that BulkGauge never charges past; a job that would exceed it stops before it starts and offers you the two ways forward, raising the limit or running the part that fits.
You are charged for descriptions that are written and kept, so a quoted cost is always a maximum: rejected descriptions, descriptions held because the image would not load, and repeated images described once and reused are all free.
Four controls keep the cost down, and none is optional: images with existing alt text are never sent, identical images are described once and cached by image hash, images are downscaled before sending, and a rejected description is neither counted nor charged.
The preview shows each image beside its description and its length. Any row can be edited or rejected; a rejected row is neither written nor counted.
One selector at the top of the rule builder changes what a job targets: products, collections, pages and blog posts, or discount codes. The counts beside each type are what your store holds now.
Everything runs through the same preview, snapshot, apply and undo path. One exception is enforced in code rather than warned about:
Smart collection rules are out of scope in this version; collection fields are editable, collection rules are not.
A multi-store job is one parent job with one child job per store. Children are ordinary single-store jobs, which is why per-store undo works exactly like any other undo.
Scope is set at the top of the rule builder: this store, a store group, all linked stores, or a chosen set. Filter-based rules resolve independently in each store, which is the common case. Matching the same product across stores is by SKU, then handle, then exact title; every job reports the products that had no counterpart rather than skipping them quietly.
The rule is validated against every store at preview time, so a store missing a metafield definition is named with the reason and can be skipped while the rest proceed. Relative price operations run across currencies; absolute amounts are blocked on groups that do not share one.
Rate limits are per store, so stores run in parallel and a six-store job takes roughly as long as its slowest store. A store joins an organisation by accepting an invitation in its own admin, and can unlink itself at any time without the organisation owner’s involvement. Every link and unlink is recorded.
Every tier includes one store. That store — the hub — carries the subscription. Stores you connect install BulkGauge on the free plan and inherit the hub's features; a connected store is never charged for being connected and never sees the hub's invoice.
Additional stores are charged per store at a rate that falls in bands. On Growth: $19 each for stores 2–5, $14 for 6–10, $10 for 11–25, and $5 each for stores 26–100. From the hundred-and-first store on, each one is $0 — so the total stops rising at $710 a month and does not change again, however many stores you add. The same shape applies on every tier: $390 on Core, $1,130 on Scale, $1,485 on Compliance. No tier limits how many stores you connect.
Your own store is included in the base. So an agency describing itself as having "7 connected stores" is billed for 8: their hub plus seven clients. Every screen that quotes a price says which it is counting.
Adding a store changes your total from your next cycle, never mid-cycle, and the date is shown before you send the invitation. Removing a store reduces the total from the next cycle in the same way — there are no partial-month charges or refunds in either direction, and cycling stores in and out cannot game the bands.
No tier limits store count, so a plan change can never put you over one and nothing is ever disconnected. The single change that stops multi-store jobs is moving to Free, which does not include them: links persist, single-store editing continues everywhere, and a scheduled cross-store job that comes due is skipped and reported rather than partly run.
An optional add-on on any paid plan. A scheduled job reads your catalogue data through the Shopify API, encrypts the result with AES-256 inside BulkGauge, and writes it to one destination: our storage, a Google Drive or Dropbox folder you authorise, or a download link that expires in 24 hours.
What is copied: products and variants, metafields and metaobjects, collections, pages, blogs and navigation, inventory levels, discounts and price rules, and theme settings data. Products cannot be excluded — every other type references them.
What is never copied: orders, customers, theme code, and anything another app keeps in its own database. Shopify provides no way to write an order or a customer back, so a copy of them would be a file you could never use.
Daily, weekly or manual, at an hour you choose. Times are your store's timezone, shown on screen beside the field, because the person configuring it is often in a different one. Retention is a count of restore points — 7 on Core, 30 on Growth, 90 on Scale and Compliance — and the schedule screen states what each choice costs in storage before you save it. If storage fills, backups stop and you are told; a restore point you are keeping is never deleted to make room.
Two options, and the trade is real. If BulkGauge holds the key, restore always works and our staff cannot browse your backups, but we hold the key material and could technically decrypt a copy. If you hold the key, we cannot read your backups and cannot help you read them: the key is displayed once, never stored by us, and a lost key means every copy encrypted with it is permanently unrecoverable. There is no reset and no support route. Copies made under one key stay readable with that key when you switch.
Restore is not a rollback. There is no Shopify API that returns a store to an earlier moment, so BulkGauge replays creates and updates, and the preview names four outcomes per object: updated in place, recreated, skipped because it already matches, and cannot be restored with the reason on the row.
Before the first write, a restore point of the store as it is now is taken, so the in-place updates can be undone from Jobs in one action. Recreated products cannot be undone — undoing would delete them again, and their new IDs are already in use. Restore is gated by typing the count of products it will write to, the same gate as a job over 1,000 variants.
Progress is reported by data type while it runs, and the completion summary leads with what did not come back: how many were skipped, how many references broke, and a list behind each.
On the Compliance plan, 12 months of price history feeds the Omnibus prior-price block, and per-product checklists track GPSR fields — manufacturer, responsible person in the EU, safety warnings, and the passport identifier. The dashboard reports what is complete and incomplete. It does not report whether you meet a legal obligation; that judgement is yours and your adviser's.
Common failures and their fixes are listed on the install page. Anything else: support@bulkgauge.com, with the job id from the jobs list if there is one.