AI visibility

A visibility project tracks one brand across the AI models. Create one under AI Visibility → New project, enter the brand name and website, and add the competitors you want to benchmark against. CrunchJunkie uses the brand and competitor names to detect mentions in AI responses, so spell them exactly as they appear in the market — including common variations if the brand is known by more than one name. Large competitor sets are fine — a project can track a whole industry ranking; beyond 20 tracked names the extractor switches to a mode that reads only the brands an answer actually names, so a long list never degrades detection accuracy. A competitor entered as a web address ("https://www.example.com/") is tracked under its domain ("example.com"), with the domain as its website; rename it on the Brands page to the name answers use for that brand, since mentions are matched by name. A rename moves the competitor's history (its mentions and daily figures) to the new name. The setup guide drafts the first prompts for you from the details entered so far (the brand, its web address, category, competitors and market; it does not read the site itself unless a Brand Profile exists): open questions a buyer asks before they know which brand to pick, and at most one about the brand. A prompt whose text names the brand shows whether it will be filed as Brand or Discovery, and a click switches it. Tick, edit or replace them; if no draft comes back, the step shows empty fields and a Suggest prompts button. Each project is independent, which makes it easy to run visibility for several clients side by side. Once the project exists, you add prompts and choose which models to scan, then CrunchJunkie takes over the daily monitoring.

Prompts are the questions CrunchJunkie asks the AI models on your behalf. Add them under the project's Prompts tab and give each one a category: Discovery prompts are unbranded category questions ("best marketing reporting tools for agencies"), Brand prompts name your client directly ("is Lumière any good?"), and Competitor prompts name a competitor or ask for alternatives to one ("Velora alternatives"). CrunchJunkie runs every prompt against every enabled model on each scan and records whether your brand was mentioned, where it ranked in the answer, how it was described, and which sources the model cited. Which prompts to add, and how many, is the subject of the next section.

If you already have a list of prompts — in a spreadsheet, exported from another tool, or handed over by a client — import the whole list at once instead of typing each one. On the Prompts tab, click Import, then upload a CSV, TSV or Excel (.xlsx) file. CrunchJunkie reads one prompt per row and shows a preview of exactly what it will create before anything is saved. Download the template from the import dialog to see the columns. Only prompt is required; the rest are optional. The tags column holds one or more labels separated by a semicolon (for example "reporting; agencies"), or you can spread tags across several tag columns if that is how your sheet is built. category is one of discovery, brand, competitor or shopping — anything else falls back to discovery. market and language set a prompt's market override (a country name or code, and a language), so a single import can span several markets at once; leave them blank to inherit the project default. Set active to "no" to import a prompt switched off. Intent is applied automatically. You do not need an intent column: CrunchJunkie predicts each prompt's intent — Commercial, Informational or Navigational — from its wording, exactly as it does when you add a prompt by hand. If you would rather set it yourself, add an intent column and your value wins. Either way, every intent stays editable on the prompt afterwards. The preview tells you how many prompts are ready, how many were skipped (blank or over 2000 characters), how many rows were duplicates, and how many already exist in the project. CrunchJunkie never imports a prompt you are already tracking, so re-importing an updated list adds only what is new. Confirm, and the prompts appear in the table, ready to scan.

Every project has a market and a language, set under the project's Settings. They decide what each AI model is asked — not how many models run — and getting them right matters more than most settings in the product. They work differently depending on the engine, and the difference is the whole point. The seven chat models (ChatGPT, Gemini, Perplexity, Claude, Grok, DeepSeek, Meta AI) are told to answer as if for someone in that market, replying in that language. Google AI Overviews, Google AI Mode and Microsoft Copilot are searched from the selected country instead, because they are search surfaces rather than chat models. That second group is why prompt language matters. For AI Overviews and AI Mode, your prompt text is the search query. "beste Marketing-Agentur München" and "best marketing agency Munich" are two different searches — different results, different sources, different AI answers. No market setting changes that; only the prompt text does. So write prompts in the language your client's buyers actually search in. For a German client, German. The test is not what language your agency works in — it is what a real buyer types into ChatGPT or Google. A German SME looking for a supplier types German. One exception worth checking before you localise everything: in some categories and markets, buyers genuinely search in English because the English-language material dominates the field. B2B software in the Nordics and the Netherlands often behaves this way. If that is true of your client's category, English prompts are the correct measurement and you should keep them. The language also decides what CrunchJunkie writes for the project. The Brand profile auto-fill, prompt suggestions, the Objections and Fact-checking analyses and the GEO Audit's AI insights are all written in the project's language, whatever language the website or the AI answers are in; brand and product names stay as written. Text written before you changed the language stays as it was until you run it again. The project's market and language are the default, but you can override the market on individual prompts — which is how one project tracks a brand across several markets at once. The next section covers it.

A brand that sells into more than one language market used to force an awkward choice: one project that pooled every market into a single, meaningless average, or a separate project — or worse, a separate client — per market, which split the brand and billed it twice. Neither is necessary. Market is set per prompt, so one project tracks a brand across as many markets as it sells into. On the Prompts tab, every prompt has a Market dropdown. Leave it on Inherit (project) to use the project's default, or pick a country to scan and pool that prompt in its own market. Write each prompt in the language that market's buyers actually search in — a German prompt set to Germany, an English one to the UK or US — for exactly the reasons in the section above. The market you pick is recorded on every run at scan time, so editing a prompt later never retroactively relabels the history you have already collected. Because each market is pooled on its own population, the numbers stay honest — and once a project spans more than one market, the Overview grows two things to read them with. A Filter by market switch at the top scopes the whole page — visibility, share of voice, sources, everything — to one market at a time, or All markets for the blended view. And a Markets table lists every market side by side: visibility, share of voice, sentiment, average position and run count, each pooled only on that market's own scans. Share of voice is always measured within a market and never blended across them, so a strong position in Germany never flatters a weak one in the UK. That side-by-side view is the part most visibility tools don't offer — it's where you see that you lead in one market and trail in another, which is usually the whole reason for tracking more than one. Multi-market tracking is included, not a paid add-on. It is metered the same way as everything else in AI visibility — by checks (prompts × engines × passes). Giving a prompt a specific market adds no surcharge; a prompt scanned in Germany costs exactly what any prompt costs. If you genuinely want the same question measured in two markets, that is two prompts — and so two prompts' worth of checks, the honest cost of measuring twice. Still, don't split one brand across two clients or two projects to separate markets. It bills the same brand twice, splits the reporting, and describes one company as two. Set the market on the prompt instead.

