What's new in Spagify

Every exclusion Spagify proposes is checked later against your search-term data. That check now writes down what it saw instead of staying silent: an excluded search that never appeared again, a search that was sent to the right product after the exclusion, or one that kept costing money with no sale where it was not excluded. Your approving a proposal is recorded as your decision, not as proof the proposal was right — the proof comes from the data. On an account that records too few sales to tell, a search with no sales is never counted as a win for the exclusion.

A share of brand exclusions is now held back for two weeks before going live, like other exclusions, so their results can be measured. And a search that costs a lot on few clicks — the normal shape on a high-ticket product — now counts by what it spent, not only by how many clicks it got.

Exclusions that route a search to the right tier of your funnel can no longer be rejected by mistake: rejecting one would make your own campaigns bid against each other. Trying to reject one now explains what the exclusion does and points to the real action, pausing the product or removing it from the funnel. Routing exclusions rejected earlier while they were still live have been put back.

The badge next to each SKU read "Live" for any product in a Spagify campaign, even when every one of its ad groups was paused — so a product Spagify had just paused, because one of your own campaigns also served it, still said "Live" next to the alert saying it was paused. A product in a campaign whose ads are all paused now reads "Paused", and hovering the badge says why: which of your campaigns it stepped aside for, out of stock, disapproved in Merchant Center, one of your automation rules, or a pause you made. The launch product picker shows the same badge.

When you rejected or archived an exclusion Spagify had already pushed to Google Ads, the row disappeared from your plan — and the negative keyword stayed live in Google. Now rejecting, archiving, editing the text of, or removing an exclusion from your Brands or Exclusions lists takes it out of Google Ads first, and a daily check removes anything an earlier rejection left behind.

Brands and exclusions you type into Settings, or that came in from your old account, are now recorded as yours: Spagify's AI checks will never remove them, and if the AI had dropped one and you add it back, that counts as your decision over the AI's.

The AI also learns only from what actually happened — a held-back search that went on to sell, a sale on a blocked search, something you removed — and no longer from its own earlier reversals.

Pause on a product's page recorded the pause and showed "Product paused." — and the product's ad groups kept serving. Now a pause stops the ads in every campaign Spagify runs for that product within the hour, a resume brings back exactly the ad groups the pause stopped (a product Spagify paused for being out of stock stays paused until it is back), and republishing a funnel leaves a paused product paused. Every pause and resume is in the activity log like any other change Spagify makes.

When an exclusion turns out to be wrong — you removed it in Google Ads, a check found it named something you sell, or a later AI review reversed it — that was recorded and then forgotten. The AI that reads your search terms and judges brand exclusions now sees your store's recent corrections each time it works, in plain language ("'turbidex' was excluded as another brand and later found wrong: it is the media your own filter is made of"), so the same shape of mistake is not proposed twice.

Spagify's AI reads each search that triggered one of your ads to work out what the shopper wanted, and excludes searches for a different kind of product or routes them to the right product. Until now it read only searches that had been clicked. The searches that hurt your click-through rate most are the ones that never get clicked: a search for a water softener landing on your carbon filter, or a search for a $40 cartridge landing on a $1,200 backwashing unit. Those were never read, so nothing could act on them.

Now a search shown ten or more times in a month on one of Spagify's campaigns is read whether or not anyone clicked it, and a confident read of a different kind of product can exclude it on impressions alone. Searches on campaigns you run yourself are only read when they were clicked, since Spagify never changes those campaigns.

Spagify also stopped excluding brand names that appear in your own product titles. A funnel selling a "Fleck 2510 AiQ Sediment Filter / Turbidex" treated Turbidex as another company's brand and excluded it from its own campaigns. A brand whose name is on your product titles is now part of what the funnel sells.

Three warnings are about a product's current state rather than a one-off event: a product paying well under what other advertisers bid, a Merchant Center price that differs from your store, and a product showing out of stock in Merchant Center while you have stock. Spagify re-checks them every day and opened a fresh copy each time, so one product could fill your alerts with the same warning day after day.

Each product now has one of these warnings at a time. It stays up to date while the problem lasts and closes on its own once it is fixed. Copies that had already stacked up close the next time Spagify checks.

When Spagify's AI reads a search as someone shopping for a different product, it excludes that search. The exclusion used to go only on the campaign the search showed up in, usually your Generic tier. In a Priority Funnel that just moved the search down a level: the Brand or Product Specific tier picked it up instead, at a higher bid. These exclusions now go on every tier of the funnel at once, so the search stops costing clicks instead of getting more expensive. Exclusions already in place are extended to the other tiers on the next hourly pass.

The performance report email has been rebuilt around the questions you actually ask. It opens with your profit for the period and the change against the period before, with a chart of the running total through the week or month. Then it shows what Spagify did: the searches with no orders it blocked, the products with no sales it paused, the out-of-stock products it paused and resumed, and what that spend was worth, with a running total since you connected next to your plan cost. Only actions with a clear counterfactual are counted, each at its trailing 30-day spend rate, and anything that was reversed is listed too.

A one-sentence explanation of what drove the result sits over the funnel numbers, the products with the biggest swings follow, and the report ends with the changes waiting for your approval and the things only you can act on, such as a restock. Approve links open the item in your Inbox with its own Approve button; nothing is ever applied by following a link. Rows that depend on an add-on, such as pricing against the market, appear only when the add-on is on your plan.

The same report opens in Spagify from the email and from the Inbox. Without unit costs on your products the report reads in revenue instead of profit.

Settings → Billing now lists every add-on Spagify sells, with its price and whether your plan already includes it, and an Add button that opens checkout — a one-time charge for a one-off service, a monthly line for an ongoing one. What you bought shows on the same card with its date, and a monthly add-on can be ended there at the end of its period. The same add-ons appear on the pricing page.

The first of these is Founder Setup & Monitoring, which until now was arranged by email.

When Spagify's AI reads a search term as someone shopping for a product you do not sell (a cheap party shot dispenser on a store selling premium wine systems, say), it approves an exclusion for it. Those approved exclusions were being prepared and then left waiting: nothing sent them to Google Ads, so the same searches kept costing clicks. Now every exclusion Spagify has approved is sent on the next hourly pass, whichever check found it. Exclusions that cannot go out yet, such as one waiting for a paused campaign to come back or for the AI brand check to confirm a brand, still wait until they can.

A promo code now works however you pay. Stores billed through Stripe have always been able to type one at checkout; stores that installed Spagify from the Shopify App Store and pay through Shopify Billing could not use one at all. Now there is a promo code field on the plan chooser and on Settings → Billing for those stores: enter the code before approving the charge and the discount is on the subscription Shopify asks you to approve, with what it does ("30% off for 3 months") shown before you commit.

Behind this, plan prices and trial lengths moved into Spagify itself, so a price shown on the pricing page, charged through Stripe and charged through Shopify Billing is always the same number.

The performance report email now shows its numbers as well as listing them. Under the table, paired bars set this period's cost, clicks, orders and revenue against the period before, and a day-by-day chart shows how cost, clicks and revenue moved through the week or month, with the busiest day named.

At the foot of the report, a key explains every term it uses: each metric, each kind of change Spagify made (what a "bid step" is, for instance), and what "still open" and "decisions waiting" mean. The AI's catalog-based exclusions, which the report used to list under an unhelpful name, now appear as "AI-suggested exclusions" with the same explanation.

The same report, charts and key included, now opens in Spagify too: from the "See this report in Spagify" link in the email and from the report's entry in the Inbox.

Spagify decides how far your Generic bids may rise by checking how often higher bidders beat you over the last three days. Since October 1 that three-day figure had not been coming through, so Spagify used two weeks of history instead and the bids stayed at their resting limit while you were being outbid. Spagify now builds the three-day figure from your account's daily numbers, and Generic bids rise again while competitors are beating you.

Google caps how many keywords your account-wide negative list can hold, and the cap is not the same on every account. When a new exclusion would go past it, Google refused the whole batch, and Spagify tried again every hour without success while the plan showed as failed. Now Spagify reads the real cap from Google's refusal, adds what still fits to the account-wide list, and puts the rest on a list attached to every campaign Spagify runs, so those searches are blocked either way.

When your Generic campaign is losing most of its auctions to higher bidders, Spagify lets its bids rise further, then pulls them back if clicks suddenly cost far more than usual, since that is usually another advertiser overspending. "Usual" was measured against your own recent clicks, which were cheap because the bids had been held low. The first raise therefore looked like a price spike and was undone within hours. Now a jump in cost only pulls the bids back once you are paying more than other advertisers bid for the same product.

Spagify keeps generic-search bids below what the market pays on purpose, so those searches stay your cheapest clicks, and raises them by itself while competitors are outbidding you. The "Bidding under the market" alert still fired for those ads and told you to raise the bid, which would have undone that by hand. It now covers only your brand and product-name ads, and the generic-search warnings already open have been cleared.

Before a brand Spagify found in your search terms is excluded, the AI brand check confirms it is a brand you do not sell. That check often finished after Spagify's last push of the day, so a confirmed exclusion could wait many hours for the next push. Now a confirmed exclusion is sent to Google Ads straight away.

Spagify also stopped preparing exclusions for campaigns it did not create. It reads search terms from your whole account, including campaigns you run yourself, but it never changes those campaigns, so these exclusions could never be sent and only showed up as waiting forever. Their search terms still inform the brand exclusions that protect Spagify's own campaigns.

Every page Spagify served, and the check it runs in the background to keep you signed in, re-saved your sign-in as it was when that request started. One that finished a moment after you signed in, signed out, or switched accounts put the earlier sign-in back, so you could sign in and still be signed out, or sign out and find yourself still in. Now only a request that actually renewed your sign-in saves it.

When a sign-in could no longer be renewed, Spagify signed you out but could leave the old sign-in behind in your browser. The login page then found it, signed you out again, and repeated this until you cleared your cookies. Now an expired sign-in is removed completely the first time, and you land on the login page once, ready to sign in.

Google can stop accepting Spagify's access to your ad account: when access is removed in your Google account's security settings, when the Google user who connected it loses access, or when a Google Workspace policy asks everyone to sign in again. Until now nothing said so. Syncing, bidding and negative keywords simply stopped working.

Now Spagify notices the first time Google refuses, emails the workspace owner once with a button to the page where you reconnect it, and raises a critical alert in your inbox. Settings → Integrations shows the same message with the reconnect button. Your campaigns keep running in Google Ads as they are, and everything Spagify manages resumes on its own once you reconnect.

The Google Ads card also no longer says "OAuth token expires soon" on every connected account. That warning was wrong: Spagify renews that token by itself every hour, so there was never anything for you to do.

When a Priority Funnel advertises some of a brand's products, searches for that brand's other models, which you sell but this funnel does not advertise, could still show its ads. A funnel for one water-softener valve was shown to searches for a different valve of the same brand over a hundred times in a week. Nobody clicked, because it was the wrong product, and each of those impressions made the ads look less relevant to Google.

Now each funnel excludes the model names of the same brand's other products, such as "5600 SXT" from a funnel advertising the "2510 AiQ", in every one of its campaigns. Searches for those models are left to whichever of your campaigns advertises them. The funnel's own models are never excluded, including other products of the same model.

Spagify keeps bids on generic searches low, so those searches stay your cheapest clicks and most of your budget goes to your brand and product-name campaigns. That limit was a fixed share of what the market pays. When other advertisers outbid it, your generic ads stopped showing, even on days with plenty of budget left. On one store generic ads won a third of the auctions they entered and took one click in a week, while half the daily budget went unspent.

Now the limit moves. While your generic ads are losing auctions to higher bids, the limit rises in step with how much they are losing, and it comes back down as they start winning again. It never rises during a sudden price spike, which is usually another advertiser burning through a badly set budget rather than shoppers you are missing. Generic bids still stay below your brand and product bids, and the daily budget still paces them.

Products Google has not yet priced for generic searches now use the market price Google reports for the same product in your other campaigns, instead of the fixed bid set at launch.

Support attachments and keyword-list files can now be up to 4 MB each, down from 5 MB. Files between 4.4 MB and 5 MB were being refused with a vague "too large" message after today's security update, which sends everything through spagify.com. Spagify now tells you before it sends anything. A screenshot or a list of tens of thousands of keywords is still far below the limit.

