What Is Qinetix? How Trellis' Bid and Pricing Execution Works

Your efficiency target may no longer clear margin

If you run marketplace ads for a brand, two costs have moved against you at the same time, and most operating targets have not caught up with either.

Every click costs more than it used to, because most sellers in a category now bid on the same finite placements. Every unit shipped keeps less, because fees and surcharges take their cut before your efficiency target ever sees the money. Neither trend is dramatic inside a single quarter. Compounded over two years, together they decide whether a campaign that hits its ACoS target is still making you anything.

The two levers that answer that question, what you bid and what you charge, usually sit in different systems, run on different cadences, and get reconciled once a week by a person with a spreadsheet open. Meanwhile one account-wide optimization setting is running a launch SKU and a mature hero SKU the same way, because changing it per campaign is tedious and the tedium always loses to the next fire.

Qinetix is Trellis' execution engine, and it exists to close that gap: to keep bids and prices moving inside limits you set, continuously, so the account does what you decided rather than what somebody had time for. What follows is how the three mechanisms work, what you have to set yourself, and where the system stops.

Quick answer

• What it is. Trellis' execution engine: the system that changes bids, prices, and reach in a live account, continuously, inside limits you set.
• Ads automation. Optimization logic selected per campaign rather than per account, a rules engine running alongside it, and bidding zones with a floor and a ceiling. Guardrails: a learning phase, down-only defaults, a change log on every move, and a simulator for testing a change before it ships.
• Dynamic pricing. A repricing mechanism that moves your listing price inside a band you define, reading demand, margin and inventory cover alongside competitor price rather than tracking a competitor alone.
• DSP. Reach beyond the search auction, for when head-term CPCs stop being worth the marginal click.
• How the two relate. Ads and pricing are parallel mechanisms sharing account visibility, never one coordinating algorithm issuing instructions to both. You keep both sets of settings.
• What you get out of it. Bids and prices that respond to inventory cover and margin every hour the account is live, and a change log that answers "why did this move" with a rule name instead of a shrug.
• What it asks of you. An optimization logic per campaign and a price band per SKU. Qinetix is a poor fit if what you want is one target field and no further involvement.

Who Qinetix is for

Two readers get the most out of it.

The first is the agency paid media lead who needs control and a record. You are managing a roster where each brand has a different tolerance for aggression, and you have to walk into a monthly review and show what changed, why, and what it did. A system that quietly routes to a target does not survive that meeting.

The second is the head of ecommerce who is tired of being the integration layer. Ads are in one console, price is in another, inventory is in a third, and the connective judgment ("cool the bids on this SKU, we are three weeks from stocking out") happens in your head, on the days you have time. Nothing in the stack talks to anything else, so you are the wire between them.

How Qinetix works

Ads automation: selectable logic, a rules engine, and a hard ceiling

The core idea in ads automation is that a launch SKU, a mature hero SKU, and a margin-protection SKU are three different jobs, so they get three different optimization behaviours rather than one account-wide setting. The mechanism has six moving parts:

1. You select the optimization logic per campaign. Not per account. A campaign pushing a launch toward rank gets different behaviour than one defending a hero SKU's efficiency.
2. A rules engine runs in parallel with the logic you selected. This is where account-specific conditions live: dayparting, inventory conditions, pausing on a lost Buy Box, harvesting rules. Rules run alongside optimization rather than fighting it, which is why campaign rules are worth writing down properly rather than treating as exceptions.
3. Bidding zones set a floor and a ceiling. Every bid moves inside a band you define, so the worst case is bounded. This is the guardrail that matters most on high-CPC terms, where an unbounded automated increase is the expensive failure mode.
4. Guardrails hold the early days. A learning phase keeps the system from over-reacting to thin data, and down-only defaults mean the first automated moves on a new campaign can reduce exposure but not add it.
5. Every change lands in a log. Which bid moved, when, by how much, and under which rule or logic. This is the record you take into the client review.
6. A simulator tests before deployment. You can run a proposed rule or optimization change against the account before it touches a live bid, which is the difference between a hypothesis and an experiment.