Coming up with the right prompts is the hardest part of setup, so Crunch can do the first pass for you. On the Prompts tab, click "Suggest prompts" and CrunchJunkie reads the project's brand, website, product type, the attributes you want to be known for, your competitors (and their domains) and the coverage you already have, then proposes realistic buyer questions across the intent mix — unbranded category queries, brand questions and competitor comparisons — that fill the gaps rather than duplicate what you track. The suggestions get sharper when the project has a Brand profile — a short description of what the business is, its market segment, positioning, audience and products. In the project's Settings, click "Auto-fill from site" to have Crunch read the brand's website and draft it (or write it by hand); it's fed straight into the suggestion prompt so ideas fit the actual business, not just the brand name. Everything is editable and never invented — a field the site doesn't support is left blank. The profile is written in the project's language (Settings → Market & language), whatever language the website is in: an English site for a German project gives a German profile, with brand and product names kept as the site writes them. An existing profile isn't translated automatically: if yours came out in the site's language, click "Auto-fill from site" again to rewrite it. That replaces the whole profile, hand edits included. Auto-fill can make at most 12 AI calls per project in any 24 hours (one per click, two when a cut answer is retried). Once the project has been scanned, discovery also leans on your own scan data: it weights suggestions toward the topics where competitors currently get recommended and you don't (the same measured gap as the Opportunity score), so the ideas target real weaknesses rather than generic category questions. Suggestions grounded that way carry a small Gap badge. If the client's Google Search Console is connected, discovery also reads the real queries the site already shows for in Google (last 90 days, every connected property, filtered to the project's market when possible) and turns the buyer-intent ones into candidate prompts. Those carry a Search Console badge naming the exact query and its impressions — taken from the Search Console data, never from the model. Be precise about what that is: real Google search demand for that query, evidence of what people in this market look for. It is not a measurement of what they ask AI assistants, which nobody can measure. Suggestions land in a review queue that survives reloads: each carries a short why — the competitor, use case, attribute or observed gap it targets — so you can see what it's grounded in. Add the ones that fit, dismiss the rest (a dismissed suggestion is remembered and never proposed again), and edit any after adding like a prompt you wrote yourself. A deliberate honesty note sits above them: these are grounded candidate questions, not measured demand. CrunchJunkie never shows a fabricated "AI prompt volume" — no tool can measure how often a topic is asked across ChatGPT, Perplexity or Gemini (the providers don't publish it), so a precise "searches/mo" figure is always a guess. You prioritise from what we can measure — the Opportunity score below — not from invented numbers. If you already have keywords in mind — product categories, use cases, search terms — use "From keywords" instead: paste them in (one per line or comma-separated) and Crunch turns each into realistic buyer questions across the intent mix, rather than restating the keyword verbatim. It's the quickest way to seed a tracking set around topics you care about, and the results are the same editable suggestions you add with a click.

Once a project has scan data, the Prompts table shows an Opportunity column, and clicking it sorts your prompts by where the biggest wins are. This is the honest, measured answer to "where should I spend effort?" — and it is deliberately not a demand or volume estimate. The score answers one question we can actually measure from your own scans: on this prompt, do competitors get recommended while you don't? A prompt reads High when rivals are named across many runs and you're absent on most — the classic gap to close. It's computed as competitor presence × (1 − your visibility), both pooled over the same runs, so a prompt where you already lead, or one nobody wins yet, correctly reads Low rather than as an opportunity. Each score carries its basis on hover ("You 0% · competitors 60% · 24 runs"), and — where the gap sits on specific engines — names them ("missing on Perplexity, Claude"), so you know exactly where to act. A small confidence dot from the sample size follows the same honesty rule as everywhere else: a prompt with only a handful of runs shows "Collecting" instead of a confident tier pulled from noise. Why no "prompt volume" next to it? Because there is no ground truth for how often a question is asked inside ChatGPT or Perplexity — the providers publish only aggregate totals, and the tools that print a precise "1,200 searches/mo" are extrapolating a consented browser panel that sees a fraction of usage (their own docs concede the figure "could be half or double — good for ranking, never a literal count"). Rather than resell a guess as a fact, CrunchJunkie prioritises from measured competitive gaps. Optionally (a beta, off by default) it can also show a clearly-labelled Google Keyword Planner search-volume figure next to each prompt — a proxy for traditional-search intent, never relabelled as AI demand. It's shown as a range ("1K–10K") rather than a false-precise number, and the exact keyword it looked up is shown for transparency, because a full AI-style question and a Google keyword are rarely identical. The opportunity ranking itself always stands on what we actually observed.

CrunchJunkie can track ten AI surfaces: ChatGPT, Gemini, Perplexity, Claude, Google AI Overviews, Google AI Mode, Microsoft Copilot, Grok, DeepSeek, and Meta AI. Enable the ones that matter for your client's audience under the project's Models settings — you don't have to run all ten. Each enabled model is scanned automatically every day. Each surface maps to a specific, current model version: ChatGPT is tracked on GPT-5.6 with web search, Gemini and Claude with web search, Perplexity through its Agent API (Perplexity's web search and inline citations, currently answering on OpenAI's GPT-6 Luna), Grok with web search, Meta AI on Muse Spark, and Microsoft Copilot, Google AI Overviews and AI Mode through a search-results provider. Since early October 2026 (between 1 and 6 October; Perplexity does not publish the day) Perplexity runs that web search as its Fast Search. Our before/after check on three of our own tracked projects found no change beyond run-to-run noise: 25.3 sources per answer before, 25.8 after (26–30 September vs 7–13 October, 96 answers each on the same 38 prompts), so Perplexity's history stays comparable across the switch. Nine of the ten are web-search-grounded; DeepSeek is the exception. Our scan sends DeepSeek the web search tool, but its current model ignores it, so since 10 September 2026 DeepSeek's answers come from model memory. The URLs in them are labelled "from model memory, not a search" and left out of every citation and source figure; DeepSeek's brand mentions still count. Grok answers store the sources they cite from 7 October 2026; earlier Grok answers show none. The exact model each surface calls is shown on the Models settings page and evolves as providers ship new versions. Some models require specific setup. Google AI Overviews, for example, is tracked through a search-results provider rather than a chat API. The Models settings page tells you exactly what each one needs and shows the current status of every connection at a glance.

A gap prompt is one your buyers ask where AI engines mentioned you in zero measured runs. The Brief button on those rows generates an evidence-grounded content brief: CrunchJunkie assembles the actual AI answers for that exact prompt, the competitor pages those answers cited, and each winner's extracted GEO signals (direct quotations, statistics with named sources, authoritative outbound links — the signals a 2024 lab benchmark, the KDD'24 GEO paper, scored highest). The brief is hard-constrained to that evidence: it never invents sources or figures, and when there is nothing to build on it says why and what unblocks it in your workspace (run a scan, tick an engine that names the pages it cites, or add a key for one) instead of guessing. Refresh before you build. When the client's Google Search Console is connected, the brief first checks whether a page of the site is already within Google's reach for the searches behind the prompt — the prompt itself and the web searches the engines actually ran before answering. It reads the client's own query-by-page rows for the last 28 days across every connected property, keeps only queries that genuinely share the prompt's vocabulary (brand-name queries never count), and looks for a page in Google's top 20. If there is one, the brief opens with "Refresh this page", names the URL, its average position, the query and the impressions, and the whole plan describes changes to that page — a page Google already retrieves for these searches is the cheapest route to an AI citation, and it becomes the page the recommendations are diffed against. If there is none, the brief says "New page" and, for orientation, names the closest page that fell short. Without Search Console it makes no claim either way and tells you what connecting it would add. The position is Google's impression-weighted average over the matched queries, labelled as such — never a fixed rank. Reopening a brief shows the saved version instantly — free — with a Regenerate button when you want it rebuilt from fresh evidence (that is a new AI call, metered like any other). Each brief stores its 0% baseline. Once you've published the page it describes, click Measure impact — CrunchJunkie re-scans that one prompt and compares only fresh runs against the baseline, so the lift you see is current evidence, not an average diluted by history. Batch briefing runs the same loop across every gap prompt at once. There's a full walkthrough — with a two-minute video — in the Resources hub: "Turn an AI-visibility gap into a cited page".

Each check in a scan is a real, live AI query with web search enabled — the same call your customers' assistants make — and a single search-grounded answer takes 30–90 seconds to generate. That time is the AI provider thinking, not the platform working; no tool can make a model answer faster. A full scan is prompts × engines × passes of those checks, run several at a time, so a thorough configuration takes real minutes. The scan bar shows honest progress: how many checks have actually saved, a live time-remaining estimate, and — if any checks fail — how many, with the reason. On the Prompts page, click the failed-checks badge for a per-engine breakdown of what failed and why (it is almost always one provider's key or quota, which is why every prompt loses exactly one check). A failed check is attempted up to 3 times and saves no run — it never counts against a Managed AI allowance, and on your own keys a provider call that fails isn't billed by the provider either. One exception: an answer that arrives empty or cut off is not stored (a later pass may ask again), but the provider did answer that call, so on your own keys it bills it. You don't need to watch it. Close the tab whenever you like — the scan continues on our servers and your results are waiting next time you open the project. Every scan runs on our servers; an open tab only speeds up the scan it started, running 6 checks at a time while it is open. You'll get one summary email the moment the scan finishes — wherever it finishes, and never more than one. (A scan you stop yourself doesn't email; you were there.) You can start another scan at any time. Run scan on a different project while one is running starts it on our servers straight away, alongside the first. Run scan on a project that is already scanning queues the new scan instead of stopping the running one: it starts by itself on our servers when that scan finishes (or fails, or is stopped) — usually within seconds, at most a few minutes when our servers are busy — and the dialog says roughly when — "about N min", from the running scan's measured pace, once it has saved a few answers. (A scan nobody started by hand — the automatic first scan of a new project, or a scheduled scan that has not run a single check yet — is simply replaced by yours, and anything the automatic one already saved counts.) A project holds one queued scan: starting again replaces it with the settings you just confirmed. A queued scan uses nothing from your allowance until it starts. The scan bar at the bottom of the app lists every running and queued scan of your workspace with its progress and time left — not only the one your tab started — and that is where you stop a running scan or cancel a queued one. Most other AI-visibility tools only run prompts on a fixed overnight schedule, so their dashboards always show yesterday's data and there is nothing to wait for — but also no way to measure right now. CrunchJunkie gives you both: the automated schedule (weekly, daily, or every N days — pick the rhythm and the hour; most teams pick early morning so fresh numbers are ready with the first coffee) for routine tracking, and the on-demand scan for the moments you need an answer today — after a site change, before a client call. Use the schedule as your default and the manual scan as your instrument, and the waiting disappears from the workflow entirely.

A visibility line steps and, weeks later, nobody remembers why. Was it a real change, or did you add two engines, switch the market, or pause scanning that week? Timeline notes put the answer on the chart itself. We record configuration changes automatically. Whenever something changes that genuinely moves the numbers — market, answer language, engines added or removed, prompts added or removed (including through the MCP connector), passes per prompt, scan frequency, competitors, brand aliases, or pausing and resuming — a note is written against that date. Deliberately nothing else: a note on every save is a note people stop reading. The same rule shapes repetition: adding ten competitors or ten prompts across a day merges into one note naming them all, and a change undone the same day leaves no note at all — the measurement ends the day where it began. The wording explains the statistics, not just the setting. Adding a competitor says Share of Voice will step even if nothing about your brand changed, because it is measured against a different set of brands from that date. Pausing says the line has a gap rather than a decline. You add your own for everything else — "client launched a TV campaign", "site migration", "new pricing page". Backdate them to the day the thing happened, which is usually not the day you write them down. On the chart, notes appear as small markers on the date axis; hover to read one. Several on the same day cluster into a single marker with a count. Your notes and ours are different colours, so you can tell at a glance which is which. Manage them all under the project's Settings tab, where automatic ones can also be dismissed once you have taken them in. Automatic notes are internal and stay internal. "Market changed from United States to Spain" is a correction you made to the measurement, and it has no place in the report your client reads. Your own notes are internal by default too — you can promote one to appear in client reports and share links, but nothing is ever shown to a client unless you deliberately choose it. One more thing the notes do: when a configuration change falls inside the period you are looking at, the chart says so. A period-over-period comparison across that date is comparing two different measurements, and we would rather tell you than quietly show you a number that looks like a result.

Four headline metrics tell you how you're doing. Visibility % is how often your brand appears across all tracked prompts. Every one of these counts EARNED mentions only — times a model named your brand in its own answer. Paid placements are a separate channel: ChatGPT Ads and the like never appear in these numbers, so a client running both should read AI visibility and AI ad spend side by side, never added together. Share of Voice is your slice of total brand mentions versus your tracked competitors — the clearest signal of who owns the conversation. Sentiment scores how positively each mention describes you, and Average Position records where you land when you do appear. Drill into any metric by model, by prompt category, or over time. The Responses view lets you filter to All, Mentioned, Not mentioned, or Mention gap (prompts where a competitor appears and you don't) — the fastest way to find concrete opportunities. The Sources view ranks the domains AI cites most, and the Insights view turns all of this into prioritised, plain-language actions. Those four metrics tell you how often and how prominently you appear; the Perception view (under Brand in the nav) tells you what the models actually said — the descriptive terms they used about each tracked brand, and which of those terms are used for you and nobody else. See the Perception guide for how to read it.

You don't have to keep checking the app to catch a problem. When Signals raises a fall in a client's AI visibility, or a competitor named in more of the client's answers than the client, CrunchJunkie emails the workspace owner. The bar is the one the Signals inbox uses: the last 14 days against the 28 days before, at least 40 answers on at least two scan days in each, and a fall of at least 15 % and 3 points at 95 % confidence (see Signals & Automations for the whole rule). One scan never raises it. The email is worded from the signal itself, with the same periods, answers and confidence, and links straight to the project. It goes once per change, however long the change lasts, and there is nothing to switch on. It is sent at 10:00 in your workspace's time zone (Settings → Preferences); a workspace without a valid time zone keeps 10:00 UTC.