Spagify's AI brand check reads every brand you block and takes out the ones that are not really brands, so a common word does not stop real shoppers from seeing your ads. It had no answer for another store's name, such as Home Depot or AJ Madison, so it treated those as "not a brand" and unblocked them, letting your ads show to people looking for a different shop. It now knows a competing store when it sees one and keeps those searches blocked. Store names it had already unblocked go back on your list of brands you do not carry and are blocked again automatically.

Each early access code creates one account, for the email it was sent to and the Shopify store you joined the waitlist with. Signing up with Google works when the Google account uses that same email; if it does not, the sign-up page now says so instead of showing a generic error. Onboarding fills in your store for you on the Connect Shopify step. A store can join the waitlist once, so if someone on your team already signed it up, ask them to invite you.

If your workspace has more than one ad account, the picker at the top of the app names the one you are working in. Products, Overview, Autopilot and Launch were still showing spend, revenue and ROAS added up across all of them, so the numbers on screen did not match the account named above them, and Launch planned a campaign for one account from every account's results. Rules listed every account's rules and outcomes the same way.

Those pages, and Rules, now follow the account you pick, like the rest of the app. With a single ad account nothing changes.

Spagify never asked you to confirm your email when you signed up with a password, and a Shopify install creates an account from the store's email without confirming it either. So anyone could open an account with your address before you did, and when you later signed in with Google you joined that account while they stayed signed in.

Now, the first time you sign in with Google to an account whose email was never confirmed, Spagify signs out every other session on it and removes its password, because nothing showed that password was yours. Keep using Google, or choose a new password with "Forgot password". Accounts whose email was already confirmed, for example by a password reset, are unaffected.

An account created by installing Spagify from the Shopify App Store has no password. If you then installed Spagify on another store with the same email, Spagify asked you to log in, but there was no password to log in with, and "Forgot password" sent nothing.

"Forgot password" now emails such an account a link to set its first password. The login page also explains this when a Shopify install sends you there.

If you pay for Spagify through Shopify, changing plan creates a new charge for you to approve, and Shopify then cancels the old one. Spagify read that cancellation as your subscription ending and moved your workspace to the Free plan, even though the new charge was active. Declining a plan change did the same.

Now only the end of the charge you are actually paying on changes your plan. Approving a new plan moves you to it, and declining one, or letting it lapse, keeps you on the plan you already have.

Spagify's AI reads every clicked search against the product it showed, and it could tell when a shopper wanted something else entirely, such as a wine fridge when the ad was for a wine dispenser. It could only act on that after three paid clicks on the same search with no sale, and not at all on a store whose sales Google Ads cannot see. On a high-priced product that rarely happens, so correct reads went unused.

Now a confident read that a search wants a different kind of product, a part, a repair or the wrong kind of buyer is blocked after the first paid click, whether or not your sales tracking works. Searches for reviews or comparisons are left alone, since on an expensive product those are often buyers. The AI also now sees each product's price, so a search for a $100 gadget is no longer mistaken for a buyer of a $5,000 machine.

A Priority Funnel keeps most of its shared budget for your brand and product-name campaigns, and holds generic searches to a small share. That share existed to protect money those campaigns could spend. When they are already winning nearly every auction they enter, a higher bid buys them nothing, so the budget kept for them went unspent. On one store that was about half the daily budget, every day.

Now, while your brand and product campaigns have nothing left to win, generic searches are paced against the whole shared budget instead of their small share. They give the money back the moment those campaigns can use it, or the day's budget runs ahead of plan. Generic bids stay inside the same range as before, so generic searches remain your cheapest clicks.

This alert compares what a product has paid per click over the last 30 days with the average maximum other advertisers set for the same product. It used to describe the first number as your bid, so a product bidding $1.81 whose one click had cost $0.12 was reported as bidding $0.12. The alert now says "has paid ... on average", and names the market figure as an average maximum.

Yesterday's AI check looked only at the brand exclusions Spagify finds in your search terms. It now also checks the ones built from your list of brands you do not carry, most of which Spagify suggested when you launched. Any entry it is confident is not a competitor brand, or that would block buyers for something you sell, is taken off the list and out of Google. Each removal appears in your activity log with the reason.

We are also trying a slightly stricter bar for words the check thinks are not brands at all, such as place names and product finishes. We are watching your campaigns' performance while we do, and will review this if it drops.

Spagify reads your search terms for brands you do not sell, so it can stop paying for shoppers looking for someone else's product. The rule behind that looks for a word that keeps appearing next to your product types and never converts, and it could not tell a brand from an ordinary word. On one store it treated "hard", "soft" and "oxidizing" as competitor brands, which kept your ads away from searches like "hard water softener".

Now every brand exclusion found this way is checked by AI before it reaches Google. The check looks at what you sell, the searches the word came from and how often your own product pages use it, then decides whether it really is a brand you do not carry and whether blocking it would turn away real buyers. Only confident brands go live. Exclusions it is confident are wrong are removed, including ones already in your account, and each one it removes is listed in your activity log with the reason.

Spagify's AI checks on your exclusions also now run daily for the first two weeks after a funnel launches, when most of them are found, and weekly after that. Before, the review ran weekly from day one.

When Spagify retires one of its negative keywords, it asks Google to remove it. If the keyword was already gone — deleted in Google Ads, or its list or campaign removed first — Google answers that it cannot find it, and Spagify recorded that as a failed removal. It then tried again, and failed again, every day.

The keyword being gone is exactly what the removal was for, so Spagify now records it as removed and stops retrying. Your activity log no longer shows the same failure day after day.

When a Performance Max campaign of yours sells the same products as a Spagify funnel, Performance Max wins those auctions and the funnel gets little or no traffic. On accounts running on autopilot, Spagify used to fix that by excluding the products from your Performance Max asset group.

That was a change to a campaign you built, not one Spagify built, and Spagify only ever changes its own. It now leaves your Performance Max alone on every plan and tells you about the overlap instead: the alert names the products and the campaign, so you can exclude them from Performance Max yourself or stop advertising them in Spagify. It closes itself once nothing overlaps.

When a product's web address changes in Shopify and Spagify cannot create the redirect because the store has not granted that permission, Spagify tells you so. It checked again every day and, each time, added a fresh copy of the same notice to your inbox rather than updating the one already there.

There is now one notice while the problem lasts, and it keeps its count of affected product links up to date. Reconnecting Shopify from Settings grants the permission.

Anyone in a workspace could open billing, change or cancel the plan, add or remove add-ons, and remove teammates, whatever their role. Those actions now belong to the people they should: owners and admins manage billing, invites and members, and only the owner can remove an admin or change someone's role. Members keep full use of everything else.

Invites are also now tied to the address they were sent to. Accepting one means signing in with that email, and accepting an invite never changes the role of someone already in the workspace.

When you install Spagify from the Shopify App Store with a store email that already belongs to a Spagify account — one you sign into with a password or Google — Spagify no longer opens that account straight away. It takes you to the login page instead, and once you are signed in it opens Settings so you can connect the store in one click.

A Shopify install proves you manage the store, not that you own the email address on it, so it is no longer enough on its own to open an existing account. If you signed up through Shopify and never set a password, reopening Spagify from your Shopify admin works exactly as before.

On the Lost to bid and Pricing tabs, the headings along the top of the table did not line up with the figures underneath them. Impressions could sit over the eligible count and Bid over something else again, so reading a row meant counting across and hoping. The wider your product titles, the further out it went.

The rows are now built as real table columns, so a heading always sits over the figures it names and stays there whatever the titles are. Clicking anywhere on a row still opens its detail, and the waste ledger on the Negative keywords page now works the same way.

When Spagify reads the Google Ads account you connected, it already tells you what it found and which of your existing negative keywords block products you sell. It now also points out campaigns of yours whose end date has passed while they are still set to Enabled.

Nothing is being wasted — an ended campaign cannot serve or spend — but they clutter the account, and if an end date is ever extended one can come back to life unexpectedly. The notice names them, sits in your inbox, and closes itself once none are left.

Spagify does not touch it. These are your campaigns, not ones Spagify built, and Spagify only ever changes its own.

Spagify aims each tier's bids at a share of what other advertisers pay for the same product. Google only reports that figure once a product has built up enough impressions, so for the first few days of a new funnel there is no market number to aim at and Spagify bids around the estimate it made at launch instead.

That is normal and it sorts itself out, but nothing said it was happening — the daily bid summary reported bids moving up and holding as though they were tracking the market. It now tells you plainly while bids are still set from the launch estimate, and stops saying it as soon as Google reports a real benchmark for any of your products.

Spagify's baseline exclusions — the junk-search terms and the brands you do not carry — go into your account-wide negative keyword list so they cover every campaign in the account, including ones Spagify did not build.

Spagify thought that list held 1,000 keywords. The list it actually uses holds far more, so on an account past 1,000 it decided there was no room left and quietly sent every new exclusion to a campaign-level list instead. Those exclusions still applied, but only to Spagify's own campaigns — your other campaigns stopped being covered, and nothing said so, because the exclusions themselves reported success.

Fixed. Exclusions go to the account-wide list as intended. And if your list ever genuinely is full, Spagify now tells you the limit Google actually reports rather than the number Spagify assumed.

Google keeps your daily budget, your spend and your "today" on your ad account's clock, not ours. Spagify read that clock when it needed it but never remembered it, so anything that looked up your time zone afterwards — your weekly and monthly summaries, and every "today" and "so far today" figure — fell back to an assumed one.

Spagify now reads your account's time zone and currency straight from Google and keeps them. New accounts get them before their first campaign goes live, so the very first day of a funnel is paced and reported on the right clock. If your account is not in US Eastern, your day boundaries and hourly bid pacing were slightly out and are now correct.

When Spagify builds a funnel for one of your brands, it also blocks your other brands from it, so a search for a brand you sell elsewhere does not land in the wrong campaign and bid against your own ads.

On an account whose funnel had just been built, those blocks were being prepared and then rejected by Google, because Spagify was not telling it which campaign to put them in. They are sent in a group, so one missing campaign took the whole group down with it — on a new funnel that could be every brand block at once, with nothing on the page saying the fence was not up.

Spagify now works out the campaigns itself, from the funnel the blocks belong to, and puts each one on every tier of it. Blocks that were rejected for this reason are repaired on the next run — you do not need to do anything. If the funnel's campaigns genuinely are not live yet, the blocks wait for them and go out when they are, instead of failing.

You could already change the match type on selected negatives from the bar at the top of a plan. It did not do what it looked like it did: the row showed the new match type, but the negative Spagify pushed to Google kept the old one, and the next time the plan was rebuilt your change was quietly undone. Both are fixed.

Changing a match type now changes the negative. One row from its menu, or many at once from the bar. A negative already live in Google is removed and replaced with the new match type on the next push, because Google cannot change a match type in place.

Your choice sticks. A row you set carries a small yours badge. Spagify keeps it through every regeneration, the miner never puts its own pick back, and the weekly AI review leaves it alone. If you change your mind, Reset to Spagify's pick puts the original back.

Spagify learns from it. Every choice is remembered on the Memory tab. On Growth and above, once you have corrected the same kind of row the same way three times — say, uncarried brands from Phrase to Broad — new rows of that kind are made your way from the start, marked learned so you can see what happened and reset it if it is wrong. On Starter your choices are kept exactly the same; the learned rule is shown, and applies when you move to Growth.

