> For the complete documentation index, see [llms.txt](https://docs.intelligems.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.intelligems.io/general-features/targeting/audience-targeting/purchase-likelihood-targeting.md). # Purchase Likelihood Targeting Some visitors land on your site ready to buy. Others are just browsing. Right now, you can't tell the difference until they've already started acting, by which point you've missed your chance to shape their experience. Purchase Likelihood targeting changes that. It's an audience that estimates how likely a visitor is to convert, assigned the moment they land, before they've clicked, scrolled, or added anything to a cart. The same offer doesn't always work the same way for every visitor. Purchase Likelihood shows you how each tier responded in your results, so you can spot where an experience may work differently and test it. #### What it is Purchase Likelihood sorts every visitor into one of three tiers, relative to your own store's traffic: | Tier | Who's in it | | ---------- | ----------------------------------------------------------------- | | **Higher** | About your top 20% of visitors, by predicted purchase probability | | **Medium** | About the middle 50% | | **Lower** | About the bottom 30% | Tier sizes in a given test vary based on that test's traffic. These tiers are calculated against *your* traffic, not some global benchmark. A "Higher" visitor on your store is compared to your other visitors, not to visitors on a store with a completely different customer base or price point. That's what makes the tiers meaningful no matter what you sell or how your store typically converts. A note on what these labels mean: they're relative, not absolute. A "Higher" visitor is more likely to buy than your other visitors, not necessarily likely to buy in any absolute sense. Depending on your store, even your top tier might convert in the single digits to around 10%. Treat the tiers as a ranking of your traffic, not a prediction that any individual visitor will or won't purchase. #### Where you'll find it Right now, Purchase Likelihood is available as a **targeting** audience, in both personalizations and tests: * **Eligibility**, for deciding who can be included in a test or personalization based on their tier * **Group assignment in tests**, where the tier can also help determine which test group a visitor sees by using Advanced targeting * **Results by tier**: on any experience that targets at least one tier, the By Audience table in your results has a Purchase likelihood tab showing how each tier responded The Purchase likelihood tab only appears in experience results. Sitewide analytics doesn't break traffic down by tier, because visitors are only scored when they enter an experience that uses Purchase Likelihood targeting. **Supported test types today:** Merchandising, Shipping, Checkout, and Post-Purchase. **Not yet supported:** Content and Pricing tests. If you're running one of those, Purchase Likelihood won't show up as a targeting option yet. Please let us know if this is something you are interested in. **How to use it** The easiest way to start is an offer test. Pick a free gift, a sitewide discount you're considering for BFCM, or any offer you already have in mind, and target all three tiers (Higher, Medium, and Lower). When results come in, open the Purchase likelihood tab in the By Audience table to see how each tier responded. A couple of other places to start: * **Lower tier:** test a free gift or discount to see whether it moves conversion for visitors who usually browse and leave. Watch profit per visitor, since an offer that converts browsers can still cost you margin. * **Higher tier:** test a premium upsell or bundle to grow AOV from visitors who are already likely to buy, without discounting them. #### What data it uses Purchase Likelihood is built entirely from signals available the moment a visitor lands, so it never needs to wait and see how they behave: * **Device type** — mobile, desktop, or tablet * **Country** * **Whether it's their first visit** to your store * **Referring source** — where the visitor came from * **Landing page** * **Day of week and time of day** * **Your store's industry and sub-industry** * **Your store's typical conversion rate and average order value** No scrolling, clicking, or cart activity required. Everything above is available at the instant a visitor arrives, which is what lets the tier be assigned on the first page view. #### What to know before you start * **It's a signal, not a guarantee.** A "Higher" visitor converts at a meaningfully higher rate than a "Lower" one, but it's still a probability, not a promise. Treat it the way you'd treat any other audience: a starting point for a hypothesis, not a certainty. * **It's built for testing, not for skipping testing.** Use Purchase Likelihood to decide *who* sees a test, not to decide what the outcome will be. Let your results tell you whether a different experience for your Higher-tier visitors actually moves profit per visitor. * **It's in closed beta.** Purchase Likelihood isn't generally available yet. See below for how to request access. ### Try it Likelihood to Purchase is currently in closed beta. If you'd like to be included, let us know here: [Request access](https://intelligems.portal.usepylon.com/forms/likelihood-to-purchase-interest) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.intelligems.io/general-features/targeting/audience-targeting/purchase-likelihood-targeting.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.