A single overall visibility number hides where you actually win and lose. CrunchJunkie classifies every prompt on two axes so you can slice it. Buyer intent — Commercial (comparing/buying), Informational (learning) or Navigational (looking for a specific brand) — is auto-predicted for each prompt and stays editable. Branded vs non-branded is derived deterministically from your brand name and its aliases: a branded prompt names you ("is Lumière any good?"), a non-branded one is a pure category question ("best CRM for agencies?"). Both classifications are rule-based, not an opaque model guess, so they're instant, free and 100% reproducible. On the Prompts page these become one-click slice filters. Each slice chip shows that slice's visibility with its sample size (for example "Non-branded 34% · 340 runs"), so a slice built on three runs never reads like one built on three hundred — the number always carries its sample size. The distinction that matters most: high branded visibility just means AI repeats what you already told it, while non-branded visibility is the real prize — being recommended when the buyer hasn't named you yet. Slicing by Commercial intent shows exactly the purchase-moment queries where a recommendation converts. Because that difference is so easy to miss, the Overview watches for it: when a large share of your prompts name your brand (or branded prompts materially lift the headline number), it shows an inline flag with your non-branded visibility right there — so a visibility figure that looks high only because you're asking about yourself by name can't be mistaken for genuine, unprompted recommendation.

A fair question, and worth being precise about. CrunchJunkie's scans are independent of your own AI-account history: we don't query the ChatGPT or Gemini consumer apps (which carry memory, custom instructions, chat history and your location) — we call the providers' APIs, where every request is stateless. Each scan sends only the prompt plus a web-search tool; there is no memory, no prior conversation, no personalisation, and this is true whether the scan runs on your own key (BYOK) or on Managed AI. Your account, your searches and your history never leak into the result. The provider doesn't tailor an API answer to whoever owns the key. So when a brand's visibility looks surprisingly high, check the prompts first: the usual reason is prompt design, not bias. A prompt that names the brand ("What are Acme's strengths?") practically guarantees a mention, which lifts the headline number without proving the brand is recommended. That's exactly why we separate branded from non-branded (above) and surface the non-branded figure: it's the honest, bias-free signal, and the right number to track over time and to compare against other tools. If two tools disagree on a brand's visibility, the usual reasons are different prompt sets (branded vs unbranded), different model versions, and different numbers of runs — not one being "biased".

Not every AI answer is built the same way. On the Responses view you can filter by the features an engine actually used to produce an answer. "Web search" marks answers where the model retrieved live web sources before replying (grounded) rather than answering from its training memory — and the ungrounded answers are exactly where hallucinated or outdated brand claims tend to hide, so filtering to them is a fast way to audit risk. "Shopping" marks answers where the engine returned product recommendations. "URLs from memory" marks DeepSeek answers since 10 September 2026: DeepSeek ran no search, so the URLs in them come from model memory, not a search. They are shown under that label, never as sources, and no citation or source figure counts them. These flags are derived only from signal the provider genuinely exposes — the sources a model retrieved, and the products it recommended — never inferred or faked. We deliberately don't claim features our provider APIs don't report (such as ads or maps blocks): honest, verifiable coverage matters more than a longer feature list. Each response also shows its feature tags inline, so you can see at a glance how a given answer was assembled.

Winning the first answer is only round one. Real buyers keep talking: "best CRM for startups?" becomes "which of these is best for a small team?" — and a brand can win the broad recommendation and vanish the moment the ask gains one constraint. Follow-up survival measures exactly that. For a tracked prompt you write one realistic follow-up (the "narrower"); during the scan, right after the engine answers the original prompt, CrunchJunkie asks that follow-up in the same conversation and records whether your brand — and each competitor — survives into the second answer. The Follow-up view then shows survival rates per brand and per engine with the sample sizes behind them, over the last 90 days. A few honest mechanics. It's opt-in per project (AI Visibility → Settings → Follow-up survival) because a follow-up is a real second run: eligible prompts cost roughly twice as much, and every turn-2 is counted and metered exactly like any other check. Only prompts with a configured follow-up get one — we never invent the question; you write it on the Follow-up page, or have your assistant set it over the MCP connector (update_tracking_prompt) — and only conversation-capable engines take part: the direct-API engines carry the conversation, while the search-capture engines (Google AI Overviews, AI Mode, Copilot) and DeepSeek have no multi-turn channel and are honestly left out. The follow-up is asked in the project's language, the second answer runs through the same mention extraction as the first, and each turn-2 stores the exact follow-up text it used as immutable evidence. Three things are left out of the rate and listed under it, so the number only covers conversations that can say something: a follow-up the engine answered without naming any company (a counter-question, a refusal, a checklist), which is not a drop; answers to an earlier wording of a follow-up you have since changed, because two different questions are two different measurements; and conversations whose first answer named no tracked brand. Spelling variants count as the same brand ("Claneo GmbH" in the first answer and "Claneo" in the second is a survivor). One limit to know: if the second answer refers back without the name ("the first option"), the brand still reads as dropped. If you reword a tracked prompt, its follow-up is cleared so you write one that fits the new question. Below the rates, the page shows what else changed when the question narrowed, over the same conversations. Who is named when you drop out, whether you track them or not. Which sources the follow-up answer cites compared with the first answer. Which web searches the engine ran for the follow-up: the terms it kept from the first question, the ones it added itself, searches for a brand, and site: lookups. Each follow-up is marked by what it did (searched and cited, searched without citing, ran no new search when the engine reported an empty search list, or search not visible when no search list came back, as with engines that don't show their searches and with answers scanned before the engines' "no search" was recorded), and only follow-ups that ran a new search enter the source comparison, because the others have no sources of their own. An engine asked the same question twice already names partly different brands and sources, so every "kept" figure sits next to the same figure between two first answers to the same question on the same engine; the follow-up only did something if it moves further than that. A domain is labelled "cited more" or "cited less" only when an exact sign test says so over at least 8 conversations, and below 10 cases you see counts ("3 of 7") instead of percentages. A follow-up that names only companies you do not track counts as a drop. Open any conversation to read both answers with their sources and searches. These are API conversations with each engine (no account, no history, no personalisation), not a logged-in consumer app. Read the metric the way it's built: not "how visible am I?", but "when a real buyer narrows the ask, am I still in the room?" — a question no other visibility tool currently measures.