Finding the rows is easier. Under the tabs on a plan there is now a search box (a term, or a product's name or SKU), a match-type filter and an "Only rows you set" switch, with a Select all shown button beside the count — so a bulk change is aimed, not clicked row by row.

Everywhere you choose how a negative keyword is matched — adding one to a campaign, editing one, adding one to a plan, changing several at once — the three options are now in the same order with the same words: Broad — widest, Phrase, Exact — narrowest, each with a one-line explanation of exactly which searches it stops.

The old help text in two of those places had it backwards. It called Exact "safest" and said Broad blocks "any related search". For a negative keyword that is the wrong way round: Broad is the widest block (every one of the words, in any order), and Exact is the narrowest — on a single word it stops only that bare one-word search, so it is the one that quietly does nothing. The badges on your negatives lists use the same colours and the same wording, so a match type reads the same on every page.

Spagify already had the AI look over your own exclusion lists once a week and pull anything that could block a real buyer. That review never looked at the negatives Spagify itself mined from your search terms — so a wrong guess there stayed until you spotted it. On one new account that was a "brand" block on a word that is actually a kind of product the store sells.

The weekly review now reads those mined negatives too — every uncarried-brand block and every performance block still in play, with its match type and the reason it was proposed — and can do two things:

• Reject a block that should not exist: a "brand" that is really a product word, an attribute or a place, or anything that would stop a shopper who wants something you sell. The row is marked rejected with the AI's reason, and if it was already live in Google it is removed. This happens on every plan, because it is protecting your traffic.
• Re-match a block whose words are right but whose match type cannot do the job — a two-word pairing matched as a phrase that lets the same words in the other order straight through. On Growth and above the block is switched to the match type it needs and re-pushed; on Starter the row is annotated with what it should be, and you change it from the plan.

The review is capped: it may change at most a fifth of what it was shown in one pass, so a bad reading cannot empty a list. You will see what it did in Activity, and each changed row explains itself.

Two changes to how Spagify's AI reads your search terms.

It now says how each block should be matched. Google gives a negative keyword three ways to match, and they mean the opposite of what most people expect: broad is the widest block, exact the narrowest — an exact block on a single word stops only the bare one-word search and nothing else. When the AI proposes a block from a search term it now also says which shape it needs: a name matched as a phrase, a pair of words that must both appear in any order (matched broad), or, rarely, one exact search. Until now every AI block was a phrase, so a pairing like "dual zone" let "zone dual" straight through.

It stops the brand guesser calling product words brands. Spagify looks for brands you do not sell by spotting words that keep appearing next to your product types without ever converting. That rule cannot tell a brand from a noun — on one account it proposed blocking "chlorinator", which is a product, not a maker. The AI already reads those same searches, so where it has read a search and did not name a brand in it, the rule now stands down. Searches the AI has not read are still judged the old way.

Nothing here pushes anything new to Google on its own; AI proposals stay in review as before.

When Spagify finds a brand you do not sell showing up in your searches, and that brand is also an ordinary word — American, Star, Harmony, Elite — it blocks the brand paired with a product type so the ordinary word stays open. Until today it built that pairing by crossing the brand with every product type in your store. One account got 494 exclusions that way: "american avis-add-charge", "harmony lead removal multimedia", "star nitrate removal" — pairings no shopper has ever typed, several of them built from product-type labels that are really internal bookkeeping. They sat at the top of the list, they matched nothing, and they buried the exclusions that mattered.

A brand block is now built from the words shoppers actually typed next to that brand, most common first, and never more than three per brand. If no one has paired the word with anything yet, Spagify says nothing rather than filing a block that cannot fire. Brands you add yourself under Global Exclusions still get paired — with the product types you sell most of, capped the same way.

The junk rows on the account above are being cleared; nothing you approved or pushed is touched.

Some brand names are also ordinary words — Delta, Summit, Elite, American, Star. Blocking one of those outright is dangerous, because it would also block anyone searching for the ordinary word, so Spagify instead blocked the brand paired with one of your own product types: delta faucet rather than delta.

That pairing was matched as a phrase, which means Google only honoured it when the shopper typed those words in that exact order, next to each other. "delta faucet" was blocked. "faucet by delta" was not. Neither was "delta kitchen faucet". The block looked right in your list and let most of the traffic it was written for straight through.

These pairings are now matched on all the words, in any order, which is what they always meant. Nothing else changed: a real brand name, a model number or a product title is still matched as a phrase, because those have one spelling and one word order. There is nothing to do — the change applies as your exclusions are next refreshed.

On the Launch page you can tick regions that are expensive to ship to — Alaska, Hawaii, Puerto Rico, Guam and the rest — so your ads do not run there. Each of those ticks sent Google a region code, and all but Alaska's were the wrong code. They are not guessable numbers and the names beside them looked right, so nothing gave it away.

What it meant in practice: a campaign launched with those boxes ticked stopped showing ads in Colorado, Virginia, Washington DC, Vermont and Rhode Island — about 25 million people — while still showing them in the places you had asked to skip. Hawaii's code was Colorado's, Puerto Rico's was Virginia's, Guam's was Washington DC's. The Canadian territories pointed at three cantons in Switzerland.

Every code has been corrected and checked against Google directly, and a test now pins each one so it cannot drift again. New launches are right from today. Campaigns you have already launched keep the old exclusions until they are corrected — if you ticked any of these regions, check Locations on your campaigns, or contact us and we will fix them for you.

Until now everything Spagify could say to you was either about your own account — an alert about a product, a campaign, your feed — or an email. There was no way for us to tell you something about Spagify itself at the moment you were looking at it: a permission we now need, a change worth planning for, something we fixed.

There is now a banner at the top of the page for exactly that, and its colour tells you what kind of message it is before you read a word. Green is something good that is already done and needs nothing from you. Blue is worth knowing. Orange is something changing that you should plan for. Red is something only you can fix, and it stays until it is fixed.

You can close anything that is only news, and it stays closed. A message that needs something from you has no close button, and disappears on its own the moment the thing it is about is resolved — reconnect a store the message is asking you to reconnect, and it is gone on your next page load without you dismissing anything.

Spagify approves and pushes the safe exclusions on your plans by itself, but that pass only ever looked at the plans it had created for a live funnel. A plan made any other way was never picked up — so a safe suggestion on one could sit there indefinitely: not counted anywhere as needing you, and not approved by anything either. One account had eleven short terms sitting in exactly that state, quietly left out of every push.

Every plan is now checked on each pass, whoever made it. Anything safe and still waiting is approved and pushed the same way, so nothing depends on which plan it happened to land on. This only runs where automatic approval is already on for your workspace and your account is set to act — nothing starts pushing on its own that was not already.

The Negative keywords list had one red Conflicts number per plan, telling you to go resolve it. Most of what it counted was not yours to resolve: terms Spagify had already ruled out and will never push — a word that would have blocked something you sell, a duplicate, a term Google already covers, or one the system watched and decided against. On the plan Spagify maintains for each funnel it could only ever be that, because those exclusions are approved when they are created and never go to review. So the number was permanently red with nothing behind it.

It is now two columns. Excluded is what Spagify ruled out — settled, shown plainly, there to read rather than act on. Waiting on you is the short list actually held back for a decision, and it only turns red when there is something in it. For most plans, and for every funnel routing plan, it reads zero.

When Spagify could not push a negative keyword to Google Ads, the plan said the push had failed and the only explanation on offer was "Google Ads rejected the operation — see error message in the audit log". That is not something you can act on, and the audit log is not a page you can open.

A failed plan now explains itself. Each reason appears once, however many exclusions it held back, and says plainly whose move it is: something only you can do, something that is on us, or something that clears on its own. Where there is somewhere to go, there is a button that goes there — reconnect a Google Ads account whose permission lapsed, or open your lists when the account-wide exclusion list has hit Google's 1,000-keyword cap. Where it is ours, it says so, so you are not left hunting through settings for a problem you cannot fix.

Reasons Spagify does not recognise yet are not a dead end either: the failure still names who owns it and hands us the full response from Google with one click, so you do not have to go find it.

Spagify keeps a short list of searches nobody buys from — "pdf", "jobs", "tutorial", "torrent" and a dozen more — and blocks them across your whole Google Ads account. Google allows exactly one account-wide negative keyword list per account, so if you already had one of your own, Spagify could not add a second: those exclusions quietly fell back to a list covering only the campaigns Spagify built, and your own campaigns kept paying for those searches. It still worked, it just covered less than it appeared to, and nothing said so.

Now it does. You get one alert, under Existing account import in your notification settings, naming your list and how many exclusions were affected, with the three ways out: add the terms to your own list, delete your list and let Spagify create its own, or leave it as it is. The alert updates itself while the situation lasts and closes on its own once the slot frees up. Nothing about Spagify's behaviour changed — it still never writes into a list you own — and the same narrowing is now recorded in your activity log either way.

On the Negative keywords page, the plan Spagify maintains for each funnel was listed as "Funnel Routing" followed by a long internal id. If your launch was split into one funnel per brand or category you got one of those rows per funnel, told apart only by the id — so there was no way to see whose numbers you were reading. Each row now carries the funnel's own campaign name, and the short id stays underneath for when you contact us.

The Synced column counts the same thing as the columns beside it. It used to count placements — one per ad group a negative is applied to — while Total, Approved and Conflicts counted negatives, so Synced could read higher than Total and look like an error. It now counts the negatives that are live in Google Ads, and hovering it still tells you how many placements those hold.

Asking for help now takes a picture with it. Open Help and there is a box under "what happened" — drop a file on it, click to browse, or just paste: take a screenshot with your keyboard shortcut and press Cmd-V (Ctrl-V on Windows) anywhere in the form, without saving the image first. Up to three files, 5 MB each, and images, PDFs and plain text logs are all accepted. Each one goes straight to the person reading your request, so a screen that looks wrong no longer has to be described in words.

And the button itself is easier to find. Help used to be an unlabelled icon between two other icons in the top bar; it is now a labelled button in its own colour, which is not much of a change unless you were the one hunting for it while something was broken.

Launch new campaign now sits at the top of the Overview page, beside the date range. Overview is where you land and where you ask what to do next, and starting a new set of campaigns was only reachable from the small button in the top bar. It appears once a Google Ads account is connected, and goes to the same launch flow.

On a large catalogue the Launch page could fail outright with We couldn't reach Spagify. Check your connection and try again. — with nothing wrong with your connection. Asking Google for a suggested bid sent every selected product's id in the web address, and past a few hundred products that address grew longer than our own gateway accepts, so the request was turned away before it arrived and the page had nothing to show. The ids now travel in the body of the request, which has no such limit, so the step works on a catalogue of any size.

When you rename a product, its old page stops existing and Google disapproves the offer within a day unless a redirect sends the old address to the new one. Spagify asks for exactly one write permission to create that redirect, and it was asking for the wrong one: write_content, which covered redirects in an older version of Shopify's API and does not in the current one. Shopify answered "Access denied", and the redirects were never created.

Spagify now asks for write_url_redirects, which is the permission Shopify actually checks — and nothing else changes about what Spagify can touch: still no pages, blog posts, themes or navigation. If you connected with a custom app, add write_url_redirects to its scopes in your Shopify Dev Dashboard, release the new version, then reconnect from Settings → Integrations; Spagify tells you on that page while the permission is missing. Everything else about your account keeps working in the meantime.

When a launch is split into one funnel per brand or category, the daily budget is divided evenly between them. Google only accepts a budget in whole cents, and the division did not round — so a total that did not divide cleanly into the number of funnels (the more funnels, the likelier) produced an amount like $0.625 a day, Google refused it, and every funnel of the launch failed at its first step with nothing created. Each funnel's share is now rounded to the nearest cent before anything is built, the budget you type is held to cents in the form, and any budget Spagify sends to Google — on a launch or a later change — is rounded the same way as a last line of defence. If your split launch failed this way, launching it again builds it correctly.

Splitting a launch by category needs a category on each product, and most stores have none: Shopify's category and product type fields are optional, and a catalog built by import rarely fills them. Until now every such product landed in the "Other" funnel, so for those stores the split did nothing.

Spagify now reads the titles of the products your store has not categorised and names a category for them the way a shopper would search — "range hoods", "wine dispensers" — reusing your own category names wherever the products belong there, so a store that has categorised half its catalog keeps one vocabulary. It runs on its own shortly after your products sync and again whenever new uncategorised products arrive. On the Launch page these products now group under those names; a product your store has categorised keeps your category, always, and if you fill categories in later yours take over without anything to redo.

On the Launch page you could group campaigns by category, but the switch to launch one funnel per category was greyed out: every category's Generic campaign would have competed with every other's for the same searches, and nothing kept a "cookware" search out of the Electronics funnel. That is wired up now, so the switch works. Each category among the products you pick gets its own Generic / Brand / Product-Specific funnel with its own budget, and every other category the store sells is excluded from all three of its campaigns, the way other brands already are. A category that shares a word with the funnel's own — "Coolers" beside "Wine Coolers" — is left alone, so a funnel never blocks its own traffic. Products with no category share one "Other" funnel, which excludes every named category and catches the rest.

One fix underneath applies to launches you may already have. A brand carried by products both inside and outside a funnel — a split by category puts the same brand in several funnels, and launching only some of a brand's products leaves the rest outside — was being treated as another brand and excluded from all three of that funnel's own campaigns, so the funnel could not show for its own brand's searches. A brand that any product in the funnel carries is never excluded from it now. Existing funnels pick this up on their next routing refresh, which also removes the wrong exclusions.

Shopify tells Spagify about a product or stock change by sending it to whichever Spagify apps your store has installed, and it stamps each message with the key belonging to the app that sent it. If your store had two — a custom app you created plus the one from the App Store, or a custom app you rebuilt without removing the first — Spagify only recognised the stamp from one of them and turned the others away.

You would not have seen an error. The updates simply did not land, so a price or stock level could sit stale until the next full sync picked it up.

Spagify now recognises a message stamped by any of its own apps, so every update arrives whichever app sent it. This is not a loosening of the security check: a message still has to carry a valid stamp from an app you installed, or it is refused exactly as before. We also now spot when a second, redundant app is still sending, so it can be tidied up.

A plan's header could say 11 conflicts while the Conflicts tab under it showed none. The header was a number written once when the plan was generated; the tab counted the rows in front of you, by a different rule. Every conflict figure on the page — the summary card, the line beside the push button, and the tab — now counts the same rows the same way: rejected, blocked by policy, or flagged by the conflict check (self-blocking, duplicate, already in Google Ads, category overlap). The stored number is refreshed whenever a row changes, so the plan list agrees too.

The rows behind the phantom count were short terms — "red", "pdf", "diy" — that the conflict check had marked for a second look. That marking left them suggested but counted them nowhere: not under Needs review, not under Conflicts, and never picked up by the automatic approval, so they were left out of every push without anything telling you. A short term is now treated as what it is, a medium-risk negative: approved with the rest when your plan approves medium-risk terms automatically, and left suggested alongside the others when it does not. A category overlap or a performance block with weak evidence still waits for you, and now shows under Needs review with the other high-risk terms.

Shopify has several ways to describe stock — counted or not counted, and, when counted, either refusing orders at zero or letting customers keep buying. Spagify reads all of them, and asks you directly about products Shopify does not count. Two updates were not following the same rule.

When a stock change came in from Shopify, the older answer could win. A product that had just sold out was recorded correctly, but an earlier reading of it stayed on file and took precedence the next time anything looked. The effect was a sold-out product quietly becoming eligible to advertise again — and an ad whose own page says sold out is what gets a product disapproved in Merchant Center. A stock update now records a sold-out it finds, while anything it cannot see — a draft product is not for sale however much stock it has — is left to Shopify to answer.

And if you told us not to watch stock for a product, that answer was overriding Shopify itself. It is meant to settle the cases Shopify leaves open, not to contradict a definite sold-out. A product Shopify counts, that refuses orders at zero, and has none left, now stays out of your ads whatever you answered. Products Shopify does not count, and products set to keep selling past zero, are unaffected — they stay advertised, as they should.

A Google Shopping ad finds your product through its offer in Merchant Center. If the account linked to Spagify has no offer for a product, an ad for it can never show — so Spagify refuses to build one. That refusal was the first you heard of it: you would choose how campaigns are grouped, pick your products, set locations, bids, a daily budget and your safety options, press Launch, and only then be told none of it could run. The message named an account number and suggested checking your feed, which sends you to look at a store that is often perfectly fine.

Spagify now checks the moment the account is linked, and tells you what it found. The common cause is not a few missing products — it is an account fed by a different store than the one you connected, and that is now said plainly, with the number of products the account does carry.

On the Launch page, any product your feed has no offer for is marked Not in feed in the product list, so you see it while you are choosing rather than at the end. If some of your products are missing, the launch leaves those out and builds the rest. If none of them are there, the message now tells you which of the two things is wrong — an account with nothing in it needs your store's feed published to it, an account full of another store's products needs a different link — because retrying without changing one of those fails in exactly the same way.

When something failed, what came back was often the raw technical reply — the request we made, a status code, and a blob of JSON. A launch that refused looked like this:

POST /api/google-shopping/build-campaign-set failed: 400 {"message":"None of the 8 selected product(s) could be found in Merchant Center account 5741451424 (50 offer(s) read)…

Now it reads as three things: what happened, why it happened, and the one thing to do next — with a link straight to the page where you do it. The same launch now says none of the products you picked are in your Merchant Center feed, that your feed has 50 products and none of them are these, that it is usually because they are under review, disapproved or out of stock, and links you to Merchant Center.

Nothing technical reaches you any more: a server problem, a request that never got through, and a page that failed to load all say so in plain words instead of showing a status code or "Failed to fetch".

When a part of the app could not fetch its data, most of the time it simply kept spinning. A few pages went blank instead, and one settings switch showed off for a setting that might well have been on. All three read as "still working", none of them said anything had failed, and none gave you a way to retry short of reloading the page.

Anywhere this can happen now shows what went wrong and a Try again button — the reason the API gave, in place of the spinner, with the rest of the page untouched. That covers your billing and plan details, auto-approve and routing settings, the keyword and negatives tabs, a product's keywords and negatives, and the admin pages. Data already on screen is never replaced by an error: if a background refresh fails, what you are looking at stays.

Your original 21-day trial date stays on your account after you subscribe. Once that date passed, every page except Settings was replaced by Your trial has ended and an invitation to upgrade — on a plan you were already paying for. Nothing was actually wrong behind it: your campaigns, your data and everything Autopilot does carried on normally the whole time.

The screen now appears only for accounts genuinely still on the free trial. On a paid plan every page opens as usual, whatever your original trial date says.

Connecting a store queues every one of its products to be read for brands, product lines and identifiers. Spagify was taking the whole catalogue at once, and on a large one the hourly update ran out of memory and stopped before it finished — then started over an hour later and stopped in the same place. For a store this had just happened to, nothing moved: no metrics, no alerts, no changes to your campaigns.

The catalogue is now read in batches, a few hundred products an hour, and the rest of the hourly update runs normally while it works through them. A large store takes a few hours to read in full instead of never finishing, and everything else about your account keeps up to date the whole time.

A Google Ads account can be connected to one Spagify workspace at a time. Choosing one that another workspace already has used to fail with an unexplained error on the Confirm account step, with nothing to tell you what had gone wrong or what to do.

It now tells you the account is already connected elsewhere, and names it, so you can either disconnect it there or sign in to the workspace that already has it. Re-confirming the same account in the workspace that already owns it now simply succeeds, so a retried setup step no longer dead-ends.

When a launch failed, the Launch window told you why and offered Retry. If the retry failed for the same reason, the window stayed on Build plans with the spinner running and no way to close it; the only way out was to reload the page. It happened today to a merchant whose whole catalogue had been refused as out of stock (see the entry below).

A retry that fails now shows the failure again, with the same message and the same Retry and Close buttons, however many times you try. A failed build creates nothing in Google Ads, so retrying is always safe.

If you do not count inventory in Shopify — because your supplier holds the stock and ships it — Shopify reports no units for your products. Spagify was reading that as "none in stock" and refusing to advertise any of them. A launch would stop with No eligible products were found for this workspace, which told you nothing you could act on, and it was your whole catalogue.

Spagify now reads availability the way your storefront does. If a shopper can buy it, it can be advertised: products you do not count, products set to keep selling when they run out, and products with units on the shelf. Nothing changes for a store that does track its own stock.

Where Shopify does not say either way, the Launch page now asks instead of refusing. Products showing no units are listed with one question — Track inventory for this product? — answered Yes or No per product, or for all of them at once. No means your supplier holds the stock, so advertise it whatever the count says. Yes means watch Shopify's count and keep it out until stock shows. Your answer is remembered, so you are asked once, not at every launch.

One thing you cannot answer your way past: a product that is genuinely sold out on your own store. Google disapproves an offer that says in stock when the page says sold out, so those are listed separately, with a button to take them out of the launch. Restock them in Shopify and Spagify picks them up on the next sync.

Editing a product with a lot of variants or a long description could fail to reach Spagify. The update was rejected before it was read, so the change stayed in Shopify and Spagify carried the old details — the wrong price or title could sit in your ads until the next full sync caught up.

Spagify now accepts product updates of any size Shopify sends. The next edit to any product comes through. One thing to check if this had been happening to you for a while: Shopify stops sending updates altogether after enough failed attempts, and it does not start again by itself — reconnect Shopify from Settings → Integrations and they resume.

Connecting Shopify means building a small custom app in your Shopify Dev Dashboard and pasting its Client ID and Client secret into Spagify. The five steps for that, with a copy button on every value you have to type into Shopify, used to open in a panel only after you clicked Connect with Custom App — one click past the step that asks for your store, so the step itself gave you nothing to follow.

They are now on the Connect Shopify step itself. Enter your store domain at the top, follow the steps below it — the Shopify admin link opens your own store once the domain is in — and paste the two credentials under Paste them here at the bottom. Nothing to open first, and nothing to keep open while you work in Shopify.

From Settings → Integrations, the same walkthrough still opens in a panel on the right.

Until now every product Spagify imported from your store was labelled Testing from the moment it arrived — including products that had never been in a campaign. Right after connecting a store, that made the whole catalog look as if Autopilot were already working on all of it.

Testing now means what it says. A product is Not in ads until a campaign gives it a live ad group, becomes Testing the moment one does, and goes back to Not in ads if its last ad group is removed. Scaling and Paused are unchanged. The Products and Autopilot pages group products the same way, and the Launch page can filter on Not in ads when you are choosing what to advertise next.

Nothing changes in Google Ads. Autopilot never made decisions about products without ads; the label now says so.

Clicking a column heading on the Brands page could leave the table with more rows than you have brands: some brands appeared twice, a few sat at the top out of order, and every further click added more. It happened on stores whose catalog lists a manufacturer under more than one spelling — "Bosch" and "BOSCH", or "Sub-Zero" and "Sub Zero". The table showed them as separate rows but treated them as the same one.

Every brand row now has its own identity, so sorting rearranges the rows in place. Clicking Brand sorts A to Z first and Z to A on the second click, like every other table in Spagify, and the column headings use the same sort arrows as the Campaigns and Search terms tables. Brands spelled two ways in your catalog still show as two rows, because that is how your store lists them.

Until now the Launch page chose products for you. You narrowed the catalog by brand, category, product type, price or stock, and Spagify took everything that matched, or its recommended subset. If you wanted one particular product left out, or one particular product added, there was no way to say so.

Choose products is a new control in the Products step. Narrow to a brand or category first, open it, and every product in scope is listed with a checkbox, all ticked to start. Clear the ones you do not want, or Deselect all and tick only the ones you do. A quick search across product name, SKU, brand and category finds the one you mean in a catalog of hundreds, and Select all and Deselect all act on whatever the search matches. Products in Spagify's recommended set are marked; the Use recommended products switch, now off unless you turn it on, narrows the start set to them.

Your choices are kept when you change the filters or the recommended switch. Products that come into scope later follow the automatic rule; anything you decided by hand stays as you left it. The number of changes you have made shows on the button, and one click undoes them all.

Preview and the launch itself use exactly what you ticked. If you never open it, nothing changes: the automatic pick works as before.

Spagify lowers a bid when an ad group is already winning essentially every auction it enters and paying more than the market to do it. At that point the extra cents buy nothing — the impressions were coming anyway.

On some ad groups that never happened. Two rules read your click counts differently. The rule that reacts to clicks without a sale discounts recent clicks first, because on a store where people take days to decide, a click from yesterday has not had its chance yet. The rules that react to your share of the auction were reading the undiscounted count. Between the two numbers sat a gap, and an ad group whose clicks landed in it matched neither rule — so no bid rule ran on it at all, and the bid simply stayed where it was.

The gap fell exactly on your best ad groups. It takes a certain amount of traffic to land in it, which means the ad groups doing the most work were the most likely to be frozen — winning every auction, overpaying for it, and holding that price day after day.

What you will notice: the bid rules act on these ad groups again, in both directions. One that is winning its auctions outright and paying above the market has its bid brought down toward what the market actually pays, and that particular step stops at your market benchmark rather than going under it. One that is still losing impressions because its bid is too low can now be raised instead — while it was frozen, neither could happen. Nothing moves faster than one step a day, and every bid stays inside the band around your plan bid that it always has.

The spend figure on your Overview has always been the total across the products Spagify advertises. If you also run Performance Max, a Search campaign, or Shopping campaigns of your own, that number was smaller than the one Google Ads shows you — with nothing on the page to explain the gap.

Where your ad spend goes is a new panel under the Revenue vs Spend chart. It splits the account's entire spend into Spagify-managed, your other Shopping campaigns, Performance Max, Search and anything else, with clicks, conversions, revenue and ROAS for each. The two numbers now reconcile.

Read it as composition, not a contest. Google spreads conversion credit across every campaign that touches a purchase, so these rows do not add up to your account's revenue and no single row's ROAS stands on its own. Performance Max also takes the auction from Standard Shopping on the same product, so wherever it overlaps products Spagify advertises it is holding that row down — which is exactly what the Performance Max alert is there to tell you.

If Spagify is the only thing running on your account, the panel does not appear. There would be nothing to compare it against.

There is now a Spagify community on Slack: a place to ask questions, see what other merchants are doing with their funnels, and talk to us directly.

Where to find it: spagify.com/slack. The welcome email introduces it, every email from Spagify links to it in the footer, and the last step of setup does too. That one address always takes you to a working invite, so a link you saved weeks ago still gets you in.

Spagify blocks a search term as wasteful when it has taken clicks and produced no sale. The question underneath that is statistical: how many clicks with no sale would be surprising? If a term gets a handful of clicks and none of them buy, that is what most terms look like most of the time — it is not evidence of anything.

The bar was 15 clicks, and it was too low to mean what it claimed. At a 3% conversion rate — ordinary for Shopping — fifteen clicks produce no sale 63% of the time by pure chance. Spagify was blocking terms on a coin toss, and roughly two times in three the term had done nothing wrong.

The bar is now 100 clicks, the point at which no sale is genuinely unlikely (under 5%) rather than merely common. If you sell higher-priced products, where each sale takes more clicks, your account's bar is higher again.

What you will notice: fewer terms flagged as wasteful, and a longer wait before one is. That is the intended trade — the ones you do see are now terms with real evidence against them, instead of terms that were unlucky. Nothing already blocked is unblocked, and if you have set your own click threshold it is left exactly as you set it.

This pairs with the spend change below: money decides whether a term is worth acting on, clicks decide whether there is enough evidence to act. They are now doing those two jobs separately.

Spagify blocks a search term as wasteful once it has spent enough money with nothing to show for it. "Enough" was a fixed $50, the same figure whatever the size of your account — and a fixed figure is the wrong shape for this.

If you spend a few hundred a day, $50 on one query is barely noticeable, and Spagify was arguably too quick to act. If you spend a few dollars a day, $50 is more than your whole account spends in a fortnight, so no single query could ever reach it — the protection existed on paper and could never fire. A store running £3 a day got nothing.

The bar now scales with your account. It is a share of what your ads actually spent over the window, with a small floor, and it never rises above the figure you have configured — so if you are spending enough for the old bar to have made sense, nothing changes for you at all. Below that, Spagify can finally see the terms quietly draining a small budget.

One thing deliberately did not change: how many clicks a term needs before Spagify will judge it. That is not about how much money is at stake, it is about having enough evidence to be confident, and lowering it alongside the money would turn a careful rule into a guess.

Anything newly caught by the lower bar is offered to you rather than applied. Spagify treats a term that has spent less than the full configured amount as a judgement call, which means it is prepared, explained, and waits for you to apply it — on every plan, however your automation settings are configured. You get the finding without handing over the decision.

Spagify blocks a search term as wasteful when it has taken clicks, cost real money, and recorded no sales. That reasoning only works if your account is able to record a sale.

If conversion tracking is broken — no purchase action counted, or a tag that never fires — then every search term in your account reads zero sales, including the ones that are quietly making you money. The rule could not tell the difference, so it would have blocked whichever terms simply spent the most. On most stores those are the best ones.

Spagify now checks that your account has actually recorded sales before it judges any term for the absence of them. If it hasn't, no term is blocked for lack of conversions, and Spagify says that is why rather than quietly finding nothing — because a report with no findings looks exactly like a healthy account.

There is a second, less obvious case it now handles. When tracking gets fixed, the clicks from before the fix stay unmeasured forever — a tag that was not firing does not go back and fill in the sales it missed. For a while the account looks healthy while still holding weeks of clicks that could never have recorded anything. Spagify waits for that period to pass out of view before judging terms on it again.

Rules that use the absence of sales to protect a term are unchanged, and still work whatever your tracking is doing — Spagify will never propose blocking a brand or a query that has converted.

If your conversion tracking is healthy, nothing changes for you. If it isn't, the alert on your dashboard is the thing to fix, and these blocks resume on their own once it is.

When Spagify raises a bid to win back impressions you are losing to better-ranked competitors, it needs to know how much you are actually losing right now. For a product with steady traffic it reads that over the last few days. For a very quiet product there is not enough recent traffic to read, so it falls back to a two-week view.

Spagify no longer raises a bid on that fallback view. Two weeks of a quiet product's history covers as many as fourteen different bids, so the gap it reports is largely one that earlier, lower bids left behind — not one today's bid could close. Raising into it bought nothing, and because each tier is kept above the one below it, an inflated bid on a quiet product also pushed up the bids sitting above it.

A quiet product can still have its bid raised when it is genuinely starved — very few impressions and a small share of the ones available. That is a judgement about how often your ad is eligible at all, not about price, and it is the case where a higher bid does help.

If your products all get regular traffic, nothing changes for you.

Earlier today Spagify stopped raising bids on auctions you are already winning. That was only half the problem. A bid that had climbed higher than it needed to still had no way back down — it stayed there, winning the same impressions it would have won for less.

When a product is winning effectively every auction it enters, and bidding more than the going rate to do it, Spagify now walks that bid back toward the going rate. It comes down gradually — at most 15% a day, the same limit that governs every other bid change — and it stops at what the market pays rather than dropping below it. The moment the auction starts pushing back and you begin losing impressions again, the descent stops, and the ordinary rules take over.

This is money back with nothing given up. A bid above the going rate on an auction you already win outright is not buying you position; it is only raising the price of the clicks you were getting anyway.

Two rules still come first. If a product is converting, what its sales afford decides its bid, not its impression share. And a bid never drops below the tier beneath it — your Product Specific bids stay above Brand, and Brand above Generic, whatever the auction says.

You will see this on your daily bid summary as winning every auction, so paying less for the same ads.

Yesterday Spagify started repairing a purchase action that cannot record a sale. It had a flaw worth correcting quickly, because it could quietly make an account harder to fix rather than easier.

Some stores have two purchase actions: one that Google Ads created for a tag on the storefront, and one imported from Google Analytics. If the tag was never installed, the first of those can sit there enabled and doing nothing, while the Analytics import — which is receiving your orders — sits switched off beside it. Spagify used to reach for the enabled one first, because that is the commonest fix by a wide margin. On a store in this shape, counting it changes nothing, and it leaves the account looking repaired, so the import that would have worked is never switched on.

Spagify now checks whether anything has recorded at all first. If your account has recorded nothing — not one conversion on any action, counted or not — then an action that is switched on has clearly never fired either, and switching on an Analytics import instead is the change with a chance of working. When something has been recording and simply is not counted into your Conversions column, nothing changes: that is still a one-field fix and Spagify still makes it.

If your store has no Analytics import, nothing changes for you either.

Spagify now sends a monthly performance report on the 1st, on every plan. It covers the calendar month that just finished against the month before: what the ads cost, what that bought, what Spagify changed on your account, the negatives it pushed, the warnings still open and anything waiting on you. It arrives switched on — you can turn it off under Settings → Notifications like anything else.

This closes a real gap. The weekly report is a Growth feature, so a Starter account that never opened the notification settings got no recurring report about its own account at all. Now every plan hears from Spagify once a month, whatever else is switched on.

Both reports now carry the numbers you would otherwise look up in Google Ads: cost, impressions, clicks, CTR and average cost per click, alongside orders, revenue and ROAS — laid out in the order an ads report reads, each one beside the same figure for the period before and the change between them. Reports already in your Inbox pick up the new rows too.

They are also now called what they are. "Your week in Shopping" is the Weekly performance report, and the button at the bottom takes you to your dashboard rather than to an empty queue when nothing is waiting on you.

One more thing, on Starter: when a month goes by in which Spagify only proposed changes rather than applying them, the report says exactly that and points at your Inbox, instead of reading as though nothing happened.

If you are on Growth or above, the recommended notifications are now switched on for you rather than waiting to be found: ads that stopped serving, funnel health, automation failures, the existing-account import, and both performance reports. Anything you had deliberately switched off, and anything outside that recommended set, is unaffected going forward — and product updates are untouched either way.

When one of your products is losing out to better-ranked competitors, Spagify raises its bid to win some of those lost impressions back. To decide that, it looks at how much of your available impressions you are losing to rank.

It was looking too far back. That figure was read over the past two weeks — but Spagify adjusts your bids every day, so a two-week average blends together as many as fourteen different bids, and keeps reporting the gap the oldest and lowest of them left behind. Once a bid had done its job and started winning, the old reading still said there was ground to make up, and Spagify kept raising. On a product already winning nearly every auction, a higher bid buys nothing new — it just pays more for the impressions you were already getting.

Spagify now reads that figure over the last few days instead, so it reflects the bid you are actually running today. When a product has too little traffic for a short read to mean anything, the longer view still answers, so nothing changes for your quieter products. And a bid increase is now refused outright — on the daily pass as well as the hourly one — when there is no meaningful share left to win.

You may see a product's bid level off rather than continue climbing. That is the point: it had stopped buying anything.

Your Google Ads connection card now counts the paid orders of the last 30 days that were created away from your storefront — by phone, from a quote you invoiced, or at the till — and says what became of each: how many carried a Google click id and were recorded in Google Ads, and how many had nothing to credit them with.

Until now Spagify only kept the orders that carried a click id, so it could not tell you how much of your revenue the ads were never getting credit for. Every paid order is now recorded, with or without one. The ones with no click id are counted, not sent anywhere: an order like that cannot be matched to an ad with what Spagify currently reads from Shopify, and the card says so plainly rather than leaving the number out.

On Starter the card shows the same counts and what Growth would do with them. On every plan, an ordinary storefront checkout is left to your Google Ads tag; Spagify never sends it a second time.

Spagify has grown a lot of engines this quarter, and the plan pages never said which of them act on your account by themselves. They do now, and the line has moved on Starter.

Every paid plan, unchanged: your funnel launches and stays launched. Bids are stepped hourly and daily, the shared budget is kept whole and repaired when it breaks, Query Protection's routing and uncarried-brand negatives go out on their own, low-risk mined blocks push themselves, and every guard acts without asking — out of stock, disapproved by Merchant Center, taken over by Performance Max, search partners earning nothing. Every alert, every explanation and the daily note per funnel are on every plan too. Spagify never stops telling you something is wrong because of your plan.

What now waits for one click on Starter: the judgement calls. Medium-risk negatives mined from your search terms — waste predictions, pooled phrases, impression hogs, and what the AI read of a query concluded. Moving budget between funnels to follow the better earner. Moving a campaign up Google's bidding ladder when it qualifies. Spagify still finds every one of these, checks it against your catalog, and prepares it with its match type and scope; it then sits in your Inbox behind an Apply button instead of going out on its own. Nothing already applied is undone.

Growth and above: all three happen without you, as before.

Two things worth knowing either way. A high-risk block has always been described as waiting for a person, and in one path it could slip through on confidence alone — that is fixed, and it now waits on every plan. And a proposed bidding-strategy move used to have nowhere to appear; it is in your Inbox now.

A sale closed by phone, from a quote you invoiced, or at the till still goes through Shopify — but the Google Ads tag on your storefront never sees it, so as far as Google Ads knew that customer never bought. Spagify has had a path for these sales since launch, and it has never worked: no conversion was ever sent. The counter on your Google Ads connection card has read uploaded: 0 the whole time. That is fixed.

Growth and above: when an order created outside your storefront carries a Google click id — a quote form on your site can pass one through — Spagify now records it in Google Ads against the ad that brought the buyer. It goes into a conversion action of its own, Spagify — offline & assisted sales, which Spagify creates in your account the first time it has something to send. Nothing your storefront tag already recorded is ever sent again: an ordinary checkout is the tag's sale, and sending it too would count it twice.

What this does not do yet: an order with no click id — a phone sale from a customer who never went through your site, a quote raised by hand in Shopify — still cannot be matched. That needs the buyer's email or phone from the order, which Spagify does not currently read from Shopify; we are looking at what asking for it would involve before deciding. For now, the fix is that the sales that can be credited are, and that number stops being zero by construction.

Starter accounts keep everything as it was; nothing is sent.

Spagify keeps a record of every bid change it makes for you: what your campaign looked like at the time, what it decided, and how that product performed over the week afterwards. That record is what will eventually let Spagify judge its own bidding rules against real results instead of following fixed ones.

There was a problem with it. Your daily bid steps were exactly the same size every time, so the record could only ever show what the current rules do — never whether a slightly different bid would have done better. A record with no variation in it cannot answer that question.

Daily steps are now varied a little, by up to a fifth of the step's own size. A step that would have raised a bid 10% might raise it 8% or 12% instead. On a $2.30 bid that is a few cents. What does not change: the direction is never reversed, so a step up is always a step up, and every limit already in place still holds — the most a bid can move in a day, the bounds around your plan bid, and the ceiling that keeps a bid near what clicks cost in your market. Your hourly Generic steps have worked this way since launch; this brings the daily steps in line.

You do not need to do anything, and the effect on what you pay is small by design.

Spagify has grown a lot of controls, and not everyone needs all of them. We are working towards display modes — from a simple view up to a full one, plus a custom set you choose yourself — so the app can show you the parts you actually use instead of everything at once.

To decide what belongs where, we have started counting how often each control is opened: a filter, a table sort, a settings panel. These are counts, not a recording. We store the name of the control and the page it is on, attached to your account. We do not store what you typed, your search terms, your product or brand names, or any value you enter into a field — and a control that has no name of ours on it is counted only as "a button was pressed on this page".

Nothing looks different yet. The display modes will not arrive until there is enough real use behind them to draw the lines honestly. Our Privacy Policy has been updated to describe this.

Last week Spagify started telling you when your account had no way to record a sale. Telling you was only half of it: the commonest version of this fault is one checkbox. A purchase conversion action sits in Google Ads, enabled, marked primary — and simply not counted into the Conversions column, so every sale it sees is thrown away and every "no conversions" figure you are shown is empty by construction.

On Growth and above, Spagify now makes that change for you. Once a day, if nothing in your account counts purchases, it will count a purchase action that is enabled but excluded, un-hide a hidden purchase import, or create a purchase action if you have none at all. Every change is written to your activity log with what it was before and what it is now, so you can see exactly what happened and undo it.

It is deliberately narrow. Spagify only ever touches actions in the Purchase category — never a lead, sign-up or page-view action, because counting one of those would quietly change the number your bids are optimised against. It never turns anything off, hides anything or deletes anything. And if you turn an action back off after Spagify turned it on, it takes that as your decision and leaves it alone from then on.

One thing it cannot fix is the tag itself. If the Google Ads tag is not on your storefront, nothing fires no matter how the actions are configured, and no setting in Google Ads changes that. Accounts in that position will see this alert change rather than disappear — from no action counts sales to nothing has fired yet across your clicks, which is the more useful thing to know. On Starter the alert tells you which change to make yourself.

A Priority Funnel keeps its three tiers in order: for the same product, the Brand bid sits a little above Generic and the Product Specific bid a little above Brand, so the searches that show the most intent are the ones you pay most for. That ordering had no ceiling. Google prices each tier's clicks separately, and on one account the market price for a product's brand searches came out above the price for its specific-model searches — so every time the Brand bid rose toward its own market, it pushed the Product Specific bid up with it, to 55% over what those clicks were worth, with nothing to bring it back.

The ordering now stops at the market. A tier's bid is still kept above the tier below, but never more than 20% above what a click on that tier is worth in your market — the same limit its hourly pacing already respects. Where the market prices the tiers the other way round, the order is allowed to invert; which campaign answers a search is decided by campaign priority, not by the bid, so nothing about routing changes.

Bids already parked above that limit ease back. A bid sitting more than 20% over its market with no sales or lost impressions asking for it is walked down 15% a day until it is back inside; a bid that high because it is earning sales is a valuation and is left where it is. Your bid history shows these as "kept above the tier below, as far as its market allows" and "easing back toward its market".

When a search term's words match a product's title closely, Spagify files it under that product in Keyword Intelligence. It did that even when its own AI read of the same term said the shopper wanted something else — a competitor's brand, a product family you do not carry, a manual, a repair — so a search for a wine cooler could be filed as a keyword for a wine dispenser, and a competitor's name as a keyword for your product.

The read now outranks the word match. A term the AI has read as the wrong buyer, or could not read at all, is not filed as a keyword for the product it happened to serve, however well its words score. It is still handled the way it should be — a competitor's brand is proposed for your uncarried-brands list, an off-intent term for a block.

Keywords filed that way before are withdrawn. On its next pass Spagify removes any keyword it filed from a search it has since read as off-intent, as long as nobody has approved it. A keyword you approved is yours and stays.

Spagify shows profit as what is left after ads and the cost of the goods. When a product had no cost per item on file, that cost was treated as zero — so profit was just revenue minus ad spend, and break-even ROAS showed nothing at all. A product was reported as profitable at any return above 1.0x, which for anyone who buys their stock is not a cautious estimate, it is the wrong number.

Products with no cost on file now use an assumed 30% gross margin — a $100 product is treated as costing $70 — so profit and break-even ROAS are figures you can act on from the first day. 30% is the low end of ordinary retail margin, chosen deliberately: it understates your profit rather than overstating it, so nothing built on the number gets reckless while the real cost is missing.

It is always labelled. Any product using the assumption still shows the "cost missing" marker, its cost field stays empty rather than displaying a guess, and the alert about missing costs now names the rate it is estimating with. An estimate is never presented as a measurement.

Adding your real costs replaces the assumption straight away. Fill in "Cost per item" in Shopify and it syncs on the next product sync. If your typical margin is nothing like 30%, tell us and we can set your rate — a settings field for it is coming.

Spagify checks every hour whether your funnel is spending ahead of where the day's plan says it should be, and eases bids down when it is. The check was right; how often it acted was not.

A bid cut takes a few hours to show up in the day's spending. Spend is measured from the start of the day, so a lower bid only moves that total as the rest of the day accrues at the new price — on a smaller account, that is several hours, not one. Until now the hourly pass cut again anyway, every hour, before the previous cut had a chance to register. On one account a day that was never more than 28% ahead of plan ended up with bids 43% lower by mid-morning, and its discovery tier pinned to the bottom of its range for the rest of the day.

Bids now wait two hours after a change before moving the same way again. A move in the opposite direction is never delayed: if a cut goes too far and spending falls behind, the next hour can raise the bid straight away. Your bid history will show fewer, larger, steadier steps instead of a long run of small ones pulling the same way.

Your discovery campaign also has a real floor now. The lowest a Generic bid may go is no longer a small fraction of what the market charges — a bid that low shows your ad almost nowhere, which is not "answering searches cheaply", it is not answering them. The floor now sits at 40% of what a click on that tier is worth in your market, and your own floor setting still applies whenever it is higher. On the account above, the searches this tier exists to catch — "wine dispenser", "automatic wine dispenser" — were being shown once a day and clicked never. Generic remains by design the cheapest of your three tiers.

An account can run for weeks with ads live and no way for a purchase to reach Google Ads: the conversion action exists but is not counted, or its tag was never installed on the store. Every "no conversions" figure is then empty by construction, and everything that reads it — bid decisions, learning, the eligibility rules for automated bidding — is judging a number that could never have been anything else. Spagify's own check for this was a checkbox a person had to tick.

A new daily check reads your Google Ads conversion actions and the last 30 days of recorded conversions. If no enabled action counts purchases into conversions, you get a Sales cannot be recorded alert that names each action and its state, with what to do: install the Google Ads tag through Shopify's Google & YouTube channel, or link Google Analytics 4 and import its purchase event as a counted action. If a counted action exists but nothing has fired across enough clicks — not even on the actions that are not counted — the alert says the tag is most likely not on the site.

The alert stays current while it lasts and closes itself once a counted action exists and a conversion has been recorded. At that point Spagify also marks conversion tracking verified on your plans, so that step no longer waits on a click.

Two fixes shipped alongside it. A bulk edit in Shopify used to mark every product it touched out of stock until the next hourly sync — the update webhook was reading a field Shopify does not send — and on one account that raised five false Cannot serve alerts on products holding a thousand units. The webhook now leaves stock and price alone when the payload does not carry them. And Cannot serve alerts now close themselves once the product is active and back in stock, instead of waiting in your inbox to be dismissed.

When someone searches your shop's name — on its own, or alongside a product — that is the most decided shopper you will see all day. Until now Spagify had no rule for them, and on one account an old negative keyword was quietly keeping your ads out of those searches altogether.

Your store's name is now a Brand-tier term. It is excluded from your Generic campaign, so these searches are answered by your Brand campaign rather than competing for the discovery tier's deliberately small budget. They are not pushed into Product Specific either: someone naming your shop has already chosen you, and there is no reason to pay your highest bid for them.

Searches that name both your store and a product still go to Product Specific, decided by the product — the part of the query with a SKU in it.

Why not simply block them? Because a search like "MX4-Q3HD your store" is nine parts product and one part shop name. Blocking on your name takes a search for something you sell off the board — and every competitor carrying that product still appears in the same row of ads. Your listing is the one missing.

Two safeguards: your myshopify subdomain is never used as a keyword, and if your store's name is also the name of what you sell — a shop called "Wine Dispensers" — nothing is excluded, so your own category searches are never blocked.

Negative keywords that Spagify's rules no longer call for are now removed automatically. Previously a routing negative only went away if your catalogue changed; a rule change left the old keyword live on Google indefinitely. Nothing to click.

When a day was running under budget, Spagify raised your Brand and Product Specific bids every hour to try to use it. That is right when there are auctions you are missing. It is wrong when there are not.

Bids are now only raised where there is still impression share to win. For each product, Spagify checks how much of its available impressions it is losing because it is outranked. Where that is near zero — the ad already shows almost every time it could — the bid is held instead of raised, and the reason is recorded as already winning nearly every auction rather than a pacing step. A budget that stays unspent because there simply are not more searches to buy is not a problem a higher bid can fix, and paying more for the clicks you were already getting is the only thing it achieves.

Pacing bids down is unchanged and is never held back: one shared budget means an exhausted day stops all three campaigns at once.

Separately, the Generic tier now has more room to move. Generic exists to answer broad searches cheaply, so it is deliberately capped well below what the market pays. That cap was sitting too low — on a live account every Generic bid was pinned to it for days while the campaign lost four in five of its available impressions to better-ranked ads. The cap has been raised from half to seventy per cent of the distance between the learning floor and the tier's market target. Generic still cannot reach that target, so it remains the cheapest tier in the funnel by design.

Your daily cap is never exceeded. Google holds the budget and stops showing your ads when it is spent, and Spagify plans on less than the full cap so the day has room. Bidding higher does not spend more — it buys fewer, better-placed clicks out of the same money, and when the budget is gone the ads stop. That is deliberate.

What is new is that the budget alert now does the arithmetic. Instead of telling you that you lost a share of your impressions to budget and leaving you to guess, it names the daily figure that would stop the loss and roughly how many more clicks a day that buys at what clicks currently cost you.

It also tells you when the budget, not the bid, is the real limit. Using what other advertisers pay for the same products, it works out how many clicks a day your cap buys at the going rate. If that number is small, no amount of bid tuning will change the outcome, and the alert says so plainly rather than suggesting a bid change that cannot help.

Every figure is left out rather than estimated when the underlying data is not there yet.

Google knows what other advertisers bid for the same product you sell, and it will tell us. Until now Spagify never asked. Your bids were set from a plan when the funnel launched, and nothing since then compared them with what a click actually costs in your category.

Your funnel now aims at a share of the market price for each product. Google reports an average maximum cost per click per product; the Generic campaign aims at 45% of it, Brand at 75%, Product Specific at 100%. That keeps the funnel's shape — broad searches answered cheaply, high-intent searches paid for properly — while tying every bid to a real number instead of a guess. Bids walk toward the target inside the existing daily limits, so nothing jumps overnight, and where Google has no benchmark for a product your planned bid still applies.

And you get told when a product is underbid. A new alert names the product, your cost per click, what the market pays, and the share that represents — raised only when the gap is actually costing you impressions to better-ranked ads rather than to budget. Where your listing earns more clicks than the market average when it appears, the alert says that too, because it means the bid is the only thing standing between that product and the traffic.

This is the answer to "my ads aren't showing" when everything else is correct: the ad is eligible, the feed is fine, and it is simply being outbid.

Google bills clicks in whole cents and refuses any bid that is not one — a bid of $0.7395 is rejected outright, and until now a few of Spagify's own calculations could produce exactly that: a tier bid taken as a percentage of a launch bid, the average of several products' bids on the launch page, or a rule capped to a percentage of the current bid. The first sign was five bid changes on one store that Google threw back in a single morning.

Every bid Spagify computes now lands on a whole cent before it is sent, and a bid that somehow is not one is refused by Spagify with a plain reason instead of failing at Google. The launch page shows the same number Google will hold, the keyword bid box and the rule editor's bid and budget fields accept cents only, and a rule cannot be saved with a fractional-cent amount — you will see why straight away rather than discovering it in a failed run later.

The notifications step of setup used to be a table of twelve switches in two columns, all off, with a Slack form underneath. Most people ticked everything or nothing.

Setup now starts you on a recommended set and shows it as a short list: ads that stopped serving, funnel problems, changes Google refused, what an existing account import found, a weekly summary, and product news. Continue saves that list. If you want something different, Customize opens the full set, now grouped under four headings — problems that need you, what Spagify did, summaries, and news from Spagify — with the recommended rows marked.

Settings → Notifications has the same grouped layout and a Use recommended button that puts the list back. The Slack channel lives there too and has left setup altogether: it needs a webhook from your Slack admin, which nobody has to hand on day one.

Nothing changes for anyone who already chose. If you never opened the panel, you still receive only product news until you do.

Open a product and the Keyword Intelligence card lists the terms Spagify pulled from its title, SKU and description, grouped by buyer intent. Those terms steer each search to the right campaign in your Priority Funnel — a model number to Product Specific, a brand name to Brand — and they have always done that on their own.

The card did not say so. Every row wore a grey SUGGESTED badge next to an Approve button, and each tier had an "Approve tier" button, which made it look like a review queue with thousands of items waiting on you. Approving changed nothing: the routing read the terms either way. One store had 32,000 rows in that state.

The badge and the approve buttons are gone. The card now says plainly that nothing needs your approval. The two actions that do something remain: Block turns a term into a negative keyword, and Remove discards a term that does not belong to the product and teaches Spagify not to suggest it on similar ones. A term already headed to Google as a negative is marked Negative.

One thing that quietly depended on that approval is fixed with it. When shoppers spell a brand as two words — "z line" for ZLINE, "kitchen aid" for KitchenAid — and a search spelled that way converts, Spagify learns the spelling and routes it like the brand. It used to hold each spelling back until someone approved it, and nobody ever did, so none of them routed. A spelling is now trusted on the evidence alone when both words join into a brand you carry, the search converted, and neither word is a common word such as "for" or "best" — that last rule is what stops "for all" becoming a phrase negative across your Generic campaign.

Every product used to carry its own Autopilot on / Autopilot off badge, and it read "off" unless someone had opened that product and clicked a button. Nothing else ever switched it on — not launching a campaign, not connecting Google Ads, not finishing setup — so a store whose automation was running could still see "Autopilot off" on every product in its catalogue, and the getting-started checklist could never tick Run Autopilot.

Autopilot is now the account-level setting it always appeared to be, the one in Settings → Automation. A product's badge tells you what is actually happening to it: on, reviewing changes before they go live, off because the whole account is set to watch only, or held out by you. The button in the product drawer holds one product out of autopilot and puts it back.

Two things start working as a result. Products now move through Testing → Scaling → Failed on their own performance, and any rules you have written apply to your catalogue instead of quietly matching nothing.

What your plan counts has changed to match. An advertised item ID is now a product with a live ad group — what you are actually running ads for — rather than a product someone had clicked that button on. Your usage figure on the overview may move as a result; the included amounts and prices are unchanged.

Open any product and there is a Search terms tab. It lists the searches that actually put that product into a Shopping auction — impressions, clicks, spend, cost per click and conversions for each one, with a row per funnel campaign so you can see a query arriving through Generic at one price and through Product Specific at another.

Until now the only way to ask "what were people searching when they saw this product?" was the account-wide Search terms page, where one product's queries sit among every other product's.

It is the same table as that page: the waste and intent badges, the filters, the sorting and the paging all behave identically, and the waste threshold still follows your store's profile. Choose a window of 7, 14, 30 or 90 days. A product shows nothing here until its ads are live and Google has reported the first queries against them.

Your funnel's three campaigns share one daily budget, so when it runs out they all stop together. Until now only the Generic campaign was adjusted through the day, which meant a quiet morning left high-intent clicks unbought and a busy afternoon could empty the budget before evening.

All three campaigns are now paced hourly, up as well as down. Brand and Product Specific still get their real bid once a day from each product's own fourteen days — what a click on that product is worth does not change hourly — and the hourly pass only nudges within twenty percent either side of it, never breaking the order that keeps Generic cheapest and Product Specific dearest.

A sudden jump in click prices is treated as what it usually is. When a click starts costing far more than that campaign normally pays, it is rarely new demand; more often another advertiser has set their budget badly and is overpaying until it runs out. Chasing them buys their mistake. Spagify now compares today's cost per click with that campaign's own recent history and eases off the raise, by more the bigger the jump and by more again the less of the day's budget you have left. It never stops you competing altogether, and it never holds a bid up during a spike.

Nothing is adjusted on campaigns using Smart Bidding. If a campaign has graduated to Maximize Conversion Value or Target ROAS, Google sets the bid per auction and a manual bid does nothing, so Spagify leaves it alone rather than writing changes with no effect.

The Generic campaign in a Priority Funnel is there to answer broad searches cheaply, so they are not answered by your Brand and Product Specific campaigns at three to ten times the bid. Those two are where your budget is meant to go.

It was not behaving that way. On a quiet day the hourly pass walked the Generic bid all the way up to its full planned bid, using Google's simulator to take the biggest step that still fit the day's Generic allowance — which is buying traffic, not answering it. Then, because Generic was most of a small day's spend, the same pass cut it back to its floor. One funnel went from $0.52 to $0.04 in five hours over $0.65 of spend against a $10 budget, after climbing to the top overnight and taking every click of the day.

Now the Generic bid sits around the middle of its range: between the learning floor you set and the planned bid, so ads still show and broad searches still get caught, without chasing volume. A bid left above the middle settles there on the next hourly pass. Your Generic campaign's own share of spend only pulls the bid down once it has actually spent a meaningful part of the day's plan — a single click at 4am no longer reads as a runaway. Your total budget is paced exactly as before, and an exhausted budget still pulls bids down at any hour.

Nothing changes for Brand and Product Specific, which are still set once a day from each product's own numbers.

There is a lifebuoy button in the top bar now, next to the notifications bell. It opens a short form for anything you need: something wrong with your ads, a page of Spagify that is broken, a feature you wish existed, or a question about billing. You pick the one that sounds like your problem in plain words — there is no queue to choose, no priority to set, no ticket type to guess at.

When you report something broken, the form attaches what we would otherwise have to ask you for: the page you were on, which build you are running, and the last few errors the page hit. What is included with this report lists every item before you send it. Passwords, card details and access tokens are never collected, and web addresses are stored without their query strings.

If a page does crash, the error screen now has a Tell us what happened button that opens the same form already knowing the page and the error's reference.

You get an email with a reference number, and replying to that email adds to the same request. What you type is kept if you close the form by accident or the page reloads — clicking outside it does not close it, and neither does Escape.

Connect with Custom App now opens a panel down the side of the page with every value you have to enter in Shopify — app name, the scope list, App URL, webhooks API version — each next to a copy button, and links straight to your Shopify admin and the Dev Dashboard. The scope list is the one that mattered: retyped by hand, a single wrong character only surfaces at the end, as a Shopify error about a missing scope.

The store domain field now takes whatever you have to hand. Paste the whole admin URL, the domain with https:// on the front, or just your store handle, and it becomes the .myshopify.com domain when you click away. A custom storefront domain is left alone rather than guessed at, because guessing it wrong would connect you to somebody else's store.

Clicking outside the panel no longer closes it and takes your half-filled form with it, and neither does Escape. Cancel and the X ask first once you have entered anything. Same for the legacy custom-app form.

Everything between a Shopify store and a running Shopping funnel, in one place: a video walkthrough with chapters, each of the seven steps written out, and a link to every Shopify and Google page you have to visit along the way — the Google & YouTube channel, Merchant Center, the Shopify Dev Dashboard, Google Ads conversions.

It also covers the parts the setup wizard cannot do for you: getting your products into Merchant Center before Google Ads can serve them, why to decline the Performance Max campaign Google offers on the way through, and how to check that conversion tracking is actually recording. Read it at spagify.com/docs/getting-started; it is linked from your welcome email and from the setup wizard.

Spagify reads your paid orders to attribute Google Ads clicks to real revenue. On stores with more than a page of paid orders in the look-back window, the sync re-read the same first page instead of moving on, so older orders never arrived and conversions uploaded to Google Ads were short. It now pages through the whole window.

When Spagify adds new products to a running Priority Funnel, the funnel's Query Protection is regenerated for everything it now contains: each original ad group gets the negatives that keep the newcomers' model numbers out of it, and each newcomer gets the same protection against the originals. Until now Query Protection was fixed at launch, so products added later competed with their siblings for the same searches.

A product you discontinue in Shopify also leaves the funnel's routing. Its model numbers are no longer blocked from the Generic and Brand campaigns, so a search for it can still reach a similar product instead of going nowhere.

The Funnel tier out of budget alert used Google's trailing seven-day figure, which kept reporting a budget shortfall for days after the funnel's shared budget had fixed it. It now judges only the days since Spagify last repaired the funnel's budget and bids, day by day, and says which days it looked at. Days with too few impressions for Google to report a share are not counted, and a window with none raises nothing.

One alert per funnel tier now stays current while the shortfall lasts and closes on its own when the share is back under 10%, instead of a new copy every day. The alert also describes what the bid controller does in both directions: it steps the Generic bid down while the funnel runs ahead of its planned spend for the hour, and back up toward the plan bid while it runs well behind.

The Campaigns page counted one product per campaign however many were in it, and filtering a product list by campaign returned only that one product. Both now count every product with a live ad group in the campaign — a five-product Priority Funnel reads as five, not one.

Starter, Growth and Scale can now be billed yearly: $990, $2,990 and $7,990 a year, the same as ten months at the monthly price. Pick monthly or yearly on the pricing page or when you start your trial. Already subscribed? Settings → Billing has a "Switch to yearly" button; the year starts the day you switch and the unused part of your current month is credited.

Starter accounts now get the same engines as Growth and Scale: the funnel bid controller, funnel integrity repairs, the stock and disapproval guards, network pruning and the Performance Max guard all act on their own, and low- and medium-risk negative keywords are approved and pushed every tick.

Review-first mode is still one switch away in Settings → Automation if you want every change held for your approval.

Every Monday morning in your ad account's time zone: the week's spend, revenue and ROAS against the week before, what Spagify changed, the negatives it pushed, the warnings still open, and what is waiting for your decision. Switch it on under Settings → Notifications. Growth and above.

The Keyword Intelligence add-on is retired: search-term mining, the AI intent read and the exclusion seed run for every workspace. Competitor price reads (the Pricing tab's storefront and marketplace prices) are now the Price Intelligence add-on on Starter and Growth and included on Scale. Each plan carries a monthly allowance of AI-read search terms, shown under Settings → Keyword Intelligence.

The Pricing tab on every product shows Google's price benchmark for the same item, a market price composed from competitor storefronts with a confidence score, and the competitors it found. Two alerts come with it: Price above market (losing the click to the price) and Price below market (margin left on the table). Spagify never changes a price.

From early afternoon in your ad account's time zone, Spagify compares today's impressions with the two previous days. A product that served on both and has nothing today raises one Serving stopped alert with the likely causes, and closes it on its own when impressions return.

When a disapproved offer's product page answers again, Spagify asks Google to re-review it. Where Google will not accept the request from Spagify yet, you get one Review needed item per product with the exact issue and the button to press in Merchant Center. While an advertised offer is disapproved, its status is re-read every hour instead of once a day, and the disapproval alert now stays open per product and closes itself on approval.

Settings → Notifications lists every kind of message Spagify can send, with a switch per person for email and, for owners and admins, per workspace for Slack. Nothing is sent until it is switched on. Every alert now carries an explanation: what it means, the likely causes, what fixes it and what Spagify already did on its own, in the app and in the email. Emails share one layout with one button and a footer that says how to change what you receive.

A new tab under Products shows where impressions are lost to rank, Google's bid simulator curve where one exists, and the search terms where you rarely reach the top of the page. The funnel bid controller uses the same simulator to size its steps.

Ninety days of search terms broken into single words and two-word phrases, each with what it cost and what it returned, so the leak shows up as a word rather than a thousand queries. Block a phrase in one click. Separately, terms shown hundreds of times that are rarely clicked and never convert are proposed as negatives on their own.

Search partners and display expansion that earn under half of what Google Search earns are switched off per campaign (an alert instead, on review-first accounts). Products with live Spagify ads are excluded from your Performance Max asset groups so the two never bid against each other.

Negatives found on your existing campaigns that protect products with no live ads are marked Not advertised and left alone until those products serve. Anything Spagify applied from a campaign that stopped serving is withdrawn again. Non-Shopping campaigns are labelled in the Existing setup tab, and your feed label is carried into new builds.

The Campaigns page can remove one of your own pre-Spagify campaigns from Google Ads, with a confirmation that names it.

With the write_content permission granted, a renamed product handle gets a redirect from the old URL automatically, so Merchant Center never sees a dead landing page. The public Permissions page lists every Shopify and Google permission Spagify asks for and what each is used for.

The tier bid controller now waits for conversion lag before it calls a product wasteful, and steps value bids on mature data only, so a slow-converting product is not cut the day after it spends.

Connect an account with existing Shopping campaigns and Spagify reads the structure: campaigns, ad groups, listing groups and every negative keyword. Each negative is classified (catalog first, AI for the rest) and judged against the products it protects. The Existing setup tab shows what was found, and the launch flow pre-fills from it. Refreshed daily.

Generic-tier bids step hourly against the account clock; Brand and Product Specific bids move daily per product. An integrity pass keeps the shared budget consolidated and first-touch bids aligned, and raises an eligibility alert when bids cannot fix a broken funnel. A daily digest per funnel lists every bid moved and why.

Every search term gets a tier fit. Spend that landed in the wrong tier is booked per funnel per day with its cause, and a Funnel leak alert fires when the leak is material. Insights → Funnel integrity shows the leaks and the biggest offenders.

One strategy picker across launch and campaign settings, and it only lists what the campaign can take today: Target ROAS appears once the conversion volume qualifies; Enhanced CPC is gone.

Every negative you approve or reject becomes an outcome label; a small holdout keeps the system honest. A Learning card in Settings and a Learning section under Insights show what the classifier has learned and how it scores in shadow before anything changes.

Every "last N days" report uses the same trailing window, and each day is labelled as the day it names in the ad account's time zone rather than your browser's. The Campaigns table shows shared and budget-limited pills next to the daily budget.

An ad group whose product Merchant Center disapproved is paused, and enabled again when the offer is approved, so no budget is spent on ads that cannot show. Switch it per campaign in campaign settings.

Auto-approve is on by default: only HIGH-risk candidates and policy blocks wait for a person. Every tick approves and pushes what is safe on an existing plan too, and the Search terms page shows when a term already has a live negative and asks before pushing a new one.

Accounts are classified HIGH_TICKET, STANDARD or HIGH_VOLUME from their price points and volume, and the spend and click thresholds behind waste blocks scale with the profile, so a $2,000 appliance is not judged like a $20 gadget.

The Insights tab under Negative keywords now reads in Shopping terms: live negatives by kind, spend blocked in the window, the review queue, and what the AI reads cost.

One account-level list holds the baseline; brands you don't carry go to a campaign-level list; live placements follow the plan they belong to; counts are honest; rollback runs in the background and never races a delete. A live funnel that lost its routing plan gets it rebuilt every tick.

The three tiers of a funnel now share one Google budget instead of a 20/30/50 split, product partitions inherit their tier's bid, and the Generic bid steps to keep headroom below the daily cap. Bids and the budget are verified after every publish. Campaigns are named by what they sell and their tier ("Napa Technology - Brand"), not a random suffix.

New products that match a live funnel are added to it automatically on Growth and above (drafted for approval on review-first accounts). The launch preflight warns about products already live in another Spagify campaign and lets you keep or drop each one.

Every live funnel gets its Query Protection plan generated automatically: baseline exclusions, brands you don't carry and sibling isolation, with the AI exclusion seed running after launch, then daily, then weekly.

Spagify resolves each product's real Merchant Center offer ID once a day and reads its status: disapprovals, ineligibility, price and availability mismatches, with the issue text Google shows. Item-level alerts replace guessing from the ads side.

The out-of-stock pause and resume switches on a campaign now do what they say: an ad group is paused when its product runs out and resumed when inventory returns.

Budget, priority, bidding, spend, conversions, revenue and ROAS per campaign over the window you pick, with campaign and ad-group negatives in a drawer.

The sidebar is reorganised into hubs with routed tabs, Settings lives in the sidebar and is split into pages, and every app page shares one header and one date-range control. Search terms gets word-order search, filters, sortable columns and CSV export.

A recurring warning while a Performance Max campaign runs alongside Spagify funnels, because PMax takes the auction first and starves Standard Shopping.

Each bid, budget, negative, pause and structural change Spagify makes is logged with the value before, the value after, the reason and who or what made it. The product page shows its own history; records older than 90 days are archived, not deleted.

Each clicked query is read against the product that served it and labelled: on intent, another product you carry, a brand you don't carry, an accessory or part, informational, wrong audience. Off-intent terms become proposals in your plan. The AI never pushes a negative on its own.

From your catalog's categories, the AI proposes the competitor manufacturers and the category-specific off-intent terms to exclude before the first click is wasted. Every proposal is reviewed in a plan.

Setup and data items you have to finish yourself (missing unit costs, a store detail to fix) live in the Inbox next to the automation's proposals. Every product list shares one scope control, and each product shows the campaigns it is live in.

Held automation runs, budget moves, proposed splits, finished experiments, alerts, stale negatives and setup items, each with why and the expected effect, and approve or dismiss on the row. A badge in the sidebar counts what waits.

Products move from Testing to Scaling on real ROAS and conversions over a seven-day window, and back or to Paused when they stop earning. The capital tier drives the tier-bid runs. The Autopilot page shows the engine's actual decisions and the policy behind them.

Profit is revenue minus ad spend minus unit cost times orders, everywhere. Break-even ROAS per product, and a prompt listing the products with no unit cost so the number is never silently wrong.

Six pieces landed together:

• match types and defaults per purpose, ambiguous brands handled, a merchant global exclusion list
• model and brand aliases, so "MX4Q3HD" and "mx4 q3hd" route the same way
• product-line and other-brand isolation between your own products
• catalog-change triggers: negatives retire when the product they protected leaves
• brands you don't carry, with a list you can edit
• routing negatives delivered as shared lists

Negatives added from Search terms, the Campaigns tree, keyword lists or the product page are conflict-checked (your own brand, a product's title tokens) and tracked like every other placement, so nothing can quietly block your own products.

A build that would put a product into a second live Spagify campaign is refused, Google's campaign status is mirrored into the app, and every product shows Live or Not in campaign. The products table pages at 50 rows per lifecycle group and returns the whole catalog.

The app works on a phone, the product modal is tabbed with long lists paged, and the signup flow no longer dead-ends: logged-out pricing buttons carry the plan into signup, every page has its own title, and onboarding resumes where you left it.

Products Merchant Center does not carry are skipped at launch and listed, the real offer IDs are resolved from Merchant Center instead of guessed, and a warning appears when Performance Max is active on the account.

Performance blocks and pooled n-grams mined from search terms arrive as candidates in a plan, mined daily. Routing considers sibling variant option values, never negatives your own store name, and repairs keyword text Google Ads refuses.

Pick Starter, Growth or Scale on the pricing page or during onboarding; checkout carries the choice through. Google Ads connection failures now show Google's own message instead of "no accounts".

Checkout errors are shown instead of failing silently, the onboarding retry loop after checkout is gone, and subscription period ends are read correctly.

A full-application audit: tenant isolation hardened on every endpoint, retries with backoff on the Shopify client, offline conversion partial failures no longer lost, budget reallocation made spend-neutral, and the rule engine's idempotency gap closed. Password reset and invite flows fixed; a Brands page in the sidebar.

One card for automation: on or off, review-first or automatic, a hard daily spend ceiling, and the objective the budget bandit optimises for (revenue or profit). Alerts when an automated action fails. A subscription is required app-wide once the trial ends.

Each account has an autonomy level (observe, recommend, low-risk automatic, structural). Campaigns move from manual CPC to Target ROAS when Google would accept it. A weekly budget bandit reallocates across funnels under your spend ceiling. Structural evaluation proposes splits and runs them as canary experiments before promoting or ending them. Out-of-stock and disapproved products are excluded from all of it. Cross-brand negatives keep one brand's ads from serving another's queries.

One launch can build a full priority funnel per brand or per category, with routing scoped to each set's own products. The campaign-name prefix is optional and the date is opt-in.

Search-term reporting corrected, funnel campaign construction corrected, a Priority Funnel routing service that moves brand and SKU queries down the waterfall, tier-aware search-term mining, and the unsafe automatic paths removed.

A rebuilt product modal, and a preview of what an Autopilot run would change before it changes anything.

Compliance webhooks, the customer-managed custom-app connection with short-lived tokens, and the Shopify onboarding guide.

Terms, privacy policy and a plain statement of what Spagify does and never does with Google Ads access, in preparation for Google's verification.

Keyword lists, workspace keyword memory, and the first search-term mining, with the plan gate that keeps it on the right plans.

Waitlist signups receive an early-access code; workspaces that used one keep beta status while their subscription stays active.

The first complete product: Shopify sync, Google Ads connection, one-product-per-ad-group Shopping campaigns built, published and activated from the catalog, a rule engine with templates and dry-run testing, alerts, keyword lists, quality-score monitoring, team invites, a 21-day trial with Stripe billing, and a demo workspace.

A REALLOCATE_BUDGET action, a per-condition trace on every automation run so you can see why a rule fired, four data-driven rule suggestions from your own metrics, 90-day LTV as a rule condition, and soft limits on rules and item IDs per plan.

Product, inventory and order webhooks keep the catalog current in real time; Shopify orders are uploaded to Google Ads as offline conversions; ad disapprovals are monitored; feed guardrails and LTV land in the product view. Audience targeting and RLSA for the accounts that use them.