SkuLift vs Rankscale

SkuLift treats Share of Voice as a measurement discipline rather than a single percentage. The methodology is a four-level pyramid: presence (is the brand mentioned at all), prominence (where in the answer and how weighted), citation (is the brand a named source) and authority (the Citation Authority Score that captures how load-bearing the citation is). Each level is computed from the same per-query, per-engine measurements, so a headline number can always be decomposed back to the evidence that produced it.

The position-weighted count (PWC) formula is adapted from the GEO research published at KDD 2024: a mention near the top of an answer counts for more than one buried in a closing caveat, because that is how a reader — and an answer engine re-ranking its own output — actually weighs it. Every query is sampled N=5 times to smooth the stochastic variance that single-shot probes inherit, and queries are classified A/B/C by intent so that high-intent comparison prompts are never averaged together with low-intent informational ones.

The point of this depth is defensibility. When a marketing leader reports an AI-visibility number to a board, the next question is "how do you know". The pyramid, the PWC weighting, the N=5 sampling and the A/B/C split exist so that the answer is a method, not a vibe. A flat "share of voice" figure is easy to produce and hard to defend; a decomposed pyramid is harder to produce and easy to defend.

The Citation Authority Score at the top of the pyramid deserves its own note. Being mentioned is not the same as being cited, and being cited is not the same as being the load-bearing source an answer leans on. CAS captures that distinction with a confidence zone, so a brand can tell whether it is a passing reference or the reason the engine reached its conclusion. That granularity is what lets a content team prioritise: hardening a load-bearing citation is a different lift from earning a first mention, and the pyramid keeps the two from being conflated in a single headline figure.

You can verify the depth without taking it on faith. Ask any comparison tool to show how a headline visibility number decomposes, how it weights position, how many samples sit behind a single figure, and how it tells an informational query apart from a high-intent comparison query. SkuLift answers those with the pyramid, PWC, N=5 and the A/B/C split respectively. That is the test we would apply to ourselves, and the one we would encourage a buyer to apply to every vendor on a shortlist, including us.

Rankscale tracks mention, position, sentiment and citation source per answer, and adds an AI Readiness Score built from a deterministic page audit (publicly described as 90+ to 200+ checks). That on-page audit depth is a genuine Rankscale strength. A named four-level SOV pyramid with PWC weighting and N=5 sampling is not part of its public description, so we record "Not publicly documented".

SkuLift probes four engines natively — ChatGPT, Claude, Gemini and Perplexity — and, crucially, separates two regimes that are often collapsed into one. A parametric answer draws only on the model’s trained weights; a web-grounded answer is retrieved and cited from live sources. These behave differently for a brand: you can be strong in a model’s parametric memory yet invisible the moment it switches to retrieval, or vice versa. Measuring them as one number hides exactly the gap a content team needs to act on.

Each engine is reached through its own collection path. ChatGPT measurement runs through an anti-bot stack with rotating exits and per-session identity budgets, plus a separate logged-session mode. Claude is measured through the Anthropic API with workspace credentials. Gemini uses the Google AI surface. Perplexity uses a browser-driven flow. The collection complexity is industrialised so the brand consumes a clean, comparable number per engine rather than maintaining four bespoke scrapers.

Multi-engine posture is a deliberate product stance, not a feature checkbox. Recommendations are engine-agnostic: a gap surfaced on one engine can be answered by an article that is then re-measured across all four. The brand optimises for the conversational surface as a whole, not for whichever single engine a point tool happened to support first.

The parametric-versus-web-grounded split is the part most easily lost when coverage is reported as a single number. The same prompt can produce a confident, brand-favourable answer from a model’s trained memory and a very different answer once the model retrieves and cites live sources — or vice versa. Collapsing the two hides the lever a content team can actually pull: web-grounded gaps are usually addressable with fresh, citable content, whereas parametric gaps move on a slower horizon. SkuLift keeps the two regimes separate per engine so the recommended action matches the cause of the gap.

Engine count alone can also mislead, which is worth saying plainly since several competitors lead with it. A long list of engines measured shallowly tells you less than a focused set measured with a consistent methodology and the parametric/web-grounded distinction intact. SkuLift’s view is that the four engines it probes natively cover the surfaces where most B2B and D2C buyers actually research today, and that depth of measurement per engine beats breadth of engines counted. A buyer who genuinely needs the widest possible list is, fairly, better served elsewhere.

Engine breadth is a Rankscale strength: its public materials cite 17+ engines, accessible from the entry plan without engine-gating — a broader native list than SkuLift’s four. If your priority is the widest engine list at low entry cost, that breadth is a real advantage.