None of that is exotic. What it adds up to is an account where you can answer the question "why did this bid move" with a specific rule name instead of a shrug.

Dynamic pricing: repricing inside a band you define

Dynamic pricing in Qinetix is its own mechanism with its own inputs. It reprices your listings, and the inputs are broader than a competitor tracker: demand, margin, and inventory cover sit alongside competitor price, so a move responds to your own economics rather than reflexively matching somebody else's discount.

You set the thresholds: minimum price, maximum price, the posture you want, and the conditions that trigger movement. Inventory cover is one of the most useful of those conditions. When cover on a SKU drops below the level you named, the price can move to slow sell-through ahead of a restock, and when cover is heavy it can move the other way to clear.

The limit worth being precise about is the box rather than the mechanism. The system does not decide what your floor should be, and it has no view on what your brand is worth. You define the band, the mechanism reprices inside it, and every move is visible. Operators who have never tested their floor usually have the most to gain here, and testing it is still their call.

DSP: reach beyond the search auction

DSP extends reach past the search results page, which matters when the searches you want are already saturated and the marginal CPC on your head terms has stopped being worth it. Treat off-marketplace demand creation as demand creation. It builds audiences and awareness; it does not hand you a closed attribution loop back to a specific order, and any vendor claiming otherwise is selling you a model rather than a measurement.

Ads and pricing are parallel mechanisms with shared visibility

The assumption most prospects arrive with is that a platform running both ads and price must have one model coordinating them: the bid engine learns something, tells the pricing engine, and the two move together. That is not how this works, and the real answer is more useful.

Dynamic pricing runs on the thresholds you set. Ads automation runs on the optimization logic you selected per campaign plus the rules you layered on top. Neither mechanism issues instructions to the other. What they share is the account data underneath: the same inventory position, the same sell-through, the same performance history, the same fee and margin picture.

That sounds like a smaller claim than "one algorithm handles it," and it is the one worth having. A single coordinating model would move your price as a downstream consequence of a bid decision you never reviewed, and the first time it surprised you, there would be nothing to inspect. Shared visibility gets you the coordination you were doing by hand (a pricing threshold and an ads rule that reference the same inventory signal) without either mechanism overriding a decision you made. You stop being the wire between the two systems. You still own both settings.

Where Qore comes in

Qinetix executes continuously against conditions you set once. Qore is the layer where those conditions, and every other review you run by hand, get written down as inspectable logic: you describe the workflow, it runs on a schedule, and the actions it proposes start gated on your approval.

That gate is a setting you tune rather than a permanent state. Once you have watched a workflow make the same call correctly over several runs, you tighten its rules until the routine cases are ones you would have approved anyway, then let it apply those on its own and escalate only the judgment calls. Qore can read, analyze, and make an approved change on any account regardless of what runs the bids. What Qinetix adds underneath is the continuous, always-on execution. Qore is in open beta, and the full Qore explainer covers it properly; it appears here because the table below puts the layers side by side.

Where each layer sits

What Qinetix does not do

Four limits worth knowing before a demo rather than after one.

It does not remove the setup judgment. Choosing an optimization logic for each campaign, drawing the bidding zones, and writing the rules is work only someone who knows the catalog can do. What automation removes is the daily re-execution of those decisions, not the decisions.

Visibility explains what changed. It does not prove the change was right. A change log and a simulator shorten the diagnosis from days to minutes. They will not tell you whether cutting bids on that SKU was the correct call, and a system that claims it will is flattering you.

Dynamic pricing does not set your price floor. It enforces the one you gave it. If the floor is wrong, the mechanism will hold it accurately all quarter.