When an AI model answers a prompt it often cites the pages it drew on, and CrunchJunkie records every one. Which of those pages count as yours is decided by your own-domain list: every domain you tag Owned here, the domain of your last audit, the client website and any brand alias written as a domain (a group site, a second country domain). A brand with several sites gets all of them attributed as its own — in citations, fan-outs, source performance, the URLs view and content briefs — and because ownership is worked out when a page is read, a domain you add applies to past scans immediately. The Sources view ranks the domains cited most across your prompts and models within the date range you pick — the last 30 or 90 days, all time, or a custom from–to range — and the same range applies to the chart and the URLs view, so the three always describe one slice. Those are the sites actually shaping what AI says about your category. The URLs view goes a level deeper, listing the individual pages cited and how often each appears, so you can see exactly which articles, listicles or product pages the models lean on. Gemini names the site a source came from, never the page, so its answers count in the Sources view but not in the URLs view, and a note there says how many it left out; when every answer came from Gemini, the URLs view says so instead of asking you to run a scan. Gap analysis turns this into a to-do list. It surfaces the domains where AI cites a competitor but never you — your clearest content gaps. Each gap is a concrete opportunity: earn a mention on that source (a review site, a directory, an industry roundup) and you start appearing where buyers are already being pointed. Earn it, never fake it: no fake reviews, no invented sources, no sites that pose as independent while repeating your own claims. Google's spam policies count attempts to manipulate its AI answers as spam, and from 12 November 2026 Anthropic's usage policy bans using Claude to plant such sources. Because all three views are built from real scan citations, they update every time a scan runs. The URLs view also surfaces "Cited in AI, not (yet) winning in Google": your OWN pages that AI engines cite as a source but that rank low — or don't appear at all — in Google organic. It joins the AI citations to each page's average Google position across every Search Console property connected for the client (last 90 days), so you see the pages winning in AI before they win in Google — the ones to double down on. It reads all connected properties, not just one, so a page whose rank lives in a different property (a domain property vs a www / non-www prefix) is still matched. It's deliberately honest: Google's position is an impression-weighted average across queries (not a fixed rank), "No Google data" means no impressions in the window on the connected property — the page may not be ranking yet, OR that property doesn't cover the URL (e.g. a www-only property when the page lives on the bare domain) — and homepage / host-only citations that can't be matched to a specific page are counted separately. If most cited pages show no Google data, that's usually a sign the property covering the domain isn't connected, and a note points you to fix it. It needs Search Console connected for the client. Both the Sources and URLs tables carry a brand-mention filter with Any / All / None logic, so you can slice the citation set precisely. "Any of" shows sources cited in runs that mentioned at least one selected brand; "All of" shows only sources cited in runs that named several brands together — the fastest way to find a page that talks about you and a competitor at once; and "None" shows sources cited where no tracked brand was mentioned — untapped places not yet talking about anyone you follow. At the top of the Sources view is a Source health check. AI answers cite live web pages, and two source-quality problems are worth catching when they concern your brand: a dead link (a cited page that now returns HTTP 404 or 410 — it no longer exists) and a retracted source (a cited URL whose DOI is confirmed retracted by Crossref, which integrates the Retraction Watch database). Click "Check sources" and CrunchJunkie verifies the individual pages AI cited and flags any that are dead or retracted, with the exact status or DOI. It is deliberately conservative and accuracy-first: only a definitive 404/410 is called dead (a network hiccup never is), and retraction only covers academic DOIs — so it's most useful for health, science and research-cited brands, and simply shows nothing to flag for everyone else. Results are cached per URL and checked in bounded batches, so the check stays fast and cheap; re-run it any time to re-verify. The Query fanouts view shows the step BEFORE the citations: the web searches each engine actually ran before answering your prompts — the "fan-out". These are captured verbatim from the engines' own search tool calls during your scans (measured, never estimated), and they're the queries that decide which pages get read and cited, so they are what your content should answer — not just the prompt wording itself. Each engine searches with its own tool, not necessarily Google, so a Google ranking only matters for searches people also type into Google. A line at the top of the page says how the searches were produced: each model ran them via its provider's official API — no login, no memory — for the market in your settings, with the model, location and scan dates named. They are not a transcript of anyone's session in ChatGPT or another assistant app, where a logged-in person with a history may see different searches. Coverage is stated honestly on the page: fan-outs exist only from new scans onward, some engines never expose their searches (that's a provider trait, not evidence they didn't search), and Google AI Overviews, AI Mode and Copilot have no fan-out by construction — there, the prompt is the search. Each answer also records whether the engine ran no web search at all, which is not the same as an answer that came back without a search list (the engine may have searched without saying what for, or the answer was scanned before this was recorded); the page names both per engine, so a missing list is never read as no search. Perplexity's searches are read from the queries its Agent API returns with each set of results. Deliberately absent: search-volume figures. None exist for AI fan-outs, so none are shown. Three signals are read straight off the recorded searches — no model behind them. "Words the engines added" lists the words that appear in the engines' searches but not in the prompt the engine received — your prompt plus the market and language instruction CrunchJunkie sends with it, also as the engines write that market and language in the language they search in (Spain, España, Spanien) — leaving out your brand (in any capitalisation), your competitors (a competitor's name of up to four letters only exactly as you entered it, so a competitor called "Box" does not hide the word "box") and the engines' own names: the intent an engine assumes behind your prompt (a prompt about in-silico trials fanning out to "FDA guidance" and "validation" tells you what to write). Click a word to filter the table. "Sites looked up directly" lists the hosts an engine queried with a site: operator — its own shortlist for those prompts, with your domain marked when it is on it; competitors on that list while you are not is the gap to close first. And a "with a year" chip counts the searches an engine dated (2025, 2026 …): it wants current material, so a page that visibly carries this year's date has the edge. The page opens with four headline tiles — answers with fan-outs, distinct searches, site: lookups with your own count, dated searches — and every tile, panel and column header has a click tooltip that explains what the number is and how to act on it. Each search also shows where you stand in its outcomes, so you know which fan-outs to fix first. "You in the answers" counts, over exactly the answers that ran the search, how many cited your domain and how many named your brand — measured from real citations, never modeled — and the table's default order is plain subtraction: the searches shaping the most answers without you come first. "Cited instead" lists the third-party domains those same answers actually cited — who owns the search today; one dominant domain is a clear target, a fragmented field is a winnable search. And when Search Console is connected, a Google column joins your own Search Console data in two tiers that are never added together. The exact match is the primary figure: your average position and impressions for the same string once only case, accents, quotes and punctuation are ignored (so an engine's "crunchjunkie" in quotes matches your crunchjunkie row), with Search Console's own wording shown when it differs. A search that uses an operator — site:, a -term exclusion, OR, intitle: and the like — is narrower than its words ("site:semrush.com pricing" is not the query "pricing"), so it never has an exact match. Below it, in its own labelled box, a similar query: a shorter query from your Search Console whose every word appears in the search (at least two words, filler words ignored, operators removed first), shown in its own wording and with the engine's operator when there was one ("the engine looked this up on semrush.com only") — never your rank for this search. Where several such queries exist, their impressions and clicks are added up and the position is weighted by impressions, never a plain average of positions. A line above the table counts both tiers over every distinct search in the window: searches with an exact match, and searches with only a similar query — never the same search twice. When Search Console returns its maximum of 25,000 rows for a property, the page says so: rarer queries are missing there. Long machine-written searches rarely appear in Search Console because people rarely type them; a ranking only exists for searches people also type into Google. A search where you already rank in Google's top 10 for the exact search but AI answers never cite you is the highest-leverage fix of all, and it's flagged right on the row: the content exists, it just isn't being cited — a similar query never raises that flag. A dash means neither tier has a row for the window (Google anonymizes rare queries) — never proof you can't rank. If Search Console can't be read — access refused because the connection needs reconnecting, or an error from Google's API — the page says so per property and hides the column instead of showing "no matches"; when only some properties fail, it says that a dash may be a match in a property that failed. Two more panels read the searches themselves. "Brands named in the searches" counts, for your brand and each tracked competitor (names, aliases and the brand's domain from Settings, whole words — "PEEC-AI" and "peec.ai" count as Peec AI), how many distinct searches and how many answers name it inside the search string — a competitor named often is the one the engines check you against. Lower-case mentions of a competitor's one-word name are counted, with a note: if that name is also an everyday word, some of them may not mean the brand. Your own brand never carries the note. Clicking a brand lists exactly the searches it counted. "Recurring word sequences" lists the two- and three-word sequences that recur in at least two searches, counted in every search that contains them, with that count out of all distinct searches and how many of those searches came from a prompt that already contains it; sequences that start or end on a filler word, a tracked brand name on its own or cut in half, and sequences that are the prompt's own words or the scan's market and language instruction in every search that contains them are left out. Above the tiles, a prompt-type switch narrows everything to searches run for your Shopping prompts or for every other category — the type belongs to the prompt that triggered the search, the search itself is not classified — and a topic picker narrows it to prompts with one tag; "Group by topic" sorts the table into one section per prompt tag, where a search run for prompts with different tags appears under each. Each row links straight to the Content Brief for the prompt that triggers the search most. One-click views above the table narrow it to the searches that never cite you or to the rank-but-uncited set, alongside a free-text filter and a minimum-answers threshold for cutting the long tail of one-off searches. For a client imported from Peec AI, a switch above the page — Our capture / Peec — shows a second, separate list: the sub-queries Peec recorded in its own chats. For most engines Peec drives the consumer app, logged out, by browser automation; for some it calls the model's API instead, and each engine says which — "ChatGPT" is the app, "GPT 5 Search (API)" is an API model, and those rows carry an API badge. CrunchJunkie imports what the client's own Peec project already holds, with the client's Peec key, and scrapes nothing itself. The view is labelled "Peec AI (imported)", separates web searches from Peec's shopping lookups (with the products Peec listed for each; this is Peec's own classification of the query, not a prompt type), and counts Peec chats rather than answers. It is never added to our own fan-outs or to anything built on them — the counts, the signals, the Search Console column, Content Briefs — because the two are different capture methods over different conversations. Read them side by side: a search both record is a strong signal, and one only Peec's app capture records shows where the consumer app searches differently from the API. Peec's API marks no fan-out as predicted; every row names the chat it was observed in.

The URLs view shows, for every cited page, where it stands in its citation lifetime over the last 26 completed weeks: a status, its citation rate before and now, when it was last cited and a weekly trend. A click on a page opens its drill-down. A page's citation rate counts only its eligible answers: each week, the answers to the prompts, engines and markets that cited the page at least once in the 8 weeks before. The week in which a prompt first cited the page never counts toward its rate, so a page does not look as if it peaked the week it was found and then decayed, and prompts that never cited the page do not dilute it. Rates are pooled over the weeks (citing answers divided by eligible answers, once) and always shown with n, the eligible answers behind them. A week without eligible answers is a break in the line, never 0. Weeks run Monday to Sunday in UTC, and the statuses read completed weeks only: "before" is the 4 weeks before the last 2, "now" is the last 2 completed weeks. Answers whose cited sources are not known are not measured. Gemini names sites, not pages, so its answers count only per domain, and DeepSeek answers with URLs from model memory are left out, as on every source figure. A page has an established citation rate when, in the 4 weeks before, it was cited in at least 2 of the weeks, at least 3 times, in at least 8 eligible answers, at a rate of 15% or more. Steady: established, with no change we can tell from noise. Lost: established, and not cited in any of its eligible answers of the last 2 weeks, with answers in both weeks and at least 6 of them, and so many that chance is very unlikely: at the lower end of its earlier rate, the chance of no citation at all is 5% or less. The sample is shrunk where answers cluster by prompt and week, so a few busy prompts cannot make a change look certain. A lost page stays lost until it is cited again in at least 2 answers of a 2-week window (regained, shown for 4 weeks) or goes 8 weeks without a citation (ended: no answer counts as eligible for it any more). Fading: its rate now is half its earlier rate or less, on at least 8 eligible answers, at 95% confidence, two weeks in a row. Rising: twice its earlier rate or more, at 95% confidence, two weeks in a row; or a new page that the prompts which found it kept citing the week after, in at least 25% of 4 or more answers on at least 2 prompts. New: first cited in the last 2 weeks, on prompts we had been asking for at least 4 of the 8 weeks before. First measured: the same on a prompt or engine measured too briefly before to call the page new. A new page keeps its status for up to 6 weeks while it is still cited and too young to be established. No recent data: an established page whose prompts had no answers in one of the last 2 weeks (a paused prompt, a removed engine, a missed scan); it is never counted as a loss. Occasional: cited, but not established, so there are too few answers to call a trend. Most cited pages are occasional: at the default weekly scan with 2 runs per prompt only pages cited across several prompts or engines earn another status, and more runs per prompt or a daily scan sharpen it. A steady page marked with an asterisk was not cited in its last few eligible answers, too few to call it lost. The drill-down shows the status and since when, the rate before and now with n, the first citation (marked "on or before" when it falls in the week our measurement starts), the last citation, weeks cited out of weeks measured, the longest and current streak, how many prompts, engines and markets are eligible now, the weekly rate and, on the same weeks, the eligible and citing answers (also as a table), starting at the first week with any answers for the page (a note says from when, and how many weeks of the 26 came before), a marker wherever an engine changed model (once per change, dated by its first answer), the status per engine, the prompts that cite the page with their before and now, and the pages cited instead in the answers that dropped it. For a lost, fading or ended page it names a likely cause only when the data shows one: the page answered HTTP 404 or 410 when it was checked in the last 14 days, another page of the same site took over its prompts, the crawler of an engine that lost the page is blocked on your site according to the latest GEO audit, engines that lost the page and changed model carried 70% or more of its earlier citations (each named with its own share), a tracked competitor's page is now cited in at least 5 and at least a fifth of the answers that dropped it, or those answers cite fewer sources overall. Otherwise the cause reads unknown. The figures come from weekly counts built in the background from each project's answers: refreshed within about 10 minutes of every scan and checked every night, so the statuses are as of the time shown. Until the first build is done (usually within 10 minutes) the URLs view says it is preparing the citation history. In the MCP connector, get_cited_url carries any page's lifetime and list_citation_lifetimes lists every page whose status is not occasional (occasional pages are counted, not listed); Ask Crunch reads a short summary of the statuses with their n. In a report, the AI Visibility table "Citation lifetime" lists pages by these statuses. Two presets: "Pages losing AI citations" (your own pages that are lost, fading, or whose citations ended within the period) and "New competitor pages cited" (your tracked competitors' pages that are new, rising or regained); you can also choose the pages (your own, your tracked competitors' or all) and the statuses yourself. The statuses are as of the report period's last two completed weeks, against the 4 weeks before them, so a report on a past month shows that month's statuses; those 4 weeks can reach back before the period, and a footnote names the weeks read. Each row shows the status, the rate before and now as citing / eligible answers, the change in points, when the page was last cited, the weeks it was cited, the engines it is eligible on, and a Trend column with its weekly rate over 12 weeks (on unless you switch it off). Pages cited too rarely to call a trend are not listed. The table covers the whole project: of the widget's filters only Source applies (your scans, Peec AI's or both). Citation history reaches back 26 weeks, so for a period that ends before that the table stays empty and says why. It looks the same in the app, on a share link and in the PDF, and an AI summary reads its rows with their n.

Before an AI can mention a brand, its crawler has to be allowed to read the site. The Crawlability tool checks a domain's robots.txt against every major AI crawler — GPTBot and OAI-SearchBot (ChatGPT), ClaudeBot and Claude-SearchBot, PerplexityBot, Google-Extended and Googlebot, and more — and tells you whether each is Blocked, Partial or Allowed. Expand any crawler to see exactly why (which user-agent rule matched) and how to change it. The tool distinguishes training crawlers (blocking them keeps your content out of model datasets, often intentional) from search and answer crawlers (blocking these directly hurts your AI visibility), so you can make the right call per bot. The domain pre-fills from the client's saved website. The Crawlability check also re-runs automatically on the same weekly cadence as the GEO Audit, so its history and change-log stay current without a manual click — a new snapshot is logged only when robots.txt posture actually changes, and a badge on the page shows when it was last checked (amber if a check ever goes stale, older than about a week). Crawl insights is the companion view: once you forward your server logs, it shows how often each AI crawler actually visits the site — turning "we allow GPTBot" into "GPTBot fetched 40 pages last week". Together, Crawlability tells you who can read the site and Crawl insights tells you who is. One important caveat, because it trips people up: crawler visits show whether AI bots can reach you — not whether you're cited in AI answers. A model often mentions a brand from its training memory without a fresh crawl, and live answers usually cite from an index or cache rather than hitting your server per question, so low (or even zero) crawler visits don't mean low visibility. For whether you're actually being cited, use AI Visibility; Crawl insights is the access-side signal, not a citation count. The top-pages table connects the two sides per page: next to each crawled path, Read shows how many scan answers pulled that page while researching and Cited shows how many cited it as a source — each counted once per answer, matched to your site by page path, and only from answers that expose the genuine retrieved-vs-cited split. Gemini's answers are left out of both columns, since Gemini names the site a source came from, never the page. The two columns deliberately have different denominators — several engines expose citations but never their retrieved list, so Cited can exceed Read without anything being wrong; the footer under the table states both counts. Below it, "Cited in answers, not crawled in this window" lists your pages AI answers cite without any recent crawler visit — the norm, not an anomaly, for exactly the index-and-cache reason above. The one pattern worth acting on: a page bots fetch heavily that never gets read into an answer is content the models collect and don't use. When enough pages carry both events, a "Time to citation" line appears: the observed median lag between a page's first logged crawl and its first captured citation, with per-engine medians once at least three pages qualify. Observed is the operative word — both series begin when you connected logs and when citation capture started, and engines differ widely, so read it as what happened on this site, never as a promised speed; pages cited before any logged crawl are counted separately, for the index-and-cache reason above. "Broken for AI crawlers" is the per-page repair list: every URL that answered an error to an AI-bot fetch — dead links (404/410), server errors, rate limits — with the exact status counts and the bots that hit it. Deliberately absent from it: 403/406 edge blocks, because those are access policy rather than breakage and live in the Firewall & Access view — mixing the two would make intentional blocking read as a bug. Once logs are flowing, Crawl insights leads with AI Bot Traffic — the same hits grouped by the company behind the bots rather than the individual user-agent. It shows how many providers reached the site, total AI fetches, the share each provider took (a stacked bar — OpenAI vs Google vs Anthropic vs Amazon…), and the split between user-request fetches (a bot pulling a page live for someone's question) and search-and-training crawls. It's the fastest read of who is paying attention to the site and why. A provider groups all of its bots together (so OpenAI folds GPTBot, OAI-SearchBot and ChatGPT-User into one row), and every share is the provider's hits over the total, so the bars always add up to 100%. Requests to API and tool-call paths (anything under /api/, plus /mcp and the MCP/OAuth sign-in lookups under /.well-known/) are counted separately as API / tool calls: an AI client calling your MCP connector or an endpoint is not a person reading a page, and on one site 804 of Claude-User's 813 requests were exactly that. They stay in total fetches, but not in user requests or the top crawled pages, and the page shows their count and busiest paths on their own line. Each provider also carries a Verified level — the share of its fetches we could confirm came from that company's own published IP ranges. Some providers (OpenAI, Google, Perplexity) publish machine-readable IP-range feeds; we fetch and cache them and check each hit's source IP against them. A request claiming to be GPTBot from an IP outside OpenAI's published range is a spoofed user-agent and is never counted as verified. Providers that don't publish ranges are shown honestly as unverifiable rather than guessed — so a missing Verified score means "no way to check", not "fake". It's the difference between "a bot said it was ChatGPT" and "it provably was". Connecting the logs takes one of three routes, all on the Crawl insights page. On Vercel: Team settings → Drains → Add Drain → data: Logs → project: the one serving this site → sources: Functions, Edge Functions and Static Files → environment: Production → destination: paste the ingest endpoint shown on the page (JSON or NDJSON format — verification passes automatically). On Cloudflare: Logpush is an Enterprise-only feature, so on the free or Pro plan add a small Worker instead — deploy a forwarder (Workers & Pages → Create → Start with Hello World → paste → Deploy) and attach a Route at yoursite.com/*. The ready-to-paste snippet, with your ingest endpoint already filled in, is on the Crawl insights page under "Forward logs with a Worker." (Enterprise users can still use a Logpush job pointed at the same endpoint.) Anywhere else: upload a .log, .txt, .csv or gzipped .gz access-log file (combined/common format) with the Upload button — .gz files are decompressed in your browser, so a raw server log like sslaccesslog.gz uploads as-is. Privacy note either way: only AI-crawler hits are stored (bot name, path, status, time); human visitors' requests are discarded on arrival and never persisted.

AI crawlers do three different jobs, and blocking them has three different price tags. TRAINING crawlers collect content for future model training: OpenAI's GPTBot, Anthropic's ClaudeBot, Google-Extended (Google's AI training opt-out), Applebot-Extended, Amazonbot, Meta-ExternalAgent, ByteDance's Bytespider, and Common Crawl's CCBot — whose dataset feeds many models at once, so blocking CCBot opts you out of more than one company's training. Blocking a training crawler removes your content from what FUTURE models know from memory. It costs nothing visible today and doesn't touch live answers — it's a legitimate policy choice — but it compounds quietly: models that never read you cite you less from memory later. SEARCH crawlers feed the live-answer index that citations come from: OAI-SearchBot (ChatGPT search), Claude-SearchBot, PerplexityBot, meta-webindexer (Meta AI — Meta says allowing it "helps us cite and link to your content in Meta AI's responses"), Amzn-SearchBot, Applebot (which also powers Siri and Spotlight), Google-CloudVertexBot. Blocking these is a direct, immediate visibility cost — the engine can't retrieve your pages when composing answers, so it cites someone else. USER-TRIGGERED fetchers act only when a person asks: ChatGPT-User, Claude-User, Perplexity-User, Gemini-Deep-Research, meta-externalfetcher, DuckAssistBot, Mistral. Blocking these makes "read this page" fail live, in front of the exact user who asked about you. One special case outranks all of this: Googlebot itself feeds both classic Search AND AI Overviews — controlling AI use of your content is what Google-Extended is for; blocking Googlebot for GEO reasons would take your Google Search visibility with it. Two traps are worth knowing. First, most "block all AI" robots.txt recipes take out the search and user-triggered crawlers along with the training ones — paying the immediate visibility cost to get the training opt-out, usually unintentionally. The Crawlability tool separates the two classes per bot precisely so you can block training crawlers while keeping the live-answer ones. Second, a User-Agent string is trivially forged: anyone can send "GPTBot" in a request header, and in real production logs a large share of claimed AI-crawler traffic is exactly that. The only trustworthy identity check is the provider's own published IP ranges. OpenAI (openai.com/gptbot.json and companions), Google (developers.google.com's crawler IP feeds) and Perplexity (perplexity.ai/perplexitybot.json) publish machine-readable feeds; Crawl insights checks every logged hit claiming those providers against the live feeds and marks it verified or spoofed. Providers without a confirmed machine-readable feed are marked UNVERIFIABLE — deliberately: some vendors document reverse-DNS lookups instead, and where we can't verify against an official source we say so rather than guess, because a wrong "spoofed" would smear a legitimate crawler. The Crawler identity verification card on the GEO Audit page shows your own verified-vs-spoofed split from your forwarded logs.

Everything above can go into a report. Add a Table widget, choose the AI Visibility source, and set its dimension: Brand, Model, Brand × Model, Perception, Prompt, Gap analysis, Cited URLs, Source domains, Trending URLs, Crawler visits, AI bot traffic, Crawl sections, Crawler access, Tag, Brand × Tag, Tag × Month, Brand × Month, Topic, Biggest Movers, Cited Sources, Source Performance, Source Health, Retrieval & Citations, plus the shopping set (Shopping, Product, SKU, Product Schema, Feed Readiness, Shopping Sources) covered in the AI Shopping Visibility guide. Every one of them reads the report's date range and carries its sample size, so the client sees the same honest numbers you do. "Gap analysis" puts the content-gap list in front of the client. Each row is a domain the models cited, with four figures: "Cited with competitor" is the number of scan runs where that domain was cited and a competitor was mentioned, "Cited with you" is the same count for the client's own brand, "Gap" is the first minus the second, and Runs is how many runs the domain appeared in at all. A domain counts at most once per run — ten citations of the same site inside one answer is one appearance, not ten — so the figures read as reach rather than repetition. Only rows with a positive gap are shown: a domain that cites you as often as your rivals isn't an opportunity, and neutral rows would bury the ones worth acting on. One difference is worth knowing before a client asks about it. The Gap analysis page inside the app looks at every run ever recorded, because it's a working tool and you want the complete list of gaps in front of you. The report widget honours the report's date range instead, because a client report covers a period. So the same project can legitimately show more domains on screen than in last month's report — that's two tools answering two different questions, not a discrepancy to chase. "Prompt" breaks results down by the individual question rather than rolling them up. Tag and Topic group prompts together, which is the right grain for a theme and the wrong one for "when someone asks this exact question, do we appear?" — the question clients actually ask. Each row shows the prompt's tags, the day it was first tracked, its Visibility (the answers that named the brand, divided by the prompt's answers in the period) and, when the report compares periods, the change in percentage points. A change that is not clearly beyond the margin of error starts with "~"; then a note under the table gives the change that is clear on the rows shown (twice the margin of error of the change, both periods' margins combined) and the answers per prompt behind it. With a few dozen answers per prompt only large moves are clear, so most changes read "~": at that sample size a moderate move cannot be told apart from noise. "Tracked since" is the day of the prompt's first stored answer, not the day the prompt was created: for prompts imported from Peec AI the creation date is the day of the import, while the first imported chat says when Peec started asking it. Rows are sorted worst-first, because a report about AI visibility is more useful opened on the questions you are losing than the ones you already win; the widget's Sort can order them by prompt, Visibility or its change instead (a table saved before 8 October 2026 keeps its worst-first order until you pick a sort). Until 8 October 2026 the Visibility column was called "Mention rate", and the table counted answers differently from the Visibility KPI: on a project with both Peec AI data and our own scans, an engine that both track was counted twice on a day both measured it. The table now counts it once, as the KPI does, so on such projects a saved Prompt table's Visibility and Runs can change, and Runs go down — the earlier figures counted those answers twice. The Topic table and the Tag table (without the extra metrics) follow the same rule since 9 October 2026: their rate is called Visibility (it was "Mention rate") and each row is the Visibility KPI filtered to that topic or tag, so on such projects their Visibility and Runs can change too, and Runs go down. Filtered to one market, the Prompt, Topic and Tag tables keep the answers stored without a market (from before markets were recorded) under the project's own market, as the Visibility KPI does; until 9 October 2026 the Prompt table left them out. Tags get four views of their own, built for agencies that report one product or theme at a time. "Brand × Tag" is a heat map: your client and its tracked competitors down the side, the tags you pick across the top in the order you set, each cell the share of answers that named the brand, with the change against the previous period in points underneath and the number of answers at the head of every column. A change that is not at least twice its margin of error (the KPI cards' rule) is printed grey with a "~" in front, here and in the change columns of the other tag tables. The widget's own filters apply to every column: set a product tag such as "Inhaltsversicherung" as a filter and each column adds its own tag to it, while an optional Total column shows the filters alone. Heat shading is optional and comes with a low-to-high legend. "Tag × Month" and "Brand × Month" put the calendar months of the widget's range across, end with the change against the previous month and against the first month, and print "—" for a month without answers rather than a zero. The "Tag" table can now show Visibility, Retrievals, Retrieval Rate, Citations and Citation Rate per tag, each row being exactly the KPI card filtered to that tag, with an optional change column per metric, a Total row, and your own choice and order of tags; on Peec AI data alone its rates are per chat, as on the KPI card. On a Peec AI project, a column with one tag and the Source filter set to Peec AI reads Peec AI's own per-tag figures; a column that adds its tag to a tag already in the filters is recomputed from the imported chats, because Peec AI reports one tag at a time, and the widget says which columns did which. A report template keeps its tags, Tag filters included, by name: applied to a client, it keeps the tags that client's prompts use and drops the others, naming them on the widget in the editor. A column or cell with fewer than 30 answers behind it is marked as indicative only. The Prompt, Topic, Tag (both kinds), Brand and Source domains tables can show a Trend column; switch it on in the table's settings, or ask for a trend when you add or edit the widget with Ask Crunch or the MCP connector. It draws a small line per row: the row's Visibility (on Source domains, the domain's share of answers, or of chats on Peec AI data alone; on an extended Tag table that shows no Visibility column, its first Retrieval or Citation rate, or the rate behind its first Retrievals or Citations count, in the unit its column uses) for each week of the report period, Monday to Sunday and cut to the period, or for each calendar month when the period is 180 days or longer. Each point is computed from the same answers as the row's own value, over that week only, so it equals the KPI card filtered to that row and those days; weeks are never averaged into one another. A week in which the row had no answers leaves a gap in the line, never a 0, and a week with fewer than 30 answers shows a hollow point and counts as indicative only. Each line has its own scale, at least 10 points tall, so a fraction of a point does not look like a swing; hover over a point for its value and the number of answers behind it (for a Retrieval rate, the answers that list what they retrieved; for a Citation rate, the answers that retrieved your site: each rate is computed over those only). The column looks the same in the app, on share links and in the PDF. AI summaries read the weekly values, and the MCP connector's get_report_data returns them per row, null for a week without answers, with the answers behind each one. "Cited URLs" is the page-level counterpart to Cited Sources. Cited Sources is domain-only, so a Reddit thread, a review article and a forum post all collapse into "reddit.com" — right for "which sites matter", wrong for "which page do we need to get onto". Each row is an actual URL with a rough page type, how many answers used it as a source, how many of those cited it, and whether your brand or a competitor was mentioned in those same answers. Both tables name their first count for what it counts: on a view that holds only Peec AI data it is "Retrievals", the pages Peec says the model retrieved; otherwise it is "Appearances", the pages an engine retrieved or cited. The "Citations" column beside it counts only the cited ones, and shows "—" where none of those answers reports its citations; on a view of Peec AI data only it counts every citation, as Peec AI does, so a page an answer cites twice counts twice and Citations can exceed Retrievals. Until 8 October 2026 that first count was labelled "Citations". The Sources and URLs views label their counts the same way. Gemini names the site a source came from, never the page, so Gemini's answers are not counted in Cited URLs, and a footnote says how many were left out; they count in Cited Sources and Source domains. A Cited URLs or Trending URLs table whose answers all come from Gemini says exactly that instead of "No data for this period", in the app, on shared links and in the PDF. "Source domains" answers "which sites do AI answers lean on, and how much?". It ranks domains by their share of chats: the answers that used at least one page of the domain, divided by every answer in the widget's filters, Tag included. Each answer counts once per domain, however many of its pages it used, so a domain at 30 % was in three answers out of ten (on Peec AI data this is Peec's retrieved percentage). When the report compares periods, a second column shows the change in percentage points. Retrievals (on a view of Peec AI data only) or Appearances and Citations follow the same rules as the Cited Sources table, and the Category column shows Peec AI's classification of the domain (Editorial, UGC, Corporate, Institutional, Reference, Related, Other, or a class you defined in Peec), read at each Peec sync for Peec's last 90 days. Your own domains and your tracked competitors' domains always read Own and Competitor. On our own scans, where Peec has no classification, CrunchJunkie uses a fixed list of well-known review, social, reference and news sites, marks those categories as its own, and leaves other domains blank rather than guessing. Your domain is highlighted; when it falls outside the table, a footnote gives its rank. The Limit sets how many domains show (10 by default). "Trending URLs" shows which pages AI answers are turning to more. It takes the period's most-used pages (the 20 with the most retrievals by default) and lists the ones whose count rose most against the previous period: the previous and the current count, the change, and the change in percent, or "new" when the page was not used before. On Peec AI data the table adds the page title Peec reports and Peec's page type; otherwise the page type is CrunchJunkie's rough guess from the URL. The previous period is the report's comparison period, or the period of the same length just before when the report has none, and a footnote names it. When prompts were added after the previous period began, so the previous period covered fewer prompts, a second footnote says so: part of the rise then comes from prompts the previous period does not fully cover. When the previous period has no answers at all — tracking had not started, scans were paused, or an import does not reach back that far — nothing is compared: the previous count and both changes read "—", the pages are listed by their current count, and the footnote says there is no previous-period data. "New" only ever means a page that was not used in a previous period that does have answers. Like Cited URLs, the table leaves Gemini's answers out of both periods and says in a footnote how many. Your own pages are highlighted. "Rank from the top N URLs" and the Limit set the two numbers (20 and 10 by default). "Crawler access" is the bot-by-bot robots.txt posture, sorted blocked-first so problems surface at the top. Note it is NOT date-ranged like the others: it reads the most recent crawlability check, because robots.txt posture is a current state rather than something that accumulates over a period. Showing it as of an arbitrary past date would be misleading, since it may well have been fixed since. "Crawler visits" is the other new table, and the one piece of AI-visibility evidence that is measured rather than sampled: it lists the AI crawlers that actually fetched pages from the site, read from server logs. It needs crawl-log ingestion set up for the project first — see the AI crawlers & crawlability guide for how it works and what an empty table means. "AI bot traffic" is the provider-level version of that table: one row per company (OpenAI, Google, Anthropic, Amazon…) with its total fetches, its share of all AI fetches, and the split between user-request and search/training crawls. It's the same summary the Crawl insights page leads with, so the report and the app always agree. Like Crawler visits it's measured from server logs and needs ingestion wired up first. "Crawl sections" splits the same page fetches by site section (/blog, /products, /docs…), exactly as the "By site section" card on the Crawl insights page does: requests, their share, the three busiest crawler operators, distinct URLs, the share answered 2xx, refused (403/406) or failed, and the last crawl. A footnote says how many fetches carried a status, what was left out, and that a fetch is access, not a citation. The GEO Audit source adds one more: a "Competitor crawler access" table that benchmarks your robots.txt against your competitors' — one row per AI-answer crawler showing whether YOU block it and how many of your competitors do, so "you block ChatGPT while most competitors allow it" jumps out. It's populated once you add competitor domains in the AI-visibility project's settings (only domains you enter are checked), and it renders in the app, on shared links and in the PDF. A competitor whose robots.txt can't be read is left out rather than guessed at. The GEO Audit source also has a "Firewall & access policy" table. Where "Crawler access" reports only what your robots.txt says, this one joins that with a live probe: it fetches your homepage, and one content page from your sitemap, with each AI-answer crawler's user-agent and checks whether the request actually got through. The content page matters because Cloudflare's AI-crawler default since 15 September 2026 blocks agent and training crawlers only on pages that show ads: a crawler can pass the homepage and be refused on your articles, and the table then says "Blocked on content pages". Cloudflare is named as the likely cause only when that page's own responses carry Cloudflare's edge markers and the blocks follow its pattern (agent and training crawlers refused, search-only crawlers let through); otherwise the note stays vendor-neutral. Since 9 October 2026 a confirmed block on the content page also counts in the audit's live-reachability check, exactly like one on the homepage, and the check names the page ("Homepage reachable for every probed crawler; /blog/x blocked for ChatGPT-User"); until then the score read the homepage alone, so a site blocked only on its articles passed. The free GEO audit on our website runs the same two-page probe. The column that matters is the verdict — "Firewall blocks" means your robots.txt allows the crawler but a firewall or CDN refuses it anyway (an HTTP 403/406 the crawler hits before robots.txt is ever consulted), so the crawler can't read or cite you no matter what robots.txt says. It fills in after a GEO audit runs a conclusive probe, covers the eight crawlers a block can be pinned to — the search crawlers (OAI-SearchBot, PerplexityBot, Googlebot, Meta AI's meta-webindexer), the live agent fetchers (ChatGPT-User, Claude-User, Perplexity-User) and ClaudeBot — and renders in the app, on shared links and in the PDF. A bot-challenge or rate-limit is shown but never counted as a confirmed block.

Larger projects benefit from a little organisation. The Brands view manages the exact names CrunchJunkie matches as mentions — your client plus its competitors — including spelling variations and aliases, so a mention is never missed or miscounted. One case needs care: a brand whose name is also an ordinary word, a month or a generic term (an agency called MAI and the German month Mai, pilot, Neuland, Conclusion). CrunchJunkie counts such a name only where the answer uses it as the name of a company — in a list of vendors, with a location, a legal form or a figure — and not where it is simply a word, such as a date or a heading. If you track a name like that, add the legal form or the domain as an alias ("MAI GmbH", "mai.de") — it gives the extractor an unambiguous spelling to match as well. Tags let you label prompts (by theme, funnel stage, or client priority) and then filter every metric by tag, which is the fastest way to answer questions like "how visible are we on bottom-of-funnel comparison prompts?". Project Settings is where you control the brand name and website, the competitor list, which models run, runs-per-prompt, and the scan schedule. Scheduling is off, daily, or weekly — and you pick the exact time (and, for weekly, the day) it runs, in the project's time zone, so scans land when you want them. A time you change is kept in the project's zone, or in your workspace's (Settings → Preferences) if the project has none, and saving another setting never moves it; a schedule saved before time zones existed runs, and is shown, in UTC. An AI assistant that changes the time through the MCP connector (update_scan_settings) follows the same rule unless it names a time zone: a changed day or hour is always saved with its zone, and a day, hour and zone equal to the project's change nothing. On a day the clocks change, a scan due in an hour the clocks skip runs right after the jump, and an hour that happens twice scans once. A new project starts with a slot of its own: a weekday and a night hour in your workspace's time zone (Settings → Preferences), spread so that projects don't all scan in the same hour; projects created before October 2026 keep their schedule. Scheduled scans run on our servers, many workspaces' scans side by side with the workspaces taking turns, so one workspace's large batch never holds up another's scan. Changes here apply from the next scan onward.

Already tracking AI visibility in Peec AI? You can import a Peec project straight into CrunchJunkie instead of running native scans for that client. Under Data → Integrations, open Connect on the Peec AI card, choose the client, and paste a project-scoped Peec API key (created in Peec under Account → API Keys). CrunchJunkie verifies the key, then imports the project's visibility, share of voice, sentiment, average position, prompts and cited sources. Once imported, the data populates the exact same AI Visibility screens and report widgets as native scans — Overview, Prompts, Sources, Gap analysis and the report builder all work unchanged. The project is marked as Peec-sourced so the origin of the numbers is always clear, and re-syncing pulls the latest figures. Note that Peec's REST API is currently part of their Enterprise/beta tier, so the key needs API access enabled on their side. Brands stay in step with Peec on their own. Every sync reads Peec's brand list and mirrors it into the project: a Peec brand that matches one of your competitors by name, alias or domain, in any spelling, is linked to it (Peec's spelling becomes an alias, your display name stays), and a Peec brand you do not track yet is added as a competitor under Peec's name with its aliases and domain. Nothing is ever removed, so a competitor you track only natively stays. Whenever brands change — through the mirror, the Brands page, project settings or the MCP connector — the imported chats are re-read automatically so the new or newly linked names get their measurements from Peec's own brand detections; Sync on the Peec card does the same on demand, and Verify/Repair appears when the card reports missing chats. A report's brand ranking always compares brands over one shared set of answers — the runs on which every listed brand was measured — so Share of Voice adds up to 100 % and a brand added late is never scored over a smaller sample than the others. Peec's fan-out queries — the searches behind each Peec chat, from Peec's /queries/search and /queries/shopping — are imported by a separate background job every hour, never by Sync or the daily metrics refresh, so a slow Peec can never hold those up. They go into their own table and appear on Query fanouts under Peec and in the MCP connector's get_query_fanouts with fanoutSource "peec", always as a separate source. The first import reads the last 90 days; later ones continue from the last whole day read in full and read the three days before it again, because Peec keeps adding chats to a day after it ends — so "Imported through" is never today. A day with more fan-outs than one import reads is continued where it stopped, web searches and shopping lookups each have their own share of every import, and every request stays inside a time budget and well under Peec's rate limit. A large project's history can therefore take a few hours to arrive; the page says while it is still catching up, shows an error if Peec refused, and notes it when Peec listed more rows than it returned. Fan-out rows older than 400 days (about 13 months) are deleted every day, whether or not Peec is still connected. Disconnecting Peec AI deletes all of them at once, with the stored key, and a later reconnect imports them afresh. If the key is replaced with one for a different Peec project, the previous project's fan-outs are removed and the new project's are imported from scratch; a rotated key for the same project keeps them. Tag-filtered widgets on a Peec project. When a report widget is filtered by Source = Peec plus one Tag, it shows Peec's own figures for that tag — the brand list, Share of Voice, Sentiment and Position exactly as Peec's dashboard reports them — imported once a day rather than recomputed from the chats. Note the one definition that differs: Peec's Share of Voice counts every occurrence of a brand, repeats within one answer included, while the native Share of Voice counts answers; Visibility and Mentions are identical either way. Any other filter combination keeps the chat-based computation. The same rule applies everywhere else a Peec project is shown — the Overview, the API and the MCP connector: whenever the view contains Peec data only (a project without native scans, or the source switch set to Peec), Share of Voice counts every occurrence as Peec does, so the figures equal Peec's dashboard. As soon as native scans are in the same view (the blended source), Share of Voice counts answers for every brand, because that is the one unit both sources share; a blended table is therefore not meant to match Peec's dashboard, and switching the source to Peec gives Peec's figures again. Retrievals and citations on Peec data (8 October 2026). The same rule decides how Retrievals, Retrieval Rate, Citations and Citation Rate are counted. Whenever a view holds Peec data only, they use Peec's own definitions, computed from the imported chats: Retrievals are your pages retrieved, summed over all chats; Retrieval Rate divides them by every chat (pages per chat, e.g. 0.37 — not a percentage); Citations count every citation of your pages, as Peec does, so a page an answer cites twice counts twice; Citation Rate divides the citations in the chats that retrieved your domain by the number of those chats (e.g. 1.58 per chat). Peec's "Used as source", the share of chats that retrieved your domain, is the Source Appearance Rate. Before this date a Peec chat that cited nothing dropped out of Citation Rate's denominator, which pushed the rate up, and a chat without sources dropped out of Retrieval Rate's; both now count as zero, for chats imported earlier too, without a re-import. Since October 2026 the import also stores how often each chat cited each page (Peec's citation_count), so these figures count citations the way Peec does. They can still differ from Peec's own reports where prompts were paused or deleted in Peec: its reports count only its active prompts, while the chats already imported for those prompts stay here. Chats imported before then held only which pages a chat cited: until they are read again, each page they cited counts once, and every widget, KPI card and the Overview say under the figure how many such chats it holds, in the app, on shared links, in PDFs and in the AI summary's data. Retrievals, Retrieval Rate and Used as source are unchanged, and so are all figures of our own scans and of views that mix them with Peec data. The Cited Sources, Cited URLs and Source domains tables count Citations the same way on a view of Peec data only. A view that mixes native scans with Peec data keeps the answer-based definitions — answers that retrieved or cited your domain, rates in percent. A period in which the client's Peec chats retrieved pages but not one of them cited anything did not capture citations (chats imported before 2 July 2026, when the import started storing cited pages, and never synced since), so its Citations and Citation Rate show "—", never 0; on a line chart the per-chat rates get their own axis next to percentages. A chart whose range holds periods with Peec data only next to periods with native scans counts every point the answer-based way, so that the line keeps one unit, and since 9 October 2026 it says so under the chart and names the Peec-only periods. A period-comparison chart that sets a Peec-only period against one with native scans, and a Month or Week table whose periods are mixed that way, count the same way and carry the same note. The AI summary reads every chart series, and a per-chat rate, with its unit, so 0.37 per chat is never read as 37 %. Disconnecting Peec AI (Data → Data sources → Disconnect) deletes everything imported from Peec for that client, with the stored key: the answers with their sources, Peec's daily and per-tag figures, the fan-out queries and the prompts imported from Peec. A prompt that CrunchJunkie's own scans also ran, or that a content brief was made from, stays and only loses its link to Peec; the content brief stays too, without its quotes from Peec answers. The Perception analyses and brand suggestions built from the answers are cleared at once (run Perception again to analyse what is left), and open signals computed from Peec's data are resolved. If a client ended up with two Peec connections (a Connect submitted twice could create a second one; it no longer can), both go. From the moment you disconnect nothing more is imported. Most imports are deleted at once; a very large one takes a few minutes, during which the source shows as Removing in the list and every view of the client — the app, reports, shared links, PDFs, the API and the MCP connector — shows its own scans only. Your own scans, other clients, and the competitors that Peec's brand list added to the project stay as they are. Reconnecting imports the Peec project afresh.

Peec-imported data and CrunchJunkie's own (native) scans live side by side on the same client without clobbering each other. Every data point is tagged with its origin — "peec" or "native" — and the two are stored under different model names (Peec uses friendly labels like "ChatGPT" and "Perplexity"; native scans use the specific model versions they call, e.g. ChatGPT on GPT-5.6 with web search, or Perplexity through its Agent API). Because of that they never overwrite one another: running a native scan adds native data alongside the imported Peec data rather than replacing it, and a Peec re-sync only refreshes its own imported rows. When a client has both, the AI Visibility overview shows a source switch — All / Native scans / Peec AI (imported) — so you can view either source on its own or together. One thing to keep in mind: in the combined "All" view the same assistant can appear twice (once from Peec, once from a native scan), so for a single client it's best to treat one source as your source of truth and use the switch when you want to compare. A Peec-imported project won't start native scanning on its own — it has no native prompts and its scan schedule stays off until you add prompts and choose to run them.

Settings → Billing shows a usage ledger under the Managed AI meter: every check this period, broken down four ways — by client, by engine, by day, and by where the scan was started. It shows two numbers side by side, and the difference between them matters. Scans is how many times we actually queried an engine. Checks used is what that deducted from your allowance. They are not the same, because premium engines (ChatGPT, Claude, Grok) count 3× — so 200 scans on ChatGPT is 600 checks. Premium engines are marked with a ×3 badge, and when the two numbers differ the ledger states the reconciliation outright: "N scans became M checks once premium engines were weighted." Managed checks and your own-key checks are listed in separate columns and never added together. Managed checks draw down the package you pay for; own-key checks run on your API key and cost you nothing here. A single combined number would not describe anything real. What it costs. Own-key checks cost nothing here, but your providers bill them, so the ledger estimates that: a "≈ Own-key cost (USD)" column on every row and on the total, labelled "≈ cost on your own provider bill". It prices each own-key scan's tokens at the provider's list price when the scan ran, plus its search or grounding fee, in US dollars because that is what providers charge in, and names the day our price table was last checked (a weekly check of each provider's pricing page; a price that differs or cannot be read keeps the date where it was). Because each scan is priced at the rate of its own day, a provider's price change never re-prices your earlier scans. It is an estimate: your provider's own bill is authoritative and can differ, mostly through search and grounding fees, cached tokens, discounts and monthly plans such as SerpAPI's. The step that reads each answer (Claude Haiku) runs on CrunchJunkie's key and is not in the estimate, unless an Anthropic key is saved as your AI assistant key; then it lands on your Anthropic bill too, and the ledger says so. Scans from before 3 July 2026, when the ledger began recording whose key ran each scan, cannot be priced: they show "—" and are left out of the sum, never counted as zero, and the statement says how many there were. When a provider reported no token count for a scan, it is priced from a typical scan: your own average for that engine in the same range when at least 10 of its scans reported tokens, otherwise our default, and the statement says how many scans that applies to. Managed checks have no cost column, because your package pays for them: for the current period the total reads "included", or shows the overage so far (checks beyond your allowance and carried-over checks, times your overage price, in your billing currency). It appears once, on the totals, because overage belongs to the whole period rather than to any one row; earlier periods' overage is on your invoices. If the package was taken or cancelled during the period, the meter counts only from that moment: the statement says so, gives the checks since then, and leaves anything earlier in the period to your invoices rather than guessing. "Last 30 days" and "Last 90 days" are whole UTC days ending today, from 00:00 UTC, and "Previous period" covers at most 31 days; since October 2026, so totals for those ranges can be slightly lower than the same ranges showed before. The two amounts are in different currencies and on different bills, so they are never added. The CSV carries the estimate for each own-key scan in own_key_est_cost_usd, with own_key_cost_note beside it, after all the existing columns so a sheet built on the old file keeps working; on managed rows both are blank. The billing meter shows the same estimate under its BYOK figure, and the connector's get_usage returns it as byokCost. Use it to answer the questions the meter alone cannot: which client is consuming the package, whether a premium engine is worth what it costs on a particular project, and whether a spike was one bad day or a steady climb. There is a PDF export for passing the breakdown to a client or into an expense system. "Started from" answers a question the other tabs cannot: whether checks came from a scan someone clicked in the app, from a scheduled scan, from an AI assistant acting through the MCP connector, or from an automation. Metering is identical on every path — a check costs the same wherever it was started — so this tab is attribution, not pricing. An assistant's own reasoning on an MCP call runs on your ChatGPT or Claude subscription and never appears here; only scans it starts (after your confirmation) do. The same split is returned by the connector's get_usage tool. Under the table, the tab also lists assistant messages on Managed AI in the same window by where they were started, a separate allowance from checks: answers and report analysis in the app, the monthly copies' summaries, the connector, automations, and "Report emails", the AI summaries rewritten before a report email went out. get_usage returns this month's as assistantMessages.bySurface. Checks for a client that has since been deleted appear as "Deleted client:" followed by the brand that was scanned. Checks recorded before July 2026 have no client attached and appear as "No client (before July 2026)"; checks recorded before 23 September 2026 have no starting surface and appear as "Not recorded". All of them are shown rather than dropped, so the parts always add up to the total.

You can run scans two ways. Bring-your-own-keys lets you connect your own API keys for each model; CrunchJunkie runs the scans through them and you pay only the providers' usage rates, with no markup. Keys are encrypted at rest. They run your scans, and an OpenAI, Claude or Gemini key also powers Crunch's AI features (report summaries, Ask Crunch, content briefs) unless you add a separate assistant key; Grok and DeepSeek keys run scans only. This is the most cost-effective option if you already have provider accounts. Managed AI is the no-setup alternative: CrunchJunkie runs the scans on our own infrastructure, with no keys to manage. Every engine you switch on runs on CrunchJunkie's own provider keys (during the 14-day trial, Perplexity only). It is metered by check (one check = one prompt, run once, on one engine — the scan and its follow-up analysis count together as a single check). You pick a monthly package with an included check allowance, from €25/mo (Lite, 645 checks) up to €399/mo (Scale, 12,250 checks), and pay €0.05/check beyond it (all excl. VAT). Efficient engines count 1× per check; premium engines (ChatGPT, Claude, Grok) count 3× — so 100 scans on ChatGPT uses 300 checks, not 100. There is no limit on how many prompts you track, on any plan. Cost is governed by the check allowance, which measures what actually drives it: prompts × engines × passes. Unused checks roll over. Whatever is left at the end of a month is carried into the next one and spent only after that month's fresh allowance, so nothing you paid for expires while you still hold the package. The balance accumulates up to six months' worth, and is forfeited if you cancel Managed AI — it is a benefit of holding the subscription rather than stored credit. During the free trial we cover a single Managed engine (Perplexity) so you can see real data before paying for anything. It cites the pages it used, so content briefs work during the trial too. A trial that started on Gemini, before the switch in October 2026, keeps Gemini until it ends. When the trial ends, that free engine is switched off and nothing is added to your plan: Managed AI is opt-in only. To keep scanning, pick a Managed AI package under Settings → Billing, or add your own API key and scan at no markup. We remind you by email a few days before, and your prompts, results and schedule stay exactly as they are. You can mix Managed and your own keys, turn individual engines on or off, and set a spend cap that pauses Managed scans before a bill surprises you (your own keys keep running, since we never cap what you pay for directly). See the pricing page for current Managed AI details.

The unit is the check. One prompt, asked once, on one engine, is one check — unless it's a premium engine (ChatGPT, Claude, Grok), which counts as three. Every total below is just that, multiplied out: prompts × passes × the sum of the engine weights. One scan. Say you track 10 prompts and run them on the four Balanced engines — ChatGPT (premium, 3×) plus Perplexity, Gemini and Google AI Overviews (efficient, 1× each) — at two passes. One pass of one prompt is 3 + 1 + 1 + 1 = 6 checks; two passes is 12; across 10 prompts, a single scan is 120 checks. One month. Scanned weekly, that's about 4.3 scans a month ≈ 516 checks. Scanned every second week, about 258. Against a package. Managed AI Lite includes 645 checks for €25/mo. Both cadences fit inside it: weekly (≈ 516/mo) leaves about 129 checks, which roll into next month. Track 15 prompts instead and the same setup is 180 checks a scan, ≈ 774 a month: 129 over, billed at €0.05 each — €6.45, so €31.45 that month (excl. VAT, like every Managed AI figure) — unless you've banked rollover, which is always spent before any overage. Unused checks bank up to six months' worth. Overage is billed on the invoice that closes the month it was used in, including the last month if you cancel. If you move to a bigger package during a month, overage you had already used stays billed; it counts toward any overage on the new package, so no check is charged twice. The cheapest pulse. Lite scan mode — two efficient engines at one pass — is just 2 checks per prompt per scan. Tracking 20 prompts weekly is 20 × 2 × 4.3 ≈ 172 checks a month, well under a third of the Lite allowance. Two things never cost you a check: there's no limit on how many prompts you track (only scanning them draws down the allowance), and a failed check — retried up to three times — is never counted, on Managed AI or on your own keys. (A check that failed because its answer arrived empty or cut off is not counted either, though on your own keys the provider bills the call it answered.) On your own keys none of this is metered by us at all: you pay each provider's rate directly, per answer and without any weighting, so their bill follows the raw count — prompts × passes × engines.

Before setting up a full project, anyone can try a quick version at /ai-visibility-check on the marketing site — no account, no signup. Enter a brand (and, optionally, up to three of your own prompts and an email for the fuller write-up), and CrunchJunkie runs a small, real scan on the spot: it queries a single web-grounded AI model a handful of times and reports how often the brand was mentioned as a Visibility %, with the exact sample size ("n = … runs") and a boundary-safe margin of error (± %), plus any real sources cited. It's deliberately a small sample on one model, and the page says so — it's an honest snapshot, not a fabricated score, and if a run or two fails the number is recalculated on what actually completed. It's a good way to show a prospect what AI is saying about them in under a minute; the full product tracks continuously across all ten models with many more prompts, competitors, sources and trends over time. Use it as a lead-in, then create a project to go deep.

If you open ChatGPT (or Gemini, Perplexity) on your phone, run one of your prompts, and compare it to a CrunchJunkie scan, the answers usually won't match exactly — and that's expected. AI answers are non-deterministic and personalised, so a single manual check and a controlled scan measure different things. Five reasons they diverge: • Different model. The consumer ChatGPT/Gemini/Perplexity apps use whatever default model and built-in web search your account gets. CrunchJunkie scans a defined list of specific model versions via their APIs (e.g. ChatGPT on GPT-5.6 with web search, Perplexity through its Agent API, Gemini, Google AI Overview). Different model, different answer. • Personalisation. Your app carries memory, custom instructions, account history and your location — all of which bias the answer (e.g. toward agencies near you). Scans run clean and neutral, with no personal memory, against the market you configure, so results are comparable across clients and over time. • Live browsing. When the app browses the web, it pulls fresh results that change minute to minute. A scan captures a controlled snapshot. • Sampling. The same prompt returns different answers on repeat runs, because models sample. That's why CrunchJunkie runs each prompt several times and aggregates — one manual run is a single noisy sample. • Time. Models and the web index change constantly; a scan from last week and a check today will differ. The takeaway: a manual spot-check is one personalised, noisy data point. CrunchJunkie's value is the controlled, repeatable, multi-run measurement that averages out that noise — so you can track the trend and compare brands fairly, rather than reacting to a single screenshot.

A visibility line steps and three weeks later nobody remembers why. Was it a real change — or did you add two engines, switch the market, or pause scanning for a week? Timeline annotations answer that on the chart itself. CrunchJunkie writes most of them for you: whenever a project setting that affects measurement changes — market, language, engines, competitors, brand aliases, prompt set, passes per prompt, schedule, or scanning paused/resumed — an automatic annotation is recorded with the exact before/after. When an engine's provider swaps the model behind it (the same engine starts answering with a newer model), we record that too. Changes that alter what is measured (market, language, engines, competitors, aliases, prompts, a swapped model) are flagged specially, because a delta that spans one of them compares two different measurements. You can also add manual notes — "new pricing page live", "PR campaign started" — from the annotations panel on the visibility timeline. Every annotation is internal or shared, and the rule is strict: automatic annotations are always internal — your clients never see your configuration changes. A manual note you mark as shared appears in client-facing reports too: as numbered notes beneath the AI-visibility charts in the in-app report, the shared report link, and the PDF, so the client reads the same explanation next to the same line. Internal notes stay visible only inside the app.