SkuLift implements three open agentic protocols: ACP (the Agentic Commerce Protocol used by ChatGPT), AP2 (the agent protocol in Google’s Gemini stack) and MCP (Anthropic’s Model Context Protocol). The thesis is that AI-engine visibility is the leading edge of agentic commerce: once answer engines begin transacting on a user’s behalf, being citable is necessary but no longer sufficient — the brand also needs to be reachable by the agent that acts.

In practice MCP is the most actively used of the three on the agent side; the orchestrator and its sub-agents expose tools and resources MCP-style. ACP and AP2 are supported at the wire-format level so that agent-to-agent interactions are not blocked by protocol incompatibility as the standards mature. This is forward integration, not a claim that every protocol is in heavy production use today.

Most platforms in this category position themselves as visibility monitors — they tell you where you stand. SkuLift adds the protocol layer so that the same brand context that powers measurement can also power agentic transactions when the engines support them. That is the meaning of "agentic-commerce-native" rather than "AEO dashboard".

It is worth being precise about maturity so the claim stays honest. Protocol support here means the wire formats are implemented and the brand context is exposed in a way those protocols can consume; it does not mean every protocol is in heavy production use across every engine today, because the engines themselves are still rolling these standards out. The value is positional: a brand that is already structured for ACP, AP2 and MCP does not have to re-platform when answer engines move from citing to transacting. SkuLift treats that as infrastructure to have in place early rather than a race to retrofit later.

This is also the axis where category labels matter. Tools that describe themselves as AEO or GEO platforms are, by their own framing, about visibility — being found and cited. The agentic-commerce framing is one step further out: it assumes the engines will increasingly act, not just answer, and that brands will need to be addressable by those actions. If that assumption is wrong for your market, the protocol layer is simply latent and costs you nothing; if it is right, having it already in place is the difference between leading and retrofitting. We flag this as a forward bet, stated as a bet.

A public implementation of the ACP/AP2/MCP agentic-commerce protocols is not documented for Rankscale at the time of writing; we therefore mark it "Not publicly documented" rather than absent.

The agentic loop is supervised, not autonomous-to-publication. A persisted orchestrator state machine includes an explicit human-gate state: no external action — no published article, no Shopify edit, no outbound integration call — executes without an owner or admin approving it on the Recommendations page. The role split (viewer / member / owner / admin) is enforced at the API layer, not just hidden in the UI.

Budget guardrails are enforced before each agent call: an approximate per-run envelope, a configurable daily cap per workspace, a turn cap and a timeout per orchestrator session. The aim is that autonomy scales the loop without ever scaling unsupervised spend or unsupervised publication.

Memory is split between episodic (append-only, what happened) and semantic (distilled priors). The semantic consolidation is human-reviewed before it updates the agent’s long-term behaviour. Governance is therefore not a single approval button bolted on at the end; it is woven through the budget envelope, the role matrix and the memory-write path.

For a regulated or brand-sensitive organisation, this is often the deciding axis. An autonomous content tool that can publish without a checkpoint is a liability the moment it gets a fact, a tone or a competitor claim wrong. SkuLift’s posture is that autonomy should accelerate the work up to the point of external impact and then stop for a human. The audit trail makes that defensible after the fact: the human-gate decisions are recorded, so a brand can show who approved what and when, rather than discovering an unreviewed change only after it is live.

Governance and speed are usually framed as a trade-off; the gate is designed so they are not. Everything up to the point of publication — measurement, pattern extraction, drafting a recommendation, preparing a lift — runs autonomously and quickly, so the human is asked to decide, not to do the work. The approval step is therefore a few seconds of judgement on a fully prepared action, not a bottleneck that re-introduces manual labour. That balance is the whole point: keep the throughput of automation while keeping the accountability of a person on the publish decision.

Rankscale documents a readiness/diagnose/fix/prove workflow. A formal, persisted human-gate state machine with owner approval before every external action is not described in its public materials, so we make no assertion either way.

The closed loop is the product. Measurement that does not lead to action leaves a marketing team with a dashboard and no next step. SkuLift turns measurements into Insights (stable patterns: citation gaps, content gaps, mention drops, competitor surges), Insights into Recommendations, and Recommendations — once approved at the human gate — into Lifts. A Lift is a versioned, scheduled, replayable action that ships a measurable change to a real surface: a WordPress article, a Shopify copy edit, a Studios bulk update.