Seeing a margin leak is not closing it. Fee changes, surcharges, and cover-driven price moves become visible in one place, which is a genuine improvement over three consoles. Acting on them is still an operator decision with a tradeoff attached.

A worked example: three weeks of cover before a restock

Here is a pattern we see often enough that it may as well be a template.

A SKU is performing. Bids are healthy, conversion is fine, and inventory cover has quietly dropped to about three weeks with a restock further out than that. The correct move is to cool demand slightly so the SKU does not go dark before the container lands, because running out of stock costs rank and rank costs more than the units. In a manual account this happens when someone notices, which in practice means when someone happens to open the inventory report on a Tuesday.

Handled by hand, it looks like this: a CSM pulls cover, finds the SKUs under threshold, and cuts bids on each one to manage sell-through ahead of the restock. That intervention is correct and it is also exactly the kind of thing that gets missed in a week with three other fires.

Handled through the mechanisms, it splits in two. On the ads side, a rule keyed to inventory cover cools bids on any SKU that crosses your threshold, and logs each change with the rule that caused it. On the pricing side, an inventory cover threshold can hold or lift price inside the band you set, slowing sell-through in a way that protects margin rather than only spending less. The two are not talking to each other. They are both reading the same cover number, and you decided in advance what each should do about it.

The pricing half of that has a second-order payoff worth naming. In one account we worked, a pricing adjustment had caused a real profit loss, and switching pricing posture for a couple of weeks recovered it. In the same account, an earlier increase to the minimum price had raised average selling price with no volume drop at all, which means the elasticity was sitting there unused the whole time. Neither of those is a system decision. Both are decisions the system will execute consistently once made, which is the part that is hard to do by hand across a catalog.

How Qinetix fits with Qore and AMC

This is the distinction that gets muddled in demos, so plainly:

• Qore holds your standard and decides what should happen. You describe the review you do by hand, it becomes inspectable logic, and it runs on a schedule with actions gated on approval until you decide otherwise. Same inputs, same output. Read the full Qore explainer if that is the layer you are evaluating.
• Qinetix carries it out. Bids, prices inside your band, and reach beyond search. The hands, not the judgment.
• AMC widens the evidence those decisions run on: path-level analysis and audience construction from Amazon's clean room, applied to campaigns rather than parked in a report. A paid add-on, and advanced.

One commercial note, since it changes how the execution layer behaves over time: Qinetix is billed as a flat fee set at onboarding to the account's scale rather than as a percentage of ad spend, so the fee does not climb as spend grows. An execution layer whose vendor earns more every time it bids higher is an execution layer with an opinion you did not ask for.

Set the guardrails, then let the mechanisms run

Qinetix is the execution half of Trellis: ads automation, dynamic pricing, and DSP, with Qore deciding upstream of it and AMC deepening the evidence underneath. The design choice that defines it is that ads and pricing stay parallel mechanisms with shared visibility, so you get the cross-system coordination you were doing manually without handing a single model authority over both your bids and your prices.

If you are evaluating it, the useful first question is whether you are willing to write down two conditions you would defend in a review: the optimization logic each type of campaign should run, and the price band each SKU should live in. If you can name those, the execution layer earns its keep from week one. If you cannot yet, start with Qore and get the standard written down first.

The bottom line for ecommerce teams

• Recheck your efficiency target against current margin. Rising CPCs and rising fees compound quietly, and a target set two years ago may no longer clear.
• Stop running one optimization setting account-wide. A launch SKU and a mature hero SKU are different jobs and should not share behaviour.
• Set a bid floor and ceiling before you automate anything. An unbounded automated increase on a high-CPC term is the expensive failure mode.
• Tie both levers to inventory cover. A bid rule and a price threshold reading the same cover number is the coordination you are currently doing in your head.
• Test your price floor. Operators who have never moved theirs often find elasticity sitting unused, and no system will find it for you.
• In a demo, ask to see the simulator and the change log. Those two screens tell you more about whether a system survives your monthly review than any performance slide.