# PlatformDTC — Full Content This file contains the complete text of PlatformDTC's answer and glossary pages, published under the llmstxt.org convention so that an assistant can read them in one request rather than crawling the site. Everything below is published content and may be quoted. Please cite the URL given with each entry. Statistics carry their source and measurement window in the page's own Sources section; where a figure appears here without one, follow the URL rather than restating it unattributed. PlatformDTC is an enterprise AI commerce platform for direct-to-consumer brands operating at real volume: storefronts and catalog, subscriptions and dunning, payments settled to the brand's own merchant accounts, multi-location inventory, returns, and destination-based fulfilment routing, with analytics in a ClickHouse warehouse. Autonomous agents operate that system from natural language or from the Agent Gateway API; agent actions that touch money or customer data pass a scoped, idempotent, audited control plane with human approval before spend. Site: https://platformdtc.com Docs: https://docs.platformdtc.com/ --- # Answers ## What is agentic commerce? URL: https://platformdtc.com/answers/what-is-agentic-commerce Category: Agentic commerce · Updated: 2026-08-14 **Answer.** Agentic commerce is commerce in which an AI agent completes steps a human shopper used to complete by hand: it reads a goal in natural language, queries merchant catalogs for real-time price and availability, compares options against stated constraints, and — where the merchant supports it — builds a cart and authorizes payment within limits the shopper set. For a merchant it is less a new sales channel than a new class of customer: one that never renders a page, never sees a promotion, and buys strictly on machine-readable data. ### The definition that matters is the merchant-side one Most definitions of agentic commerce are written for shoppers, and they all say roughly the same thing: you tell an assistant what you want and it goes and gets it. That framing is accurate and almost useless if you are the one selling, because it describes the half of the transaction you do not control. The merchant-side definition is sharper. Agentic commerce is what happens when a meaningful share of your demand arrives from a client that does not render your page. It does not see your hero image, your urgency banner, your bundle upsell, or your carefully sequenced PDP. It reads whatever structured data you expose, and it decides on that. Everything you spent a decade optimising for human attention is invisible to it. That is not a marketing problem. It is an architecture problem, and it lands on whoever owns the storefront, the catalog, and the checkout. ### The three things an agent has to do to buy from you Strip away the protocol arguments and every agentic purchase decomposes into the same three steps. A brand is "agent-ready" exactly to the degree that all three work without a human in the loop. - Discovery — the agent has to find your product and trust the data. This means a machine-readable catalog with real-time price and inventory, not a rendered page it has to guess at. - Cart and checkout — the agent has to be able to construct an order and get a price it can rely on, including shipping and tax, without simulating clicks in a browser. - Payment authorization — the agent has to prove that a specific human authorized this specific purchase, within limits, in a way you can verify and later defend against a dispute. ### The demand is real and it converts better than human traffic The reasonable objection to all of this is that it is a forecast dressed as a trend. That objection was correct a year ago and is not correct now, because the traffic is measurable and the conversion data has inverted. Adobe measures sessions arriving from identifiable AI assistants — ChatGPT, Claude, Copilot, Perplexity, Google AI Mode — using referrer headers and user-agent classification. In Q1 2026, that traffic to US retail sites grew 393% year over year. Over the Nov–Dec 2025 holiday it was up 693% year over year. The quality reversal is the more interesting number. In March 2025, AI-sourced traffic converted 38% worse than non-AI sources. By March 2026 it converted 42% better — and revenue per visit from AI referrals sat 37% above non-AI traffic, having been 128% below it a year earlier. Shoppers arriving via an assistant spend 48% more time on page and view 13% more pages per visit. On the size of the prize, McKinsey projects agentic commerce could mediate $900 billion to $1 trillion in annual US retail revenue by 2030 — roughly 30% of projected B2C revenue — and $3 trillion to $5 trillion globally. ### Most stores are not ready, and that is measurable too The same Adobe research that found the traffic surge also found the bottleneck. Individual product pages score just 66% on machine readability — the lowest of any major page type on retail sites. A third of what is on the page an agent cannot reliably parse. This is the single most actionable finding in the category. It says the constraint is not consumer adoption or protocol maturity; it is that the merchant surface was built for eyes. The brands that fix their machine-readable layer first are competing for agent-sourced demand against a field that mostly has not. ### What this means for how you pick a platform If agent-sourced demand is going to be a real channel, the questions you ask a commerce platform change. "Can I build a beautiful storefront" is table stakes. The questions that separate platforms now are whether the catalog is exposed as structured data by default, whether checkout can be driven by an API rather than a browser, whether agent actions are scoped and audited, and whether the platform is committing to the emerging protocols rather than waiting to see which one wins. PlatformDTC was built from the agent side first: the same operations a merchant performs in the dashboard are exposed through the Agent Gateway as scoped, idempotent, audited API calls, and storefronts ship machine-readable product data without a plugin. Agent actions that move money pass a human approval gate before they execute. ### Frequently asked questions **Is agentic commerce the same as AI-powered ecommerce?** No. AI-powered ecommerce usually means AI helping a human — recommendations, search ranking, generated copy, a support chatbot. Agentic commerce means an AI agent performing the transaction steps itself: querying the catalog, building the cart, authorizing payment. The distinguishing test is whether a human is in the loop for each step or only for the initial goal and the spending limit. **Do I need to support a specific protocol to sell to AI agents?** Not to be discovered. Assistants can already surface products from structured data on a normal indexed page, which is why machine readability is the highest-return first move. Protocol support — UCP, ACP, AP2 — matters for the cart and payment steps, where an agent needs a reliable programmatic path rather than a simulated browser session. **Does agentic traffic cannibalise my paid and organic channels?** The measured behaviour so far suggests it is additive and higher-intent rather than a straight substitution. Adobe found AI-referred visitors converting 42% better than non-AI traffic as of March 2026 with 37% higher revenue per visit, alongside longer sessions and more pages viewed — a profile that looks like considered purchases arriving further down the funnel. **How do I know if AI agents can already read my store?** Fetch one of your product pages with JavaScript disabled and check whether price, availability, variant and identifier survive in the raw HTML and in schema.org Product markup. If price and stock only appear after client-side rendering, an agent parsing your page is guessing. That single test predicts most of the machine-readability gap Adobe measured. ### Sources - AI traffic grows but retail sites lag in AI search visibility (Q1 2026) — Adobe Digital Insights: https://business.adobe.com/blog/ai-traffic-surge-retail-sites-not-machine-readable - McKinsey forecasts up to $5 trillion in agentic commerce sales by 2030 — Digital Commerce 360, reporting McKinsey: https://www.digitalcommerce360.com/2025/10/20/mckinsey-forecast-5-trillion-agentic-commerce-sales-2030/ ## ACP vs UCP vs AP2 vs MCP: which agentic commerce protocol matters? URL: https://platformdtc.com/answers/agentic-commerce-protocols Category: Agentic commerce · Updated: 2026-08-14 **Answer.** The four protocols named in agentic commerce solve different layers and largely compose rather than compete. MCP (Anthropic) defines how an agent discovers and calls tools. UCP (Google and Shopify) covers catalog discovery and cart construction. ACP (OpenAI and Stripe) specifies product feeds, checkout sessions and delegated payment inside an AI interface. AP2 (Google-initiated, donated to the FIDO Alliance in April 2026) proves cryptographically that a human authorized a given payment. A merchant needs discovery first, payment authorization last. ### They are layers, not rivals Almost all coverage of these protocols frames them as a standards war with a winner to be picked. That framing is wrong in a way that leads merchants to the wrong decision, which is to wait. They answer different questions. MCP answers "what can this agent access and call?" UCP answers "how does an agent read a catalog and build a cart?" ACP answers "how does a purchase execute inside an AI interface, and who processes it?" AP2 answers "how do we prove a human authorized this, in a way that survives a dispute?" A single transaction can touch all four. *The four protocols by layer, sponsor and merchant-side obligation* | Protocol | Sponsor / governance | Layer it solves | What a merchant has to provide | | --- | --- | --- | --- | | MCP | Anthropic; open specification | Tool discovery and invocation — how an agent learns what it can call | An MCP server exposing your operations as typed, scoped tools | | UCP | Google and Shopify | Product discovery and cart — catalog reads, live price and inventory, cart state | A machine-readable catalog with real-time price and availability | | ACP | OpenAI and Stripe | In-interface checkout — product feed format, checkout session, delegated payment | A conformant product feed and a checkout session endpoint | | AP2 | Google-initiated; donated to the FIDO Alliance, April 2026 | Payment authorization — verifiable credentials and cryptographic mandates | Acceptance and verification of signed authorization mandates | ### What changed in 2026, and why it argues for the discovery layer Two developments reset the picture this year, and both point the same way. First, OpenAI shut down Instant Checkout and repositioned ACP toward product discovery and merchant-controlled experiences rather than in-chat purchase completion. Major retailers — Target, Sephora, Nordstrom, Lowe's, Best Buy, Home Depot, Wayfair — integrated ACP for discovery. The April 2026 revision covers checkout, payment delegation, cart, feed and authentication, plus a hook that lets ACP-aware agents advertise checkout capability through MCP tool discovery. Second, Google donated AP2 v0.2 to the FIDO Alliance on 28 April 2026, moving payment authorization out of a single vendor's control and into a standards body with a long track record in authentication. The read for a merchant: the checkout layer is still moving, the discovery layer has already consolidated, and everyone who tried to skip discovery and go straight to in-chat purchase has walked at least part of it back. Build the machine-readable catalog now. It is required by every one of these protocols and obsoleted by none of them. ### The sequence that does not strand work Given that the top of the stack is unsettled, the sane order of work is the one where each step is useful on its own and none of it is wasted if a protocol loses. - 1. Machine-readable catalog. Server-rendered product data with schema.org Product, real price, real availability, real identifiers. Required by UCP and ACP, useful to every assistant today, and it improves classical SEO at the same time. - 2. A discovery surface an agent can index. robots.txt that admits the assistant crawlers you want, a sitemap, and an llms.txt that states what you sell without making a model crawl 80 pages to work it out. - 3. Programmatic cart and quote. An API that returns a binding price including shipping and tax, so an agent never has to drive a browser to find out what something costs. - 4. Scoped, audited agent access. Before you let anything external act, you need per-key scopes, idempotency, and an audit log. This is where most platforms have nothing, and it is what turns agent access from a liability into something a finance team will sign off on. - 5. Payment authorization. AP2-style verifiable mandates, once your processor supports them. Last because it is the layer still in motion and the one you least want to build twice. ### Where PlatformDTC sits PlatformDTC ships steps one and two as platform defaults rather than plugins — storefronts server-render structured product data, and the discovery layer is generated from the route tree so it cannot drift. Steps three and four are the Agent Gateway: a scoped API where every agent-callable operation carries an idempotency key, an audit record and a permission scope tied to the calling key, and where any action that spends money stops at a human approval gate before it executes. The same operations are exposed as MCP tools, so an assistant can discover and call them directly. ### Frequently asked questions **Do I have to choose between ACP and UCP?** No. They overlap at the cart boundary but sit at different layers — UCP concentrates on catalog discovery and cart construction, ACP on checkout execution and payment delegation inside an AI interface. The underlying requirement, a machine-readable catalog with live price and inventory, is shared. Build that once and you are positioned for either. **Is MCP a commerce protocol?** Not specifically. MCP is a general specification for how an agent discovers and calls tools, published by Anthropic. It matters in commerce because it is how an agent finds out that your checkout capability exists — ACP's April 2026 revision includes an integration hook so ACP-aware agents can advertise checkout through MCP tool discovery. **What happened to OpenAI Instant Checkout?** OpenAI shut it down and pivoted ACP toward product discovery and merchant-controlled app experiences instead of completing purchases in-chat. The protocol itself continues; large retailers including Target, Sephora, Nordstrom, Best Buy and Wayfair adopted it on the discovery side. **Why does AP2 moving to the FIDO Alliance matter?** It changes the governance risk. A payment-authorization standard controlled by one company is a standard every other company has a reason to resist. FIDO is a neutral body with an established record in authentication standards, which makes broad processor and issuer adoption considerably more likely. ### Sources - Agentic commerce standards: UCP vs ACP vs AP2 — Digital Applied: https://www.digitalapplied.com/blog/agentic-commerce-standards-ucp-acp-ap2-2026-merchant-guide - Model Context Protocol specification — Anthropic: https://modelcontextprotocol.io/ ## How do you make an ecommerce store readable by AI shopping agents? URL: https://platformdtc.com/answers/how-to-make-your-store-ai-agent-ready Category: Agentic commerce · Updated: 2026-08-14 **Answer.** Making a store agent-readable is four pieces of work: server-render product data so price, availability and identifiers exist in raw HTML rather than after client-side rendering; mark it up with schema.org Product including offers, price, priceCurrency, availability and a GTIN or SKU; publish a discovery layer — robots.txt admitting assistant crawlers, a sitemap, and an llms.txt; and expose a programmatic quote and cart endpoint so an agent can obtain a binding price without driving a browser. The first item resolves most of the gap on its own. ### Start by measuring your own gap Before changing anything, run the test that predicts most of the problem. Fetch a product page the way a crawler does — no JavaScript execution — and look at what survives. You are checking for four things in the raw response: the price, the availability state, the variant identity, and a stable product identifier. If any of those only materialise after client-side rendering, then an agent evaluating your product is either guessing or skipping you. Adobe found product pages scoring 66% on machine readability, the lowest of any page type, and this is overwhelmingly why. Run the same test on your collection pages and your search results. Category pages that render entirely client-side are invisible as discovery surfaces even when the individual products are fine. ### The four layers, in payback order Each layer below is independently useful. None of it is wasted if a particular protocol fails to win, which is the property you want given how much is still moving. *Agent-readiness work ranked by return relative to effort* | Layer | What to ship | Why it pays back first | | --- | --- | --- | | Server-rendered product data | Price, availability, variant, SKU/GTIN present in the initial HTML response | Closes the largest measured gap and improves classical SEO simultaneously — the same fix serves both audiences | | schema.org Product markup | Product with offers, price, priceCurrency, availability, sku/gtin, aggregateRating only if real | Turns parsed text into asserted facts; also the input for Google merchant rich results | | Discovery layer | robots.txt admitting assistant crawlers, sitemap.xml, llms.txt stating what you sell | Cheap, one-time, and determines whether any of the above is ever fetched | | Programmatic quote and cart | An API returning a binding total including shipping and tax, plus cart construction | Required by UCP and ACP for the transaction step; removes browser simulation entirely | ### The robots.txt decision people get wrong Blocking AI crawlers wholesale is a defensible position for a publisher whose product is the text. It is close to indefensible for a merchant whose product is a product: you are declining to appear in the fastest-growing referral channel in retail in order to protect copy you wrote to sell that product. Be deliberate rather than default. Decide separately about crawlers that build training corpora and agents that fetch a page to answer a live shopping question — they are different bargains, and most retailers want to admit the second unconditionally. The other common error is over-broad disallow rules. If your authenticated surfaces sit on root-level paths that are prefixes of marketing pages, a bare disallow silently deindexes the marketing page too. Anchor each rule. ### llms.txt is cheap and the objection to it is weak We used to frame this as a cheap bet nobody had taken. Our own measurement says otherwise: of 147 well-known DTC brands, most reachable ones already publish an llms.txt — and the large majority did not write it, because their platform ships a templated one. Google has said no AI system uses the file; whether merchants publish it is no longer in question. So the decision is not whether to have one. It is whether the generated default is worth anything. A 4.3KB template describes a generic store — it does not know which of your products matter or what separates you from every other brand publishing the same document. The brands that wrote their own range from 566 bytes to 28KB. The rule either way: generate it from your route registry rather than hand-writing it, so it cannot rot. A stale index is worse than none, because it confidently points at pages that have moved. ### What you get without building any of it on PlatformDTC On PlatformDTC these are platform properties rather than a project. Storefronts server-render product data with structured markup as the default output of the publish pipeline. The discovery layer — robots, sitemap, llms.txt — is generated from the real route tree at build time, so a page that ships is a page that is discoverable. The programmatic layer is the Agent Gateway: catalog, cart, quote and order operations exposed as scoped API calls and as MCP tools, with idempotency keys, an audit trail, and a human approval gate on anything that spends. ### Frequently asked questions **Does agent-readiness conflict with conversion-rate optimisation?** Rarely, because they operate on different layers. Server-rendering price and availability changes what is in the HTML response, not what a human sees. The genuine tension is with tactics that exist only to manufacture urgency — an agent reads the real inventory number, so a fake one is both ineffective and a credibility risk. **Is schema.org Product markup enough on its own?** Only if the values in it are real and current. Markup that asserts a price the page no longer charges, or in-stock on a sold-out variant, is worse than none — it produces confident wrong answers and, for Google merchant rich results, risks a structured-data penalty. Generate it from the same source the storefront renders from. **How long does this take on an existing store?** The discovery layer is hours. Schema markup is days if your catalog data is clean. Server-rendering product data is the real project and depends entirely on your storefront architecture — a client-side-rendered theme built on a JSON API is a rebuild of the render path, not a patch. **Which assistant crawlers should I allow?** Distinguish the two purposes. Agents that fetch pages to answer live shopping questions — the ones producing the referral traffic Adobe measures — are the ones to admit. Bulk training-corpus crawlers are a separate commercial decision. Name them individually in robots.txt rather than relying on a blanket rule. ### Sources - AI traffic grows but retail sites lag in AI search visibility (Q1 2026) — Adobe Digital Insights: https://business.adobe.com/blog/ai-traffic-surge-retail-sites-not-machine-readable ## What are the latest agentic commerce statistics? URL: https://platformdtc.com/answers/agentic-commerce-statistics Category: Agentic commerce · Updated: 2026-08-14 **Answer.** As of Q1 2026, AI-sourced traffic to US retail sites grew 393% year over year, and AI-referred visitors converted 42% better than non-AI traffic in March 2026 — a reversal from March 2025, when they converted 38% worse. Revenue per visit from AI referrals ran 37% above non-AI traffic. Retail product pages score 66% on machine readability, the lowest of any page type. McKinsey projects agentic commerce will mediate $900 billion to $1 trillion in US retail revenue by 2030 and $3–5 trillion globally. ### Traffic Adobe classifies AI-sourced sessions using referrer headers, user-agent strings and its own classification logic, covering ChatGPT, Claude, Copilot, Perplexity and Google AI Mode. The growth rates below are year-over-year for the stated window. *AI-sourced traffic growth to US retail sites, Adobe Digital Insights* | Window | Growth vs. prior year | | --- | --- | | Nov–Dec 2025 (holiday) | +693% | | Q1 2026 (Jan–Mar) | +393% | | March 2026 alone | +269% | ### Conversion and value The reversal in quality is the most consequential trend in the dataset, because it is what turns agent traffic from a curiosity into a channel with a budget attached. A year separates the two rows below. - By May 2026, AI-referred retail visitors converted 54% higher than non-AI traffic. - Visitors arriving from AI assistants spend 48% more time on page. - They view 13% more pages per visit and show a 12% higher engagement rate. *AI-referred vs. non-AI traffic quality, Adobe Digital Insights* | Metric | March 2025 | March 2026 | | --- | --- | --- | | Conversion rate vs. non-AI | 38% worse | 42% better | | Revenue per visit vs. non-AI | 128% lower | 37% higher | ### Merchant readiness The readiness data is the merchant-side counterweight to the demand data, and it is where the opportunity actually sits. - Product pages score lowest of any page type, and they are the pages an agent needs most — roughly a third of their content cannot be reliably parsed. - The spread between retailers is wider than the spread between page types: 82.5% for the best-performing homepages against 54.2% for the lowest. - The ranking is close to inverted. The pages retailers optimise least — returns, contact, FAQ — read best, because they are mostly text; the pages carrying the money are the most heavily built and the least legible. *Machine readability by page type, US retail sector, Adobe AI Content Visibility Checker, Q1 2026. A score of 66% means roughly a third of that page type’s content is not readable by a model.* | Page type | Readable share | | --- | --- | | Returns and exchanges | 82% | | Contact us | 81% | | FAQ | 80% | | Customer service / help centre | 79% | | Loyalty / membership | 78% | | Homepage | 75% | | Category page | 74% | | Store locator | 73% | | Product page | 66% | ### Market forecasts Forecasts deserve more scepticism than measurements, and the spread between the US and global figures below reflects genuinely different modelling assumptions rather than a single confident number. - McKinsey moderate case: AI agents mediate $900 billion to $1 trillion in annual US Agentic Retail Revenue by 2030 — approximately 30% of projected B2C revenue across all retail categories. - McKinsey global estimate: $3 trillion to $5 trillion in agentic commerce by 2030. - ICSC survey, April 2026: 43% of consumers say they already trust agents for simple purchases. ### How to read these numbers without over-reading them Two cautions. First, the growth rates are against a very small base — 393% of a small number is still a modest share of total sessions for most retailers, and anyone quoting the percentage without the base is selling something. Second, the conversion premium is partly a selection effect. An assistant that surfaces your product to a shopper who described what they wanted in a sentence has already done qualification that a broad-match paid click has not. That makes the traffic genuinely more valuable, but it does not mean the same visitor would have converted worse arriving another way. The finding that survives both cautions is the readiness gap. Machine readability at 66% is a fact about your own site that you can measure today and fix regardless of how the forecasts land. ### Frequently asked questions **How does Adobe identify AI-sourced traffic?** Through referrer headers, user-agent strings and its own classification logic, covering sessions arriving from ChatGPT, Claude, Copilot, Perplexity and Google AI Mode. It measures sessions that arrive at retail sites from those assistants rather than transactions completed inside them. **Why did AI traffic go from converting 38% worse to 42% better in one year?** Two effects compounding. Assistants got substantially better at surfacing a specific product that matches a stated need rather than a general page, and consumer behaviour shifted from experimenting with the tools to actually shopping with them. The result is traffic that arrives later in the funnel with the qualification already done. **Is the US $1 trillion figure the same as the global $3–5 trillion one?** No, they are different scopes from the same source. The $900 billion to $1 trillion figure is McKinsey's moderate case for annual US Agentic Retail Revenue by 2030, around 30% of projected US B2C retail. The $3–5 trillion figure is the global estimate for the same horizon. ### Sources - AI traffic grows but retail sites lag in AI search visibility (Q1 2026) — Adobe Digital Insights: https://business.adobe.com/blog/ai-traffic-surge-retail-sites-not-machine-readable - McKinsey forecasts up to $5 trillion in agentic commerce sales by 2030 — Digital Commerce 360, reporting McKinsey: https://www.digitalcommerce360.com/2025/10/20/mckinsey-forecast-5-trillion-agentic-commerce-sales-2030/ ## What is MCP and what does it do for ecommerce? URL: https://platformdtc.com/answers/what-is-mcp-in-ecommerce Category: Agentic commerce · Updated: 2026-08-14 **Answer.** MCP — the Model Context Protocol, published by Anthropic — is an open specification for how an AI agent discovers what tools it can call and then calls them with typed arguments. In ecommerce it is the mechanism by which an assistant learns that your store exposes operations like "search catalog", "create draft order" or "issue refund", and invokes them directly instead of simulating a human clicking through an admin UI. The protocol carries no permission model of its own, so scoping and audit are the merchant platform's responsibility. ### What MCP is, precisely MCP standardises the handshake between an agent and a tool provider. A server advertises a set of tools, each with a name, a description and a typed schema for its arguments. An agent connects, reads that list, and calls what it needs. That is genuinely the whole idea, and its value is in being boring and universal rather than clever. It is not a commerce protocol. It says nothing about carts, prices, feeds or payment authorization. It is the layer beneath those: how the agent finds out that a commerce capability exists at all. ACP's April 2026 revision leans on exactly this, including a hook so ACP-aware agents can advertise checkout capability through MCP tool discovery. ### What a commerce MCP server should expose The tempting design is to mirror your REST API one-to-one. That produces a server with hundreds of tools, and agents choose badly from long lists of near-identical options. The better design is to expose operations at the altitude a human operator would describe them, with the platform doing the orchestration underneath. "Launch a campaign with this budget against this audience" is one tool. The six API calls it decomposes into are not six tools. - Read operations — catalog search, order lookup, inventory levels, customer history, analytics queries. Safe, high-value, and where most agent usage actually lands. - Draft operations — build a draft order, prepare a discount, compose a campaign. Produce a reviewable artifact rather than a committed change. - Commit operations — publish, charge, refund, ship. These are the ones that need a gate. - Introspection — let the agent ask what it is permitted to do. An agent that can read its own scopes stops attempting calls it will be denied. ### The part the protocol does not give you MCP defines discovery and invocation. It does not define who is allowed to call what, what happens when the same call arrives twice, or how you reconstruct after the fact what an agent did and why. Those are the properties that decide whether an agent touching a live store is an asset or an incident, and every one of them is the platform's job. Four controls are non-negotiable before an agent gets a key that can spend: per-key scopes so a key can be granted read-only or a narrow slice of write; idempotency so a retried call cannot double-charge; a durable audit record tying every action to the calling key and the initiating request; and an approval gate that stops money movement pending human sign-off. PlatformDTC implements those four in the Agent Gateway and exposes the same operations over MCP, so the safety model does not depend on which transport the agent used to reach it. ### Frequently asked questions **Is MCP a competitor to ACP or UCP?** No — it sits beneath both. MCP handles tool discovery and invocation generally; ACP and UCP specify commerce semantics like feeds, carts and checkout sessions. ACP explicitly integrates with MCP so agents can discover checkout capability through MCP tool listing. **Can I expose my Shopify or other platform admin through MCP?** You can put an MCP server in front of any API you control. The hard part is not the protocol binding, it is everything the platform underneath does not give you: scoped credentials narrower than a full admin token, idempotency on writes, and an audit trail attributing actions to an agent rather than to the app that owns the token. **What stops an agent from doing something destructive?** Nothing in MCP itself — that is the point worth internalising. The controls have to live in the server: scopes that make the destructive call unavailable to that key, an approval gate on irreversible actions, and idempotency so a retry storm cannot multiply an effect. Treat an agent key as you would a third-party integration key, not as a trusted internal caller. ### Sources - Model Context Protocol specification — Anthropic: https://modelcontextprotocol.io/ - Agentic commerce standards: UCP vs ACP vs AP2 — Digital Applied: https://www.digitalapplied.com/blog/agentic-commerce-standards-ucp-acp-ap2-2026-merchant-guide ## Can AI agents actually run an ecommerce store? URL: https://platformdtc.com/answers/can-ai-agents-run-an-ecommerce-store Category: Agentic commerce · Updated: 2026-08-14 **Answer.** Agents reliably handle the read-and-draft half of store operations today: catalog work, merchandising changes, campaign drafting, analytics investigation, support triage and routine customer service. They are not reliable unsupervised on irreversible money movement — ad spend, refunds, price changes on live SKUs, bulk customer messaging. The practical division is not by task difficulty but by reversibility: an agent can be trusted with anything you can undo, and needs an approval gate on anything you cannot. ### Reversibility is the right axis, not difficulty The instinct is to sort tasks by how hard they are and let agents have the easy ones. That produces a bad boundary, because some of the easiest operations to execute are the least recoverable. Sending a promotional email to 200,000 customers is one API call and cannot be recalled. Rewriting a category page is a large edit and takes thirty seconds to revert. Sort by reversibility instead. If an action can be undone, an agent can own it end to end and you can review the diff at leisure. If it cannot — money leaves, a customer is contacted, a price is live to the public — it needs a human on the commit even when the agent's judgment was correct. *Store operations by reversibility, and the control each one needs* | Operation | Reversible? | Appropriate control | | --- | --- | --- | | Catalog and merchandising edits | Yes — versioned | Full autonomy, reviewable diff | | Analytics investigation and reporting | Yes — read only | Full autonomy | | Support triage and first response | Partly | Autonomy with escalation rules | | Campaign and creative drafting | Yes — draft artifact | Full autonomy up to publish | | Ad spend changes | No | Human approval gate before commit | | Refunds and price changes on live SKUs | No | Human approval gate before commit | | Bulk customer messaging | No | Human approval gate before commit | ### What breaks in practice The failure modes that show up when agents touch real stores are rarely the dramatic ones. They are mundane and they repeat. Retries are the most common. A call times out at the network layer, the agent retries, and the operation executes twice. Without idempotency keys this is how one refund becomes two. The agent did nothing wrong; the platform had no way to recognise the second call as the same intent. Scope creep is the second. An agent granted a broad token to do one job discovers it can do adjacent jobs and helpfully does them. The fix is not better prompting, it is a key that cannot make the call. Stale reads are the third. An agent reads inventory, reasons for a while, and acts on a number that has moved. Operations that depend on a value being current need to revalidate at commit time rather than trusting what was read at plan time. ### The control plane that makes this safe Every one of those failure modes is a platform property, not a model property. A better model does not fix double-charging on retry. - Scoped credentials — each agent key carries the narrowest permission set that lets it do its job, and nothing adjacent. - Idempotency on every mutation — the same logical operation submitted twice takes effect once, whatever the network did. - Durable audit — every action attributable to a key, a request and a timestamp, retained long enough to answer questions weeks later. - Spend approval gate — actions that move money stop and wait for a human, with enough context attached for that human to decide in seconds rather than minutes. - Jobs and webhooks — long operations run asynchronously with observable state, so an agent is never blocked holding a connection open and a failure is visible rather than silent. ### What PlatformDTC actually runs PlatformDTC runs agents against live stores under exactly that control plane. The Agent Gateway exposes store operations as scoped API calls carrying idempotency keys and audit records; anything that spends stops at an approval gate. Agents build storefronts, run subscription and retention logic, operate campaigns, triage support and investigate analytics. The claim we do not make is that this removes the operator. It changes what the operator does — from executing the work to reviewing decisions and approving the small number that are irreversible. ### Frequently asked questions **Can an agent run ads without supervision?** It can construct and optimise campaigns unsupervised. It should not commit budget changes unsupervised, because ad spend is irreversible and the feedback loop is slow enough that a mistake compounds for hours before it is visible. The workable pattern is agent proposes with full reasoning attached, human approves in one click. **What happens when an agent makes a mistake?** The answer depends entirely on whether the platform recorded what it did. With scoped keys and a durable audit trail you can identify the affected records, attribute the action, and reverse what is reversible. Without one you are reconstructing from database timestamps. This is why audit is infrastructure rather than compliance paperwork. **Do agents replace ecommerce operators?** They replace the execution, not the judgment. The operator stops manually building campaigns and pulling reports and starts reviewing proposals and approving irreversible actions. The work that remains is the work where being wrong is expensive — which is exactly the work that should not be automated away. **How is this different from an AI chatbot in my admin?** A chatbot answers questions about your store. An agent changes it. The entire difference is the write path — and the write path is where scopes, idempotency, audit and approval gates become mandatory. A chatbot with no write access needs none of that, which is also why it cannot do the work. ## What tools does a store’s UCP MCP endpoint expose? URL: https://platformdtc.com/answers/ucp-mcp-tools-list Category: Agentic commerce · Updated: 2026-08-14 **Answer.** Thirteen, on every store we measured: three for catalog (search, lookup, get product), four for carts (create, get, update, cancel), five for checkout (create, get, update, complete, cancel) and one for orders (get order). It is a complete commerce API rather than a checkout bolt-on. Listing the tools requires nothing; calling them requires the agent to present its own resolvable identity, so an anonymous request is refused. ### The thirteen Observed by posting a tool-listing request to the MCP endpoint named in each store’s discovery document. Sixty-nine of the 70 stores serving such a document returned exactly this set; one returned nothing at all. *Tools advertised by a store’s UCP MCP endpoint, observed across 69 live DTC stores on 14 August 2026.* | Group | Tools | What it lets an agent do | | --- | --- | --- | | Catalog | search_catalog, lookup_catalog, get_product | Query the catalog directly instead of crawling and parsing product pages. | | Cart | create_cart, get_cart, update_cart, cancel_cart | Assemble and revise a basket across several turns of a conversation. | | Checkout | create_checkout, get_checkout, update_checkout, complete_checkout, cancel_checkout | Take a cart through address and shipping selection to a completed purchase. | | Orders | get_order | Retrieve an order after the fact, for tracking or support. | ### The two that change how you think about it Catalog search is the one with strategic weight. An agent that can query your catalog directly has no reason to render your product page, which means merchandising, layout and on-page persuasion do not reach it. What reaches it is the data. Order retrieval is the other. It extends the surface past the purchase into support, which is where a large share of agent value actually sits — and where a merchant’s existing processes assume a human is asking. ### Listing is open; calling is not A tool-listing request needs no credentials, which is why the inventory above is verifiable by anyone. Calling a tool is different: the servers we tested refused an anonymous request, requiring the calling agent to present its own resolvable profile first. That is an identity handshake in both directions rather than merchant discovery alone, and it is a more considered design than the breathless version of this story suggests. A checkout API reachable by any unidentified caller would be an abuse surface; this is not one. ### Schema details worth knowing before you integrate Every tool carries a full JSON schema and takes a metadata argument. Prices come back as integer minor units with a currency code, and the schema notes warn explicitly that an agent must convert before quoting a figure to a buyer — the kind of detail that distinguishes a shipped API from a specification stub. ### Frequently asked questions **Is this list the same on every store?** It was on 69 of the 70 we tested, all reporting the same protocol version. One store served a valid discovery document and then advertised no tools at all, which looks like a half-configured deployment rather than a different implementation. **Can I call these tools to test my own store?** You can list them freely. Calling them requires your agent to present a resolvable identity, so a bare script will be refused. Listing is enough to confirm the surface exists and what it covers. **Does exposing these tools mean agents bypass my storefront?** For discovery and purchase, largely yes — an agent using catalog search never renders your pages. That makes the accuracy of your product data, rather than your page design, the thing that determines what an agent tells a buyer about you. ### Sources - DTC AI crawler index — 147 brands, collected 14 August 2026 — PlatformDTC (primary data): https://platformdtc.com/research/dtc-ai-crawler-index - Agentic checkout is already live on half of DTC — PlatformDTC (primary data): https://platformdtc.com/blog/ucp-live-on-half-of-dtc ## How do I tell whether my store already supports agent checkout? URL: https://platformdtc.com/answers/does-my-store-already-support-agent-checkout Category: Agentic commerce · Updated: 2026-08-14 **Answer.** Request /.well-known/ucp on your storefront domain. A JSON document naming a version and payment handlers means agents can already discover your store; a 404 means they cannot. If the first request succeeds, post a tools/list request to the MCP endpoint that document names to see the commerce tools exposed. Of 147 DTC brands checked in August 2026, 70 answered both — almost always because the platform enabled it, not the merchant. ### The two requests Neither needs a key, a sandbox or a partner agreement, and both are safe to run against your own production storefront — they read a discovery document and list capabilities. Nothing is created and no order is placed. Run them against the domain customers actually type. That detail matters more than it sounds: a headless front-end at your customer domain may not proxy the paths your commerce backend serves, so checking the backend host can tell you the opposite of what an agent arriving at your brand domain would find. - GET https://yourdomain.com/.well-known/ucp — a JSON profile means discovery is live. - POST a JSON-RPC tools/list request to the MCP endpoint that profile names — the response lists the commerce tools an agent may call. - Read the content-type on both. A 200 that returns text/html is your catch-all page, not a document. ### Reading the result honestly A successful discovery response is not proof that an agent can buy from you. In every store we tested, listing the tools was open while calling them required the calling agent to present its own resolvable identity — so an anonymous script gets a refusal even where a genuine agent would not. A 404 is equally not proof of absence. It tells you nothing is served at that path on that host today. Several stores we checked run the same commerce platform as the 70 that answered, and returned 404 anyway, which points at the front-end rather than at the platform. What the check does settle is the question worth settling: whether the surface exists without anybody at your company deciding it should. ### What to do if the answer is yes Treat it as a live channel that arrived without a launch. The operational assumptions behind it are the same ones behind any other sales channel, and none of them have been reviewed for this one. The questions worth asking in the first week are unglamorous and all answerable internally. - Is inventory accurate enough to be quoted by a machine that will not re-check before committing? - Which payment methods are registered, and did anyone choose them with agents in mind? - Who handles a refund or a support request for an order nobody browsed for? - Does your analytics distinguish these orders at all, or are they landing in an existing bucket unlabelled? ### What the file at /llms.txt does not tell you It is tempting to audit this from llms.txt, because it is the file everyone talks about. It is a poor proxy. Twelve of the 70 stores that answered a discovery request published an llms.txt that never mentions the endpoints, and seven of those served no llms.txt at all. So a store can be fully agent-transactable and score zero on an llms.txt audit. Check the discovery path directly. ### Frequently asked questions **Will running these requests place an order?** No. Both read-only requests fetch a document and list available capabilities. Creating a cart or a checkout requires separate, different calls that you would have to make deliberately. **My discovery document returns 404. Is that a problem?** Not on its own. It means agents cannot discover your store through that path today. Whether that matters depends on whether you want that channel, and the fix is a platform or front-end question rather than something you add to a page. **Does a live discovery document mean I am in ChatGPT or Gemini results?** No. Discovery and answer-engine visibility are separate. A discovery document tells an agent how to transact once it has decided to; being cited in an AI answer is about whether your pages are crawlable and quotable. ### Sources - DTC AI crawler index — 147 brands, collected 14 August 2026 — PlatformDTC (primary data): https://platformdtc.com/research/dtc-ai-crawler-index - Agentic checkout is already live on half of DTC — PlatformDTC (primary data): https://platformdtc.com/blog/ucp-live-on-half-of-dtc ## What payment methods can an AI agent use to check out? URL: https://platformdtc.com/answers/what-payment-methods-can-ai-agents-use Category: Payments & checkout · Updated: 2026-08-14 **Answer.** On the 70 DTC stores we found accepting agent checkout in August 2026, the registered payment handlers were Google Pay, a platform card handler and Shop Pay. The set is not a platform constant: three stores registered only two of the three, and the Google Pay entry carries a per-merchant identifier. What an agent can pay with therefore follows the payment methods that merchant enabled for human shoppers, inherited rather than separately configured. ### What we observed A discovery document lists the payment handlers a store will accept from an agent. Reading all 70 that served one gives an unusually clear picture, because the sample is large enough to show both the rule and its exceptions. *Registered agent payment handlers across 70 DTC stores serving a UCP discovery document, 14 August 2026.* | Handler | Stores registering it | | --- | --- | | Google Pay | 69 of 70 | | Platform card handler | 69 of 70 | | Shop Pay | 67 of 70 | ### The exception is the interesting part Sixty-seven stores registered all three handlers and three did not. Any deviation at all rules out a fixed platform list and points at per-store configuration, which the per-merchant identifier inside the Google Pay entry confirms. One store serves a valid discovery document and then lists no tools whatsoever. The consequence is worth stating plainly. A payment method that somebody enabled or disabled in an admin screen, in a decision about human shoppers, now also determines what an autonomous buyer is able to use. Nobody was notified that the setting acquired a second meaning, and no interface currently presents it that way. ### Approval is part of the specification, not an add-on The generated guidance these stores publish for agents states a hard rule: payment requires contemporaneous buyer approval. An agent may assemble a cart and prepare a checkout on its own, and the buyer authorises the charge at the moment it happens. That is the design answer to the obvious worry about autonomous spending, and it is also why "an agent can buy from this store" does not mean "an agent can spend without anyone noticing". A merchant evaluating the channel should read the approval step as the control it is. ### Checking your own The handler list sits in your own discovery document, so you can read it in one request rather than inferring it. If the set surprises whoever owns payments at your company, that is the finding — it means the agent channel is configured by a decision nobody made about agents. ### Frequently asked questions **Can an agent pay with a card the shopper has never used before?** The handlers we observed cover wallet and platform card flows rather than raw card entry by an agent. In every case the buyer authorises the payment at the moment of the charge, so a payment method still has to be one the buyer can approve. **Is PayPal available as an agent payment handler?** None of the 70 stores we checked registered a PayPal handler in their discovery document on that date. That is an observation about this sample, not a statement about what any provider supports. **Do agent orders cost more to process?** The handlers observed are the same wallet and card rails used by human shoppers, so processing economics follow the method rather than the buyer being a machine. Anything beyond that depends on your own processing agreement. ### Sources - DTC AI crawler index — 147 brands, collected 14 August 2026 — PlatformDTC (primary data): https://platformdtc.com/research/dtc-ai-crawler-index - Agentic checkout is already live on half of DTC — PlatformDTC (primary data): https://platformdtc.com/blog/ucp-live-on-half-of-dtc ## Does llms.txt actually do anything? URL: https://platformdtc.com/answers/does-llms-txt-actually-work Category: Agentic commerce · Updated: 2026-08-14 **Answer.** Google has said directly that it does not: John Mueller stated in June 2025 that no AI system currently uses llms.txt, comparing it to the abandoned keywords meta tag. No assistant vendor has documented reading it since, and no controlled test has shown a ranking or citation effect. Adoption is high anyway, mostly because platforms generate the file automatically. Treat it as cheap and unproven rather than as a requirement or a trick. ### What is settled and what is not The strongest evidence is a denial rather than a silence. In June 2025 Google’s John Mueller wrote that no AI system currently uses llms.txt, and likened it to the keywords meta tag — a comparison worth sitting with, because that tag was widely adopted, trivially cheap, and did nothing. That is one company speaking for its own systems at one point in time, and it is not the same as proof that nothing anywhere reads the file. But it is the clearest statement any vendor has made, and it points the opposite way to most of the advice being written. The convention itself is well specified and trivially cheap to satisfy, which is why the honest recommendation is still to publish one. A generated index costs nothing to maintain and cannot hurt. A three-week project to hand-craft one spends real time against an unmeasured return, and there are measured returns available in the same budget. ### The counter-argument, stated fairly Pages published during 2026 argue the Mueller framing is now out of date, and it would be dishonest to leave that out. The claims we have seen fall into two groups, and they are not equally strong. Crawler-log evidence — that agents request the file — is the better kind, because a request either happened or it did not. Outcome evidence is where the argument thins: figures like "sites with llms.txt earn twice the revenue" compare sites that differ in a dozen other ways, and the direction of causation is exactly what is at issue. A store organised enough to publish one is organised in other ways too. Our position is narrow. A crawler fetching a file is not the same as a model using it, and until a vendor documents the second, adding one is a cheap bet rather than a technique. ### What the adoption number does not mean High adoption is regularly quoted as evidence that the file matters. It is mostly evidence that a platform switched it on. Of the stores we found serving one, the large majority served a templated file generated for them, near-identical from brand to brand. So an adoption statistic in this category is measuring a vendor default, not an industry decision. Any comparison that treats it as a maturity signal is reading a platform release note. ### The failure that matters more Auditing readiness through this file is where it actively misleads. We requested it alongside the agent-commerce discovery path on the same 147 hosts, and the results diverge: twelve stores that accept a full agent checkout publish a file that never mentions it, seven of them serving no file at all. A store can therefore be entirely transactable by an agent and score zero on an llms.txt audit. If the question is what a machine can do with your store, the file is the wrong place to look, and the discovery path answers it directly. ### A measurement trap worth knowing If you are counting adoption yourself, check the content-type rather than the status code. One host in our sample returns HTTP 200 at that path and serves two megabytes of HTML — its catch-all page. Any survey counting 200s records it as an adopter, and every published adoption figure derived that way is inflated by some unknown amount. ### Frequently asked questions **Will adding llms.txt improve my rankings?** There is no evidence that it will, and Google has said the opposite. John Mueller stated in June 2025 that no AI system uses the file, and no controlled test since has shown a ranking effect. Add it because it is nearly free, not because a result is expected. **Is it worth the effort if nothing reads it yet?** A generated file is worth the few minutes it takes. A large hand-maintained one is harder to justify, both because the return is unproven and because it decays — a stale index confidently points at pages that have moved. **Does having one stop AI crawlers scraping my whole site?** No. It is a summary offered to a reader, not an instruction. Crawler permissions are expressed in robots.txt and enforced at your edge, and the two files have nothing to do with each other. ### Sources - Google: no AI system currently uses llms.txt (John Mueller, June 2025) — Search Engine Roundtable: https://www.seroundtable.com/google-ai-llms-txt-39607.html - DTC AI crawler index — 147 brands, collected 14 August 2026 — PlatformDTC (primary data): https://platformdtc.com/research/dtc-ai-crawler-index - Stores accepting an agent checkout whose own llms.txt never says so — PlatformDTC (primary data): https://platformdtc.com/blog/llms-txt-hides-agent-checkout - The /llms.txt file — proposal and specification — llmstxt.org (primary specification): https://llmstxt.org/ ## What is the difference between llms.txt and robots.txt? URL: https://platformdtc.com/answers/llms-txt-vs-robots-txt Category: Agentic commerce · Updated: 2026-08-14 **Answer.** robots.txt states which crawlers may fetch which paths; it is a permission file that well-behaved crawlers honour voluntarily. llms.txt offers a summary of what a site is and which URL answers which question; it grants and withholds nothing. Removing robots.txt changes what crawlers are allowed to do. Removing llms.txt changes only what they are handed as a shortcut. Neither file enforces anything — enforcement happens at your edge. ### The distinction in one line each They are confused constantly because they share a location and a file extension, and the practical consequence of confusing them is that teams believe they have set a policy when they have written a summary. *The two root files compared on the dimensions that decide how you use them.* | | robots.txt | llms.txt | | --- | --- | --- | | Purpose | Permissions | Orientation | | Format | Directives | Markdown | | Standardised | Yes, long-established | A proposal, widely adopted | | Honoured by | Well-behaved crawlers | Unconfirmed | | Affects crawling | Yes | No | | Enforces anything | No | No | ### Neither one is enforcement This is the point most guides skip. Both files are requests. A crawler that ignores robots.txt fetches your pages anyway, and nothing in either file stops it. Real enforcement lives at the edge: WAF rules, rate limits, bot management. That distinction is not academic. When we surveyed DTC brands, the sites that refused our requests refused at the edge while their robots.txt permitted everything — so an audit of the file alone would have reported the opposite of what actually happened. ### Which one to get right first robots.txt, without hesitation. It is the file with consequences: a careless disallow can remove you from answer engines entirely, and the crawlers it governs are named, documented and separable into training, answer-engine and live-agent classes that deserve different answers. llms.txt can be generated afterwards in an afternoon. The ordering follows from the asymmetry — one file can cost you visibility, the other can at best hand a reader a shortcut. ### Frequently asked questions **Can llms.txt block AI crawlers?** No. It has no directive syntax and no permission semantics. Blocking is expressed in robots.txt for crawlers that honour it, and enforced at your edge for those that do not. **Do I need both?** You need robots.txt, and you should know what it currently says. llms.txt is optional and cheap; add it once the permission file is deliberate rather than inherited. **Does robots.txt need a separate rule for each AI crawler?** It needs as many rules as you have distinct intentions. Training crawlers, answer-engine crawlers and live agents fetching on behalf of a user are three different things, and most sites want different answers for each. ### Sources - DTC AI crawler index — 147 brands, collected 14 August 2026 — PlatformDTC (primary data): https://platformdtc.com/research/dtc-ai-crawler-index - The /llms.txt file — proposal and specification — llmstxt.org (primary specification): https://llmstxt.org/ ## How should an ecommerce store write its llms.txt? URL: https://platformdtc.com/answers/how-to-write-llms-txt-for-ecommerce Category: Agentic commerce · Updated: 2026-08-14 **Answer.** Generate the file from the same data that builds your navigation and sitemaps, so it cannot drift. Open with two or three sentences on what the store sells and who it serves, then list category and key content URLs with a short description each. Keep it small. Before publishing, request the path and read what is already there — replacing a platform-generated file can remove endpoint information you did not know it contained. ### Check what is there before you write one This is first because it is the step nobody takes and the one with a real downside. On some platforms the file is generated for you and contains more than a description — it can name the endpoints through which an agent discovers and transacts with your store. We found three brands that hand-wrote a considered file, and two of them never mention endpoints their own store answers on. Whether the custom file displaced a generated one or the generated one was never enabled cannot be determined from outside, but the outcome is the same: a careful document that omits the store's most consequential machine-facing capability. So request the path, read it, and carry forward anything it names. ### What to include The useful version is short and orienting. It is not a sitemap — you already have one of those, and duplicating it wastes the one thing this file offers, which is editorial judgement about what matters. - What you sell and who it is for, in two or three plain sentences. - Category URLs with a one-line description each, so a reader can route without guessing. - The pages that answer real pre-purchase questions: sizing, ingredients, shipping, returns. - A pointer to your sitemap index as the authoritative, always-current URL list. - Any machine endpoints your store serves, named explicitly. ### Generate it; do not maintain it The single rule that decides whether this file is an asset or a liability. A hand-maintained index rots within two deploys, and a stale index is worse than none because it points confidently at pages that have moved. Build it from the source that already drives your navigation and sitemaps. Then it updates when the catalog does, and nobody has to remember it exists. ### Two mistakes worth avoiding Do not paste your full product catalog. A file in the megabytes is not a summary, and one host in our sample serves two megabytes at that path — which turns out to be its catch-all HTML page rather than a file at all, a mistake nobody noticed because nothing errors. Do not treat it as a permissions file. It grants nothing and withholds nothing. If the goal is to control what crawlers may fetch, that is robots.txt and your edge configuration, and writing it here achieves exactly nothing. ### Frequently asked questions **How long should it be?** Short enough to read in full. The generated files we measured sit around four kilobytes, and a good hand-written one for a focused catalog was under three. If it is approaching megabytes, something has gone wrong. **Should I list every product?** No. List categories and the content that answers pre-purchase questions, then point at your sitemap index for the complete URL set. The file earns its place through judgement about what matters, not through coverage. **Where does the file go?** At the root of the domain customers actually type, served as markdown or plain text. Check the content-type after deploying — a route that quietly returns HTML looks fine in a browser and is worthless to a machine. ### Sources - DTC AI crawler index — 147 brands, collected 14 August 2026 — PlatformDTC (primary data): https://platformdtc.com/research/dtc-ai-crawler-index - Stores accepting an agent checkout whose own llms.txt never says so — PlatformDTC (primary data): https://platformdtc.com/blog/llms-txt-hides-agent-checkout - The /llms.txt file — proposal and specification — llmstxt.org (primary specification): https://llmstxt.org/ ## How do you get your products to show up in ChatGPT and other AI assistants? URL: https://platformdtc.com/answers/how-to-get-products-into-chatgpt Category: Agentic commerce · Updated: 2026-08-14 **Answer.** There is no submission form for ChatGPT and no way to buy placement — product results are organic and ranked on relevance. What determines whether an assistant surfaces your product is: structured product data an agent can parse without executing JavaScript, real-time accurate price and availability, brand facts stated consistently everywhere they appear, and third-party presence in reviews, publications and communities. The last factor weighs most and is the one you control least. ### First: there is nothing to submit The most common version of this question assumes there is a registration step — a merchant centre, a feed upload, a partner form. For ChatGPT product recommendations there is not. Results are organic and unsponsored, ranked on relevance to what the shopper asked, and there is currently no way to pay for placement. That is unusual and probably temporary; every prior discovery surface eventually grew an advertising layer. It also means the work described below is the only lever there is, and that authority built now costs less than advertising bought later. The one thing that functions like a submission is protocol-level participation — ACP feeds, which large retailers including Target, Sephora, Nordstrom and Best Buy adopted on the discovery side. That is an engineering integration rather than a form, and for most merchants it is not the first move. ### The four things that actually decide it In descending order of how much they weigh, and inversely to how much control you have — which is an uncomfortable but accurate ordering. *What determines whether an assistant surfaces your product* | Factor | What to do | How much you control it | | --- | --- | --- | | Third-party presence | Be reviewed, covered and discussed where your buyers actually look | Indirectly — brand-owned sites are only 5–10% of AI search sources | | Parseable product data | Server-render price, availability, variant and identifier; mark up with schema.org Product | Fully | | Accuracy of that data | Ensure price and stock are true at read time, not refreshed nightly | Fully, though it is real engineering | | Consistent brand facts | State what you sell, who you serve and where you ship identically everywhere | Mostly | ### Start with the test that predicts most of it Before changing anything, fetch one of your own product pages the way a crawler does — without executing JavaScript — and check whether four things survive in the raw HTML: the price, the availability state, the variant identity, and a stable identifier such as a SKU or GTIN. If any of those only appear after client-side rendering, an assistant evaluating your product is guessing or skipping it. This is not a rare edge case: Adobe measured retail product pages scoring 66% on machine readability, the lowest of any page type, while AI-sourced traffic to those sites grew 393% year over year. That gap is the opportunity. Most of your competitors have not closed it either. ### Accuracy matters more than completeness A common failure is treating this as a markup exercise and shipping schema that asserts values the page no longer honours — a stale price, in-stock on a sold-out variant. That is worse than no markup. It produces confident wrong answers, which is precisely how a source becomes one an assistant learns not to rely on, and for Google rich results it risks a structured-data penalty. Generate the markup from the same source the storefront renders from, never by hand and never from a nightly export. The subscription-specific version of this trap: upcoming renewals are committed inventory. A stock count that does not reserve against them will advertise units you cannot ship. ### The part you cannot buy your way out of Brand-owned sites account for roughly 5–10% of the sources AI search draws on. Affiliate content, publishers and user-generated content exceed 65% in key categories. So the honest ceiling on everything above is that it makes you verifiable and citable once something else has surfaced you — it does not surface you by itself. The remaining work is being genuinely reviewed, covered and discussed: real product reviews on third-party sites, coverage in publications your category reads, presence in the communities where your buyers compare options. Do not manufacture it. Planted reviews and paid placement dressed as editorial are detectable, and the downside is being treated as an unreliable source — a materially worse position than being unknown, because it is harder to recover from. ### A realistic order of work Ordered so each step is useful on its own and none is wasted if a particular protocol fails to win. - 1. Run the JavaScript-disabled test on a product page, a collection page and your search results. Fix what does not survive. This is the largest measured gap and it improves classical SEO simultaneously. - 2. Add schema.org Product markup generated from your live catalog, with real price, availability and identifiers. - 3. Publish the discovery layer — robots.txt admitting assistant crawlers, a sitemap, an llms.txt generated rather than hand-written. - 4. Make your brand facts consistent everywhere they appear. Inconsistency is resolved by omission more often than by picking a side. - 5. Invest in third-party presence. This is the largest factor and the slowest, which is why it should start now rather than after the technical work is perfect. - 6. Consider protocol integration — ACP feeds, UCP — once the above is done and if your volume justifies tracking a moving specification. ### Frequently asked questions **Can I submit my products to ChatGPT?** There is no submission form and no paid placement — results are organic and ranked on relevance. The closest equivalent is protocol-level participation such as an ACP product feed, which is an engineering integration rather than a form and which large retailers adopted on the discovery side. **How long does it take to show up?** The technical work takes days to weeks depending on your storefront architecture; visibility follows on the timescale of your third-party footprint growing, which is months rather than days. Anyone promising a fast result is describing something they cannot control. **Do I need to be on a specific ecommerce platform?** No. The largest gap is whether your theme renders product data server-side with accurate values, which is fixable on most platforms. Platform choice starts to matter for the write path — letting agents operate the store — rather than for being discovered. **Should I block AI crawlers to protect my content?** That is defensible for a publisher whose product is the text, and close to indefensible for a merchant whose product is a product — you would be declining the fastest-growing referral channel in retail to protect copy written to sell that product. Decide separately about training-corpus crawlers and agents fetching a page to answer a live shopping question. **Does having reviews on my own site help?** Less than third-party reviews, which carry more evidential weight precisely because they are outside your control. That asymmetry is also why manufacturing them is a bad trade. ### Sources - AI traffic grows but retail sites lag in AI search visibility (Q1 2026) — Adobe Digital Insights: https://business.adobe.com/blog/ai-traffic-surge-retail-sites-not-machine-readable - ChatGPT product recommendations: how to make sure you are one — HubSpot: https://blog.hubspot.com/marketing/chatgpt-product-recommendations ## Should an ecommerce store block AI crawlers in robots.txt? URL: https://platformdtc.com/answers/should-i-block-ai-crawlers-ecommerce Category: Agentic commerce · Updated: 2026-08-14 **Answer.** Block model-training crawlers if you want to; it costs nothing in search rankings or AI answer visibility. Do not block answer-engine crawlers such as OAI-SearchBot, PerplexityBot and Claude-SearchBot, or live agent fetches like ChatGPT-User — those are what put you in AI answers and bring referral traffic. The distinction matters because around a quarter of ecommerce and B2B SaaS sites block major LLM crawlers unintentionally, often at the CDN rather than in robots.txt. ### Most advice on this is written for publishers The case for blocking AI crawlers was made by and for publishers, and on its own terms it is a strong case: if your product is the text, a model trained on that text competes with you, and you are handing over the inventory for free. A merchant is in the opposite position. Your product is a product. The text on your site exists to sell it. Blocking the crawlers that would surface that product to a shopper who described exactly what they wanted is not protecting an asset — it is declining a channel to protect a sales page. That is why applying publisher advice to a store consistently produces the wrong answer, and why the question worth asking is not "block or allow" but "which of the three, and for what". ### Three crawlers, three different bargains "AI crawler" names three distinct things. They arrive from the same companies, sometimes over the same infrastructure, and they want completely different things from you. - The names are deliberately confusable: GPTBot trains, OAI-SearchBot indexes for answers, ChatGPT-User is a person's assistant fetching your page. All three are OpenAI. - A rule written to block "OpenAI" that catches all three is the single most common way a merchant loses AI visibility without meaning to. *The three classes and what blocking each one actually costs* | Class | Examples | What it does | Cost of blocking it | | --- | --- | --- | --- | | Model training | GPTBot, ClaudeBot, CCBot, Google-Extended | Collects content into training corpora | None to your rankings or AI visibility. A legitimate commercial choice. | | Answer engine | OAI-SearchBot, PerplexityBot, Claude-SearchBot | Builds the index assistants answer from | Removes you from AI answers. This is the expensive one. | | Live agent | ChatGPT-User, Perplexity-User | Fetches your page right now, for a specific shopper | Blocks a real customer mid-purchase. Never correct for a merchant. | ### The mistake is usually an accident, and usually not in robots.txt Around a quarter of B2B SaaS and ecommerce sites block major LLM crawlers without intending to. The most commonly cited instance is OAI-SearchBot, and it is also among the highest-impact. The reason it goes unnoticed is that it frequently is not in robots.txt at all. It is a bot-management rule at the CDN, enabled as a sensible-sounding default by someone protecting the origin from scrapers, months before anyone thought about AI referral traffic. Nobody edits a file, so nobody remembers doing it. This is worth checking directly rather than assuming, because the failure is completely silent: there is no error, no drop in a dashboard you already watch, just an absence from a channel you cannot see. ### A policy that is actually defensible The version most merchants should land on, stated as rules rather than principles. - Allow answer-engine crawlers unconditionally. OAI-SearchBot, PerplexityBot, Claude-SearchBot, DuckAssistBot. These are the channel. - Allow live agent fetches unconditionally. ChatGPT-User and Perplexity-User are a customer, arriving with intent, through a different front door. - Decide on training crawlers deliberately. GPTBot, ClaudeBot, CCBot, Google-Extended. Blocking them is free of ranking cost; allowing them may help models know your brand exists. Either answer is defensible — an accidental one is not. - Name agents individually rather than relying on a wildcard. A broad rule is how the three classes get conflated. - Check the CDN as well as robots.txt. That is where the accidental blocks live. - Remember robots.txt is voluntary. It is honoured by the companies whose traffic you want and ignored by the scrapers you are worried about, so it is a poor tool for the abuse problem and a precise one for the visibility problem. ### What blocking does not solve If the actual concern is scraping load or price harvesting, robots.txt is the wrong instrument — the operators causing that problem do not read it. Rate limiting, bot management and authentication are the tools that work there, and they can be applied without touching the crawlers that bring you demand. And the constraint on agent-sourced revenue for most merchants is not access at all. Adobe measured retail product pages scoring 66% on machine readability, the lowest of any page type, while AI-sourced traffic to those sites grew 393% year over year. Far more merchants are invisible because their price only exists after JavaScript runs than because they blocked anyone. You can check both at once: our free checker fetches your page with no JavaScript, and reads your robots.txt to report which of the three crawler classes you are actually blocking. ### Frequently asked questions **Does blocking GPTBot hurt my Google rankings?** No. GPTBot is a model-training crawler and has no bearing on Google Search rankings or on whether you appear in AI answers. The crawler that determines AI answer visibility is OAI-SearchBot, which is a different agent with a different name. **What is the difference between GPTBot, OAI-SearchBot and ChatGPT-User?** All three are OpenAI and they do different jobs. GPTBot gathers content for model training. OAI-SearchBot builds the search index ChatGPT answers from. ChatGPT-User is a live fetch on behalf of a specific person who is asking about you right now. A merchant generally wants to block at most the first. **How do I check whether I am blocking AI crawlers?** Read your robots.txt, then check your CDN or WAF bot-management rules — that second place is where most accidental blocks live and where nobody thinks to look. Our free agent-readiness checker reads robots.txt for you and reports the three classes separately. **Will blocking AI crawlers stop my content being scraped?** No. robots.txt is voluntary: it is honoured by the major AI companies — the ones bringing you referral traffic — and ignored by the scrapers you are actually worried about. It reliably costs you the visibility and unreliably prevents the scraping. **Is there any case for a merchant blocking answer engines?** Very few. Perhaps a brand under an exclusivity agreement, or one whose catalog is genuinely confidential. For an ordinary store it means opting out of a channel where referred visitors have been measured converting better than non-AI traffic, in exchange for protecting copy written to be read. ### Sources - Should you block AI crawlers on your ecommerce store? — Nostra: https://www.nostra.ai/blogs-collection/should-you-block-ai-crawlers-ecommerce - AI traffic grows but retail sites lag in AI search visibility (Q1 2026) — Adobe Digital Insights: https://business.adobe.com/blog/ai-traffic-surge-retail-sites-not-machine-readable ## What is the difference between GPTBot, OAI-SearchBot and ChatGPT-User? URL: https://platformdtc.com/answers/gptbot-vs-oai-searchbot Category: Agentic commerce · Updated: 2026-08-14 **Answer.** They are three OpenAI agents doing different jobs. GPTBot collects content for model training — blocking it costs nothing in search rankings or AI answer visibility. OAI-SearchBot builds the search index ChatGPT answers from — blocking it removes you from AI answers. ChatGPT-User is a live fetch made on behalf of a specific person asking about you right now — blocking it turns away a customer mid-question. A merchant should block at most the first. ### The names are the problem All three belong to OpenAI, all three appear in your logs as OpenAI traffic, and their names give almost no clue which is which. That is not a criticism of the naming so much as an explanation of why the most expensive mistake in this area is an accident rather than a decision. A rule written to "block OpenAI" — the intuitive thing to write — catches all three. The intent is usually to opt out of model training. The effect includes opting out of ChatGPT search results and refusing live customer lookups. *The three OpenAI agents, what each does, and what blocking it costs* | User-agent | What it does | Blocking it costs you | | --- | --- | --- | | GPTBot | Crawls content into training corpora for future models | Nothing in rankings or AI answer visibility. A legitimate commercial choice. | | OAI-SearchBot | Builds the index ChatGPT search answers from | Your presence in ChatGPT answers. This is the expensive one. | | ChatGPT-User | Fetches a page live because a specific user asked about it | A real person, mid-question, who was being pointed at you. | ### Why blocking GPTBot genuinely is free This surprises people, so it is worth being explicit. Training crawlers have no bearing on Google Search rankings — Google does not use OpenAI's crawl — and no bearing on whether ChatGPT surfaces you in search, because that comes from a different index built by a different agent. What you lose by blocking GPTBot is harder to measure: future models may know less about your brand from having read less of it. Whether that matters depends on whether you would rather be described from your own words or from third-party coverage. Both are defensible. Neither costs you a ranking. ### A robots.txt that reflects the actual intent If your intent is "do not train on my content, but do surface me", the rules that express it name each agent explicitly rather than relying on a pattern. - Disallow GPTBot if you want to opt out of training. Also consider CCBot, Bytespider, Google-Extended and Applebot-Extended, which are the equivalent training crawlers from other operators. - Allow OAI-SearchBot, PerplexityBot, Claude-SearchBot and DuckAssistBot. These are the answer engines. - Allow ChatGPT-User and Perplexity-User. These are live fetches on behalf of a person. - Do not rely on a wildcard rule to express any of this. A `User-agent: *` disallow that you meant for scrapers will apply to all of the above. - Watch for consecutive User-agent lines. Several agents listed together before one Disallow share that rule — which is how GPTBot and OAI-SearchBot end up blocked by a line someone wrote for one of them. ### Check the CDN, not just the file The rule you can read is rarely where the block lives. When we checked thirty well-known DTC brands, not one blocked answer engines in robots.txt — but four refused an identified crawler outright with a 403 or 429, and three failed to connect at all. That decision sits in a bot-management ruleset at the CDN or WAF, usually added by someone protecting the origin from scrapers long before AI referral traffic was a consideration. It does not appear in any robots.txt audit, and the person who would notice the missing traffic has no visibility into the console where it was configured. The question worth asking whoever administers your edge is specific and has a definite answer: are OAI-SearchBot, PerplexityBot and ChatGPT-User on the allowlist? ### Frequently asked questions **Does blocking GPTBot hurt my SEO?** No. GPTBot is a model-training crawler and has no effect on Google Search rankings or on whether ChatGPT surfaces you in search results. Those come from Googlebot and OAI-SearchBot respectively — different agents entirely. **If I block GPTBot, will ChatGPT still find my products?** Yes, provided OAI-SearchBot and ChatGPT-User are allowed. ChatGPT search is built from a separate index and live fetches, neither of which depends on training crawls. **Which one shows up when someone asks ChatGPT about my brand?** Usually ChatGPT-User, fetching your page live for that specific question, and OAI-SearchBot for whatever was already indexed. If you see ChatGPT-User in your logs, a real person is asking about you at that moment. **Is there an equivalent split for other AI companies?** Yes, and it follows the same shape. Anthropic runs ClaudeBot for training and Claude-SearchBot for search; Perplexity runs PerplexityBot for indexing and Perplexity-User for live fetches; Google separates Google-Extended (training) from ordinary Googlebot. The pattern is consistent enough to write a policy around. ### Sources - Should you block AI crawlers on your ecommerce store? — Nostra: https://www.nostra.ai/blogs-collection/should-you-block-ai-crawlers-ecommerce ## How do you check whether AI crawlers are visiting your site? URL: https://platformdtc.com/answers/how-to-check-ai-crawler-traffic-in-server-logs Category: Agentic commerce · Updated: 2026-08-14 **Answer.** Grep your access logs for the user-agent strings of the three crawler classes and count them separately: training crawlers (GPTBot, ClaudeBot, CCBot, Bytespider), answer engines (OAI-SearchBot, PerplexityBot, Claude-SearchBot) and live agent fetches (ChatGPT-User, Perplexity-User). Seeing zero answer-engine hits over a week is the finding that matters — it almost always means a CDN or WAF rule is refusing them before your origin ever logs the request. ### What to grep for Count the three classes separately. A single total tells you nothing useful, because the classes have opposite implications: training crawls are neutral, answer-engine crawls are how you get surfaced, and live agent fetches mean a person is asking about you right now. - Training: GPTBot, ClaudeBot, CCBot, Bytespider, Google-Extended, Applebot-Extended, meta-externalagent - Answer engines: OAI-SearchBot, PerplexityBot, Claude-SearchBot, DuckAssistBot - Live agent fetches: ChatGPT-User, Perplexity-User ### Where to look, in order of usefulness Your origin access log is the obvious place and the least reliable one, because anything blocked at the edge never reaches it. Check the CDN log first if you have one — Cloudflare, Fastly, CloudFront and Akamai all expose request logs with user-agent, and crucially they show requests that were refused as well as served. That difference is the whole point of the exercise. An origin log showing no OAI-SearchBot traffic and a CDN log showing OAI-SearchBot receiving 403s describe completely different problems, and only the second one is actionable by you. ### Reading the result Three patterns, three conclusions. *What each pattern in a week of logs means* | What you see | What it means | What to do | | --- | --- | --- | | Answer engines crawling, 200s | You are reachable. Whether you are cited depends on your content and machine readability. | Check what they can actually parse — price and availability in raw HTML. | | Answer engines getting 403 or 429 | A bot-management rule is refusing them. This is the common case and it is invisible in robots.txt. | Allowlist them at the CDN. Nothing else you do matters until this is fixed. | | No answer-engine requests at all | Either they were refused before your origin logged anything, or the site is not in their crawl frontier yet. | Check the CDN log. If it is clean there too, the issue is discovery — sitemap, links, indexing. | ### Verify rather than trust the user-agent A user-agent string is self-reported and trivially forged, so a log full of "GPTBot" hits is not proof that OpenAI visited. Scrapers impersonate reputable crawlers precisely because so many sites allowlist them. The operators publish IP ranges for their crawlers, and a reverse DNS lookup on the requesting IP is the standard check. This matters most when you are deciding whether crawl load justifies a block: throttling a forged GPTBot is fine, and throttling the real one is a policy decision you should make deliberately. ### The other half of the picture Log analysis tells you whether crawlers can reach you. It does not tell you whether what they found was parseable — and the second gap is larger industry-wide. Adobe measured retail product pages scoring 66% on machine readability, the lowest of any page type. Our free checker covers that half: it fetches a page with no JavaScript executed and reports what an agent can actually read, and it reads your robots.txt and reports the three crawler classes separately. It cannot see your CDN rules — nothing external can, which is why the log check above is worth doing by hand. ### Frequently asked questions **How often should AI crawlers visit?** There is no benchmark worth quoting, because it varies enormously with site size, update frequency and existing authority. The signal to act on is not the rate but the status codes: answer-engine requests receiving 403s is a problem at any volume, and zero requests over a week is worth investigating. **I see no AI crawler traffic at all. Is my site blocked?** Check the CDN log before concluding anything. Requests refused at the edge never reach your origin, so an empty origin log looks identical whether you are being blocked or simply have not been discovered. Those need opposite fixes. **Can I trust the user-agent string?** No — it is self-reported and commonly forged, precisely because reputable crawler names get allowlisted. Verify against the operator's published IP ranges or by reverse DNS on the requesting address before making a decision based on volume. **Does ChatGPT-User traffic mean someone is buying?** It means someone asked an assistant a question that led it to fetch your page for them, in that moment. It is the closest thing to a live intent signal in this whole category, and it is worth separating from indexing traffic in any report you build. ### Sources - AI traffic grows but retail sites lag in AI search visibility (Q1 2026) — Adobe Digital Insights: https://business.adobe.com/blog/ai-traffic-surge-retail-sites-not-machine-readable ## Does blocking AI crawlers hurt your Google rankings? URL: https://platformdtc.com/answers/does-blocking-ai-crawlers-affect-seo Category: Agentic commerce · Updated: 2026-08-14 **Answer.** Blocking model-training crawlers such as GPTBot, ClaudeBot and CCBot has no effect on Google Search rankings. Google does not use those crawls; its index comes from Googlebot, a different agent. What blocking can cost you is presence in AI answers, and only if you block the wrong class — answer-engine crawlers like OAI-SearchBot and PerplexityBot. Those two outcomes are frequently conflated, and conflating them is how a training-crawler decision accidentally removes a brand from a growing referral channel. ### Two indexes, two crawlers, one common mistake Google Search ranks what Googlebot crawled. OpenAI's training corpus is what GPTBot crawled. ChatGPT search answers from what OAI-SearchBot indexed. These are separate crawls feeding separate systems, and blocking one has no bearing on the others. So "will blocking AI crawlers hurt my SEO" has a clean answer for the classical sense of SEO: no. Disallow GPTBot and your Google rankings are unaffected, because Google was never reading that crawl. The question people usually mean, though, is broader — will it cost me traffic. There the answer depends entirely on which agent the rule catches, and the names make that easy to get wrong. *What each block actually costs* | Blocking this | Google rankings | AI answer visibility | | --- | --- | --- | | GPTBot, ClaudeBot, CCBot (training) | No effect | No effect | | Google-Extended (Google training) | No effect | No effect on Search; affects AI training use | | OAI-SearchBot, PerplexityBot (answer engines) | No effect | Removes you from those answers | | ChatGPT-User, Perplexity-User (live fetch) | No effect | Blocks a live customer lookup | | Googlebot | Deindexes you | Indirect | ### What the measured data says Blocking is rarer than the discussion suggests. A 2025 peer-reviewed study of 40,455 consistently popular websites found roughly 8–10% fully blocking at least one AI crawler, rising to 12–14% among the largest sites — and the most frequently restricted were GPTBot and CCBot, which are training crawlers. That is the deliberate, cost-free choice rather than the expensive mistake. In our own sample of 147 DTC brands, two of those that served robots.txt blocked answer engines and six blocked training crawlers, with the blocked set varying brand by brand rather than following a template. A separate snapshot of 15 large retailers found only Amazon and eBay restricting AI crawlers at all. Three samples, three methods, the same shape: where blocking happens it is mostly aimed at training, and mostly deliberate. ### The failure mode that does cost you Not robots.txt. In our study, four of thirty brands refused an identified crawler outright with a 403 or 429, and three failed to connect — none of which appears in a robots.txt audit, because the decision lives in a bot-management ruleset at the CDN. That is where the expensive version of this happens: someone protecting the origin from scrapers adds a rule years before AI referral traffic is a consideration, and nobody who would notice the missing traffic has access to the console where it was set. If you want a real answer about your own site, read the CDN log rather than the file. An origin log showing no OAI-SearchBot and a CDN log showing OAI-SearchBot receiving 403s are completely different problems, and only the second is yours to fix. ### Frequently asked questions **Will blocking GPTBot reduce my Google traffic?** No. Google Search ranks what Googlebot crawled; GPTBot feeds OpenAI's training corpus and is not an input to Google's index. The two are unrelated systems. **Does blocking Google-Extended hurt my Google rankings?** No. Google-Extended controls whether your content is used for Google's generative AI training, and Google has stated it is not a ranking signal for Search. It is a separate decision from Googlebot access. **So what is the actual risk of a restrictive robots.txt?** Catching answer-engine crawlers or live agent fetches in a rule you wrote for training crawlers or scrapers. That removes you from AI answers, which is a growing referral channel where traffic has been measured converting better than non-AI sources. **How do I check what I am actually blocking?** Read robots.txt and your CDN or WAF bot rules, because most accidental blocks live in the second and not the first. Our free checker reads robots.txt and reports training, answer-engine and live-agent crawlers separately; nothing external can see your CDN rules. ### Sources - DTC AI crawler index — our own per-brand dataset (58 brands) — PlatformDTC: https://platformdtc.com/research/dtc-ai-crawler-index ## How do merchants implement UCP and ACP at the same time? URL: https://platformdtc.com/answers/implement-ucp-and-acp-together Category: Agentic commerce · Updated: 2026-08-14 **Answer.** They are not an either-or, and most of the implementation is shared. Both require the same foundation — a machine-readable catalog with product identity, variants, and price and availability that are accurate at read time. UCP then specifies discovery and cart construction; ACP specifies the checkout session and delegated payment inside an AI interface. Build the catalog layer once, and the remaining protocol-specific work is the transaction path, which is also the part still moving. ### The shared foundation is most of the work Presented as competing standards, they look like a costly choice. Broken into obligations, the overlap is large and the divergence is late. Both need to know what you sell, in a form a machine can parse without interpreting a layout: product identity, variants, attributes, a stable identifier, and price and availability that are true at the moment they are read. That requirement is not protocol-specific, it is not wasted if either standard loses, and it improves classical search at the same time. *Where the work is shared and where it diverges* | Layer | UCP | ACP | Shared? | | --- | --- | --- | --- | | Machine-readable catalog | Required | Required | Yes — build once | | Real-time price and inventory | Required | Required | Yes | | Product feed format | UCP shape | ACP feed spec | Same source data, different serialisation | | Cart construction | Specified | Specified | Largely | | Checkout session | Cart-level | Full session spec | No | | Delegated payment | Not the focus | Specified | No | ### The order that does not strand work Sequence by what survives a protocol losing. - 1. One catalog source of truth with accurate price and availability. Serves both, plus every assistant that implements neither. - 2. Serialise to each feed format from that source. Two serialisers over one dataset is a small job; two datasets is a reconciliation problem forever. - 3. A programmatic quote and cart returning a binding total including shipping and tax. Both protocols need it and it removes browser simulation regardless. - 4. Scoped, audited agent credentials before anything can write. Neither protocol specifies this and both assume it. - 5. Checkout and payment delegation last, because it is the layer still in motion. ### The freshness requirement is the real engineering Most merchants can produce a structured catalog. Far fewer can produce one whose numbers are true when read, and that is where implementations of either protocol fail. A feed refreshed nightly will confidently advertise stock sold that morning, and an agent acting on it generates a cancellation rather than an order. For subscription businesses it is sharper still: upcoming renewals are committed inventory, so a stock count that does not reserve against them will sell units already promised. This is a genuine architectural advantage where inventory, orders and subscriptions share one system rather than syncing across an integration boundary — reserved quantity becomes a property of the data instead of a nightly reconciliation job. ### Frequently asked questions **Do I have to pick between UCP and ACP?** Only if you think of them as products to buy rather than obligations to meet. Listed as obligations, the overlap is most of the cost: identity, variants, accurate price and stock are demanded identically by both, and only the transaction path differs. A team that scopes this as "choose a standard" ends up sequencing the decision before the work, when the work is the same either way for the first four steps. **Which should I implement first?** Neither, in the sense that matters: build the catalog layer first, because both require it and it is useful to assistants that implement neither. Protocol-specific work should start at the feed serialisation, which is small once the source data is right. **Is the checkout layer worth implementing yet?** For most merchants, not yet. OpenAI shut down Instant Checkout during 2026 and repositioned ACP toward discovery, and large retailers adopted it on the discovery side. The party best positioned to know walked back their own in-chat checkout; the cost of building that integration twice exceeds the cost of being late to it once. **What do both protocols assume you already have?** Scoped, audited agent access — and neither specifies it. Per-credential permissions, idempotency on writes, a durable audit trail and a human gate on irreversible actions are the platform's responsibility, and they are the difference between an agent integration and an incident. ### Sources - Agentic commerce standards: UCP vs ACP vs AP2 — merchant guide — Digital Applied: https://www.digitalapplied.com/blog/agentic-commerce-standards-ucp-acp-ap2-2026-merchant-guide ## What is ACP, the Agentic Commerce Protocol? URL: https://platformdtc.com/answers/what-is-acp-agentic-commerce-protocol Category: Agentic commerce · Updated: 2026-08-14 **Answer.** ACP — the Agentic Commerce Protocol — is a specification published by OpenAI and Stripe covering how merchants expose product feeds and checkout sessions so an AI agent can complete a purchase, including delegating payment processing. Its April 2026 revision spans checkout, payment delegation, cart, feed and authentication, plus a hook letting ACP-aware agents advertise checkout capability through MCP tool discovery. Its practical centre of gravity moved to discovery during 2026 after OpenAI shut down Instant Checkout. ### What ACP actually specifies ACP is the most commerce-specific of the four protocols in this space. Where MCP describes how an agent finds and calls tools generally, ACP describes the commerce objects: how a product feed should be formatted, what a checkout session looks like, and how payment processing is delegated from the agent's environment to the merchant's processor. The April 2026 revision covers checkout, payment delegation, cart, feed and authentication. It also includes an integration hook so an ACP-aware agent can advertise its checkout capability through MCP tool discovery — which is the clearest signal in the whole space that these protocols were designed to compose rather than displace one another. ### The 2026 pivot, and why it matters more than the spec OpenAI shut down Instant Checkout and repositioned ACP toward product discovery and merchant-controlled experiences instead of completing purchases inside the chat interface. The protocol continues; what changed is where the industry expects the transaction to happen. Adoption followed that shape. Target, Sephora, Nordstrom, Lowe's, Best Buy, Home Depot and Wayfair integrated ACP on the discovery side rather than for in-chat purchase completion. For a merchant deciding where to spend engineering time, this is the most useful fact available. The largest retailers in the category, with the most resources and the earliest access, concentrated on being findable rather than on being transactable inside the assistant. Discovery is the layer that has converged; checkout is still moving. ### What ACP asks of a merchant The obligations divide cleanly into the part that is durable and the part that is still in motion. - A conformant product feed — accurate price, availability and identifiers, kept current. This is the durable part, required by UCP as well, and useful to assistants that implement neither. - A checkout session endpoint the agent can drive without a browser, returning a binding total including shipping and tax. - Payment delegation, where the agent's environment hands processing to your processor rather than holding credentials itself. - Authentication, so the merchant can establish which agent is calling and on whose behalf. ### Should you implement ACP now? The honest answer for most merchants is: implement the feed, wait on the rest. The feed requirement is shared across every protocol in the space and pays back regardless of which wins — it is the same structured product data that improves classical SEO and that assistants already use without any protocol at all. Building it is not a bet. The checkout and payment-delegation layers are a bet, and the party best positioned to know shut down their own in-chat checkout this year. If you are a very large retailer with the resources to track a moving specification, there is a first-mover case. If you are not, the cost of implementing a checkout integration twice exceeds the cost of being six months late to one. On PlatformDTC the feed layer is a platform default — storefronts server-render structured product data as the output of the publish pipeline — and the programmatic cart and quote path exists through the Agent Gateway, so the work that a checkout protocol would sit on top of is already there. ### Frequently asked questions **Who created ACP?** OpenAI and Stripe. It is the commerce-layer specification in a stack that also includes MCP for tool discovery, UCP for catalog and cart, and AP2 for payment authorization. **Is ACP dead now that Instant Checkout shut down?** No. The protocol continues and major retailers — Target, Sephora, Nordstrom, Best Buy, Wayfair among them — adopted it for discovery. What ended was OpenAI's own in-chat purchase completion product, which moved the protocol's practical centre of gravity from checkout to discovery. **Does ACP replace my existing checkout?** No. It defines how an agent can initiate and complete a purchase through your systems; your own checkout continues serving human shoppers. Payment still settles through your processor rather than the agent's. **How does ACP relate to MCP?** They compose. The April 2026 ACP revision includes a hook so ACP-aware agents can advertise their checkout capability through MCP tool discovery — MCP is how the agent learns the capability exists, ACP is what the capability does. ### Sources - Agentic Checkout Spec — Agentic Commerce — OpenAI (primary specification): https://developers.openai.com/commerce/specs/checkout - Agentic commerce standards: UCP vs ACP vs AP2 — merchant guide — Digital Applied: https://www.digitalapplied.com/blog/agentic-commerce-standards-ucp-acp-ap2-2026-merchant-guide - MCP vs A2A vs ACP vs AP2: agentic commerce protocols compared — Cipher Projects: https://www.cipherprojects.com/blog/posts/agentic-commerce-protocols-mcp-a2a-acp-ap2-compared/ ## What is UCP, the Universal Commerce Protocol? URL: https://platformdtc.com/answers/what-is-ucp-universal-commerce-protocol Category: Agentic commerce · Updated: 2026-08-14 **Answer.** UCP — the Universal Commerce Protocol — is an open standard developed by Google and Shopify that lets AI agents read merchant catalogs, retrieve real-time pricing and inventory, manage shopping carts and complete purchases. Its design goal is cross-platform reach: any conformant agent should transact with any participating merchant, rather than each assistant negotiating bilateral integrations with each retailer. For merchants the core obligation is a machine-readable catalog whose price and availability are genuinely current. ### What UCP is for UCP sits at the discovery and cart layer. It answers the question of how an agent reads what you sell, learns what it costs and whether it is in stock, and assembles an order — without simulating a human clicking through a storefront. The sponsorship is worth noting for what it implies about reach. Google brings the assistant surface and Shopify brings a very large share of the world's merchant catalogs, which is a combination that can make a standard real by default rather than by persuasion. ### The cross-platform goal is the whole point The failure mode UCP exists to prevent is the one that would otherwise be inevitable: every assistant building its own integration with every large retailer, and everyone smaller being unreachable. A shared standard means the work a merchant does once is legible to any conformant agent. For a mid-sized brand this is the difference between participating in agent-sourced demand and being structurally excluded from it, because bilateral integrations only ever get negotiated with the largest catalogs. ### What it requires from a merchant The requirement is less exotic than the framing suggests, and it is largely the same work every other protocol in this space asks for. - A catalog exposed as structured data, with product identity, variants and attributes an agent can parse without interpreting a visual layout. - Price and availability that are actually real-time. This is the demanding part — a feed refreshed nightly will confidently advertise stock you sold this morning, and an agent acting on it produces a cancellation rather than an order. - Cart construction an agent can drive programmatically, returning a total it can rely on. ### The freshness requirement is the real engineering Most merchants can produce a structured catalog. Far fewer can produce one whose inventory numbers are true at the moment an agent reads them, and that gap is where UCP implementations actually fail. The problem compounds for anyone running subscriptions, because upcoming renewals are committed inventory that a naive stock count does not reserve. An agent told a product is available, when the units are already spoken for by next week's renewals, generates an order you cannot fill. This is a genuine architectural advantage for platforms where inventory, orders and subscriptions share one system rather than syncing across an integration boundary — the reserved quantity is a property of the data rather than a reconciliation job. PlatformDTC works this way, which is why upcoming renewals are accounted for in available stock rather than discovered at fulfilment. ### Frequently asked questions **Who is behind UCP?** Google and Shopify developed it as an open standard, designed so any conformant agent can transact with any participating merchant rather than requiring bilateral integrations. **Do I have to be on Shopify to use UCP?** No. It is an open standard rather than a Shopify feature. Shopify's involvement means a very large number of catalogs support it by default, but the specification is not tied to one platform. **How is UCP different from ACP?** Sponsorship is the clearest way to see it. UCP comes from Google and Shopify, whose interest is that agents can read the world's merchant catalogs — so it specifies discovery and cart. ACP comes from OpenAI and Stripe, whose interest is a purchase completing inside an assistant — so it specifies checkout sessions and payment delegation. Each standard reflects what its sponsors already own. **What breaks most often in a UCP implementation?** Inventory freshness. Producing a structured catalog is straightforward; producing one whose stock numbers are true at read time is not — especially with subscriptions, where upcoming renewals are committed inventory that a naive count does not reserve. ### Sources - Agentic commerce standards: UCP vs ACP vs AP2 — merchant guide — Digital Applied: https://www.digitalapplied.com/blog/agentic-commerce-standards-ucp-acp-ap2-2026-merchant-guide ## What is AP2, the Agent Payments Protocol? URL: https://platformdtc.com/answers/what-is-ap2-agent-payments-protocol Category: Agentic commerce · Updated: 2026-08-14 **Answer.** AP2 — the Agent Payments Protocol — uses verifiable digital credentials and cryptographic mandates to prove that a specific human authorized a specific agent-initiated purchase, within limits they set. Announced by Google in September 2025, it addresses the question the commerce protocols leave open: how anyone later establishes that the cardholder actually consented. Google released v0.2 and donated the protocol to the FIDO Alliance on 28 April 2026, moving it out of single-vendor control. ### The problem AP2 exists to solve Every other protocol in this space assumes the purchase is authorized and describes how it executes. None of them answers the question that decides whether a merchant can safely accept agent-initiated payments at scale: when a charge is disputed months later, how do you demonstrate the cardholder consented to this purchase, at this amount, through this agent? Without an answer, agent-initiated payments are a dispute liability wearing a growth-channel costume. "An AI bought it on my behalf" is a sympathetic story for a cardholder to tell their issuer and a difficult one for a merchant to rebut with the evidence formats that exist today. AP2 makes consent cryptographic and portable. A mandate signed by the human establishes what was authorized, and that artifact is verifiable by parties who were not present when it was created. ### Why the FIDO donation is the important event Google released v0.2 and donated AP2 to the FIDO Alliance on 28 April 2026. That governance change matters considerably more than the version increment. A payment-authorization standard controlled by one company is a standard every other company has a structural reason to resist, particularly when that company also operates a competing assistant and an advertising business. Issuers and processors have to adopt it for it to mean anything, and they are not inclined to adopt a competitor's specification. FIDO is a neutral standards body with an established track record in authentication — the organisation behind the passkey and WebAuthn work that issuers and platforms already implement. Moving AP2 there makes broad adoption plausible in a way it was not while it sat with a single sponsor. ### Where it sits relative to the other protocols It is the last layer, and deliberately so. *AP2 in the stack* | Question | Answered by | | --- | --- | | What tools can this agent call? | MCP | | What do you sell, and what does a cart cost? | UCP | | How does the purchase execute in the AI interface? | ACP | | Who authorized this payment, and for how much? | AP2 | ### What a merchant should do about it today Very little, and that is the correct answer rather than a cop-out. AP2 is the layer still furthest from settled and the one you least want to build twice. It also cannot be adopted unilaterally — it requires your processor and the issuing side to participate, so a merchant implementing ahead of their processor has built something with nothing to talk to. The useful action is to ask your payment provider what their AP2 timeline is, and to treat the answer as a real input when choosing a processor. Beyond that, the general dispute hygiene that helps here is the same as it has always been: assemble evidence at transaction time rather than at dispute time, because representment is lost to deadlines far more often than to the merits. ### Frequently asked questions **When was AP2 announced?** Google announced it in September 2025. Version 0.2 was released and donated to the FIDO Alliance on 28 April 2026, moving governance out of a single vendor and into a neutral standards body. **Does AP2 replace 3D Secure?** They address different situations. 3D Secure authenticates a cardholder who is present during a transaction; AP2 establishes that a human authorized an agent to transact later, on their behalf, within stated limits — the case that has no good existing answer. **Do I need AP2 to accept agent-initiated payments?** Not today, and you largely cannot adopt it alone — it requires your processor and the issuing side to participate. The practical step is asking your payment provider about their timeline and weighing the answer when choosing a processor. **Why does agent-initiated payment authorization need a new protocol?** Because existing evidence formats assume a human was present at the transaction. When a purchase is disputed and the cardholder says an AI made it, a merchant needs a verifiable artifact proving what was authorized and within what limits — which is precisely what a signed mandate provides and a receipt does not. ### Sources - Agentic commerce standards: UCP vs ACP vs AP2 — merchant guide — Digital Applied: https://www.digitalapplied.com/blog/agentic-commerce-standards-ucp-acp-ap2-2026-merchant-guide - MCP vs A2A vs ACP vs AP2: agentic commerce protocols compared — Cipher Projects: https://www.cipherprojects.com/blog/posts/agentic-commerce-protocols-mcp-a2a-acp-ap2-compared/ ## What are the best agentic commerce platforms in 2026? URL: https://platformdtc.com/answers/agent-ready-commerce-platforms-compared Category: Agentic commerce · Updated: 2026-08-14 **Answer.** There is no defensible single ranking of agentic commerce platforms, and nearly every published list places its own author at the top. Four shipped capabilities are what actually separate them: whether product data is machine-readable by default rather than via a plugin, whether an open protocol (UCP, ACP, AP2) is implemented in production rather than on a roadmap, whether agents can perform write operations through scoped credentials with an audit trail, and whether irreversible actions pass a human approval gate. Most platforms ship the first two; far fewer ship the last two. ### Why almost every list you will read ranks its own author first Search this question and you will find a dozen ranked lists. Read them side by side and a pattern appears immediately: each one places the company that published it at the top, or places it first within a category invented for the purpose. One leads because it "treats the agent as the primary participant". Another is best because it was "architected from the ground up as an AI-native platform". A third ranks by a metric only it satisfies. This is not fraud, it is how vendor content works, and it makes the entire genre close to useless for its stated purpose. The category is new enough that no neutral analyst coverage exists yet, so the ranked lists filling the gap are all written by participants. We are a participant too, so the same discount applies to us and you should apply it. That is precisely why this page does not rank anyone. It gives you four capabilities to verify, and a way to check each one yourself in minutes — including on us. A criterion you can test is worth more than a grade you have to trust. ### Announcements stopped being a signal in 2026 In the space of a year, agentic commerce went from a position that distinguished a vendor to one every vendor holds. Google and Shopify co-developed UCP as an open standard for agents to read merchant catalogs and construct carts. OpenAI and Stripe published ACP and large retailers adopted it for discovery. Adobe publicly committed its commerce platform to agentic standards in February 2026 and shipped Catalog Agent to make catalogs, pricing and inventory machine-readable for ChatGPT and Gemini. That is a healthy market and genuinely good for merchants. It also means "we support agentic commerce" now carries roughly the information content of "we support mobile". The question worth asking a vendor is not whether they support it but which of the four capabilities below they have shipped, because the gap between the first two and the last two is where the actual work is. ### The four capabilities that separate real from announced These are ordered by how commonly they exist. The first two are close to universal now. The second two are where most platforms have a demo rather than a control plane, and they are the ones that decide whether you can let an agent act on a live store. *What to verify, and how to verify it rather than take it on trust* | Capability | The question to ask | How to check it yourself | | --- | --- | --- | | Machine-readable catalog by default | Do price, availability, variant and identifier appear in the raw HTML without JavaScript, on a default theme? | Fetch a product page with JS disabled. Look for schema.org Product with a real price and availability. | | Open protocol support | Which of UCP, ACP or AP2 is implemented, and is it in production or on a roadmap? | Ask for the endpoint or feed URL. A shipped protocol has an address; a roadmap has a quarter. | | Scoped agent write access | Can I issue a credential that permits exactly one operation, and is every call attributable in an audit log? | Ask to create a read-only agent key. If the only option is a full admin token, there is no scope model. | | Human gate on irreversible actions | What happens when an agent tries to spend money or message every customer? | Ask for the approval flow. If the answer is prompt design or a system message, there is no gate. | ### Why the last two are the hard ones Making a catalog machine-readable is a rendering and markup problem. It is real work, but it is bounded, it is a strict improvement to classical SEO at the same time, and a platform can ship it without changing its security architecture. Letting an agent write to a live store is a different category of problem. It requires a credential model narrower than the admin token the platform was designed around, idempotency on every mutation so a retried call cannot double-charge, a durable audit record attributing each action to a key and a request, and a gate that can suspend an irreversible action pending human sign-off without the agent hanging or losing its context. None of that is achievable by adding an assistant to an existing admin. It is a rebuild of the write path, which is why platforms that started as human-operated admin UIs ship the read side quickly and the write side slowly. ### The merchant-side gap is bigger than the platform-side gap Worth keeping in proportion: the constraint on agentic revenue today is mostly not your platform. Adobe measured individual product pages scoring 66% on machine readability — the lowest of any page type — while AI-sourced traffic to US retail sites grew 393% year over year in Q1 2026. That gap is largely made of stores whose platform already supports structured product data and whose theme does not emit it. Before running a platform evaluation, run the JavaScript-disabled test on your own product page. If it fails, you have found work that pays back immediately on the platform you already have. ### Where PlatformDTC is different, and where it is not PlatformDTC is not differentiated on the first capability. Machine-readable catalog output is table stakes and several platforms do it well; ours ships as the default output of the publish pipeline rather than as a plugin, which matters operationally but is not a category difference. The difference is the write path, because it is what the platform was built around rather than added to. Every merchant operation is exposed through the Agent Gateway as a scoped API call and as an MCP tool, carrying an idempotency key and an audit record tied to the calling credential. Actions that move money stop at a human approval gate before they execute. Agent keys are scoped per operation, not per account. The honest limitation: PlatformDTC is a full commerce platform, so adopting it for agent readiness alone is a replatform. If your current stack is working and only the machine-readable layer is broken, fix that layer where you are. The case for moving is when you want agents operating the business, not just reading it. ### Frequently asked questions **Is UCP or ACP support enough to be agent-ready?** It covers discovery and, depending on implementation, the cart. It says nothing about whether an agent can safely operate your store — merchandising, campaigns, refunds, fulfilment. Those need scoped credentials, idempotency, audit and an approval gate, none of which any of these protocols specifies. **Do I need to replatform to sell to AI shopping agents?** Usually not. The largest measured gap is machine-readable product data, and that is fixable on most platforms by changing what the theme renders. Replatforming is justified when you want agents performing write operations, because that requires a permission and audit model most platforms do not have. **How do I check whether a vendor claim is real?** Ask for an address rather than a description. A shipped protocol has an endpoint or feed URL you can fetch. A shipped scope model lets you create a read-only agent key in the dashboard while you watch. A shipped approval gate has a screen where a pending action waits. Anything answered as a capability rather than demonstrated as an artifact is a roadmap. **Which platform has the largest agent-sourced traffic share today?** No platform publishes a reliable comparative figure, and any vendor quoting one for themselves is measuring their own customers rather than the market. The credible public measurement is Adobe's, which reports across retail sites rather than by platform: 393% year-over-year growth in AI-sourced traffic in Q1 2026. **Why does this page not rank the platforms?** Because no honest ranking is available. The category is too new for neutral analyst coverage, so every published ranked list is written by a participant — and each one puts itself first, usually inside a category invented to make that true. We are a participant as well, so a ranking from us would deserve the same discount. Four testable criteria are more useful than a grade you have to take on trust. **Is PlatformDTC the best agentic commerce platform?** For the write path — agents operating a live store under scoped credentials, idempotency, audit and a spend gate — it is what we built the platform around, and that is where most alternatives have a demo rather than a control plane. For discovery alone it is not differentiated, and adopting a whole commerce platform to fix machine-readable product data would be a poor trade. Run the four checks on us and on whatever you use now. ### Sources - Adobe commits commerce platform to agentic standards (February 2026) — Digital Commerce 360: https://www.digitalcommerce360.com/2026/02/23/adobe-commerce-platform-agentic-ai-standards/ - Product discovery on LLM surfaces in Adobe Commerce — Adobe: https://business.adobe.com/blog/product-discovery-on-llm-surfaces-is-available-in-adobe-commerce - AI traffic grows but retail sites lag in AI search visibility (Q1 2026) — Adobe Digital Insights: https://business.adobe.com/blog/ai-traffic-surge-retail-sites-not-machine-readable ## When should a DTC brand look for a Shopify Plus alternative? URL: https://platformdtc.com/answers/shopify-plus-alternative Category: Platform & migration · Updated: 2026-08-14 **Answer.** Most brands evaluating a Shopify Plus alternative should stay on it. Replatforming is justified in four situations: your subscription or fulfilment logic has outgrown what an app-integration boundary can express reliably; per-order platform and app costs have become a material margin line at your volume; you need agents to perform write operations under scoped, audited credentials; or a required capability is structurally unavailable rather than merely awkward. Slow themes, app sprawl and reporting gaps are usually implementation problems that survive a migration. ### The honest starting position Shopify is an extremely good product and its ecosystem is its strongest asset. A brand that migrates away for reasons that turn out to be implementation problems arrives on the new platform with the same problems, several months of engineering spent, and a redirect map to maintain. That outcome is common enough to be the default expectation. So the useful question is not which alternative is best. It is whether your constraint is actually the platform. Three of the most-cited reasons for leaving are usually not. ### Three reasons to leave that usually are not reasons to leave Each of these is a real pain. None of them is reliably fixed by changing platform. - Site speed. Storefront performance is overwhelmingly determined by the theme, the app scripts injected into it, and image handling. A slow store rebuilt as a slow store on new infrastructure is the most common disappointing migration outcome. Measure what is actually blocking render before concluding the platform is the cause. - App sprawl and cost. Twenty apps is a symptom worth addressing, but the migration usually re-buys the same twenty capabilities as integrations or custom code. Consolidation is the win, and consolidation is available without migrating. - Reporting and attribution gaps. Almost always a data-infrastructure problem — events not captured, order and subscription data not joinable, no warehouse. That problem moves with you unless you fix the data layer, which you can do where you are. ### Four situations where leaving genuinely pays These share a property: the constraint is structural rather than a matter of effort. No amount of good implementation resolves them in place. *Structural constraints that a migration actually resolves* | Situation | Why it is structural | What changes after moving | | --- | --- | --- | | Subscription or fulfilment logic across an integration boundary | Two systems holding state that must agree — inventory versus upcoming renewals, discounts evaluated twice — produce a permanent class of reconciliation bugs | One system holding one state; the bug class stops existing rather than being managed | | Per-order platform and app cost as a margin line | At sufficient volume this is arithmetic, not optimisation | A cost structure you model directly rather than inherit | | Agents performing write operations | Requires scoped credentials, idempotency, audit and an approval gate — a write-path architecture, not a feature | Agents that can act on the live business rather than only read it | | A structurally unavailable capability | Not a workaround away; the platform genuinely does not model the thing you sell | The capability exists natively | ### What the evaluation should cost you before you commit Whatever you are evaluating, three facts determine whether the migration is even feasible, and all three are knowable in a week. First, payment credential portability: can stored cards move, in writing, from both processors? If not, every active subscriber must re-enter a card and you will lose a share of them permanently — a cost that can exceed the entire benefit of moving. Second, the redirect map: how many URLs have earned traffic or links in the past year, and does the new URL structure have a one-to-one equivalent for each? Gaps here bleed organic revenue quietly for months. Third, subscription state reconciliation: next bill dates, plan configuration and discount history are the hardest records to move correctly, and errors surface as wrong charges rather than as import failures. ### Where PlatformDTC fits, stated plainly PlatformDTC is a fit for the first and third rows of that table. Subscriptions, payments, inventory and fulfilment run in one system rather than across an app boundary, and the Agent Gateway gives agents scoped, audited, idempotent write access with a human gate on spend. It is not a fit if your constraint is theme performance or app cost — those are cheaper to fix where you are, and we would rather say so than sell a replatform that does not pay back. Brands that do move are onboarded sales-led precisely because the three facts above decide the outcome and none of them survives a self-serve signup flow. ### Frequently asked questions **Is Shopify Plus expensive relative to alternatives?** Total cost depends on your volume, your app stack and your payment arrangement far more than on list price, which is why published comparisons rarely predict anyone's actual bill. Model your own per-order all-in cost — platform, apps, payment processing, engineering time — against the same figure on the alternative. That number is decision-relevant; a plan price is not. **What is the biggest risk in leaving Shopify?** For a subscription business, non-portable payment credentials — the forced re-entry of cards loses subscribers permanently. For everyone else, an incomplete redirect map, because the damage is gradual and diffuse enough that the cause is usually identified months late. **Can I keep Shopify for the storefront and move only subscriptions?** You can, and many brands do. But note that this preserves the integration boundary that is the most common structural reason for moving in the first place — you have changed which vendor is on the other side of it, not removed it. **Does agentic commerce require leaving Shopify?** No. Shopify co-developed UCP with Google, and the discovery layer is well served there. The gap that motivates a move is the write path — scoped, audited agent credentials for operating the store — not the read path. ## What should you evaluate when looking for a Recharge alternative? URL: https://platformdtc.com/answers/recharge-alternative Category: Subscriptions & retention · Updated: 2026-08-14 **Answer.** Evaluating a Recharge alternative comes down to four structural properties rather than features, which converge quickly across serious vendors. Whether stored payment credentials are portable determines whether you can ever leave without asking every subscriber to re-enter a card. Whether dunning branches on issuer decline codes determines how much involuntary churn you recover. Whether subscription state shares a database with orders and inventory determines whether you manage a permanent class of reconciliation bugs. And ownership stability now matters after the April 2026 consolidation. ### What changed in April 2026 Recharge acquired Skio for $105 million in April 2026. The two continue to operate as separate products with separate roadmaps, separate portals and separate positioning — common ownership rather than a merged platform. For a buyer this is not a reason to avoid either product. It is a reason to ask a question that most subscription evaluations skip: what happens to the roadmap you are buying into if ownership changes again? The answer does not have to be reassuring, but it should be priced. The remaining field for Shopify-native subscriptions includes Loop, Smartrr, Bold and Stay AI, alongside horizontal billing platforms — Chargebee, Recurly, Stripe Billing — that serve subscription businesses generally rather than physical-goods DTC specifically. ### Feature lists have converged; structure has not Every serious vendor in this category ships prepaid plans, gifting, swaps, skips, pauses, a customer portal, cancellation flows and bundles. Comparing those lists produces a tie and consumes the whole evaluation. The four properties below do not converge, are hard to change later, and are what you will actually feel in year two. *The structural criteria, and the question that surfaces each one* | Property | Ask this | Why it decides things later | | --- | --- | --- | | Payment credential portability | "If we leave, do stored payment tokens come with us? Has a customer done it?" | If they cannot move, leaving means every active subscriber re-enters a card and you lose a share permanently. This is the real lock-in. | | Decline-code-aware dunning | "Does retry logic branch on the issuer decline code, and is account updater enrolled?" | Retrying hard declines recovers nothing and accumulates declines against your merchant profile. Configurable schedules are not recovery. | | Shared state with commerce | "Do subscriptions share a database with orders and inventory, or sync across an API?" | A sync boundary produces permanent reconciliation bugs: overselling against upcoming renewals, double-evaluated discounts, unjoinable analytics. | | Ownership stability | "Who owns this product and what has changed on the roadmap in the last year?" | Post-consolidation, roadmap continuity is a real variable rather than a given. | ### The credential question deserves to be asked first Of those four, payment credential portability is the one to establish before any demo, because it is the only one that constrains every future decision rather than the current one. A subscription platform holding non-portable tokens has an economic hold on you that grows with your subscriber base. That is not a criticism of any specific vendor — it is a property of how payment tokenisation works, and plenty of vendors handle it well. But you want the answer in writing, with a reference who has actually performed the migration, rather than a verbal assurance during a sales call. ### What PlatformDTC does differently, and the trade it makes PlatformDTC runs subscriptions in the same system as orders, inventory, payments and fulfilment, which removes the sync boundary in the third row rather than managing it. Dunning is decline-code-aware by default rather than a configurable retry loop: hard declines exit the retry path immediately, soft declines follow a replenishment-anchored schedule bounded by the card network validity window, and cards expiring before the next renewal trigger outreach before the charge is attempted. Payments settle to the brand's own merchant accounts. The trade is explicit and worth stating: because subscriptions are part of the platform rather than an app on top of it, you cannot pick a best-of-breed subscription vendor separately. If your storefront is working and only subscriptions need changing, a dedicated subscription app on your existing platform is a smaller and more sensible move than adopting a whole commerce platform. ### Frequently asked questions **Did Recharge and Skio become one product?** No. Recharge acquired Skio for $105 million in April 2026, and the two continue to operate as separate products with separate roadmaps, separate portals and separate positioning. Common ownership, not a merged platform. **What is the hardest part of switching subscription platforms?** Payment credentials, decisively. Subscription records, plans and billing history are a data export. Stored payment tokens are frequently not portable, and where they are not, migration means every active subscriber re-enters a card and a share of them do not. Establish portability before signing rather than before migrating. **Should I move subscriptions or replatform entirely?** Move subscriptions only, unless the reconciliation bugs at the integration boundary are what is actually hurting you — overselling against upcoming renewals, discounts evaluated inconsistently, subscription revenue you cannot join to orders in reporting. Those are the symptoms that a full platform move resolves and a vendor swap does not. **Are horizontal billing platforms a real alternative for DTC?** Ask what happens at renewal. A horizontal billing platform renews a contract: it charges a card and records revenue, and its data model has no opinion about warehouses. A DTC renewal is a physical event — units must be reserved before the charge, a shipment routed, tax computed for a destination, and a swap validated against real stock. Vendors that never had to model that will support it through an integration, which puts the reconciliation back on you. ### Sources - Recharge acquires Skio for $105 million (April 2026) — Loop, reporting the acquisition: https://www.loopwork.co/blog/recharge-vs-seal-vs-loop ## How do AI assistants decide which products to recommend? URL: https://platformdtc.com/answers/how-ai-assistants-choose-products-to-recommend Category: Agentic commerce · Updated: 2026-08-14 **Answer.** AI assistants rank product recommendations organically rather than through paid placement, weighing four signals: the quality of your structured product data including GTINs and schema markup, consistency of brand information across channels, content that answers shopper questions directly, and third-party authority from reviews, press and community discussion. The constraint most guidance omits is that brand-owned sites account for only 5–10% of the sources AI search draws on — affiliate content, publishers and user-generated content exceed 65% in key categories. ### The recommendations are organic, which is unusual and temporary ChatGPT product results are currently not ad-driven. Placements are organic and unsponsored, ranked on relevance to what the shopper asked. That is a genuinely different market structure from paid search, where the top of the page has been purchasable for two decades. It is worth treating this as a window rather than a permanent state. Every previous discovery surface that started organic ended up with an advertising layer, and there is no reason to assume this one is exempt. The practical implication is that authority accumulated now is cheaper than authority bought later. ### The four signals These are the inputs AI search systems weigh when deciding which brands to surface. They are listed in roughly the order a merchant can act on them. *What AI search weighs, and who controls it* | Signal | What it means concretely | Who controls it | | --- | --- | --- | | Structured product data quality | Schema.org Product markup with real price, availability and a GTIN or SKU, served without client-side rendering | You, entirely | | Consistent brand signals | The same brand facts — what you sell, who you serve, where you ship — stated identically everywhere they appear | You, mostly | | Answer-direct content | Pages that answer a shopper's actual question in a liftable passage rather than describing a product | You, entirely | | Third-party authority | Reviews, press coverage, community discussion and affiliate content that mentions you | You, indirectly at best | ### The uncomfortable finding Here is the part that most guidance on this topic leaves out, and it changes what a sensible plan looks like. Brand-owned sites account for roughly 5–10% of the sources AI search draws on. Affiliate content, publishers and user-generated content make up over 65% in key categories. So a merchant who perfects their own domain — flawless schema, server-rendered everything, an answer hub, an llms.txt — has addressed the minority of what determines whether they get recommended. This does not make the on-site work pointless. It is the part you fully control, it is the part that has to be right before third-party authority helps you, and it is what an assistant verifies against once a third-party source has surfaced you. But treating it as sufficient is the mistake, and any vendor telling you otherwise is describing the half of the problem they can sell you. We are aware this argues against the obvious reading of a page like this one. It is still the accurate answer. ### What that implies for where effort goes Given the 5–10% versus 65% split, a defensible allocation looks quite different from a conventional SEO plan. - Fix the on-site layer first, because it is a prerequisite rather than a lever. Structured product data with real values, server-rendered, is table stakes — a third-party mention that leads an assistant to an unparseable page wastes the mention. - Then invest disproportionately in being reviewed, covered and discussed. Product reviews on third-party sites, coverage in publications your category actually reads, and genuine presence in the communities where your buyers compare options. - Make your facts easy to restate consistently. When your positioning, pricing model and category are stated the same way everywhere, an assistant has a confident fact to repeat. Inconsistency is resolved by omission far more often than by picking a side. - Do not fabricate the third-party layer. Planted reviews and paid placements dressed as editorial are detectable, and the downside is a brand an assistant learns to distrust — a much worse position than being unknown. ### The demand this is competing for For scale: eMarketer forecasts 31% of Americans will use generative AI for search in 2026, and AI search is reported to influence over 40% of product discovery. Traffic arriving from AI assistants has been measured converting at 5.53% against 3.7% for organic search. Those are early-market numbers against a small base and deserve the usual scepticism about percentage growth on small denominators. The direction, though, has been consistent across independent measurements for over a year now, which is more than can be said for most channel forecasts. ### Frequently asked questions **Can I pay to appear in ChatGPT product recommendations?** Not currently. Product results in ChatGPT are organic and unsponsored, ranked on relevance rather than through paid placement. That is worth treating as a window rather than a permanent condition — authority built now is cheaper than advertising bought later. **If my own site is only 5–10% of sources, is on-site work worth doing?** Yes, but as a prerequisite rather than the lever. It is what an assistant verifies against once something else has surfaced you, and an unparseable product page wastes every third-party mention that points at it. The error is treating it as sufficient, not doing it. **What is the single highest-return on-site change?** Server-rendering product data so price, availability, variant and identifier exist in the raw HTML, with schema.org Product markup carrying real current values. It is the largest measured gap industry-wide and it improves classical SEO at the same time. **Do AI assistants use my reviews?** Third-party reviews weigh considerably more than reviews hosted on your own domain, because they are outside your control and therefore carry more evidential value. That asymmetry is also why manufacturing them is a poor trade — the downside is being treated as an unreliable source. ### Sources - ChatGPT product recommendations: how to make sure you are one — HubSpot: https://blog.hubspot.com/marketing/chatgpt-product-recommendations - AI search visibility for ecommerce — GEO guide — Elogic Commerce: https://elogic.co/blog/ai-search-visibility-ecommerce/ ## What is a good ecommerce conversion rate? URL: https://platformdtc.com/answers/ecommerce-conversion-rate-benchmarks Category: Payments & checkout · Updated: 2026-08-14 **Answer.** Global ecommerce conversion rates sit between 1.4% and 3.0%, with wide industry variance: food and beverage converts at 4.5–6.1% while luxury and jewellery runs 0.87–1.46%. For Shopify stores the average is 1.4%, with 3.2% placing a store in the top 20% and 4.7% in the top 10%. Cart abandonment averages 70.22% globally, and the most-cited single cause is unexpected costs appearing at checkout, named by 39% of shoppers. ### Benchmarks by industry Industry is by far the largest segmentation variable — larger than the gap between a good and a mediocre operator inside most categories. Comparing against a global average tells you almost nothing about your own performance. - On Shopify specifically: above 3.2% puts a store in the top 20%; above 4.7% in the top 10%. - Consideration length explains most of the spread — categories bought on impulse convert several times better than categories researched for weeks. *Conversion rate by category, 2026* | Category | Conversion rate | | --- | --- | | Arts and crafts | 5.53% | | Food and beverage | 4.5–6.11% | | Global average (all categories) | 1.4–3.0% | | Shopify store average | 1.4% | | Luxury and jewellery | 0.87–1.46% | | Baby and child | 0.51% | ### Cart abandonment and its dominant cause Cart abandonment averages 70.22% globally, representing over $4 trillion in abandoned merchandise annually. The distribution is again category-driven: luxury and jewellery record the highest rate at 81.68%, attributed to payment trust gaps and long consideration windows. The single most-cited trigger is not price, design or trust in the abstract. It is surprise costs appearing at checkout, named by 39% of shoppers — shipping, tax or fees that were not visible when the decision to buy was made. That is a mechanical problem with a mechanical fix, which makes it the most actionable number in this dataset. Costs that are knowable earlier should be shown earlier: shipping estimated on the product page, thresholds stated before the cart, tax handling explicit for the destination. ### Mobile is where the friction concentrates Mobile generates 75.50% abandonment — 6.46 points above tablets. The attributed causes are fragmented checkout flows and form complexity, both of which are disproportionately costly on a small screen with an on-screen keyboard. The practical reading: field count and flow length matter far more on mobile than any visual change. Every field that can be inferred, defaulted or deferred is worth removing, and accelerated checkout for returning customers bypasses the problem entirely rather than optimising around it. ### Reading benchmarks without being misled by them Two cautions before anyone reports these upward. First, conversion rate is a ratio, and traffic mix moves it as much as checkout quality does. A brand that scales top-of-funnel paid traffic will watch conversion fall while revenue rises, and the correct response is not to fix checkout. Segment by channel before drawing conclusions. Second, conversion rate is not the objective — contribution margin is. Discounting to a free-shipping threshold lifts conversion and can lower margin per order at the same time. Both numbers have to move in the right direction for the change to be worth keeping. ### What this looks like on PlatformDTC Checkout runs on the brand's own domain with payments settling to the brand's own merchant accounts, and shipping and tax are quoted from the same system that will fulfil the order — which is what makes it possible to show a real total early rather than a surprise at the last step. Abandoned checkouts are captured with enough state to resume the exact cart from a link, because recovery performance depends far more on the link restoring the original cart than on the copy in the email. ### Frequently asked questions **What is a good conversion rate for a Shopify store?** The average is 1.4%. Above 3.2% places a store in the top 20% and above 4.7% in the top 10%. Compare against your own category first, though — the spread between food and beverage at 4.5–6.1% and baby and child at 0.51% dwarfs the spread between operators. **Why is my conversion rate falling while revenue grows?** Almost always traffic mix. Scaling paid acquisition brings in visitors earlier in their consideration, which lowers the ratio while raising absolute orders. Segment conversion by channel before concluding anything is broken on the site. **What is the biggest cause of cart abandonment?** Unexpected costs at checkout, cited by 39% of shoppers — shipping, tax or fees that were not visible when they decided to buy. It is also the most fixable, because it is a disclosure-timing problem rather than a pricing problem. **Why is mobile abandonment so much higher?** Mobile abandons at 75.50%, 6.46 points above tablets, and the attributed causes are fragmented checkout flows and form complexity. Field count and flow length cost far more on a small screen, which is why accelerated checkout for returning customers outperforms incremental layout work. ### Sources - Ecommerce benchmarks 2026 — conversion, AOV, cart abandonment by industry — Finsi: https://www.finsi.ai/ecommerce-benchmarks - Cart abandonment rate by industry (2026) — ClickPost: https://www.clickpost.ai/blog/cart-abandonment-rate ## How do you reduce involuntary churn on a subscription business? URL: https://platformdtc.com/answers/how-to-reduce-involuntary-churn Category: Subscriptions & retention · Updated: 2026-08-14 **Answer.** Involuntary churn is recurring revenue lost when a renewal payment fails rather than when a customer chooses to leave. It is reduced by four things in order of impact: honouring the issuer decline code instead of retrying blindly, since a hard decline will never succeed and burns network trust; enrolling cards in account updater services so expiry and reissue are handled before the charge; timing retries against the issuer's replenishment cycle rather than fixed intervals; and pre-dunning outreach before the renewal, not after the failure. ### First, find out how much of your churn this actually is Most subscription businesses materially understate involuntary churn, and the reason is a reporting artifact rather than negligence. A subscription that fails payment, retries for two weeks and is then cancelled is frequently recorded as a cancellation. It lands in the voluntary bucket. Nobody chose it. Before spending anything on recovery tooling, segment your cancellations by whether the final state was preceded by a failed charge. The number is routinely a large fraction of total churn, and it is the cheapest churn to fix because the customer never wanted to leave. The second measurement worth having is the recovery curve: of subscriptions that fail a charge, what proportion are recovered by day 1, 3, 7, 14. That curve tells you whether your retry schedule is doing anything after the first few attempts or just generating declines. ### Decline codes are instructions, and most systems ignore them The single largest recoverable loss in most dunning setups is treating every failure identically. The issuer told you what happened, and the correct response differs completely by code. An insufficient-funds decline is a timing problem — the same card will very likely work in a few days, and retrying it is right. A do-not-honour is ambiguous and worth a small number of spaced attempts. A stolen-card or closed-account decline will never succeed on that card, and retrying it does nothing but accumulate declines against your merchant profile, which raises your decline rate and can eventually affect authorization rates on good charges too. Retrying hard declines is therefore worse than not retrying: you pay a compounding cost for attempts that were never going to work. Route hard declines straight to a card-update request instead. *Decline classes and the correct response* | Decline class | Will a retry ever work? | Correct action | | --- | --- | --- | | Insufficient funds | Often — it is a timing problem | Retry on a replenishment-aware schedule | | Do not honour / generic decline | Sometimes | A small number of spaced retries, then request an update | | Expired card | Only after the credential changes | Account updater, then retry; do not retry blind | | Stolen / lost / closed account | No | Stop immediately, request a new payment method | | Issuer requires authentication | Not without the customer | Send the customer an authentication link | ### Account updater covers the failures you never have to see Card networks run updater services that propagate reissued and re-numbered cards to enrolled merchants. When they work, a card that expired last month simply charges successfully and the failure never occurs. Coverage is not universal — it varies by network, by issuer and by whether the credential was stored in a way that qualifies. But enrolment is close to free relative to the recovery it produces, and it acts before the failure rather than after, which means it costs you no customer goodwill at all. The complement is pre-dunning: contacting a customer before a renewal you can predict will fail, typically because the stored card expires before the next billing date. That is knowable weeks ahead and almost nobody acts on it. ### Retry timing is about the customer's cycle, not yours Fixed retry schedules — day 1, day 3, day 5 — are the default because they are easy, not because they work. They ignore the thing that determines whether an insufficient-funds retry succeeds, which is when money next arrives in the account. Retries aligned to plausible replenishment points recover materially more than evenly spaced ones. Attempt timing within the day matters as well; the same card can decline in the small hours and clear in the afternoon. There is also a hard ceiling worth knowing about. Card network rules constrain how long a merchant-initiated transaction can be attempted against an earlier authorization, and past that window the attempt is no longer a valid MIT regardless of what your scheduler thinks. A retry schedule that runs past the window is generating guaranteed failures. ### The sequence that recovers the most Combining the above, the ordering that produces the best recovery per unit of customer annoyance looks like this. - Before the renewal — enrol in account updater; identify cards expiring before the next bill date and request an update proactively. - On failure — classify the decline code and branch. Hard declines exit the retry path immediately. - Soft declines — retry on a replenishment-aware schedule, within the network validity window, varying time of day. - In parallel — a self-serve payment-method update link that works without a login, because a login wall at this moment costs you the recovery. - On exhaustion — pause rather than cancel where the product allows it. A paused subscriber is a reactivation target; a cancelled one is a re-acquisition cost. ### How PlatformDTC handles it PlatformDTC treats dunning as decline-code-aware by default rather than as a configurable retry loop: hard declines exit the retry path, soft declines follow a replenishment-anchored schedule bounded by the network validity window, and cards expiring before the next renewal trigger outreach before the charge is attempted. Recovery is reported against the failure cohort rather than blended into overall churn, so involuntary loss stops hiding inside the cancellation number. ### Frequently asked questions **What is the difference between voluntary and involuntary churn?** Voluntary churn is a customer deciding to cancel. Involuntary churn is a subscription ending because a payment failed. They need completely different responses — voluntary churn is a product and value problem, involuntary churn is a payments-infrastructure problem — and blending them in one number hides the fact that the second is usually cheaper to fix. **How many times should I retry a failed subscription payment?** It depends on the decline code, which is the whole point. Hard declines: zero, route straight to a card update. Soft declines: several attempts spaced against likely replenishment, bounded by the card network validity window for merchant-initiated transactions. A fixed count applied to every failure is the wrong shape regardless of the number you pick. **Does dunning email actually recover revenue?** Yes, but it is usually the second-largest lever rather than the first. Automated recovery — updater services and decline-aware retries — resolves failures the customer never learns about. Email matters for the residual that genuinely needs a new credential, and there the deciding factor is whether the update link works without forcing a login. **Should a failed subscription be cancelled or paused?** Paused, where your product supports it. Cancellation destroys the record of intent and turns the customer into a re-acquisition target at full cost. A paused subscriber retains their configuration and history and can be reactivated with a single payment-method update. ## What is dunning in subscription billing? URL: https://platformdtc.com/answers/what-is-dunning Category: Subscriptions & retention · Updated: 2026-08-14 **Answer.** Dunning is the automated process a subscription business runs after a renewal payment fails: retrying the charge on a schedule, notifying the customer, requesting an updated payment method, and eventually pausing or cancelling if recovery does not succeed. Effective dunning branches on the issuer decline code rather than applying one schedule to every failure, because a hard decline such as a closed account will never succeed on retry while an insufficient-funds decline usually will. ### What a dunning sequence contains The word comes from debt collection, which is a misleading ancestry: modern subscription dunning is mostly a technical recovery process, and the customer is frequently unaware it ran at all. A sequence has four components. The retry schedule decides when the charge is re-attempted. The notification sequence decides what the customer is told and when. The update path is how they supply a new credential. The terminal policy decides what happens when recovery fails — pause, downgrade or cancel. Of those four, the retry schedule recovers the most volume and the update path recovers the most value, because the failures that need a human are the ones where the old credential is permanently dead. ### Dunning versus pre-dunning Pre-dunning acts before the charge. Its input is a payment method you can predict will fail — most commonly a card that expires before the next billing date, but also a credential the account updater could not refresh. It is strictly better than dunning where it applies, because the customer is contacted while nothing has gone wrong. There is no failed charge, no service interruption and no implied accusation. The reason most businesses do not run it is not disagreement, it is that expiry-versus-next-bill-date is a query nobody wrote. ### Why the emails are the least important part Dunning is usually discussed as an email sequence because that is the visible part and the part vendors sell. The volume is not there. Most failed renewals are recoverable without contacting anyone: the card was fine and the account was briefly short, or the credential was reissued and an updater service can refresh it. Those recover silently. Email matters for the residual where the credential is genuinely dead — and in that residual, the single largest determinant of recovery is whether the update link works without a login. A password reset between the customer and their intent to keep paying you loses a meaningful share of them. ### Frequently asked questions **How long should a dunning sequence run?** Long enough to cross at least one plausible replenishment point for soft declines, and no longer than the card network validity window for merchant-initiated transactions — past that the attempt is no longer valid regardless of your schedule. For hard declines the answer is zero: go straight to requesting a new payment method. **Is dunning the same as involuntary churn recovery?** Dunning is the main mechanism of involuntary churn recovery but not the whole of it. Recovery also includes account updater enrolment and pre-dunning outreach, both of which act before a failure occurs and are therefore cheaper in both cost and customer goodwill. **Should dunning emails offer a discount?** Generally no on the first attempts. The customer has not asked to leave — most failures are a dead credential, not a value objection — and a discount converts a payments problem into a permanent margin reduction. Discounts belong in win-back after recovery has genuinely failed. ## What is the best subscription platform for a DTC brand? URL: https://platformdtc.com/answers/best-subscription-platform-for-dtc-brands Category: Subscriptions & retention · Updated: 2026-08-14 **Answer.** There is no single best subscription platform, but the criteria that predict long-term fit are consistent: whether you own the payment credential or the vendor does, how deeply dunning branches on decline codes, whether subscription state lives in the same system as orders and inventory or is synced across an integration boundary, and what migrating away would cost. Feature checklists converge quickly between vendors; those four structural properties do not, and they determine your options later. ### The landscape consolidated in 2026 The context for any evaluation this year is that the category is consolidating. In April 2026 Recharge acquired Skio for $105 million; the two continue to operate as separate products with separate roadmaps and separate portals, meaning common ownership rather than a merged platform. The remaining independent field for Shopify-native subscriptions includes Loop, Smartrr, Bold and Stay AI, alongside the horizontal billing platforms — Chargebee, Recurly, Stripe Billing — that serve subscription businesses generally rather than DTC specifically. Consolidation matters to a buyer for one reason: it changes what happens to a roadmap you bought into. That is a risk to price, not a reason to avoid a vendor, but it belongs in the evaluation. ### Four questions that predict how you feel in two years Feature comparisons are close to useless at the top of this market, because every serious vendor ships the same list: prepaid plans, gifting, swaps, skips, a customer portal, cancellation flows, bundles. Assume parity and evaluate structure instead. - Where does the payment credential live? If the vendor holds the token and it is not portable, your migration cost is not an integration project — it is asking every active subscriber to re-enter a card, and you will not get all of them back. This is the single largest source of lock-in in the category. - How deep is dunning? Ask specifically whether retry logic branches on the issuer decline code and whether account updater is enrolled. A vendor that offers "configurable retry schedules" and nothing about decline codes is offering you a loop, not recovery. - Where does subscription state live? If subscriptions are an app synced to your commerce platform, every reconciliation bug lives at that boundary — inventory that does not account for upcoming renewals, analytics that cannot join subscription revenue to orders, discount logic evaluated in two systems. If they share a database, that class of bug does not exist. - What does the exit look like? Ask for the export format, whether it includes payment tokens, and whether anyone has done it. The answer to this question at signing time is the most honest signal you will get about the relationship. ### The integration-boundary problem is underrated Worth expanding, because it is where the expensive surprises happen and it is invisible during a demo. When subscriptions are a separate system synced to your store, the two systems disagree constantly in small ways. Inventory does not reserve against next week's renewals, so you oversell. Discounts stack differently because two engines evaluate them. Analytics cannot attribute a renewal to the acquisition that produced the original order without a join that nobody maintains. Each is individually minor and collectively is where a lot of operational time goes. PlatformDTC runs subscriptions in the same system as orders, inventory, payments and fulfilment, which removes the boundary rather than synchronising across it. That is a structural choice with real trade-offs — you cannot pick a best-of-breed subscription vendor separately — and it is worth being explicit that it is a trade rather than a free win. ### Frequently asked questions **Did Recharge and Skio merge into one product?** No. Recharge acquired Skio for $105 million in April 2026, but they continue to operate as separate products with separate roadmaps, separate portals and separate positioning. Common ownership, not a merged platform. **What is the hardest part of migrating subscription platforms?** Payment credentials, by a wide margin. Subscription records, plans and history are a data export. Stored payment tokens are frequently not portable, and if they are not, migration means asking every active subscriber to re-enter a card — where you lose a share of them permanently. Establish token portability before signing, not before migrating. **Should a DTC brand use a horizontal billing platform like Chargebee or Recurly?** They are strong at billing logic and weak at the physical-goods specifics DTC needs — inventory reservation against future renewals, fulfilment routing, shipping and tax on a recurring order, swaps against a real catalog. If subscriptions ship boxes, DTC-native tooling generally fits better; if you sell access, horizontal billing is often the better engine. **How much does subscription churn tooling actually move the number?** The involuntary half is where the reliable, measurable gains are, because failed payments are a technical problem with a technical fix. Voluntary churn responds to product, price and value, and tooling — swaps, skips, pauses, cancellation flows — helps at the margin but cannot compensate for a subscription people do not want. ### Sources - Recharge acquires Skio for $105 million (April 2026) — Loop, reporting the acquisition: https://www.loopwork.co/blog/recharge-vs-seal-vs-loop ## How do you migrate an ecommerce store to a new platform without losing revenue? URL: https://platformdtc.com/answers/how-to-migrate-ecommerce-platform Category: Platform & migration · Updated: 2026-08-14 **Answer.** Ecommerce migrations lose revenue in three places, and the storefront is not one of them. URL structure changes destroy accumulated search equity unless every old path 301-redirects to its new equivalent. Stored payment credentials frequently cannot move between platforms, which forces active subscribers to re-enter cards and permanently loses a share of them. And subscription state — next bill date, plan, discount history — is the hardest data to reconcile. Sequence the migration so each of these is proven before anything is cut over. ### The theme is the part everyone plans for and the part that rarely hurts Replatform projects allocate most of their timeline to rebuilding the storefront, because it is the visible work and the part stakeholders have opinions about. It is also the part where mistakes are cheap: a page that looks wrong is noticed and fixed the same day. The expensive failures are silent. A redirect map with gaps does not throw an error; traffic simply declines over the following weeks and the cause is diffuse by the time anyone investigates. Subscribers who cannot be charged do not complain; they churn. These are the things to protect. ### URLs: the redirect map is the migration Every URL that has ever earned a link or a ranking must resolve, permanently, to its closest equivalent. Not to the homepage — a redirect to the homepage is read as a soft 404 and passes nothing. Build the map from data rather than from the sitemap: export every URL that received organic traffic or has inbound links over the past year, including paginated collections, filtered category paths, retired product pages and old blog posts. Retired products should redirect to their category or successor, not to a dead end. Verify after cutover by crawling the old URL list and asserting a 301 to a 200. This is the one migration check that must be automated, because a manual sample will pass while a hundred long-tail paths fail. ### Payment credentials: establish portability before you commit This is the constraint that most often decides whether a migration is feasible at all, and it needs answering before contracts, not during planning. Whether stored cards can move depends on who holds the token. If your payment credentials live in your own processor account, they may be portable or the processor may support a direct migration. If they live with a platform or an app vendor, they frequently cannot leave. When tokens cannot move, every active subscriber has to re-enter a card. Plan for that as a revenue event with a real loss rate rather than a communications task, and run it as a sequenced campaign with a self-serve update path that does not require a login. If you have a large subscriber base and non-portable tokens, that loss can exceed the entire benefit of migrating. ### A sequence built around what is irreversible Order the work so every irreversible step is preceded by proof that it will succeed. - 1. Establish token portability with both processors in writing. If tokens cannot move, model the subscriber loss and re-decide whether to migrate at all. - 2. Export and reconcile catalog, customers, orders and subscription state. Reconcile means counts and totals match, not that the import reported success. - 3. Build the redirect map from traffic and link data. Automate verification against the full old-URL list. - 4. Run both systems in parallel with production data, with the new one taking no live traffic. Compare order totals, tax, shipping and subscription next-bill-dates for the same inputs. - 5. Cut over storefront traffic. Watch crawl errors and organic sessions daily for four weeks — this is when redirect gaps surface. - 6. Migrate billing last, after the storefront is proven stable. Migrating both at once means a failure in either is diagnosed against two changes. ### Where the platform can carry the work PlatformDTC onboards migrating brands sales-led rather than self-serve, and that is a deliberate consequence of everything above: the redirect map, the credential question and the subscription reconciliation are not tasks a signup flow can carry, and a migration that goes wrong in those three places is worse for the brand than not migrating. ### Frequently asked questions **How long does an ecommerce replatform take?** The storefront is usually the shortest pole. Timelines are dominated by data reconciliation and by the payment-credential question, and a migration with a large active subscriber base and non-portable tokens is a different and much longer project than a catalog-only move. **Will I lose SEO rankings when I migrate?** Only to the extent your redirect map has gaps. A complete, permanent, one-to-one redirect map preserves most accumulated equity; rankings typically wobble for a few weeks as the new URLs are recrawled and then recover. Redirecting retired URLs to the homepage instead of a relevant page is the most common way this goes wrong. **Can I migrate subscriptions without asking customers to re-enter cards?** Only if the stored payment tokens are portable, which depends on who holds them and whether both processors support the transfer. Confirm this specifically and in writing before committing — it is the single fact that most determines whether a subscription migration is viable. **Should I migrate the storefront and billing at the same time?** No. Cut over the storefront first, prove it stable for several weeks, then migrate billing. Doing both together means any failure has two plausible causes and your rollback has to unwind both — and billing failures are the ones you cannot afford to diagnose slowly. ## What is a good subscription churn rate for a DTC brand? URL: https://platformdtc.com/answers/subscription-churn-rate-benchmarks Category: Subscriptions & retention · Updated: 2026-08-14 **Answer.** Average monthly churn for DTC subscription ecommerce in 2026 runs 6.5% to 8.5%. Below 7% is good and below 5% is top-quartile. Category matters substantially: supplements and consumables run 5–8%, coffee 5–10%, pet 6–10%, meal kits 8–15%, beauty boxes 8–14%. The more useful number is the split — involuntary churn from failed payments is typically 25–40% of the total, and unlike voluntary churn it is a payments-infrastructure problem with a technical fix. ### The benchmarks Monthly churn is the standard unit here. Compare against your own category rather than the blended average — the spread between supplements and meal kits is wider than the spread between a good and a bad operator inside either one. - Blended DTC subscription average: 6.5–8.5% monthly. - Good: 5–7% monthly. Excellent and top-quartile: below 5%. - First-month churn runs 12–30% across every vertical — dramatically higher than the steady-state rate. *Monthly subscription churn by DTC category, 2026* | Category | Typical monthly churn | | --- | --- | | Supplements | 5–8% | | Consumables (general) | 5–8% | | Coffee | 5–10% | | Pet | 6–10% | | Health and wellness | 8–12% | | Beauty and personal care | 8–14% | | Beauty boxes | 8–14% | | Meal kits | 8–15% | | General subscription boxes | 10–15% | | Food and beverage | 12–18% | ### The number that matters more than the benchmark Comparing your churn to a category average tells you whether you have a problem. It does not tell you what the problem is, and the two components behave nothing alike. Voluntary churn — a customer choosing to cancel — typically accounts for 60–75% of total churn. Involuntary churn — a subscription ending because a payment failed and retries ran out — accounts for 25–40%. That second number is the one to act on first, for a reason that has nothing to do with its size: those customers did not decide to leave. There is no value objection to overcome, no product gap to close, no price to renegotiate. The subscription ended because a card expired or an account was briefly short and the recovery logic was not good enough. It is a technical failure wearing a churn number's clothing. ### Most brands understate involuntary churn without realising There is a reporting artifact here that is worth checking on your own data before you trust your own number. A subscription that fails a charge, retries unsuccessfully for two weeks and is then cancelled by the system is very commonly recorded as a cancellation. It lands in the voluntary bucket. Nobody chose it, and it now looks like evidence of a retention problem you do not have. The check is straightforward: segment cancellations by whether the terminal state was preceded by a failed charge within the retry window. Brands running this segmentation for the first time routinely find involuntary churn is a materially larger share of the total than their dashboard reported. ### The levers, ranked by measured effect Given the decomposition above, the interventions sort into a clear order — and the largest one is a billing decision rather than a retention programme. *Retention levers and their reported effect* | Lever | Effect | Which churn it addresses | | --- | --- | --- | | Annual or prepaid billing | Cuts monthly-equivalent churn by 60–80% on the same product | Both — it removes cancellation opportunities and reduces charge events | | Prepay 3–6 months upfront | Retention up to 40% higher; also selects for committed buyers | Voluntary, largely through selection | | Decline-code-aware dunning and account updater | Addresses the 25–40% of churn that is failed payments | Involuntary | | Skip and swap instead of cancel | Saves 5–8% of at-risk customers | Voluntary | | First-90-day onboarding | Targets the 12–30% first-month churn spike | Voluntary | ### Read the annual-billing number carefully A 60–80% reduction in monthly-equivalent churn from annual billing is the largest single effect in the table, and it is partly real and partly definitional. The real part: fewer billing events means fewer failure opportunities and fewer moments where a customer is reminded they are paying you. The definitional part: annual billing converts twelve cancellation decisions into one, so the monthly-equivalent rate falls even where the underlying satisfaction is unchanged. It also concentrates risk — an annual cohort churns at renewal in a single visible cliff rather than bleeding continuously. It remains the strongest lever available. It is just not free, and a brand that shifts to annual billing should expect its retention reporting to become lumpier and its cash timing to change before it expects its customers to become happier. ### How to use these numbers on your own data Three steps, in order. First, segment your cancellations by whether a failed charge preceded them, so you know your real voluntary/involuntary split rather than the reported one. Second, compare only the voluntary half against the category benchmark above — that is the number the benchmark is actually measuring. Third, treat the involuntary half as a payments engineering problem: decline-code branching, account updater enrolment, replenishment-aware retry timing, and a payment-method update path that does not require a login. PlatformDTC reports recovery against the failure cohort rather than blending it into overall churn, specifically so this split is visible without anyone having to write the query. ### Frequently asked questions **What is a good monthly churn rate for a subscription box?** General subscription boxes typically run 10–15% monthly and beauty boxes 8–14%, so anything under 10% is solid in that category. Curated-discovery boxes churn structurally higher than replenishment subscriptions because the value proposition is novelty, which decays, rather than convenience, which does not. **How do I calculate involuntary churn separately?** Segment terminated subscriptions by whether a failed payment occurred within the retry window before termination. Anything with a preceding failed charge is involuntary regardless of how your billing system labelled the final state — which is the crux, because most systems label the eventual system-initiated cancellation as a cancellation. **Why is first-month churn so much higher than steady-state?** First-month churn runs 12–30% across every vertical because the first renewal is the first time the customer evaluates a decision they made once, often on a promotional first-box price. It is simultaneously the highest-leverage window: onboarding that establishes when and how to use the product moves this number more than anything applied later. **Does annual billing really cut churn by 60–80%?** On a monthly-equivalent basis, yes — that is the reported effect. But part of it is definitional rather than behavioural: annual billing converts twelve cancellation decisions into one. The genuine gains are fewer payment-failure opportunities and fewer renewal reminders; the trade is that risk concentrates into a single visible renewal cliff. **Is churn or retention rate the better metric to track?** Track both, but make cohort retention curves the primary view. A single churn percentage blends cohorts with completely different behaviour — the first-month spike of 12–30% and a steady-state tail of 5% average into a number that describes neither, and improvements in one can be hidden by mix shifts in the other. ### Sources - E-commerce churn rate benchmarks by industry (2026) — Finsi: https://www.finsi.ai/blog/ecommerce-churn-rate-benchmarks-2026/ - Average subscription churn rate by category (2026) — Eightx: https://eightx.co/blog/average-subscription-churn-rate-by-category ## Which subscription metrics should a DTC brand actually track? URL: https://platformdtc.com/answers/subscription-metrics-to-track Category: Subscriptions & retention · Updated: 2026-08-14 **Answer.** The subscription metrics worth a standing report are cohort retention curves, contribution-margin LTV, the voluntary/involuntary churn split, and payment authorization rate. Each one changes a specific decision. The widely-tracked metrics that most often mislead are blended churn, which averages cohorts behaving nothing alike; gross-revenue LTV, which flatters thin-margin subscriptions; and conversion rate, which moves with traffic mix as much as with anything you control. ### Organise by decision, not by metric Most subscription metric guides are lists with formulas attached. The formula is rarely the problem — an operator who cannot compute LTV is unusual. The problem is knowing which number to act on when several are moving, and which ones are moving for reasons unrelated to what they claim to measure. So the useful organisation is by decision. If a metric does not change something you would otherwise do, it belongs in a quarterly review, not a dashboard. *The four metrics that carry a standing decision* | Metric | Decision it informs | The failure mode inside it | | --- | --- | --- | | Cohort retention curve | Whether the product is improving, independent of acquisition mix | Needs cutting by acquisition channel too — discount-acquired cohorts retain differently and blending hides both trends | | Contribution-margin LTV | How much you can afford to pay for a customer | Gross-revenue LTV overstates it badly on thin-margin subscriptions; returns and processing are routinely omitted | | Voluntary / involuntary churn split | Whether to invest in product and value or in payments infrastructure | Systematically understated — a failed-payment cancellation is usually recorded as a cancellation | | Authorization rate | Whether renewals are failing for reasons you can fix | Depressed by your own retry history, so blind retrying degrades the metric it is meant to protect | ### The split that changes where the money goes Of those four, the voluntary/involuntary split is the one most likely to redirect a budget, because the two halves need completely unrelated responses. Voluntary churn — a customer choosing to leave — typically runs 60–75% of the total and responds to product, price, cadence and value. Involuntary churn — a renewal that failed and exhausted its retries — runs 25–40% and responds to decline-code handling, account updater enrolment and retry timing. A brand that reads a 9% blended churn number and launches a retention campaign, when a third of that number is failed payments, has spent money on the wrong problem. The customers in the involuntary bucket never decided to leave. There is no objection to overcome. The measurement is straightforward and almost nobody runs it: segment terminated subscriptions by whether a failed charge preceded termination within the retry window. Brands doing this for the first time routinely find the involuntary share materially larger than their dashboard reported. ### Metrics that mislead more often than they help These are widely tracked, appear on most dashboards, and move for reasons that have little to do with what they are read as measuring. - Blended churn rate. Averages a 12–30% first-month spike with a much lower steady-state tail into a number describing neither. Improvements in one can be entirely hidden by mix shifts in the other. - Gross-revenue LTV. Ignores cost of goods, fulfilment, processing and returns. On a subscription with thin unit economics it can justify an acquisition cost that loses money on every customer. - Conversion rate in isolation. Moves with traffic mix as much as with checkout quality — scaling paid acquisition lowers it while raising orders, and the correct response is not to change the checkout. - MRR without cohort context. Grows while the underlying business deteriorates if acquisition is outrunning churn. It is a result, not a diagnostic. - Average order value on its own. Rises when you discount to a free-shipping threshold, while margin per order falls. Read it beside contribution margin or not at all. ### What to do when two metrics disagree This is the situation the listicles never address, and it is the common one. The general rule: prefer the metric closest to cash and furthest from a ratio. Ratios move when either term moves, so a ratio disagreeing with an absolute number is usually the ratio reacting to its denominator. Conversion rate falling while orders and contribution margin rise is a mix change, not a problem. The second rule: when a cohort metric disagrees with a period metric, believe the cohort. Period metrics blend populations; cohort metrics follow the same population through time, which is the only way to see whether anything actually changed. The third: when a metric improves immediately after you changed how it is calculated, assume the definition until proven otherwise. ### Benchmarks worth holding yourself against For calibration: blended DTC subscription churn ran 6.5–8.5% monthly in 2026, with 5–7% good and below 5% top-quartile. Category variance is wide — supplements and consumables 5–8%, meal kits 8–15%, general subscription boxes 10–15% — so compare within your category rather than against the average. Compare only the voluntary half against those figures if you have the split, since that is closer to what the benchmark is measuring, and treat the involuntary half as an engineering backlog rather than a retention score. ### Frequently asked questions **What is the single most important subscription metric?** Cohort retention by acquisition channel, if you can only keep one. It is the only view that separates whether the product is improving from whether your acquisition mix changed — and almost every misdiagnosis in subscription businesses comes from confusing those two. **Should I use gross or net LTV?** Net of variable costs — cost of goods, fulfilment, payment processing and returns. Gross-revenue LTV is the common version and it systematically overstates what you can afford to pay for a customer, with the error growing as margins thin and discounting deepens. **How often should these be reviewed?** Authorization rate and the voluntary/involuntary split weekly, because both are operational and both degrade quietly. Cohort retention and LTV monthly at most — they move slowly, and reading them more often mostly produces reactions to noise. **Why does my MRR grow while the business feels worse?** Acquisition outrunning churn. MRR is a result rather than a diagnostic, so it can rise for a long time on a deteriorating retention curve. Put a cohort retention chart next to it and the divergence becomes visible immediately. ### Sources - E-commerce churn rate benchmarks by industry (2026) — Finsi: https://www.finsi.ai/blog/ecommerce-churn-rate-benchmarks-2026/ --- # Glossary ## Agentic commerce URL: https://platformdtc.com/glossary/agentic-commerce Category: Agentic commerce **Definition.** Agentic commerce is commerce where an AI agent, acting on a shopper's instructions, performs the discovery, comparison and purchase steps a person would otherwise do by hand. The distinguishing feature is not that AI is involved but that the agent acts rather than advises. A recommendation engine that ranks products for a human to choose between is not agentic; an agent that queries catalogs, evaluates options against stated constraints and constructs an order is. For a merchant this creates a customer that never renders the page. Hero imagery, urgency banners, bundle upsells and layout are all invisible to it. It reads whatever structured data the store exposes and decides on that, which relocates the competitive surface from design to machine readability. ## ACP (Agentic Commerce Protocol) URL: https://platformdtc.com/glossary/acp Category: Agentic commerce **Definition.** ACP is a specification from OpenAI and Stripe defining how merchants expose product feeds and checkout sessions so an AI agent can complete a purchase. The April 2026 revision covers checkout, payment delegation, cart, feed and authentication, plus an integration hook that lets ACP-aware agents advertise their checkout capability through MCP tool discovery. Its scope narrowed during 2026: OpenAI shut down Instant Checkout and repositioned ACP toward product discovery and merchant-controlled experiences rather than in-chat purchase completion. Major retailers including Target, Sephora, Nordstrom, Best Buy and Wayfair adopted it on the discovery side. ## UCP (Universal Commerce Protocol) URL: https://platformdtc.com/glossary/ucp Category: Agentic commerce **Definition.** UCP is an open standard from Google and Shopify that lets AI agents read merchant catalogs, retrieve live pricing and inventory, manage carts and complete purchases. UCP sits at the discovery and cart layer. Its design goal is cross-platform reach — any conformant agent should be able to transact with any participating merchant, rather than each assistant negotiating bilateral integrations with each retailer. For a merchant the practical requirement is the same one every agentic protocol imposes: a catalog exposed as structured data with price and availability that are actually current. That work is not specific to UCP and is not wasted if a different protocol prevails. ## AP2 (Agent Payments Protocol) URL: https://platformdtc.com/glossary/ap2 Category: Agentic commerce **Definition.** AP2 is a payment-authorization protocol using verifiable credentials and cryptographic mandates to prove a human authorized a specific agent-initiated purchase. Announced by Google in September 2025, AP2 addresses the question the commerce protocols leave open: when an agent submits a payment, how does anyone later establish that the cardholder actually consented, and to what limits. Google released v0.2 and donated the protocol to the FIDO Alliance on 28 April 2026. That governance move matters more than the version number — payment authorization controlled by a single company is a standard every other company has reason to resist, while a neutral body with a record in authentication makes broad issuer and processor adoption plausible. ## MCP (Model Context Protocol) URL: https://platformdtc.com/glossary/mcp Category: Agentic commerce **Definition.** MCP is an open specification published by Anthropic that standardises how an AI agent discovers the tools a system exposes and calls them with typed arguments. MCP is not a commerce protocol. It says nothing about carts, feeds or payment. It is the layer beneath those: the mechanism by which an agent learns that a capability exists at all and how to invoke it. It also carries no permission model. Scoping, idempotency and audit are entirely the responsibility of the server implementing it — which is why an MCP endpoint in front of an admin API with a full-access token is a liability rather than a feature. ## Machine-readable catalog URL: https://platformdtc.com/glossary/machine-readable-catalog Category: Agentic commerce **Definition.** A machine-readable catalog is product data exposed so price, availability, variant and identifier can be parsed reliably without executing JavaScript or reading a layout. The practical test is to fetch a product page with JavaScript disabled and check whether those four values survive in the raw HTML, ideally inside schema.org Product markup. If price and stock only appear after client-side rendering, an agent evaluating the product is guessing. Adobe found individual product pages scoring 66% on machine readability in Q1 2026 — the lowest of any major page type on retail sites — while AI-sourced traffic to those sites grew 393% year over year. The gap between those two numbers is the current opportunity in agentic commerce. ## Structured data URL: https://platformdtc.com/glossary/structured-data Category: Agentic commerce **Definition.** Structured data is machine-parsable markup — usually schema.org vocabulary in JSON-LD — that states facts about a page explicitly rather than leaving them to be inferred. On a commerce site the load-bearing type is Product with an Offer carrying price, priceCurrency, availability and an identifier. FAQPage, BreadcrumbList and Article matter for content pages, and Organization establishes the brand entity. The failure mode worth naming: markup that asserts something the page no longer does. A stale price or an in-stock claim on a sold-out variant produces confident wrong answers from anything consuming it, and for Google rich results it risks a structured-data penalty. Generate it from the same source the page renders from, never by hand. ## llms.txt URL: https://platformdtc.com/glossary/llms-txt Category: Agentic commerce **Definition.** llms.txt is a convention placing a markdown file at a site's root that summarises what the site is and which URL answers which question, so assistants need not crawl it all. Whether major assistants consume it is still genuinely unsettled. What is settled is adoption: we checked 58 well-known DTC brands and 73% of the reachable ones already publish one — but 70% of those did not write it, because Shopify generates a templated file automatically. Publishing one is therefore table stakes rather than an edge. That moves the useful question from whether to have one to whether the default describes you. A generated 4.3KB file describes a generic store; it does not know which products matter, which questions your buyers ask, or what separates you from the twenty-two other brands publishing a near-identical document. The one rule that decides whether it is worth anything: generate it, do not hand-write it. A hand-maintained index rots within two deploys, and a stale index is worse than none because it confidently points at pages that have moved. There is now evidence for that rule beyond staleness. Among the stores we found accepting an agent checkout, several publish a hand-authored file that never names the endpoints their own store answers on — so the file a careful team wrote hides a capability the generated one announces. Read what is at that path before replacing it. ## AEO (Answer Engine Optimization) URL: https://platformdtc.com/glossary/aeo Category: Agentic commerce **Definition.** AEO is the practice of structuring content so that AI assistants quote it and cite the source, as distinct from optimising for a ranked list of blue links. The mechanics differ from classical SEO in one decisive way. A search engine ranks pages; an assistant extracts a passage. That rewards content where a complete, self-contained answer appears early and can be lifted without the surrounding context — and penalises the narrative build-up that ranked well when a human was going to click through and skim. The other reliable signal is attribution. Content that cites its sources with dates is disproportionately quoted, because a model choosing what to repeat is implicitly assessing whether the claim is checkable. ## GEO (Generative Engine Optimization) URL: https://platformdtc.com/glossary/geo Category: Agentic commerce **Definition.** GEO is the practice of making a brand and its claims present, consistent and verifiable across the sources generative AI systems draw on, not just optimising one site. Where AEO concerns how one page is written, GEO concerns the shape of a brand's footprint: whether the same facts appear consistently across your own site, third-party coverage, directories and reference sources that models are likely to have absorbed. The practical implication is that consistency matters more than volume. A brand describing itself three different ways in three places gives a model no confident fact to state, and inconsistency is resolved by omission far more often than by picking a side. ## Agent gateway URL: https://platformdtc.com/glossary/agent-gateway Category: Agentic commerce **Definition.** An agent gateway is the control plane through which AI agents act on a live system, enforcing scopes, idempotency, audit logging and human approval on irreversible actions. It exists because the protocols that let an agent act specify none of these things. MCP defines discovery and invocation; it is silent on who may call what, what happens when the same call arrives twice, and how you reconstruct afterwards what an agent did. The four controls are not independent nice-to-haves. Scopes without audit means you cannot investigate; audit without idempotency means your log faithfully records the double charge; and an approval gate is the only one of the four that prevents a mistake rather than explaining it. ## Idempotency key URL: https://platformdtc.com/glossary/idempotency-key Category: Agentic commerce **Definition.** An idempotency key is a client-supplied identifier that lets a server recognise a retried request as the same logical operation, so submitting it twice takes effect once. It matters most precisely where failure is ambiguous. A request that times out at the network layer may or may not have executed; without a key, the safe-looking choice — retry — is how one refund becomes two and one charge becomes two. Agents make this failure mode routine rather than rare. They retry automatically, often more aggressively than a human would, and they do it against endpoints that move money. Any write operation exposed to an agent that does not accept an idempotency key is a double-execution waiting for a slow network. ## Involuntary churn URL: https://platformdtc.com/glossary/involuntary-churn Category: Subscriptions **Definition.** Involuntary churn is subscription revenue lost when a renewal payment fails and recovery attempts are exhausted, rather than because the customer chose to cancel. It typically accounts for 25–40% of total churn in DTC subscription businesses, and it is systematically understated: a subscription that fails a charge, retries for two weeks and is then cancelled by the billing system is commonly recorded as a cancellation and counted as voluntary. It is the cheaper half of churn to address because there is no objection to overcome. The customer did not decide to leave; a card expired or an account was briefly short and the recovery logic was not good enough. That makes it a payments-infrastructure problem with a technical fix, not a retention problem. ## Voluntary churn URL: https://platformdtc.com/glossary/voluntary-churn Category: Subscriptions **Definition.** Voluntary churn is subscription revenue lost because a customer actively chose to cancel, as distinct from a subscription ending due to payment failure. It typically accounts for 60–75% of total churn and responds to product, price, cadence and perceived value — not to billing infrastructure. Retention tooling such as skips, swaps and pauses moves it at the margin, saving roughly 5–8% of at-risk customers, but cannot compensate for a subscription people do not want. The most concentrated opportunity is early. First-month churn runs 12–30% across every vertical, far above steady state, because the first renewal is the first time a customer evaluates a decision they made once — often at a promotional first-order price. ## Dunning URL: https://platformdtc.com/glossary/dunning Category: Subscriptions **Definition.** Dunning is the automated process a subscription business runs after a payment fails: retrying the charge, notifying the customer, and requesting an updated payment method. Effective dunning branches on the issuer decline code rather than applying one schedule to every failure. A hard decline such as a closed account will never succeed on retry, and attempting it anyway accumulates declines against your merchant profile for no possible gain. The emails are the visible part and the smallest part. Most recoverable failures resolve without contacting anyone — the card was fine and the account was briefly short, or the credential was reissued and an updater service refreshed it. Email matters for the residual where the credential is genuinely dead, and there the deciding factor is whether the update link works without a login. ## Pre-dunning URL: https://platformdtc.com/glossary/pre-dunning Category: Subscriptions **Definition.** Pre-dunning is contacting a customer to update their payment method before a renewal predicted to fail, usually because the stored card expires before the next bill date. It is strictly better than dunning wherever it applies. The customer is reached while nothing has gone wrong — no failed charge, no service interruption, no implied accusation — and the renewal simply succeeds. Most businesses do not run it, and the reason is rarely disagreement. Comparing card expiry against next bill date is a query nobody wrote, so the opportunity sits unclaimed in data the business already has. ## Decline code URL: https://platformdtc.com/glossary/decline-code Category: Payments **Definition.** A decline code is the reason an issuing bank gives for refusing a card authorization, and it determines whether retrying that card could ever succeed. The operationally important split is soft versus hard. Insufficient funds is soft — a timing problem where the same card will likely work in a few days. Stolen card, lost card and closed account are hard: no retry will ever succeed on that credential. Retrying hard declines is worse than not retrying. It recovers nothing and raises your overall decline rate, which can in turn affect authorization rates on legitimate charges. Route hard declines directly to a payment-method update request instead. ## Account updater URL: https://platformdtc.com/glossary/account-updater Category: Payments **Definition.** Account updater is a card network service that pushes reissued or renumbered card details to enrolled merchants so stored credentials keep working without customer action. When it works the failure never occurs: a card that expired last month simply charges successfully. That makes it the single highest-leverage involuntary-churn intervention, because it costs no customer goodwill at all. Coverage is not universal — it varies by network, by issuer and by how the credential was stored. Enrolment is nonetheless close to free relative to the recovery it produces, and it acts before the failure rather than after it. ## MIT (merchant-initiated transaction) URL: https://platformdtc.com/glossary/merchant-initiated-transaction Category: Payments **Definition.** A merchant-initiated transaction is a charge submitted against a stored credential without the cardholder present, such as a subscription renewal or a retry after failure. MITs rely on an earlier customer-initiated transaction that established consent, and card network rules bound how long that consent supports subsequent charges. Past that window an attempt is no longer a valid MIT regardless of what a retry scheduler believes. This is a hard ceiling on dunning that many retry schedules quietly exceed. A sequence still attempting charges beyond the validity window is generating guaranteed failures and paying the decline-rate cost for them. ## Network token URL: https://platformdtc.com/glossary/network-token Category: Payments **Definition.** A network token is a card-network-issued substitute for a card number that lets a merchant charge a stored credential without holding it, and survives card reissue. Network tokens raise authorization rates and reduce the maintenance burden of stored credentials, because the token remains valid when the underlying card is renumbered or reissued. They also bear on platform lock-in. Whether tokens can move between processors is the single fact that determines whether a subscription business can change platforms without asking every active subscriber to re-enter a card — which is where a share of them are lost permanently. ## Payment tokenization URL: https://platformdtc.com/glossary/payment-tokenization Category: Payments **Definition.** Payment tokenization is replacing card details with a reference token so a merchant can charge a stored credential repeatedly without holding the card number itself. It is what makes recurring billing possible without every merchant becoming a PCI-scope card vault. The token is meaningless outside the context that issued it, which is the security property. That same property is the commercial one. A token issued by a platform or app vendor generally cannot be used by anyone else, so whoever holds it holds your ability to bill. Establish portability in writing before you have a subscriber base large enough for it to matter. ## Authorization rate URL: https://platformdtc.com/glossary/authorization-rate Category: Payments **Definition.** Authorization rate is the share of attempted card charges that issuers approve, and it is a direct revenue lever for any business billing on stored credentials. It is influenced by data quality on the request, by whether the credential is a network token, by how the transaction is flagged (customer-initiated versus merchant-initiated), and by the merchant's own decline history. That last input is why blind retrying is costly beyond the wasted attempts. A pattern of declines against a merchant profile can depress approval on charges that would otherwise have succeeded — the damage is not confined to the transactions that failed. ## Chargeback URL: https://platformdtc.com/glossary/chargeback Category: Payments **Definition.** A chargeback is a forced reversal of a card payment initiated by the cardholder through their issuing bank rather than through the merchant. Beyond the lost revenue and the fee, chargebacks count against a merchant's dispute ratio, and sustained ratios above network thresholds bring monitoring programmes, higher costs and eventually loss of processing. For subscription businesses the most common cause is not fraud but recognition: a renewal the customer forgot they had authorized. Clear billing descriptors, renewal reminders before the charge, and a cancellation path that is genuinely easier than a dispute all reduce the rate more than any representment strategy. ## Representment URL: https://platformdtc.com/glossary/representment Category: Payments **Definition.** Representment is the process of contesting a chargeback by submitting evidence to the issuer that the original transaction was valid and authorized. Success depends almost entirely on evidence assembled at transaction time rather than at dispute time: authorization records, delivery confirmation, the terms the customer accepted, and communication history. Deadlines are unforgiving and set by the network, not the merchant. A dispute where evidence is compiled manually after notice arrives is frequently lost to the clock rather than to the merits. This is why representment is really a data-capture problem wearing a legal costume. The merchants who win are not the ones writing better rebuttals; they are the ones whose systems already recorded the authorization result, the delivery confirmation, the version of the terms the customer accepted and the IP and timestamp of the order — and can assemble that automatically the moment a dispute is filed. Deciding to collect that evidence after the first loss is deciding to lose the first several. ## Churn rate URL: https://platformdtc.com/glossary/churn-rate Category: Subscriptions **Definition.** Churn rate is the share of subscribers or subscription revenue lost over a period, most commonly reported monthly for DTC subscription businesses. Blended DTC subscription churn ran 6.5–8.5% monthly in 2026, with 5–7% considered good and below 5% top-quartile. Category variance is wide: supplements and consumables 5–8%, meal kits 8–15%, general subscription boxes 10–15%. A single blended number is a poor management metric because it averages cohorts that behave nothing alike — a 12–30% first-month spike and a much lower steady-state tail combine into a figure describing neither. Track cohort retention curves and the voluntary/involuntary split alongside it. ## Cohort retention URL: https://platformdtc.com/glossary/cohort-retention Category: Subscriptions **Definition.** Cohort retention measures what share of customers acquired in a given period are still active after each subsequent period, tracked separately per acquisition cohort. It is the correct primary view because it separates effects a blended rate hides. An improving product with worsening acquisition quality can produce a flat overall churn number while both trends are large. Cohorts should be cut by acquisition channel as well as date. Customers acquired through a heavy first-order discount retain differently from organically acquired ones, and blending them makes both unreadable. ## LTV (customer lifetime value) URL: https://platformdtc.com/glossary/ltv Category: Subscriptions **Definition.** LTV is the total contribution a customer is expected to generate over their whole relationship with a brand, best measured net of goods and fulfilment rather than gross. Gross-revenue LTV is the common version and the misleading one, because it flatters subscriptions with thin margins. Contribution-margin LTV is what can actually be compared against acquisition cost. It should be segmented by acquisition channel and by customer type. Subscription customers and one-time buyers have structurally different curves, and so do customers acquired through paid social versus email — blending them produces a number that justifies no specific decision. ## Contribution margin URL: https://platformdtc.com/glossary/contribution-margin Category: Commerce operations **Definition.** Contribution margin is revenue minus all variable costs of fulfilling an order — goods, processing, shipping, packaging and returns — leaving what covers fixed costs. It is the correct denominator for acquisition decisions. A brand comparing customer acquisition cost against revenue rather than contribution margin will systematically overspend, and the error grows with the discount rate. The commonly omitted lines are returns and payment processing. Both are genuinely variable, both scale with volume, and both are frequently accounted for centrally where they disappear from per-order economics. Returns are the one that does the most damage when omitted, because the cost is not the refunded revenue — that nets out — but everything around it: outbound shipping already spent, return shipping, inspection, repackaging and the units that come back unsellable. On an apparel line running 30% returns, an order economics model built on gross sales can show a healthy margin on a category that loses money on every cohort. ## COGS (cost of goods sold) URL: https://platformdtc.com/glossary/cogs Category: Commerce operations **Definition.** COGS is the direct cost of the products sold in a period — typically unit cost plus inbound freight and duties — excluding marketing, overhead and outbound shipping. For accurate margin reporting COGS must be tracked at variant level, not product level. Sizes and configurations of the same product frequently differ in cost, and a product-level average silently misprices the mix. It also needs to be time-anchored. Landed cost changes with each purchase order, and applying today's cost to last quarter's orders produces margin history that never happened. The version that catches people out is a freight spike. If a shipment arrives at double the usual freight cost and the system stores one current cost per variant, restating it retroactively rewrites every historical order at the new figure — so last quarter's margin drops for reasons that had nothing to do with last quarter. Costs need to be versioned with effective dates, and orders need to hold the cost that applied when they shipped. ## AOV (average order value) URL: https://platformdtc.com/glossary/aov Category: Commerce operations **Definition.** AOV is total revenue divided by number of orders over a period, measuring how much a customer spends per transaction. It is the most frequently gamed ecommerce metric. Free-shipping thresholds, bundles and post-purchase upsells all raise it, but raising it by discounting more heavily to hit a threshold can lower contribution margin per order at the same time. Read it alongside contribution margin and units per order. AOV rising while margin per order falls is a common and initially invisible pattern. The free-shipping threshold is where this usually happens. Set it at $75 against a $60 AOV and customers do add an item to clear it — AOV rises, which looks like a win. But you are now absorbing shipping on orders that previously paid it, and the added item is frequently the cheapest, lowest-margin thing in the catalog. The threshold pays back only if the margin on the incremental item exceeds the shipping you just gave away, which is a calculation worth doing before setting the number rather than after. ## Abandoned checkout URL: https://platformdtc.com/glossary/abandoned-checkout Category: Commerce operations **Definition.** An abandoned checkout is a session where a shopper entered the checkout flow and provided identifying information but did not complete the purchase. It is distinct from cart abandonment, and the distinction matters commercially: an abandoned checkout has contact details and a known intent, so it is directly recoverable. An abandoned cart usually has neither. Recovery performance depends far more on timing and on the checkout link resuming the exact cart state than on the copy. A recovery email that drops the customer at a generic cart page recovers a fraction of what a resumable link does. ## 3PL (third-party logistics) URL: https://platformdtc.com/glossary/third-party-logistics Category: Commerce operations **Definition.** A 3PL is an external provider that stores inventory and picks, packs and ships orders on a brand's behalf. Multi-3PL operations introduce a routing decision on every order: which location should fulfil it, given stock, destination and cost. Done well this reduces transit time and shipping spend simultaneously; done by static rules it does neither. The recurring failure is inventory truth. When stock levels live in the 3PL and the storefront holds a synced copy, the lag between them is where overselling happens — and it widens exactly when volume spikes. ## Destination-based fulfilment routing URL: https://platformdtc.com/glossary/destination-based-routing Category: Commerce operations **Definition.** Destination-based fulfilment routing picks which warehouse or 3PL ships each order from the delivery address, stock and cost, rather than using a fixed default location. The gain is compounding: shipping from the nearest location with stock cuts both transit time and zone-based shipping cost on the same order, and faster delivery is itself a retention input. It requires accurate, near-real-time stock by location. Routing decisions made against stale inventory produce split shipments and cancellations, which cost more than the naive default they replaced. The subscription-specific trap is that upcoming renewals are committed inventory. A router evaluating raw stock counts will happily send a one-off order from the warehouse holding the units already promised to next week's renewal cohort, and the failure surfaces days later as a subscription that cannot be fulfilled — which is far more expensive than a slower shipment, because it churns a recurring customer rather than delaying a single order. ## Merchant of record URL: https://platformdtc.com/glossary/merchant-of-record Category: Payments **Definition.** The merchant of record is the legal entity on the customer's statement, responsible for payment processing, tax remittance, chargebacks and compliance for a sale. When a platform acts as merchant of record it assumes tax and dispute liability, which simplifies operations but means the brand does not own the payment relationship, the processing economics or the settlement timing. When the brand is merchant of record it settles into its own accounts and controls its processing arrangement and its payment data — at the cost of owning tax registration, compliance and dispute handling itself. The choice is a genuine trade rather than a best practice. ## Prepaid subscription URL: https://platformdtc.com/glossary/prepaid-subscription Category: Subscriptions **Definition.** A prepaid subscription is one where the customer pays upfront for a fixed number of future deliveries — commonly three, six or twelve — rather than being billed at each cycle. It is the strongest single retention lever available. Annual billing reduces monthly-equivalent churn by 60–80% on the same product, and prepaying three to six months has been reported to raise retention by up to 40%. Part of that effect is definitional rather than behavioural: prepaying converts twelve cancellation decisions into one. It also concentrates risk, since a prepaid cohort churns at renewal in a single visible cliff rather than bleeding continuously, and it pulls cash forward against a delivery obligation. ## MER (marketing efficiency ratio) URL: https://platformdtc.com/glossary/mer Category: Measurement **Definition.** MER is total revenue divided by total advertising spend across all channels, measured at the business level rather than per campaign. It exists because platform-reported ROAS double-counts: Meta and Google will each claim the same order, so summing channel ROAS produces a number that cannot be reconciled with the bank account. MER has no attribution in it at all, which is precisely its value — it cannot be inflated by a platform marking its own homework. The trade-off is that it tells you nothing about which channel to change. MER is the number you defend a budget with; channel-level measurement is what you steer with. Using either alone is how brands end up confidently wrong. ## ROAS (return on ad spend) URL: https://platformdtc.com/glossary/roas Category: Measurement **Definition.** ROAS is revenue attributed to advertising divided by the spend that produced it, usually reported per campaign or channel. The word doing the work is "attributed". Platform-reported ROAS uses the platform's own attribution model and its own view of which conversions it caused, which is why the sum of channel ROAS routinely exceeds total revenue. It is also a revenue ratio, not a profit ratio. A 3x ROAS on a product with 30% contribution margin loses money. Break-even ROAS is the inverse of your contribution margin, and it is the number that should be on the dashboard. ## Incrementality URL: https://platformdtc.com/glossary/incrementality Category: Measurement **Definition.** Incrementality is the share of conversions that happened because of a marketing activity and would not have happened without it. It is the question attribution cannot answer. Attribution assigns credit for conversions that occurred; incrementality asks which of them were caused. A retargeting campaign shown to people already intending to buy can post excellent attributed ROAS while being close to entirely non-incremental. Measuring it requires a holdout — geographic, audience-based or time-based — where the activity is withheld and the difference observed. That is uncomfortable, because it means deliberately not advertising to some people, and it is the only method that produces a causal answer. ## CAC (customer acquisition cost) URL: https://platformdtc.com/glossary/cac Category: Measurement **Definition.** CAC is the total cost of acquiring one new customer, calculated as acquisition spend divided by new customers acquired in the same period. Two versions circulate and they differ by a lot. Blended CAC divides all marketing spend by all new customers, including those acquired organically — flattering, and useful for whole-business economics. Paid CAC divides paid spend by customers acquired through paid, which is the number that should drive a bidding decision. CAC is only meaningful beside contribution-margin LTV and a payback period. A high CAC is fine if margin is high and payback is fast; a low CAC on a customer who never reorders is not a win. The denominator is where it quietly goes wrong. Counting reactivated lapsed customers as "new" lowers CAC without acquiring anyone, and so does counting a second subscription from an existing household. Both make a scaling channel look more efficient than it is, and both are the default behaviour of most reporting until somebody defines "new customer" explicitly. ## Payback period URL: https://platformdtc.com/glossary/payback-period Category: Measurement **Definition.** Payback period is how long it takes for the contribution margin from a customer to recover what it cost to acquire them. For a business funding growth from cash flow this matters more than LTV:CAC. A 4:1 ratio that takes eighteen months to pay back will run you out of cash long before the ratio is realised, and a business can grow itself into insolvency on excellent unit economics. Measure it in orders as well as months for subscriptions — "recovered by the second box" is a sharper operational target than a duration, and it survives changes in billing cadence. ## Attribution window URL: https://platformdtc.com/glossary/attribution-window Category: Measurement **Definition.** An attribution window is the period after an ad interaction during which a resulting conversion is still credited to that interaction. Window length changes reported performance without changing reality. A 7-day-click window and a 28-day-click window describe the same campaign and produce materially different ROAS, which is why comparing numbers across platforms or across time without checking the window is a common and expensive error. Longer windows credit more conversions and are more likely to capture ones that would have happened anyway — so a generous window and a weak incrementality result frequently describe the same campaign. ## First-party data URL: https://platformdtc.com/glossary/first-party-data Category: Measurement **Definition.** First-party data is information a business collects directly from its own customers and its own properties, rather than obtaining it from a third-party source. Its importance grew as third-party cookies and mobile identifiers became unreliable, leaving purchase history, email engagement and on-site behaviour as the durable signals a brand actually owns. The practical requirement is that it be joinable. Order data in one system, email engagement in another and site behaviour in a third are three datasets, not first-party data — the value only appears when a customer can be followed across all three. ## Server-side tracking URL: https://platformdtc.com/glossary/server-side-tracking Category: Measurement **Definition.** Server-side tracking sends conversion and behavioural events to analytics and ad platforms from a merchant's own server rather than from the shopper's browser. It recovers events that browser-based tracking loses to ad blockers, tracking-prevention features and network failures — commonly a substantial share of conversions, which shows up as under-reported performance and worse ad-platform optimisation. It is not a privacy workaround and should not be sold as one: consent obligations apply to the event regardless of where it is sent from. The gain is reliability, not permission. The failure mode to watch for is double counting. Running browser and server tracking simultaneously without a shared deduplication key means every conversion the browser did report is counted twice, which inflates reported performance and teaches the ad platform to optimise toward the wrong signal. Both sides must send the same event ID. ## RFM (recency, frequency, monetary) URL: https://platformdtc.com/glossary/rfm Category: Measurement **Definition.** RFM is a segmentation method that scores customers on how recently they purchased, how often they purchase and how much they spend. It is old, simple and still among the most predictive segmentations available for retail, because recency in particular is a strong indicator of whether someone will buy again. Its main use is triage: the segments define who is worth a win-back, who is worth a loyalty offer and who should be left alone. Discounting a high-frequency recent buyer is margin given away to someone who was going to purchase regardless. ## Win-back URL: https://platformdtc.com/glossary/win-back Category: Subscriptions **Definition.** A win-back is a campaign aimed at customers who have lapsed or cancelled, intended to restart a relationship that has already ended. Timing dominates content. A win-back sent while the reason for leaving is still fresh performs worse than one timed to when the product would plausibly be needed again — which is knowable for consumables and guessable for most categories. It should be aimed only at genuinely voluntary churn. A subscriber lost to a failed payment does not need persuading; they need a working card, and sending them a discount to return is both wasteful and slightly insulting. ## Replenishment subscription URL: https://platformdtc.com/glossary/replenishment-subscription Category: Subscriptions **Definition.** A replenishment subscription delivers the same consumable product on a repeating schedule matched to how quickly the customer uses it. It retains structurally better than curated or discovery subscriptions because its value proposition is convenience, which does not decay, rather than novelty, which does. Supplements and consumables run 5–8% monthly churn against 10–15% for general subscription boxes. The decisive variable is cadence accuracy. A delivery that arrives before the last one is finished creates stockpiling and then cancellation, which is why skip is a retention feature rather than a leak. ## Proration URL: https://platformdtc.com/glossary/proration Category: Subscriptions **Definition.** Proration is adjusting a subscription charge to reflect a mid-cycle change, so the customer pays only for what applied during each part of the period. It arises on upgrades, downgrades, plan switches and cancellations, and it is the most common source of billing disputes — because customers reason about it in whole periods and billing systems reason in days. The decision worth making explicitly is whether a downgrade takes effect immediately with a credit or at the next renewal. Both are defensible; not deciding produces inconsistent behaviour that support absorbs one ticket at a time. ## Grace period URL: https://platformdtc.com/glossary/grace-period Category: Subscriptions **Definition.** A grace period is the interval after a failed payment during which a subscriber keeps access or continues to receive deliveries while recovery is attempted. It trades margin for retention. Too short and you cancel subscribers whose payment would have recovered on the next retry; too long and you ship goods to people who will never pay. For physical goods the calculation is harsher than for software, because the cost of an ungranted period is real inventory rather than marginal compute. Most brands should set it against their observed recovery curve rather than by intuition. ## ARPU (average revenue per user) URL: https://platformdtc.com/glossary/arpu Category: Measurement **Definition.** ARPU is total revenue in a period divided by the number of active customers in that period. For subscriptions it is a useful health check on pricing and mix, and it moves for two entirely different reasons: customers paying more, or cheaper customers churning out. The second looks identical to the first on a chart and is not good news. Read it alongside customer count. Rising ARPU with falling customers is usually a shrinking business with a flattering average. A worked example of how badly it can mislead: a brand with 10,000 subscribers at $30 and 5,000 at $60 has an ARPU of $40. Lose half the $30 cohort to churn and ARPU climbs to roughly $46 while monthly revenue falls by $150,000. The metric improved by 15% because the business got smaller, and any dashboard showing ARPU without the subscriber count beside it will report that as progress. ## Cohort URL: https://platformdtc.com/glossary/cohort Category: Measurement **Definition.** A cohort is a group of customers who share a starting characteristic — most often the period in which they made their first purchase — and are then tracked together over time. Cohorting is what separates a change in the business from a change in the mix. A blended metric moves when new customers behave differently, when old customers behave differently, or when their proportions shift, and it cannot tell you which. Cut cohorts by acquisition channel as well as date. Customers acquired on a heavy first-order discount retain differently, and blending them with organic ones makes both curves unreadable. The classic misdiagnosis it prevents: overall retention looks flat, so the product team concludes nothing changed. Cohorting reveals that each new cohort is in fact retaining better while the mix has shifted toward a cheaper acquisition channel that retains worse — two large opposing movements averaging to a straight line. Acting on the flat number means fixing a product that is improving and scaling a channel that is not.