After a Lift ships, a re-measurement is queued at a configurable horizon (default seven days) and the delta against the pre-lift baseline is written back. The loop is therefore auditable end to end: the recommendation links to the lift, the lift links to the published change, and the change links to the re-measured outcome.

This is the structural difference from a monitoring-only tool. A monitor tells you the score; the loop changes the score and proves the change. The editorial pipelines (WordPress, the article generator, Studios) live inside the loop precisely because, without an execution surface, a recommendation is theatre.

The attribution this produces is the quiet payoff. Because each lift links to a published change and that change links to a re-measured delta, a marketing leader can answer the hardest question in the category — did the work move the number — with a specific before-and-after rather than a correlation. Over several iterations the agent’s memory also accumulates which kinds of lift moved which kinds of gap, so the loop does not just close once; it compounds, running each cycle against a better prior than the last.

A fair caveat keeps this honest too: a closed loop is more to operate than a dashboard. It assumes you have a surface to publish to — a WordPress site, a Shopify store, a Studios workspace — and a person to sit at the gate. For a team that only wants the number and will act on it through channels of its own, that machinery is overhead it does not need, and a focused monitor is the lighter, sensible choice. The loop earns its keep specifically when acting on findings is the bottleneck, which for most content-driven brands it is.

Rankscale’s page audit surfaces concrete fixes through a deterministic, rule-based engine (explicitly no LLMs in the audit) — a real and fast diagnostic-to-fix path. What is not publicly documented as such is a scheduled publish-then-re-measure loop that writes a baseline-versus-post delta back to the originating recommendation.

Choose SkuLift when measurement is only step one. If your team needs a defensible SOV methodology (the four-level pyramid, PWC weighting, N=5 sampling, A/B/C intent split), the parametric-versus-web-grounded distinction per engine, agentic protocol support, and — above all — a human-gated loop that turns a measured gap into a published change and then re-measures the impact, SkuLift is built for that whole arc.

Rankscale is the better choice if your priority is a broad engine list at accessible entry pricing plus a deep, deterministic page-level AI-readiness audit — particularly for an agency or an SEO-led team that wants fast, rule-based technical checks across many engines and clients without a long onboarding. Its deterministic audit is a real differentiator there.

If you are unsure, the deciding question is simple: do you want a tool that tells you the score, or a tool that changes the score and proves it. Rankscale is strong at the former on its own terms; SkuLift is built for the latter, with the measurement depth to back it up. Neither answer is wrong — they describe different jobs.

Team shape matters as much as feature lists. Rankscale rewards a team that already has content and governance capacity and wants a sharp, focused instrument. SkuLift rewards a team that wants the instrument and the operating loop in one place — measurement, recommendation, human-gated execution and re-measurement — so that fewer hand-offs sit between seeing a gap and proving it closed. If your bottleneck is acting on insights rather than producing them, the loop is the part that pays for itself.

A practical tie-breaker: write down the three questions your leadership actually asks. If they are "where do we stand, in which markets, with what sentiment", a focused analytics tool answers them well. If they are "what should we do about it, who approved it, and did it work", those are loop questions, and a measure-only tool will leave you assembling the answer by hand each quarter.

Start by transposing what you already track. The brand, the competitor set and the comparison themes you maintain in Rankscale map onto SkuLift’s SOV query set — the SOV Setup agent calibrates that set against a seed sample so you are not re-typing prompts by hand. Existing reporting cadences carry over; SkuLift runs the query battery on a recurring schedule across ChatGPT, Claude, Gemini and Perplexity.

What is new is everything downstream of the number. Once a measurement gap is detected, the Insights and AEO-GEO Strategist agents propose a concrete action, an owner approves it at the human gate, and a Lift ships the change to a real surface — a WordPress article, a Shopify edit, a Studios update. A re-measurement is then scheduled to write the delta back, so the migration also gives you attribution you did not have before.

Run the two tools in parallel during a pilot. Keep Rankscale reporting live, bring SkuLift up on the same brand and competitor set, and compare the numbers for one full measurement window before switching primary reporting. Because SkuLift separates parametric from web-grounded answers, expect to see structure your previous single-number view did not surface — that is the methodology working, not a discrepancy.

Plan the cutover around a first lift, not just a first measurement. The migration is only complete when you have run one gap all the way through the loop: detected it, approved a recommendation at the human gate, shipped a Lift, and read the re-measured delta. That first full cycle is the moment the closed loop stops being a diagram and becomes your operating cadence; everything before it is parity with Rankscale, and everything after it is the capability the migration was for.