Skip to main content
    Pulsar / bidding engine / SP, SB, SD

    You set the ceiling. Pulsar maximises everything under it.

    Tell Pulsar what a product family may spend, a maximum ACOS or TACOS, and what to maximise: revenue, units or profit. The target is a hard ceiling, never a number to drift toward. Every bid is computed from what a click is actually worth, and every increase in spend has to prove it bought sales.

    Where it runs
    Inside the SYNQ App, on the accounts we manage. Every scope runs in shadow mode before a single live write.
    The decision, in one line
    bid = λ × ceiling × value per click
    λ
    One pacing dial per scope
    Over the ceiling it turns every bid in the scope down at once. Under it, and only if the last raise proved itself, it may turn up.
    ceiling
    Your max ACOS or TACOS
    A hard constraint, not a setpoint. Pulsar will happily run far below it when extra spend buys nothing.
    VPC
    Value of one click
    The sales a single click is expected to generate, borrowed from the levels above it until the entity has earned its own number.
    Objectives: revenue, units, profitConstraint: max ACOS or max TACOSScope: parent ASIN, child ASIN or product groupAd types: SP, SB, SD
    How it works

    Four properties that decide whether a bidder is safe to leave running.

    Most tools get the arithmetic right and the guardrails wrong. The interesting part is what happens on the bad days: an out of stock week, a lost Buy Box, a raise that bought nothing.

    01
    It knows what a click is worth
    Every keyword and product target carries a live estimate of the sales one click generates. Thin entities inherit their estimate from the ad group, campaign and product family above them, so no decision is ever made on eight clicks and one lucky order.
    02
    One dial per product family, not per keyword firefighting
    The whole scope moves together toward the constraint, and budget flows to the most valuable clicks on its own. The ceiling binds where you set it, so a loss-leader child can deliberately run hot while the family holds.
    03
    Market aware, never market blind
    Stock, Buy Box and delivery health feed the estimator. Days when nothing was buyable are masked out of the learning data, so an out of stock week never reads as "this keyword stopped converting". A hero variant going out of stock lowers value estimates gradually instead of tripping a rule.
    04
    Every raise has to prove itself
    Spending more is an experiment, not a right. After each increase Pulsar checks whether sales actually followed at a marginal cost inside the ceiling. If they did not, the raise is taken back. Cuts are automatic, raises are earned.
    Under the hood
    Value per click, borrowed until earned
    VPC(node) = ( value(node) + m × VPC(parent) )
                  ÷ ( clicks(node) + m )

    Estimates are shrunk up the chain: entity, ad group, campaign, scope. A dense keyword with a thousand clicks keeps its own number. A sparse one rides its lineage until it has earned one. No click threshold cliff, no do-nothing zone.

    1,000 clicksown data
    8 clicksmostly inherited
    prior strength m = 20 equivalent clicks · recency half-life 14d
    The marginal response gate
    marginal ACOS = Δspend rate ÷ Δsales rate
    (3d after the raise vs 3d before)

    A raise matures only after the attribution lag has passed, and a second raise cannot start while one is still immature. If the extra spend bought sales above the ceiling, or bought nothing at all, the raise fails and the dial holds or reverts.

    This gate is the institutional memory of one specific failure: paying 59% more per click for zero additional clicks, while every dashboard still said "under target".
    Two loops, asymmetric on purpose
    Fast loopACOS
    Trailing scope ACOS above the ceiling steps the dial down for every bid at once. The portfolio moves as one instead of per keyword.
    Slow loopTACOS
    Where the retail feed exists, trailing TACOS above its ceiling forces the dial down regardless of ACOS. It only ever pushes down, which makes it immune to attribution games.
    Attribution, per ad type
    SPSame product attribution, valued at entity level.
    SBValued at full halo credit, allocated to keywords by click share. Judging brand campaigns on same SKU sales strangles top of funnel. The TACOS loop keeps the credit honest.
    SDClick attributed sales only. View-through is logged and carries no bid value until it survives a holdout.
    Safety

    Safe by construction, not by supervision.

    Four properties, no exceptions
    Time budgeted moves
    Bids travel a bounded distance per week, not per run. A missed run donates its authority to the next, and a rerun on the same day has zero elapsed time, so it changes nothing. Duplicate runs are harmless by arithmetic rather than by lock.
    bids ≤ 35% / week · dial ≤ 15% / week
    Serve floors
    Below a certain bid an entity stops winning auctions, data freezes, and a naive controller keeps cutting on stale evidence forever. Cuts are floored, and anything found below its floor is lifted back to visibility in one step. A bid that cannot buy data cannot be controlled.
    floor = 60% of realised CPC
    Shadow mode first
    Every scope runs the full computation with zero writes before it goes live, and live rollouts start with tightened bounds. Shadow and live share one code path, so what you review is what will execute.
    Fail closed and audited
    Any error aborts the run before a single API write. There is no fallback controller and no partial push. Every change is logged with its before and after values.
    Standing rule
    No campaign, ad or product ad is ever paused or enabled from inventory data. Amazon already halts ineligible delivery itself, and acting on imperfect stock data cuts real sales. Pulsar changes bids. That is all it changes.
    What comes nextIn progress

    Learned step sizes, from our own bid history.

    Every bid is snapshotted daily and every pushed change is logged with its before and after values. That is a growing record of bid to outcome, on real accounts, which is the dataset a bidding model actually needs.

    A small, logged share of entities receives bounded random perturbations, which supplies the causal variation that observational data cannot. The first learned model is bid elasticity, impressions gained per unit of bid, per campaign cluster. It replaces fixed step caps with moves sized to the expected response, still hard capped.

    Language models supervise and explain. They are not in the decision loop, and they will not be.

    Shipped
    Daily bid snapshots and change log
    Every decision reproducible after the fact.
    Shipped
    Bounded exploration jitter
    Small, logged, ≤10% perturbations on a slice of entities.
    Building
    Bid elasticity model per campaign cluster
    Expected response replaces fixed step caps.
    Next
    Profit mode on per SKU margins
    Falls back to revenue until margins exist, by design.

    See it run in shadow mode on your own account.

    We point Pulsar at your portfolio with writes disabled and walk you through what it would have changed and why, bid by bid. If the answers are not convincing, you have lost half an hour.